［姿勢編］目的を忘れてはいけない

　システム開発プロジェクトを進めていると，時折，目的と目標と手段がぼやけてしまうことがある。特に，プロジェクトの終盤やトラブルが発生したときがそうである。目的が忘れられ，手段ばかりが話題の中心になる。工程表通りに進め，計画通りに納品することにやっきとなってしまう。しかし，それではプロジェクトの成功を収めるのは難しい。プロジェクト・マネージャ（PM）は，いかなる状況に陥ってもプロジェクトの目的を見失ってはならない。

Mさんの失敗例

　独立系SIベンダーF社に勤務するMさんは，都内にあるサービス・プロバイダB社の電話受付システム開発のPMを任された。このシステムは，顧客からの各種問い合わせを電話で受け付けると同時に，オペレータの操作卓に顧客のプロフィールや過去の応対履歴，購入履歴などの情報を表示し，的確なサポートを提供することを目的としていた。いわゆる典型的なCTIシステムである。これによってB社は，これまでオペレータがいったん電話を切ってからかけ直すという方法しかできなかった受付業務を改善し，顧客満足度の向上を狙ったのである。

　Mさんは，これまで通信系システムに関する開発経験はあったが，CTIに関する経験は無かった。ただ，これまで多くの現場を渡ってきたMさんだけあり，システム開発自体は順調で，スケジュールも前倒し気味に進んでいった。

　ユーザー部門を交えた総合テスト・フェーズに入って，エンドユーザーである何人かのオペレータから「最初に表示される画面が，少し複雑で使いにくい気がする」という意見が聞こえてきた。

　Mさんは通常，システム開発終盤で出されたエンドユーザーの意見はその場では取り上げず，変更要求として管理し，システム稼働後に検討を行うようにしている。しかし，今回に限り，この意見を取り上げることにした。理由は，同様の意見が複数のユーザーから出たということや，開発自体は順調に進んでおりスケジュールに若干のゆとりがあるということだった。それに加えて，MさんがCTIについて開発経験不足で自信が無いがゆえに「CTIのユーザー・インタフェースについてもう少しこだわりたい」という理由が大きかった。

　早速，Mさんは何人かのオペレータとの意見交換を行った。するとオペレータの意見は「この画面は使いにくい」という共通の意見に集約された。そこでMさんはこの問題となった画面について変更すべきかどうかを検討することにした。

　Mさんが検討を開始すると，オペレータたちの間では様々な意見が飛び交うようになっていた。それはMさんが全く予期せぬものであった。「最初に表示される画面が複雑すぎて，このままでは業務に支障が出るので使えない」。

　この意見はB社のプロジェクト責任者の耳に入ることとなった。B社からは正式にF社に対して当該画面に関する改善要望が提出されたのだった。こうなってしまっては，Mさんとしても当該変更要求について受け入れざるを得ない。

　この改善要望をきっかけに，オペレータの間からは「使えない」という意見が次々と噴出した。既に最終確認テストが完了した画面についても，それまでの結果をひっくり返して「使えない」と言われたのである。結局，このシステムは改善要求の受け入れと納期延期を繰り返し，最終的に納期半年遅れとF社の大幅な赤字でようやくカットオーバーにこぎ着けたのだった。

プロジェクトには目的と目標と手段がある

　Mさんの失敗は，このシステム開発の目的と手段を取り違えた結果の典型的な例である。今回の場合，システム開発の目的はB社受付業務の改善である。顧客満足度を向上させるべく一日でも早くCTIを実現したいということである。そのためには，多少使いにくいところがあったとしても全体業務として大きな影響を与えないのであれば，まずは実現することが最優先されるべき事柄であったのだ。にもかかわらず，目的を達成するべき手段であった「物作り」にこだわってしまったばかりに大きな失敗へとつながったのだ。

　すべてのプロジェクトには目的と目標と手段がある。この目的と目標と手段の違いを明確にせずにプロジェクトをスタートさせてはならない。筆者は，これらの違いについて聞かれた場合に，次のような例で部下に指導している。

目的：業務改革，業務効率化，BPRなど
目標：○○業務にかかる手作業を○○時間軽減する
　　　○○業務のリードタイムを○○日短縮する
手段：○○業務のシステム化する
　　　○○業務の見直しを行い，その一部をシステム化する

　Mさんの場合，手段である「物作り」にこだわることなく，本来の目的に従い予定通りにカットオーバーさせるべきであった。そうすれば時間経過による顧客要望の変化（使いにくい気がする→使いにくい→使えない）に振り回されることもなかったのだ。その上で，使いにくい部分について利用状況を見ながらゆっくりと機能改善を行うべきであったのである。

仕事の本質は業務改善

　システム開発プロジェクトでは，どうしても「物作り」の部分に焦点が当たってしまい，本来の目的を見失いがちである。確かに「物作り」は大事である。発注側である顧客ですら物作りばかりを気にする場合も多い。しかし，プロジェクトの本質は業務改善であり，システム開発やパッケージ導入といった物作りは，あくまでそれを実現するための手段である。

　PMたるもの絶対に目的と手段を取り違えてはならない。プロジェクトの途中で目的が見えにくくなったり，ぼやけたと感じたりした場合には，一度そのプロジェクトの原点に立ち返り，再確認するべきである。