writing by MASA *このコラムはiPM naviで配信しています ITプロジェクトは、多くのメンバーが関わって一つのシステムを作り上げていきます。 その過程において、メンバーは作業を円滑に行うためにPMを含めたステークホルダーに質問や相談をするものです。 しかし、プログラム製造工程で『業務仕様』の質問が多発するITプロジェクトは、危機状態であると認識してください。
監修：Osamu 2001年に大手コンサルファームBにジョイン。 ITコンサルタントとして複数のシステム開発プロジェクトのPM・PMOに従事。 2016年よりSIerの取締役として、BtoC向けスマートフォンアプリ開発サービスのビジネススケールに貢献。 2019年にITコンサルファームを設立。 大手金融会社の新規事業のIT担当として、脳機能を定期的に測定することにより、認知機能の変化を把握するシステムの開発を担当し自社ビジネスを拡大。
こんにちは、プロコンサルのMASAです。
iPM PREMIUMで運営しているオンラインサロンでは、プロコンサルが企業さまのPMへ個別のレクチャーやプロジェクトの後方支援を行なっています。 その活動を通じて、プロジェクトを成功に導くために活用した大手コンサルファームならではの特別なノウハウやメソッドをコラムにしています。 今回のコラムは、某IT企業に勤務する32歳のPMの方からのご相談となります。
MASAのキャリア 2004年に大手コンサルファームBにジョイン。 大手事業会社をクライアントに持ち、クライアント社内で活用する品質マネジメント基準・開発プロセス基準の策定に従事。 また、PMOとしてクライアントのプロジェクト推進及び品質維持に貢献しプロジェクトを成功に導いた。 2016年に大手コンサルファームMにジョイン。 大手エネルギーインフラ会社のガバナンス部門にて、大規模システム開発プロジェクトのマネジメント品質管理に従事。PMOとしてプロジェクト運営における問題点の可視化とプロジェクトマネージャおよび上位層への改善提案によりプロジェクトを成功に導いた。
PMからのご相談
■相談者 某IT企業に勤務する32歳のPM ■相談内容 わたしは、某IT企業でPMに携わっている32歳です。 PMは、今回で3回目ですが毎回自分のマネジメントには不安を抱えています。 ①わたしが担当するITプロジェクトは、要件定義・基本設計・詳細設計を弊社が行い、開発工程をITパートナーへお願いしています。 *一部のメンバは設計作業に参加していたが現在は不在である。 ②現在、ITパートナーがプログラム製造を行なっています。 ③また、ITパートナーはプログラム製造工程から多くのエンジニアを投入して、作業を行っていが設計工程に携わり、業務仕様を理解しているメンバーは、チームに残留していません。 ④そのことから、ITパートナーから業務仕様の確認を含めた多くの質問があり先行きが不安です。 *後日判明したことは、相談者の会社が作成した設計書は、業務仕様に関して大雑把に記載されていた。 ⑤ITパートナーが、業務仕様を曖昧に理解していたらプロジェクトは破綻します。 ⑥ITパートナーが、業務仕様をきちんと理解しているか、どのように確認すれば良いでしょうか？ ■相談のポイント ①ITパートナー内に、業務仕様を理解しているメンバーがいない。 ②ITパートナーから業務仕様の確認を含めた多くの質問がある。 ③その原因は、設計書には業務仕様の内容が大雑把に記載されているからである。 ④相談者は、ITパートナーの仕様理解度の確認方法がわからない。
こんな時は、こうしてみれば良いですよ！
このように前提条件を整理しました。 ・ITパートナーは、業務仕様を理解すれば作業を円滑に進められる技量がある。 ・設計書に不備があるが、設計書を完璧に修正する時間がない。 ITプロジェクトは、設計書をもとにプログラム製造します。 しかし、設計書の業務仕様の記載が大雑把であれば質問も多発します。 この状況に、PMが嫌気がさし不親切な態度を取ったら、ITパートナーは業務仕様を自分勝手に想像してプログラムを製造するので、プロジェクトが破綻します。 そうならないように、ITパートナーのメンバーが仕様を理解できるように、2つのアプローチが必要です。 アプローチ1 ITパートナーで仕様を知っているメンバを連れ戻してもらい、体制に組み込んでもらう。 アプローチ2 アプローチ1ができないのであれば、当該プロジェクトは結合テスト工程以降の品質劣化が懸念される。 そのため、相談者が中心になって、ITパートナー向けの「業務仕様説明会」、または「QA解決会」を数日間集中的に行い業務仕様の理解を深めてもらう。
大規模・小規模・ウォーターホール・アジャイル...限らずプロジェクトは作業工程毎に役割分担が決まっています。 論理的には、前工程の作業が完了した場合には、担当メンバーがチームからリリースになっても、何も問題はないはずです。 しかし、そうならないのがITプロジェクトです。 メンバーの入れ替え、キーマンの離脱は不思議なことではありませんが、プロジェクトにとってはリスクです。 一番は、成果物を作り上げていったまでの経緯や成果物に盛り込まれていない顧客との約束事...etcがあります。 これを一つ一つ記録に残しすのは難しいもので、記録に残したからといって即座に探し出すことも無理なものです。 PMは、プロジェクト計画の段階で、キーマンの離脱に備えて品質劣化を防ぐ対策を考量しておかなければなりません。 これもPMの重要な役割の一つなんです。 最後まで読んでいただき有難う御座いました。
わたしのコラムで、あなたのお役に立てれば幸いです。
品質管理・スコープ管理、こんなようなコラムを配信していこうと思ってます。
ぜひ、今後とも応援を宜しくお願いします。
*Back Numberはこちらです↓
