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

広木大地

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

エンジニアリングという分類の組織で、ものを作り上げるにはどういった体制が必要か。その論理を書かれています。関係の無い世界にいる人間には分かりにくい、エンジニアリングという世界。その分かりにくさからくるコミュニケーションの問題やクライアントとの関係の解決をどのように行ってくるかという方法論は、実は全ての仕事にも当てはまるものです。
一回で終わってしまうプロジェクトではなく、製品は生き延びて利益を出し続けないといけません。完結しないゆえに不確実性を内包するプロダクトに対する考え方。不確実性に対応する組織の考え方。そのためのコミュニケーションの具体的な取り方。それらを包括する、一本通った組織の意識共有をどのように行うかなど、今日の組織の在り方に勉強になるものがありました。

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

エンジニアマネージャーを目指す人は是非読むべき一冊だと思いました。ものを作り始める時にどれだけ最初の不確実なことをなくせるかが、進捗に遅れを出さずにプロジェクトをうまく回せるということが一番ひびきました。
ついやりやすいタスクから手をつけてしまいがちですが、なるべく難易度が高いようなタスクから手をつけようという考え方に変わりました。
また人と人との関係の重要性をうたっており、まさにその通りだとしみじみ感じました。

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

エンジニアリングに関する組織論、思考法、マネジメント視点で書かれた本書は、なぜ開発がうまくいかないか、その不確実性について論理立てて構成して書いてある。
一度読むだけでは本書はなかなか身につかず、経験をしながら都度参考にする良書。
著者の経験とインプット量を想像した上で、本書は再読の価値があり、自分なりに思考するのに非常に適した本。

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

【文章】
　読み易い
【ハマり】
　★★★★★
【共感度】
　★★★★★
【気付き】
　★★★★・

・自分自身や、自分が大切にしているものに危害を加えられそうになったときに怒りの感情が立ち上げる
・論理的思考によって、ソフトウェアを組み上げる事が可能であるという前提に立ったプロセスが、ウォーターフォールをはじめとする設計主義的プロセス
・観測できないものは制御できない
・ティーチングによる他者説得よりも、自分で気付く自己説得を重視する
・「エンジニアリング」とは、不確実な物事の曖昧性を減らし、具体化・明確化していくこと。つまり、情報を生み出し、不確実性を削減すること
・不確実性は、環境不確実性（未来の事は分からない）と、通信不確実性（他人の事は分からない）の二つに分かれる
・プロフェッショナルは、不確実性の高い事から着手していき、詰めの精度を高くする
・「考える」は行動で、「悩む」は心の状態
・経験主義によって、仮説の検証を行う
・通信不確実性が局所最適化を生む
・「アジャイル開発」とは、開発手法を指す言葉ではなく、開発する組織の在り方を指す言葉
　・不確実性を減らすためには、どうすべきかを常に問い続ける姿勢
　・盲目的に標準プロセスに従う開発は、「アジャイル開発」とは言わない
・プロジェクトは終了する事を目指し、プロダクトは終了しない事を目指す
・ソフトウェア産業の根底には、東洋思想に影響を受けたヒッピー文化が流れている
・ソフト開発受注者は、明確な計画と契約を定義し、そこを責任分界点とすることで自己防衛を図る、それによって「限定合理性」が生まれてしまう

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

学生、新卒、シニアエンジニア、プロダクトオーナー、エンジニアマネージャー、経営者、誰彼かまわず必読。正直まだ３割も実感を伴った理解になってない。が、それでいいんだと思った。

著者は何だったかな、、何かで、「いろいろな本を読み漁った後に、この本を読んで欲しい」と述べておられたように記憶してます。

私見ですが、いろいろな本を読む動機付けとして、この本で喉に魚の骨を刺しておくのは読み方のひとつ。意識/無意識に、アレって何だったんだ、むむむ、って思いながら、日々の仕事に向き合ったり、何か本を読んでいて、あっもしかして、あーこういうことか、なるほどー！という読み方ができるといいんじゃないかと思った。

あと、この本の記述を不磨の大典のごとく援用して、誰かを非難するのは間違った使い方で、自分を振り返ったり、カイゼンジャーニーな使い方が幸せになれる用法と読んだ。

以下、強く印象に残った章と感想。

ch1-4,論理的思考の盲点。「やあやあ我こそは常に論理的思考に基づいて職務を遂行する職業人であるぞ」などという事実無根の願望を木っ端微塵にしてくれます。典型的には「カッとなってる時」は、さも猛烈に論理的に頭が高速回転頭してるように感じてますが、シャワー浴びて、頭をアイスノンで物理冷却して、この章を読むと、論理的思考の盲点を踏み抜きまくってることに気づくはずです。過去の様々を振り返っても恥ずかしくなります。からの返す刀で、いま進行中の仕事も点検してみると多々ひどいところがあって、まったくひどいです。ひどいと気付いたものは、角が立たないように軌道修正します。あれとかそれとか。喉の魚の骨。

ch2, メンタリングの技術。内省の技術でもある。と読んだ。ヒアリングしつつ、メンターの思考リソースを貸しながら、メンティ自身に気づかせる。クソ難しい。今のところ読み返してる回数が最も多い。喉の魚の骨。

ch3, ch4。企業買収の局面で、スタープレイヤーが居る居ないよりも、素晴らしいチームに高い金額がつく、というのを何か別のところで見た記憶があった。ch3,4を読んで、なるほど、チームがある、チームビルドできる人がいる、自己組織化している、などが高価になるロジックを理解できた気がした。喉の魚の骨。

ch5-3,技術的負債の正体。恥ずかしながら、このレベル感で、多角的に深堀って紐付けて整理した論考は初めて読みました。目から鱗。循環的複雑度が負債の指標であるのは間違いなくも、他の構成要素を手繰り寄せることができず、まして「エンジニアと経営者のコミュニケーション」なんて結論になると1ミリも想像つかなかった。技術的負債には、システムアーキテクチャとかミドルウェア選定とかクラス設計で立ち向かうみたいなのイメージしか持ててないエンジニアは、この章を足がかりに他の章を読み進めると良いでしょう。