■

 「エンジニアリング組織論への招待」を読む。

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

 ・エンジニアリングは実現の科学。「曖昧さ」を減らし、「具体性・明確さ」を増やす行為が「エンジニアリングとは何か」という答えでもある。

・組織においても、経営トップからエンジニアまで、不確実なことを実現していく。

・情報を生み出していくことが不確実性を下げることに繋がる。学校教育では、反復的に決まったことを覚えることが勉強のメインとなっており、生み出すことに慣れていない。「3枚の裏側のトランプのうち、ハートのエースはどれか？」という問いの答えは、「一つずつ裏返して確認する」しかない。

・何が問題が分からない状態から、学力テストの状態まで落とし込むという「思考のリファクタリング」が必要。

・認知の歪みや感情はどうしても排除できないが、なるべく排して組織を論理的に捉える必要あり。

・なるべく分からないものから先に手をつける。そうすると、仕事の初期に大きな問いをクリアできるので、短時間で6、70点のクオリティの仕事が出来る。

・ソフトウェア工学の祖、トム・デマルコの名言「観測できないものは制御できない」の通り、制御できないものを見極めて無駄なエネルギーを使わない。

・BSとPLは、微分積分の関係にある。要は、資産をビジネスモデルに変換し、増加した資産でさらにビジネスモデルに投資する、というフィードバックサイクルのシステムと捉えられる。PLの視点でだけで見ると従業員教育とか研究開発投資とかは「コスト」でしかないので削減するのと局所最適となってしまうが、再投資してフィードバックすることで全体最適を得ることが出来る。

・発注者と受注者では協力してモノづくりするはずなのに、それぞれ違うインセンティブが働くため、限定合理的な納品物が出来てしまうケースがある。

・依存型人間と自立型人間ははっきり分けられるものではない。仕事で誰かに依存してる人も、趣味のサークルを自律的に運営しているかもしれない。

・「考える」は行動で、「悩む」は状態である。悩んでいる状態から考える状態に移行させるメンタリングが必要となる。

・メンタリングの時、相手の感情について「どうしてその感情に至ったか」を解きほぐすのはアリだが、別に同感する必要はない。

・我々は少し難しい計算問題は筆算して、計算を分解して考えるのに、人生の問題や仕事の問題を筆算せずに考えて途方に暮れてしまうことが多い。

・能力は習慣の微分。さらに、習慣は行動が元となる。能力はコントロール出来ないが、行動や習慣化はコントロール出来るので、身につけていけば能力はついてくる。

・プロジェクトマネジメントとプロダクトマネジメントの違いはいくつかあるが、前者は終わらせることが目標なのに対して後者は終わらせないことが目標となる。

・プランニングポーカーを使って、見積もり意識をチームメンバー内で統一する。

・「コンウェイの法則」という「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」法則がある。組織階層の深さや他拠点にまたがる組織のコードなどは、コミュニケーションに問題が起きやすくバグが埋め込まれやすい。よって、「ソフトウェア開発上の問題はの多くは、技術的というよりも社会学的なものである」というトム・デマルコの言葉がその通り当てはまる。

・技術的負債は解きほどくと非機能要件となる。

・取引コストによって会社の境界線が決まる。取引コストとは経営上のリソースを市場から手に入れるためのコストだが、内部にするのか、それとも外部のまま受発注するのかの判断をしていく必要がある。外注するためには「探索コスト」「交渉コスト」「監督コスト」がかかるので、これらコストの総計が取引コストより低ければ外注した方がお得。だから、変に事業部制とかを導入すると社内に不要なコストが発生したりしてうまくいかないケースがある。

・ビジネスをコンピュータに理解出来る明晰な言葉で表現するのがプログラミング。