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

作者: 広木大地
出版社/メーカー: 技術評論社
発売日: 2018/02/22
メディア: 単行本（ソフトカバー）
この商品を含むブログ (2件) を見る

パンチライン？

「エンジニアリング組織論への招待」に関しては、以前読書メモを書きました。この本、論旨が素晴らしいのはもちろんなのですが、読んでいて「楽しい」んですよね。

私がなぜ楽しく感じたかというとこですが、要所要所にパンチラインが出てきて「え？なにこれスゴイ」と引き込まれたからだと思っています。

パンチラインとは、HIPHOP用語では「印象的な部分」とか「決め台詞」みたいな意味です。

えてして現実って複雑で面倒くさくて理解不要なものなで、私のような子羊は基本的にさ迷ってまるじゃないですかw

この本、マネジメント界にたくさん存在する複雑な概念を、シンプルに一言で表現してくれるんですよね。私は、しばしば登場するこの「ひとこと」にいちいち感心し、心の中で勝手に「パンチライン来た！」と思ってました。

なので、私がこの本の論旨を理解しようとするなら、パンチラインをまとめてみるのがよさそうと思い、やってみることにしました。*1

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

誰かの曖昧な要求からスタートし、それが具体的で明確な何かに変わっていく過程が実現で、その過程のすべてがエンジニアリングという行為です。

もっともなので、迷ったら「自分は何かを具体化できているか」を問うようにするとよさそう。

人間にとって、本質的に「わからないこと」はたった2つしかありません。それは、「未来」と「他人」です。

要は、マネジメントの対象は「未来」と「他人」だとわかります。

あまりに鮮やかなフレーズなので、あの名作パンチライン「3つの袋」に替わり、結婚式でのスピーチでの定番になることを密かに願っています。

論理的に考えるには、「非論理的に考えてしまう」瞬間を知ることが重要です。

私は非常にしばしば、論理性よりも自分の承認欲求を満たす行動に走ります*2。なので上記のように言われると耳が痛いですね。

お互いの情報伝達が不完全で、それゆえに引き起こされた問題であっても、何か害意や悪意をその中に見出してしまいがちなのが人間の性です。

国際紛争も社内の謎なゴタゴタも、思い当たる節があります。

「透明性」とは、つまり、継続したコミュニケーションや仕組みを通じて、コミュニケーションの不確実性を低く維持し、情報の非対称性が削減され、限定合理性の働きを弱められている状態のことをいうのです。

本書で繰り返し語られる「不確実性を下げることが大事」は、「透明性」という言葉もより具体的に説明しまえるところがスゴイ。「透明」という言葉からすると「見えている」という印象だけが先行しますが、「お互いに話が通じる」ということが大事であることがわかります。

Chapter 2　メンタリングの技術

すべてのその人の問題は当人しか解決できないので、解決策を言うこと自体が、相手への敬意を欠いた行為とも言えます。

...

「問題を解決してあげよう」という意識ではなく、「モヤモヤしていない問題に変換してあげよう」と考えることが重要です。

最近以下の本を楽しく読んで、これに関してはまた別途まとめたい感じがしています。

([い]6-1)アドバイスかと思ったら呪いだった。 (ポプラ文庫)

作者: 犬山紙子
出版社/メーカー: ポプラ社
発売日: 2018/06/05
メディア: 文庫
この商品を含むブログを見る

「いいアドバイスをする」というのは、無理ゲーなことがしばしばあります。

「誰が悪いか」という問題解決にとって「どうでもいいこと」にこだわるのは、自分でない誰かに責任を求めて思考停止することで、自分自身をコンフォートゾーンの中で安心させるための防衛装置が働いているからです。

本書のパンチラインの秀逸なところは、このように「私の弱さ」をえぐってくるところですw 私も心地よい場所だけにいたいんですよ、本当は。

「自分の弱さやミス、相手との意見の違いや直したほうがよいところを、率直に飾らずに話せるかどうかというのが、「心理的安全性」という概念の重要な視点です。

これは別の文書を読んだ時にも感じました。↓

ここで「安心」と「信頼」が出てきてるけど、Googleのいう「心理的安全性」は後者のような気がする。ただただアットホームなチームに「信頼」関係があるとは考えにくいですね https://t.co/LHhM3l0go8
— k.nakahashi (@k_nakahashi) 2018年11月12日

必要なのは、結果ではなく行動、行動だけでなく存在への承認です。

へーしゃでは現在「インストラクター」を設置していますが、基本的にこのためだけのものです。意外（？）とよくできてるなぁと...w

「わかる」の定義を「具体的な行動を行うことができる」に変換してしまえば、その行動を通じて、「わかった」状態を確認できますし、「わからない」ポイントもより明確になるでしょう。

これはChapter 1で出てきた「具体的にすることがエンジニアリング」というパンチラインと呼応していて面白いです。

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

アジャイル開発は従来型の開発に比べて、平均して3倍の成功率と1/3の失敗率という統計が出ています。

大規模開発ほどアジャイル開発が効果的であるという調査結果や一部ヨーロッパ諸国ではアジャイル開発が政府からの受注の前提になっていることなども紹介していて、基本的にこの流れは不可避化だと思います。

プロジェクトにとって最大のリスクは、「終了しないこと」

...

プロダクトにとっての最大のリスクは、「終了してしまうこと」

これも固い韻を踏んでてまさにパンチラインって感じですがw、非常に重要なことを言っています。

プロダクト内にプロジェクトが生まれることも普通で、この場合はPMBOKのようなプロジェクトマネージメント的な管理手法も大事になってくると思います。

「何を作るかを考える人」は、目的不確実性の削減に対してアプローチをしたいと考えていて、「どのように作るかを考える人」は方法不確実性の削減に対してアプローチしたいと考えています。

これも現場レベルで重要で、優秀な人同士の議論で「話が食い違ってしまう」パターンのよくある例かと思います。

「人はその人のアイデンティティの一部となっていることについて実りある議論はできない」

これは他のエッセイからの引用ということですが、納得感もありつつ、難しさも感じます。

マネジメントレベルで何かを変えようとするとき、今まで一生懸命だった誰かのアイデンティティを踏みにじる可能性は思ったより高い印象があります。

アジャイルな方法論で重要なことは、役割で関係性を縛らないことにあります。

自分が「役割を遂行するにはどうしたらよいか」ではなく、チーム全体の目的において、「今自分は何をすべきか」という問いをメンバーが常にもつことになるからです。

...

また、役割を分けない、決めないということは、ある専門性を持ったメンバーがいたとしても、必要に応じて、別の専門領域の事柄も手伝っていくように変化させていきます。

たまに私も、なんらかの施策によって自分の「役割」がなくなってしまうと怯えることがあります。そういうときこそ、「何をすべきか」を問うべきなのでしょうね。。。

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

「わからないもの」に立ち向かうことが人間にとって困難なことだからです。不安の量を「見える化」していくことで、早期にリスクを顕在化することができます。

Web開発初心者あるあるで、「ビジネスロジックより先にViewを作りがち」ということあると思うのですが、こういうことが理由な気がしますね*3。

スケジュールマネジメントを行うのであれば、要求が詳細化していく過程そのものをマネジメントしていかなければなりません。

これホントにその通りで、ウォーターフローの悪習として語られる「基本設計」「詳細設計」とかのあれですが、スケジュールマネジメントの上では詳細化のフォーマットがあるのってありだと思うんですよね。

多くの経営者が「納期」というものを決めて、プロジェクトを管理させるのは、その日にリリースされるという絶対の情報を欲しがってしまうからです。

こうして「納期」におびえて愚痴りながら仕事をする現場のエンジニアが誕生するのですが、やはりお互いにコミュニケーションをとるべきなのでしょう。たとえばスクラムなどは、そういったコミュニケーションをとるためのイベントを色々組み入れていますよね*4。

スクラムはいつどのようにチームが課題と不安に向き合うのかを規定して、改善を行うためのタイミングを矯正するためのフレームワークであることがわかります。

「スクラムとは何なのか」について、スクラムガイドよりもわかりやすく描写してくれています。

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

エンジニア組織は、組織の下流工程に位置しやすい

↑ 章のタイトルですが1行で泣けますね、これ😭

続いて ↓

開発部門は、組織のアウトプットとしての「システム」を構築する部門であるため、この多重に積み重なったエージェンシースラックの不合理が発露される場所になりやすいという性質を持っています。また、恐ろしいことにそのような関係性をもって生み出された「システムそのもの」に、組織の不合理が蓄積されるという現象が起きてしまうのです。

これらの何が泣けるって、結局手を動かしている私たちのモチベーションを維持できなくなってくるとこかと思います。

「やらされて」いる上にクソコードができあがっていくという。。。

権限を明示することは、「縛ること」であって、明示しないからこそ自由であるとする発想をすると、多くの場合問題が生じます。

...

権限が明示的でないことが意味しているのは、上司の胸先三寸で権限について差配できるということです。

上司がそんなつもりなくても、そうなってしまうかもしれません。「明示的にする」のって意外と大変であるという現実が、この状況を加速させる気がしますね。

ある単体の組織の効率性を測るときに、「より少なく抽象的な指示」であっても成果を残すことができるのかを考えると、組織の成長をとらえることができるということです。

本の冒頭の「エンジニアリング≒具体化」とリンクしてくる話です。

ついでにいうと、これは組織ではなく個人でも同じですねぇ。成長してない個人はマイクロマネジメントになりがちになってしまう (>_<

「技術的負債」というキーワードで問うべきは、エンジニアチームと経営者の間に存在する認識の差

これはかなり大胆な提起ですが、そのくらい両者の認識の差は大きいので心してコミュニケーションとるべし、とも思います。これに関しては、筆者の広木さんの以下のツイートも補助線ですね。

学習コストや技術的負債という言葉は、「慣れるまで時間がかかる」という事実や「ある改修に時間がかかる既存コードだ」という事実だけを表現していると思うと議論が噛み合わない。

それらの言葉によって何の価値判断をするか、したかが会計用語を使うことに含意されている。
— 広木大地/ エンジニアリング組織論への招待 (@hiroki_daichi) 2018年11月21日

↓はもっと怖い。

エンジニアカルチャーの一部にアナーキーな部分がある。中二的な皮肉や露悪的な話し方をカッコいいと思うファッション。なので、テキストコミュニケーションで書いてきた人がいるのに「クソコード」とか「技術的負債」とか言っちゃって、ヘイトを集めていざ改善するときに協力を得られないとかよくみる
— 広木大地/ エンジニアリング組織論への招待 (@hiroki_daichi) 2018年9月24日

これ、「技術的負債」って実はエンジニア組織そのものなのではww😱 「POがリファクタの必要性をわかってくれない」とか言ってるの、自分たちのせいなわけです。