デマルコ 大いに語る
デマルコ 大いに語る
ソフトウェア24の閃きと冴え
日科技連(1998)
ソフトウェア・プロジェクト
Tom DeMarco
★★★★★
「ピープルウエア」のデマルコのエッセイ集。PowerPCプロジェクトの担当プログラム・マネージャーであったシーラ・ブラディとの対談は必読である。デマルコの著作の中では本書を第一に勧める。
・ソフトウェア開発の作業の大部分は圧縮できない。圧縮されたスケジュールに対しては、まず無駄な作業を省こうとする。次に残業するようになる。最後には品質を犠牲にしてスケジュールを守ろうとする。このようなアプローチは数回の戦闘には勝てるかもしれないが戦争には勝てない。かつての米国の自動車産業のように。
・計測性機能不全の例(日立ソフトウェア・エンジニアリング)単体テストでの発見バグ数が多いほどシステムテストで多くのバグを発見しなければならないと言うプレッシャーから、開発者は単体テストのバグを隠すようになった。
・作業者にプロであることと、実績評価の単純な計測値表示も追及せよと両方を追求するのは無理である。
・自分たちの成功や失敗を分析しない本当の理由は「怖いから」。
・ソフトウェアプロジェクトの納期遅れは、生産性が低いことが問題とされるが、もっと妥当なスケジュールを設定することに焦点を当てなければいけない。
・大切なのは貴重な資源つまり時間の燃焼率を測ることである。プロジェクトの初期に稼いだ1週間は、大詰めの1週間と同じだけ大切である。
・人は失敗からの逃避として否認の態度を続ける場合がある。計測が高くついても割に合うのは、否認が始まる前に対応できるからだ。納期まであと3ヶ月になっても不具合発生率がこうだったらどうなるかと言う質問が出来る。
・残業は短距離走ではよいかもしれないがマラソンには向かない。
・たいていのソフトウエア技術者は、予定を達成するために残業するんじゃなくて、達成できないことをやましく感じないように残業している。
・一番下っ端の開発作業者が、日程遅れも品質不良もみな自分たち自身の落ち度になると知ったら、こう考えるしかない:どんな間違いだったらボスの落ち度になるのかな、と。
・出荷日が近づくにつれて仕事量の減る人が出てくる。納期前に全員まだ多くのやるべき作業があったとしたら、それは工程計画が全部間違っていたということである。
・過剰機能の例。部下の仕事までも何でも完璧にこなそうとする模範指導型管理職。本来マネージャーは触媒である。マネージャーの仕事のうち、やさしいほうは制御と調整に関係する。難しいほうは、動機づけ、調和、チームワーク、個人の成長、そして仕事に対する満足度のような人間的な配慮に関係する。模範指導型マネージャーにはとても手が回らないのが、この人間的側面なのである。
・「何か一つだけ手を打つとしたら」・・・4対1の確率で次が役に立つ。「部下に一度に一つの仕事だけをさせること」

