内製化の成功への道 〜アジャイル開発・DevOpsと人材育成の両立〜

近年、DX施策のひとつとしてシステム内製化が注目されています。

内製化は、自社内でシステム開発や運用を行うことで開発速度の向上や変化に対応できる柔軟性を得られることが大きなメリットです。
しかし、従来システム開発や運用をベンダーに任せていた企業が内製化に取り組むには、まず人材の確保と育成、社内の組織体制づくりから考える必要があります。

本セミナーでは実例も交えて、とくにアジャイル開発やDevOpsを実現するための人材育成という観点から、内製化のメリット、体制づくり、そのプロセスでよくある課題と解決方法などをご紹介します。

Transcript

1. 内製化の成功への道 〜アジャイル開発・DevOpsの導入と人材育成の両立〜 NCDCオンラインセミナー NCDC株式会社 2023年10月16日
2. プレゼンター紹介 2 新井 貴大 エンジニア NCDCではフルスタックエンジニアとして新規 アプリケーション開発、お客様の開発チームへ 技術支援を担当。 技術面のみではない多面的な周囲へのサポー トを通じて開発を進めるのが強み。
3. NCDCのご紹介
4. 私たちにできること① l デジタルビジネスに必要な要素にフォーカスし、⼀元的に提供しています。 l スモールスタートでの検証から、本開発・継続的な改善までサポートします。 4 ワークショップを中⼼とし た合理的なプロセスで、ビ ジネスモデルの検討からUX デザインまで、迅速に⾏い ます。 関係者が多数いる場合の組 織横断、会社横断のファシ リテーションも得意です。 新規性の⾼いプロジェクト ではMVP（Minimum Viable Product）を⽤いた検証を⾏ うなど、⽬的に応じて段階 的な開発を企画します。 早い段階でモックやプロト タイプを⽤意してユーザの 評価を確認します。 ユーザとのタッチポイントとなる各種デバ イスのフロントエンドデザインから、クラ ウドサービスを駆使したバックエンドの開 発まで。多様なテクノロジーをインテグ レーションします。 l AI / IoT / AR l モバイル・ウェブ アプリ開発 l クラウドインテグレーション l システムアーキテクチャコンサルティング など ビジネスモデルのデザイン スモールスタート・PoC システム・インテグレーション ユーザ視点を⼤切にした 課題抽出・企画 モックやプロトタイプ の開発・検証 開発 継続的な改善
5. 私たちにできること② l 社内に最適な組織がない場合の組織づくりや⼈材育成から、⾼度な技術をもったエンジニア による技術移管まで、幅広くお客様をサポートします。 5 ビジネスモデルのデザイン スモールスタート・PoC システム・インテグレーション ユーザ視点を⼤切にした 課題抽出・企画 モックやプロトタイプ の開発・検証 開発 継続的な改善 企業のDXやデジタルビジネスの創出に必要なこうしたプロセスを多⾯的にサポート DX戦略⽴案 ⼈材育成 技術移管 リファレンス実装 DX組織構築⽀援 アジャイル導⼊⽀援 ⼿法や技術の選定 ブランディング
6. はじめに
7. はじめに l 本セミナーは、以下のような方に向けて話します l 内製化を推進するにあたり、どのような体制・開発プロセスで進める べきか検討している方 l 社内の人材育成に興味のある方
8. 内製化とよくある課題
9. 内製化とは l ベンダーや外部に委託していた業務を社内で行うこと 9 外注 内製化 企業 ベンダー 発注 納品 企業 ベ ン ダ $ よくある内製化事例 ・システムの一部を切り出して小規模からスタート ・要件定義フェーズから社内メンバーに加え、ベンダーを含めスタートする選択肢も 必要に応じて 開発支援 開発・改善
10. 内製化のメリット 10 ①柔軟に仕様変更 に対応できる ②ソフトウェア開発の ノウハウの獲得できる ③品質、期間、コスト などを自分たちで コントロールできる
11. 内製化のメリット①柔軟に仕様に対応できるようになる 11 開発 要件定義して一気に開発 柔軟に方向性を調整 この期間に開発したも のを修正しているので、 その分のコスト、期間 は余分にかかる 予め決めたものをまっすぐ作るので、 コスト・期間は相対的に小さい。 ただし、できあがったものが課題を解 決しているかは「要件定義次第」 要件定義 後で変えられないので、 いるかも知れない機能を 詰め込みがち 使ってみて フィードバック ただし、柔軟性のためだけなら、 外部ベンダーと準委任契約で アジャイル的にやることも可能 途中で何度も確認しているので、 必要十分になっている
12. 内製化のメリット②ソフトウェア開発のノウハウの獲得 l 近年の業務改善や、新規事業開発はソフトウェア開発がほぼ必須 l ソフトウェア開発に理解があるエンジニア、マネージャーの存在が重 要になってきています l 少なくとも業務や事業への理解と、ソフトウェア開発の 勘所を掴んでいるプロダクトオーナーができる人材の育成は必須 12 プロダクトオーナー エンジニア デザイナー
13. 内製化のメリット②ソフトウェア開発のノウハウの獲得 l 自分たちで開発することで、次のようなメリットがあります l 開発に関するプログラミングやクラウドなどの技術的な スキルが組織に蓄積される l 何が難しくて、何が簡単か分かる l 外注した時、開発費用が高いなと感じることはないでしょうか？ 13 ソフトウェア開発ではある機能は2日でできると思ったことが、 想定していないエラーに引っかかると半日潰れるということが 良くあります。 外注していたときは、それらに対応するバッファーを外注先が 持っており、その中でやりくりします。 結果、自分たちでやらないと各機能の実装の難易度が 肌感として分からない
14. 内製化のメリット③品質・期間・コストなどを自社でコントロール可能に 14 システムの根幹に影響がある 変更はどれで、 後からでも良いものは何か プロダクトオーナー エンジニア デザイナー ソフトウェア l 仕様変更が発生した場合、プロジェクトの途中でスケジュールと予算の観 点から軌道修正することができる l 定期的（週次など）にチームが開発する機能を判断できる体制作りは必要
15. 課題１）発注先が社内になっただけで、当初の課題を解決していない l 社内の開発チームで内製開発するようにしたが、開発が柔軟になっていな い l 開発プロセスの問題 l 開発プロセスが外部開発と変わっていない。要件定義して、最後に事業部側が 受入れ試験をやるだけになっており、最後の最後で「これじゃない！」という のが発覚する。 l 業務とITの壁が取り払えてない l プロダクトオーナーが既存業務で忙しく、プロダクト開発に深く参画できてい ない。 l プロダクトオーナーはITの経験はあるが、対象の業務、サービスに対してドメイ ン知識がない。業務側を巻き込めていない。 l 事業部側がITは自分たちには関係ないというマインドから変わっていない 15 プロジェクト発足時にアプリケーションを利用する方を内製化チームのメン バーとして参画してもらう。 また参画メンバーはプロジェクトに専念できるよう社内調整を行います。さらに 人事異動などによるメンバー欠員リスクを減らす。
16. 課題２）スケジュールが遅延して完了しない l アジャイル的に開発を行っているが、 １週間ごとのスプリントミーティングの度に変更が発生して、 いつまで経ってもリリースできない l チーム内のコンセプト・認識の違いによる問題 l 開発しているサービスのコンセプトは、チームやステークホルダーで認識 あっているでしょうか l プロダクトオーナーやチームが、その変更がどれだけ重要なのか、 費用対効果を評価して、判断ができているか l 仕様が決まっていない状態でスプリントの開発がスタートしてないでしょ うか 16 定期的にプロジェクトの目的と開発のマイルストーンをチーム内で認識合わ せを行いましょう。 向かう先がぶれてしまうと、入れて良い変更なのか判断が難しくなってしまい ます。
17. 内製化を成功に導くための重要な要素
18. 内製化を成功に導くための重要な要素 18 体制の構築 開発プロセス 人材育成
19. 内製化を成功に導くための重要な要素 ①体制の構築
20. 体制の構築①対象プロジェクトの選定 l まずプロジェクトの選定にあたり、下記の観点から考えます l 自社の内製化の戦略、どこまで内製化したいのか l 社内で保有している技術、スキルやノウハウ l 開発対象サービスのプロダクト、サービスの特性 l 「これを作ったらいい」と決まっているものについては、 ウォーターフォールで開発した方がコストや期間を短縮可能 l 数ヶ月など小さい単位で外部に発注して、その都度、方向を見直すな ども有用 l ノウハウやスキルが不足しているのであれば、外部ベンダーから開発 サポート受けながら内製化チームを発足 20
21. 体制の構築①対象のプロジェクトの選定例 21 自社のスキルから 対象のシステムは 難易度低い 難易度高い 何を作ればよいか 決まっている イメージです。 自社の戦略や、どこまでできるかによって、軸も変わります。 何を作ればよいか 探索が必要 柔軟性を内製化の 目的とした場合の軸 会計システム 顧客向け 新規サービス 社内向け 業務改善 小規模PJ 営業支援 システム
22. 体制の構築①どのような体制でやるか 22 技術サポート （NCDC） プロダクトオーナー （社員） エンジニア （社員） デザイナー （NCDC） アジャイルコーチ （NCDC） あるお客様での事例 企業 IT部門 DX推進 １つのチームは8人程度。 フロントエンドもバックエンドも できる体制。 ReactやAWSなど アプリケーション開発のために 必要な技術を移管 Webアプリ、モバイルアプリの開発 経験が浅いところからスタート l 独立してサービス開発を進められるように、チームはプロダ クトオーナー、フロントエンド、バックエンドのエンジニア などから構成するのが理想 エンジニア （社員） エンジニア （NCDC） l 社内に実際の開発を含めてノウハウを蓄積するのであれば、それを前提とした担当者の業務配分、 計画が必要です l 特にプロジェクトオーナーについては、事業とITを理解している重要人物であるため積極的参加が求め られる エンジニア （NCDC） システム全体のUI・UX設計
23. 体制の構築①内製化に向けた開発チームの技術的なキャッチアップ l 何かしらのプログラミング言語でのシステム開発の経験があ るエンジニアが何人かは必須 l 外部のエンジニアをチームに組み込むのは問題ない。 l ただし、丸投げにせず、プロダクトオーナーとエンジニアは蜜に コミュニケーションを取り、開発する機能のユースケースや、 業務的なニーズを共有する必要があります。 l Javaや.NETなどでサーバーサイドのアプリケーションを開発していた エンジニアが、サーバレスや、コンテナに対応したアプリケーションを 開発することは比較的容易 以下の通り、AWS Lambdaはよく使われている実行環境をサポートしている l Java、Go、PowerShell、Node.js、C#、Python、Ruby 23
24. 体制の構築①内製化に向けた開発チームの技術的なキャッチアップ l AWSを使用することでアプリケーションエンジニアが環境構築なども手軽に できるようになったことで、高い専門性を持った専任のインフラ担当者や、 ネットワーク担当者が居なくてもサービス開発を始められるようになった l 以下のような点において、外部の経験、ノウハウをインプットすることで、 効率よくスタートしたり、サービスの商用利用を開始する際の安心感はあります l たくさんあるAWSのサービスの中からどのような組み合わせで実現するのか l サーバレスやコンテナを使用する上で、アプリケーションの設計で 気をつけないといけないポイント l セキュリティを担保するための設計 24
25. 内製化を成功に導くための重要な要素 ②開発プロセス
26. 開発プロセス②プロジェクトの目的や全体像の確認 l 開発チーム全体でプロジェクトの目的と進む方向性を決めます。 l インセプションデッキと呼ばれる手法 26
27. 開発プロセス②プロジェクトの目的や全体像の確認 27
28. 開発プロセス②プロジェクトの進め方 28 リリース リリース リリース 設計 開発 テスト 改善 設計 開発 テスト 改善 設計 開発 テスト 改善 開 発 機 能 の 検 討 l 決められた機能を2~3週間などの短期間で繰り返し開発を行います l 各期間ごとにPOを中心にプロジェクトメンバー全員で、機能要件が満たさ れているか、確認することが好ましいです l 短期間で検証できるように、デプロイの自動化やテスト環境の整備は必要 になります(DevOpsにつながってきます) スプリント① スプリント② スプリント③
29. 開発プロセス②事例 29
30. (参考) DevOps、CI/CDについてもう少し技術的に踏み込んだ情報 30 l 以下で以前実施したセミナーを公開しておりますので、ぜひ ご参照ください。 「AWSで実現するモダンアプリ開発〜DevOpsやCI/CDを基礎から実践方法まで解説〜」 https://ncdc.co.jp/columns/8508/
31. 開発プロセス②アジャイル開発を加速させるDevOps 31 l DevOpsにより実現できること l ビルド、テスト、デプロイ、リリースを自動実行可能に l チームおよびユーザーが実行できるテスト環境を比較的容易に用意が 可能に(aws amplifyを使用) l 例.開発実装中のAという機能をユーザーにテストしたいという場合、aws amplifyのpreview機能により生成されたURLより検証が可能 機能A 機能B 機能C A環境 https://testA B環境 https://testB C環境 https://testC ユーザー それぞれの環境 で検証が可能
32. 開発プロセス②コミュニケーション 32 l 短いサイクルで設計・開発を進めていると必ず仕様に関するQAや 再検討項目が発生します。都度発生した課題に対して迅速に解決す るためには、以下を意識することが重要です。 l 臨機応変に対応できるようslackやteamsなどチャットツールを利用 l スプリント期間中に仕様の漏れが判明したとしても、チャットであればそ の仕様を詰めるために PO と会話すればすぐ解決する可能性も。 l メールやスプレッドシートを用いた連携でもよい。ただし、mtgを細かく設 定するなどの工夫が必要。 l 目標達成のために、チームで課題解決に取り組むという意識作り l ひとりのタスクを止めてしまうと、全体へ影響が出てしまいます。チーム 内の他の人材やステークホルダーと連携する必要ができてます。職種関係 なくチーム同士で声をかけあうことが非常に重要となります。
33. 内製化を成功に導くための重要な要素 ③人材育成
34. 人材育成③お客様チームのエンジニアへの人材育成事例 ソースレビュー 実装されたソースコードに対して コメントの上レビューを実施 仕様解説 機能概要と実現に必要な処理を検 討 コード理解 既存のコードの理解、似た処理が あればどのように実現されている のか確認 実装 実際にソースコードを書き始めま す。時間はしっかり確保 モブプログラミ ング 画面共有やVscodeなどのエディタ を使用して一緒にコードを書きま す タスク完了 l プロジェクト内でスキル移管を実施 定例MTGやソースコードレビュー、モブプログラミングで実現 Meetの画面共有 VscodeのliveShareを使用した モブプログラミング 必要に応じて コミュニケーション Slackやバーチャルオフィス等
35. DevOpsとNCDCの内製化支援サービス
36. 内製化支援サービス l 「DevOpsをやってみたい。でもハードルが、高そう」と思われた方へ l NCDCでは「内製化支援サービス」を提供しています l 少しでも興味がありましたら、ぜひお問い合わせください l URL : https://ncdc.co.jp/service/insourcing/ l NCDCは、AWSの「内製化支援推進AWSパートナー」に参加しており、豊富な実 績と知識で内製化をサポートすることが可能です l https://aws.amazon.com/jp/blogs/psa/202203-inhouseit-with-aws-partners/ 36
37. [参考]NCDCの内製化支援サービスの紹介 37 ⽇本企業のIT部⾨は従来「システムの安定稼働」を重視してきましたが、 近年は「ビジネス要求に応じてスピーディーにシステムを変化させるこ と」が求められ始めています。 こうした要求に応えるために、システムの内製化やアジャイル・ DevOpsの導⼊に取り組む企業が増えていますが、アウトソーシングか ら内製主体の体制に移⾏するには、社内に新たな知識・スキルを貯える ことが⽋かせません。 このサービスでは、NCDCが持つ技術⽀援やDX⽀援の豊富な経験を活か し、内製化に取り組む企業の⽀援を⾏います。柔軟なシステム運⽤を可 能にする先進的な開発⼿法や、クラウド活⽤術などの知⾒・技術をお客 さまの社内に蓄積していただくことで、外部ベンダーに依存せず⾃⾛で きる開発チームづくりをサポートします。 具体的には、内製化を検討しているお客さまの状況を伺い、NCDC側で 最適な計画を⽴案。⽀援が必要な領域に合わせてコンサルタント、エン ジニア、UXデザイナーなどの専⾨家をアサインします。 クラウドなどをうまく使って 柔軟なシステムを内製化したい 豊富なDX⽀援経験により 蓄積されたノウハウ システムのモダナイゼーション、 アジャイル開発、DevOps、 AI,IoTの活⽤、開発技術選定、 UX/UIデザイン... お客様 コンサルティング などを通じて 実践的な知識や スキルを移管 概要｜ビジネス要求に柔軟に対応できる開発体制づくりを支援
38. まとめ
39. まとめ l 内製化を成功させるために l 自社の内製化の戦略にあっており、現状のスキルにあった プロジェクトを選定する l 事業とITを理解しているプロダクトオーナーの育成・積極参加は必須 l プログラミングまで内製化するかはどうかは自社の戦略次第。 もちろんできたほうが良いが、そのためには担当者の業務配分や、 評価の方法なども検討が必要 l 内製化に合わせて、開発プロセスも変える l 必要に応じてパブリッククラウドを使用してDevOpsの導入を検討
40. info@ncdc.co.jp www.ncdc.co.jp