企業「カジュアル面談にきてくださいよ」 求職者『はい、ぜひ』 企業「弊社を希望した理由は？」 求職者『は？』 求職者 ・・・帰宅・・・ 求職者 .oO( 正式応募どうしようかな。やめとくか ) メーラー 「ゆーがっためーる」 企業からのメール この度は、当社にご応募いただきまして、誠にありがとうございます。 残念ながら今回はほげ様のご期待に添えない結果となりました。 求職者『ちくしょう転職だ！※違う』 というような、カジュアル面談の悲劇を防ぐべく、情報をまとめようと思います。 補足になりますが、個人的な経験からくる恨みとかそういう動機からまとめているのではなく、今後採用に関わる可能性もある身として、界隈がよりよい状態になったほうが求人・求職側相互にとってよいだろう、という話を身近なエンジニア・人材界隈のビジネスをしている人・人事担当の人などと話し合った結果としての記事化です。 特に現状カジ

モチベーション3.0 で有名なダニエル・ピンク氏の著書「When 完璧なタイミングを科学する」を読みました。 そして手元にはダニエル・ピンク氏のサイン入り蔵書票が。 When 完璧なタイミングを科学する 作者: ダニエル・ピンク,勝間和代出版社/メーカー: 講談社発売日: 2018/09/06メディア: 単行本この商品を含むブログを見る 本の概要と蔵書票についてまとめます。 「When 完璧なタイミングを科学する」はどんな本か？ 「When 完璧なタイミングを科学する」は「いつ」に着目した本です。 1章では人間の生活リズムのタイプを3分類し、1日の中で上下に推移するパフォーマンスについて説明しています。 一番典型的なタイプは昼に向けて調子が上がっていきピークに到達し、その後夕方にかけて低下していき、夕方に再度あがっていく。 そんな傾向にあります。 こういった調子の傾向に合わせて、 どの時間

私には小学校低学年の娘がいます。 娘は3年以上前からセミが大の苦手で、夏になると恐怖で外にいることが苦痛に感じるほどでした。 この問題が今日解決したので経緯についてまとめます。 きっかけ 娘がなぜセミを苦手か質問をしました。 すると「セミが逃げるときにオシッコをかけてくることを知ったこと」がきっかけであることがわかりました。 汚いオシッコをかけられるという事実を元にセミへの恐怖感を膨らませていったようです。 第1手 第1手としてセミに対する印象を変えることを試みてみました。 セミの一生に関する情報娘に説明しました。 何年も土の下にいて、やっと外に出てきて懸命にいきているんだよ という話です。 娘はこの話に対して、理解し、共感はしたものの恐怖を拭い去ることはできませんでした。 第2手 セミに関して情報収集する過程で以下の情報を手に入れました。 セミの尿はほとんど水で有害物質は含まれない セミ

「システム開発において雑でもいいのでスピードを上げることが重要」という話をちょくちょく見かけます。 この文脈における 雑の定義 や 雑を適用する領域 ってみなさんどのあたりを想定して話しているのだろう？ と思ったのでざっくり整理してみようと思います。 私の前提 経験としてはSI'er下請けの立場でウォーターフォール型のプロジェクトのプログラマとして従事した経験が1番長いです。 個別のモジュールを担当するプログラマだったり、チーム全体の課題管理・レビューなどをするチームリーダーなどを経験しています。 全体的なシステム設計などアーキテクト的なことはやっていません。 現職では自社のシステムを開発しています。 明確にアジャイルをうたっているわけではないですが、 やり方はアジャイル開発に近いです。 副業でWebサービスの開発をお手伝いしています。 こちらも明確にアジャイルをうたっているわけではないで

あなたにとっては難しいことを「 そんなの簡単だよ 」と言われたことはありますか？ あなたにとっては簡単なことを「 それは難しいね 」と言われたことはありますか？ 「簡単」というのは人によって異なります。 「簡単」は「難しい」のかもしれません。 では「簡単」を分解して「難しい簡単」から「簡単な簡単」の集まりにしてみましょう。 簡単とは 単純で理解が容易なこと 時間や手間がかからないこと 今回は 1. に関する話です 簡単格差とは？ ※ 簡単格差はここで便宜上作った呼称です。正式に存在する用語ではありません。 人が物事を「簡単」と感じるかどうかは様々な要素で構成されており、 各要素の能力・知識が多いかどうかで結果は大きく変わってきます。 ある人物Aが簡単だと感じている対象と、 それに対して人物Bが感じる簡単さ（難しさ）の差を 簡単格差 と呼ぶことにします。 簡単の構成要素 人が物事を「簡単であ

Gitを理解するにはGitの中身の知るのが良い、 と天の声が聞こえてきたので学習がてらまとめることにしました。 この記事は個人メモ的な記事です。 基本的に既出情報なのでタイトルをみてピンと来ているかたは読む必要がありません。 ※この記事を読むタイミングとしてはGitの基本的な操作と概念をある程度理解した あとが良いと思います。曖昧な基準ですが。 Gitの2種類のコマンド 配管（ Plumbing ） コマンド 磁器（ Porcelain ） コマンド Gitの中身 Gitオブジェクト blob オブジェクト tree オブジェクト commit オブジェクト tag オブジェクト 参照 .git配下のファイル、ディレクトリの説明 HEAD ファイル index ファイル objects ディレクトリ refs ディレクトリ 関連資料 Gitの2種類のコマンド Gitの中身はキーバリュー型の

私には3人の娘がいます。 長女(7歳)と次女(4歳)が時々「どうせわたしなんか・・・」という卑屈モードに入ることがあり、 「これは自己肯定感や自信が足りないのではないか？」 という予想のもと、実体を知りつつ褒める機会を増やす施策として 「 今日あったこと報告ノート 」というものを導入しました。 自己肯定感 子どもの自己肯定感を高めるポイントは一般に2つ挙げられます。 愛されている実感 自信を持つこと です。 子どもに対する愛情はけっこういい感じに注ぐことができているのではないかな？ 特に妻はものすごく子どもに愛情を注いでいます。 ということで、今回は「自信」をもたせることにフォーカスをしました。 今日あったこと報告ノートとは？ 以下のルールを作りました たのしかったことを一つ以上書く おぼえたこと（できるようになったこと）を一つ以上書く ききたいことがあれば書く 困ったこと、相談したいこと

仕事に子育て。自分自身。モチベーションは行動の源泉力です。 一昔前は「アメとムチ」が効果的とされていましたし、現在もその視点で部下や子どもの育成に 取り組んでいる方もいると思います。 しかし、アメとムチは短期的な効果こそあれ、長期的には逆にモチベーションを削いでしまう。 長期的なモチベーションを与えるには内的動機づけを刺激する必要がある。 そういった理論を分かりやすくまとめたのが書籍「モチベーション3.0」です。 ターゲット この書籍を読むと役立ちそうなターゲット 部下を持つ上司 仕事、コミュニティ、学校の部活などチームの生産性を上げたい人 組織レベルの意思決定を行う人 子育て中のパパ、ママ 自分自身のモチベーションをうまく刺激できていないと感じている人 お客様と近い領域で仕事をしている人 要約 人間のモチベーションの歴史はモチベーション1.0からスタートします。 モチベーション1.0は生

ソフトウェア開発者に人気のポッドキャスト「rebuild.fm」で話題になっていた 週報仲間 。 2016年1月27日の配信 Aftershow 127 で取り上げられていました。 この放送を聞く二ヶ月前。私たちは分報仲間を開始していました。 ※この分報仲間には miira というチーム名がついています。ツイッターのプロフィールのmiira㌠はこのことです 前提情報 週報仲間とは？ 3行でまとめると 仲間内で課外活動の週報を送り合う 何を書くかは自由 他人の頑張りをみてやる気が高まる そんな活動です。 以下のブログエントリを読むと詳細が載っています。 bellflower.dodgson.org 分報とは？ 今やっていること、困っていることなどをSlackなどのチャットツールで特定のチャンネルを作ってつぶやく手法です。 社内Twitterと例えられているのもその特性が分かりやすくていいです

今日ふとしたきっかけで、娘と虹の色に関する会話になった。 娘「おとうさん、にじってどんないろがいくつあるんだっけ？」 私「うーん、わからないから調べてみよう。スマートフォンで調べるね」 娘「うん」（私のスマートフォンを覗き込んでくる） 私「みつけた」（Wikipediaの虹のページを娘に見せる） ※実際にスマホで見せた時はオレンジの後に折り返して次の行になっていた 私「赤・オレンジ・黄色・緑・水色・青・紫だね」 娘「あか・おれんじ・きいろ・みどり・みずいろ・あお・むらさきかー。うん、おぼえたよ！」（私のスマートフォンをみながら） ※娘は6歳で幼稚園の年長さんです。ひらがなとカタカナはわかりますが、漢字は読めません。 つまり、私が見せた画面の色と私の発言を理解することができますが、スマホに書かれているオレンジ以外の 漢字で書かれた色を読むことはできません。 ： しばらくあと ： 私「そういえ

日々の業務のワークフローの変更を伴うような大きめの施策を行う際に、 パターンカタログのフォーマットで導入判断を支援するようにすることで 意思決定が円滑にしたり、導入の背景の共有する試みを導入しはじめました。 パターンテンプレート Learning Patterns , Presentation Patterns などで利用されている パターンのテンプレートを流用させていただくことにしました。 -- Memo Context どのような状況を前提としているか Problem 解決すべき問題（抽象的） Forces 解決すべき問題の要因（具体的） Solution 解決索（抽象的） Actions 解決のための行動（具体的） Consequence 結果。ポジティブな結果とネガティブな副次効果を書く を元にします。 以下は、 Creative Shift で提供されているテンプレートです。 P

少し前に公開した、手作りすごろくを境に長女との遊び方を変えてきています。 ※以下、手作りすごろくの話のリンク tbpgr.hatenablog.com 今日は新しく思いついた遊びのみで長女と遊びました。 最近、手作りすごろくの件もあり長女に「パパが考えた新しい遊び」を 催促されることに。今日は延々と「パパが考えた新しい遊び」縛りで遊ぶことになりました。 まぁ、目新しい感じではないのだけど間髪開けず身近にあったものや 頭のなかに思いついた家のおもちゃなどを組み合わせてどんどん遊びました。 以下、今日遊んだもの。ちなみに順序は遊んだ順。 が付いているものは、遊んだ後に 長女に確認したら「すごくおもしろかった」という感想をもらったものです。 ゲーム一覧 バトンミントンの羽一回転 バトミントンのラケットのガットの上に羽を落として、跳ねた羽を立てるゲーム。 10回投げて立てた回数の多いほうが勝ち。

2015年の年末か2016年の年始あたりに著書「マンガでわかるWebデザイン」が発売される予定の プロのイラストレーター「湊川あい」さんに個人アイコン制作を依頼してみた結果をまとめます。 湊川さんの仕事っぷりは他のイラストレーターさんとはおそらくかなり異なるので、 誰に頼んでも似たような成果物を得られるわけではないと思います。 その点も含めてお知らせできればいいな、と思います。 経緯 私は基本的には企業でシステム開発および付随する業務を行うソフトウェア開発者です。 しかし、2013年末あたりから状況が一変してきました。 2013年12月末からCodeIQの出題者をすることになったのです。 以降、主力(色物)出題者の一人として現在も継続して出題を行っています。 所属組織においても1開発者というよりももうちょっと上の部分を担当する比率が増えてきました。 上長と組んで開発者の採用を担当したり、組

CodeIQで業界未経験の優秀な人材を効率良く狙い撃ちした話について。 経緯 今年度に入ってから、チームが新たな局面を迎えています。 今までは社内の1システムを主として,その他にいくつかのシステムを保守していたのが、 会社全体を見据えたシステム群の設計・開発をすることになりました。 技術的にも新たに導入が必要なものが多数あり、新規メンバーが必要となってました。 ※ちなみにシステム開発とは別の本業を行う親会社のための開発会社であり、 現状では社名をアピールすることが推奨されていないので匿名にします。 そのうち状況が変わるかもしれませんが。 前提 転職市場 ちょっと古い記事ですが、「なるほど」と思える記事があります。 第1回　エンジニアがなかなか採用できないワケ - なぜ，エンジニアの採用は難しいのか？ ポイントは以下です。 転職したいエンジニアは2割 絶対転職しないと思うエンジニアは1割 転

HugoとGitHub PagesでMarkdownベースのWebサイトをお手軽に構築します。 今回は行った作業の概要のみをまとめて細部については省略します。 経緯 CodeIQで出題しているデスマコロシアムのWebサイトを作りたい、 と前々から思っていて放置していたのですが、 最近CodeIQのアイコンイラストをお願いしている Webデザイナの湊川あいさんのアドバイスもあり着手することにしました。 作成しはじめた時点ではデスマコロシアムが最終回になる予定じゃなかったんですけどね・・・ 湊川あいさんについて マンガでわかるWebデザイン執筆中の湊川あいさんにデスマコロシアムのアイコンを発注しました。 これが成果物です。 湊川さんは、Webデザイナでありつつイラスト・SEO・マーケティングなど 幅広い知識を持っており、アイコンイラストのみの枠に閉じていません。 マネーフォワード社のエンジニア

概要 自動化・効率化 の検討方法を検討する 経緯 2015/01/18 から個人KPT を開始しました。経緯については下記参照。 個人での KPT の活用開始と KPT-CD という独自概念について 現在、実行中の try の中に 毎週土曜に自動、効率化を必ず行う 自動化検討タスク 自動化実装タスク があります。 日々増える大量のインプット・アウトプット。 どんどん増えるやりたいこと。 これに対応するために、定期スケジュールの中に自動化・効率化を組み込むことにしました。 そして本日が初回実施日。 着手するにあたって、自動化・効率化の検討を行う際の基準を決める必要がでてきました。 目的 自動・効率化によって時間を創出する。 自動・効率化のコスト - 自動・効率化による長期コストの削減 + 自動・効率化時に得られた技術的知見 = 自動・効率化利益 雑な感じだけど、上記のようなイメージで 自動・