開発会社に任せきりにしないベンダーコントロールの進め方

システム開発を外部に依頼すると、作業の大半は開発会社が進めます。そのため発注側は「専門家に任せたのだから、あとは報告を待てばよい」と考えがちです。ところが、仕様の判断や優先順位の決定まで開発会社に預けてしまうと、完成したシステムが業務に合わない、費用がいつの間にか増えている、といった問題が起きます。

こうした事態を防ぐために発注側が行う管理を、ベンダーコントロールと呼びます。ベンダーコントロールは、開発会社を細かく監視することではありません。発注側が持つべき判断と情報を手放さず、開発会社が力を出しやすい状態を保つための仕組みです。

情報システム部門がない中小企業でも、ベンダーコントロールは実践できます。必要なのは技術の知識よりも、何を手元に置き、どの場面で誰が判断するかを決めておくことです。

この記事では、ベンダーコントロールとベンダーマネジメントの使われ方の違いを整理したうえで、任せきりになる原因、発注側が手元に持っておくべきもの、定例会と進捗報告の使い方、自社の体制に合わせた管理の範囲を解説します。

ベンダーコントロールとベンダーマネジメントの使われ方の違い

ベンダーコントロールとベンダーマネジメントは、どちらも発注側が外部の開発会社とどう関わるかを表す言葉です。公的な定義で区別されているわけではなく、使う人や会社によって意味の幅が異なります。ただ、実務での使われ方にはある程度の傾向があります。

言葉	よく使われる場面	主な対象
ベンダーコントロール	開発プロジェクトの最中に、発注側が開発会社の作業を管理する場面	進捗、品質、仕様の範囲、変更の判断
ベンダーマネジメント	取引先としての開発会社を、選定から契約、評価、関係の維持まで含めて管理する場面	選定基準、契約条件、取引の評価、複数ベンダーの使い分け

大まかにいえば、ベンダーコントロールは一つのプロジェクトの中での管理を指すことが多く、ベンダーマネジメントはそれを含む、より広い取引管理を指すことが多い言葉です。大企業の情報システム部門では、ベンダーマネジメントを調達や契約管理の一部として扱い、ベンダーコントロールをプロジェクトマネージャーの仕事として扱う、という分け方も見られます。

中小企業が一つの開発を発注する場面では、両者を厳密に分ける必要はありません。この記事では、開発の最中に発注側が判断と情報を手元に置き続けることをベンダーコントロールと呼び、その中身に絞って説明します。開発会社の選び方や評価基準は、ベンダーマネジメント側の話として別に検討してください。

なお、「コントロール」という言葉から、発注側が一方的に指示を出すイメージを持たれることがあります。しかし、システム開発は発注側と開発会社の共同作業です。IPA（情報処理推進機構）が公開している「情報システム・モデル取引・契約書」の解説では、裁判例で問題になる開発会社のプロジェクトマネジメント義務と発注側の協力義務について、一方が主でもう一方が従という関係ではないと説明されています。発注側が自分の役割を果たすことも、ベンダーコントロールに含まれると考えるのが実態に合っています。

参考：情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）〈第二版〉／IPA（情報処理推進機構）

任せきりになるのはどんなときか

発注側が任せきりの状態になるのは、担当者の意識が低いからとは限りません。多くの場合、判断に必要な情報が開発会社の側にしかなく、発注側は報告を信じる以外に方法がない、という構造ができあがっています。

典型的なのは次のような状態です。

• 進捗報告が「順調です」「8割完了です」といった言葉だけで、何が終わったのかを確かめる材料がない
• 打ち合わせで決まったことが、開発会社のメモにしか残っていない
• 仕様の変更や追加の要望が、現場の担当者から開発会社へ直接伝わっている
• サーバーやドメイン、ソースコードの管理場所に、発注側がアクセスできない
• 開発会社からの質問に誰が答えるのかが決まっておらず、回答が遅れる

これらに共通するのは、発注側が「確かめる手段」と「決める手順」を持っていないことです。確かめる手段がなければ、報告が実態とずれていても気づけません。決める手順がなければ、仕様は会話の流れで少しずつ広がっていきます。

前述のモデル契約の解説では、裁判例を引きながら、オーダーメイドのシステム開発は開発会社だけでは完成できず、発注側が社内の意見を調整して要望を明確に伝え、機能や画面・帳票を決定し、成果物を検収するといった役割を分担する必要があると説明しています。言い換えれば、発注側の判断が抜けた部分は、誰かが代わりに決めるか、決まらないまま残ります。開発会社が代わりに決めた内容は、業務を知らない立場での推測になりやすく、後から「思っていたものと違う」という形で表に出ます。

ベンダーコントロールの出発点は、開発会社を疑うことではなく、この構造を変えることです。次の章で、そのために発注側が手元に置いておくべきものを具体的に挙げます。

発注側が手元に持っておくべき5つのもの

ベンダーコントロールに必要なのは、高度な管理手法ではなく、発注側がいつでも見られる場所に置かれた情報です。次の5つがそろっていれば、技術に詳しくない担当者でも状況を把握し、判断を下せます。

決定事項と未決事項の一覧

打ち合わせで決まったこと、まだ決まっていないこと、決まっていない事項を誰がいつまでに決めるかを、一つの一覧にまとめます。開発会社が作る議事録を受け取るだけでなく、発注側が内容を確認して承認する形にしておくと、後で認識が食い違ったときの拠り所になります。

モデル契約の第12条では、開発会社が連絡協議会の議事録を作成して発注側の承認を得ること、議事録には少なくとも決定事項、継続検討とされた事項、継続検討事項の検討スケジュールと担当者を記載することが定められています。あわせて、発注側が定められた期間内に具体的な理由を示して異議を述べなければ承認したものとみなす、という規定例も置かれています。自社の契約に同様の規定がある場合は、議事録を読まずに放置すると内容を認めたことになりかねないため、受け取ったらその週のうちに確認する習慣をつけてください。

成果物の最新版

要件定義書、画面の設計書、テスト計画書など、工程ごとの成果物の最新版を、発注側が管理する共有フォルダにも置いてもらいます。メールの添付で受け取るだけでは、どれが最新か分からなくなります。版と日付が分かる状態にしておけば、変更があったときに差分を確かめられます。

アカウントと権限

サーバーやクラウドの管理画面、ドメイン、ソースコードの保管場所、外部サービスのアカウントについて、契約者が誰か、発注側の誰がアクセスできるかを一覧にします。開発中は開発会社が操作しやすいように権限を渡してかまいませんが、契約の名義と管理者権限は発注側に残しておくことが重要です。開発会社と連絡が取れなくなったときや、保守を別の会社に移すときに、この一覧があるかどうかで対応の難しさが大きく変わります。

進捗の根拠

進捗は割合ではなく、終わった成果物で確かめます。「画面設計が8割」ではなく「20画面のうち16画面の設計書がレビュー済み」のように、数えられる単位で報告してもらうよう、最初に依頼しておきます。開発途中の画面を実際に触れる環境があれば、なお確実です。

変更の台帳

仕様の変更や追加の要望を、受け付けた日、依頼者、内容、費用と期間への影響、採否、判断者の欄を持つ台帳で管理します。モデル契約でも、仕様の変更は変更管理書を使った手続によってのみ行う形が示されています。台帳があれば、口頭での「ついでにお願い」が積み重なって費用が膨らむことを防げます。

持っておくもの	ないと起きること	最初の一歩
決定事項と未決事項の一覧	言った言わないの争いになる	議事録の承認ルールを決める
成果物の最新版	古い版で判断してしまう	発注側の共有フォルダを用意する
アカウントと権限	保守の切り替えや障害対応ができない	契約名義と管理者を一覧にする
進捗の根拠	遅れに気づくのが終盤になる	数えられる単位で報告を依頼する
変更の台帳	費用と期間が少しずつ膨らむ	要望の窓口を一人に絞る

参考：情報システム・モデル取引・契約書〈第二版〉ソフトウェア開発委託基本モデル契約書（ひな型）／IPA（情報処理推進機構）

定例会と進捗報告をどう使うか

多くの開発プロジェクトでは、発注側と開発会社が定期的に集まる定例会が開かれます。定例会を報告を聞くだけの場にすると、発注側は情報を受け取るだけで、判断の機会を失います。ベンダーコントロールの観点では、定例会は「確かめる場」と「決める場」として使います。

モデル契約の第12条では、連絡協議会で扱う事項として、進捗状況、リスクの管理と報告、双方の共同作業と分担作業の実施状況、仕様に盛り込むべき内容の確認、問題点の協議と解決などが挙げられています。さらに、開発会社は取り決めた様式の進捗管理報告を提出し、遅延の有無、遅延があるときはその理由と対応策、体制の変更の要否などを協議することになっています。自社の契約にここまでの規定がなくても、定例会の議題をこの項目に沿って決めておくと、確認の抜けが減ります。

定例会の議題	発注側が確かめること
前回からの進捗	予定していた成果物が実際に終わったか。終わっていないものは何で、いつ終わるか
遅延とリスク	遅れの理由が発注側の回答待ちか、開発会社の作業か。対応策は誰が何をするのか
発注側の宿題	開発会社から依頼された確認や資料の提出が、期限どおりに終わっているか
変更と追加の要望	台帳に載った要望の費用と期間への影響。今回採用するか、見送るか
次回までの予定	次回の定例会で確認できる成果物は何か

見落とされやすいのが、発注側の宿題です。開発の遅れは、発注側の回答や資料の提出が遅れたことから始まる場合も少なくありません。モデル契約の進捗管理報告の参考例でも、開発会社から提示された発注側が解決すべき事項について、発注側からも報告する必要があると書かれています。定例会では、開発会社の進捗と同じ重さで自社の宿題の消化状況を確認してください。

報告の受け取り方にも工夫ができます。報告書の数字に違和感があれば、その場で根拠となる成果物を見せてもらいます。テストの段階であれば、計画したテスト項目数、実施済みの数、見つかった不具合の数と未解決の数を、毎回同じ形式で出してもらうと推移が分かります。数字の推移が急に良くなったときや、何週も変わらないときは、理由を聞くきっかけになります。

自社の体制に合わせて管理の範囲を決める

ベンダーコントロールの範囲は、会社の体制や契約の形によって変わります。すべてを同じ深さで管理しようとすると、兼務の担当者では手が回らなくなります。自社の状況に合わせて、どこまでを自分たちで持つかを決めることが大切です。

状況	発注側が必ず持つもの	任せてよいもの
情シスがなく、担当者が兼務	決定事項の一覧、変更の台帳、アカウントの名義と管理者権限、受入の判断	技術的な作業計画、設計の内部構造、テストの実施方法
社内にIT担当者がいる	上記に加え、進捗の根拠の確認、主要な成果物のレビュー	プログラムの書き方、開発ツールの選定
複数の開発会社に分けて発注	上記に加え、会社間の仕様の整合とスケジュールの調整	各社の内部の作業管理

複数の開発会社に分けて発注する場合は、特に注意が必要です。モデル契約の第13条では、発注側が開発を分割して発注し、連携するソフトウェアを第三者が開発している場合、機能の整合性やスケジュールの調整、各社の進捗管理と調整については発注側が責任を負う形が示されています。会社間の調整を誰も担わないまま分割発注すると、つなぎ目の不具合が終盤まで見つからず、責任の所在も曖昧になります。調整を自社で担えないなら、分割発注をやめて一社に任せるか、調整業務そのものを契約として誰かに依頼するかを選んでください。

契約の形によっても力点が変わります。準委任契約で開発を進める場合は、作業の進め方や優先順位を発注側が決める場面が多くなるため、定例会での判断の比重が高くなります。請負契約の場合は、完成させる義務は開発会社にありますが、何を完成させるかを決めるのは発注側です。要件や設計の確定、変更の判断、検収といった場面で、発注側の判断が求められることに変わりはありません。

社内に判断できる人がいない場合は、発注側の立場で助言する外部の専門家に、要件の整理や成果物のレビューを依頼する方法もあります。その場合でも、採否を決めるのは社内の責任者です。助言者に判断まで預けると、任せきりの相手が開発会社から助言者に変わるだけになります。

まとめ

ベンダーコントロールは、開発会社を監視することではなく、発注側が持つべき判断と情報を手元に置き続けることです。ベンダーマネジメントが選定から評価までを含む広い取引管理を指すのに対し、ベンダーコントロールはプロジェクトの最中の管理を指すことが多く、中小企業の一つの開発ではこちらが実務の中心になります。

任せきりの状態は、担当者の意識ではなく、確かめる手段と決める手順がないことから生まれます。決定事項と未決事項の一覧、成果物の最新版、アカウントと権限、進捗の根拠、変更の台帳の5つをそろえれば、技術に詳しくない担当者でも状況を把握できます。

これから開発を始めるなら、契約前に定例会の頻度と議事録の承認ルール、進捗報告の形式、アカウントの名義を開発会社と決めておいてください。すでに開発が進んでいるなら、まず変更の台帳とアカウントの一覧を作り、次の定例会の議題に自社の宿題の確認を加えることから始めると、無理なく管理の形を整えられます。