下請けからパートナーへ〜企業に問われる発注スキル〜

はじめに

先日、このようなニュースを見ました。大手証券会社と大手Slerのシステム開発のプロジェクトでの訴訟の行方を報じていてます。

「プロジェクト失敗の原因は仕様凍結後も変更要求を多発したユーザー（発注）企業にある」
https://xtech.nikkei.com/atcl/nxt/news/18/11853/

これは、長く日本の製造業、ゼネコン、その他のあらゆる業種で長年、当たり前とされていた発注側>受注側の力関係が変化し、今後は発注側⇄受注側が共に同じゴールを目指すパートナー型がプロジェクト成功へと導くのには当たり前のスタンスとなる時期が本格的に始まると個人的には感じています。

その背景にあるのは、高度スキル人材の不足、革新の必要性です。現在、大企業といえど、エンジニア等の高度スキル人材の採用は困難で、さらにイノベーションの推進が大命題になった昨今では、新しい分野に明るい人材を自社内で人材を完結することが極めて困難になっております。

今noteでは発注側がベンダーと付き合う際のTipsを記載致します。発注側、受注側（ベンダー）と表現すること自体が良くないと感じますが、ここでは便宜上、発注側とベンダー（受注側）と記載致します。

今後は、外部企業との連携がさらに増える可能性が極めて高い状況です。そこで、発注側がベンダーを下請け業者としてではなく、パートナーとしての関係構築を根付かせないと、引き受ける企業がなくなる可能性すらあるのではないかと感じております。

パートナー企業として対等な関係を構築することで、引いてはプロジェクトの成功に近づくはずです。それでは本編に入ります。

対象読者
-大企業でDXの推進をされている方
-非エンジニアの起業家
-ITベンダー（この言い方好きじゃないけどw）とコミュニュケーションとる必要がある担当の方

何がわかるか
-ITベンダーと付き合う時のTips

何でこれ書いているか
-大学時代の友人がある団体のDX担当者にいきなりなって相談がきた
-そういえば、こうゆう相談多いな
-実際、日々のクライアントワークでいくつか発注側が注意した方が良い点がわかってきた

企業がベンダーに発注する時の2つのTIPS

1. 予算、納期、要件（未確定orもりもり）のどれかは歩みよらなければブロジェクトは破綻する
   
   システム開発のプロジェクトは、企画→開発→改善/保守→内製化のようにフェーズが進むとここでは定義します。
   開発フェーズ段階で、予算と納期が決まっていて、要件は未確定かもりもりという状況でベンダーを探している状況が驚くほど現場には多いです。
   
   これは、既に企画フェーズの部分は社内かコンサル（エンジニアがいない）等が介入して完結しているケースが想定されます。アウトプットとして現実的な３要素をアドバイスできるエンジニアが企画段階に入っていないことが多いので、まず企画段階で破綻しているケースが多いです。
   さらに、開発段階に入って、無謀だとエンジニアが気づいたところで組織の承認プロセスフローに起因してまき戻せないこという問題があります。
   
   解決策とししては前述したように、企画段階からエンジニアをアサインして現実的な開発計画をパートナーとして一緒に考えるのが理想です。ただし、既に企画段階が終わっている状況ではその施策は打てないので、現実的な解決策としてはほとんどが仕様を極限まで下げる調整になるかと思います（ここが大切です）。企業のプロジェクトのほとんどが、予算と納期が決まっているのでここを動かすことができれば、その施策もありえますが基本的に動かしにくいと思います。ベンダーとコミュニュケーションをとる発注担当者は、予算と納期が決まったプロジェクトであれば社内のあれもしたいこれもしたいという意見を鉄の意志で投げ返し、現実的な計画でプロジェクトをスタートさせることが重要になります。
   

2. 誰が作るのかを確認する
   発注担当者はIT知識に乏しく、工数の管理ができないことがケースが多いと思います。その際には、せめてプロジェクトメンバーのバックグラウンドはチェックするようにしましょう。また、ベンダーが再委託する先がある場合は再委託先の確認と再再委託を認めるかの観点も必要になります。企業間取引なので、企業に丸投げしているケースでは誰が最終的には成果物を作っているのかわからないケースも多いです。発注側がプロジェクトメンバーのバックグラウンドをチェックすることでベンダー側から出される見積もり（逆にバッファをもりもりにしているケースも多い）や、アサインメンバーの質の担保の抑止力にもなります。大手企業のプロジェクトは（大手企業）発注者→大手コンサル→大手ベンダー→中小開発会社→フリーランスのような商流は珍しくないので、結局開発会社やフリーランスの誰が開発しているか発注側からすると見えにくい構造で、成果物を出す作り手が見えないのでプロジェクトが有事の事態になった時に膨大なコミュニュケーションコストがかかりリカバリーをするのが極めて難しくなります。

もう一つ、請負と準委任契約とをうまく使い分ける必要があるのですが、これは一長一短で判断が難しいので、ここでは割愛致します。

最後に

弊社では大企業のDX推進、非エンジニア起業家のプロトタイプ開発支援にこれまでパートナー企業として多くのサポートをさせて頂いてきました。開発プロジェクトのラフにご相談承りますので、お気軽にご連絡ください！
https://gaogao.asia/contact/