上司の薦めで、ピープルウェアを読んでみました。ここ最近、自分が問題意識をもっていたことと重なることが多く、得るものが多かったです!

ソフトウェア開発における生産性についての本ですが、違う業種や、趣味での活動でもあてはまることは多くあると思います。むしろ、IT関係以外の方にこそ、読んでもらいたいくらいです。

ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである

冒頭に書いてあるこの言葉が、響きました！
自分が新人の頃はもっと技術があればとは思ったのですが、ここ最近は、技術レベル以前のところで躓いているのでは感じるようになったので、やはりそういうことだったかと。

エンドユーザの要求をはるかに超えた品質水準は、生産性を上げる一つの手段である

一見すると、品質を追求しないで手抜きをした方が作業時間も短く、動くもの程度であればたくさんつくれるような気もしますが、そのスタンスでやってその後のバグで手痛い目に合うことも何度かあり。。。

本の中では、「今の段階だと、MTBFは1.2時間で非常に不安定だが、3週間後には2000時間とかなり良くなる」という例が出ます。早期のリリースを優先するあまり、低品質な製品をユーザは受け入れてしまっているということのようです。更にいえば、ユーザと開発者では必要とする品質に大きな差があり、ユーザの水準にあわせると、長期的にはコストが増えてしまうということ。

ユーザから見れば、極悪なスパゲティコードであっても要求する機能が満たされていればOKですが、開発者からすれば、要求機能を満たした上でコードの品質も追求する、ということでしょうか。最近なら、git管理の品質も加わって、コミットコメントやコミット粒度をどうするか、というのもあるでしょう。

もっと、開発者側の水準がもたらすものを重要視するような流れが増して欲しいものです。

チーム形成の不思議な化学反応

• 品質至上主義
• 満足感を与える打ち上げ
• エリート感覚の醸成
• チームに異分子を混ぜることの奨励
• 成功しているチームを守り、維持
• 戦術でなく戦略を与える

自分がいる合唱団に、この7つそれぞれにあてはまるかなと思うものがあり、この辺がうまくいく要因なのかと。

チーム殺し、7つの秘訣

• 守りのマネジメント
• 官僚主義
• 作業場所の分散
• 時間の分断
• 製品の品質削減
• はったりの納期
• チーム解体の方針

チーム殺しにつながる、残業の予期しない副作用

がんばって残業できる人と、そうはできない人の、ある種の二つの派閥ができてしまい、その状態が長引くことで、残業しまっくてる人たちが、私生活の乱れからのストレス増加や、残業できない人達を疎遠に感じるようになったりして、チームに亀裂が入るという...

我々はなんと悲しい生き物なのだろうか。

気になったキーワード

• 会社のルーチンワークは、就業時間に見合うところまで膨張する傾向がある
• エントロピーは組織内では常に増加する
• メソドロジーの愚かさ
• 悪意の追従
• リスクから逃げない
• よりよい変化のモデル
• 眠れる巨人よ、目を覚ませ

参考サイト