ネットプロテクションズ（以下、NP）のIT部門であるビジネスアーキテクトでは、これまで開発を外注で行っていました。2015年からはテスト的に内製を一部開始し、現在ではチームとして内製を行う組織を作っています。なぜ外注100％で開発を行ってきた状況から、内製を取り入れ始めたのか。その理由をCTOである鈴木史朗に伺いました。

内製化への最初のチャレンジと課題

我々は経営ミッションに「つぎのアタリマエをつくる」を掲げています。そのミッション達成のため、サービスを企画からいくつかの実装まで内製しています。サービス内製を担うのは、NPのIT領域をつかさどるBA（ビジネスアーキテクト）グループです。

私が入社した15年ほど前は、システム開発を外部ITベンダーに委託していました。しかし私は、すべて内部で開発をしたほうがより早く・正確かつ高い品質でモノづくりができると考えていたので、内製へと体制の切り替えを推進していきました。

そのような体制にしてから3年ほどたった時期にメンバーの評価をしたところ、あまり技術力が向上していないことに気が付きました。

当時の開発対象は「NP後払い」というサービスひとつのみでした。また、「NP後払い」は決済というデリケートなサービスであるため、なかなかリスクを取ったチャレンジングな開発はできない特性を有しています。そのため、技術のバリエーションがなかなか増えにくく，よって技術力が伸び悩む環境でありました。

一方でNPは事業拡大フェーズにあったため、スピードと品質を上げるために内製の体制を見直すことにしました。切り分けとして、企画・設計はNP社員が担い、開発部分は外部ITベンダーに依頼することにしました。結果として、多くの機能をリリースすることができましたし、2015年度には「NP後払い」の年間の流通金額が1,000億円を突破し、月間の取引件数は200万件を超える規模となる成長を支えることができたと思っています。

外部の力を借りながら、社内のITリテラシーを高めるには

しかしその反面、実装に携わらないデメリットも当然のごとく生まれてきました。それは、内製体制の時期に経験した以上のITリテラシーの低下です。我々の決済サービスは前例がないため、将来を考えつつ緻密に設計していくことが必要となります。我々のITリテラシーが低いと、ITベンダーの設計案や工数の妥当性を判断することができず、理想を実現できるシステムではなかったとしても、適切にフィードバックをすることができません。新規事業を作るときも狭い範囲の手段でしか考えることができず、本来実現したい価値を生み出せないことも往々にして起こりえます。

技術力の低下から起こり得る問題は把握しながらも、そう簡単には内製に切り戻せないジレンマが続いていました。それは、ビジネスリーダー思想とエンジニア思想に衝突の恐れがあったからです。

ネットプロテクションズは事業を生み出すビジネスリーダーの集団であることを志向しています。一方でエンジニアはその特性として、プログラミングのスキル自体が目的化しやすく、また周囲とのコミュニケーションも疎かにしやすい職種なので、どうしてもビジネスリーダーとの衝突リスクが高まります。また、自らの世界を自然と狭めてしまいがちになるため、エンジニアというキャリアステップを踏むと、ビジネスリーダーへの道のりを遠ざけてしまう傾向にあります。

新規事業開発をきっかけに内製チーム再興

こうした状況の中、ある転機が訪れました。新規事業「atone」の開発にあたって、立ち上げメンバー達が自ら開発を行いたいと言ってくれたのです。この提案はチャンスだと感じました。と言うのも、提案してくれたメンバー達は元々ビジネスサイドで事業づくりに貢献してくれていました。また、新規事業づくりにおいての開発だったので、ビジネスづくりありきの開発になります。こうした状況からITが目的化せず、事業づくりのために開発が行えると感じたのです。

実際、このプロジェクトはうまく進んでくれました。事業づくりをベースにしたことで目的を失わず、また初心者に近いメンバーも含めた個々人がそのためにスキルアップをしてくれたことで、これまでになくスピーディかつ高品質に開発が完了しました。実際外注で80人月程度と想定される開発規模を、35人月程度で進めることができました。未来へのベクトルを精緻に実装でき、安定的に運用できていること，初心者の育成サイクルが機能していることを考慮にいれると、数字以上の効果があると言えます。

この経験から、ビジネス目的×内製という一気通貫の内製チームを作ることが、社内のITリテラシーを向上させ、“いいビジネス”を生み出し続けられる組織になるための一つの方法であるという学びが得られました。