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

広木大地

「コミュニケーションにおける不確実性を減らすには？」「技術的負債を解消する方法とは？」「経営陣とエンジニア間の認識のずれを解消するには？」
エンジニアリングにおける課題を解決する思考の整理方法やメンタリング手法を，さまざまな企業の技術組織アドバイザリーを務めている著者が解説。
若手を戦力として育て上げ，成長する組織を設計・運営するためにおすすめの1冊です。

• カテゴリ: ビジネス・実用
• ジャンル: IT・コンピュータ / 情報科学
• 出版社: 技術評論社
• ページ数: 304ページ
• 電子版発売日: 2018年03月02日
• コンテンツ形式: EPUB
• サイズ(目安): 21MB

[ブクログ · ★★★★★]

エンジニアリング組織がある場合には、営業を含め必読の本

人間が作り上げる組織ということを前提に組織マネジメントの要諦が表現されている。

不確実性を下げ、内発的動機をドライブし、本来の目的に立ち返った開発組織を作っていくために大半示唆に富んだ本

[ブクログ · ★★★★★]

期待以上によかった。もう7年前になるが古びていないしシステム開発以外の仕事や日常生活でもハッとさせられる言葉が満載

P11　「理学」が物理学や化学のように世の中の自然の原理を見つけて、説明していく学問であるのに対して「工学」はそれらに依拠しながらも「何か役に立つものを」「実現していく」学問です。エンジニアリングとはつまるところ「実現」していくための科学分野だと言えるでしょう。

P19　学力テストは普通、論理的な思考を用いて行います。しかし人は、論理的思考を常に正しく運用できるわけではありません。とりわけ、他人が介在する問題について、わたしたちは感情的にならざるを得ない生き物です。仕事は通常、複数人で行います。そのため、人間関係や他人との共同作業をしていくうえで、意識的、無意識的に感情的になることがままあります。これを乗り越えて、問題を正しく認知する必要があります。

P37　わたしたちは、物事に取り組むときに、つい「どうやるか、どのくらいで終わるか」がわかっているような仕事を優先的に好んで行いがちです。そうすると、最後のほうに「道や廊下、どのくらいで終わるのか」わからないような不確実性の高い課題ばかり残ってしまい、完了時期がいつまでたってもわからないというような結果になってしまいます。これは、プロジェクトマネジメントにおいても同じことが言えます

P41　重要なのは、本来コントロールできないはずのものをあなたの行動で変化させようと試みる時には、その対象が「観察できる」必要があるということです。なぜなら「観察できない」ものはどんなに行動したとしても変わったのか変わらないのかわからないからです。

P65　問題解決のための眼、それは「視野」（広い狭い）「視座」（高い低い）「視点」（鋭い凡庸）の３つに分類できます。

P122　（何かを説明したときに「わかった？」と聞くのは）まったく意味のない行動だったと悟り、意図的に減らしていくようにしました。【中略】観測可能な行動を通じて理解を確認するには、たとえば「試しに一人でこれをやってみて」であるとか「代わりに自分の言葉で説明してみて」と行動を促すような方法があります。

P123　わたしがよく使う言葉として「能力は習慣の積分だ」というものがあります。習慣とは行動が染みついたものです。そのため「行動」や「習慣」は外からでもメンタリングの方法論を用いて成長を促すことができます。（習慣は行動の積分。習慣が能力に変われば成果につながり成果は自信となって行動を強化していく）

P136　プロジェクトは「はじめ」と「終わり」があり、それが高価をあげて「終了すること」が目的です。それに対して、プロダクトは「製品・サービス」ですので、そのプロダクトが継続的に収益を上げて損益分岐点を越えて発展することで「終了しないこと」が目的になります。【中略】このようにプロジェクトマネジャーとプロダクトマネジャーは本質的に異なる不安に対してアプローチする存在であるという違いがあるわけです。

P157　「合理的な理解」よりも「体感的な習熟」

P172　米国における俗語に「クールエイドを飲むな」という言葉があります。（誰かの思想信条を無批判に受け入れるな）【中略】アジャイルという言葉が誤解されている理由には、こうしたクールエイドを飲んでしまった人々にも問題があります。

P182　時間は、経営における重要な資源です。このことは一概に「早く終わる」ことが重要であるという意味ではありません。「どのくらいの時間がかかりそうなのかを、できる限り正確に知ることができる」ことが重要であるということを意味しています。

P210　本来、ソフトウェアプロダクトを提供する事業において「その日」にリリースされていないといけないという制約は、意図的に作らない限り生まれません。むしろ、本来のビジネスを総合的に考えると「何を作るのか」「それは市場に受け入れられるのか」といった不安がはるかに大きいウェイトを占めるケースのほうが多いのです。しかしスケジュール不安の大きい開発者と経営者という関係性がある場合には、まずはその「情報非対称性」を取り除くことが重要です。スケジュール以外にも重要なことがあるのだということを、お互いに気が付く必要があるからです。

P216　最初に構築した仮説から、一番の不安材料となるものを洗い出し「不確実性を下げられる存在」つまり顧客に当ててみることで初めて、仮説の不確実性が削減されます。（目的不確実性が下がっていくと大きなコストをかけられる　仮説構築⇒ユーザー調査⇒プロトタイプ検証⇒MVPリリース⇒小規模マーケティング⇒大規模マーケテイング）

P220　不確実なことを減らすには、一番不確実なことから確かめていくことです。そうすれば早く失敗できるので、一番早く問題解決できます。エンジニアリングとはそういうことです。それは「言うは易し行うは難し」の典型例とも言えます。【中略】人間には恐怖から逃げる仕組みが用意されているのでなかなか抗うことができません。「一人でできないのであれば複数人でやればよい」と考えると少しだけこのことが簡単になります。現実を直視し、不安に向き合えるようにチーム全体が個々人をサポートしていく状態になれば、仕事における不安に向き合うことができるようになります。⇒不安に向き合うフレームワークとしてのスクラム

P243　権限移譲のレベル
レベル１　上司が部下に命令する　２上司が部下に説得する　３上司が部下に相談する　４上司が部下と合意する　５上司が部下に助言する　６上司が部下に尋ねる　７上司が部下に委任する　　cfデリゲーションポーカー

P250　（カニンガムの提唱した）「技術的負債」という言葉は、会計上も経営指標においても計上されるわけではない空想上の概念に過ぎません。「技術的負債」という言葉の定義もあいまいで、何をもって技術的負債ということができ、何を持って測定され、どのような返済手段があるのかといった議論も尽くされることなく、広く用いられるようになりました。その結果「技術的負債」という言葉の存在で何かを説明したと思い込む人々や、ソフトウェア開発における経営上の問題について関心を抱かない経営者によってむしろコミュニケーションを断絶する言葉になってしまっているケースがあるように思います。

P276　システム外注における取引コスト＝探索のコスト（外注先選定にかかるコスト）交渉のコスト（契約条件を決めるために必要なコスト）監督のコスト（外注先をマネジメントするコスト）

P277　（企業のコアコンピタンスとして内製で持つものと一時的に必要な機能や周辺領域を拡大するために外注するものの）線引きをシステムの構造（アーキテクチャ）として持つことで、上手に取引コストをコントロールできます。

P286　機能横断型組織＝新しい知見が生まれやすくなりビジネス上の意思決定が早くなる＝知の探索/機能別組織＝特定の領域の効率を上げていく＝知の深化
全ての業種においてこの「知の探索」と「知の深化」のバランスの見極めが必要です。

[ブクログ · ★★★★★]

最後まで密度の濃い、目から鱗の内容であった。
エンジニアリング、メンタリング、アジャイル、など、フワッとした言葉を、明確に定義付けし、府に落ちた。
少しでも行動に移していく。

以下メモ。書ききれない。。
・エンジニアリング:実現のため不確実性の低い状態に効率良く移す全ての過程(不確実性の削減)18
・問題が解けないのは、問題が正しく明晰に記述できていないため。解決よりも先に、問題をはっきりさせる。経験主義の考え方と仮説思考が重要。21,50
・不確実性の高い物を優先して取り組む。効率よく不確実性を下げるプロセス。やりたくないもの。37
・出来ること:コントロール出来るものを操作し、観測できるものの結果を見る(経験主義)。42
・良いプログラムとは:視野、視点、視座を広く、鋭く、高く置いている。65
・コミュニケーションがうまくいかないのは、「情報の非対称性」と「限定合理性(極小最適)」が存在。
コミュニケーション能力:不確実性を減少させる能力
情報の透明性:意思決定に関わる情報が、組織内に正しく整合性をもって伝達されるための取り組み。情報公開とは異なる。72
・・・

[ブクログ · ★★★★★]

経営理論や組織開発のエッセンスが概ね網羅されている上に、個人でできることを起点に組み上げられていて実践しやすい。
著者の深い実践知が垣間見える名著。

[ブクログ · ★★★★★]

エンジニア向きなタイトルではあるが、Chapter1と2は組織のマネジメントや不確実性を低減する思考法について書かれており組織のマネージャーにおすすめの内容。

[ブクログ · ★★★★★]

まず、アジャイルやスクラムが何のために必要なのかを端的にまとめられている。また、不確実性や技術的負債といった曖昧に語られる言葉について分析、紹介している点、情報の非対称性から発生する限定合理的な行動という切り口からエンジニアリング組織に起こりがちな問題について説明している点など、良い点を挙げればキリがない。

エンジニア組織に関わるすべての人に読んでもらいたい一冊。

[ブクログ · ★★★★★]

個人から組織まで様々な視点で抽象的なことから具体的なことまで書かれていてとても良かった。ベスト本です。エンジニア組織に関わる人なら全員読むべき本だと思いました！

[ブクログ · ★★★★★]

不確実性が高いプロジェクトをどのようにドライブするか、各要素ごとにかなり丁寧に書いてある。
私はチームメンタリング部分を参考にしたかったため、それ以外は読み飛ばしたが、かなり具体的で参考になった。
メンタリング部分だけでも読む価値がありそう。

[ブクログ · ★★★★★]

自分的には非常に良書だった。個人レベルの思考方法についてから入り、コミュニケーションを行う上でのメンタリングの重要性、チームにおける開発・マネジメント、組織の力学と徐々にスケールアップしていく流れも良かった。エンジニアリング組織で働く人の学びになる記述が多くある。特にメンタリングのところは、自分がメンティーの立場だったときに記述されていたようなコミュニケーションを実践できていなかった先輩も多かったし、自分がメンター的立場だったときを思い出すと発言や接し方を反省すべきところがたくさん思い返された。ところどころ、「～は○○といいます」みたいなところでは出典を出した方が良い気がしたのと、筆者の経験を踏まえた自身の考えなのか、出典のある定説なのか分からず、モヤモヤ感じるところもあったが、文章の納得性は非常に高いので、割と素直に理解・共感できた。また、節の中での項目間のつながりがよく分からず、伝えたいことが羅列されているように見えてしまう感もあった。その分を差し引いてもぜひ多くの人に読んで欲しい重要な知見が詰め込まれている。

[ブクログ · ★★★★★]

予想に反して、所属している会社で起こっていること、行われていることのバックグラウンドを理解することに役立つ一冊だった。
個人的には本書で解説されたようなアジャイルムーブメントの背景は知らなかったので面白かった。
若手中堅向けな印象、OJTトレーナー研修で読むといいんじゃないかな。
本書終盤に謎の誤字(変換ミスのようなもの)が多いのはどうにも気になったけど本質を損なうものではなかった。