【読了】エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

はじめに

今回年末年始で、名著とも言われている エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング を読了したので、感想やら刺さった部分などを書いていこうと思います。
というか、書きながら読み進めていたので厳密には校正するくらいなんですが、、（中の言葉を借りてる部分も多いですが、一語一句合っているわけではないです）

学びたかったこと、明確にしたかったこと

それなりにエンジニアとして経験を積み勝手が分かった雰囲気（？）になって、プロジェクトである種のリードを担うような機会がありました。

その中で立ち振る舞いや、考え方、動き方など迷うことが多かったので、手元だけではなく本質というか、広い目で出来事を捉え挑んでいける自信と道筋が欲しかったのです。

読了後の感想

実は、これを読むのは２回目だったりします。
一年位前に買って半分くらいまでは読んでいたのですが、その時最後まで読みきれていませんでした。
そのとき、「これはタイミングによって刺さる部分や感じることが違いそうだな」と思っていて、その時は今回ほどスッと入ってくる時期ではなかった気がします。ですが、今回はそのタイミングだったと確信してました。

改めて、全体を通して

  • 自分の立場、頭を抱えているものによって刺さる部分が違う
  • 様々な受け取り方もできるので、別のタイミングで読み返せる
  • 「エンジニアリング」に何かしらの壁を感じたり頭が凝り固まってしまったとき、それを解いてくれる

本だなと感じました。
私はまだ理解が甘い部分もあるので、それぞれのセクションの数はてんこ盛りでしたが、一つ一つはより掘り下げられる項目かと思います。
その為、エンジニアリング組織論への招待 というタイトルは凄くしっくりきました。

副題にもある通り、Chapter１から最後まで、如何にあらゆる不確実性を解消、向き合っていくか、ということが述べられています。
実際に手を動かすことの多いエンジニア、リーダーとしてチームを先導するエンジニア、プロジェクトを統括するプロジェクトマネージャー、はたまたそのプロジェクトに参画しているデザイナー、どんな立場の人も読む価値があるなという印象です。

ただ、同時に１週目の私がそうだったように、その時の自分が見えているもの見えていないもの、エンジニアとしてのレベルなどによってこれが名著か否かが変わるかと思います。

私はおそらくタイミングとしてはドンピシャだったので得るものが多かったですが、気になる方は色々参考にして手に取ってみてください。

CHAPTER 1 思考のリファクタリング

情報を得る

エンジニアリングという行為は、何かを実現すること。実現のために不確実性の高い状態から不確実性の低い状態に効率よく移していく過程に行うすべてのこと。

エンジニアリングの本質が不確実性の削減であることに気づかずにいると確実でない要求仕様にフラストレーションを抱え、確実でない実現手段にストレスを感じ、確実なものを確実な手段で提供したいという決してあり得ない理想を思い描いてしまう。

自分のアイデンティティの範囲を知る

自分自身の範囲が狭い人は怒りを感じにくい、それを攻撃だと思わないから。

なかなか怒らない人は優しい人であるかもしれないと同時に、何にも関心がない人なのかもしれない。

問題解決より問題認知の方が難しい

難しいのは問題を正しく認知すること。人は無意識に自分が間違っているかもしれないことを無意識に避けてしまい、正しい情報を認知できない。

自分は間違ってるかもしれないが、それに早く気づく方がよい、と思考パターンを変える必要がある。

理性主義と経験主義

理性主義は、新しい知識は、人間の理性の中にあるとする考え方

アンドロイドになり感情が消えてしまったら、楽しいや悲しい出来事から新しいものが生み出されない世界になるのだろうか..?

経験主義は、ある問題をじっくり考えてみたものの答えが出ない。理性主義はその事実の後から、分からなかったのは頭が悪かったから、など自分のミスがなかったかを考え、もう一度同じことを繰り返して思考の袋小路に陥る。
経験主義的に言えば、分からなかった、あるいは正解ではなかったということが重大なヒントになり次の行動を生み出す。

何がわかればわかるのか、を考えそれを確かめることに変換することは、問題を一発で正解することよりも簡単。

不確実性とマネジメント

不確実性の高いもの先に取り組んだ方がいい、スケジュールの精度が上がってくる

Chapter2 メンタリングの技術

他者説得、自己説得

人から与えられた説得による知識を他者説得、自分自身で気がついたことを自己説得といい、メンタリングでは自己説得を重視しその獲得を施す。

他者説得

  • 他人が答えを伝える
  • 体感を伴わない
  • 理解を確認できない

持続せず、誤解を招く可能性がある

自己説得

  • 他人が質問で施す
  • 体感を伴う
  • 行動の変化が発生しやすい

周りの状況などから、自ら今までわからなかったことを理解した状況。

以前、ツールの操作方法を他の方に教えるという時があった。
やりたいこととしては文章をコピーし、新しいページを作成しそこに貼り付ける、と言ったものだったんですが、私は何も考えずに、ちょうどその時クリップボードにコピーを持っていたので、今貼り付けちゃいましょうか？と言いました。
時間もたくさんあった訳ではないですが、その方は暫く考えた後「いや、自分でやりたいっす」と言いました。
その時私は、そりゃそうだよなちょっと言い方間違えたかも、くらいでしたが、メンタリング的にいうと他者説得になっていたのかもしれない、というストーリーを思い出した。

悩んでいる、とは

  • 選択肢が不明瞭
  • 比較軸が不明瞭
  • 評価方法が不明瞭

ハマっている状態でもあるこれは、このどれかが十分でなく判断ができない状態。
何が不明瞭なのか、そしてそこを明確にして解決に導いていく冷静な分析が必要。

心理的安全性と責任

無関心ゾーン
問題に対して責任を感じず対人リスクも折れない状況
コンフォートゾーン
心理的安全性が高いが問題に向き合えていない、対人リスクを取ることができるが実際には取っていない、居心地はいいが成長がない
不安ゾーン
心理的安全性が低いのに問題な対して強い意識を持っている
ラーニングゾーン
対人リスクを適切に切り取り問題と自分達と言う構図が生まれている時

対人リスクを避ける周囲と同調する集団心理が同調圧力、空気による支配

そうですよね？〜さんもそう思いますよね？という言葉選びや、場に苛立ちを持ち込んでしまったり、という行為は同調圧力や空気による支配を誘う場合があるかもしれない。

「この人がいると自分が言っても何か言われてしまうかも」という状態は部下→上司、本人→本人より出来る人、という関係性などで生まれがち。
仕事なのだから気にせず行けという精神論は置いておき、こういう状態は議論が活発にならず純粋な意見も出てこない状態になりうるので、振る舞いには注意が必要。
ただ、これらは対人リスクを取って何でも言い合える関係性ができていない場合で、できている場合はその類でない。

アクノレッジメントとストーリーテリング

メンターは自分の弱さや失敗をメンティに共有する必要がある
ダメで失敗もしたが、そこからこういうことを学んでこんなふうにしたら成長できた、という物語にすると効果的
ただ、こうやったらいいよは経験や過程がわからないので実行しにくい

アクノレッジメントで必要なのは、結果でなく行動、行動だけでなく存在への承認が重要

疑問：
アクノレッジメントを実行するにあたり、これはメンターがメンティにというのがベースになっているため、自分よりできる立場の人へのレビューが難しい気がする。
アドバイスしようと思っても、この人なら自分より解決方法を実は知っているかもしれない、もっと広い視野で物事を見ているかもしれない、という懸念がある。

メンターとメンティの関係性によるが、一方がその事柄に優れているためレビューを行う、ではなくコミュニケーションとして切り離す必要性もありそう。

自己開示

ジョハリの窓

いかに開放の窓を広げてコミュニケーションの中で成長を施すか

他人は分かっているが自分には分かっていない部分を「自分は分かっている」状態に変化させるためには「フィードバック」が必要。

自分は分かっているが、他人は分かっていない秘密の窓を開放の窓にするには、自己開示が必要。

開放の窓が広がることで自分にも他人にも未知の窓が開かれている、これが成長をもたらす。
メンタリングではこれを目指していく。

しかしながら、フィードバックも自己開示も対人リスクを伴うので、メンターが先導し意識的に

  • ストーリーテリング
  • アクノレッジメント
  • 傾聴
  • リフレーミング

を行いフィードバックも自己開示もしやすい状態へ持っていく必要がある。
一種のコミュニケーション能力だと思う。

CHAPTER 3 アジャイルなチームの原理

アジャイルとは？：
経験主義の考え方、不確実性をなくしていく方法論。

（アジャイルに関しては別の文献で掘り下げた方がいい部分が多いので、ここではあまり引っ張りません）

クールエイドを飲むな

誰かの思想信条を無批判に受け入れるな、ということ

なんでも批判しろという訳ではない、言い方によっては相手を否定しそれを続けることで何を言って無駄と相手に思わせてしまうかもしれないので、メンタリング的な気遣いが必要。

役割をわけない

異なる目的意識が発生し、限定合理性を生み出す
アジャイルでは、役割を遂行するためにはどうしたらよいかではなく、チーム全体において、今自分は何をするべきか、を重視する

CHAPTER 4 学習するチームと不確実性マネジメント

見積もり

不安量の大きいタスク順に問題を解決する
ランダムにな順番でタスク消化をしていく場合と比較してみると、ランダムな場合は最後まで不安量が減らない。
タスクが依存関係にあったりすると制約スラックが生まれるので出来るものからというのも一理あるが、不安量の大きいタスクを解体し、どこで不安があるのか、何をすれば不安がなくなるのか、を見ることにより優先順位の自由度が増す。

  • 経験がないライブラリの利用
  • 外部との連携（APIetc
  • 仕様詳細が未決定
  • 影響範囲が読みきれない（私の場合はここがバッファを食っている）

その場合は、小さいタスクや別のストーリーに切り出して、不安部分を抜き出すことで制約スラックを減らし、不安解消への焦点を絞れる。
何が不安なのか、というファシリテーションを常に行なっていくことで不安を切り離すアイデアが生まれる。

計画ではなく、実績で見積もりを行うこと。

スケジュール不安とマーケット不安

以下の二つには対称性がある
時間境界型プロジェクト
クリスマスや企業イベントなどにある機能のリリースを合わせる。ずらすと効果がなくなってしまい、この時間境界を納期と呼ぶ。
機能境界型プロジェクト
パッケージが固まってリリースされないと仮説検証にならないプロジェクト。他にもあった方が良い機能は多数あるが、最低限この機能が存在しないことには価値検証ができない、このラインをMVP (minimum valueable product)という

プロジェクトと分かれているが全てのプロジェクトがそうでもない。二つを同時に行う場合もあるし、切り分けて判断するケースも出てくると思う。

リリースポイント

機能が完成していて、それを提供できる瞬間をリリースポイントという

DB、Domain、UIとレイヤを切って作業すると機能が分断されてリリースポイントが少なくなってしまう。
一方、機能ごとにレイヤを切って開発できればリリースポイントは機能ごとに作ることができる（変更に強い）。

価値と不確実性

機能の優先度を考えるときにはそれぞれの機能を価値の高低とリスクの工程のマトリクスに分類できる

高価値高リスクのものは検証すべき不確実性があることがわかる
一方で、高価値低リスクのものはやるべきだが、低リスクであればいつでもできるので一番の優先度ではない。

スクラムと不安に向き合う

不確実性を減らすためには一番不確実なことから確かめていくこと。

スクラムはいつどのようにチームが課題と不安に向き合うのかを規定して、改善を行うためのタイミングを矯正するためのフレームワーク。スケジュール不安やマーケット不安のマネジメントと組み合わせて、不安への向き合い方をチームが学習するための方法論。

振り返りの流れ

問題定義から始まる。

  1. ゴールの再認識
  2. テーマ設定　振り返りのスコープを決める。ファシリはスコープから外れた話題をコントロールする必要がある。
  3. 現場整理　テーマに沿って現状の事実を並べる。ファクトに基づかない印象論を排除するため、テーマにおける情報の整理をすることが重要
  4. 良かった探し　課題を出すまで出しあう。言いづらい部分でもあるので無理矢理にでもだし、会議の雰囲気を明るく活発にする
  5. 問題の洗い出し　出来る限り様々な観点で出し合う。この時点で問題ではないなどと発言してはいけない
  6. 問題の深掘り　重要と思われる問題に対して、なぜか、を繰り返して本当の原因を探す。原因がコントロール不可能なものに到達した場合、他責化の可能性があるので注意が必要
  7. 対策の決定　他人任せなものは対策ではなくて願望なので、チームで実現可能な対策に変換する

スクラムマスターはPMとは違う、チームマスタリーになるようにチームに入り込んだり、POを助けたり、メンバー一人一人をメンタリングしたりするのが役割。

CHAPTER 5 技術組織の力学とアーキテクチャ

組織の「情報処理能力」

権限が移譲されていない組織は具体的で細かい指示を必要とする。上司(マネジメントする立場)の情報処理能力がボトルネックになってしまう。情報処理能力が向上せず不確実性を少ししか削減できず、依存型マネジメント型の組織になってしまう。
対して、目標の共有や権限の委譲などを通じて抽象的な指示が機能する組織であれば裁量が拡大し、自己組織化された組織、になる。

技術的負債

一般的に、速さを求めて構築したシステムの構造的な課題が蓄積し、債務の如く徐々に開発速度を遅くしていく現象、と捉えられている。
重要なのは、返済の見込みのない借入をしないこと、無鉄砲、無意識のうちに借入をしてしまうとマネジメントに悪影響を及ぼす。

全ての負債が悪いわけではなく、現実的にそうしなければいけないケースも出てくる。これを選択し、レビューを受けさらにブラッシュアップしてマージしていく必要がある。

ただし完全な予知は不可能、都度要件は変わり負債でなかったものが負債になる可能性もある。なので その時に出来る限り良いコード書いておく というのが重要。

今必要な機能をシンプルに作る ことに帰結する(YAGNI原則)。

目標管理と透明性

目標による管理はピータードラッカーが提唱した概念、MBOとも呼ばれている。
目標は、

  • 目標設定による主体性向上
  • モチベーションアップ
  • 問題解決能力の向上

これらは内的動機付けを重視しており、self-controlを意味している。

OKR (Objectives and Key Results)

オブジェクティブとして目標を掲げ、その結果をどのような変化がある程度定量的に判断されるかをキーリザルトとして最大三つ程度明示する。

知識として覚えておきたかったくらいなので詳しくは記載しない。

透明性と情報公開

OKRのもう一つのポイントは透明性を重視すること。従業員一人一人が組織全体を見渡して自分がなんのために仕事をしているかを深く理解するというのがOKRの果たす重要な役割

組織の透明性とは、情報が整合性を持って組織内に正しく伝達されていること

マイクロサービス化を行う時期の難しさ

時期尚早だと開発速度を遅らせてしまう可能性もある。やるには プロダクトを支えるビジネス戦略が固まっていて、ある程度仮説検証が終了している必要がある。

なぜなら、立ち上がりきっていないと、大きな作り直しや方向転換を図る可能性が十分あるため。

マイクロサービス化をめぐるトレードオフ

ここを伸ばせばビジネスを拡大できるというビジネスドライバーが明確になっている必要がある、つまり仮説検証が終わり不確実性が少ない状態。

逆にその状態は組織の人分が増え、取引コストが増大している可能性がある。

マイクロサービス化でメリットを得ようとするには不確実性と取引コストが交差するであろう時期 (スイートスポット) にアーキテクチャの転換を行う必要がある。

まとめ：エンジニアリングカンパニー

企業活動は、市場に対する不確実性も複数人の組織のコミュニケーションの不確実性を相手としたエンジニアリング。

組織上の課題が我々の身に降りかかる時、それは組織上の課題ではなく、個人の問題の顔をしている。意図的、無意識的に個人の問題として我々は考えてしまう。構造上の問題は誰かのせいでないと同じくらい税員の責任でもある。

必要なのは妥協でもなく、政治でも、卓越した技術でもなく、組織やビジネス、プロセス、そしてシステムへのエンジニアリング。

まとめ（私の）

随所随所がてんこ盛りだったので、ある程度メモを取りながら進めていました。

凄く共感、納得、次にすぐ活かせる部分もあればまだ落とし込めていない部分も多いので、この辺はこれからも何度も読み返しに来ようと思っています。

個人的にはタイミングも、内容も、ベストタイミングだったので、今読めてよかったと思います。

求めているものや明確にしたいものにもよりますが、個人的にはおすすめできる本だと感じました。

書籍書籍, 読了記録

Posted by Sho