投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
1章は退屈、難しい。
5章は、IT業界で仕事をするものにとって、納得、理解できとても参考になった。まさしく自分の考えや経験のリエンジニアリングができた感じ。
2章も中々興味深い内容。
全章再読中。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
ITとエンジニアがビジネスに貢献するために考慮すべき観点・課題が経営論や著者の経験から生まれた教訓の観点からまとまっている。ITに携わる方にはオススメしたい本
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
企業の組織構造と技術アーキテクチャの相関性など、この2分野をリンクして語る本は他に見当たらない気がして貴重。
興味を引くぶんナレッジが凝縮されているが、ちょっと深堀りするには他の書籍を読むなども必要。
実際に著者の講演を聴く機会があったので、その際おすすめしてもらったのは「ビジネススクールでは学べない世界最先端の経営学」
組織論について確かに参考になる話が多い。(読書中)
投稿元:![ブクログ](//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)
レビューを見る
不確実性は時間的不確実性と通信不確実性の2種類
この本は身の回りから会社全体まで規模を少しずつ大きくしながら不確実性とどのように向き合っていくかを説明していく
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
全く予想してなかった思ったよりアカデミック寄りでした。でも全てを不確実性と向き合うためと考えるのはとても腑に落ちる。やはりマーケット不安重視のプロダクト向き組織とスケジュール不安重視のプロジェクト向きに組織での差が納得できた。興味があるセクションとあまり参考にならないセクションの差が激しかったものの読んで良かった。参考になった。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
しっくりきました。めちゃくちゃ参考になりました。
本のタイトルに「組織論」とありますが、実際には「ソフトウェア開発における不確実性がもたらす問題と、その対処方法」について書かれた本だと思います。「組織論」としてまとめられているのは、デマルコの「ソフトウェア開発における問題のほとんどは技術的なものではなく社会学的なものである」という考えや、コンウェイの法則という「ソフトウェアは開発する組織の状態に依存する」という考えがベースになっているからのようです。つまり、良い組織であればソフトウェア開発もうまくいくし、組織に何らかの問題があればプロダクトにもひずみが出る、ってことです。プロマネ(プロジェクトマネジメント、プロダクトマネジメント)やアジャイル開発、チームビルディングに興味がある人には、きっと役立ちます。
メンタリングやアジャイルなど、書いてある視点が多様すぎて、一見何について書かれた本か理解しにくいかもしれません。また、この本では、章ごとに、個人→ペア→チーム→組織の順で、不確実性による問題点が書かれているのですが、この、組織論でありながら個人や一対一のペアの話から組み立てられた章立てが、少しとっつきにくくしているところがあると思います。ただ、チームや組織の問題を理解するため必要な流れになっていて、最後まで読むことで、すっきりと全体を理解できると思います。(ですので飛ばさずに順を追って読むことをおすすめします)
簡単に要約です。
ソフトウェア開発における不確実性とは、なんのことでしょうか?不確実性は大別すると「未来のことがわからない」と「他人のことがわからない」の2つに分けられます。そして不確実性は、情報を生み出すことで潰すことができます。
前者の未来に対しては、経験主義・仮説主導をベースに行動から情報を得ていくことが必要とされます。論理的思考には盲点がありそれだけでは足りたないとされます。またシステム思考で全体を俯瞰し、問題を正しく認識しないといけません。
後者の他人に対してはコミュニケーションを取ることが求められます。ただそこには、情報の非対称性と、それによる限定合理性が働くため、簡単にはうまく行きません。
・・・と、ここまでが第一章の内容で、個人の思考を変える必要性が説かれています。そしてこの考えがベースとなり、他者へのメンタリング、アジャイル、組織論へと段々と領域を広げて話が展開していきます。
エンジニアに限らず他職種の人にも役立つと思います。興味持たれた方はぜひ。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
不確実性マネジメントについて拾い読みした。学びはあったが、出典が明記されていないため著者の意見と一般的な話の見分けがつかないこと、他の文献を読んでの学習が難しいことがマイナス。
スケジュールの最善ケースと最悪ケースの幅が、スケジュール不確実性である。このスケジュール幅を可視化して効率よく削減していくことが重要。最後になって初めて幅が大きいと分かるのが最悪。
多点見積もりから求められる不安量=見積もり偏差が大きいタスクから順に問題解決することで、スケジュール不安を早期に減らすことができる。
不安量の大きいタスクを、不安量の小さいタスクに分解することで、不安量を減らしたり、不安部分のみを切り出して先に対処するなどの対策が打てるようになる。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
1.思考のリファクタリング
エンジニアリングとは不確実性を減らし、物事を実現すること
不確実性(エントロピー)が下がる=情報を得ること
→情報を生み出す仕組みが大事!
人は事実を正しく認知できないという前提に立つ
経験主義はわからないを行動に変換し、一歩でも早く正解にたどり着く思考の補助線
遅延した意思決定=小さく失敗し、成功確率が上がるまで巨額の投資判断は行わない
資産を微分して利益、
利益を微分してビジネスモデル
という流れの中で無形資産をコストと見なしてカットしてはいけない=局所最適になる恐れがある
2.メンタリング
高い目標が認知フレームを広げる
4.学習するチームと不確実性マネジメント
スケジュールマネジメントは制約スラックを削減すること
制約スラックはリソース制約(属人化)と依存制約(クリティカルパス)がある
投稿元:![ブクログ](//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)
レビューを見る
開発組織特有の組織論かと思いきや、「組織論」をエンジニア目線で解いて(説いて)みました、という感じの技術者もスッと理解しやすい組織論のお話。
それでいて、昨今のキーワード(心理的安全性・システム思考など)を網羅しながら、個人・1on1・チーム・組織という複数レイヤーの課題に章立てでフォーカスしてくれるという離れ業を成している愛すべき良書。
一つで一冊本が出版されているぐらいのキーワードがわんさか出てくるので、それぞれが概要説明にとどまっている部分は、読者によって評価が分かれるだと思う。が、わからないところは調べながら読める私はむしろ推す!!
本文は下記の内容から始まる。
・エンジニアリングとは「不確実性を効率よく削減していくこと」であり、「不確実性を減少させる知識」のことを「情報」と定義できる。
もうここで、新しい視点で仕事を見直せるかも、というワクワク感がある(笑
・・・不確実性を製品開発で考えてみると、企画という初期段階では企画書は曖昧さが多く残るが、開発過程で情報(市場調査結果・仕様書・設計書・試験結果・分析結果)を生成することで、最終的なアウトプットである設計情報(図面)では不確実性がかなり低くなって創作される。って感じ。
本書では不確実性に対する様々なアプローチ方法が載っているが、共通していると感じたのは、多くのケースで問題は表面的な点(モノ、コト、ヒト)として認識されるが、本質の原因は線(人の関係性、プロセス、システム)を把握しないと見えてこない、という点。線を把握し上で、レバレッジが効くところにアプローチしないとモグラ叩きを永遠とやり続けることになる、と思った。
また、セクショナリズムがただの縄張り争いではなく、情報の非対称性と限定合理性によって暴かれるところはすごく納得した。ここでもシステム思考によって局所最適同士の対立が解決するとされている。
一方で、現実的な問題として現場の人間に「全体把握せーよ」は限界があると思う。なので、自分の手から離れた先も学習視野の範囲でフィードバック機構を働かせることが肝要だと思う。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
何度か読み返さないと知識を行動に変換するに至らない気がする
ただ、内容はめちゃくちゃ良書なので、ちゃんと物理本で読めば良かった
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
エンジニアリングに関する組織論、思考法、マネジメント視点で書かれた本書は、なぜ開発がうまくいかないか、その不確実性について論理立てて構成して書いてある。
一度読むだけでは本書はなかなか身につかず、経験をしながら都度参考にする良書。
著者の経験とインプット量を想像した上で、本書は再読の価値があり、自分なりに思考するのに非常に適した本。