システム開発の内製化と外注／業務委託
プロダクト開発における、表題の件の「在り方」を非常に考えさせられることが多かった。考えたこと、取り組んだことのまとめ。
エンジニアメンバは、概ね下記の理由により内製化したいと考えている傾向が強い。
テクニカルスキルが高いメンバが多い。
管理する側／される側 という関係値ができるのが嫌。（≒社員は業務委託の品質保証のため、レビューばかりすることになる）
内製の方が好きに開発できる。
半分は理解できるし、半分眉唾だなと感じる部分がある。
社員で構成している方がテクニカルスキルが高い、と感じてくれているのは組織を管理する身としてはとてもありがたい。そこでどうしたか、何をして行ったか。
社員を増やす（採用のハードルを下げてでも）
採用は不確実性が非常に高く、即効性がない。最終的に採用ハードルを下げるようなことはしなかった。これは将来的な負債になる可能性が高いだろうと判断した。
組織内においてスキルレベルが大きく異なると評価の納得感が薄れる。
評価するのが難しい、というより、評価を受けた側の相対評価が組織内で能力にばらつきがあると適切に設定されなくなる。
互いに切磋琢磨できる環境が組織に残るモチベーションたり得る。
これはダメだ。ということで次に「管理する側／される側 という関係値」を改善して見ることに注目。
レビューをエンジニア間で相互にやるよう意識付け
端的にいうとこれはうまくいかなかった。言葉だけでは変わらないだろうと予想していたところはあるが。
委託元・委託先がある以上、皆この体制が頭にある。私も元々SIerで働いているのでよく理解してるが、人は体制図の通り動く。（それを打破してくれる人ももちろんいるが）
一方で、環境的には今は皆リモートワーク。情報は常にslackなどチャットツール上でオープンで、社員・業務委託の違いによる、メンバー間の情報の非対称性は存在しない。やってできないはずはない、というのが仮説。
これは委託元のメンバだけでなく、業務委託として一緒に働いてくれているメンバー側も、そういう線引きをしている面も大きく作用しているように思う。
スクラムっぽい体制にする
意味ないだろ、と思ってやらなかった。
請負法を守るためには、本当の意味でスクラムでやるのは難しいのではと思うし、結局こうなるだけで設定した課題の解決にならんよねと。
不可能だとは思いません。
アジャイルに対する経験値があって、自走できるメンバが揃っている
チーム、プロダクトの規模が大きくない
POやスクラムマスターをチームに対応する形でおける。
など、条件が揃えばいけるけど、今回はこれはマッチしない状況であろうという感じ。
アプリケーションがモノシリックかつ既に規模の大きなもの
同時にいくつものプロジェクトが動いている
という状況もあり、統括する人がいないと、サブシステム間の認知負荷が高まるだけで収集がつかない、という点も作用していたと思う。モノシリックなアプリケーションの状況の解決に今動いている段階なので、それが解決したあとまたこの記事を自分でも眺めてみよう。
体制を上下入れ替える
原点に帰って、やはり体制図が起因になっていることは、体制図から解決の糸口を掴もうとした。
結果的にぼくらのチームにはこのやり方がフィットした。在籍するメンバのパーソナリティ、求めるものにもよるので、万人に向けた方法とは言えないが。
明示的に体制上示すことで、色々と変化があった。
各エンジニアはよりプログラミングに集中できるようになった。
問題発生時、委託先のなかだけでCloseにならず、結果PM側の問題検知が早まった。
こう変えてみて特に感じたのが、業務委託先に求める人材のイメージが変わったことだった。何十人のチームを回すことができるPM（≒一般的に高付加価値な人材）は不要で、システム開発の実務に長けたリーダが重宝するようになった。
階層のHierarchyが、PL以下に委託元の社員がいることで結果的によりフラットになり、管理より実践に重きが置かれるようになったからかなと感じているが、この辺はまた様子を見て情報を更新したいと思う。
まとめ
内製化をした方が良い、というのも理解できる。
が、業務委託のメンバにも一緒にやる仲間として、共にプロダクトを愛して欲しいと思うし、よりスピード感を持って市場に価値を届けるためにも、より良い関係性・プロジェクトの進め方を突き詰めていきたいと、個人的には思っている。
品質管理や要員の管理のために、エンジニアがプロジェクトマネジメントにまわらないといけない、というのも同時に打破したい。苦労する道だとは思うが、取り組む価値はあるだろう。
というポエムチックなことは書いて終わり。
こういったテーマは悩む人も多いと思うけど情報が少ないと思うので、誰かの参考になると嬉しいな。