最後の項目は、プロジェクト管理手順です。
ここでは、進ちょく管理、課題管理など、プロジェクトが順調に進んでいるかを評価し、問題が発生している場合のルールを決めます。
プロジェクト管理で気を付けることは、問題の発見が遅れたり、発見しても放置したままにする状態を作らないことです。
問題が小さなうちに対処をすれば解決できる問題でも、放置をすると問題を大きくし、解決するのに膨大な時間がかかることになります。そのために、報告がすぐに上がってくるような仕組みや、問題の対処のルールを決めておきます。
問題の対処のルールは特に大事です。
できるだけ現場で即座に問題解決の行動を取りコスト追加やスケジュール遅延が発生しないようにします。問題によっては責任範囲や契約に絡むこともありますが、これらに関する調整については別途行うことをお互いに約束し、早くスケジュールの遅れを取り戻すことを目指します。
交渉などの無駄な時間の浪費や、問題が解消されず、そのため後続工程でさらなる遅延を膨れ上がらせるというような事態を発生させないようにします。このように振舞うことによって、最終的に、追加コストやスケジュール延期の話をする場合でも最小限にすることにつながります。
なお、報告は開発ベンダ側だけに求めるのではなく、自社側の進ちょく状況や課題解消状況について、情報システム部門が取りまとめ報告をしましょう。進ちょく報告会などで、ユーザー側の進ちょく状況も報告をするなどの活動を行い、開発ベンダ任せにしていないということを行動で示すことが重要です。
項目 | 情シスが気を付けるポイント |
---|---|
進ちょく管理 | ・定例会での報告内容と報告に対するアクションが決まっているか ・将来の作業予定についても管理するようになっているか |
課題管理 | ・漏れずに記録される仕組みや、何日も放置されないようにチェックする仕組みがあるか ・棚卸し会など積極的に課題を解消する仕組みが用意されているか |
リスク管理 | ・既に発生している課題だけでなく、将来発生しそうな問題についても管理されているか ・定期的にリスクを回避するための行動を検討する仕組みが用意されているか |
障害管理 | ・障害が発生した原因を調査し、再発防止に向けたアクションが決まっているか |
仕様追加・変更管理 | ・追加や変更対象のリストアップの仕組みが決まっているか ・開発ベンダ側とユーザー側の上層部による調整手順がきまっているか ・機能削減があった場合や他作業の工数が短縮できた場合に、増加分と相殺するルールが検討されているか |
構成管理・文書管理 | ・開発プログラムやドキュメントを管理する手順が決まっているか |
コミュニケーション手順 | ・共有する情報や共有する手順が決まっているか。メールの利用方法、Webを用いた情報共有の仕組みなど効率的なコミュニケーション手順が考えられているか |
表3:管理手順の内容で情シスが気を付けるポイント |
いくら取り決めを行っても、守ってくれなければうまくいきません。開発ベンダにはありのままの状態を報告することに抵抗があるところもあります。これでは、どんなにルールを決めても効果はありません。
抵抗があるのは、信頼されていないからです。例えば、ユーザー部門に後から追加要件を押し込まれたり、情報システム部門もそれを制御してくれなかったなど経験があるためです。こうした抵抗を取り除くためには、お互いの信頼関係を確立することです。
このための最初の場がプロジェクト計画書の策定です。
状況の変化による遅延などが生じても、すぐに報告してもらう限り調整する旨を、明確に伝えます。ユーザー部門もしっかり作業をすることを一緒にいる場でコミットするようにします。そして、プロジェクト開始後の数週間で確かに約束が守られていることが分かれば、信頼関係は深まっていきます。
もちろん、もともとこうした信頼関係を醸成できない開発ベンダも残念ながらいます。そうした開発ベンダには早く見切りをつけましょう。冒頭でRFPの話をしましたが、RFPでどんな技術や経験の制約をつけるよりも、信頼関係を結べる開発パートナーを見付けることの方が重要です。
RFPの中で、プロジェクト計画書に基づいた進め方に従ってもらうことを示し、プロジェクトマネージャとの面談の中で、信頼に足る人であるかどうかを見極めていくことが、プロジェクトを納期通りに完了するには重要なのです。
システム開発の現場では、情報システム部門がプロジェクトの成功に責任を持つ部門であり、そのための活動や行動で示すことが求められています。ぜひ、情報システム部門が積極的にプロジェクト推進に関係し、狙い通りのシステムを予定したコスト、スケジュールで完成させることに貢献してほしいと思います。
▼著者名 小林 博(こばやし ひろし)
ウルシステムズ 主席コンサルタント。ユーザー企業の情報システム部、開発会社を経て、2006年より現職。企業内システムの全体最適や大規模システム開発のプロジェクトマネジメントに関するコンサルティングに多く携わる。IT企画や要件定義、システム開発の領域でユーザー、情シス部員、開発者の3者がプロジェクトに積極的に参画するためのマネジメント方法や開発プロセスの確立に注力している。
Copyright © ITmedia, Inc. All Rights Reserved.