DX化の推進を背景に、システム開発プロジェクトを適切に管理する「プロジェクトマネジメント」の重要性は高まっています。
本記事では、「システム開発プロジェクトにおけるプロジェクトマネジメントの基礎」を、主に初めてシステム開発プロジェクトを担当することになった方向けに解説します。
なお本記事は「システム開発プロジェクトにおけるプロジェクトマネジメントの基礎①・②」の続きになります。
まだ読んでいない方はこちらから先に読んでいただくことをお勧めします。
システム開発プロジェクトにおけるプロジェクトマネジメントの基礎①
システム開発プロジェクトにおけるプロジェクトマネジメントの基礎②
プロジェクトマネジメントの基礎知識をこれまで解説してきました。
ここでは、プロジェクトマネジメントの重要性を再確認しておきたいと思います。
ここで質問です。
プロジェクトがなにも問題が起きずに完了する確率は何％だと思いますか？
実は実施期間が1年以上のプロジェクトに限って言うと、プロジェクトの成功率は約60%程になります。
つまり半分弱のプロジェクトは「失敗」するわけです。
ただでさえ難しい「プロジェクトマネジメント」ですが、正しい方法論を知らないとその失敗確率はますます高くなります。
ではシステム開発プロジェクトにおいてはどの工程で最も問題（コスト超過や納期遅れ）が発生するでしょうか？
正解は、「すべての工程で満遍なく問題が起きうる」です。
日経コンピューターが行った「問題が生じた工程」に関するアンケートの結果、すべての工程で満遍なく問題が発生していることが分かります。
どの工程においても気が抜けないのがお分かり頂けたかと思います。
システム開発プロジェクトをマネジメントするプロジェクトマネージャは、一見プロジェクトが上手くいっている時でも、「遅れるリスクはないか？」「PMBOK体系で考慮できていない領域はないか？」と疑い、問題に対して準備することが必要です。
先ほど、「遅延や工数増加は全ての工程で起きうる」とお伝えしました。
しかしその原因を紐解くと、ほとんどの場合「要件定義工程」が原因であることが分かります。
実際、日経コンピューターが行った調査においても遅延の理由として「要件定義が不十分」「システムの企画が不十分」が上位を占めています。
つまり上流工程、それも要件定義工程での成果が不十分だと、後続の工程で遅延や費用増が発生する可能性が高くなる、ということです。
では要件定義工程で遅れの元を発生させないためにはどうしたら良いのでしょうか。
ここでは、「要件定義で遅れの元が発生する」＝「要件定義が不十分」になってしまう最大の原因を３つ紹介し、それらに対する対策を解説します。
1. ユーザー部門を十分に巻き込めていない。
要件定義が不十分になってしまう最大の理由の１つは要件を出す側であるユーザー部門の巻き込み不足です。
巻き込み不足には以下２種類あり、
- 非協力的で要件を網羅的に出そうとする意識がない。
- そもそも要件を提示してもらう参加者が足りない。
１点目の「非協力的で要件を網羅的に出そうとする意識がない」という点に関しては、そもそもプロジェクト内での関係構築が上手くできていない可能性があります。
最も多いケースは、「システム開発はよく分からないけど上司に言われたから会議に参加している」というマインドのユーザー部門で、このようなマインドを持ったプロジェクトメンバーがいると要件定義漏れが頻繁に発生します。
この場合は、「このプロジェクトを成功させることの意義」をユーザー部門の方と共通認識化することが重要になるとともに、「システム開発プロセス」や「要件定義の考え方」といったテクニカル面もしっかり教育していくことが有効です。
またあまりにもユーザー部門の協力が得られない場合は、プロジェクトオーナーにメンバー変更を申し入れるのも有効です。
２点目の「そもそも要件を提示してもらう参加者が足りない」という点に関しては、構築するシステムの利用ユーザー部門・ステークホルダーの洗い出しが十分でない可能性があります。
システム開発を行う場合、そのシステムを利用する全部門を巻き込むのが理想的です。
しかしリソースが割けない等の理由でそれができず、情シス部門や企画部門の方のみと要件定義を進め完結させてしまうケースが散見されます。
そうなるといざシステムを作ってみると「こんなもの使えない」と実際の利用部門から反発があり「使われないシステム」が出来上がってしまいます。
このような事態を防ぐために、まず何よりも「このシステムの利用ユーザー部門は誰か」を明確に定義することが重要で、その後は「システムを利用する全ユーザー部門をプロジェクトに巻き込む」ことが必須になります。
ただ巻き込み方にも注意が必要で、全ユーザー部門の意見を全て聞き入れるというよりも「このような要件になる」と丁寧に説明し、一つ一つ各部門の合意を得て進めていくことで、後々大きな手戻りになることを防ぐことができます。
2. Want要件に惑わされる。
要件定義が不十分になってしまう理由の２つ目は、「Want要件に惑わされる」です。
基本的に要件を出す側のユーザー部門のマインドは「とりあえずやりたいことは全部言っておこう。言わないとやってくれない。」です。
これはシステム開発プロジェクトに慣れていないが故に「この機能ほんとにいるの？」と思われるような要件も思いつくがまま提示されます。
このような「なくても業務は回るがあると良い機能」を「Want要件」と言います。
このWant要件を全て聞き入れ要件定義を進めていくと、要件定義工程自体が遅延しますし「この機能がないと業務が回らない」＝「Must要件」の定義が甘くなり、後々の工程で遅延が発生します。
このような事態を防ぐために、プロジェクトマネージャは「Must要件」と「Want要件」に切り分けを必ず行う必要があり、Want要件よりもMust要件の定義に時間をかけるべきです。
ユーザー部門の意見を上手くコントロールし、意義あるシステム開発にすべきなのです。
3. プロジェクトの目的が共通認識になっていない。
要件定義が不十分になってしまう理由の３つ目は、「プロジェクトの目的が共通認識になっていない」です。
システム開発プロジェクトを進めるにあたっては、そのシステムを利用するあらゆる関係者を巻き込みながら進める必要があると、先ほど触れました。
しかしその関係者・関係部署間で、「システム開発をする目的」が共通認識化できていないことが頻繁に発生します。
例えば経理部は「老朽化したためしょうがなくシステム改修を行う。現状業務は一切変わらない。」と考えている一方で、経営企画部は「今の業務は非効率な部分が多すぎるため、業務プロセスを抜本的に見直し、新たな業務プロセスに合わせてシステムを構築する。」と考えているかもしれません。
実際このような「認識の差」はプロジェクト規模が大きく、関連部署が多岐に渡るほど多く発生します。
このように関係者・部署間によってプロジェクトの目的に認識の差があると、要件定義が難航しやすいです。
先ほどの例だと、経理部門は既存業務が変わらないと思っているのでシステム要件も「現行踏襲」が基本になりますが、経営企画部は０ベースでの要件提示になるため、齟齬が生まれやすくなかなか要件が決まりません。
こうした事態を防ぐために、「このシステム開発プロジェクトでは何を実現したいのか」というプロジェクトの目的を具体的に明文化し、関係者・部署間で合意した上で進めることが非常に重要になります。
「プロジェクトの目的」を明文化する際は、可能な限り具体的な記載にすべきで、例えば「システム導入後、〇〇という業務が月間30時間削減される。」だとか、「システム導入後、顧客満足度の〇〇という数値がXX%向上する。」といったKPI（Key Performance Indicator）を定義することも有効です。
本記事では、プロジェクトマネジメントを行うにあたり最も問題が発生しやすい「要件定義工程」を成功させるためのTipsをを解説させていただきました。
本記事を執筆している KICK ZA ISSUE株式会社では、企業のIT化/DX化のお悩みを解決できる各種コンサルティングサービスを提供しています。
ご相談は無料ですので、お気軽に こちら からお問合せください。
ありがとうございました。
コンサルタント転職・副業情報発信メディア - Day1キャリア
国内最大級のコンサルタントマッチングプラットフォーム - コンサルデータバンク
