共創型SIerが解説 「内製化を実現する7つのステップ」とは：「内製化の道」も一歩から（1）

企業の競争力を上げるため、内製化が注目されている。しかし、これまで開発に注力していなかった企業にとって内製化を実現する難易度は高い。本連載はさまざまな企業の内製化を支援しているBeeXの知見を基に内製化の手順や必要となるスキルについて解説する。第1回はBeeXが提案する「内製化を実現する7つのステップ」について。

[緒方 裕康, 大曽根 尚，株式会社BeeX]

　DX（デジタルトランスフォーメーション）の機運の高まりもあり、ビジネスのスピードは速くなっている。しかも「VUCA」（Volatility、Uncertainty、Complexity、Ambiguity）という言葉もあるようにビジネスを取り巻く環境は、不確実で曖昧、複雑なものへと変化している。

　システム開発も例外ではなく、素早く変化するビジネスに合わせて柔軟に開発、改修できなければならない。SIer（システムインテグレーター）やITベンダーに開発を丸投げしている状態ではこうした変化に対応できないため、自社で開発組織を構築して「システム開発の内製化」を進めようとする企業もある。

　だが、「丸投げ」に頼っていた企業は当然として、これまで開発にリソースを割けなかった企業にとっても内製化を実現する難易度は高い。そこで本連載は、ユーザー企業と共に内製化を実現する「共創型SIer」であるBeeXの知見を基に、システム開発の内製化に必要なステップやエンジニアのスキルについて解説する。第1回はBeeXが提案する「内製化を実現する7つのステップ」について。

共創型SIerは内製化の近道

　開発の丸投げが問題なのは周知の事実だが、大まかに整理すると課題は以下の3点だ。

• 開発や改修にかかる時間とコストの妥当性が判断できない
• 開発を委託した企業とのやりとりが煩雑になり、臨機応変に対応ができない
• ノウハウが蓄積されないため、担当者ですらその全容を把握できない（ブラックボックス化）状態になる

　内製化を実現することでユーザー企業は開発を“自分事”にできるため、これらの課題を解決できる。課題が解決するだけでなく、現場の業務知識を持った社員がシステム開発に関わるので、要件でもめることが少なくなり素早い対応が可能になるというメリットもある。

　だが、「システム開発の全工程、全作業を自社でやる余力がない」という企業はどうすればいいのか。そこで有効なのが、SIerやITベンダーを開発パートナーとして利用する方法だ。「自社のリソースはコアな部分に注力し、アウトソースできる部分はSIerを利用する」といった使い分けをすることでノウハウを蓄積しつつ、効率的に内製化を進めることができる。

内製化で変化するユーザー企業とSIerの役割

　内製化プロジェクトの進め方を説明する前に、内製化を進めるために必要な「ユーザー企業とSIerの役割の変化」についても触れておこう。

　SIerにアウトソースできるといっても「ユーザー企業はただ見ていればよい」というわけではない。ユーザー企業は積極的にシステム開発に携わり、プロジェクトリーダーのように立ち回って開発プロジェクトそのものをコントロールしなければならない。場合によっては開発メンバーの育成や開発プロセスの改善といった対応もユーザー企業の役割になる。

　もちろん開発パートナーとなるSler、ITベンダーの役割も変化する。これまではユーザー企業に要件を聞き、言われた通りに作ることが重要だった。内製化プロジェクトにおいては、プロジェクトを一緒に進めるメンバーとして「本当にその機能は必要なのか」と意見したりユーザー企業の社内調整の手伝いをしたりといったユーザー企業を後押しする動きをする必要がある。

　内製化を実現するには多くのステップが必要だが、最初にこうした相互補助の関係が構築できると、内製化は驚くほどスムーズに進む。

BeeX式「内製化のススメ」

　次に内製化の具体的なステップについて説明する。BeeXはユーザー企業の内製化を進めるために7つのステップを用意している。

BeeXが推奨する「内製化を実現するための7つのステップ」

1．「お互いパートナーとしてやっていけるか」を小規模開発で確認し合う

　ユーザー企業が開発パートナーを活用して内製化を進める際に「きっと向こうがやってくれるだろう」といった姿勢では従来の丸投げと変わらない。それぞれが主体的に行動する必要がある。

　だが、ユーザー企業からすれば、「これまで一緒に仕事をしたことのない企業（開発パートナー）がどこまで主体的に動けるか」を事前に判断することは難しい。SIer側から見ても「このユーザー企業はどこまで積極的に動いてくれるのか」といった不安は残る。

　そこでBeeXは最初のステップとしてまず小規模な開発プロジェクトを実施している。実際に開発プロジェクトを完遂させることで内製化に対する意識や技術レベル、進め方、メンバーの特性などをお互いが確認できる。「自分たちと同じ目線でゴールを目指せるか、今後一緒に自分たちが行きたいところに進んでいけるメンバーなのかどうか」という内製化を進める上で最も重要なことを把握するステップになる。

2．「内製化のゴール」を明確にする

　ここで言うゴールとは「ユーザー企業が内製化を実現したときにたどり着く場所はどこか」ということだ。単にサービスを開発する、業務を効率化するといった目先の問題解決を目指してしまうと、プロジェクトを進めるうちにユーザー企業とSIerの役割や責任が曖昧になり、本当の意味での内製化を実現することが難しくなる。できるだけ明確な「ゴールのビジョン」を持つべきだ。

　例えば「外部に委託して作った社内向けサービスを改修し、商用サービス化する」「社内システムの開発プロセスを統一、標準化してグループ会社に展開する」などだ。

　ゴールのイメージが具体的なほど「どこまでSIerに任せるのか」「自社（ユーザー企業）がどこまで責任を持つのか」「意見がぶつかったときどのように判断するか」が明確になり、内製化を実現するスピードも速くなる。SIerから見ても目指すべきゴールが明確であれば、進め方で困ることもないし、「どこまでユーザー企業に意見すべきか」といったことで判断に迷うことが少なくなる。

ゴールのイメージが具体的であれば、テレワークでも進め方で困ることはない

3．事業部門と適切なコミュニケーションを取る

　このステップの目的は「事業部門の業務理解とニーズの把握」だ。何のためにシステムを開発するのか、それによってどんなことが実現できるかを双方が理解する必要がある。そのためには最も業務を理解している事業部門との適切なコミュニケーションが欠かせない。

4．ユーザー企業が主体となってチームを構築する

　ユーザー企業の担当者が主導して「自社で対応するコアな部分」と「Slerにアウトソースする部分」を切り分け、メンバーを振り分ける。「2．『内製化のゴール』を明確にする」が済んでいれば切り分け自体は問題ないはずだ。

　注意点としてはユーザー企業だけ、SIerだけというチーム構成にしないこと。所属や役職などではなく、目標を達成するために適切なメンバーを配置することが大切だ。ユーザー企業側の都合でメンバー構成が偏ることはあり得るが、そうした場合も全体をコントロールする役割をユーザー企業の担当者が担うことでユーザー企業の主体性を維持できる。

5．内製化するシステムに適したアーキテクチャを採用する

　開発言語やフレームワーク、インフラ、マネージドサービスといったシステム開発に必要な構成、要素（アーキテクチャ）を決める。考えなければならない要素は多いが、基本的には「システムで実現したいこと」「処理時間などの制約条件」「エンジニアのスキル傾向」などを基に検討するとよい。内製化の目的に「素早く、柔軟にシステム開発できること」があるので、クラウドを積極的に活用したりアジャイル開発手法を採用したりするのも効果的だ。

　技術面についてはユーザー企業かSIerのどちらかに実績がある技術を採用しがちだが、新規事業開発などではこれまで経験のない技術を採用しなければならないこともある。そうした場合は「1．『お互いパートナーとしてやっていけるか』を小規模開発で確認し合う」に戻り、新しい技術でプロジェクトが進められるか検証し直すことをお勧めする。

6．システム開発を高速化、自動化する仕組みを導入する

　CI/CD（継続的インテグレーション／継続的デリバリー）のサービスを導入することでコーディングからリリースまでの作業を効率化できる。BeeXではCI/CDの他、サーバレスを活用するなどしてできるだけ人の手が入らない開発体制を構築している。

7．「ユーザー企業が1人でやっていける体制」を作る

　内製化の最終的な目標は「ユーザー企業だけでもシステムを開発、改修できること」だ。そのためには、システム開発や改修に必要な情報やノウハウを蓄積しておき、すぐに参照できるようにしておかなければならない。

　BeeXが進める内製化プロジェクトでは用途に合わせて「Backlog」「Trello」「Kibela」などのサービスを使い分けている。タスクはBacklogやTrelloで管理し、機能要件が決まった背景やいきさつなどはKibelaにまとめるといった具合だ。

　著者は、内製化プロジェクトで特に重要なのは「なぜそうなったのか」といういきさつが残っていることだと考えている。いきさつや背景をいつでも確認できる状態にしておくことで「情報の属人化」を防止できる。

　システム開発に必要な情報は何かが分かるので、将来改修作業が必要になったときにユーザー企業だけで対応できる。もちろん、蓄積された情報を基に開発パートナーに協力を仰ぐことも可能だ。

　SIerにとっては、ユーザー企業の担当者が変わった場合でも過去の流れが残っているので「ちゃぶ台返し」をされる可能性が低くなるし、開発メンバーが入れ替わっても事前教育にかける時間を短縮できるなどのメリットがある。このステップを丁寧に進めることで、内製化の成功率はぐっと高くなる。

内製化の第一歩は“クラウドネイティブなシステムへの移行”から

　ここまで内製化のステップについて説明した。内製化のゴールは企業によってさまざまで、採用すべき技術や構築すべき体制もそれぞれ異なる。そんな中でも“これは外せない”とBeeXが考えるのが「クラウドネイティブなシステムへの移行」だ。

　ここで言うクラウドネイティブなシステムとは、クラウドで運用することを前提に、さまざまなクラウドサービスを組み合わせたシステムのことだ。顧客ニーズや事業部門の要求に迅速に対応するために必要な「スモールスタート」と「トライ＆エラー」も簡単に実施できるというメリットがある。

　ただ、クラウドを前提にしたシステムはスクラッチ開発と違ってエンジニアの都合で自由に変更できない部分がある。内製化に携わるエンジニアには、そういった「クラウド特有の事情」を把握し、使いこなせるスキルが必要だ。そこで次回は内製化を実現するために必要なエンジニアのスキルについて解説する。

筆者紹介

緒方 裕康

株式会社BeeX

デジタルプラットフォーム本部

本部長

AWSエンジニアとして複数の案件に携わる。その後、 セールス、マーケティングなどAWSビジネスの立上げに幅広く従事。現在は、デジタルプラットフォーム本部にてクラウドビジネス全般を推進。

大曽根 尚

株式会社BeeX

デジタルプラットフォーム本部　デジタルインテグレーション部 2グループ

グループリーダー

独立系大手SIerにてWebアプリケーション、組み込み開発など複数の案件にPM（プロジェクトマネジャー）／PL（プロジェクトリーダー）として携わった後、クラウドビジネスの経験を積みたいと考え、株式会社BeeXに転職。AWSエンジニアとしてアプリケーション開発の案件に携わり、アプリケーション開発グループを拡大させるため、新規案件開拓に努めている。