アジャイルでエンジニアを内製化する５つの理由

あなたの会社では、エンジニアは自前の社員だろうか。それとも、協力会社だろうか。

アジャイルを推進するなら、開発部隊を内製化すべきだ。

その理由は５つある。
順番に見ていこう。

組織の活性化
ビジョン・方針の共有
スピード
モノ作りがはかどる仕組み
安価・安定・安心

1．組織の活性化

まず、内製化のメッセージ、そのものがポジティブである。
エンジニアの役割を外部から内部に切り替えるのだから、組織内のポストが増える。新しい人材の確保と既存社員の転籍も含め、組織内のモービリティーが上がり、組織は活性化する。
新しいことをしたい人にとって、チャンスが増える。

2．ビジョン・方針の共有

社員なら、組織のビジョンと方針を共有しやすくなる。
全員、運命共同体である組織の「仲間」である。だから、会社の情報を包み隠さず共有できる。

自分が所属する会社だから、帰属意識が芽生えるし、自社のゴールと自分のゴールとの同期をとりやすい。
仕事を、「自分事」として捉えやすい。
会社が上手くいけば、自分にとってもプラスだ。だから、ベクトルが合わせやすい。利害関係が相反しない。

3．スピード

外部ベンダーに依頼すると、調達や契約のプロセスがある。だから、どうしてもスピードが落ちる。
ベンダーマネジメントや法務等、複数の部署が介在する。だから、プロセスも複雑になりがちだ。

ベンダーの空き状況によっては、すぐに稼働できないケースもある。開始まで数ヶ月待たされることもある。
熾烈な競争の中、スピードを欠いた仕組みは命取りだ。

エンジニアリングは、モノ作りの心臓部だ。
そして、エンジニアリング機能を社内に持つことは、組織の中に動力性能を獲得することを意味する。
結果、組織は、機動的に戦略を実行していける。
競争が激化する中、自分達で、思い立ったその日から、思った方向に、直ちに手を打てる機動力は、安心感絶大である。

4．モノ作りがはかどる仕組み

「使い手」と「作り手」の理想的な関係を構築できる。

社員が「使い手」、協力会社が「作り手」の場合、そこには契約が介在する。良好な関係を築いていても、基盤は契約である。
協力会社は、リスクを減らす為、仕様を固定化しようとする。作る前に、資料化してサインオフしようとする。
社員は社員で、お客様気分である。要件のコンテキストを十分に伝えないケースもある。聞かれたら答えるが、聞かれた以上の事を、時間を割いてする人は少ない。

結果、忙しい現場の負荷を下げるため、そして協力会社に仕様を伝えるため、ビジネスアナリストの部隊ができる。彼らが、「使い手」と「作り手」の間に入って調整する。

そして、仕様書は海外に送られ、現場から遠い、ベンダーのオフショアチームが実装する。。

アジャイルを推進し、エンジニアも内製化されれば、「使い手」「作り手」ともに同じ組織に属する。全員イコールである。

契約書も、仕様書も、紙の約束で縛る必要がない。
利用者は、率直に、要求とコンテキストを対話を通して伝える。エンジニアは、即座にホワイトボードにモデリングし、プロトタイプを作る。
組織として、一枚岩となって、ゴールに向くことができる。いいプロダクトが生まれる環境が、自然と構築される。

少し、本論から逸れるが、現在BAの人は心配になるかもしれない。今後、BAがどうなるか説明しておこう。

結論として、ビジネスアナリストという役割の重要性は減る。
そもそも、プロダクトを「作って欲しい人」と、プロダクトを「作れる人」が直接やりとりすれば、当たり前にいいものができる。それを会社が違うから、リエゾン的にBAを介して作業していただけである。

BAという役割はアジャイルコミュニティには存在しない。
だが、BAはアジャイルコミュニティーの役割にコンバートできる。

BAはユーザーと開発者の橋渡しをしてきた役割だ。だから、調整事は得意である。ビジネスとシステム両方に明るい。両方のマインドを理解し、両方のペインポイントも知っている。だから、ビジネスアナリストの転籍第一候補は、スクラムマスターだろう。

技術的なスキルもあるなら、ビジネスアナリシスを柱に、エンジニアとして活躍できる。BAは受入テストに詳しいから、プログラミング力を備えれば、振る舞い駆動開発(BDD)のプラクティスも始めやすいだろう。

ビジネスドメインに詳しいなら、プロダクトオーナー、又はPOを補佐するPOチームメンバー、またはユーザーコミュニティの一員として活躍できる。

話を戻そう。

モノ作りがはかどる仕組みは、「使い手」と「作り手」が同じレベルで、同じビジョンを共有し、一枚岩になって、対話とフィードバックを繰り返しながら、モノを作ることである。

内製化すれば、ソリューション選択肢も増える。
外部ベンダーが提案するソリューションは、大抵自社製品である。多少のバリエーションがあっても、落としどころとなるテクノロジーやツールは最初から決まっている。

エンジニアが社員なら、組織戦略に沿って、最適なソリューションを選択できる。クラウドやIoTの活用など、あらゆる選択肢の中から柔軟に、中立的な立場で、自社にとって最適なテクノロジーを選べるのだ。

5．安価・安定・安心

最後に、マネジメントが気にする費用について。

協力会社に支払う金額は安くない。
アジャイルの場合、プロダクト思考で進めるから、プロジェクトと違って終わりがない。厳密には終わりはあるが、プロダクト・ライフサイクルは長い。
そして、リソースは固定で、ドメインナレッジやスキルがどんどん蓄積されていく。だから、契約が長期になればなるほど、途中で変えるハードルは高くなる。
従って、コスト負担も大きくなる。

内製化すれば、外部の高いフィーを支払わなくて済む。
協力会社の値上げも気にしなくていい。万が一のエンジニア変更も心配ない。
だから、安いし旨いのだ。

内製化初期は、ベロシティは高くないだろう。
だが、アジャイルは経験主義だ。固定チームで、ビジネスドメインを知り、技術的スキルを身につけ、めきめき力をつけていく。
内部・外部の境界線もない。チームは成長し、メンバーはチーム単位で考え、チームとして行動するようになる。
全員、同じ釜の飯を食う仲間だ。共通の顧客、共通のゴールに向かって、真のコラボレーションがすすむ。

タックマンの成長モデルが示すとおり、チームが成熟すれば、ベロシティはもりもり加速する。
そして、チームは自前だから、安定感バツグンである。
マネジメントも安心だ。

リソースを内製化する際、1番のネックはベロシティの低下だ。
内製化を進めて数ヶ月～半年、チームのアウトプットは著しく落ちる。一つの作業を2人～数名で学習しながら作るから、生産量は、半減～10分の1位になる。

組織として掲げたKPIもある。
競合他社との熾烈なシェア競争もある。

そんな中、内製化に踏み切るのはかなりの勇気が必要だ。

だが、どこかで内製化しないと、プロダクトデリバリーが安定しない。
持続可能なペースで、恒久的に顧客価値を築いていくには、安定してプロダクトを配給・支援できる体制が不可欠である。

手術が必要な時、あなたは、どうするだろうか。
今するか。
末期になってするか。

あなたはどちらを選ぶだろうか。

プロダクトデリバリーを安定化し、恒久的な顧客価値を創造するには、エンジニアの内製化が不可欠である。