ベンダー活用して開発のQCDを達成する方法 – ベンダーマネジメント

【目次】
・はじめに
・なぜベンダーマネジメントが必要か
・プロジェクト開始前のポイント
　- プロジェクトの認識合わせ
　- ベンダー提示の見積もり
・プロジェクト遂行中のポイント
　- 進捗管理
　- 課題管理
　- 品質管理
　- 仕様変更管理
・プロジェクト完了時のポイント
　- 検収
　- ベンダー評価

はじめに

システム開発ではベンダーに開発を委託するケースが多いです。

外部委託ではユーザ企業がベンダー企業に発注したり、そのベンダー企業が別のシステム会社に再委託をして成果物を調達します。
しかしIT業界では委託した成果物が期待通り完成しない場合があります。

その場合、請負契約だから責任はベンダー側にある、という意見もありますが、予定通りの成果物が出てこなければ困るのは発注者側です。
周りを見渡した時、ベンダーに丸投げしているプロジェクトの多くでトラブルが起きているのではないでしょうか。

そうならないためにも、発注者として期待通りの成果物が出てくるようにベンダーマネジメントすることが大切です。
当然、請負契約なので発注者がベンダーのメンバーに指示を出すといったコンプライアンス違反はしてけません。
許される範囲でベンダーコントロールすることが前提です。

今回は、ベンダーに開発を発注するときに、QCDを確保するためのマネジメントについて解説します。

（補足）
ここでいうベンダーには、システム会社に再委託するケースも含みます。

なぜベンダーマネジメントが必要か

JUAS（日本情報システム・ユーザー協会）がまとめた「企業IT動向調査報告書2022」によると、500人月以上のプロジェクトで「予定どおり完了」している割合は次の通りです。（2021年度調査）

Q（品質）　：10.6%
C（コスト）：17.1%
D（納期）　：13.9%

上記以外は「ある程度は予定どおり完了」「不満／予定より超過／予定より遅延」であり、何かしら問題があったプロジェクトです。
驚きの成功率の低さです。

次に、予定どおりにならなかった要因についてのアンケートです。

工期、コスト、品質いずれもベンダーのスキル不足が要因となっています。
特に品質については半数が該当すると言っています。

このような結果を見れば、ベンダーに丸投げすることがリスクであることわかります。
これはベンダーが悪いという話ではなく、相互の連携を上手くとることで問題を回避することが出来ることもあります。

プロジェクト成否を運任せにするのではなく、成功の確度を高めるためにベンダーを上手く活用して成功の確度を高めることがベンダーマネジメントの目的です。

プロジェクト開始前のポイント

ベンダーマネジメントはプロジェクト開始前から始まっています。
ここではベンダーに発注する前（契約締結前）に注意すべきポイントについて説明します。

プロジェクトの認識合わせ

開発を委託するとき、要件定義やRFPといったシステムに関する情報と同じくらい必要なのがプロジェクト計画書です。
発注側、受注側どちらの立場としても、１つのプロジェクトの中で活動するため、どのような計画で進めるのか認識合わせを行います。

プロジェクト計画書をもとに内容をすり合わせ、あらかじめベンダーからの要求事項を確認します。
ここを曖昧にして後からベンダーに対応できないと言われても困ります。
ベンダー側に無理させても、良い結果にはつながりません。

そのため契約段階、もしくはプロジェクトキックオフの前には計画の調整・合意を完了させます。

プロジェクト計画の内容については別記事「プロジェクト計画書」を参照してください。

ベンダー提示の見積もり

ベンダーが出してくる見積もりを見れば、ベンダーのプロジェクト理解度がある程度わかります。
そのため見積もりの詳細を確認したいのですが、会社によっては見積もりの内訳を「出せません」と言われることがあります。
それは会社の人月単価を知られたくないという理由が多いです。

発注者側としては、各内訳の規模感を知りたいというのはありますが、注意すべきは作業内容や見積もりの考え方が正しいか確認することです。
そのような場合は、金額や規模を空欄にしたもので良いので、検討した内容がわかる情報を提供してもらうよう交渉しましょう。

もし見積もりがどんぶり勘定の場合、開発するシステムを理解していない可能性があります。
概算見積もりではないのに、内訳を出せない場合は検討するだけの情報が足りない可能性があります。

プロジェクト遂行中のポイント

進捗管理

定期的にベンダーと進捗会議を行いますが、ただベンダーから上がってきた報告を真に受けるだけでは正しい状況把握ができません。
進捗管理の基本なのですが、ベンダーマネジメントでも次のコントロールが必要です。

マスタスケジュールの統一

マスタスケジュールやWBSについては、基本的に各社で用意するのではなく１つにまとめます。
WBSは会社都合により決められたフォーマットがある場合もあるので統一できないこともありますが、少なくともマスタスケジュールは1つです。

発注者側と受注者側で別々でマスタスケジュールを用意すると、スケジュール不整合によりトラブルが発生します。
そうでなくても、スケジュールの整合性確認は大変で工数がかかります。

報告は「困り事」「問題点」が重要

進捗報告で必要なのは問題や課題を共有し、的確な対処を行うことです。
しかし、ベンダーからの報告は基本的に良い面を強調して報告されてきます。
そのため、報告の中で「問題なし」となっていても安心せず、少しでも気になる点があれば質問し、問題点を炙り出すように心がけます。

そこで重要になるのは、問題をベンダーから報告してもらえる関係性を構築することです。
ベンダーから問題やトラブル報告があったときに「相手を責める」「必要以上に追及する」「膨大な調査指示を出す」といった対応をすると、ベンダーは問題を隠蔽するようになります。
これは「報告しないベンダーが悪い」という話ではありません。
そうではなく、問題のある報告をしてもらうためには「問題を報告されても責めない」「むしろ報告に感謝する」くらいの心づもりが必要です。

心理的安全性を確保しましょう。

定期的に成果物を確認する

進捗報告どおりに作業が進んでいるか、定期的に現物チェックします。
予定していた成果物が報告通りできているか、成果物が想定の出来具合なのか、品質に問題ないのか、など早期に確認することで納品時に検収できない品質になっていることを抑止します。

特に付き合いの少ないベンダーの場合は要チェックです。
工程終了間際にあって「実は終わっていませんでした」という残念なことにならないよう注意しましょう。

成果物の格納ルールは契約時やプロジェクト計画で調整します。
何の調整もなしに、いきなり「成果物を格納して」と言われてもベンダーは困ってしまいます。

遅延対策に「高稼働でカバー」はNG

プロジェクトで進捗遅延が発生したとき、そのリカバリ方法が「メンバーが高稼働（要するに残業）でリカバリします」しか報告されない場合は要注意です。

半日から１日程度の遅延であれば目をつぶることもありますが、数日の遅延を残業でリカバリすることは避けるべきです。
2人日（16h）をリカバリするとき、1人が1日2時間残業したとして8日を要します。
もちろん当初予定の作業は遅延なく終わらせることが前提です。
これではメンバーが疲弊してしまい、生産性が低下して進捗遅延に拍車がかかります。

考えられる対策として「他メンバーとの作業調整」「メンバーのサポート強化」「バッファ使用」などプロジェクトとして対策をとるのが正しいです。
状況によっては残業や休日出勤せざるを得ない場合もありますが、それは最終手段です。

そのような対策を考えず最初から高稼働でカバーする報告をするPMがいたら、マネジメント能力が不足しているかもしれません。
進捗管理以外でもマネジメントが上手くいっていない可能性があります。

課題管理

プロジェクトでは課題やTODOが発生します。
発注者と受注者が課題を共有することは重要であり、それを円滑にするために次の点に気をつけます。

共有する課題管理を用意する

当たり前の話ですが、共有する課題一覧は相互に管理するのではなく１か所で管理するべきです。
しかし発注者と受注者で作業場所が違う場合などファイルを共有することができない場合もあります。
しかし、相互で課題一覧を管理すると更新した内容の連携、マージする作業が発生するため非常に効率が悪いです。

例えば、Redmineなどのツール活用、Boxなどのクラウドストレージ活用など検討しましょう。

課題管理の管理ルールを設定する

課題一覧の最新化ルールを発注者と受注者の間で取り決めます。
課題一覧を適正に運用するには、更新方法、決着管理のルール、期限切れの課題チェックが必要になります。
課題管理の責任者を設定し、定期的な棚卸を行うと良いでしょう。

品質管理

前述のように、多くのプロジェクトで品質問題が発生しています。
これは当然ベンダー側の品質管理に問題があるわけですが、だからと言って発注者側が何もしなくてよい話ではありません。
低品質な成果物が仕上がってきたときに、困るのは発注者です。
発注者側も品質状況をチェックし、問題があれば是正するような行動をとることで成果物の品質を確保するべきです。

そのためにはプロジェクトの成果物の品質を定期的に確認するための途上報告を受けます。
途上報告の実施間隔はプロジェクト特性によりますが、月次くらいで実施したいところです。
体裁がしっかりした報告書を毎回作成するのは作業量が大変なので、品質の傾向と対策を箇条書きで報告してもらう程度で良いです。
もちろん品質途上報告してもらうには、その報告に要する工数が発生するので、あらかじめ見積もりに含めて契約します。

もし契約時から品質途上報告を嫌がるベンダーであれば要注意です。
プロジェクトが超短納期といった理由がない限り、品質管理の重要性を理解していない可能性があります。
そのようなベンダーは、正しい品質分析を行うスキルがないと思われます。

一番困るのは、品質の分析と対策が十分に行われないことです。
そうならないためにも、必要あれば品質分析の仕方をベンダーに指導しながら進めることも検討します。

品質分析の方法については、別記事「品質マネジメント計画」を参照してください。

仕様変更管理

プロジェクトのQCDを脅かす原因として、想定外の仕様追加や変更が多発することが考えられます。
仕様変更については、プロジェクト計画と調整しながら無理のない方法で対処するのですが、気づかないうちに仕様が膨れ上がっている場合があります。
小さな仕様変更、なし崩し的な要求の多発により仕様変更が山積みになることをPMBOKでは「スコープ・クリープ」と言います。

依頼を出す側としては、無償で変更してもらえるのは良い話に聞こえますが、プロジェクトのQCDを悪化させる大きな原因なので避けるべきです。
仕様変更のルールを徹底し、スコープ・クリークが発生していないか発注者側からも注意します。

プロジェクト完了時のポイント

検収

成果物を検収するということは、発注者側が要求する事項を全て満たしていることを確認する行為です。
もちろんシステムが正常に稼働していることも検収条件ですが、ドキュメントやマニュアルの整備、トレーニングなどの付帯作業も検収条件に入ってきます。
システム稼働したからといって十分な成果物チェックを行わずに納品を受け入れて検収すると、後から不足分を見つけてトラブルになる可能性があります。

他の注意点ですが、検収した日付から瑕疵（契約不適合）の期間が開始します。
納品が終わっていないのに検収すると、不具合を検知してもベンダーに対応してもらえる期間が短くなります。

必ず、全てが完了してから検収するようにしましょう。