初めてのプロジェクトマネージメント（５）計画｜委託先

委託先とのやりとり

調達に関わる主要なプロセスは以下の通りです。プロジェクトマネージメントを上手く進める５つのステップ その2 具体的に何をやればいいのかを決めよう！にて言及した項目以外について、ここでは触れておきたいと思います。

実際の調達は以下のように複雑なプロセスで進行します。1つ1つのアクティビティーは大きくありませんが、小さな必須アクティビティーが自社、委託先間で多く発生します。気合を入れて臨みましょう。

サンプルプロジェクトに対して、PMBOKの5つのプロセスに沿った形で解説していきます。今回は（５）計画｜委託先です。委託先と取引する場合、どんなことが起こっているのかについても良くあるパターンのフローを作成しました。参考にしていただければと思います。

担当になったら知っておきたい「プロジェクトマネジメント」実践講座

調達マネジメントの計画

このプロジェクトでは、調達マネジメント計画においてどこのレコメンドシステムを採用するかを決定することとなります。そのためにどのような評価項目をどのような基準で評価し、誰が最終的な意思決定を行うかを定めておく必要があると思います。

評価項目

1. コスト
   • コストには初期（イニシャル）コスト、運用（ランニング）コストに分かれます。
     • イニシャルコストは導入時（サービス開始前）に発生するコストで、サービス提供側がカスタマイズのための開発を行う必要がある場合の開発費用などが考えられます。
     • ランニングコストは導入後（サービス開始後）に発生するコストで、月額利用料やサーバー費用などが考えられます。
2. 品質
   • SLA
     • SLAとは、Service Level Agreementの略で、サービスの提供事業者とその利用者の間で結ばれる、サービスのレベル（定義、範囲、内容、達成目標等）に関する合意で、サービス水準やサービス品質保証などと訳されます。
     • サービスを提供する事業者が契約者に対して、どの程度まで品質を保証できるかを明示したものです。
3. コミュニケーション・サポート
   • サポート窓口
     • 障害や何らかの問題（受け渡しデータのミスなど）が発生した際に、素早く連絡が取れる体制があるか否かを確認します。
   • ドキュメントの充実
     • システム開発時や連携用データ作成時にどのように行うべきかといったドキュメント類がどの程度充実しているかを確認します。
     • 海外のサービスの場合、ドキュメントが全て英語というケースもあるので、確認が必要です。
4. 要求事項の充足度 プロジェクトの要求事項をどの程度満たすことが可能かを定量的に判断することが必要です。

評価基準

社内で外部サービスを選定する基準が存在する場合はそれに従うといいと思います。今回はサンプルプロジェクトを例に基準を定義してみました。

• 評価点は1から5までの5段階評価
  • 1：既存システムよりもかなり劣っている
  • 2：既存システムよりもやや劣っている
  • 3：既存システムと同等の品質・サービスレベル
  • 4：既存システムよりもやや優れている
  • 5：既存システムよりもかなり優れている
• 評価の付け方は既存の自社レコメンドシステムと相対的に比較して行うこと。

最終判断

• サービスの評価は以下のメンバーにて行うこととする。
  • プロジェクトオーナー
  • プロジェクトマネージャー
  • システム部バックエンドエンジニア
  • マーケティング部データ分析担当
• 選定されたサービスの説明と評価を実行後、POが最終決定することとする。

補足

サンプルプロジェクトでは社内システムの開発エンジニアやデザイナーが既にアサインされていますが、もし未アサインの場合やそもそもエンジニアが社内にいない場合などもあります。

その場合、どのようなスキルを持ったエンジニアがこのプロジェクトのために必要なのか、どのくらいの単価帯でリソースを調達するのかを固めた上で、スポットでエンジニアを確保する必要があるかもしれません。

サービスの選定と情報の取得

調達マネジメントの計画と要求事項をインプットとしてサービス選定を行なっていきます。 選定対象となるサービス提供者に連絡を取り、商品の説明や質疑応答の機会をセッティングします。 調達マネジメントの計画で定義した基準を元に、要求事項どの程度を満たすことができるかを定量的に判断します。

依頼先対応フロー詳細

自社でやること｜調達関連

• 要求事項の収集
  • 前回の記事、要求事項の収集を参照。
• リスクの特定
  • 前回の記事、リスクの特定、リスクの定性・定量的分析、リスク対策の計画を参照。
• リスクの定性・定量的分析
  • 前回の記事、リスクの特定、リスクの定性・定量的分析、リスク対策の計画を参照。
• 調達マネジメントの計画
  • 前回の記事、調達マネジメントの計画を参照。
• リストアップ
  • 要求事項をインプットとし、要求を満たせるサービスを提供している会社をリサーチしリストアップします。
• 提案の依頼
  • リストアップした会社へ連絡を取り、サービス利用に関して検討を行っていることを伝え提案を打診する。
  • 詳しい内容についての話をする前にNDAを締結しておくことをお勧めします。
  • また、この時に超概算レベルの見積りも併せて提案して欲しいと伝えておくといいと思います。
• NDAの締結
  • NDAとは秘密保持契約のことす。会社の法務担当などに相談すると自社の雛形がある場合が多いと思います。雛形がある場合はそれをプロジェクトに合わせた形に修正して受注側に署名してもらうといった流れで締結します。
• 面談の設定
  • 日時や面談方法などの調整を行います。
• 選定評価シートの記載
  • 面談が完了したら参加メンバー全員に事前に決めておいた選定シートへの記入を依頼します。
• 選定先の決定
  • 全ての提案をヒアリングし、選定シートを記載した後にプロジェクトオーナーに最終決定を依頼します。プロジェクトマネージャーが面談参加メンバーを集めてプロジェクトオーナーに説明し、検討の上決定することが多いです。
• 契約内容の事前確認
  • 契約書の雛形の確認
    • システム開発を伴う契約の場合、本契約には発注内容を記載せず別紙に記載するケースが多いです。また必ず自社の契約書フォーマットを用いて契約するとは限りません。そのため、まずは自社の法務担当などに相談してください。
  • スケジュールの作成依頼
    • 提案内容を具体化したスケジュールの作成を依頼します。開始時期はいつか、完了時期はいつか、どのタイミングでテストするかといった内容を作成し提案してもらいます。
  • 見積書の作成依頼
    • 正式見積りを提案してもらいます。この内容を確認し、契約・発注を行うかの最終判断を行います。
• 契約内容の承認
  • 契約書の調整、スケジュールと見積書の提案が行われた際に、プロジェクトオーナーに契約内容を確認してもらい、承認を取ります。ここで問題がある場合は、再度委託先と内容の調整を行うことになります。
• 契約書の締結
  • 契約書に双方の押印を行います。
• 発注書の作成と送付
  • 契約が締結された後に、発注書の作成と送付を行います。委託先が発注書を受領したら開発が開始できます。
• 定例会議の設定
  • スケジュールが提案・合意され開発が始まった後、週次レベルで委託先の進捗状況、自社の進捗状況を共有するタイミングを設けましょう。
• 支払いの実行
  • 支払いが完了したら委託先とのプロジェクトは完了です。次は運営フェーズに進んでいくことになります。

自社でやること｜品質関連

• 品質マネジメントの計画
  • この記事の品質マネジメント計画を参照。
• 品質に関する要求事項の作成
  • 品質マネジメントの計画にて作成した内容と要求事項やリスクの特定で明らかになった要求から、委託先に求める品質要求を作成します。
  • 機能面だけでなく、非機能面についても記載しておきます。
• 受け入れテストの準備
  • 受け入れテストの項目をピックアップし、リスト形式にまとめます。
  • 機能面だけでなく、非機能面も確認できる部分は確認します。
    • テスト環境が本番環境ではない場合、非機能面に関しては再現できない・テストできないものが出てくる可能性があります。その場合はリリース後に確認するケースもあります。リリース後確認事項が固まったら必ず事前に委託先と共有し、合意しておく必要があります。
• 受け入れテストの実施
  • テストがNGだった場合、委託先が再現確認のために必要な情報を提供します。テスト時の条件や発生時のエラー内容などを記録しておきましょう。
• 受け入れテストの完了
  • 受け入れテストの準備で作成したリスト全てがテスト完了となったら受け入れテスト完了となります。

共通の会議などでやること

共通の会議など同期的に実施する会議体で行われるものは以下のようなものがあります。

• 面談
  • 提案を依頼した会社との面談の際は定量的に比較検討できるよう、いくつか定型の確認事項を設定しておくといいでしょう。（開発コスト、開発期間、レスポンスタイム、同時リクエスト上限数 etc...）
• 定例会議の実施
  • この記事の調達のコントロールを参照。
• 開発完了と受け入れテストの開始
  • 委託先側の開発が完了したら受け入れテストの開始を宣言します。これ以降テスト可能な環境への変更を行う場合は情報を共有してもらうようにすることが必要です。先日テストしてNGだったものが今日テストするとOKになるといった状況になると、何が正しいのかがわからなくなってしまいます。
• 受け入れテストの完了報告
  • 受け入れテストが完了したことを委託先に共有し、後処理の開始を依頼します。

委託先がやっていること

委託先は大筋で以下のようなことを行っています。簡単な流れだけ知っていれば十分だと思いますので、詳細については割愛します。

• 要求事項の確認
• 初期提案の作成
• 契約内容の事前確認
• 発注書の内容確認と発注受書の返送
• 開発
• 請求書の発行
• 支払いの確認

調達のコントロール

基本的には定例会議を通して進捗状況の確認、課題の共有などを行って行きます。自社側のチームからの確認事項や課題の共有のみではなく、委託先からの確認事項や課題の共有を行います。可能であれば課題の解決なども行えるとよりスムーズにプロジェクトを進行させることができます。

委託先からスケジュールの組み替えなどの提案がある場合がありますが、そこで重要なのがマイルストーンとして設定されたスケジュールになります。例えば受け入れテスト開始日時などがそれにあたります。マイルストーンが変更されない限りにおいては提案に対して柔軟に対応することが多いです。

また「基本動作は対応完了しているが、エラー処理の一部が未完了になっているためレスポンスエラーに関しては来週から確認いただけるようになります」といったマイルストーン時点での申し送り事項を明確にしておくことが重要です。

開発の遅れによりプロジェクトが炎上するケースはよく見られますが、そういったプロジェクトをコントロールする方法としてはいろいろなやり方があります。個人的にはスコープのコントロールかマイルストーンの詳細化といった対応をするケースが多いです。細かい内容については書ききれないので、弊社の面談などにお越しいただけると幸いです。

最後に

いかがだったでしょうか。取引先が関係するプロジェクトはマネジメント難易度が社内のみのプロジェクトよりも高くなるケースが多いです。細かいですが必要なやり取りは慣れないうちは時間がかかりストレスを感じることもあるかもしれません。ですが一度乗り越えれば大きな自信につながると思うので気合をいれてやり切りましょう。

宣伝

株式会社WAPでは「日本企業が世界と戦うための伴走型リーダー育成」をミッションに掲げています。この困難なミッションに共に立ち向かってくれるプロジェクトマネージャーを募集しています。ちょっと気になったので話を聞いてみたい！という方も大歓迎です。Meetyにてお気軽にお申し込みください。