エンジニアリング組織論への招待の感想
■初めに
2018年の春から夏ごろでしょうか、Twitterでこの本が多くの方に読まれていることを知りました。その当時の私は、まだチームのことを考えるよりは個人として言語やフレームワークを勉強してできる範囲を広げたいと思っていたので、いつかは読みたいけどまだ読まなくていいかなと思っていました。
2019年の9月以降でしょうかデータ基盤チームが発足しリーダーとしてチームにジョインしました。その中で今までは既存のシステムで新機能開発や改修をしていましたが、まったくの新規システムかつクラウドとしてGCPを利用するのですがそちらの知見もなかったので、技術のキャッチアップとシステム開発を並行して行っていのですが、事業部側とエンジニアの間にギャップが生まれるようになりました。そのころからアジャイル的な開発（スクラム）をやった方が良いのでは？もっと事業部側に開発状況を伝え互いに何をやっているのかを把握する方が効率的なのでは？と思うようになりました。
そして、ふとエンジニアリング組織論への招待を思い出したので読んでみると。。。事業部とのもやもや、エンジニア間のもやもやの正体は何を作りたいのか、いつできるのか、どう作るのかなどの不確実性が大きくかかわっていることがわかりました。この時の気持ちが晴れたような気がしたのでその気持ちを忘れないようにするために、読書感想としてnoteに記事を残そうと思いました。
ちなみに著者が出演者として出ているこのポットキャストは非常に面白かったです。著書と合わせて読むと内容の理解が深まりました。
■思考のリファクタリング
問題解決より問題発見（認識）の方が難しい。
最初の章を読んだときに非常に心に残った部分でした。著書の中では学校の勉強と仕事を対比させながら、なぜ現実世界の問題を解決していくことが難しいのかを説明していました。開発をしていると「こんな機能ほしい」などの依頼を受けますが依頼内容がかなり抽象的な為、できるできないの判断がつかない場合があります。で、よくよく依頼者に依頼背景を聞くと、実は新機能を作るのでなく既存の改修で事足りるなどのことがあります。互いの立場が見えていなく小さい世界のスコープで物事を見ているため、別方法での解決策を考えるとができなくなり、問題発見（認識）が正確に行えないのです。
このような経験を積んでいくと、不確実性がチーム間や現場で高まってしまいます。ここでいう不確実性は下記になります。
環境不確実性（未来）
通信不確実性（コミュニケーション）
つまり、仕事をしたくなります。ゴールは一緒のはずなのに不確実性のために、ゴールに向かっていくことができない状態を打開するために、著書ではエンジニアリングを再度見つ目直します。
不確実性を削除し、秩序を作る
と、定義されています。だからこそ、システムを作っていく過程で発生することは基本的にエンジニアリングとして私は捉えるようにしました。（プロダクトオーナーとのMTGや営業にシステム説明するときも）また、不確実なことに対して悩むよりも、実際に経験する経験主義と仮説思考を用いることで、行動として物事をとらえていくことが不確実性をなくすには必須であることも理解しました。つまり、開発などのサイクルをしっかり回しながら成長することが不確実性と向き合うと認識しました。
■メンタリングの技術
「悩む」と「考える」の違い
「考える」は行動で、「悩む」は状態
メンティーがPCの前で腕組みをしている場合、何かを考えているのか悩んでいるのかわかりかねますが、その状態が例えば30分以上つづいているとメンティーは悩んでいる状態と判断できます。「考える」と「悩む」の違いは行動をしているかしていないかの違いです。
行動 => やることが明確になっているから行動ができる。
一見当たり前のようですが、再度文章として読んでみると納得度が違いました。メンティーを教える際には行動に注目して観察してみようと思いました。
■アジャイルなチームの原理
アジャイル ＝ ある理想な状態
チームが環境に適応して、不確実性を最も効率よく削減できている状態
アジャイルは不確実性をチームで削減していく方法ですが、この状態になるためにチームは常に「どのようにしたら、私たちはもっと不確実性を減らすことできるのだろうか」を問い続けなければならい。
不確実性を簡単にまとめると下記になります。
不確実性
未来：環境不確実性（方法不確実性、目的不確実性）
他人：通信不確実性
方法論としては下記が挙げられていました。
不安に向き合うこと
少人数の対話を重視する
役割を分けない
経験のみを知識に変える
意思決定を遅延する
価値の流れを最適化する
特に気になったのは「価値の流れを最適化する」点です。プロダクト型チームは時間内にどれだけ要求に応えるかを最適化するチームなため、レスポンスタイムよりスループットに焦点をあてます。要求の処理が何が原因で滞っているかを探して改善していきます。アジャイルな開発ですと、プロダクトを永続的に開発（改善）し続ける視点のためチーム間の力量を見極めながら、無理なく開発効率の最適化を常に模索することも必須の要件だと思います。
■学習するチームと不確実性マネージメント
不確実性を「見える」状態にする
スケジュールを作成するにあたり「計画ではなく実績から予測する」ことが重要と示しています。ここで言う実績とは、小さいSprintを行いVelocityを測定することで、より見積もりの測定の精度を上げていく（Velocityを安定させる）ことで将来の見通しをしやすくしていくことできます。
Velocityから未来を予測する際に、4種類（偏差、最悪、平均、最高）のVelocityから完了予定を推定する。
またユーザーストーリーとタスクを紐づけることで、多点見積もりを導入し最悪の場合のストーリーポイントがどれだけ消費されたのかを見ていくかといった手法も取り入れることで、チーム全体としてスケジュールの不確実な状態を削減することに努めていくことが、開発者は開発算段をつけることができ、事業部側は全体化を常に把握できるようになるのもだと理解しました。ここでの理解を実際の開発の現場で利用したいと思います。
■技術組織の力学とアーキテクチャ
生産性の低下 ＝ 情報の非対称性
アメリカの経済学者のガルブレイスによる組織の情報処理モデルと不確実性（目的、方法、通信）を絡めながらその中で情報処理能力が日常的に使われる「生産性」のイメージと近しいと記載されています。
不確実性 ガルブレイスの情報処理モデル
目的不確実性 - 情報処理必要量
方法不確実性 - 情報処理能力
通信不確実性 - 情報処理能力
ここから読み取ることができることは、情報処理能力とは「方法」と「通信（コミュニケーション）」が原因で、組織として生産性を低下させていることがわかります。そして、コミュニケーションによる情報の非対称性が組織として生まれ、部分的には最適化は出来ているが全体でみたときに最適化できていない状態を生み出しているのです。
その解決策として下記を上げています。
対策
- 権限の委譲と期待値調整
コミュニケーションの必要性を減らす
- 適切な組織・コミュニケーション・外部リソースの調整
コミュニケーションコストを減らし、システムに反映
- 全体間のあるゴール設定・透明性確保
限定合理性の発生する余地を減らし、情報の非対称性を削減
- 技術的負債の見える化
対応可能な課題にし、組織的な問題の発端に取り組めるようにする
ここで気が付かされたのは、事業部とエンジニアと組織を分断するのでなくチーム（プロダクトベースのため事業部もエンジニアも混在）の中で、不特定の人しか知らない情報をなくし、チームとして課題に取り組むことが重要であり、それはソースコードの技術的負債、アーキの技術的負債をエンジニアだけの問題とせずチームの問題として顕在化させる必要があることが必要だと認識しました。
■まとめ
チーム、組織が不確実性と正面から向き合えることができるようになったらエンジニアリング組織になるのだなと分かりました。道のりは険しいですが、不確実性を削減するためにエンジニアとして頑張ろうと思いました。
■参考
この記事が気に入ったらサポートをしてみませんか？