以前同僚から、いくつかのプロジェクトやタスクを持っているときにどう進めると良いかという質問を受けた。僕はその時、価値が出るポイントまで一気に進めてから次のタスクに取り組むようにしていると答えた。この話についてブログに言語化してみる。 良くない進め方の一例 たとえばプロジェクトA（自分の担当分工数10日）、プロジェクトB（自分の担当分工数20日）で、合計30日分のタスクを持っているとする。この時良くない進め方は、両方ともを完全に並列に少しずつ行って、30日後に終わるということだ。1 このやり方だと30日後にならないとプロジェクトAもBも結果が出ない。もしプロジェクトAのみに集中して終わらせれば少なくともプロジェクトAの結果は10日後に出るのに関わらずである。 このやり方がまずいのは当たり前に見えるのだが、気をつけないとやってしまいがちである。なぜなら少しずつ進めれば、他の関係メンバーに「自分

「エンジニアメンター制度の効果的な運用を目指して」という発表をEngineering Manager Meetup #5でしました Engineering Manager Meetup #5で「エンジニアメンター制度の効果的な運用を目指して」という発表をしてきました。 自分も久々の発表で緊張しましたが、自分の頭をまとめる良い機会になりました。他の発表も学びが多く、とにかく濃いミートアップでした。このような機会を与えてくれた運営の方に感謝です。また機会があったら参加・発表したいです！ 以下は発表内容のまとめです。 発表内容 アジェンダ はてなのチーム横断のエンジニアメンター制度とは 実際にどのような課題があったか どのように改善したか 改善施策により最終的にどうなったか 今回の施策を通しての気付き: マネージャ向けにも当たり前のことをする イントロ 自分がマネージャっぽい仕事をしていると以下

はてなのチーム横断のエンジニアメンター制度 - Hatena Developer Blog で紹介していますが、はてなにはチーム横断のエンジニアメンター制度があります。僕も最近までメンターとして5~6人ほどのメンティーを持っていました(今は事情があってメンターをやっていないのですが)。 メンターとして1on1をする時には1on1ミーティングに備えるアンケート - しるろぐを参考にし、事前にメンティーに面談シートを書いてきてもらうという工夫をしていました。その面談シートは改善を少しずつ加えながら運用していたのですが、一度知見共有も兼ねて最近使っていた面談シートテンプレートを公開してみようと思います。 面談シートテンプレート 以下のようなフォーマットで書いてもらっています。1on1の前にメンティーに1on1用Google Docsに追記していってもらっています。1on1用Google Docs

最近メンタリング制度のことや、技術組織のことについて興味がある。最近「エンジニアリング組織論への招待」という本が出版されて話題になっていたので読んでみた。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング 作者:広木 大地技術評論社Amazon この本は、エンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」ということと述べている。その考え方に従って、思考方法、メンタリング、チーム運営、組織運営といったプログラミング以外でのやるべきことについて、様々な背景も含めて教えてくれる。 全部読んでみたところ本当に良い本であった。メンタリングや組織運営といった、なかなか汎用化や言語化がしにくい分野を、納得のできる形で言語化されていて本当にすごい。僕は最近はメンタリング制度について考えているので、特にChapter2のメンタリングの技術の章が一番

僕は自分がやったこと・勉強したこと・気づいたことなどはどんなにちょっとしたことでも、公開の場のブログに書くようにしている。その内容はある程度雑でも良いので、とにかく公開の場に書くようにしている。それによって、結構良いことが起こっているというのを社内の日記に書いていたのだけど、これも公開の場に書いておいても良いかと思ったので書く。 これまでの経験だと、次のような良いことが起こっている。 最低限未来の自分に理解できる程度まで記事にまとめることで、知識が頭の中で言語化され、定着する 時々他の人からフィードバックを受けて、さらに学習が進むことがある 「あれ昔なんか勉強したけど覚えてないな」という時に自分のブログ見たらすぐ思い出す 分からないことを調べようとググったら自分のブログが出てきてすぐ思い出す 初めからブログに書くつもりでインプットすると、自然と体系化・汎化しながらインプットできるようになる

最近効率的な課題解決について興味があり、パフォーマンス・マネジメントという本を見かけたので読んでみた。 パフォーマンス・マネジメント―問題解決のための行動分析学 作者:島宗 理米田出版Amazon この本は行動分析学という学問から個人や組織の課題解決にアプローチするという本。ストーリー形式で書かれており、そのストーリーで行動分析学という観点でどうやって問題を解決するかを教えてくれるため、あまり知識がなくとも理解がしやすい。ストーリー形式ではあるものの、きちんと理論的に説明しているので、信用もできる。 とにかくひたすら面白かった。それぞれの理論が正に自分の行動の原因を言い当てられているようで、人間ってけっこう単純に動いているんだな...という感想を抱いた。久しぶりに面白い本に会えたなーと感じるし、面白すぎて読書ノートが異常な量になってしまった。 この本は色んな人におすすめできる。自分でやりた

ふと、自分が初めて学ぶ知識をどのように学習しているか疑問に思ったので、考えてみたことをブログに書いておく。初めて学ぶ知識というのは、自分がやったことだと例えばマネジメント、プロジェクト管理、コーチングなどがある。 僕はある知識を初めて学ぶ時、まずはストーリー仕立てで知識を解説してくれる本を読んでいることが多い。特にそのストーリーの背景に体系的な理論が見え隠れするようなものであれば、さらに良いと感じている。例えば以下のブログで紹介したような本を最初に読んでいる。 つかまらない上司にならないために - 1分間マネジャーの時間管理を読んだ - $shibayu36->blog; モチベーションと目標設定・教育と褒める叱る - 「1分間マネジャー」を読んだ - $shibayu36->blog; 問題の効率的な解決方法を学ぶ - 「世界一やさしい問題解決の授業」読んだ - $shibayu36->

以前 ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog; で、「ゴールを決め、現在位置とのギャップを考え、目標を決める」と良いということをまとめた。イメージとしては以下の図の通り。 しかし、前回の記事だと具体的にどのようにエンジニアの目標設定を行うかイメージが湧かない。そこで、もう少し具体的に最近どのようにやっていたかを書いてみたいと思う。 僕がメンティーと目標設定を行うときは、以下のフローを辿っている。 なんでも良いのでゴールのイメージを明確にする 現在の自分とゴールのイメージのギャップを考える ギャップを埋める目標を考え、アクションを定める ちなみに今回は、チームの成果達成のために個人の目標を決めるのではなく、エンジニアのスキル向上の目標を立てるという前提で書いていく。 なんでも良いのでゴールのイメージを明確にする

半年前から会社でシニアエンジニアという役職で、エンジニアのメンターの役割を担っている。その役割を出来るだけうまく演じられるように、半年間はコーチングの学習を進めてきた。 目標設定の仕方を学ぶ - 「ザ・コーチ」読んだ - $shibayu36->blog; なぜ最近コーチングや人間の学習モデルの勉強をしているのか - $shibayu36->blog; 「コーチングのすべて」読んだ - $shibayu36->blog; また、半年間、目標・1on1・評価と一通りの業務をこなし、コーチングの実践が出来た。 そこで今回はコーチングの学習と一通りの実践を通して学んだことで、特に役に立ったと思うことについて一旦まとめてみる。特に役に立ったと思った知識は以下の二つである。 ゴールを決め、現在位置とのギャップを考え、目標を決める 解決案を与えるのではなく質問する ゴールを決め、現在位置とのギャップを

本職の企画の人が優れた機能案を出してくる理由がわからなくて、どうやってやってるんですかと雑談した。新たな発見があったので、雑なメモだけ残しておく。*1 その人の企画の流れ 企画の流れは、以下の3ステップで行っているらしい。 1. 登場人物を分類する 2. 登場人物ごとの振る舞いを分解する 3. 様々な振る舞いを照らし合わせて、機能・UIを絞り込んでいく 「1. 登場人物を分類する」は、機能に関わる人物をツリー構造に分類していき、分類をした結果から、その機能を使うメインターゲットを決めるフェーズらしい。 例えば、ブログユーザーをブログの作者と読者に、さらに作者を毎日更新する人とそうでない人に、みたいにどんどん分解していく。すると、機能のメインターゲットが浮かんでくる。 「2. 登場人物ごとの振る舞いを分解する」では、メインターゲットを中心に、どのような振る舞いをするかを考えるフェーズらしい。

サービスの成長について少しだけ理解を深めたくて読んだ。 いちばんやさしいグロースハックの教本 人気講師が教える急成長マーケティング戦略 (「いちばんやさしい教本」シリーズ) 作者:金山 裕樹,梶谷 健人インプレスAmazon この本では、サービスを成長させるためにはどのようなことを行えば良いか、具体的な例をあげながら紹介している。いわゆるバズワード的なグロースハックの解説というよりも、きちんとサービスの成長を考えるようなものになっていてよかった。 この本は次のように具体的に、まずこうやってみましょうと提示されているところが良いと思った。書かれている内容を参考にして、まず手を動かしてみて自分の知識に変えていくというのがスムーズにできそう。 施策はActivation, Retention, Referral, Revenue, Acquisitionの順に行う 成長のステージごとに施策を変え

最近以下のようにコーチングや人間の学習モデルの勉強をしている。 目標設定の仕方を学ぶ - 「ザ・コーチ」読んだ - $shibayu36->blog; 「リファクタリング・ウェットウェア」を再読した - $shibayu36->blog; 「コーチングのすべて」という本を今読んでいる そこで、自分の考えをまとめるためにも、なぜ最近コーチングや人間の学習モデルの勉強をしているか書いてみようと思う。 最近、株式会社はてなという会社で、シニアエンジニアというポジションに付いた。シニアエンジニアは、数人のエンジニアのメンターとして、目標設定・1on1面談・評価などを行うポジションだ。また、社内のエンジニアの一つのロールモデルとなれるような態度を求められる。 このポジションになった時に、まず初めに考えたことは、このポジションとして求められていることは何なのかということだった。考えた結果、数人のエンジ

最近、学生時代よりも学習時間を取れなくなっていて、このままだと新しいことが身につかなくなっていっていくのではという危機感があった。またメンターをするにあたって、人の学習モデルをある程度理解しておいて、アドバイス出来るようにしたいという思いもあった。そこで、昔読んだ「リファクタリング・ウェットウェア」に、学習に関することが書いてあった記憶があったので、さらっと再読した。 [asin:4873114039:detail] この本は、人間の脳について研究していた著者が、脳の働き方などについて解説し、その上で脳を活かすためにはどのようにしたら良いかについて解説している本。脳をハックするということを題材にしているのが面白い。 この本を読むと、人間の技能習得モデルとか、より良い学習の仕方とか、直感をうまく活かす手法とか、そのようなことを学ぶことが出来る。一度でも読んでおくと、今後の学習が効率的になるの

最近コーチングという分野に興味を持って、まずは簡単でさくっと読めそうな「ザ・コーチ」という本を読んだ。 ザ・コーチ 最高の自分に気づく本 (小学館文庫プレジデントセレクト) 作者:貴彦, 谷口小学館Amazon この本は、副題も含めると「ザ・コーチ - 最高の自分に出会える『目標の達人ノート』」という題名で、その名のとおり目標設定をなぜ行うのか、どうやって行うのかについて知ることが出来る本だった。1分間シリーズのように小説形式となっていて、すぐに読むことが出来る。 現在、自分が目標って何のためにあるのかもう一度知りたいと思っていた時期だったので、非常に面白かった。読書メモがかなりの量になった。マネージャーをやっている人や、その方向に行きたいと思っている人、他にも教育を担当している人は是非おすすめ。 以下のことが印象に残ったので、それについて書こうと思う。 目的・目標・ゴールの定義と、目標設

これまで少し大きめな機能であれば、コードを書く前にまず仕様や実装の方針をissueのdescriptionにまとめ、それを先にレビューしてもらってから実装にとりかかるということをしていた。最近、その方針をそもそもrepositoryのファイルとして書いて、PullRequestしてレビューしてもらうようにしたら便利だったのでご紹介。 なぜコードを書く前に仕様や実装の方針をレビューするのか 前提としてなぜコードを書く前に仕様や実装の方針をレビューして欲しいのかについて書いておく。これはとにかく手戻りの量を少なくしたいという要求のためである。 実装に取り掛かろうとすると、実装の方針はいくつか思いつくが、どれが一番よいか迷うことはよくある。その場合に誰にも相談せず自分だけで判断し、コードを書いてからPullRequestを送った場合、もしその選択に重大なミスがあった場合全て書きなおさないといけな

HTML5/CSS3モダンコーディング フロントエンドエンジニアが教える3つの本格レイアウト スタンダード・グリッド・シングルページレイアウトの作り方 作者:吉田真麻翔泳社Amazon 最近自分のプロジェクトのデザイナが、JavaScriptで実装しないといけないと思っていたことをどんどんCSSで実装していくのを見かけた。この出来事から、JSで実装したほうが良いか、デザイナにやってもらったほうが良いか、どちらが良いかを自分で判断できてないと感じたので、最近のCSS事情を知りたいと思って読んだ。サラッと流し読みするだけで、CSS3で利用できるようになったよく使うプロパティの概要を把握できたので、今の自分の知りたいことが分かって非常に良かった。 例えば以下のことを学ぶことが出来た。 reset.css, normalize.cssとはなにか beforeやafter擬似要素を使ったいろんな技

昔に動的言語だとひたすらテストを書かないといけないけど、静的型チェックの仕組みがあればそんなにテストを書かなくてもいいよねみたいな話があった記憶がある。昔は結局どうなんだろうと思ってたのだけど、最近もそういう話を耳にして、やっぱりそんなことないだろうという気持ちになったのでメモ。ふと思いついただけなので正当性は分からない。 まずなぜそのような話になるのか考えたのだけど、「静的言語ならコンパイル時に型チェックをすることができるため安全性を高められる」という点からこういう話が上がってきているように思う。しかしよく考えてみると、静的型チェックという仕組みは、プログラムテキストとして正当であるかという点しか保証していない。つまり、特定の変数が必ずその型であるとか、特定のエンティティからのメソッド呼び出しが正しいか(メソッド名や引数など)とか、関数が返す型がかならず指定した型になるかとか、そのような

最近コードレビューをどのように回していくかについて考えたことがあったのでブログに書いておく。 コードレビューの目的 コードレビューには誤りの発見以外にいろいろな目的がある。自分の中ではid:hisaichi5518が昔プレゼンでまとめていた目的が結構しっくり来ている。 https://speakerdeck.com/hisaichi5518/kodorebiyufalsehua?slide=8 http://hisaichi5518.hatenablog.jp/entry/2014/10/29/165721 機械的に発見できない誤りの発見 技術力の向上 属人性の排除 コードレビューの目的としては誤りの発見と同様に、技術力の向上や属人性の排除といった教育的側面も重要である。 コードレビューで課題に思っていたこと 自分のチームでは基本的に一人がコードレビューをして、OKだったらmergeをして

コード中に後でやろうと思って以下の様なTODOコメントを書くことがあります。TODOコメントというのは # TODO: 後でリファクタリングしたい ... # TODO: 投稿機能ができたら置き換えること ... みたいなやつです。 コード中にTODOコメントを気軽に書いてしまいがちですが、よくTODOコメントが放置されて気づいたらプロジェクト中に大量のTODOコメントが書かれたりすることがあります。直せる量を超えてくると、直すモチベーションも下がってきて、結局ただのコメントと同じ状態になります。 最近いろいろ工夫して、TODOコメントの書き方を変えたところ、そこそこうまく回ったのでメモしておきます。 TODOコメントの問題点 問題点として次のものがあると考えました。 (1) 書く人によって形式がバラバラ TODO, XXX, FIXMEなどバラバラだったりする (2) TODOコメントの

ディレクター時代に仕事でプロジェクトを受け持つ時にどうやったら成功させることが出来るのかについていろいろ考えていた。僕は開発フローをいろいろ考えるのが好きなのだけど、実際に自分がリーダーシップを取ってプロジェクトを進めることを経験すると、そもそもその前に考える・決めるべきことがたくさんあるということが分かったので、ブログに書いておこうと思う。 ここで言うプロジェクトとはサービスを一から作ったり、サービスの一機能を作ったり、受託案件一つだったりを指す。特に開発プロジェクトに限定するものでもない。 プロジェクトを成功に近づけるためには、まずプロジェクトの開始時に、プロジェクトの5W1Hを明確にし、個々のメンバーの責任範囲を決め、それらを一つの場所にまとめておくということをしておくと良いと考えている。 5W1Hを決める すごい基本的なことだけど、プロジェクトをやる上でやはり5W1Hは大事である。