ITプロジェクトの成否は、そのプロジェクトを実施する体制にかかっていると言っても過言ではありません。

• 必要なメンバーが体制に入っているか
• 適切に権限が委譲されているか
• プロジェクトリーダー、サブリーダー、担当者・責任者（承認者）などそれぞれの役割が明確になっているか

といった観点から適切なプロジェクト体制が組まれているかチェックしてみましょう。

プロジェクトの計画にスケジュール表は必須ですが、実際の現場においてスケジュール表が必ずしも有効に機能されている事例ばかりではありません。

ITシステムの構築などは、多くの場合で開発を委託されているITベンダーで作成されますが、このスケジュールはITベンダーで行う開発作業がメインとなっており、顧客側で検討したり確認したりする期間が考慮されていない場合があります。

顧客側も自分たちの業務に直結するプロジェクトと認識し、マスタースケジュールも自身で作成するべきものと認識しておきましょう。

プロジェクトを進めていく中で、関係者間で「言った、言わない」ということは往々にして起こります。そういったことを防ぐために口頭ではなく文書のやり取りでコミュニケーションをとることが大切になりますが、特に会議での決定事項・宿題事項などを記録する議事録は重要になります。

ただ、多くの場合、議事録を作って終わりとなってしまっています。作成された議事録を出席者で確認した後、プロジェクトの責任者が承認するなど、プロジェクトメンバー全員での共有が大切です。

ITシステム構築のプロジェクトでは、様々な課題が発生します。課題管理表で現状どういう課題が存在するのかを関係者で共有します。単に課題の内容を記録するだけではなく、担当者・期限・重要度といった情報を加え、それぞれの課題に対して優先度をつけながらプロジェクトに影響が出ないよう適切に課題を解決していくことが可能となります。

プロジェクトを進めていくうちに課題が増えてくると、新しく出てきた目の前の課題に目を向けすぎて、過去に出てきた重要な課題がおざなりになってしまうことがあります。定期的に課題の棚卸を行い、時には「重要度の低い課題についてはあきらめる」といった判断も必要です。

ITシステムを構築する上で、要件定義書はなくてはならないものです。どういうシステムを作るのかを依頼者とITベンダーで共有するためのもので、ITシステムの設計図です。顧客が望む要件・ITベンダーが作成しようとしている機能について、漏れなく要件定義書に記載する必要があります。

書き漏れがある場合、実際に顧客側で使用した際に「思っていたもの（依頼したもの）と違う」ということが起こりえます。自分たちが当たり前と思っていることでも、相手側にとっては当たり前と認識していないことが多々あります。電話や会議での口頭だけで「言ったつもり」が相手に通じていないこともあります。

書面を残して確認をしておくことで、認識の齟齬を減らすことが出来ます。万一トラブルが発生した際もその書面が証拠になりますが、逆に書面に記載されていないことは「言った、言わない」の水掛け論になるので注意が必要です。

改めて言うまでもありませんが、ITシステムを何のために導入するのかという目的が重要です。この目的は個々の担当者の要望ではなく、組織全体としての目的として明確にし、関係者全員で共有されておく必要があります。

システムの具体的な設計に入ってくると、それぞれの担当者が自分の使い勝手を重要視しすぎることで、作業が前に進まなくなったり、組織全体としてのより重要な目的から外れてしまったりすることがあります。

プロジェクトリーダーは、参加するメンバーに個々の利害ではなく、組織全体の目標を意識させるように啓発していくことが必要になります。

昨今のビジネではスピード感を求められます。特にITの進歩は急激に進んでおり、システムの構築が遅れてしまうとせっかく時間をかけて作ったものがも既に陳腐化してしまうこともあり得ます。

システムの設計を進めていって具体的な形が見えてくると、顧客側も利用シーンがより具体的にイメージできるようになるため、細かな個所が気になってくるようになります。もちろん、実際の業務に直結するものであるし、どうせ作るならより使いやすいものにしたいという気持ちも理解できます。ただ、使い勝手というのは個人の感覚によるものも大きく、慣れで解決する部分もあります。システムの導入目的にもよりますが、あまりに使い勝手にこだわりすぎてしまうと、本来の目的の達成が遅れることになります。

まずは組織全体としての大目標が達成できる骨組みを構築してから、その後で個々の機能を肉付けしていく進め方をお勧めします。完璧を求めすぎず重要事項を優先して前に進んでいくことも必要です。

プロジェクトのメンバーの協力がなければ、プロジェクトの成功はあり得ません。ITベンダーと顧客との間はもちろんのこと、顧客側内部での協力も重要です。システムに対する思いが経営層と現場の担当者との間で差異があったり、部門間で対立したりすることで、プロジェクトが前に進まなくなってしまうことがあります。

協力には密なコミュニケーションが必須です。特に各自の常識を前提としてコミュニケーションをとっていると、自分が伝えた意図と相手が受け取った意図が異なってしまうことがあります。面倒に感じるかもしれませんが、自分の当たり前が相手の当たり前とは限らないと認識して丁寧にコミュニケーションをとっていくほうが、結果的にプロジェクトが早く前に進むことになります。

また、プロジェクト関係者に適切に責任と権限を委譲しておくことも必要ですし、責任と権限を委譲できる人を配置することも必要です。意見が分裂して前に進まなくなるような時は、リーダー・サブリーダーが決断して前に進める勇気も必要ですし、その判断をメンバーが承服できる信頼関係も必要です。