システム開発現場でトラブルを招く要因とは・・・

今日は、システム開発現場での話ですが、

ご承知のように、システム（ソフトウェアの）開発っていうのはよくトラブルを起こします。
納期遅延は元より、バグだらけだったり、何とも使いづらく役立たずだったりと、まぁ多々あるわけです。

よくあるトラブルの原因の一つに、
3～4人程度の体制でやっている小さなプロジェクトでは至って優秀な結果を残してきたリーダーに、ならばということで、10人規模の中規模開発プロジェクトを任せてみると、不思議と大方が失敗します。

失敗する原因は、要するに3～4人で行う小規模な開発プロジェクトと、
10人で行う中規模な開発プロジェクトとでは、リーダーに要求される能力の根本が違うからです。

私自身、プロジェクトのマネージャーとして、現場のリーダーを束ねる
役目というのを経験してきた中で、これまでにそうしたリーダーを何人も見てきました。

では、どうしてこうなるか？というと、

例えば、3人体制の（リーダー1人に若手ＰＧ2名といった）プロジェクト
の場合よくあることですが、経験のまだ浅い2ー3年目の若手のプログラマーが、

単体テストの段階で使い物にならないようなプログラムを組んでしまっていることが発覚して、「これじゃー最初から作り直しだ～！」ということが必ずと言っていいほど起こります。

その若手は、とりあえずドキュメント書きとか、テスターとかの雑用係りに回して、リーダー自身が（リーダーの責任で）、自身が3日くらい徹夜をして、その若手が担当したプログラムを代わりに一から作り直して完成させます。

まぁ若手が担当して1ヶ月や2ヶ月で作れるようなプログラムであれば、
小規模でも部下のいるプロジェクトを任されるリーダーであれば、大概は
2－3日もあれば完成させる実力は持っているものです。

最悪、若手の部下の2人ともがダメなプログラマーであったとしても、
リーダー1人が1週間も徹夜をすれば、、といった力業（ちからわざ）で
なんとかプロジェクトは収まるわけです。

実際にこの私も、その昔現場のリーダーだった頃には、この方法で難を切り抜けてきたという経験は、1度や2度ではありませんし、小規模なプロジェクトのリーダー経験者であれば、必ずと言っていいほどこれは誰でも経験していることだと思います。

で、問題は、そうして表向きは失敗なしでやってきたリーダーに、ならばということで10人規模の少々大きめなプロジェクトを任せることになったという場合に起きるわけです。

さすがに、10人規模ともなると、先ほど言ったリーダー1人の力業によるリカバリーというのはできませんし、メンバーの人数が多ければ当然それだけ管理のほうが大変で手一杯となってきますから、

この規模になるとリーダー自身がプログラミングをするということは余りなくなり、管理に徹するということとなりますので、今度はその管理能力が問われるようなるわけです。

3人程度のプロジェクトの時は、管理なんて殆どしなくても、自分のプログラミング力によって担当プロジェクトを成功させることが出来てきたリーダーにとっては、それは初めてともいえる仕事になるわけですから、、

なので、当然ながらここで失敗するリーダーというのは非常に多いわけです。

私の経験で言うとですが、配下のプロジェクトが（リーダーが）失敗するか成功するかは、最初にそのプロジェクトの進捗会議に参加して、各メンバーからの進捗報告を会議室の隅で黙って聞いて様子見ていれば、開始初期の段階からすぐに見分けが付いて判断はできるものです。

なぜそれができるのかと言うと、

一つの判断基準として、ダメなリーダーの催す進捗会議では、決まってメンバー達は「順調です。」または「少々遅れ気味です。」と言った報告をしています。

プロジェクト管理の基本中の基本としてよく知られるのが「定量的な報告を・・・」ということになるわけですが、それすら分かっていないというリーダーなわけですから、これは論外です。

だから、端から失敗するであろうことは、明白なんです。

で、もう少しはマシなリーダーになると、
「現在、進捗○○パーセントです。」といった報告をさせていますが、実は
ここが一番の落ち度が高い所（重要なポイント）です。

○○パーセントの○○の算出方法というのが非常に重要な事項であるにも関わらず、ただメンバーの感覚で言わせているケースというのが実に多いわけです。

そうなると、よくある話なんですが、例えば

プログラム作成＆単体テストで4週間の工程を組んでいるプロジェクトがあったとして、通常、毎週週一で進捗会議を開いてメンバー各人の進捗報告
をさせるのが一般的ですが、

最初の1週間目の進捗会議であるメンバーが、「現在の進捗は50％です。」
と報告したとします。4週間の作業なので、1週間で既に50％ということは、
概ね予定の倍のスピードで進んでいるということを意味します。

とまぁ、本当に優秀なプログラマーであれば、これは大変よくある話です。
（当初の線表の（計画の）ミスは指摘されてしかるべきではあります、、）

で、翌週の2週間目にそのメンバーは、「現在の進捗80％」と報告するわけです。4週間の半分で既に80％ならば、リーダーはそれは順調だねと褒め、安心する（安心してしまう）わけです。

で、翌週の3週間目、そのメンバーは、「現在の進捗95％」と報告します。
更に、翌週の4週間目（終了間際）、そのメンバーはまた「95％」だと言います。

そうして結局、このメンバーの作業は遅延を起こすということになるわけです。1週間で（最初の1/4の時間で）半分の50％の作業が既に終わっていた（予定の2倍のスピードで進んでいた）にも係わらず、、です。

これは決してただの笑い話ではなく、開発現場で度々繰り返される典型的な
失敗の例なのです。

振り返ってみてみると、このメンバーの各週毎の進捗具合というのは、50％、30％、15％、0％、となって推移していましたので、明らかに鈍化の一途を辿っています。

（最後の4週目に至っては進捗0％なのですから、「お前、この1週間なにもしていなかったのか！」と、リーダーからの怒号が飛んでしかるべき事態です。）

当初、50％進んでいたものが、次は30％にまで落込んだことにリーダーならまずもって気が付かなければならないというのは当然の話なんですが、80％という数字にとらわれて、それに気が付かないダメなリーダーが実に多いというのが開発現場の実態かと思います。

これは、何が原因かといえば、やはり定量的な進捗管理というのができていないからなわけです。メンバーの感覚だけで言う「進捗率何％です。」という報告には何の意味もありません。

定量的な進捗報告とは、ドキュメントは何枚中、何枚が書き終えたとか、作成予定モジュールの何個中、何個が完了したとか、の数字であって、

当然、その完了というのの判断には、リーダーやサブリーダーその他第3者のレビュー確認という行為が済んでいることが前提になります。

で、その数字を進捗報告会で各人に報告をさせるわけです。これが、正しい進捗会議のやり方であるわけです。

まぁ、それも基本中の基本ではありますが、その基本ができていない現場リーダーが実に多い。。

またどうしても、小プロジェクトで成功してきたんだから、それくらいはできるリーダーなんだろうと決め付けてしまいがちな所が、そもそも間違いの元なのです。

なので結局、詰まるところ、これは現場のプロジェクトリーダーの失敗というよりも、その上の、それをつかさどる立場のマネージャー等の管理者の失敗である、ということが言えるわけです。

結論から言うと、システム開発業務のプロジェクトというものは、3人と10人（開発メンバーの人数が、）とでは、まったくの別物。

この事を、まずもってリーダーの上に立つ管理者のマネージャー等が、よく、よく、把握しておかなければいけませんし、リーダーに対する教育と管理能力の見極めをしっかりと行うこと、

まさしく、そこが非常に重要であると思う次第です。