エンジニアリング組織論への招待を読んだ。

エンジニアリング組織論への招待を読んだので、学びをまとめておこうと思います。

概要

前回の記事に引き続き、エンジニアという立場から見た、マネージングや組織論というところで基礎を作るためにまずはがむしゃらなインプットをしようということで相談したところ、当書を紹介していただいたので読み始めたのがスタートでした。

300ページもの本でボリュームもあり読み応えがある本でした。
今回は、全くの無知という訳ではなく、前回の本であるエンジニアリングマネージャーのしごとを読んでいた事もあり、多少被る知識の部分があったということで、読みやすい部分もあれば、アジャイル開発、スクラムなど体制の話も盛り込まれていた事もあり、少し調べながら読む必要がある部分もあったので、良い負荷がかかったインプットができたと思います。

1回読んだだけでは噛み砕けていない部分もあるので、期間を空けてもう1回軽く通しで読んでみるなどをしてみようかと思います。

当書を通して得る概念

エンジニアリングとは、「不確実性を解消すること」です。

不確実性というのは、抽象度の高い事柄であり、人が不安に感じる根源のこと。
不安に感じる要因としては、未知のものに対して無意識にでも恐怖を感じるという人間の本能からきており、「避けたいもの」という認識が働く事柄。

この不確実性が高い状態のことをエントロピーが高い状態と言います。
逆に少しでも不確実性が低くなると、エントロピーが低い状態に近づくという感じです。

このエントロピーを下げていく工程をエンジニアリングと言い、そのための手法が全体を通していろんな観点から、いろんな手法が書かれています。

構成

1~4章では、5章に向かって下地を固めていくという構成になっています。

1章では、全ての前提の知識となる事柄に触れ
2章で相手との対話について触れ
3章ではチームでの取り組みについての手法や歴史について触れ
4章ではその手法を使ってチームへの作用の解説
という構成になっています。

5章で組織という大きな枠組みの中でどのような問題が存在していて、どのように不確実性の解消をしていくのかを紹介しています。

用語ピックアップ

経験主義と仮説主義

不確実性という問題を解決をするためには、思考のリファクタリングが必要です。
その手法として以下のものがあります。

経験主義

情報を得るために、行動を起こしてその結果から問題解決に向かう手法

仮説主義

問題に対して、少ない情報から全体像を想定し、その像を確認するで問題解決に向かう手法

４つのイドラ

認知の歪み

ネガティブな感情により生まれる思考
以下のような、個々人の持つ印象や感情による歪曲された認知

ゼロイチ思考

「常に」「全部」「決して」といった断定的な思い込み
中間にあるグラデーションを認識できない思考

一般化

小さい事例をあたかも全体の事例のように認識し
一般化させてしまうことにより、大きな問題へと発展させてしまう思考

これはレッテル貼りへ発展し、一般化させた結果
当てはまる人はこうであるに違いないといった決めつけが発生する。
こういったところから認知の歪みが発生する。

すべき思考

Should構文で考えてしまう思考。
〜すべき、〜であるべき などの固定観念から自分自身を追い詰めてしまう思考。

選択的注目

朝の占いなどで、ラッキーカラーを知った時にその色のものがよく目に入る現象のネガティブバージョン。
人に対して、一度ネガティブな印象を持つと、その人が何をしてもネガティブに捉えてしまうという認識。

結論の飛躍

例えば、既読スルーするつもりがなかった相手に対して、
ネガティブな思い込みをすることによって発生する認知の歪み。

環境不確実性

行動と観察に生じる不確実性の種類
「未来」という不確実性からくる不安が生まれる。
未来が近づき、現実に近づくにつれて確実なものへと変化していく。

通信不確実性

コミュニケーションに生じる不確実性の種類
「他人」という、自分がコントロールできないものに対する不確実性。
自分が伝えたことを１００％認識してもらう事は不可能であると同時に、
どれくらいの理解度なのかを押し測る事も不可能であることから不安が生じる。

不安への対処法

不確実なところから、不安な事柄へと発展します。
そして人には、不安なものへの恐怖がありそれを避ける傾向があります。
これをタスクベースで落とし込むと、不確実性の高いタスクに対して恐怖を感じることになります。
結果として、確実性の高いタスクを優先的に行おうとしてしまう傾向が現れます。
これによって不確実性なタスクが最後に残り、スケジュールギリギリになって不確実なものが残り、見積りとズレてしまうという事象が発生してしまいます。

この現象を回避するために、不確実性の高いタスクを優先的に行うことでエントロピーを高めることで不安を解消するようにするのが良いです。

アジャイル

ここで、アジャイルとウォーターフォールの話が出てきます。
ソフトウェアの開発ではよくウォーターフォール開発があげられますが、アジャイル開発での成功確率の方が高いそうです。

プロジェクト初期に関しては、まだエントロピーがかなり高い状態で始まります。
その状態でプロジェクトを最後まで構想し作り始め、最後の最後に結局顧客のニーズと異なるものができてしまったという事例が多くなってしまうのがウォーターフォールでの開発。

対して、アジャイルであれば、マーケットフィットを模索しながらになるため、小まめの調整を行う事が多いことから、大きく失敗するということをなくし、コストを最小限に抑えることができるという点でアジャイルの方が成功率が高いということになります。

プロジェクトマネジメントとプロダクトマネジメント

まず、マネジメントの言葉の定義として
対象となるものの資源・資産・リスクを管理し、効果を最大化する
とあります。

プロジェクトマネジメントに当てはめると
「対象となるプロジェクトの資源・資産・リスクを管理し、効果を最大化する」
プロダクトマネジメントだと
「対象となるプロダクトの資源・資産・リスクを管理し、効果を最大化する」
となります。

プロジェクトは、はじめと終わりがあり、終わりに向けて取り組むのに対し
プロダクトは、はじめはあれど終わらないようにすることが目的となってきます。
その点で、不安となる要素が変わってきます。

ウォーターフォールかアジャイルか

上記によって、ウォーターフォールが悪というような形になってしまっていましたがそういう訳ではないです。
どちらが良いというにはまず、この二つを比べるために、この二つが同等の性質のものとして捉える必要があります。
そうすると、この二つの不安要素である不確実性のスコープを見比べる必要があります。

ウォーターフォールで生み出される不確実性

• 方法不確実性
• 目的不確実性
  アジャイルなチームで生み出される不確実性
• 方法不確実性
• 通信不確実性
• 目的不確実性

上記の通り、アジャイルが持つ不確実性は、ウォーターフォールが持つ不確実性のスコープを包含しています。
それぞれが不確実性の解消の目的が異なるため（プロジェクトとプロダクト）、比べられるものではないのです。
具体的に落とし込むと、「何を作るか考える人」と「どう作るか考える人」との対立が発生してしまうのです。
それによって引き起こされる認知の歪みにより、通信不確実が方法不確実へ発展してしまうことがありえます。

組織化

セルフマスタリー

まず、チームとして理想の形態というのは各々が「セルフマスタリー」状態になることです。
つまり、自分で目標に向かって行動できているという確信が持てていることになります。
未来の自分が今の自分をメンタリングしているような状態になることが良い状態になります。
将来の目標がハッキリしていて、すでに道筋が見えていて、そこに向かって行動している状態ですね。

SECIモデル

Socialization（共同化）
Externalization(表出化)
Combination(連結化)
Internalization(内面化)
の構成から成るモデル。

問題意識への暗黙知から形式知への浸透が広まっていくモデル。
明文化されていない知識を「暗黙知」といいます。
逆に明文化されている知識を「形式知」といいます。
この暗黙知と広めていくことが組織の発展に繋がります。

例えば、自分達が見落としがちな問題に対して、
見落とさないようなルールを作って実践していく中で、メンバーの中での暗黙のルールとなる。
そうしているうちにルールにしなくとも、組織内で同じ問題に対する対応の意識というのが浸透することで、
また新たな問題へ目を向けられるようになるといった好循環を作る事ができるのである。

自分のチームでもこれは実践していて、定期的にエラー通知の結果をチーム全員で確認し、対応をどうするかと言った話し合いをし形骸化しがちな問題に対して意識を向けるという流れができて、組織全体へと広まっていくというような循環を作っていっています。

しかし、これには時間もかかるし、根気のいることなので実施するにはそれなりの覚悟が必要なので
効果が出るまで粘り強く広めていく必要がありそうです。

技術負債

技術的負債がないプロダクトは存在しないと言われるほど、プロダクト開発にはつきもので
これに対処するには、経営層と非経営層とでの情報の非対称性が存在する。

これについても、負債についての可視化と、工数やコストといった観点で不確実性を解消する必要がある。
可視化については、ソースコードの複雑性の証明（if分岐の数など）、コードの依存関係の証明、バージョン管理などによる誰がいつどこを触ったかなどの証跡などの証明によって可視化する事で経営層への認識を伝えることへの助けになります。

さらに、お互いの認識を共通のものにするために「ユビキタス言語」を作成したり、経営層がどういう戦略を考えているかの透明化をすることで、それをアーキテクチャに当てはめるという逆コンウェイ作戦といった手法を取る事を検討できます。

また、ビジネスフェーズに合わせて、アーキテクチャの再設計（モノシリックからAPI化であったり、マイクロサービス化といった）を行うことで、いかにしてコストを減らすための技術負債を少なくするかといった戦略を考えていくこともできます。

まとめ

当書を通して、かなり自分の中で組織やマネジメントという面の知識の糧になったと思います。
他にも

• アジャイルの誤解
• アジャイルが経営学に取り込まれていた時の歴史
• スクラムによるタスク管理と計測
• 認知の歪み、通信不確実性に対する対処法
  などなど、非常に参考になる事柄が多く書かれており、また他の本を読んで知識や実践を通した上で、もう一度読みたい本だと思いました。

今、恐らく組織論という不確実性を抱えている自分のような人がターゲットになっているような本だと思うので、同じような境遇な人は是非一度手に取ってみて欲しいです。