界隈でも話題のMicrosoft 牛尾さんの本。
買おうかなーどうしようかなーと思いつつ本屋で少し立ち読みしたら面白かったので買って読んでみた（読みやすく2日くらいでサクッと読めた）。
Microsoftのイケてる技術者たちの考え方や仕事の仕方を見てみたくて買ったけど、牛尾さんと同僚たちの色々なエピソードが載っており単純に読み物としても面白かった。
具体的なTipsも色々と参考になるものがあり、これを機に普段の自分の働き方も見直してみたいと思う。
ただ自分としては、最後の章の日本特有の批判文化についての牛尾さんの考察のところが一番刺さったかもしれない。具体的なエピソードとして、善意から始まったコロナ下での接触確認アプリCocoaが、リリース後にSNSでボロクソに言われまくったという話が挙がっており、そんなことがあったとは知らなかった…。確かに、自分も今はエンジニアリングの話題もたくさんTwitterでフォローしているから感じるけど、界隈では基本常に何かの批判の話題ばかりのように思える。。アメリカ流の、相手を否定しない、コントリビュートと感謝のループの文化が作れるよう一人一人が意識をしていかなければならないと強く思った。もちろんアメリカにも色々な企業があるし一括りには出来ないと思うけど、そういった文化がある向こうでは皆が楽しく感謝しあいながら働いておりそれが高い生産性に繋がっているのだなぁ、と本全体を読んで感じた。
メモ
- 障害の対処について
- いきなり手を動かしとにかく試行錯誤して時間を浪費するより、事実（ログ、データ）を確認し仮説を立てる→その仮説を証明するための行動を取る。これは当たり前と言えば当たり前だけど、つい手を動かして「よくわからんがとりあえず怪しいかもしれないところを変えて動かして結果を見る」を繰り返して時間を浪費、とかやりがち。実際仕事でも、解決後に「ちゃんとログを丁寧に読んで考えてればもっと早くわかったかもなー…」ということがあったりした。次にこのような場面に出会ったらまず一度落ち着いて事実を確認することを意識してみたい。
- 思いつきで色々試しても時間がかかるうえ新しいことを何も学んでいない。
- いきなり手を動かしとにかく試行錯誤して時間を浪費するより、事実（ログ、データ）を確認し仮説を立てる→その仮説を証明するための行動を取る。これは当たり前と言えば当たり前だけど、つい手を動かして「よくわからんがとりあえず怪しいかもしれないところを変えて動かして結果を見る」を繰り返して時間を浪費、とかやりがち。実際仕事でも、解決後に「ちゃんとログを丁寧に読んで考えてればもっと早くわかったかもなー…」ということがあったりした。次にこのような場面に出会ったらまず一度落ち着いて事実を確認することを意識してみたい。
- どんなに頭が良い人でも何かをちゃんと理解するのには時間がかかる。
- 結果を出すことを焦るあまり、しっかり理解するのを焦ってはいけないという話。
- 小さなドキュメントをコードの前に書く
- これは普段自分もやっているかも
- BeLazy：より少ない時間で価値を最大化する
- いかにやることを減らすか？
- 1番重要な1つだけピックアップする
- 仕事を固定して出来ることを最大化する
- あれもこれもは、無理
- 「準備」「持ち帰り」をやめてなるべくその場で解決する
- いかにやることを減らすか？
- 失敗を受け入れる
- フィードバックを歓迎するムードを作る
- 「検討」をやめて「検証」する
- 早く失敗する（Fail Fast）
- 不確実性を受け入れる
- ソフトウェア開発は計画通りいかないものであり計画通りいかないことは失敗ではない。スピーディに軌道修正出来る柔軟性のほうが遥かに大切
- 進捗の実績だけで状況判断し納期を固定したままスコープを出し入れする
- 計画は「今のところは、こういう予定」くらいの感覚で見た方が良い
- 絶対にデッドラインを割りたくない案件だったらシンプルに早く始めるしかない
- コードリーディングのコツは極力コードを読まないこと
- 実装の隅々まで見るより、インターフェースを追う
- 生産性とはいかに「ググらずに実装できる」を増やすか
- ここにも「結果を出すことを焦らない」考え方が通ずる
- マルチタスクは生産性が最低なのでやらない
- 「WIP=1」を保つ
- 自分がやったからと言って理解できているとは限らない
- 説明可能か？の意識が大事
- 「説明可能」に持っていくための有効な手段：新しいことを学んだらブログに書く。サンプルコードはそのまま使うのではなく、自分なりに変えたものを作る
- 説明可能か？の意識が大事
- 「作業内容を人にそらで説明できるか」を記憶できたかのチェックポイントにする
- コーネルメソッド
- 頭の中のみで整理する：記憶力向上のFA
- 人の話を聞くときは、他の人に説明することを想定して、頭の中で整理しながら聞く
- 情報量を減らす
- たくさん情報があっても消化できないだろう？の感覚（脳への負荷が軽い）
- 最初から全部説明しない。たくさん書いてあったりしても読むのが大変。付加的な情報は聞かれた時でOK
- 相手が求めている情報への感度を研ぎ澄ます
- 日頃から人に伝えることを前提とした整理をしておく
- コードを「読み物」として扱う
- 「読んだ人がどう感じるか？」を意識してコードを書く
- クイックコール（予定されていない通話）の活用
- 自分にその分野のコンテキストがなければまずエキスパートに聞いた方が良い→かなりショートカットできる
- 相手が忙しいかは考える必要は無い、メッセージがスルーされたらたぶん忙しい
- クイックコールがすぐに無理なら、ミーティングの設定を依頼する
- 一つ配慮すべきポイントは、「相手が労力を要せず回答できるものか」
- 気軽に聞ける空気の大切さ
- 「そんなん聞くの？」ってことでも聞いて良い。Microsoftでは優秀な人もそういう質問をしている
- 皆が気軽に聞くことを実践すると組織全体の効率は上がる
- 気軽に聞ける仕組みは気軽に断れる空気とセット
- 自分では助けになれないものは気軽に他の人に聞くことを促したりできる
- ディスカッションは自分の考えを自分なりに深めるための行為であり初心者こそやった方が良い
- 間違えたら恥ずかしいという感覚は一切捨てること
- 「相手を否定しない」「相手のアイデアを否定しない」「自分の考えとして意見を言う」
- 「In my opinion」：あくまで自分の意見であるという配慮
- チームの上下関係を無くす
- スキルや経験に関係なく、全員が同じ責任を持っているフラットな仲間としてふるまう
- 失敗に寛容な雰囲気がチャレンジ精神を生む
- 生産性を上げたければ定時上がりが効率が良い
- 日本にとって致命的な足枷になりかねない独特の批判文化をやめる
- アプリケーションはどんなに優秀なチームが開発しようが、必ず何かしらの不具合は存在する
- 批判の文化が開発者の心を砕く
- 良いところが9あっても、問題が1であっても、1をクローズアップし批判される
- アメリカの文化：コントリビュートと感謝のループ
