素晴らしい本です。「不確実性を減らすために」という考え方をするようになりました。
1. 思考のリファクタリング
元々マネジメントをやる前から吹き込まれてきたことなのですんなり腹落ちしました。
曖昧→具体に変えていくことがエンジニアリング活動
コミュニケーションの不確実性を減らす
情報の非対称性を減らす
2.メンタリングの技術
マネージャーをやる以前に採用・教育(オンボーディング)活動を2年やってきているので、ティーチング/コーチングの話や自走を促すための方法論には共感・補強ができました。
「内心」ではなく「行動」に注目すること p.168
本当にそう。内心を理解しようとして、自身のメンタル含めてお互いに消耗したことがあるのでSMARTの原則を心がける。
3. アジャイルなチームの原理
マネジメントとは、対象となる○○の資源・資産・リスクを管理し、効果を最大化する手法 p.191
現状、エンジニアリングとプロダクトの２つのマネジメントをしているが、それぞれに当てはめて言える簡潔な表現だと思います。
PdMは下記に対処し、プロダクトを継続発展させること。(受け持っているプロダクトはこの辺り弱いなあ...)
損益分岐点を発展すること
マーケット不安を減少させること
アジャイル開発とは「チーム全体をメンタリング」するための方法論であって、開発方式ではありません。 p.198
Clean Agileの概要にこういうこと書いてあったけど、気がついたら手法や開発方式に目が行きがちですよね...。
アジャイルとは、小さなことをしている小さなプログラミングチームの小さな問題を扱う小さなアイデアである。アジャイルとは、大きなことをしている大きなプログラミングチームの大きな問題を扱う大きなアイデアではない。大きなことは大きなチームなんかじゃできない。小さなことをする小さなチームがいくつも集まり、コラボレーションしながら大きなことを成し遂げるのだ。このことを、我々はあらためて認識する必要がある。
エンジニアリング組織論への招待を読む前は、私自身かなり手法原理主義でしたが、目的達成のために考えることを放棄したらダメだなと思うようになりました。(その上でアジャイルプラクティスいいねってやっていきたい)
「アジャイルなチーム」を作るという目的を達成しながら、「ウォーターフォール」という言葉で意識されがちなスケジュール不安について中心に対応するようなプロセスや文化を作り上げていくことができます p.239
アジャイルを何に適用するのか？(人、チーム、開発方式、会社) そういうことを考えていくことがアジャイルの本質なのかも。
4. 学習するチームと不確実性マネジメント
めちゃくちゃ好きな章。
制約スラックとかクリティカルパスとかは輸送最適化とかで大学時代にやったので親近感がありますね。 ダミーデータを作る話とかはテストファーストの意義にも繋がるなと思いました。
プリンシパル・エージェント理論
コントロールコスト
シグナリングコスト
エージェンシースラック
この辺りはお話形式だけど、じっくり読んだ方が良いと感じました。
ベロシティの誤用には気を付ける。(ベロシティは相対見積もりのためチーム間共有できる尺度ではない) これは私だけがわかっていてもダメだということは身をしみて理解している...。
仮説の不確実性が下がるまでは、大きな予算をかけることは無駄になってしまうかもしれません。ですので、できるだけ安いコストをかけて順番に仮説を検証していきます p.309
これを新規のプロダクトで実践予定...。(PoC時点にプロトタイプを用意して仮説検証する)
スクラムはいつどのようにチームが課題と不安に向き合うのかを規定して、改善を行うためのタイミングを矯正するためのフレームワークであること p.316
スクラムイベントの有用性は3年程度運用しているので、ある程度は理解しています。 チーム(チームメンバー)のペインポイントが丸わかりになるので、個人的にスクラムを採用しなくても(カンバン形式とかXPでも)スクラムイベントはやるべきだと思います。
5. 技術組織の力学とアーキテクチャ
「エンジニア」の「技術組織」といった企業における1要素の付加価値がわかりませんので、エンジニアの生産性といったものは特定することができません。企業における付加価値額というものは、営業や技術といった個別の部署で測定できるものではありません。企業全体をシステムとして、投入した労働人数に対してどれだけの付加価値が得られているのかを測るものです p.325
労働生産性の話ですが、これは私も強く組織に言いたい。特定の部署を特定の尺度で生産性測定し、その良し悪しを見ることはやめるべきだと。 本書では測定できないの一点張りですが、個人的見解では、さらに部署内での局所最適化(最悪の場合生産性指標のハック)や従業員満足度の低下があるとみています。 例えば生産性を上げる方法として人件費を極限まで削るという方法があるわけです。あとは言うまでもないでしょう。 この労働生産性をブレイクダウンして数値化する行いも愚かだと認識しています。(本書でもそもそも測れないって言及しているわけで) 付加価値額や人件費というのは定量的ですが、これを支えるプラクティスは定性的なものも多いと思っています。それを従業員に自発的にやってもらうには権限移譲し、その結果の分析体制と判断の明確化が必要だと思います。
5.2.権限委譲とアカウンタビリティ p.341
大事。
責任と権限は、整合性をもたなければなりません。権限がないのに責任がある状態や、責任がないのに権限がある状態はどちらも組織に悪い結果をもたらします。 p.343
ほんとにそう。
そもそも「クイック&ダーティ」というトレードオフというものが成立するのかというのは常に考えの中に入れておく必要があります p.364
これは t_wadaさんがよく言及している「質とスピード」というもの。定期的にアップデートして、講演されているので、ウォッチしています。
エンジニアと経営者の技術負債に関する認識の違いには気をつけたい。
アーキテクチャの複雑性
将来要件の複雑性
なぜか、社内間やりとりなのに、社外と同レベルのコミュニケーションコストがかかるってめちゃくちゃわかりますね...。イノベーションを生み出したいなら機能横断チームの必要性が書かれていて、納得感しかないです。もちろん機能別組織の良さというのも本書や実体験から理解しています。
OKRの先進的なポイントは「目標による管理」をしっかりとやり直そうという話だけではありません。もう1つの重要なポイントは、「透明性」を重視することです。目標設定を通じて、従業員1人ひとりが組織全体を見渡して、自分が何のために仕事をしているのかを深く理解するというのが、OKRの果たす重要な役割です。 p.414
MBO, OKRは両方経験していて、現在はOKRを利用しています。(MBOに関しては私より上のレイヤーが管理しているため) 利用意図として、チームメンバーに自身の仕事の意味を理解して自走しやすくしたいなという意味合いが強いです。
逆コンウェイ作戦って最近よく聞くトピックだなと思ってましたが、わかりやすく学ぶことができました。
参考文献
広木 大地. エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング (Japanese Edition)