TatsuyaのテクTechブログ

IT技術を中心に勉強したことを書くブログ

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

 年末、ようやく読み終えた。SNSのITエンジニア界隈で流行っているのと、カイゼン・ジャーニーを読み終えたところで次に読むマネジメント系の本としてちょうど良いと思い、Kindleで10月下旬から読み始めた。冒頭から個人的に学門的な観点で踏み込んでおり小難しいなと感じましたが、最後まで読んで、自主的に動ける人・組織へ成長させるための知識・技術及びIT技術と組織の結びつきが(完全ではないが)理解できたと思う。また、その様な内容だったので、エンジニアに限らず、社会人であれば読んだほうが良いと思う。

 

本書は全般的に学びのある内容だったが、その中から個人的に印象があった部分をまとめておく。

1.Chapter.2の「課題の分離」

 こちらは学びというより、過去に得た知識を思い出したのと、再認識できた内容になる。本書では、メンティが抱える問題を傾聴するときに、その問題は本当に自分の課題なのか、他者(他チーム)の課題なのかを切り分けて、問題の対処をする必要がある。また、メンターもメンティの問題を「自分の課題」とは捉えて、メンティの課題を解決してはいけない。というものです。

 この内容を読んだときに、数年前に読んだ「嫌われる勇気」の内容(アドラー心理学)にあった「課題の分離」を思い出した。当時は、心理学の知識と捉えたのと他事情で、仕事に適用させるところまでは考えられなかったが、心理学を具体的に活かす方法として知れてよかったと思う。

 

2.Chapter.3 の「プロジェクトマネジメントとプロダクトマネジメント

 こちらは、プロジェクトマネジメントとプロダクトマネジメントの違いを書いた部分となり、以下の様に書かれていた。

 ・プロジェクトマネジメント

  ・プロジェクトを「終わらせる」ためのマネジメント

  ・最大のリスクは「終了しないこと」

  ・プロジェクトマネージャーは「スケジュール不安」を減少させるために動く

 ・プロダクトマネジメント

  ・プロダクトを「終わらせない」ためのマネジメント

  ・最大のリスクは「終了すること」

  ・プロダクトマネージャーは「マーケット不安」を減少させるために動く

 

 一番の違いは"終わらせる" or "終わらせない"という部分であるように思うし、違いを的確に表した文章だなと感じた。プロジェクトマネジメントの案件の経験を振り返ると、納品日または本番稼働日に向けて、計画されたタスクを全て終わらせるために動いているんだと気づくことができた。また、納品日または本番稼働日までにタスクが全て終わるかどうかの不確実性を「スケジュール不安」と呼び、プロジェクトマネージャーは「スケジュール不安」を減少させるために、品質・タスク・ステークホルダー・スコープなどPMPに定義されているマネジメント要素を管理・調整させていると認識できた。

 プロダクトマネジメントの方は、経験がない(似たようなのはあるが)ので知識の取得に修まっているが、プロジェクトマネジメントとは全く動き方が異なるマネジメントであると分かりやすく理解することができた。

 

3.Chapter5.「技術組織」の力学とアーキテクチャ

 こちらは一つの章全体となる。現在、職種はシステムエンジニアだが、チーム内でITアーキテクトに近い役割を担っている。個人的なITアーキテクトの定義は「ビジネス課題を解決するためのITシステムのアーキテクチャの策定・実行、またビジネスアイデアを実現させるためのITシステムのアーキテクチャの策定・実行」としているが、経験が浅いのもあり、ビジネスとITシステムの紐づけができていない。しかし、この章を読むことで、組織とITシステムの紐づけについて得るものがあった。例えば、言葉だけ知っており意味を知れていなかった「コンウェイの法則」「技術的負債」を知ることができた。

コンウェイの法則」は次のようなものと書かれている。

システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう

 具体的には、組織構造から発生するコミュニケーションコストの高さにより、高い部分の機能追加は行われず、低い部分の機能追加が優先して実装されてしまうというもの。コミュニケーションコストを避けた機能追加で本質的な問題解決になる場合は良いと思える。ただ、そうでない場合は小手先による問題解決となり、追加された機能は"秘伝のタレ"として残り、システム全体のリプレイスやマイグレーション時の計画時に見逃されて、ユーザーテストで発覚して問題になる気がする。

でも、現実はリソースと納期の都合上、できる範囲(なるべくコミュニケーションコストを抑えて)での機能追加は観測できる範囲では多いので、コンウェイの法則は避けられない事象なのであると思う。

 「技術的負債」という言葉自体は、コンピュータ技術者ウォード・カニンガムによって1992年に提供された概念であり、経験レポートで次のようなものと語っている。

 最初のコードを出荷することは、借金をしに行くのと同じである。小さな負債は、代価を得て即座に書き直す機会を得るまでの開発を加速する。危険なのは、借金が返済されなかった場合である。品質の良くないコードを使い続けることは、借金の利息としてとらえることができる。技術部門は、欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、立ち尽くすはめになる。

品質を犠牲にして開発を進めていくと、徐々に機能追加が困難なシステムとなり、コミュニケーションコストが増えていくことになると認識し、「コンウェイの法則」の延長上にある1つの状態だと感じた。こちらも避けにくい事象なのではないかと感じたが、本書ではフィリップ・クルーシュテンの4象限の定義により技術的負債は「見えないマイナスの価値」であるとしている。それならば見えるようにすれば良いと考えるが、直感的に簡単ではないと感じたし、見えるようにするためのコストをどうするかも考えないといけないが、本書にはそのためのヒントも載っているので、必要性が出てきたときに再読したい。

 

 

 ここからは備忘として、Chapterごとに私が記録しておきたいところを、箇条書きベースでまとめておく。途中で力尽きて消そうかと考えたが、再読するときのことも考えて残しておく。 

Chapter1.思考のリファクタリング

・「エンジニアリング」は「不確実性」減らす行為

  →具体的にいうと、「曖昧さ」を減らし、「具体性・明確さ」を増やす行為

  →「曖昧さ」は経済学や社会学の分野では「不確実性」と表現される

・仕事は「複数人」「情報があるかわからない」「答えが決まっていない」もの

・仕事が上手く進まない理由として、論理的思考の盲点。

 →人は感情的になる。認知能力の限界、立場などによりコミュニケーションが失敗し、情報を正しく扱えなくなる。

・仕事では「経験主義」と「仮説思考」を使って答えに近づく

 経験主義:行動を起こした結果で得た情報から問題解決を行う

 仮説思考:限定された情報から想定した全体像を確かめる思考様式

・システム思考:仕事の正解を自ら設定する思考様式。限られた時間と資源の中で答えに近づくために必要。

・理性主義と経験主義

 理性主義:「前提」から演繹的に世の中を説明する考え方。

 ・ウォーターフォールの「設計主義的プロセス」も、理性によって、設計主義的にソフトウェアをくみ上げることが可能であるという前提のプロセス

 ・スクラムは「経験主義的プロセス」。「スクラムガイド」に経験主義に対して言及がある。

 ・経験主義的発想では、「分からなかった」「正解ではなかった」も重大なヒントであり、次の行動を生み出す。

・仮説思考

 ・演繹法帰納法に続く推論能力方法

 ・新しい諸概念を導入する唯一の論理的操作

 ・わずかな痕跡から説明可能とする大胆な思考展開・モデル化を行い、それを検証するための行動につなげる

 ・経験主義をさらに生産的なものにするための「大胆な跳躍」をもたらす

PDCAサイクル

 ・仮説を検証するためのサイクル

 ・仮説を明らかにする&検証できるのかというアイデアを持つこと

・リアルオプション戦略

 ・「遅延した意思決定」を行うための戦略

 ・小さく投資・失敗をして成功の確率を上げていくこと。巨額の投資判断による失敗を防ぐための考え方

・問題の解決と問題の明晰化

 ・問題の明晰化のほうが難しく、重要

 ・すぐ解けない問題は、問題が明晰ではない。問題をはっきりさせるために仮説検証をする思考に切り替える

・不確実性

 不確実性の詳細

 ・環境不確実性:未来に関すること。経験主義・仮説思考で減少させる

 ・通信不確実性:他人に関すること。コミュニケーションで減少させる

  ・情報の非対称性:人により持っている情報が異なること。

  ・限定合理性:人の認識できる範囲でしか、合理的な行動をとれない。

 

Chapter2.メンタリングの技術

・メンタリングは思考のリファクタリング

・メンターの由来は、古代ギリシャ神話。おでゅせうす王の息子を立派な王に育てた賢者として伝承された「メントール」にちなんで。

・「自ら考える人材を作る」ためのテクニック

 ・自立型人材:自ら問題を発見し解決することができる。問題について、自分事として捉えている

 ・依存と自立の境界線:上司と部下の関係における期待値の違い。同じなら問題なし。違うなら問題あり。

 ・コンフォートゾーン:役割の中で、自分が「心地よく」いられる思考の範囲や行動の範囲

 ・学習性無気力:自立的な活動に対して、否定され続けた結果、生まれた無気力。

 ・自己効力感:自立的な活動に対して、肯定され続けた結果、生まれる感覚。

  ・自己効力感がコンフォートゾーンを上回るようにメンティを導くこと

・効果的なメンター/メンティの関係性

 効果的な関係性を築くための条件

 ・謙虚:お互いに弱さを見せられる

 ・敬意:お互いに敬意をもっている

 ・信頼:お互いにメンティ(自身)の成長期待をもっている

 それぞれの頭文字をとって、「HRT」と呼ばれる

・メンティの成長を手助けするために

 ・他者説得から自己説得に:自分で課題と答えを見つけさせる。

  ・他人が質問で促す

  ・体感を伴う

  ・行動の変化が発生しやすい

・悩むと考えるの違い

 ・悩むは状態

 ・考えるは行動

 ・前者は他人が観測できないが、後者は観測できる

・傾聴・可視化・リフレーミング

 ・悩むから考えるに移すためにメンターができる行動

・課題の分離

 ・ある問題は誰にとっての課題であるのか、はっきりさせること。

 ・他人の課題か自分の課題かで行動が変わる。

心理的安全性

 ・「対人リスク」を伴う行動が増えている状態のこと

 ・それで、よくするために「問題に対して向き合う状況」を生み出している。

 ・ラーニングゾーン:心理的安全性が高く、責任も高い状態。メンティが目指す位置。

 ・メンタリングでは"メンティの弱さ・失敗を開示してもらう"、自分の弱さ・失敗を開示する状況を作りあげる必要がある

 ・メンターは、成長物語から弱さ・失敗を開示する

・行動を観測する

 ・メンティの行動は見れるが、内心は見れない

 ・「SMART」な行動

  ・S:具体的な

  ・M:測定可能な

  ・A:到達可能な

  ・R:関連した

  ・T:時間制限のある

・能力は習慣の積分、習慣は行動の積分

・ゴール認識

 ・行動変化に至らせるためのゴールのレベル

  0:願望

  1:義務

  2:欲求

  3:意思

  4:必然

 

Chapter3.アジャイルなチームの原理

アジャイル開発は、チーム全体に対してメンタリングを行い開発出力を向上させる方法論

・「ソフトウェア開発を行うチームをどのように構築していくか?」がアジャイルの目的

アジャイル開発が必要となった理由

 ・ソフトウェアが大規模化・複雑化

 ・マーケットの不確実性に対応する

アジャイル開発は3倍の成功率、1/3の失敗率

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

 ・プロジェクトマネジメント

  ・プロジェクトを「終わらせる」ためのマネジメント

  ・最大のリスクは「終了しないこと」

  ・プロジェクトマネージャーは「スケジュール不安」を減少させるために動く

 ・プロダクトマネジメント

  ・プロダクトを「終わらせない」ためのマネジメント

  ・最大のリスクは「終了すること」

  ・プロダクトマネージャーは「マーケット不安」を減少させるために動く

 ・スケジュール不安:やってみないとできるか分からないという不確実性(方法不確実性)に依拠する

 ・マーケット不安:やってみないとマーケットに受け入れられるか分からないという不確実性(目的不確実性)に依拠する

・スケジュールとマーケットの2つの不安

 ・ウォーターフォール的な計画駆動は、スケジュール不安のみが前提となる

  ・初期計画で精度を高める。変化に弱い。

 ・アジャイル開発は、スケジュール不安とマーケット不安の両方がある。

  ・実験的に徐々に精度を高める。変化に強い。

アジャイルをするな、アジャイルになれ

 アジャイルな状態

 ・情報の非対称性が小さい

 ・認知の歪みが少ない

 ・チームより小さい限定合理性が働かない

 ・対人リスクを取れていて心理的安全性が高い

 ・課題・不安に向き合い不確実性の削減が効率よくできている

 ・チーム全体のゴール認識レベルが高い

 個人がアジャイルになり、他の人もアジャイルになれば、チーム全体が自然とアジャイルになる。

・ウォーターフールとアジャイル

 ・ウォータフォールの範囲

  ・方法不確実性(スケジュール通りに終わるか)

  ・目的不確実性(マーケット(客)に受け入れられるか)

 ・アジャイルの範囲

  ・上2つ

  ・通信不確実性(継続するチームマネジメント)

スクラム

 ・振り返りのためのフレームワーク

 ・Whatに関する学習ループ:顧客に届けるものの検証

 ・Howに関する学習ループ:現場の改善「計画」「振り返り」

 

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

・不確実性マネジメントで管理する不確実性と管理手法

 ・方法不確実性:スケジュール予測と見積もりの手法

 ・目的不確実性:要求と仮説検証の手法

 ・通信不確実性:振り返りの手法

・スケジュールマネジメント

 スケジュールマネジメントで見積もる3要素

 ・理想工期:工期人月/人数

 ・制約スラック:作業同士の依存関係による無駄な時間

 ・プロジェクトバッファ:見積もりの不確実性を吸収するための期間

 これらに注目して改善を行い、リリース時期の精度を上げるのがスケジュールマネジメント

・プリンシバル・エージェント理論

 経済における人間関係を「依頼者」と「代理人」との契約の束としてとらえる考え方

 ・エージェンシートラック:依頼者からみて、代理人に嘘をついたほうがメリットがあると思うことで、適正価格よりも費用が高くなるときの差額のこと

 ・コントロールコスト:依頼者の利益が、代理人の利益になるように監視やインセンティブの形で支払う必要があるコスト

 ・シグナリングコスト:「情報をもつ側」が情報を開示し、非対称性を解消するために支払うコスト

・マーケット不安

 ・時間境界型プロジェクト:特定時期(クリスマス商戦など)に向けた機能のリリースをするプロジェクト。この時間境界を「納期」と呼ぶ。

 ・機能境界型プロジェクト:ある機能のパッケージが固まってリリースしないと仮説検証にならないプロジェクト。この機能のラインのことをMVPと呼ぶ。

 ・スコープバッファ:機能境界型プロジェクトによる当初計画した機能とMVPの差

 ・リリースポイント:機能が完成して提供できる瞬間。また、プロダクトオーナーや経営者が初めてプロダクトを触って機能を確かめられる瞬間。触れられることで、初めて目的不確実性が減少する。そのため、リリースポイントはなるべく遅らせず、早めにしてもらうほうが生産的。

 ・ユーザーストーリー:各種機能の分解方法。サービス全体がある顧客にとっての物語になるように分解する。

  ・どのような人が

  ・何ができる

  ・そのことでどのような感情になる

 ・INVEST:チームが開発作業を開始するおにちょうどよい粒度のストーリーになっているか判断するフレームワーク

 ・リーンキャンバス:仮説を明らかにするフォーマット

スクラム

 不安への向き合い方をチームが学習するための方法論

 役割

 ・プロダクトオーナー

 ・開発チーム

 ・スクラムマスター

 イベント

  スプリントの間に行うイベント

  Whatの検査、Howの検査、日々の検査ができるようになっている

  ・スプリント計画

  ・デイリースクラム

  ・スプリントレビュー

  ・レトロスペクティブ

 ・ゴール設定

  インセプションデッキ:ゴール認識を合わせるためのフレームワーク

 

Chapter5.技術組織の力学とアーキテクチャ

労働生産性はビジネスの結果を分析する手法。

 ・偶発的にうまくいった場合も、必然的にうまくいった場合も区別なく計算される。組織内部を考察するには、あまり向いていない。

 ・必然的にうまくいった、いかないを分析できたほうが良い。

  例:1枚の宝くじで当たるか祈るよりも、いくつ宝くじを買うことができるか

  ・不確実性を効率よく仮説検証する能力だと言いかえれる(投資規模やリソース?)

  ・不確実性の削減≒情報を生み出す。不確実性を削減できる力≒企業の情報処理能力。 

ガルブレイスの組織情報処理モデル

 ・保有するシステムを含む組織形態から、企業の情報処理能力が決定し、対象となる市場の不確実性から、必要な情報処理量が決定する。

 ・情報処理量に対して、企業の情報処理能力が上回れば「組織成果」につながる。

 ・エンジニアリングの不確実性とのつながり

  目的不確実性:情報処理必要量(戦略)

  方法不確実性:情報処理能力(戦術)

  通信不確実性:情報処理能力(兵站

・個人の総和が組織の能力にならない

 ・組織が完全な能力を発揮するのには組織内で行われるコミュニケーションが100%の完全な情報伝達が必要。

 ・実際は不可能で、人数が増えるほどコミュニケーションの失敗が発生する。

 ・理想的な情報処理能力の推移と、現実の情報処理能力の推移の差を埋めるのが「コミュニケーションコスト」

 ・組織のコミュニケーションネットワークはプリンシバル・エージェント関係

・組織とシステムの関係

 ・システムの構築を行う組織

  情報処理のモデルで考えると、経営層が市場の不確実性を判断し、ビジネス部門が戦略を練り、開発部門が具体的で必要なシステムに落としていく。階層構造になる。

 ・開発部門は実現フェーズに近い組織

 ・コンウェイの法則:システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう

  ・コミュニケーションコストが高い組織になるほど、コミュニケーションを避けるために実現性の高い機能を重点的に開発が効率が良いと判断するようになる。

  →部分最適解のシステムになったり、経営層が気づかないまま組織設計上の問題が組み込まれることになる。

・エンジニア組織のアンチパターンへの処方箋

 ・組織全体のコミュニケーションの改善

  ・個々人:Chapter1

  ・マネジメントとメンバー、メンバー同士:Chapter2

  ・チーム:Chapter3,4

 ・組織と権限

 情報処理能力の高い組織

 ・責任と権限が一致している

  ・不一致が生じると、認識している権限が違うという「情報の非対称性」により情報処理能力が低下する。

 ・権限を委譲できている

  ・権限が一人に集中すると、その人の情報処理能力が、その組織のボトルネックとなる。

  ・具体的な指示がないと動けない。マイクロマネジメント型組織

  ・抽象的な指示でも動ける。自己組織化された組織

 ・デリゲーションポーカー

  ・権限移譲のレベルをメンバー間で合意を楽しみながら作れる手法

・技術的負債

 ・アメリカのコンピュータ技術者であるウォード・カニンガムによって、1992年に提唱された概念

 ・追加開発により、徐々に初期の設計から逸脱することで追加開発工数が増えていく状態。

 ・技術的負債を抱えたシステムは、積み上げていくにつれバランスが悪くなったジェンガと似た状態

 ・なり得る要素「無鉄砲な/慎重な」「意図的な/無意識の」の4象限

  ・慎重で意図的:リスクより、リリースを優先

  ・慎重で無意識:たぶん大丈夫

  ・無鉄砲で意図的:設計する時間がないので、雰囲気で作る

  ・無鉄砲で無意識:設計方法がわからないので、雰囲気で作る

 ・見ることができないもの

  ・技術的負債は、見えないマイナスの価値