専門知識がなくても開発ベンダをうまく巻き込むには

プロジェクトワークの現場の具体的な悩みに対して、それをひもとくフレームワークとその組み合わせ方を解説！第７回のテーマは、「専門知識がない発注者の立ち居振る舞いはどうするか」です。

今回のQuestion

自分たちがシステム導入側で、システム開発業者に開発に入ってもらうプロジェクトを担当しています。技術面をサポートしてくれる専門人材が社内におらず、自分たち主体で進めなければなりません。このような場合、どのように開発業者を巻き込んでいけばよいのでしょうか？

Answer

請負契約は受託側に「プロジェクトマネジメント義務」が自動的に発生しますので、誰かしらは必ずPMの役割を果たす必要があります。つまり、発注側に専門知識がなくても適切に取り組みを進める義務がベンダ側にあるので、専門知識は本来、必要ありません。通常は、発注以前のやりとりのなかで、体制図やコミュニケーションの方法を確認し、適切にPMしてくれるベンダを探しましょう、ということが大前提です。

とはいえやはり、なんでもかんでもおんぶにだっこでは、うまくいきませんし、発注側が押さえておくことで受託側が動きやすくなるポイントもあります。

①役務提供契約の3類型（契約と交渉）

②V字モデル（情報システム・ソフトウェア）

③ロール定義（作業計画)

フレームワーク①　役務提供契約の3類型

要素：請負契約・準委任契約・派遣契約

まずは、どういう形でベンダに入ってもらうのか、そもそもの契約の形から考えます。請負契約は、発注側が仕様を明確に定義できることが前提の契約形態です。しかし専門サポートが社内にいない状態では、精緻な仕様を発注側だけで固めることは難しく、請負で契約してしまうと、後から「言った通りに作っただけ」という水掛け論が起きやすくなります。

専門知識がない側が主導する場合、業者の専門性を借りながら要件そのものを一緒に固めていく、準委任契約の形の方が実態に合っていることが多いです。まず、この契約形態の選択自体が、巻き込み方の土台になります。

フレームワーク②　V字モデル

要素：要件定義・システムテスト、基本設計・結合テスト、詳細設計・単体テスト、実装

次に覚えておくとよいのが「V字モデル」の言葉です。契約の形が決まったら、次にV字の左右のどちらを自分たちが持つべきかを線引きします。V字モデルの左側（要件定義、システムテスト＝受け入れテスト）は、業務を実際に使う側にしか判断できない領域であり、専門知識がなくても、ここは発注側が主導権を手放してはいけません。

逆に右側（詳細設計、実装、単体テスト）は、技術専門性がなければ判断できない領域であり、ここは業者の専門性に委ねてよい部分です。「専門サポートがいないから全部業者に任せる」のではなく、V字の左側だけは自分たちで握り続ける、という発想が、丸投げと過干渉の両方を避ける鍵になります。

フレームワーク③　ロール定義

要素：案件・製品・関係者・メンバー・資源・計画

契約形態とV字の分担が決まったら、最後にそれを実務レベルの役割として具体化します。特に重要なのが、V字の左側を発注側が握り続けるためには、発注側の中で「誰が要件を最終判断するか」「誰が受け入れテストの合否を決めるか」という役割を、名前付きで明確にしておくことです。

専門サポート不在の状態では、この役割が曖昧なまま進むと、業者側が「発注側の誰に確認すればいいか分からない」まま進めてしまい、後になって「そんな話は聞いていない」という事態を招きます。ベンダを巻き込むことの本質は、外部の専門家に多くを求めることではなく、自分たちの側の役割をはっきり示すことでもあります。

まとめ

専門知識を持たずに、なにかしらの専門性のあるものを発注したり、導入したりするのはプレッシャーがかかりますよね。しかし、対価を支払う以上は、つくる人と同等の専門知識を保つ必要は、まったくありません。

一方で、外部の専門家が動きやすくなるためのコミュニケーションや役割、進め方については理解しておくことをお勧めします。

参考：あなたの悩みの解決法が、必ず見つかる一冊。

無料ワンポイントアドバイスサービスも、よろしければご活用ください！

プロジェクトのワンポイントアドバイス

執筆者のご紹介