昨年話題になっていたこちらの本を読んでみました。
エンジニアリング組織論への招待 ?不確実性に向き合う思考と組織のリファクタリング
- 作者: 広木大地
- 出版社/メーカー: 技術評論社
- 発売日: 2018/02/22
- メディア: Kindle版
- この商品を含むブログを見る
内容としては、「エンジニアリングの本質とはなにか？」にといったふわふわした概念について論理立てて説明されている、非常に興味深い内容になっています。
読んでみて思うところがあったので、今回はそのメモです。
tl; dr
なんとなく、個人的な大事だと感じたことを列挙するとこんな感じです。
- エンジニアリングの本質は不確実性を排除し、具体性を付与する(情報を生み出す)こと
- 不確実性の根源は「他人」と「未来」で、これらをマネジメント・ハンドリングすることこそがエンジニアリング
- これらを組織では、メンバーが自立的に問題解決するように促すメンタリングが有効に機能する必要がある
- 不確実性に立ち向かう組織には"アジャイルである"ことが求められる
- アジャイルなチームであることで、不確実性を正しく把握し確実に削減していくことができる
- 組織全体で不確実性を削減していける状態を保つためには、組織構造にも気を配る必要がある
思考のリファクタリング
この本では、エンジニアリングの本質は「曖昧さ」を減らし、「具体性・明確さ」を増やす行為だとしています。
言われてみればそのとおりですね。ソフトウェアを作ることも、要件を固めることも、組織を組み立てることも、全てエンジニアリングの一部だと思います。 エンジニアリングが対象となる問題は、大体が答えの無い問題です。 つまり、不確実性満載で、どこから手をつけていいかもわからないことがほとんどです。 こういった問題に対して、具体性を与え、最終的に問題を解決することがエンジニアリングの本質なのだと思います。
曖昧さ、不確実性の根源は、「未来」と「他人」です。 この不確実性を下げるために、エンジニアリングと名のつくあらゆる行為は行われます。 よく、不確実性のコーンとかを使って、プロジェクトが進むに連れてだんだん不確実性が下がっていくと言われたりしますね。
不確実性を下げるためのポイントとして3つ紹介されています。
- 論理的思考の盲点
- 事実と意見の切り分けをはっきりさせることが、問題を把握するために重要なこと
- 経験主義と仮設思考
- いくら考えてもわからないことはたくさんあり、筋の良い仮説に基づいて試行することで不確実性を削っていく
- システム思考
- トップダウン型思考では物事の関係性すべてを把握することは難しいので、システム全他を俯瞰的に観察することが大事
なんとなくこんな感じでしょうか。個人の理解なので、間違ってたらごめんなさい。本ちゃんと読んでください。
これらをフル活用して不確実性に立ち向かうことが有効だとしています。 …頭ではわかっているものの、なかなかうまくできないんですよね。
メンタリングの技術
メンタリングってなんだっけ？
本書の定義によれば、こんな感じらしいです。
対話を通じて、メンタリングする人の思考力を一時的に貸し出し、思考の幅を広げていくことで、その人の歪んだ認知を補正し、次の行動を促し、成長させていく手法です。
ほほう…難しいですな…
個人的な理解としては、こんな感じだと思ってます。
- 理想の姿：メンティーが問題解決（不確実性の削減）を独力で行える状態
- メンターの仕事：問題に対する答えではなく、問題を解く考え方やその障害物を取り除くこと
なので、メンターがメンタリングとして行うことは、
- 問題の傾聴と整理
- コントロール可能な事象と方針の共感
かなと思います。
メンタリングってどうやってやるか
あるべき姿とお仕事の方針が分かったところで、具体的な手法について、たぶんこんな感じですかね。
傾聴
メンタリングは、メンティーの問題を解決するためではなく、メンティーの抱える問題を明確にするために実施します。 なので、メンタリングでは自分の意見を言うのではなく、メンティーの不安材料を一つ一つ明確にして、次に何をすべきかを自分で気づかせることが必要です。
これが、聞くこととメンタリングすることの違いです。 メンターの正論を振りかざすのではなく、メンティーの感情が深く入り込んだ問題把握を、客観的見るように仕向けることが必要です。
気をつけないといけないことは、「人の言葉には感情が乗っかっている」ということです。 事実を客観的に語ることはなく、少なからず主観によって脚色されていきます。 それを適切に切り分けて、具体的かつ客観的に捉えさせることが必要になります。
SMART
あとは、メンティーへのフィードバックとして、内面に対するフィードバックではなく、行動や習慣に対するフィードバックをするとが大事らしいです。
能力や結果は、本人が必ずしもコントロールできない部分なので、そこではなく行動や習慣など、本人の力でどうにかなる範囲に対してフィードバックすることで、建設的なメンタリングになっていくはずです。 また、このときの考え方にSMARTと呼ばれるものがあります。
- Specific：具体的な
- Measurable：測定できる
- Achievable：到達可能な
- Related：当人に関連した
- Time-Bound：時間制限のある
これらが満たされるように仕向けるフィードバックを行うことが重要になります。 こうしていくことで、より具体的な行動をメンティーに想起させることが可能になります。 そうすれば、自ずと自発的に動くようになっていくことが期待されます。
アジャイルなチームの原理
アジャイル開発が必要とされた理由
アジャイル開発が必要とされた理由は大きく２つで、
- ソフトウェアの大規模化・複雑化に対応する
- マーケットの不確実性に対応する
ためです。 どちらも、不確実性に対応するためと言い換えることができそうです。
マネジメントってなんだっけ？
マネジメントとは、対象となる○○の資源・資産、リスクを管理し、効果を最大化する方法
です。それ以上でもそれ以下でもありません。
Be Agile
アジャイルの文脈で、たまに"Be Agile"とかいう言葉が使われたりします。 アジャイルのお作法に乗っ取るだけでなく、アジャイルの考えを体現しろってことなんでしょう。
メンタリングが適切に機能し、チームとしてゴールに対して高いゴール認識を持った「自己組織化されたチーム」である状態になることが、アジャイル開発の本質のようです。
SECIモデルとダブルループ学習
言葉だけメモっときます。 そのうちアジャイルについてちゃんと勉強すると思うので、そのタイミングでこの辺は復習したいと思います。
SECIモデルは組織の成長には、形式知と暗黙知のループが必要と考えるモデル、ダブルループは行動と結果の反復学習から前提を疑う外側のループを含めた学習モデルのようです。
アジャイルに関する主な誤解
歴史的な話はおいてちょっと気になった部分を挙げておきます。
| 誤解 | 典型的ダメ発言 |
|---|---|
| アジャイルは決まったプロセスである | ウォータフォールかアジャイルか使い分ける必要がある |
| アジャイル開発では設計をしない | アジャイルは反対。設計しないとダメだ。 |
| アジャイル開発では優秀なメンバーが必要 | うちのメンバーは優秀じゃないのでアジャイルはできない |
| アジャイル開発では中長期計画がない | アジャイルだから計画しなくていいんでしょ？ |
| アジャイル開発には開発者に決定権がある手法だ | アジャイルにすると開発者が好き放題開発するんでしょ？ |
よく聞くフレーズが並んでいたので、今度何かで使うことにします。笑
学習するチームと不確実性マネジメント
基本的なアジャイルの進め方はこの辺で一応書いています。
いかにして不確実性を削減するか
Do Agile ではなく、Be Agileの観点でアジャイルの進め方を見直してみます。
不確実性ざっくり3分割
こんな感じに3つに大別されます。
- 方法不確実性：スケジュールと見積もり
- 目的不確実性：要求
- 通信不確実性：コミュニケーション
何度も出てきますが、 エンジニアリングは「曖昧さ」を減らし、「具体性・明確さ」を増やす行為です。
上の不確実性をすべて継続的に削減していくことが、エンジニアリングの本質となります。
方法不確実性
この不確実性を一言で表現すれば、いつ終わるかわからない不安です。 その原因は、システムに使用する技術に関する理解の浅さだったり、コミュニケーションうまくいかないことであったり、様々です。 いつ終わるかわかりませんが、それでもスケジュール・見積もりは建てなければなりません。
この不確実性を解消していくには、スケジュールとその不確実性を可視化していくことです。 詳しいやり方は本書に譲りますが、こんなものが紹介されていました。
- CCPMアプローチ
- 多点見積もり
- 相対見積もり（Tシャツ、プランニングポーカー）
どれも、スケジュールの不確実性をなるべく考慮して、プロジェクトが不確実なものだという考えに基づいているように感じます。 そして、スケジュールをノルマではなく、見積もりと考え直す必要性があるように感じます。 不確実性が経験主義的に削減されていって、それでも納期に間に合わないという状況であれば、それに対応するためのアクションを打てばいいだけなんです。
目的不確実性
目的不確実性は、作っているもの、やっていることが本当にあっているかという不安です。 これに立ち向かうには、すばやくリリースを行い、テンポよくフィードバックをもらい、方向性を修正し続けることです。
本の中ではユーザーストーリーが紹介されていますが、機能単位で小さく作っていきます。 ときに非効率な作り方に見えるかもしれません。 開発の効率よりも、目的不確実性に立ち向かう手段だと考えれば、納得してやれるはずです。
一つ面白かったのは、リーンキャンバスです。 普段からプロダクトの価値を語るときにはエレベーターピッチを作れと言われていますが、その他にもリーンキャンバスというフレームワークがあるのですね。 勉強になります。
これはなんかサマになるので、今後意識して作ってみたいと思います。
通信不確実性
この手の話をしていると、だいたいレトロスペクティブの話になります。 でもレトロスペクティブって難しいです
と、そんなことを考えていたところに、ありました段取り！！
- ゴールの再確認：インセプションデッキでゴールを確認
- テーマの設定：議論のテーマを設定
- 現状整理：今どうなっているか、事実を並べる
- 良かった探し：無理やり良かったことを言い合う
- 問題の洗い出し：問題と思われる点を言い合う。なるべくさまざまな観点で
- 問題の深掘り：重要な問題について、原因を探る。コントロールできる原因であるかどうかに注意が必要
- 対策の決定：実行可能な対策を決定。必ず全員で実行できることがポイント
やっぱりインセプションデッキって大事なんですね。 わからないことは不安です。だから、わかるように状況を整理して、どうしたら解決できるのかに目を向けることができるように、振り返りを行っていきます。
技術組織の力学とアーキテクチャ
さて、この本で一番気になっていた技術組織に関する話です。
組織が健全かどうかは生産性で語られることが多いです。 一般的には生産性は、投下した労働に対する収益ですが、エンジニアの組織ではガルブレイスの情報処理モデルである程度説明することができます。
そして、不確実性は下記のように当てはめることができるかもしれません。
このモデルで考えると、方法・通信不確実性が組織の情報処理能力を低下させる要因になっており、これはコミュニケーションコストとみることができます。
つまり、（少なくともこのモデルでは）コミュニケーションコストがエンジニア組織の生産性を低下させる要因ということです。
実際には、コミュニケーションだけが原因ではないとは思いますが、生産性改善していく具体策としては大体こんな感じです。
| 対策 | 内容 |
|---|---|
| 権限の委譲と期待値調整 | コミュニケーションの必要性の削減 |
| 適切な組織・コミュニケーション・外部リソースの調達 | コミュニケーションコストの削減 |
| 全体感のあるゴール設定・透明性確保 | 情報の非対称性の削減 |
| 技術的負債の見える化 | 組織として生産性の阻害要因を見える化 |
面白いですね。エンジニアとしては、そもそも無駄なコミュニケーションはしたくないので、なるべくコミュニケーションを減らす方向に考えているところは、納得です。
権限移譲に関しては、飴と鞭、義務と権利、で権利の明文化と報告責任の付帯が重要です。 ルールのない自由なんて、お互い怖くてなんもできないですよ。
その他、組織内の情報の見える化は大事ですねって話です。 まあ、いらないコミュニケーションは、こっちからオープンにふるまうことで解決していきましょ。
技術的負債にについては、これはなかなか根が深い問題で、一般的にはなかなか理解されない問題です。 技術的負債を見えるようにすることが第一歩、その先に負債による開発速度の低下を定量評価することしか進む道はないのかなと、個人的には思っています。だって、説明できないっすもん。。。
その他、マイクロサービスとかはそのうちちゃんと勉強するんで、そこで改めて具体的に見ていきたいと思います。
感想
おそらく、現代の多くのビジネスマンが抱える不安の根源とその対策について、エンジニアリングという切り口で解説した本です。 世の中の仕事の大半はよくわからない不確実なものの塊です。 その不確実性を削減して問題解決まで持っていくにはどうすればよいか、そのための組織はどうあるべきか、といったことが細かく書かれていた印象です。 論理は難しいですが、納得感もあり、非常に共感する内容になっていました。
エンジニアリングと言う切り口で組織づくり、マネジメントは確立した答えがない分、どこの組織でも苦手な人が多い印象です。 （あるいは当事者はできてるつもりで、現場からは悲鳴が上がっているかも?）
アジャイルという文脈では、正しいアジャイルの考え方を理解した上で、アジャイルを実践していくことは、開発だけでなく組織の成長に繋がります。 マネジメントを行う立場の方は、騙されたと思ってぜひ本書を読んでほしいです。
組織の中で各役職でどうふるまうべきかについては、こちらの本も是非ご参考ください。
