背景
VUCA（*1）と呼ばれる変化の時代、多様化するニーズに対応するため、IT部門には迅速な開発力・開発体制が求められています。
システム開発をアウトソースするより、柔軟にニーズに対応できる「内製化」に注目があつまっています。
内製化のメリットとしては一般的に以下が挙げられます。
- 業務品質のコントロールが効きやすい
- ノウハウを蓄積して競合優位性を生み出せる
- システムの仕様変更や機能の追加がしやすい
- 費用対効果の向上・コストの削減
- 情報漏えいの防止・機密情報の取り扱いが容易
一見良いことだらけに見えますが、そのまま鵜呑みにしていいのでしょうか。
今日にも、システム部から内製化の提案を受ける日が来るかもしれません。
そのとき流行っているから、メリットが多いからと安易に承認してしまうと、思わぬトラブルに発展するケースも散見されます。
ここでは、お客様自身で内製化を進めていましたが、思うように開発が進まず、我々が支援に入って立て直した事例をもとに、気を付けるポイントを説明します。
（*1）Volatility・Uncertainty・Complexity・Ambiguity
内製化失敗事例
お客様はこれまで蓄積してきた独自のノウハウを集約したシステムを内製化で構築しようとしていました。
ニッチな業界のため、既存のパッケージなど活用できるものもなく、また自分たちにしか出来ないことがあるはずだと、０からスクラッチで作っていました。
開発は大いに難航し、最初に実現したいことの手前でプロジェクトは頓挫していました。
その時の内製化の課題は以下でした。
品質（機能）
独自のノウハウは100％に近い形で実現できていたのですが、メンバのスキル不足もありエラーハンドリングが適切にできていないなどシステムとして基本的に満たすべき品質に達していませんでした。
品質（UI/UX）
独自のノウハウを機能として実現することはできていましたが、開発者がそこで力尽きてしまいUI/UXまで十分に手が回らず、インストールや設定が煩雑だったり画面レイアウトが使いにくかったりと、UXの観点から見た品質もよくありませんでした。
アジリティ
要件変更や機能追加が頻繁に発生する状況にもかかわらず、慣れ親しんだウォーターフォールで開発をしていたため、改修に時間がかかっていました。そのため、ユーザの要望に応えるのに数カ月かかってしまうということすらありました。
立て直し案
我々が支援に入った段階で改めて確認したところ、先に挙げた内製化の問題に加えて、出来上がったものへのユーザの満足度もあまり良くないことから、対症療法的に立て直すのではなく、思い切って作りなおす方向に舵を切りました。
今回の場合、2つの方針を立てました。
OSS活用による品質向上
中途半端なフルスクラッチでは、品質、アジリティともに中途半端になることが分かったため、フルスクラッチにはこだわらずOSSを活用することにしました。といっても、100%のニーズを満たすOSSは存在しなかったため、OSSがもつ機能をベースに、プラグインで独自のノウハウを実装することにしました。副次的な効果として導入設定方法や見た目も改善されました。
OSSを利用する際には機能面に目を向けるだけでなく、下記の二点についても留意しました。
- 利用するOSSのライセンスと制約を把握する
- サポートの考え方をあらかじめ整理する
特に、サポートについては、商用製品のような手厚いサポートが期待できないため、内製化メンバで自己解決ができることを目標にして、開発を通じて少しずつスキルを高めていきました。
アジャイル開発によるアジリティ向上
要件変更や機能追加が頻繁に発生することがわかっていたので、ウォーターフォールからアジャイルに開発方法を変更しました。結果として、新機能は最短2週間でできるレベルまでアジリティが向上しました。
アジャイルは軌道に乗ってしまえば、スピード感のある開発が可能ですが、ウォーターフォールしか知らないメンバには敷居が高いものです。そのため、チーム立ち上げ時のメンバの習熟に関しては、外部からコーチングをしていただきました。またメンバにSCRUMマスターの資格を取得してもらい、コーチが居なくても独力でアジャイル開発を進められるようにしました。
まとめ
このお客様は内製化方針を修正後、安定してシステム開発を進めています。
内製化で享受できるメリットはいろいろありますが、どのようなシステムをどのような方針や体制で開発するかによって得られる結果は変わってしまいます。これらを事前に検討せずになんとなくの感覚で内製化開発を採用してしまうと失敗してしまいます。
本稿で紹介した事例も参考にしていただき、安易に内製化に飛びつくことなく、よくよく検討したうえで採用していただきたいと考えています。