前回に続き、テーマはリスク管理である。リスク管理の共通課題とは、リスクをできるだけ丁寧に事前に洗い出し、臆病なくらいに備えることである。それには五感を動員し、リスクの予兆に早めに気付く必要がある。
 |
支援を頼まれたら、「とても無理」と簡単に拒絶したり、レベルの低い者を支援に出したりする傾向があることは問題だ。頼んだ側からすれば、レベルの低い者でも断るわけにはいかず、まさに“ありがた迷惑”ということになってしまう。顧客に迷惑をかけないためにあえて支援を求めているのだから、支援する側は支援される側が是非ほしいと思うような力を持つ者か、せめて教育のしがいがある者を出す必要がある。
支援者側の基本原則は、自分たちが困った際に、先に支援したチームが真っ先に返礼の支援をしたくなるような優秀な支援者を1人でもいいから出すことだ。頼んだほうが期待している以上の支援を提供できたら、受けた側はありがたく感じ、「きっといつかはお礼をしなければ」という気になる。こういう良い展開が繰り返される組織こそ、成功を積み上げられる組織であろう。
 |
特注システムを開発する場合、業務仕様がなかなか決まらなかったり、業務内容が分かりにくくテストに想定以上の時間がかかってしまうことがある。結果、工程の進捗が思わしくなく、到底納期に間に合いそうにないことが判明したならば、積極的に顧客と相談し顧客にも支援を請願してみよう。
もちろん契約上、「とんでもない」と叱責を受けるかもしれない。だが、それでも納期が大幅に遅れて取り返しがつかなくなるよりも、早めに顧客の支援を求めて何とか納期に間に合わせるほうが、顧客に与える迷惑をより軽減できるはずだ。
遅れたり、混乱したりする最大の要因は、途中からの機能の大幅増加であることが現実には多い。それだけに、顧客に支援を求めることにより、実現すべき機能の見直しが行われることになり、優先度が低い機能の先延ばしや簡略化、省略にもつながってくる。
 |
ベンダーとして、システム開発を請け負った以上は、その契約納期を守ることは当然の義務であり、意地でも守り通すという執念を持たなければならない。
しかし、進捗が遅れてプログラム品質が基準に達せず、このまま予定どおり稼働を強行すると大混乱を招き、顧客に多大な迷惑をかける、というのなら、勇気を持って顧客に延期を申し入れたい。システム開発における優先順位はあくまで、
品質 ＞ 納期 ＞ コスト
であるべきだ。
実現する機能に対しては、初めから優先度付けをしておくことが非常に重要だ。稼働延期を申し入れても、「是が非でも予定通り稼働させよ」と要求される場合には、顧客の顔が立つ最小限の機能に絞って、何とか稼働を目指さざるを得ないからである。
 |
納期が近付いてくると、納期に間に合うかどうかの判断が求められるようになる。最後まであきらめず、あらゆる手段を考え、あらゆる努力をしなければならない。だが、どうしても無理があれば適当な時点に納期が守れないという見通しを言わざるを得ない。
しかし、間に合わないと言うことはベンダーにとっても辛いことであるが、顧客の責任者にとっても厳しい話である。それだけに、間に合わないということが誰にも納得できるだけの論理や証拠が必要になる。単に気分だけで間に合わないとお詫びするだけでは、ベンダーのやる気や責任感に不信感をもたれてしまうだけだ。
しっかりした論拠をもってお詫びするためにも、しっかりとしたプロジェクト管理の来歴が確保されていなければならないのである。
