共創型SIerは内製化の近道
課題
- 開発や改修にかかる時間とコストの妥当性が判断できない
- 開発を委託した企業とのやりとりが煩雑になり、臨機応変に対応ができない
- ノウハウが蓄積されないため、担当者ですらその全容を把握できない(ブラックボックス化)状態になる
内製化を実現することでユーザ企業は開発を”自分事”にできるため、これらの課題を解決できる。
さらに現場の業務知識を持った社員がシステム開発に関わるので、要件でもめることが少なくなり素早い対応が可能になる
システム開発の全工程、全作業を自社でやる余力がない
→自社のリソースはコアな部分に注力し、アウトソースできる部分はSIerを利用する
⇨ノウハウを蓄積しつつ、効率的に内製化を進めることができる
内製化で変化するユーザ企業とSIerの役割
内製化を進めるために必要な「ユーザ企業とSIerの役割の変化」
【ユーザ企業】積極的に開発に携わり、プロジェクトリーダーのように立ち回って開発プロジェクトそのものをコントロールしなければならない。また、開発メンバーの育成や開発プロセスの改善も。
【SIer】プロジェクトを一緒に進めるメンバーとして「本当にその機能は必要なのか」と意見したりユーザ企業の社内調整の手伝いをしたりといったユーザ企業を後押しする動きが必要
→ 内製化の実現のためには、多くのステップの前にこうした相互補助の関係が必要
内製化のススメ
- 「お互いパートナーとしてやっていけるか」を小規模開発で確認し合う
- 「内製化のゴール」を明確にする
- 事業部門と適切なコミュニケーションをとる
- ユーザ企業が主体となってチーム体制を構築する
- 内製化するシステムに適したアーキテクチャを採用する
- システム開発を高速化、自動化する仕組みを導入する
- 「ユーザー企業が１人でやっていける体制」を作る
「お互いパートナーとしてやっていけるか」を小規模開発で確認し合う
ユーザ企業が開発パートナーを活用して内製化を進める際は、それぞれが主体的に行動する必要がある。
実際に小規模な開発プロジェクトを完遂させることで内製化に対する意識や技術レベル、進め方、メンバーの特性などをお互いが確認できる。「自分たちと同じ目線でゴールを目指せるか、今後一緒に自分たちが行きたいところに進んでいけるメンバーなのかどうか」最も重要なことを把握するステップ。
「内製化のゴール」を明確にする
ゴール : 「ユーザ企業が内製化を実現したときにたどり着く場所はどこか？」できるだけ明確に。
(例) 「外部に委託して作った社内向けサービスを改修し、商用サービス化する」
「社内システムの開発プロセスを統一、標準化してグループ会社に展開する」
事業部門と適切なコミュニケーションをとる
目的:「事業部門の業務理解とニーズの把握」
なんのためにシステムを開発するのか、どんなことが実現できるかを双方が理解する必要
ユーザ企業が主体となってチームを構築する
「自社で対応するコアな部分」と「SIerにアウトソースする部分」を切り分け、メンバーを振り分ける
ユーザ企業だけ、SIerだけというチーム構成にはしない
全体をコントロールする役割をユーザ企業の担当者が担うことで主体性を維持する
内製化するシステムに適したアーキテクチャを採用する
開発言語、フレームワーク、インフラ、マネージドサービスなどのアーキテクチャを決める
「システムで実現したいこと」「処理時間などの制約条件」「エンジニアのスキル傾向」
内製化の目的「素早く、柔軟にシステム開発できること」⇒ クラウド活用・アジャイル開発手法
システム開発を高速化、自動化する仕組みを導入する
CI/CD(継続的インテグレーション/継続的デリバリー)のサービスを導入
「ユーザ企業が1人でやっていける体制」を作る
内製化の最終的な目標は「ユーザー企業だけでもシステムを開発、改修できること」
⇒ システム開発や改修に必要な情報やノウハウを蓄積しておき、すぐに参照できること
タスク管理「Backlog」や「Trello」、背景や経緯は「Kibela」などのサービス利用
「なぜそうなったのか」は重要(情報の属人化を防止)
担当者や開発メンバーが入れ替わっても事前教育にかける時間を短縮できる
内製化の第一歩は”クラウドネイティブなシステムへの移行”から
「クラウドネイティブなシステム」とはクラウド運用前提でクラウドサービスを組み合わせたシステム
⇒「スモールスタート」と「トライ＆エラー」も簡単にできる
内製化に欠かせない3つのスキル
- クラウドサービスの特徴を理解し、最適な組み合わせを選ぶスキル
- 個人のノウハウをチームのノウハウに発展させるスキル
- ユーザ企業の業務を理解し、課題化するスキル
クラウドサービスの特徴を理解し、最適な組み合わせを選ぶスキル
内製化を進めるうえで「クラウドネイティブなシステムへの移行」は必須条件だ。そのためエンジニアは無数に存在するクラウドサービスのメリットとデメリットを把握し、適切に組み合わせられるスキルが必要になる。
無数のクラウドサービスの中から最適な組み合わせを選ぶことは容易ではない。当然一人では限界がある。そこで重要なのが次のスキルである「ノウハウをチームに展開するスキル」
個人のノウハウをチームのノウハウに発展させる
それぞれのメンバーがプロジェクトで得たノウハウをチームに共有し、全体の技術力を底上げする必要がある。
チームのコミュニケーションを活性化させ、ナレッジをドキュメントなどにアウトプロットし継続的に改善する
【アジャイル開発と相性の良い状態】
・チーム内で適切にコミュニケーションがとれる
・過去のナレッジが素早く参照できる
ユーザ企業の業務を理解し、課題化する
内製化を進めるエンジニアはユーザ企業の視点で業務を把握し、開発する機能がなぜ必要なのかを理解する必要がある。
「業務上、この機能は不要なので止めよう」という提案ができるようになる。
開発する機能に対して「自分が使うならどういう機能がよいのか」という思い入れが持てるかどうか
エンジニアには違和感がない「オンラインでのやりとり」にも注意
直接会ったことのないメンバーとどのようにコミュニケーションをとればいいか？
「開発に携わるメンバー間で、お互いが相手の意図をくみ取れる丁寧なコミュニケーションが重要」
一緒に仕事をする相手がどのようなコミュニケーションを好むかをあいまいにしたままではトラブルにつながりやすい。
“実践”に勝る修行はない
クラウドや顧客業務の理解、オンラインでのコミュニケーションなどエンジニアに求められるものは多い。「実践での習得」が重視される。
クラウドサービスは、比較的簡単にシステム開発を試すことができる。検証環境を使って開発を進めるのがスキル上達の近道。
エンジニアに対し、ブログや寄稿記事などで積極的に情報発信することを推奨している。
クラウド移行を機に、内製化に着手したA社
A社はシステム基盤をオンプレミスからクラウドに移行するとともに、外部に委託していたWebサービス開発を内製化することに決めた。ただ、A社のエンジニアリソースは十分ではなく、外部の力が必要不可欠だった。「自社では足りない部分のピースを埋めてもらう」
実力はもちろん「相性」を知ることが重要
・技術面の確認
「コストを抑えつつ、サービスの提供スピードをあげたい」「新しい技術を積極的に取り込みたい」
⇒ 低コストで素早いサービス提供として「サーバレス(AWS Lambda)を使った開発」を実施。
不具合は両社の責任
・内製化のゴールを明確にする
・事業部門との適切なコミュニケーション
取り組み内容はプロジェクトに関する情報のナレッジ化や視覚化が中心
「GitHub」などを使ってコードの詳細な仕様、改修履歴を共有するのは当然として「Slack」やドキュメント共有ツールを活用してエンジニア同士のやりとりを活性化し、非同期でもコミュニケーションができるようにした。
全体を俯瞰するのはユーザ企業の役割
・ユーザ企業が主体となってチーム体制を構築する
・内製化するシステムに適したアーキテクチャを採用する
・システム開発を高速化、自動化する仕組みを導入する
・ユーザ企業が1人でやっていける体制を作る
⇒ 適切なコミュニケーションをとる + 「Kibela」を導入
