投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
私は文化展示イベントの制作をしており、本書の想定読者である、いわゆるIT業務従事者ではない。しかし、本書は大きな枠組みから問題を捉えることで、自分の思考、行動を考え直すことができる。
まず、様々な開発手法の思想的ルーツをたどることで、組織で働く限り、必ず発生する問題に対処する「真の教養」が得られる。
中でも納期の見積もりの話や組織構造はコミュニケーションコストの構造であることを指摘した点は示唆的だった。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
エンジニアマネージャーを目指す人は是非読むべき一冊だと思いました。ものを作り始める時にどれだけ最初の不確実なことをなくせるかが、進捗に遅れを出さずにプロジェクトをうまく回せるということが一番ひびきました。
ついやりやすいタスクから手をつけてしまいがちですが、なるべく難易度が高いようなタスクから手をつけようという考え方に変わりました。
また人と人との関係の重要性をうたっており、まさにその通りだとしみじみ感じました。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
プロジェクトマネージャ、プロダクトマネージャ必読の本!
エンジニアリングは不確実性を減らすこと。そして、そのために必要な事を心理学や社会学的な視点から解説しています。
技術的観点よりもマネジメント観点からの、経営、組織論です。
って表題がエンジニアリング組織論ですもんね(笑)
思考方法、メンタリング、アジャイル、技術的負債、組織設計、アーキテクチャなど、マネジメント視点で不確実性を減らすために必要なことが語られています。
自律的な人材、自律的なチーム、組織を作り上げるヒントが満載です。
ソフトウエアをマネジメントする人や組織を管理する人が読んできたであろう複数の本の内容がこの一冊にコンパクトにまとまっています。
しかし、残念ながら、文章構成がイマイチで、全体的にまとまりがありません。(というかストーリが感じられません)
なので、最終章は尻切れで終わってしまった感じです。
まとめとか、ないの?
そんなわけで、★ひとつマイナスですが、良書であるのは間違いなし。
何度も読み返すべき本だと思います。
お勧め!!
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
説明損益計算書ベースでの運営に偏りがちなネットベンチャーに対する貸借対照表ベースでのマネジメント論。
技術的負債の話はエンジニア内でもよく出るが、顧客資産に関わる話をしてるのは、エンジニア本でもこれが最初ではないでしょうか?
エンジニアの楽園を作ることが狙いに見えるエンジニアキャリア本が多い中で、この本だけはエンジニアとしての事業に対しての当事者性に基づいて書かれていて、それだけで評価5です。
ちなみに、これに近いのが『仕事の説明書〜あなたは今どんなゲームをしているのか』です。ただし、パッと見、組織論からはちょっと離れますが、これもテクノロジーを利用した事業をやっている会社にとっては、組織論だと思います。
マネジメントというと、最初にヒューマンに行きがちですが、定性的なものは、実はデザイナーの方が得意かもしれません。
ただし、早すぎるテクノロジービジネスにおいては、これらの本に書かれている、数字の『設計』の理解は外せません。何故なら、コンピュータは、数字でコントロールするのですから、エンジニアはコンピュータで扱う数字の設計が外せません。
これを読めば、エンジニアの楽園を作ることを目的にしたマネジメントが長期的に如何に詰みやすいか逆に見えてくると思います。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
不確実性にどう対処していくかの問題が、様々な視点から語られている。エンジニアじゃない人が読んだほうが良い気がしている。各々のトピックが発散していて少々まとまりに欠けるが、それもまた面白い。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
# 書評☆2 エンジニアリング組織論への招待 | 不確実性の取扱には確かな裏付けのある方法で対応すべきだろう
## 概要
[ITエンジニア本大賞2019](https://www.shoeisha.co.jp/campaign/award/2019/result/)の技術書部門の大賞に選ばれていることに興味を持って読んだ。
ちなみに,ビジネス書部門の大賞の「[イシューからはじめよ](https://senooken.jp/blog/2019/04/02/)」も読破し,書評を付けている。
エンジニアリングを使った製品開発をしている企業の組織論が述べられている。IT企業を念頭に置かれているように感じたが,抽象度が高かったので,一般企業にも通用する部分は多かった。
表紙にもあるように,組織での失敗は,不確実性の取扱にあるとして,思考方法,コミュニケーション,マネジメントについて考察されていた。
ただし,自分にとっては*あまり有用ではなかった*。理由は,大部分が著者の考えだけに依るものだからだ。一部,申し訳程度にデータの引用や他書の引用はある。しかし,本書の大部分はあくまで著者の考えに過ぎない。学術的な理論や根拠に基づいているものではない。そういう意味で,あまり信頼できないと思った。
また,内容がけっこう抽象的で,一般社員が活用できるような内容ではなかった。せいぜいリーダークラスが最後のマネジメントの部分を参考にできるかもしれないという感じだった。
特に,コミュニケーションの部分に関しては,本書よりも「[人を助けるとはどういうことか](https://senooken.jp/blog/2019/02/25/)」を読んだほうが効果的だと感じた。
不確実性の取扱が重要とあるのだから,対処方法も**著者の考えだけでなく,裏付けのあるより確実性の高い方法で対処すべきだろう**。
## 結論
書籍のレイアウトはきれいに組版されており,内容にしては比較的読みやすかった。ただし,その肝心の内容が,いかにもコンサルタントや意識高い系の人間が好きそうな小難しくて,一見もっともらしそうなことがだらだらと書き連ねられている。
これらの内容に,学術的な根拠や裏付けがあるならばまだよかった。しかし実際はあくまで著者の考えに過ぎない。著者を信頼できるならば,意味はあるかもしれないが,そうでなければあまり有用ではないと感じた。
ネット上で*過大評価*されていると感じた。どこぞのよくわからん人間に新しく書かれたそれらしい意見よりも,多少古くてもしかるべき人間に書かれた信頼できる情報を当たったほうがよいと感じた。
パーマリンク: https://senooken.jp/blog/2019/05/01/
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
より良いアーキテクチャで品質の高いコードを書くには、人々の思考・組織・ビジネスの構造こそリファクタリングすべし。問題の根源は不確実性。メンタリングで自立したメンバーを育て、アジャイルな状態のチームをつくり、マネジメントで不確実性を最も効率よく削減せよ。
研究者の実験や分析より、現場の経験の方が勝るはず。論理化・言語化できれば。そんな人材がいた組織だから成長したんだ。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
第6回ブクログ大賞
ビジネス書部門受賞
「不確実性」をメインテーマとした本書が、
話題になったビジネス書たちを押しのけ大賞を受賞!
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
不確実性に対応する方法
将来
方法不確実性
目的不確実性
経験主義、仮説思考
他人
情報の非対称性
限定合理性
コミュニケーション
コントロールできることとできないことを分けて考える
観測できないことは変えられない
他人の内面など
リアルオプション
仮説を検証しながら徐々に進める
傾聴、可視化、リフレーミング
自己説得
ラーニングゾーン
心理的安全性と責任
承認
存在承認
行動承認
結果承認
ストーリーテリング
自己開示
感情の共有
価値観の共有
返報性の原理
SMART
具体的
計測可能
到達可能
関連性
時間制限
アジャイル
不確実性に対応できている状態
タスク管理
不確実性を考慮
相対的なボリュームで管理
プラニングポーカー
タスク消化率
ベロシティ
統計的に計測
最悪、最善
リーンキャンパス
顧客の課題
顧客セグメント
独自価値
解決策
チャネル
収益の流れ
コスト構造
測定項目
競合優位性
振り返り
ゴール再認識
現状整理
良かった点
問題洗い出し
問題深堀り
対策策定
組織
権限移譲と期待値確認
組織、コミュニケーション、外部リソース調達の設計
ゴール設定と透明感の確保
技術負債の見える化
権限移譲レベル
命令する
説得する
なぜやるのか
相談する
合意する
上司と部下の権限レベルが同じ
助言する
尋ねる
委任する
上司への確認なしに実施できる
技術負債
理想のシステム状態に対す機能追加工数と現状脳内システムに対する機能追加工数の差
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
エンジニアリング、組織、開発手法、アーキテクチャに関する様々な問題、現代の考え方をまとめている本です。
具体的な手法が載っているわけではなく、「こうして軋轢・不和が起こる」「なぜそれが起こるのか」「解決されるために取り入れる考え方」ということを、これでもかというくらい詳しく紹介しています。
とにかく話題が豊富で、それぞれの用語や考え方をひたすら掘り下げているので、あくまで「納得する」ための本であって、これを有効に活用して具体的に…というものではありません。
・いいところ
現代のシステム開発に関わる考え方を、(著者の考える)背景も含めて理解することができます。
説明もかなり平易で、スラスラと読むことができます。
歴史的背景、著名な考え方・発言などを紹介してくれるため、単なる筆者の思い込みではなく、裏付けを元に理解することができます。
・悪いところ
話題が豊富すぎるため、節の単位で頻繁に話題が変わり、最後にまとめとしてそれらが繋がっている…気がするのですが、あまりに話題が豊富なので置いていかれるかもしれません。きっと著者は相当頭がいいのだと思いますが、それぞれの節を結びつけて思考を理解するのはとても大変…というか私には無理でした。従って、断片的にパーツ(節)ごとに理解はできるのですが、「結局どういうこと…?」と置いていかれるかもしれません。
どの用語につけても、定義や背景をひたすら掘り下げていくので、説明によっては冗長と感じるかもしれません。また、歴史的背景などとの結びつけを、あくまで著者の考えを元に行っているため、「そう考えるとうまくいく」のであって、話題によっては強引なこじつけと感じるかもしれません。
全体的には、一度は読んでおくとシステムやサービス、組織が生じる歪みを理解できるようになるためおすすめです。ただ、この本全体を通して全てを"一貫して"理解するのは相当至難の業だと思います。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
不確実性を減らし情報処理能力を上げるための手法論が網羅的にまとめられている。個人的に刺さったのはコミュニケーションが「情報の非対称性」を解消するためのものだという話。巻末に参考文献一覧のリストがほしかった
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
「情報の非対称性」を軸に昨今のソフトウェア開発現場や組織に横たわる課題を紐解いていく、と雑にまとめ。
個人的には非常に漠然と感じていたことを整理してくれた感じでスッキリしました。
かねてより、自分が進化生態学を専門としていたことはこの業種の理解に相当役立っていると感じていたけど、それは偶然ではなくて必然でもあるのだなー、と。
一方、読んでしまったからにはこれを活かさなければ、という思いも持ったのでした。ひとまず、同じように読んだ人、同僚と対話してみたい。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
2018に賞などで評価されていたのが気になって積んでおいたのをようやく読んだ。
エンジニアリングを不確実性の削減であると位置づけてどのように活動し組織を作り運営すべきかを著者の主観を交えながら説く。
個人や育成観点の1,2章は特に目新しい知見はなかったが、不確実性という軸を持って整理されているので読みやすい。
3章のアジャイルについてはきちんと勉強したことがなかったので単なる開発手法ではなく、思想や経営に近いものとして捉えている点や歴史的な経緯も面白い。意思決定の先送りのメリットについても正しく理解できていなかったことがわかり勉強にもなった。
ただ全体として章間の繋がりがわかりにくく大きな流れが見えないので、4章のチームやスケジュールマネジメントは浮いているように見えるし、5章の組織の話題は急に大きくなったように見える。ところどころ冗長で論旨が見えなくなるところもある。
個人としては所謂SIer側の人間なので、限定合理性の発揮されやすい環境でどこまで顧客や上位層を巻き込めば組織的に実践できるのかイメージがつかないなあ。個人の視座に不確実性の削減の意識を追加するのが当面の取り組みか。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
まさにこういう本を求めていた。
ビジネス書と技術書の中間的な内容で、現場のエンジニアはもちろん、開発組織に関わるマネジメント層はもれなく読んで損はないと思う。
個人的には、特に技術的負債やアジャイルの話が参考になった。
数は多くないものの、数式を用いた説明もあるので、アレルギーある方は注意が必要かも。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
プロジェクトは、不確実性を有しており、その不確実性をどのように減らすかがマネジメントの醍醐味であると思う。
一つの解は、自律型組織を作ることである。各自が、プロジェクトの成功に必要なことを、自ら行動していけば、自ずと良い結果が生まれる。ただし、①チームを組む以上、自律的に行動できる人ばかりを集められるというのはほとんどない。自律的に行動できない人に対してはマイクロマネジメントをするのだが、将来的には自律できるように配慮することが必要である。②もちろん役割を分けることも効率的ではあるが、限定合理性が生まれ、ポテンヒットが生まれる。この点でもプロジェクト全体を見渡して動ける自律型人材が必要である。
エンジニアリングとは、「役に立つものを生み出す」ことである。役に立つという曖昧な言葉は、つまり不確実なことであるという意味になる。
▼人生観
怒っている人は、何に対して怒っているのかを知るべし。なぜなら、怒っている理由こそ、その人が大切に考えていることだから。
新入社員の能力やモチベーションはコントロールできないが、指示の出し方や行動のフィードバックはコントロールできる。コントロールできることに目を向けるべき。
クードエイドを飲むなという用語は、誰かの思想信条を無批判に受け入れるなということである。