雑感

読んで面白かった本を要約しています。主に事業・プロダクト開発(PdM/UXデザイン/マーケティング)のビジネス書と社会科学(経済学/経営学)・人文科学(哲学/歴史学)の古典。

■要約≪エンジニアリング組織論への招待≫

 

今回は「エンジニアリング組織論への招待」を要約していきます。

自分はエンジニアではないのですが、開発組織の論理を学びたいという個人的な興味関心とプロジェクトマネジメントに関する要諦をまとめた本でもあるということを知人から教わり、個人的な課題・関心の答えがあるかもと思い読んでみました。このタイミングで読めて、本当によかったなと思える素晴らしい内容でした。

 

■エンジニアリング組織論への招待

f:id:ty25148248:20220223182750p:plain

■ジャンル:組織論

■読破難易度:低~中(エンジニアリング業務に従事する方や経営学や組織行動学の知見があれば非常に読みやすいと思います。文章は非常に平易で、サクサク読めます。)

■対象者:・エンジニアリング業務に従事する方全般

    ・プロジェクトマネジメント・組織マネジメントに従事する方全般

    ・組織論のトレンドに興味関心のある方

 

 


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

【要約】

エンジニアリングとは不確実性を取り除いていく行為である」これが本書の大前提です。今回は組織論やエンジニアリングという行為の本質について論じたパート中心に要約します。アジャイル開発やリーン形式の開発の進め方について関心がある場合は本書を実際に手に取り読んでいただくことをオススメします。

 

■思考のリファクタリング

エンジニアリング組織不確実性を削減していくことで課題を解決することが組織目的です。組織構成員の不確実性への対処能力が低い際にはマイクロマネジメント型の組織を志向せざるを得ない特徴があります。逆に、自己裁量で行うことの出来る自立型組織を形成することが出来ると最も生産性が高いですが、プロジェクトメンバー全員に相応のスキルを必要とするという成立条件の難易度問題があります。

※現実にはプロジェクトメンバーのスキル・スタンスにはばらつきがあるので、スキルに依存しない仕組みを形成するように働きかけていくことがプロジェクトや組織をマネジメントしていく上では不可欠となります。スキルの至らなさを憂いても不確実性は一つも取り除かれません。

 

■演繹的思考・経験主義・仮説思考

論理的思考はビジネスの場では重宝されますが、これは極めて演繹的な思考法です。なので、不確実性が低く答えや方向性が一定に定まる場面でのみ有用であるという極めて場面限定的な思考フレームです。論理的思考の真価は「自分が非論理的≒感情的に物事を認識するタイミングを明らかにする所」にあると言います。レッテル貼りや結論の飛躍など人間が感情的な生き物であるが故に起きる認知の枠組みを是正する効果があるということです。

・上記不足に対抗する考え方として、「まずは経験をこなし経験から得た学びを基に行動していくべき」という経験主義「限られた情報から取り合えず結論を仮説立てして小さくPDCAを回していくべき」という仮説思考があります。仮説思考は今風に言うとリーン・スタートアップの思想の根幹をなします。

 

■システム思考(全体最適

「部分ではなく全体を見に行くことが大事であり、部分は相互に関係して全体に寄与する。」この前提に立って、不確実性を取り除くべく経験や情報から明晰していくことがマネジメントの基本となります。「要素の関係性から全体に掛かる法則を見出す」という思考プロセスがシステム思考で不確実性に向き合う際に必須の概念です。

・コミュニケーションの衝突のほとんどが部分から見た全体の情報把握不足による誤認です。そして、「論理的思考力は世の中的に重視されるが演繹的に類推できる範囲でしか論理は通用しない」という論理の限界性を理解したほうがいいというのが上記事象から導き出される教訓と言えます。

職業意識におけるアイデンティティの違いにより、各々の論理に忠実に自分の意見を主張することによる部門間の対立というのは良くある話ではないかと。

 

■開発組織の原理原則

プロジェクトマネジメントプロダクトマネジメントピープルマネジメントいずれも難しさの種類が異なるマネジメントです。

・ソフトウェア開発の工程は「設計と製造を同時にかつ一人の担い手が行う」という特質があります。昔は製造業のプロセス管理手法が使われ、実体に伴わず開発プロジェクトが炎上するということが多発していたようです。

・ソフトウェアは導入するハードにレバレッジをかけるものです。なので、ニーズに即した柔軟な開発が必要であり、リーン形式アジャイル開発などの手法が持ち込まれるようになりました。なので、エンジニアがデザイナーやサービス設計を担うことが多いです。

マネジメント対象物となる資源・資産を管理し、成果を最大化する行為です。プロジェクトマネジメント終わらないことが問題であり、プロダクトマネジメントプロダクトが終了してしまうことが問題です。

プロダクトマネジメントはプロダクトの価値を高める為に市場との対話を繰り返し、顧客要望に即した開発のサイクルをこなしていくことが必要になります。なので、プロダクトに関わる各々に当事者意識を持たせて成果コミットできるよう自己マスタリーを開発させていかないといけません。なので、メンバーマネジメントとしてもメンタリングの技法を用いて個々人のWILLを発芽させないといけないという話になります。

 

MBO⇒OKRへトレンドは変化

・長らくの間、ドラッカーが提唱したMBO(目標管理制度)が組織マネジメントの定石とされて来ました。MBO従業員個人の自発的な労働を喚起しようと意図した施策ですが、着想がどうしても部分最適になってしまう傾向があるので、内部組織の失敗を引き起こす温床になっているというのが最近の警笛です。

MBOに変わる形でITベンチャーなどで主に採用されているOKR全体最適システム思考の観点を盛り込んだ組織マネジメント制度です。OKR全社戦略などに関わる全体組織の成功に関わるような目的(Oを設定し、その目的(O)を達成する為の重要な結果指標(KR※部分組織に論拠したものでOK)を下部階層に設定することで、部分の仕事と全体の視点を繋げることを狙いとしたものです。

 

 

 

【所感】

・プロジェクトマネジメントに従事するようになり、全くパフォーマンス出せず辟易していた中で自分の物の見方・考え方が不味かったのだなと気づくことが出来、読めて本当によかったと思う本です。

・不確実性を取り除いていく行為が価値の高い行為である為、一見ごちゃごちゃしていて面倒そうな物事に敢えて首を突っ込んで、全体感を明らかにしたり命題を設定していくことに工数を割くことに気持ちをシフトしていかないといけないタイミングなのだなと自分の仕事のフォームを再考するきっかけになりました。※作業で成果出すマンはそろそろ限界だと漠然と認識していたのですが、それをしっかり言語化させてくれた本だと思っています。

・エンジニアやプロジェクトマネジャーがどのようなことに関心を持ち、彼ら彼女らの是とする価値観やルールを理解することが出来たのは、認知の枠組みを広げる体験となりとても良かったと思っています。○○マネジメントという仕事に何等か関わる人には心からオススメしたいなと思います。

 

以上となります!