伊豆原弓のレビュー一覧
-
-
Posted by ブクログ
ネタバレ最強に面白いし、怖い。
「偉大な企業はすべて正しく行うが故に失敗する」
主要顧客や株主の期待に応えて高利益率の製品を提供し続けてるうちに、全く異なる指標で評価される市場で生まれる利益率が低い製品にいつのまにか代替される。
最近だと地銀の勘定系システムのクラウド移行が例かな。
勘定系の評価軸は信頼性や性能。メインフレームが主に利用される。
ただ、スケールや管理の容易さで評価されるシステムにてクラウドが導入され始め、徐々に勘定系システムで要求される信頼性や性能を満たすようになり、メインフレームを代替。
メインフレームを提供する企業は持続的イノベーションを加速
→異なる指標で評価されるローエンド -
-
Posted by ブクログ
ソフトウェア開発をやっているとほとんどのパターンに見覚えを感じる。
特に印象深いパターンは
・マニャーナ：スケジュールの期限が長すぎると切迫感が無く仕事が進まない
・幸福礼賛会議：士気が高いように見せることが、個人の成績評価を大きく左右する
・ベンチに人なし：組織をスリム化しすぎて、重要なメンバーが一人欠けたら破綻する
など。他のパターンもとても風刺が効いている。
この本を読んでからは、
「あのチームは幸福礼賛会議の匂いがする」
「このスケジュールの切り方だとマニャーナに陥るかもしれない」
などと、パターン名で状況を振り返ることができやすくなった。 -
Posted by ブクログ
小説仕立てで臨場感を感じる。
喩えで感心したのは、自分の評価だけを気にする人はチームにいらないって喩え。どんなに個人として優れていてもチームを優先させない人とは働けない。そこは譲れない一線。
信頼の欠如＜完全無欠
衝突の恐怖＜表面的な調和
責任感の不足＜あいまいな態度
説明責任の回避＜基準の低さ
結果への無関心＜地位と自尊心
チームになっていない初期段階で、読みながらドキドキしたのは、チームの責任をとろうとしていない との指摘。自分の部署の内容には干渉しない。でも、自分の部署のことだけでは、チームではないという指摘。
もう一つ感心したのは、このプロセスがアップダウンがあり、必ずしも順調に -
-
Posted by ブクログ
ネタバレ小説仕立てで、チームを機能させる方法を説く。
完全に機能しているチームなんて世の中でごくわずかなので、誰が読んでも参考になる部分があるはずだ。
本書で述べてる概論は、すべて帯に集約されている。この帯書いた人えらい。
・信頼の欠如（意見は一致してないのに、議論が起きない）
・衝突への恐怖（不満があっても、会議で意見を言わない）
・責任感の不足（決定したことでも、きちんと支持しない）
・説明責任の回避（衝突を避けて、互いの説明を求めない）
・結果への無責任（各自の仕事にかまけて全体を見ない）
個人的には、説明責任への回避は、かなり難しいテーマだと思った。自分の横のメンバーに対して注意をするのは -
-
-
-
Posted by ブクログ
ネタバレソフトウェアの開発組織に見られるパターンを、良いパターン、悪いパターン含めて小粋なタイトルで類型化。業務改善するにも、まずは現状を正確に把握することが大事なので、ソフトウェア開発以外でもチームで作業している業務の方なら何らかの気付きが得られるんじゃないでせうか。
例えば、一つ目のパターン、"アドレナリンジャンキー"。
「次から次へと緊急のプロジェクトがやってくる。誰もが猛烈に忙しい。それも、いつも。...多くのアドレナリン中毒組織は、何かにつけ顧客サービス倫理を持ちだす。切迫した事態に対応することを、みごとな機動力と勘違いしているのだ。...これこそがアジャイルと思って -
-
-
-
-
-
-
-
Posted by ブクログ
ネタバレ買ってつんどくでした。
次に読んだときは，１０１の法則は読み飛ばしていました。
3度目に書評を書こうと思って読んだら、予想以上に面白かった。
最初の失業する人を、スパイが掠うという設定から度肝を抜かれました。
最後に幸せになる（ハッピイエンドな）ところがすごくよかったと思いました。
ソフトウェア開発者が幸せになるための一つの筋書きとして面白いと思います。
教訓はあくまでも読み取るもので、教えてもらうものではないかもしれません。
作業書（ワークブック）形式にして，経験だけ書いて，
教訓を各自で考えてみる形式にすると面白いかもしれません。
その後で，著者の教訓とのずれの原 -