はじめに

Microsoftのソフトウェアエンジニア 牛尾 剛さんが、ご自身の経験や学んだマインドセットやスキルを整理して紹介された書籍。個人的に特に重要だと感じたポイントを抽出して書き残しておく。

試行錯誤は「悪」

手当たり次第に試行錯誤すると時間がかかる上に、解決できたとしても次回に活かせる学びを得られない。「情報収集 -> 仮説 -> 仮説検証 -> 実行 (不十分なら先頭に戻る)」というプロセスが重要である、と紹介されている。
これはたしかに、特にトラブルシュート時にやってしまいがち。よくあるのは「取り急ぎデバイスやアプリを再起動してみたら、なぜか直った」ではないかと思っていて、この場合は再発防止策を打てないし、次に似たような問題が発生しても再起動を案内する以外になにもできない。もちろん一刻の猶予もなく、喫緊の問題の解決を求められるシーンもあるが、時間の許す範囲でしっかりとデータと向き合い、そして仮説を立てる(できれば複数案)ことを意識したい。

メンタルモデルをつくる

僕が新しいミッションに取り組む場合、業務プロセスやシステム構成の全体観を粗く鳥瞰するところからまず始めるようにしている。その後に、特に重要そうな箇所から順に各論の理解を進める。これは著者のやり方とおそらく同じで安心したが、ただ必ずしもこうやる必要はないそう。自分なりに脳内イメージをつくり、考えを整理したり、問題解決のプロセスを高速化できる方法を見つければよい(本書では「なぜなぜ分析」も紹介されていた)。
あと、僕はなるべくメンタルモデルは頭の中でつくるようにしている。書くと書いただけで理解した気になりそうなのと、手元にパソコンやスマートフォンも無い状況でもある程度は説明できるぐらい理解しておきたいからだ。

ひとつのことにフォーカスする

バックログの優先順位

本書では以下の例が紹介されている。
🇯🇵日本人 … すべてのタスクに優先順位をつける。無理なら実施しないが、時間が許せばすべて実施したい。
🇺🇸アメリカ人 … もっとも重要な1個をピックアップしたら、他はやらない。その1個にフォーカスする。
僕自身、たしかにこの例の日本人のようなことはやってしまいがち。メンバーからすると「結局『すべてやれ』ということね」と認識されているかも。リソースのキャパシティを踏まえて、もっとも効果的なインパクトを与えられるタスクに絞る決断を下せるようになりたい。

シングルタスクと、個人ワーク時間の確保

詳しくは記事が公開されているので、参照いただきたい。
「会議中に内職して、会議内容をド忘れして、録画を視聴する(議事録を読む)」「SlackとWebブラウザを往復しているうちに別のことが気になって、最初にやる予定だったことを完全に忘れる」といったしょうもないことをやっている身としては、なんとも耳の痛い話だった…。

メンバーが幸せに働けるチームビルディング

著者が紹介している優れたマネージャーは、以下のような特徴があるよう。

• チームメンバーが楽しく、幸せに働ける環境づくりに関心を寄せ、エンパワーする。

• 細かく指示することはない。一度メンバーに任せたら、あとは信頼する。

• メンバーが困って求めてきたときは、アドバイスをくれる。メンバーが詰まっていたら、そのブロッカーを取り除いてくれる。

• チャレンジした結果の失敗に対して寛容である。

僕個人としては、特に2点目と3点目が難しいと感じている。会議やSlackなどでの日々のやり取りの中で「ちょっと怪しい」「少し違う」「この細部がこう変わると、80点が85点になりそう」と感じると、つい口を出してしまう節がある。マネージャーの顔つきで仕事をする際は、自分はチームのサポーターである、と認識して振る舞うようにしたい。