ITシステム発注者から見たプロジェクトマネジメント

受注者（開発ベンダー）より進捗は順調であると報告を受けていたのに、納期直前になって「すみません、納期に間に合いそうにありません」と言われてしまったらどうしましょう。システム稼働に合わせて業務の準備をしていた発注者側からすると大問題です。このような事態はあってはならないことですが、残念ながら少なからずこういうトラブルの話は見聞きします。

なぜこういうことが起きてしまうのでしょう？もちろん、一番の原因は発注者と受注者のコミュニケーションが取れていないことです。「はい、でました。コミュニケーション」と言われるやつですね（笑）

もちろん、コミュニケーションの問題と一言で片づけるつもりはありません。なぜコミュニケーションの問題が起きてしまうのでしょう？遅延の報告をするまでは受注者は「順調である」という報告を続けています。やはり自分たちの問題をできるだけ隠したいという心理ゆえの言動でしょう。仮に少しの遅れが出ている時点で、定例報告により遅れがあるという報告をしたとしたら、発注者は「どうやって遅れを取り戻すのだ」と対応策を求めるでしょう。場合によっては、その対応で仕事が増えてしまうこともあるかもしれません。そういった面倒を避けるためにできるだけ問題を表沙汰にしたくない気持ちは分からなくはないです。
とは言え、結果的に直前になって問題が発覚した時の影響の大きさを考えると、進捗の遅れの報告は早めに受け取れることが理想です。正直に報告をしてもらえるかは両者の信頼関係によるところも大きいと思います。例えば、受注者からの遅れの報告に対して、発注者としては細かな作業指示をしたい気持ちが出るでしょうが、受注者の作業負荷を増やしすぎることがないようにするなどの配慮は必要だと考えています。


上記は、精神面の話であり即効性があるかというと厳しいでしょう。長期的な視点で考えれば両者の信頼関係を高めるためにも大切なことではあるのですが、目の前のプロジェクトに対して実質的な対策としては別の方法を考えないといけないでしょう。
精神的な対策でないならば、物理的な対策となるうでしょう。といっても、もちろん暴力的な話でありませんし、賠償を求めたり裁判沙汰にしたりするようなことでもありません。（後者は最終手段ではありますが、そこまでくると両者ともに少なからぬダメージを被ることは避けられません。）

物理的な対応としては、作業の結果（成果物）を確認するのが現実的と言えるでしょう。つまり、進捗管理を受注者（開発ベンダー）に任せきりにするのではなく、発注者側でも進捗の確認をしていくのです。作成しているもの自体を発注者自身で確認するのが一番確実です。
（別のコンテンツに「進捗管理」がありますが、こちらはどちらかというと受注者視点のものでありましたが、ここでは発注者でできる進捗管理について考えてみます。）

ソフトウェアという目に見えにくいものであるし、作業している場所が受注者の事務所などであるため、発注者側では確認しづらい面はありますが、全く確認できないわけではありません。

ただし、これには大きな壁があります。設計書やプログラムといったものを確認するとしても、発注者側で確認できるだけのスキルを持っているかということです。システムの設計書やプログラムをきちんと確認するにはITのスキルが必須になります。ITのスキルを持つ第三者に確認してもらう方法も考えられますが、予算などの関係から難しい場合も多いでしょう。
じゃあやはり無理なのではないか思われるかもしれませんが、そんなことはありません。スキルを十分に持っていなくても確認できる方法はあります。


一つは、レビュー記録を提出してもらうという方法があります。レビューというのは、設計書やプログラムを作成した後に関係者で内容を確認することですが、レビュー記録は確認担当者、確認時間、指摘事項などが記載されたものになります。何も成果物がない状態ではレビュー記録は作成できませんので、少なくとも何かしらの成果物が作成されていることが確認できます。品質についても一定の確認が可能です。例えば100ページの設計書に対して1件の指摘事項しかない場合は明らかに確認不足と言えるでしょう。


他には、テスト結果を確認するという方法も考えられます。こちらは、少し敷居が高いかもしれませんが、ポイントさえつかめば一定レベルの効果は得られると思います。
いくつか例を挙げてみます。

• テスト結果のエビデンスが取得されているか確認する

⇒テストを実施した結果の証拠となるもの（エビデンス）がきちんと残されているかを確認します。例えば、画面のコピーです。エビデンスが残されていることを確認することできちんとテストが実施されているかが確認できます。ここのポイントはあくまで「エビデンスが残されていること」で、「エビデンスが正しいかどうか」ではありません。さすがに偽りのエビデンスを作成することはないでしょうから、エビデンスが残されていることで、作業がきちんと行われているかの確認を行うのです。（偽りのエビデンスを作るような開発ベンダーであれば、その開発ベンダーを選んでしまったこと自体が間違いだったと言わざるを得ないでしょう。）

• テスト項目の内容を確認する

⇒テスト項目を確認してテストケースが網羅されているかを確認します。例えば、ある機能のテストとして、「○○が動作すること」といった正常系のテスト項目しかなければ、そのテストは不十分と言えます。ユーザが間違った入力をした場合にエラー表示されるといった異常系のテスト項目も必要ですし、性能のテスト項目も必要です。インターネットなどで不特定多数からのアクセスされるシステムであれば負荷テストも必要でしょう。


上記に例をあげましたが、慣れないととっつきにくく感じるかもしれませんし、面倒にも感じるでしょう。知識が十分でないことにより、自分の確認に自信が持てないかもしれません。しかし、発注者側が不慣れな中でもこういった相手任せにしない姿勢を見せることで、受注者側に一定のプレッシャーを与えることになり、いい加減な仕事をさせてしまうこと防ぐことにつながります。


システム開発は、受注者である開発ベンダーに任せきりにするのではなく、発注者も一緒になって行っていくことが、プロジェクト成功への近道になるでしょう。