進捗管理と開発者のやる気:『ピープルウェア(第2版)』を読んで
さて、早速ずいぶんエントリをサボってしまった。とりあえず最近読んだ本をベースに書いておこう。
『ピープルウェア』は人月の神話と並びソフトウェア開発管理の古典。それまで、というか今でも管理、マネジメントというと(EVMの手法を中心とした)ハードな管理、きっちりとした計画を立ててそれをどれだけ遵守するかに重点を置いたものが主流となっている。これに対して「開発者がやる気を持って取り組める環境作りをするほうが、ハードな管理で開発者を絞り上げ進捗をあげさせるよりも生産性が高い」ということを謳ったのが本書ということになるだろう。
ざっくり言うと、以下のようにしていれば上手くいくよというのが概要。
- 開発者に過度な進捗管理によりプレッシャーをかけない
- 進捗(納期・コスト)を重視して品質を妥協させない
- 開発者が集中出来る環境を提供する(パーティションで区切られたデスク、電話などでの中断が入らない環境)
- 退職させない(人員の入れ替えによるコストは大きい)
- 自分たちは「エリートチーム」だという認識を持たせる
我々は進捗管理を捨てるべきなのか?
上記は至極尤もな内容だと思う。ソフトウェア開発というのは人により、また人の状況により生産性が大きく違ってくる作業である。だからこそ「スーパーエンジニア」と呼ばれるような人々が存在している。であれば彼らが働きやすい環境を整え、やる気を出させる状態を作れば「生産性」という意味ではハッピーだろう。
しかしビジネスでやっている以上、プロジェクトマネージャは日々の進捗をシニアマネージャ、またはクライアントに報告せなばならない。しかもそこで唯一の正義を持っているのは、絶対的な「生産性」ではなく、計画値に対する実績、すなわち「進捗」だ。
これがついて回る限り進捗管理をせざるを得ない、しかしそのためには開発者に余計な時間を使わせ、作業を中断させ、彼らのやる気を削ぐことになってしまう。
我々は進捗管理を捨てるべきなのか?クライアントには「うちのスーパーエンジニアが超やる気で頑張ってますんでとにかく待っててください」というべきなのか?
ITは何のために存在するのか
もちろん、先の問いへの答えはNOだろう。それは常識的にもそう(言わざるをえない)なのだが、より合理的に答えるためには「ITが何のために存在するのか」を考えるべきだろう。
ITはビジネスのためにあるのだ。ソフトウェアがいくら生産的に(=効率よく)出来上がったとしても、それが使われるビジネスに合わせて出来なければ意味が無い。
例えばSCMシステムであればそれを使用する販売・購買・ロジスティクスのユーザらがそれをいつから使えるかを認識して、そのときのために準備をしておく必要があるだろう。それをソフトウェア開発側が「いつ出来るかわかりません」といわれたら、ビジネス側はいつまでに何をどう準備したら良いかが分からない。なんだかよく分からないまま待たされ、そのうちいきなり「出来たんで使ってください」と言われる。これではなんのためのITかが分からない。
では、どのように進捗を把握すれば良いのか?
僕が本書を読んだ限り、「ではどうすればいいの?」という部分への解には言及されていなかった。(というより、「進捗管理はしなくていい」という答えなのだろう。したがって、そもそも前提としている状況が異なるのかも知れない。)
つまらない回答としては、できるだけ開発者の時間を無駄にせずに(儀式的な定例進捗会議などを止め、必要に応じて進捗を確認するなど?)最小限の管理を行うこと、ということになるのだろう。しかし、つまらない。
僕は、ここにこそITが価値を発揮する機会がまだ潜んでいるように思う。開発者はひたすら集中して開発を行っていれば、自動的に進捗が可視化される仕組み。こういったものを実現できれば開発者と管理者の双方にとってハッピーな状況が作り出せるのではないだろうか。
- 作者: トム・デマルコ,ティモシー・リスター,松原友夫,山浦恒央
- 出版社/メーカー: 日経BP社
- 発売日: 2013/12/18
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (3件) を見る