■開発現場の悩み・問題点を解く １ ～プロジェクトが遅れる ① ～ （No.306）
以前，開発現場よりと題し，数回（No.258～No.265)に亘り，現場での状況におけるものの見方・考え方を述べたが，今回からしばらくの間，個々人の悩みや問題点を抱えている人に対するアドバイスとして，考え方を中心に論ずることにしてみる。毎回，個々の悩みを挙げ，それに対する解決策を述べてみる。こうした解決策は，必ずしも正解があるのではなく，実際の状況に依って変わることがあるので，参考に読んで貰えれば良い。
プロジェクトが遅れる理由
最も身近なこととして，プロジェクトが遅れることはしばしば見かけることで，他人事ではない。開発者ならば，何度となく経験しているだろう。しかし，遅れが発生する原因を知っていても，なかなか直らないものである。それほど厄介な事象と云えよう。思いつく原因を列挙してみる。
- 最初からムリな開発日程
- メンバー不足
- 要素技術が開発できていない
- 主要メンバーにアクシデント
- 前の製品との互換性に苦慮
- 計画が立てられていない（計画性が杜撰）
- マイルストーンが無い（計画性が不十分）
- 計画の読みが浅い（計画性が不十分）
- 開発内容が把握できていない（計画性が杜撰）
- 開発計画の詳細が曖昧（計画性が不十分）
- 全体の統率が取れていない
- 遅れを許す風土がある
- 大きな壁にぶち当たる（想定外）
- 予算不足
- 後戻りの繰り返し（品質悪化）
- 結果オーライの管理方法
- 外部委託管理の不手際
- 課題・リスク認識が甘い（課題やリスクを放置，見過ごす）
- メンバーのやる気がない（モチベーションが低い）
- 顧客要求が変わる(仕様変更）
- ハードとソフトのマッチング不良
- 進捗管理が不十分（ソフトは進捗が見えにくい）
- クリティカル・パスが把握できていない
挙げ出すと限りが無いが，遅れが生じている場合，上述のどこかに当てはまるだろう。
計画性の杜撰・不十分とは？
先ず，プロジェクトが遅れる理由の一番は，やはり計画性が無いことである。杜撰と云うべきか，不十分と云うべきかは，その内容の詳細によって変わるが，プロジェクトの基本は日程があることである。期限のないものはプロジェクトとは云わない。だから，プロジェクトには，日程に基づいた計画がなければならない。
日程に対する計画が何らかの理由（人員不足，技術不足など）で立てられないならば，そのプロジェクトは成り立たないのである。それを上の命令だからとして，そのままやろうとするのは最初から間違っている。リーダとして最初に，できるかできないかの見通しを立てなければならない。もちろん，１００％できるなどというプロジェクトは少なく，リスクを背負っての開発は当然である。そのリスクが大きすぎて，明らかに不可能なものは最初に排除すべきである。但し，未知なものへ挑戦するようなプロジェクトは，期限を切って，可能性を追求するものも場合によってありうる。これは，期限までにできるか，できないかを評価するもので，目的が最初から明らかになっておれば成り立つ。
計画性が杜撰なもので，酷いのは開発日程そのものがあるだけで，あとは闇雲に進むだけと云うもので，これはプロジェクトの体を為していない。そこまでのものは無いにしても，詳細な部分の検討をせず，エイッヤーと勢いだけで日程を決めてしまう場合も，余り大差はない。要はプロジェクト計画は詳細な計画そのものが生命線で，それが無い，または杜撰な場合は，プロジェクトの遅延発生は明らかである。これでは，プロジェクトに携わっているメンバーの士気に関わる問題である。
杜撰・不十分とは言い切れないが，開発すべき全貌が把握できていない場合も日程に問題が生じるケースが多い。つまり，通常のプロジェクトとは，初めて挑戦する部分はあるが，大抵はこれまでの経験に基づいて，不確定な部分を考慮して日程が引かれる。もちろん，日程優先のプロジェクトも多く，その場合は，リソースを考慮して検討されることが殆どである。メンバーが限られているケースでも，多少の日程遅れは最初から読み込んである場合もある。つまり，プロジェクトの日程は計画通りに進めることが可能な範囲で立てられているのである。
プロジェクト計画は，詳細計画として，WBSに落とし込みをしたり，マイルストーンを明確にして立てられる。特に，ソフトウェア開発では必ず，最初の計画段階でWBSに落とし込むのが通常である。これによって，詳細な日程が個人ベースにまで落とし込めるので，リソース不足などの問題点は計画段階で明らかにできる。もちろん，誰でもがWBSを作成できるわけではなく，経験を積んだ者が，開発内容とリソースのスキルと照らし合わせて検討するものである。このWBSがきっちりできているかどうかで，プロジェクトの成否が左右される。
ハードウェア，ソフトウェアの双方の開発に携わった経験者としては，どちらかといえばハードウェアの方が未確定な要素が多く，開発する部分が多い。それに比較するとソフトウェア開発は，未確定な開発というより，パワーを必要とする設計要素が多く，予測が立てやすいことが多い。初期段階で，詳細はWBSが作成できるのも，そうした点がある。ハードウェアでは，ある段階まで進まないと，詳細なWBSの作成ができない（個人に落とし込んだWBSなど）ことが多い。ただ，ハードウェア開発でも，詳細とは云わないまでも，日程計画の作成は重要で，最後の微妙な日程調整は，仕様の性能などで調整されることが多い。
プロジェクト計画の代表的なPERT（Program Evaluation and Review Technique）は，元々はアメリカの国防省の弾道ミサイル開発に応用されたもので，日本では橋造りや建造物を作る土木・建築現場で多く用いられ，大型のプロジェクト開発に利用されたものである。我々の世代の技術者はプロジェクトを任される前には，PERT手法は重要なもので必須として学ばされたものである。従って，３０年以上も昔からプロジェクトの進捗にはPERTを活用していた。
PERT活用で一番良かった点は，メンバー全員で進捗状況を共有できることだった。しかも，上司への報告も，PERTのチャートですべてが済んでいた。目に見える管理をよく言われるが，PERTは当に見える管理で，どこが問題か，遅れているかが一目で明らかになった。当時は，パソコンがそれほど活用されていなかったので，A2の方眼紙に３カ月程度のスケジュールを埋め尽くし，張り出して管理していた。他の手法に優る管理方法だった。多少の遅れは常に発生していたが，ダメージを与えるような遅れは少なかった。ただ，技術的な難題を乗り越えなければならないような壁にぶつかることでの遅れはあったが，管理上の問題は皆無だった。
開発現場なので，技術的な難題にぶつかることは多い。その難題の壁と有しているリソースのスキルのギャップが高ければ高いほど時間を要し，プロジェクトの遅れに繋がることは当然である。しかし，その課題を明確にして，リソース増強や他の知恵の利用など戦略的に攻めることで，その難題を突破しなければならない。技術課題は一見すると計画性とは関係ない問題であるが，計画がしっかりあるから，目標に対しての課題がクリアとなり，戦略的な考え方ができるとも云える。
以上，述べたことから，計画の不十分な・杜撰なものは，プロジェクトが遅れる大きな要因になっていることはお判り頂いたのではないか。
プロジェクトの遅れは最も身近な問題である
計画性の善し悪しが日程を左右する
[Reported by H.Nishimura 2013.01.28]
Copyright (C)2013 Hitoshi Nishimura
