「エンジニアリング組織論への招待」はエンジニアだけをターゲットとした、いわゆる技術書ではありません。
本書はエンジニアが、経営者が、エンジニアリングを行う「組織」に対して向き合うための考え方をテーマに書かれています。
具体的には次のようなことです。
- 新人エンジニアのメンターになった先輩はどのようにメンタリングを行えばいいのか？
- ソフトウェアの開発スピードが時間が経つにつれ遅くなるのはなぜか？
このエントリでは「エンジニアリング組織論への招待」の内容をまとめます。
エンジニアリングとは何でしょうか？
エンジニアリングとは、曖昧なアイデア、曖昧な指示を明確な仕様に落とし込むといったように、「曖昧さ」を減らし「具体性・明確さ」を増やす行為です。
エンジニアリングを行う組織は、市場や顧客などあらゆる不確実なものに対し、不確実なものを確実なものに変化させる「処理装置」と見ることができます。
ここに同じ成果が得られる2つの組織があるとします。
一方は「具体的で細かい指示」が必要な組織です。
もう一方は「抽象的で自由度のある指示」で対応できる組織です。
これら2つの組織を比べてみましょう。
具体的で細かい指示が必要な組織は、抽象的で自由度のある指示で対応できる組織に比べて次のような短所があります。
- 指示を出す人の能力に依存する
- スケールしない
- 不確実性の削減量が小さい
具体的で細かい指示が必要な組織のことを「マイクロマネジメント型」組織と呼びます。
一方、抽象的で自由度のある指示で対応できる組織は「自己組織化された」組織と呼びます。
私たちはしばしばコントロールできないものをコントロールしようとしてストレスを感じてしまいます。
「上司が自分の仕事を評価してくれない」というのを例に、何がコントロールできて、何がコントロールできないのかを考えます。
上司が自分の仕事を評価してくれないとき、コントロールできないものは次のような「他人の内心」です。
- 上司の自分に対する内心での評価
- 上司の評価基準
一方、コントロールできるものは、次のような「自分の行動」です。
- 上司の評価基準を詳しく聞くという行動
- 上司の評価基準に合わせた自身の行動の変化
- 上司を変えるための異動などの行動
- 自分の仕事を上司に詳しく説明するという行動
- 自分自身の思いを上司に知ってもらうための行動
コントロールできるものは、変化を観測できるものであるとも言えます。
自分の行動をコントロールし、変化を観測してまた自分の行動を修正する。
コントロールできないもので悩むのではなく、コントロールできるものに目を向けなければなりません。
メンタリングとは何でしょうか？
本書では具体的に次にように説明されています。
メンタリングは、知識のある人はない人に対して、上から押し付けるような教育方法ではありません。対話を通じて、メンタリングする人の思考力を一時的に貸し出し、思考の幅を広げていくことで、その人の歪んだ認知を補正し、次の行動を促し、成長させていく手法です。
個人の成長を階段に例えると、メンタリングにおいてメンターはメンティに次のようなことをする必要があります。
- 階段を認識させる
- 梯子をかける
- 階段を登りたくさせる
メンターにとっては明らかに課題があっても、メンティは上ばかり見ていて気づかないものです。
そんなとき「階段があるよ」と教えるのではなく、「足元は大丈夫？」と聞いて本人に気付きを与えるのがメンタリングです。
心理的安全性(Psycological Safety)が高いとは次のような状態を指します。
- 対人リスクと取っても問題ないという信念がチームで共有されている状態
- 自分のキャリアやステータス、セルフイメージにネガティブな影響を与える恐れなく、自分を表現し働くことができること
効果的なメンタリングには心理的安全性が欠かせません。
「どんなダメなところを見せても関係性が破綻することはない」とメンティに思ってもらう必要があるためです。
そのためには、メンターは進んで自身の弱さや失敗を開示しなければなりません。
さらにメンターは「メンティ自身の存在を認めている」という承認のメッセージを発し続ける必要があります。
アジャイルといえば、スクラムやスプリントといった手続きに関するイメージが先行してしまいます。
しかし、アジャイルとは手続きではありません。
「ソフトウェアをどのように作るか？」はアジャイルの主眼ではありません。（中略）「ソフトウェア開発を行うチームをどのように構築していくか？」がアジャイルの目的と言えます。
アジャイルは方法論であるという前提に立つと、「アジャイルか？ウォーターフォールか？」というよくある議論は、比較しようのないものを比較しようとしていることがわかります。
さらに言えば「アジャイル開発は大規模開発に不向きである」という言説も的を得ていないということがわかります。
人が増え、組織が拡大しても、組織の生産性は人数の増加に比例しません。
組織の人数が増えれば増えるほど、コミュニケーションのコストが増えるためです。
そのため、誰が誰と、どれだけコミュニケーションをとるかという組織設計が必要になります。
そして、組織とソフトウェアの間には興味深い事実があります。
それは、ソフトウェアの構造には組織構造が反映されるというものです。
これはコンウェイの法則と言います。
なぜこのようなことが起きるのでしょうか？
コミュニケーションのコストは組織が離れるほど大きくなります。
ソフトウェア開発者が効率的な開発を行おうとしたとき、当然コミュニケーションコストも小さくしたいと考えます。
コミュニケーションコストが小さいのは、距離の近い組織です。
このようにして、いつの間にか組織構造がソフトウェアに反映されてしまうというわけです。
ソフトウェアは時間が経つにつれて開発速度が低下します。
これは開発者にとっては常識ですが、開発者でない人から見ると不可解です。
経営者が開発者を問い詰めると、開発者は口を揃えて「技術的負債」を理由に挙げます。
開発者は、度重なる改修の結果ジェンガのように不安定に積み上がり、もはや手が入れられない状態になってしまった複雑なシステムのことを「技術的負債」と表現します。
開発者は、「定期的に返済しなければならないもの」という意味で「負債」という言葉を使います。
一方、経営者は「負債」に対して違った見方をしています。
それは、低い利率で借り入れられるのであれば積極的に負債を作った方が良いという考え方です。
負債という言葉に対して、「返した方が良いもの」と「借りた方が良いもの」というまったく逆の考え方をする立場では、話も噛み合わないというわけですね。
以上です。このエントリでは「エンジニアリング組織論への招待」の内容をまとめました。
評価基準について詳しく知りたい方は下記の記事が参考になりそうです。
コメントを送る
コメントはブログオーナーのみ閲覧できます