DX（デジタル・トランスフォメーション）を推進するにあたり、ソフトウェアの内製化を進める企業は増加傾向にあります。米国におけるDXの勝ち組と言うとGAFAのようなIT企業を思い浮かべると思いますが、それだけではありません。例えば、Fortune 500に入る、ホテルを運営するMGMリゾートでは、宿泊客が利用するさまざまなソフトウェアサービスをDigital Ventures Teamと名付けられた100名を超えるエンジニアのもと内製化しています。
一方で、日本企業においては、内製化を進めたいという意思は高まっているものの、なかなか進まない状況にあります。その理由のひとつは、DXなどに牽引されるIT市場の増加が引き起こす、圧倒的なエンジニアの人材不足です。
IDCによると、国内IoT（Internet of Things）市場は2019年～2024年の年間平均成長率（CAGR：Compound Annual Growth Rate）12.1％で成長し、2024年には12兆6,363億円に達するという調査報告があります。また、国内のAIシステム市場においても企業におけるAI活用が進み、2019年～2024年の年間平均成長率は33.4％で推移し、2024年には3,458億8,600万円になると予測しています。このようなIT市場の伸びとともに、IT人材の需要が増加していることが人材不足を引き起こし、企業DXを担うに十分なスキルをもったエンジニアを採用できずにDXを推進することが難しいケースが多々あります。
ふたつめの原因として、日本企業の多くがソフトウェアの開発・保守運用を外部ベンダーに委託してきた経緯があります。日本では、ソフトウェア開発の75％はアウトソースされていると言われています。このように、今までソフトウェア開発部門がなかった企業において、急に内製化を進めることは、開発部門の新設からその部門を率いる部門長の任命、さらには、外部からITエンジニアを採用するなど、会社全体の組織を大きく変更する必要があり、短期間でソフトウェア開発の内製化を実現するのは難しいケースがほどんどです。
多くの日本企業において、「IT人材不足」や「歴史的アウトソーシングによるソフトウェア開発における知見の欠如」から、しばらくはソフトウェアの開発・保守運用の委託を継続しつつ、時間をかけて内製化を進めるのが現実的でしょう。
外部委託ベンダーに対する依存を、段階的に引き下げる
「丸投げ」という言葉がありますが、自社の社員を要件定義とスケジュール管理を行うプロジェクトマネージャーとしてアサインするだけで、それ以外は外部ベンダー任せにしていないでしょうか。このように、外部ベンダーに対する依存度が高い状態のままだと、社内にソフトウェア開発の知見が蓄積されません。そこで、以下の環境を用意することで段階的に依存度を引き下げることができると考えます。
- 開発環境を自社で準備する
- 自社のメンバーがアクセス権、監査ログの確認を行う
- 自社のメンバーが開発中のタスクや、開発中の製品の仕様が意図したものと合致しているかレビューする
開発環境を自社で準備
開発環境を自社で準備することで、今まで同様、実際の開発作業は外部委託したベンダーが行いますが、ソフトウェア開発の知見が蓄積しやすい環境が整います。多くの外部委託プロジェクトでは、ソフトウェア開発が終了すると、開発ベンダーは「ソースコード」を納品しますが、「なぜそのようなコーディングをしているのか」「ソースコードの変更・修正はなぜ発生したのか」という情報は含まれていないことがほとんどです。
GitHub Enterpriseでは、このような開発作業の履歴がわかりやすく表示されるため、ソフトウェア開発を内製化するようになった場合でも、新しく入ってきたエンジニアがそのソースコードに関わる履歴を見ることできるため、プロジェクトの歴史的背景を把握でき、プロジェクトへの貢献がスムースに開始できます。
自社のメンバーがアクセス権、監査ログの確認を行う
多くのサービスがソフトウェアやアプリを通して提供されるようになり、情報漏えい防止など、ソフトウェアのセキュリティに対する重要度は高まっています。ソフトウェアに脆弱性がないような「品質」という意味でのセキュリティ対策も重要ですが、それとともに、「誰が」「どのような作業を行っているか」という、アクセス権や監査ログという観点のセキュリティ対策も必要となります。開発環境を自社で準備することで、このようなアクセス管理も行えるようになります。
GitHub Enterpriseでは、複数プロジェクトを一括、もしくは各プロジェクト毎にシングルサインオンの設定や、運用ポリシー、アクセス権の設定を行うことが可能です。複数の外部ベンダーに開発委託している場合でも、アクセス権を柔軟に管理することができるため、情報セキュリティーのコンプライアンス遵守に加え、プロジェクトおよびそれに携わるメンバーの正確な全体像の把握を適切なタイミングで行えます。また、GitHub Enterpriseはクラウドネイティブな開発プラットフォームであるためリモート環境でも開発ができ、ベンダーがオンサイトで開発する必要もありません。
自社のメンバーがプロジェクトの品質をレビューする
ソフトウェア開発が完成した際の品質の保証は、誰が最終的に担保すべきでしょうか。ソフトウェアの単純なバグから、脆弱性による情報漏えいまで、「何か」が起こった際にまず責任を問われるのは、開発を委託したベンダーではなく、開発元である自社です。法的にその責任を免れたとしても、自社のブランドイメージが毀損されることは避けられないでしょう。このようなことから、例え開発を外部委託していたとしても、自社がソフトウェアの品質に責任を持つと考えるべきなのです。
「自社がソフトウェアの品質に責任を持つ」ために、コードを製品にマージするにあたり、特定のレビューアーに承認を得るというプロセスを取り入れることを推奨します。
GitHub Enterpriseでは、このような承認が必要なチェック処理を自動化することが可能です。開発者がコードの製品マージをリクエストする（GitHubで行うPull Request）と、事前に設定されたタスクやテストが自動で実行され、テスト結果が表示されます。テスト結果が成功した場合のみ、レビューアーはそのコードマージを承認し、製品としてリリースします。
マージ前にどのようなタスクを行い、どのようなテストを実施すべきかを決める必要がありますが、このプロセスを構築するにあたり、すでにいる担当者に外部トレーニングを受けてもらったり、場合によってこの担当者だけは新規に採用する必要があるかもしれません。「要件定義とスケジュール管理だけを行うプロジェクトマネージャーがいて、あとはベンダー任せ」という状況から一歩進むために、ぜひ、このような人材投資の検討を始めてください。
多くの企業では、DX推進を成功に導くソフトウェア開発の内製化をすぐに導入することは難しい現状があります。まずは、開発環境を社内で準備し、自社の社員がスケジュールだけではなく、品質もレビューする体制を整えることから内製化の一歩を踏み出してみてください。
