システム開発受発注に見る上下関係の間違いとあるべき理想の話
システム開発に限った話ではないけれど、技術リソースを外注した時の受注、発注の関係性に上下があると勘違いしてる人が多すぎる。上下関係ならまだしも、本来思考すべき領域や責任まで転嫁している節もある。
金銭の流れだけを見れば、発注→受注なわけで、そういう思いを抱いてしまうことも理解できなくはない。しかし、受注→発注に対しても、大切な価値が提供されているし、本来その先にユーザー（システムを使う人）がいるはずであることを忘れてないだろうか。
よくある発注側の勘違いマインド
お金を出しているのだから全部やってもらえて当然
お金をかけて作ったのに売れないのは開発会社のせい
一度作り終えたらもうお金はかけたくない
金銭の対価でしかシステムの価値を測れていない経営者がやりがちな勘違い。
「お金は払うので、まるっとお任せしたいんです」
「御社に開発してもらった機能が伸びないので（タダで）作り直してください」
「マーケットとのずれは御社の考慮漏れなので（追加費用なしで）市場調査からやり直してください」
「こちらは最初にお金を払ったのだから…（以下略」
そんな依頼を聞くことや、知人の開発会社から揉め事を相談されることもある。
実際に「まるっと請け負います」をウリにしている開発会社も少なくないわけだけれど、その「まるっと」はあくまでシステム開発に関するスコープを意図するものであって、ビジネスを成功させる責任や義務が含まれているのだろうか。
もちろん昨今のバズワードでもある「DX化」の支援を掲げて、社内と並走して事業・システムづくりの両方を担ってくれるベンダーも多い。
だがしかし、どこまでいってもそのビジネスの最終責任を持つべき者は事業主でしかないのだ。
「ビジネスを考えることさえも外注してしまったら、その会社はなんのために存在しているのか…。」という話は、以下記事でも触れている。
よくある受注側の勘違いマインド
お金をいただいているのだから逆らってはいけない
赤字になっても要望通りに作りきらなければいけない
発注元の要望が第一、本当に使われるかどうかは知ったこっちゃない
一方で、システム開発を受注する側にも問題がないわけではない。
「お金をもらい目先の売上を立てること」に気をとられていると、上記のようなマインドになってしまう場面もあるのではないか。
これまでに「強く言えなくて結局追加費用なしで開発してしまいました」といった相談を受けることも多々あった。
強く言う必要はないにせよ、「上下関係」というマインドから解放されていれば最初からこんな揉め事が起きることは少ないんじゃなかろうか。
アウトプットとアウトカムの責任と矛盾
ではどうしてこのようなことが起きてしまうのかというと、このシステム受発注の関係性の中に、肝心な「ユーザー（システムを使う人）」の話が一切出てこないことが一つの要因ではないかと思っている。
成果物のアウトプットはユーザーの価値ではない
システム開発ベンダーが開発をし、納品したそのシステムは、そのままユーザー価値に直結するかというと大抵の場合そうではない。
そのシステムが誰に、いつ、どう使われるか、いくらでどんな価値を生むのか、それらの導線設計があってこそアウトカムに繋がる。
アウトカムをつくるべきは誰か
では、誰がアウトカムに責任を持つのかというと、やはりここは事業主（発注元）でしかない。
ビジネスを仮説検証するのも、方針を意思決定するのも、必要と判断された技術的な専門リソースを開発ベンダーに協力依頼するのも事業主である。
だけれど、そのほとんどの事業主がアウトカムを生み出せない。
この矛盾解消の鍵は、プロダクト開発の内製化にあるのではないだろうか。
矛盾の解消とプロダクト開発の内製化
システムを開発している側からすると当たり前のことなのだけれど「システム開発はリリースしたらゴールではない」し、むしろ事業としては「リリースできたところがスタート」になる。
だから「作り終わる」なんて概念はないし、サービスが継続される限りシステムも開発し続けられなければならない。
そのためには、いくつか必要な観点がありそうだ。
事業会社側のPM創出
プロダクト開発を内製化する上で、PMの存在は欠かせないだろう。
プロダクトマネージャーが無理なら、まずはスコープを絞った「プロジェクトマネージャー」でも良い。事業に近しいポジションに、ユーザーと開発組織を橋渡しできる存在が必須だ。
プロダクトマネージャーは「What（何を作るのか）」「Why（なぜ作るのか）」を考える
プロジェクトマネージャーは「When（いつまでに）」「How（どうやって作るのか）」を考える
外注リソースの内製的活用
前述のように、「発注」「受注」「納品」のようなプロセスでシステム開発をしていては、社内にノウハウも蓄積せず、納品して開発組織が解体してしまった途端、誰も継続的改善ができない。
とはいえ、優秀なIT人材の採用は本腰を入れなければ難しいことは誰もがわかっているであろう。
だからここであえて「外注リソース」という表現をしたけれど、会社や所属が違えど、同じシステムを開発するチームなのであれば、社内にノウハウが蓄積する方式で「擬似内製的」に開発組織を構築することをおすすめしたい。
いかに高速デリバリーするかを争う昨今で、情報を「発注」「受注」などで分けて会社間で分断していては非効率なのだから。
これらがまず最低限、システム開発受発注における関係性で是正したい理想のお話である。
このシーンでのPMに何ができることが望ましいか、会社間でどのように擬似内製的な開発組織を構築できるかは、また次回noteで言及したい。
続き↓
＊━━━━━━━━━━━━＊
PeerQuestでは、ITプロダクト成長期のプロダクトマネジメント、プロジェクトマネジメント内製化を支援しています。
PM不足でお困り事があれば課題をお聞かせください。
お気軽にTwitter DMまで🔻
https://twitter.com/maidol_28
いただいた応援の気持ちは、私が良いなって思ったコンテンツへの応援の気持ちとして次に繋げます☆+*