内製化でやりたい気持ち

SIerだと受託になるので、契約を介して委託元とプロジェクト業務を分担する。得てして、RFPや見積もり依頼書がザルだとリスクてんこ盛りでコンテンジェンシを山のように盛らざるを得ない。顧客第一とかカスタマーサクセスと言いつつも、契約は最後の砦だから、掛け声と実態の溝は埋まらない。ここを上手に運用するプロジェクトマネージャは手練れであるから委託元も手羽さない。

一方、委託元である事業会社の立場で見れば、自分たちでできない技術領域やリソースを確保できないから業務委託をするのであり、事業会社のプロジェクトの成功(実現したいことを実現する)のために、それを一緒に実現してくれる業務委託先とやりたいと考える。

SIのプロジェクトをSIerの立場で意識していたのは、プロジェクト全体として成功するための意思決定かどうかだ。もちろん、契約以上のことをしてしまうと利益供与になってしまうし、大概そうしたことをすると小さなことが大きくトラぶる。良かれと思ってやったのに、というアレである。

そうならないように念頭にあることは忘れずに、上手にバーターをするとお互い納得感を得られてプロジェクトも回せる。その追加でやりたいと言っている課題をうちでやるなら、もともとうちでやる作業のここを同じ程度の工数だから、引き取ってくれないか、的なイメージだ。

SIerでも事業会社でも自社のみのリソースで賄えない規模だと業務委託にjoinしてもらう。やはりここでも契約をベースに業務を委託することになる。これはこれで良いというか当たり前なのだが、何せプロジェクト全体での成功をしたいと思っている自分と契約の範囲を我武者羅に履行しようとするから壁を作られる。いくらスコープを変えるときは再契約なり、追加発注するからと言っても壁はなくならない。

別な面で見れば、発注サイドの自分たちでできない業務の委託をするということは、委託契約が終わったら、それを引き継がなければならない。言い換えれば、業務委託を開始する時点で、指示をしなければならないし、終わった後は自分で面倒をみる覚悟をしなければならない。

フリーランスを何度か使ったこともあるが、たまたまなのか、体系的な開発手法を知らないことが散見された。SIerのエンジニアの方がいいのかというとそう簡単に割り切れるものでもない。SIerのエンジニアは分業だからフルスタックでできるエンジニアは少ない。やはり自分の担当領域をやることで一生懸命で、全体を俯瞰していない。それにSIerだと工数のボリュームが出ないと受けないこともままある。1人だけ優秀なエンジニアを出すわけにはビジネス的にはできないからだ。

こうなってくると、ものすごく業務委託を使うことにメリットを感じない。条件さえフィットすれば手軽に始められるが、ものすごく面倒でしかない。だから、ついつい内製化でやりたい気持ちになってしまう。しかし、なかなかチームのカルチャーに合うエンジニアと巡り会えない。