top of page

プロジェクト計画で要件のFIXを後回しにさせない方法


writing by Osamu Hirayama *このコラムはiPM naviで配信しています ITプロジェクトは、プロジェクト計画で大枠でクライアントニーズを掴み、要件定義工程で詳細な要件に落とし込みます。 この段階でクライアント要件をFIXさせます。 しかし、全ての要件がこの工程でFIXするのは難しいこともあります。 クライアントの要件の中には、要件のFIX作業を進めるにつれて、社内調整が困難で、必要以上に時間が掛かることがあります。 そのため、プロジェクト計画の中で、社内で調整が難しい要件については、これらをWBSとスケジュールに反映して下さい。

  • クリティカルパス

  • マイルストーン

 

監修:MASA 2004年に大手コンサルファームBにジョイン。大手事業会社をクライアントに持ち、クライアント社内で活用する品質マネジメント基準・開発プロセス基準の策定に従事。また、PMOとしてクライアントのプロジェクト推進及び品質維持に貢献しプロジェクトを成功に導いた。

2016年に大手コンサルファームMにジョイン。

大手エネルギーインフラ会社のガバナンス部門にて、大規模システム開発プロジェクトのマネジメント品質管理に従事。PMOとしてプロジェクト運営における問題点の可視化とプロジェクトマネージャおよび上位層への改善提案によりプロジェクトを成功に導いた。

 

こんにちは、プロコンサルの平山 理です。

iPM PREMIUMで運営しているオンラインサロンでは、プロコンサルが企業さまのPMへ個別のレクチャーやプロジェクトの後方支援を行なっています。 その活動を通じて、プロジェクトを成功に導くために活用した大手コンサルファームならではの特別なノウハウやメソッドをコラムにしています。 今回のコラムは、SIerに勤務している27歳のPMの方からのご相談となります。

 

Osamu Hirayamaのキャリア 2001年に大手コンサルファームBにジョイン。 ITコンサルタントとして複数のシステム開発プロジェクトのPM・PMOに従事。 2016年よりSIerの取締役として、BtoC向けスマートフォンアプリ開発サービスのビジネススケールに貢献。 2019年にITコンサルファームを設立。大手金融会社の新規事業のIT担当として、脳機能を定期的に測定することにより、認知機能の変化を把握するシステムの開発を担当し自社ビジネスを拡大。

 

PMからのご相談

■相談者 SIerに勤務している27歳のPM ■相談内容 わたしは、某IT企業に勤める27歳です。 PMは、今回で4回目ですが要件のFIXに戸惑いながらプロジェクトを進めています。 ①わたしは、要件定義工程でお客さまと要件をFIXさせるのが下手で後続工程でトラブルを起こすことが多いです。 ②先日も単体テスト工程で、お客さまより「一部の要件が未確定であるが、プログラムを製造しても我々(お客さま)のビジネス要件を実現できるのか?」と確認の問い合わせをいただきました。 ③わたしは、要件定義工程で要件をFIXさせることは理解していますが、お客さまの諸事情もあり後手後手(プロジェクトの終盤)になってしまい突貫工事でプロジェクトを終了しています(当然、システムの品質も悪い)。 ④わたしは、お客さまにも協力していただき健全にプロジェクトを推進していきたいのですが、アイデアが浮かびません。どのような方法を取れば良いでしょうか? ■相談のポイント ①相談者は、要件定義工程で要件がFIXできない。 ②クライアントの諸事情で要件定義工程で要件をFIXできない。 ③相談者は、要件のFIXがプロジェクトの終盤である。 ④相談者は、お客さまを巻き込んだ要件のFIX方法がわからない。


こんな時は、こうしてみれば良いですよ!

このように前提条件を整理しました。

  • ITパートナーは、要件定義工程で要件がFIXできれば品質の高いシステムを開発できる。

  • クライアント健全なプロジェクト推進を望んでいて、協力を惜しまない。

要件定義工程で、クライアントのやりたいこと(要件)をFIXできるのが理想です。 しかし、諸事情で、なかなか上手くいくものではありません。 プロジェクト計画の段階で、『要件をFIXするには有効的な方法である』旨を、クライアントに伝えて、計画段階で今回、お伝えするアプローチを盛り込んで下さい。 それでは、アプローチしていきましょう! アプローチ1 クライアントの要件の中で、要件定義作業で『社内調整が難航すると思われる要件』と『社内調整が順調に進むと思われる要件』を分ける。

ITパートナーが仮説を立ててから、お客さまへヒアリングを行い見つけ出す。 アプローチ2

要件単位にWBS(タスクネットワーク、ガントチャート)を作成する。

プロジェクト全体のWBSの中の要件定義工程を細分化するということ。


👀 アプローチ2を行うためのスキル

アプローチ2をスムーズに行うには、WBSを作成できるスキルが必要です。WBSを作る手順の参考になるコラムがこちらです↓


アプローチ3

要件単位に作成したWBSから、タスクネットワークに分類する。

【パターン1】 社内調整が順調に進めタスクが単独で進行する。 【パターン2】 社内調整が難航すると思われるタスクが単独で進行する。 【パターン3】 社内調整が難航すると思われるタスク(先行タスク)と社内調整が順調に進めタスク(後続タスク)が連携してタスクが進行する。 【パターン4】

社内調整が順調に進むタスク(先行タスク)と社内調整が難航すると思われるタスク(後続タスク)が連携してタスクが進行する。


アプローチ4 これらパターンから所用期間が一番長いものをクリティカルパストして設定する。 アプローチ5 パターン3、4は合流タスクとなるためマイルストーンとして設定する。 アプローチ6 クライアントと最終的な要件定義工程のWBS(タスクネットワーク、ガントチャート)とマイルストーンを合意する。 *合意とは、クライアントが最終的な要件定義工程のWBSに従い作業を協力することを意味している(スケジュール、体制)。

 
まとめ

今回のご相談は、PMをやったことのある方であれば、経験したことがあるのでは無いでしょうか? クライアントの要件は、プロジェクト計画の段階で大枠は見えています。 また、要件定義工程で詳細を詰めていくのが通例であり、全ての要件がFIXすることが理想です。 しかし、クライアントの社内事情等があり難しいものです。 PMは、そのことを分かっているにも関わらず、要件定義工程でFIXさせるようにWBSやスケジュールを作ってしまいます。 PMであれば、無理・無茶・無駄をリスクと捉えて、事前に排除しなければプロジェクトは炎上します。 こんなことにならないように、4つのパターンに要件を分類して、クリティカルパスとマイルストーンをクライアントと合意してください。 【パターン1】 社内調整が順調に進めタスクが単独で進行する。 【パターン2】 社内調整が難航すると思われるタスクが単独で進行する。 【パターン3】 社内調整が難航すると思われるタスク(先行タスク)と社内調整が順調に進めタスク(後続タスク)が連携してタスクが進行する。 【パターン4】 社内調整が順調に進めタスク(先行タスク)と社内調整が難航すると思われるタスク(後続タスク)が連携してタスクが進行する。 最後まで読んでいただき有難う御座いました。

 

わたしのコラムで、あなたのお役に立てれば幸いです。

炎上プロジェクトの火消し役が多かったことから、炎上させないマネジメント、問題プロジェクトの解決方法、こんなようなコラムを配信していこうと思ってます。

ぜひ今後とも応援を宜しくお願いします。

*Back Numberはこちらです↓


bottom of page