$shibayu36->blog;

クラスター株式会社のソフトウェアエンジニアです。エンジニアリングや読書などについて書いています。

「ピープルウェア 第3版」読んだ

昔読んだけど、プロジェクトマネジメントや組織マネジメントをしてきた今だからこそもう一度読みたいなと思い、読んだ。

久々に読むとまた別のところに面白さを感じてよかった。特に「根本的に欠陥のある設計は、修正したりせずに、思い切りよく捨てて一から作り直したほうが結局はうまく行く」「早くヤレとせかされれば、雑な仕事をするだけで、質の高い仕事はしない」「エンドユーザーの要求をはるかに超えた品質水準は、生産性を上げる一つの手段である」「誰とチームを組んでいるか、が生産性向上の要因になっている」あたりが面白かった。

読書ノート

以下読書ノート。(「知的戦闘力を高める独学の技法」という本で気づきも合わせてメモすると良いと書いてあったのでやってみた)

  • 根本的に欠陥のある設計は、修正したりせずに、思い切りよく捨てて一から作り直したほうが結局はうまく行く 469
    • 気づき: 制度設計や形骸化したミーティングでも同じ。インクリメンタルに改善していると局所最適で無駄が多くなってしまう。一回捨てることで全体最適が出来る
  • 早くヤレとせかされれば、雑な仕事をするだけで、質の高い仕事はしない 706
    • 気づき: スケジュールは意欲の湧くものにする。
    • 気づき: 最終締め切りと、目標は別でも良い
  • エンドユーザーの要求をはるかに超えた品質水準は、生産性を上げる一つの手段である 770
    • 長い目で見れば、市場が必要としている程度に品質水準を合わせるとコストが増える
    • 開発者自身が満足する品質基準を決めることが生産性の向上につながり、品質を上げるためのコストを補って余りある 790
    • 気づき: リーンとDevOpsの科学でも、結局変更失敗率と変更速度は逆相関の関係では無かったと言っていたので、開発速度と品質がトレードオフという考えは直感では正しそうだけどそうでもないのだろう
  • 誰とチームを組んでいるか、が生産性向上の要因になっている 1248
    • パートナーの成績が良ければもう片方も成績が良く、そうでなければ逆の結果に
    • 気づき: デッドラインでも、別プロジェクトでチームとなっていた人をそのチームのまま他の部署にと書いてあったので、近いことを言ってそう
  • 仕事に取り組んだ時間の測り方を、フロー状態の時間をベースにしたものにする 1600
    • 連続して中断が入らなかったhour数で計測
    • E係数 = 中断なしの時間 / 机の前に座っていた時間で計測すると、最高0.38、最低0.10と大きな開きがあった
  • リーダーシップ:不言実行 2321
    • 気づき:経験則だが、とにかく言う前にやっていくというのは本当に大事
  • 人が入れ替わる際の全コストは、結局5ヶ月分の人件費ほどにもなる 2594

参考

昔読んだときの感想 「ピープルウェア」を読んだ - $shibayu36->blog;