共創型SIerが解説 実例で学ぶ「ユーザー企業主体の内製化」の勘所：「内製化の道」も一歩から（3）
ユーザー企業とともに内製化を実現する「共創型SIer」であるBeeXの知見を基に、システム開発の内製化に必要なステップやエンジニアのスキルについて解説する本連載。第3回はBeeXの事例を基に「具体的な内製化の進め方」について解説する。
企業の競争力を上げるため、内製化が注目されている。しかし、これまで開発に注力していなかった企業にとって内製化を実現する難易度は高い。本連載はさまざまな企業の内製化を支援しているBeeXの知見を基に内製化の手順や必要となるスキルについて解説する。第3回は実際の事例を基に「具体的な内製化の進め方」について解説する。
クラウド移行を機に、内製化に着手したA社
本稿で紹介するのはA社の事例だ。
BeeXとA社の関係が始まったのはDX（デジタルトランスフォーメーション）の機運の高まり始めたころだ。A社は「顧客のニーズを素早く把握し、サービスに反映させるにはどうすればいいか」という課題に悩んでいた。当時、A社のWebサービスは外部の開発会社に委託して開発しており、新しい機能を追加したり機能を改修したりするたびに要件定義や改修作業に時間を取られていたからだ。
そこでA社はシステム基盤をオンプレミスからクラウドに移行するとともに、外部に委託していたWebサービス開発を内製化することに決めた。ただ、A社のエンジニアリソースは十分ではなく、外部の力が必要不可欠だった。もちろん丸投げではなく、あくまでも「自社では足りない部分のピースを埋めてもらう」ことが目的だ。
そこでBeeXをはじめとするパートナー企業に白羽の矢が立った。
実力はもちろん「相性」を知ることが重要
ここでBeeXの標準的な内製化のステップをおさらいする。
A社のケースでもこちらのステップを一つずつ進めた。
「1．『お互いパートナーとしてやっていけるか』を小規模開発で確認し合う」については、特に技術面での確認を重視した。A社は「コストを抑えつつ、サービスの提供スピードを上げたい」「新しい技術を積極的に取り込みたい」という2つの思いを持っていたからだ。
そこでBeeXとA社はまず「低コストで素早いサービス提供」「新技術への取り組みの姿勢」という2点について検証を行った。
“低コストで素早いサービス提供“については「サーバレス（AWS Lambda）を使った開発」を実施した。当時BeeXにAWS Lambdaの開発経験はなかったが、有識者へのヒアリングや検証環境での試験などを繰り返し、なんとか開発を成功させた。
通常の請負案件であれば、自社で開発経験がある言語に切り替えることも選択肢になり得るが、この検証では「未経験の技術をどうやって身に付けるか」といった点も重要だったため、こうした泥臭い対応を実施した。
この検証が成功したことでA社との共創に向けた取り組みのスピードは加速した。コミュニケーションが密になり、「もっとフラットな形でプロジェクトに参加してほしい」「何かあればエンジニアの視点ですぐ指摘してほしい」と言われるようになった。
プロジェクト終了後にA社に話を聞いたところ、この検証だけではなく、その後のコミュニケーションから、「経験がなくても新しいことを一緒にチャレンジできる」と判断していただいたそうだ。
「不具合は両社の責任」
次に「2. 『内製化のゴール』を明確にする」と「3. 事業部門との適切なコミュニケーションを取る」だ。
A社の場合、「顧客にニーズを素早く把握し、サービスに反映させる体制を作る」という明確なイメージを持っていたため、どちらかと言えばゴールの議論ではなく、事業部門とのコミュニケーションをスムーズにする取り組みが中心になった。
取り組み内容はプロジェクトに関する情報のナレッジ化や視覚化が中心だ。「なぜそう決まったのか」といった背景があいまいだと間違ったコミュニケーションが発生し、トラブルの火種になりかねないからだ。
「GitHub」などを使ってコードの詳細な仕様、改修履歴を共有するのは当然として、「Slack」やドキュメント共有ツールを活用してエンジニア同士のやりとりを活性化し、非同期でもコミュニケーションができるようにした。コードレビューはA社とBeeXの両方が参加することにして、もし不具合があっても責任は追及せず、対処を優先することに決めた。心理的安全性の確保のためだ。
こうして、同じゴールに向かって適切なコミュニケーションを取れる環境を整えたら、次は「4．ユーザー企業が主体となってチーム体制を構築する」だ。
全体を俯瞰するのはユーザー企業の役割
最終的にはBeeXがいなくてもサービス開発できる体制にするため、従来のクライアント・ベンダーという関係性ではなく、より身近な存在となるように自由度の高い組織体制の方が望ましい。
A社の場合は、営業部門や事業部門、エンドユーザーとの窓口やプロジェクトの全体管理とインフラ部分をA社が担当した。BeeXは主にバックエンドシステム全般の開発を担当した。開発手法はアジャイル開発を採用したため、BeeXからは、社内のスペシャリストたちが参加し、全体を俯瞰（ふかん）するスクラムマスターの役割はA社に担当してもらった。
「5．内製化するシステムに適したアーキテクチャを採用する」「6．システム開発を高速化、自動化する仕組みを導入する」については、A社があらかじめ想定していた部分が多く、比較的スムーズに進行した。振り返ると、内製化を目指す企業の中でもA社のように明確なイメージを持っている企業は珍しい。
インフラはA社の既存システムで利用していたAmazon Web Services（AWS）に決まり、使用言語もA社が取り組んでみたかった「Go」「Python」を採用した。「サーバレスの活用」が前提にあったため、開発の高速化、自動化については問題なかった。
「7.『ユーザー企業が1人でやっていける体制』を作る」については前述した「3. 事業部門との適切なコミュニケーションを取る」で導入したコミュニケーションの仕組みが役立った。それに加えて「Kibela」を導入した。Kibelaに、機能の仕様が決まったいきさつや課題の対応状況など登録することで、新規参入者がいつでも状況を確認できる環境を整えた。
細かいナレッジを共有するときのために「Trello」も使った。TrelloはA社からも確認できるため、ナレッジが蓄積するだけでなく、「ナレッジは会社の違いを飛び越えて共有するものだ」という文化をつくることにも効果がある。
文化という意味ではプロジェクトの反省会で「KPT法」を使った評価を採用したことも大きかった。責任追及ではなく改善点を全員で考える場にしたことで情報のやりとりを活発できた。
こうしたステップを踏むことでA社は、独力で開発できる体制を構築した。内製化プロジェクトで取り組んだWebサービス開発は無事完了し、課題だった「顧客のニーズを素早くサービスに反映させること」もできるようになった。
「内製化の一歩」を踏み出そう
A社のように自社内の開発リソースが少ない状態でも、アウトソースをうまく活用できれば内製化は実現可能だ。「信頼できるパートナーがいない」という意見はあるかもしれないが、PoC（概念実証）など小規模の開発を一緒に進めることで自社との相性を見極めることはできる。
一方で、パートナー企業側の視点で言えば「内製化してしまったら仕事がなくなるのでは？」と考える企業もあるだろう。しかし、実際は逆だ。
独力で開発できるということは開発に必要な時間やスキル、コストを正確に把握できるということだ。「自社だけでは対応しきれない開発だ」と判断したユーザー企業から、内製化プロジェクトが終わった後に声を掛けてもらうことも多い。実際、A社とBeeXは現在も良好な関係性を築いており、システムの共通基盤化、サービス開発の負荷軽減、API基盤の構築などを手掛けている。
エンジニアの視点で言えば、内製化プロジェクトに携わることで、自ら改善案を提案し、顧客と一緒に仕事をするという能動的な姿勢を身に付けることができる。そういったエンジニアは他の案件でも高く評価される。
このようにパートナー企業を活用した内製化プロジェクトには幾つものメリットがある。「丸投げになってしまうのでは」とパートナー企業などのアウトソース活用に消極的な企業はPoCからでいいので一歩を踏み出してみてはどうだろうか。
筆者紹介
緒方 裕康
株式会社BeeX
デジタルプラットフォーム本部
本部長
AWSエンジニアとして複数の案件に携わる。その後、 セールス、マーケティングなどAWSビジネスの立上げに幅広く従事。現在は、デジタルプラットフォーム本部にてクラウドビジネス全般を推進。
大曽根 尚
株式会社BeeX
デジタルプラットフォーム本部 デジタルインテグレーション部 2グループ
グループリーダー
独立系大手SIerにてWebアプリケーション、組み込み開発など複数の案件にPM（プロジェクトマネジャー）／PL（プロジェクトリーダー）として携わった後、クラウドビジネスの経験を積みたいと考え、株式会社BeeXに転職。AWSエンジニアとしてアプリケーション開発の案件に携わり、アプリケーション開発グループを拡大させるため、新規案件開拓に努めている。
Copyright © ITmedia, Inc. All Rights Reserved.