事例に学ぶ内製化、DevOps戦略 〜DXパートナーとの連携がプロセス変革や人材育成の鍵〜

近年、DX施策のひとつとしてシステム内製化が注目されています。内製化は、自社内でシステム開発や運用を行うことで開発速度の向上や柔軟性の確保が図れる上に、ノウハウの蓄積、DX人材の育成など、多くのメリットをもたらします。

しかし、従来システム開発や運用をベンダーに任せていた多くの企業が内製化に取り組むには、まず人材の確保と育成、社内の組織体制づくりから考える必要があります。

そのため、内製チームをつくり、クラウドやCI/CDツールをうまく使いこなす柔軟な開発体制の実現を図るには外部パートナーとの連携が重要な要素になります。 パートナー企業の専門知識や技術力を活用して、徐々に社内へのスキルトランスファーを進めることで、社内のリソース不足という課題を抱える企業も内製化プロセスをスムーズに進めることができます。

このセミナーでは、「内製化支援推進AWSパートナー」のNCDCがご支援した内製化、DevOpsに取り組む企業の事例を通じて、内製化プロセスで起こりがちなさまざまな課題とその解決方法をご紹介します。 これから内製化を検討する方も、すでに具体的な課題に直面している方にも参考になる参考にしていただける内容です。ぜひご参加ください。

Transcript

1. 事例に学ぶ内製化、DevOps戦略 DXパートナーとの連携がプロセス変革や人材育成の鍵 NCDCオンラインセミナー NCDC株式会社 2023年8月1日
2. プレゼンター紹介 2 十川 亮平 取締役/CTO NCDCでは、モバイル、API、IoT、機械学習 などを使ったクライアントの新規サービス の企画立案や、プロジェクトの推進を支援 を担当。 建設向けIoTプラットフォーム「ミエルコ ウジ」のプロダクトマネージャーとして、 マーケティング活動やソフトウェア開発を 行っている。
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. Business 事業領域の推進 Design ユーザ視点での設計 Technology 技術による課題解決 Innovation • コンサルティング • 新規サービス企画 • PoC⽀援 • デザイン思考 • UX/UIデザイン • モバイル・Web先端技術 • IoT / AI / AR • クラウドインテグレーション 6 NCDCのサービス体系
7. はじめに
8. 本日の内容 l なぜ内製化なのか l 内製化を進めたお客様事例 l 内製化のよくある課題 l 内製化に必要なもの l どのようなプロジェクトから着手するのが良いか l どのような体制でやるか l どのような開発プロセスでやるのか l 内製化したからこそやりやすいDevOps l DevOpsとは何か l 内製化とDevOps l NCDCの内製化支援サービスのご紹介
9. なぜ内製化なのか NCDCのお客様が内製化をやろうとした理由 9 Web上で様々な施策を打ちたい。 柔軟に素早く変更したい。 フロントエンドとサーバーサイドを分離して、 フロントエンドだけは内製化を行う ライフネット生命様 保険申込みサイト これまでコストを掛けて外注していたが、 要件通りできても業務で使えなかった。 アジャイルで使いながら継続的に開発していき たい。 本田技研工業様 工場の業務改善のための アプリを内製化 以前と比較して簡単に開発できるようになった。 将来的には各事業部で改善に必要なものを 自分たちで開発できるようになりたい 製造業 工場の業務改善のための アプリを内製化
10. 本田技研工業様の例 10 https://ncdc.co.jp/cases/6821/
11. なぜ内製化なのか 一般的に以下のような目的がある 11 ①柔軟に仕様を変えたい ②ソフトウェア開発の ノウハウを獲得したい ③品質、期間、コスト などを自分たちで コントロールしたい
12. ①柔軟に仕様を変えたい 12 開発 要件定義して一気に開発 柔軟に方向性を調整 この期間に開発したも のを修正しているので、 その分のコスト、期間 は余分にかかる 予め決めたものをまっすぐ作るので、 コスト・期間は相対的に小さい。 ただし、できあがったものが課題を解 決しているかは「要件定義次第」 要件定義 後で変えられないので、 いるかも知れない機能を 詰め込みがち 使ってみて フィードバック ただし、柔軟性のためだけなら、 外部ベンダーと準委任契約で アジャイル的にやることも可能 途中で何度も確認しているので、 必要十分になっている
13. ②ソフトウェア開発のノウハウを獲得したい l 近年の業務改善や、新規事業開発はソフトウェア開発がほぼ必須 l ソフトウェア開発に理解があるエンジニア、マネージャーの存在が重 要になってきています l 少なくとも業務や事業への理解と、ソフトウェア開発の 勘所を掴んでいるプロダクトオーナーができる人材の育成は必須 13 プロダクトオーナー エンジニア デザイナー
14. ②ソフトウェア開発のノウハウを獲得したい l 自分たちで開発することで、次のようなメリットがあります l 開発に関するプログラミングやクラウドなどの技術的な スキルが組織に蓄積される l 何が難しくて、何が簡単か分かる l 外注した時、開発費用が高いなと感じることはないでしょうか？ 14 ソフトウェア開発ではある機能は2日でできると思ったことが、 想定していないエラーに引っかかると半日潰れるということが 良くあります。 外注していたときは、それらに対応するバッファーを外注先が 持っており、その中でやりくりします。 結果、自分たちでやらないと各機能の実装の難易度が 肌感として分からない
15. ①柔軟に仕様を変えたい 15 柔軟に変更を取り入れつつ、決まったスケジュール、予算内でできるように 定期的（週次など）にチームが判断できる必要がある 一括請負で発注する場合は、基本的に要件定義が終われば 最後確認するだけだったのが常に判断をしないといけない システムの根幹に影響がある 変更はどれで、 後からでも良いものは何か プロダクトオーナー エンジニア デザイナー
16. 内製化のよくある課題
17. 課題１）発注先が社内になっただけで、当初の課題を解決していない l 社内の開発チームで内製開発するようにしたが、開発が柔軟になっていな い こんなこと無いでしょうか？ l 開発プロセスの問題 l 開発プロセスが外部開発と変わっていない。要件定義して、最後に事業部 側が受入れ試験をやるだけになっており、最後の最後で「これじゃな い！」というのが発覚する。 l 業務とITの壁が取り払えてない l プロダクトオーナーが既存業務で忙しく、プロダクト開発に深く参画でき ていない。 l プロダクトオーナーはITの経験はあるが、対象の業務、サービスに対して ドメイン知識がない。業務側を巻き込めていない。 l 事業部側がITは自分たちには関係ないというマインドから変わっていない 17
18. 課題２）スケジュールが遅延して完了しない l アジャイル的に開発を行っているが、 １週間ごとのスプリントミーティングの度に変更が発生して、 いつまで経ってもリリースできない こんなこと無いでしょうか？ l 開発しているサービスのコンセプトは、チームやステークホルダー で認識あっているでしょうか l プロダクトオーナーやチームが、その変更がどれだけ重要なのか、 費用対効果を評価して、判断ができているか 18
19. 内製化に必要なもの
20. 内製化に必要なもの 20 ②どのような体制でや るか ③どのような開発プロ セスでやるのか ①対象のプロジェクト の選定
21. ①対象のプロジェクトの選定 l NCDCはアジャイルだけが正解とは考えていません l これを作ったらいい、と決まっているものについては、 ウォーターフォールで開発した方がコストや期間を 短くできる可能性もあります l 数ヶ月など小さい単位で外部に発注して、その都度、 方向を見直すなども有用な方法だと思います l 以下の両面から判断するのが良いと考えます 21 開発対象のプロダクト、 サービスの特性 自社の内製化の戦略 どこまで内製化したいのか 社内で保有している技術、 ノウハウ
22. ①対象のプロジェクトの選定 22 自社のスキルから 対象のシステムは 難易度低い 難易度高い 何を作ればよいか 決まっている イメージです。 自社の戦略や、どこまでできるかによって、軸も変わります。 何を作ればよいか 探索が必要 柔軟性を内製化の 目的とした場合の軸 会計システム 顧客向け 新規サービス 社内向け 業務改善 小規模PJ 営業支援 システム
23. ②どのような体制でやるか l 独立してサービス開発を進められる ように、チームはプロダクトオー ナー、フロントエンド、バックエン ドのエンジニアなどから構成されま す。 l 開発者は外部からその時に 必要なスキルを持つエンジニアに 入ってもらうのは問題ありません。 ただし、社内に実際の開発を含めて ノウハウを蓄積するのであれば、そ れを前提とした担当者の業務配分、 計画が必要です。 23 プロダクトオーナー （社員） エンジニア （社員） デザイナー （NCDC） エンジニア （業務委託） 技術サポート （NCDC） アジャイルコーチ （業務委託） ある製造業のお客様での事例 企業 IT部門 製造部門 １つのチームは8人程度。 フロントエンドもバックエンドも できる体制。 ReactやAWSなど アプリケーション開発のために 必要な技術を移管 Pythonで分析業務の経験はあるが、 Webアプリ、モバイルアプリの経験 はないところからスタート
24. 内製化に向けた開発チームの技術的なキャッチアップ l 何かしらのプログラミング言語でのシステム開発の経験があるエンジニアが 何人かは必須 l 外部のエンジニアをチームに組み込むのは問題ない。 l ただし、丸投げにせず、プロダクトオーナーとエンジニアは蜜に コミュニケーションを取り、開発する機能のユースケースや、 業務的なニーズを共有する必要があります。 l Javaや.NETなどでサーバーサイドのアプリケーションを開発していた エンジニアが、サーバレスや、コンテナに対応したアプリケーションを 開発することは比較的容易 以下の通り、AWS Lambdaはよく使われている実行環境をサポートしている l Java、Go、PowerShell、Node.js、C#、Python、Ruby 24
25. 内製化に向けた開発チームの技術的なキャッチアップ l AWSを使用することでアプリケーションエンジニアが環境構築なども手軽に できるようになったことで、高い専門性を持った専任のインフラ担当者や、 ネットワーク担当者が居なくてもサービス開発を始められるようになった l 以下のような点において、外部の経験、ノウハウをインプットすることで、 効率よくスタートしたり、サービスの商用利用を開始する際の安心感はあります l たくさんあるAWSのサービスの中からどのような組み合わせで実現するのか l サーバレスやコンテナを使用する上で、アプリケーションの設計で 気をつけないといけないポイント l セキュリティを担保するための設計 25
26. ③どのような開発プロセスでやるのか l 開発チームはステークホルダーとの方向性確認 l インセプションデッキと呼ばれる手法 26
27. ③どのような開発プロセスでやるのか 27
28. ③どのような開発プロセスでやるのか 28 柔軟性が必要な場合、１週間の枠（スプリントなどと呼ばれる）で 開発するものを決め、１週間が終わると、みんなで使ってみる。 できるのであればユーザーに触ってもらう。 課題を解決しているのか、ユーザーが使えるのか短い期間で確認する。 ただし、この場合でも全体の計画は必要。無いと終わらない。 プロダクトオーナー エンジニア デザイナー
29. 内製化したからこそやりやすいDevOps
30. DevOpsとは？ l Dev(開発)とOps(運用)をうまく連携するための手法の総称 30 • 計画をたてる • コードを書く • ビルドする • テストする Dev • リリースする（デプロイする） • オペレーションする • モニタリングする Ops
31. DevOps, CI/CDと内製化 l 内製化のチームには、DevOpsが向いています l 柔軟な開発とDevOpsの相性が良い l 短い間隔で開発・リリースを繰り返しやすい l 変更時にテストを自動で実行することで、安心感がある l チームで一体的な開発・運用がしやすい l 外注の場合は、契約やセキュリティの問題で、外部のメンバーとの間にど うしても壁が出来てしまう l 利用者も社内なので、素早い動きがしやすい l 高度なインフラ要員を外部から入れなくても良くなった l 外部サービスやクラウドを活用することで、インフラ専門の人材がいなく てもシステム開発が可能 31
32. 従来の開発とDevOpsの違い l 従来の開発 l 複数の機能を開発後に、まとめてリリース l リリース後は、同じ機能でしばらく運用を続ける 32 Dev(機能1) Dev(機能2) Dev(機能3) Ops リリース l DevOps l 短期間でのリリースを繰り返す l リリース後も、次の機能開発を素早く実施する Dev(機能1) Dev(機能2) Dev(機能3) リリース Ops リリース Ops Ops リリース 数ヶ月に1回しか リリースできない！ 毎週リリースしても 運用が周る！
33. 開発(Dev) から 運用 (Ops) への受け渡しが軽量化・自動化が必要 l DevとOpsの境界には、リリースの作業がある l リリース作業がこの作業が大変なので l リリース頻度が下がる l DevとOpsの連携しづらい 33 Dev(機能1) Dev(機能2) Dev(機能3) Ops リリース作業 これが大変！！ CI/CDにより、リリースの作業を簡略化・自動化できる
34. CI/CDとは何か 34 l DevOpsを実現するために、ビルド、テスト、デプロイ、リリースを自動で行う仕組み l CI : Continuous Integration → 継続的インテグレーション l 自動でビルドやテストを実施する l CD : Continuous Delivery → 継続的デリバリー l 自動でアプリをデプロイ / リリースする 既存のよくあるデプロイプロセス 開発 ビルド デプロイ/ リリース 運用 • 手動 テスト • 手順書ベー スで手動 CI、CDのプロセス 開発 ビルド デプロイ/ リリース 開発者 • マージを 切っ掛け に自動で 実行 テスト • マージを 切っ掛けに 自動で実行 • スクリプト 化されてい るがビルド の実行は手 動 • マージを 切っ掛け に自動で 実行 • ソース コードの 変更をリ リースブ ランチに マージ リリース作業がとても大変 →複数の変更をまとめて実施 →変更点が多いので、確認作業も大変 →リリースの頻度が落ちる 自動化により、リリース作業が楽になる →変更単位での実施しても問題ない →テストも自動化されているので確認も楽 →リリース頻度を上げることができる 開発者
35. 実例１ : AWS上に構築したアプリ（ソースコード管理にGitHubを利用） l ソースコード管理 l GitHub l CI/CD l AWS Amplify (ビルドやデプロイ) l GitHub Actions (テスト) l その他 l Amazon CloudWatch で運用・監視 l エラーやアラートを slackへの自動通知 35 バックエンドの 自動デプロイ フロントエンドの 自動デプロイ このプロジェクトの本番リリース作業は、 毎回30分程度です！ （作業10分、待機20分） CI/CD
36. DevOps、CI/CDについてもう少し技術的に踏み込んだ情報 36 以下で以前実施したセミナーを公開しておりますので、ぜひご参照ください。 「AWSで実現するモダンアプリ開発〜DevOpsやCI/CDを基礎から実践方法まで解説〜」 https://ncdc.co.jp/columns/8508/
37. DevOpsとNCDCの内製化支援サービス
38. 内製化支援サービス 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/ 38
39. [参考]NCDCの内製化支援サービスの紹介 39 ⽇本企業のIT部⾨は従来「システムの安定稼働」を重視してきましたが、 近年は「ビジネス要求に応じてスピーディーにシステムを変化させるこ と」が求められ始めています。 こうした要求に応えるために、システムの内製化やアジャイル・ DevOpsの導⼊に取り組む企業が増えていますが、アウトソーシングか ら内製主体の体制に移⾏するには、社内に新たな知識・スキルを貯える ことが⽋かせません。 このサービスでは、NCDCが持つ技術⽀援やDX⽀援の豊富な経験を活か し、内製化に取り組む企業の⽀援を⾏います。柔軟なシステム運⽤を可 能にする先進的な開発⼿法や、クラウド活⽤術などの知⾒・技術をお客 さまの社内に蓄積していただくことで、外部ベンダーに依存せず⾃⾛で きる開発チームづくりをサポートします。 具体的には、内製化を検討しているお客さまの状況を伺い、NCDC側で 最適な計画を⽴案。⽀援が必要な領域に合わせてコンサルタント、エン ジニア、UXデザイナーなどの専⾨家をアサインします。 クラウドなどをうまく使って 柔軟なシステムを内製化したい 豊富なDX⽀援経験により 蓄積されたノウハウ システムのモダナイゼーション、 アジャイル開発、DevOps、 AI,IoTの活⽤、開発技術選定、 UX/UIデザイン... お客様 コンサルティング などを通じて 実践的な知識や スキルを移管 概要｜ビジネス要求に柔軟に対応できる開発体制づくりを支援
40. 事例｜UXデザイン＋アジャイルによる社内ツール作成 40 Client｜本田技研工業株式会社様 Keyword｜ アジャイル , 技術支援 , UX/UIデザイン UXを重視した社内ツール開発の 内製化・⾼速化⽀援。 お客さまの課題 | 製造部⾨専属のITチームを⽴ち 上げ、製造現場のスタッフにとって本当に使える サービスを、内製で、⾼速に作っていくアジャイ ル開発体制を構築したい。そのための技術⽀援も できるパートナーを求めていた。 ソリューション | UX/UIデザインや開発を内製化 するための技術⽀援を通じて、お客さまのITチー ムを継続的に⽀援。製造ラインの業務進捗情報を 集約して表⽰するダッシュボードや、製造⼯程で のトラブル情報管理ツールなどの開発にともに取 り組んだ。 NCDCの役割 | コンサルタント、デザイナー、エ ンジニアを派遣し、UX/UIデザインからフロント エンド、バックエンドの実装まで、幅広いコンサ ルティングを実施。技術移管も並⾏し、アジャイ ル開発の体制構築を多⽅⾯から⽀援しました。
41. 事例｜業務基盤となる大規模システム刷新プロジェクト 41 Client｜ライフネット生命保険株式会社様 Keyword｜ AWS ,システムアーキテクチャ 保守まで⾒据えた⼤規模かつ 先進的なシステムを構築。 お客さまの課題 | ⼗数年前に構築したシステムが、 保守や改修にコスト（時間・お⾦）が嵩む状態に なっていた。同システムは増加傾向にあるWEB直 販に関して最重要な基盤になるため、ビジネス⾯ のニーズに迅速に対応できる先進的なシステムを 必要としており、⼤規模な刷新プロジェクトに取 り組んでいた。 ソリューション | 保守・運⽤の⼤幅な改善を実現 するクラウドネイティブなアーキテクチャを提案。 また、バックエンドだけでなく、フロントエンド でもUIデザインの改修に参画し、デザインガイド ラインの整備まで担当。 NCDCの役割 | 開発はパートナーの⼤⼿開発ベン ダーに任せ、NCDCでは主にマイクロサービスや DevOpsなどを取り⼊れた標準策定コンサルティ ングを担当。APIの設計標準化、ソースコード管 理等を担い、プロジェクト全体を指揮。
42. まとめ
43. まとめ l 内製化を推進するために、 l 自社の内製化の戦略にあっており、且つ、現状のスキルにあった プロジェクトを選定する l 事業とITを理解しているプロダクトオーナーの育成は必須 l プログラミングまで内製化するかはどうかは自社の戦略次第。 もちろんできたほうが良いが、そのためには担当者の業務配分や、 評価の方法なども検討が必要 l 内製化に合わせて、開発プロセスも変える
44. まとめ マイクロサービス プロダクトオーナー エンジニア デザイナー マイクロサービス マイクロサービス クラウドサービス Agile + DeｖOps プロダクトオーナー エンジニア デザイナー プロダクトオーナー エンジニア デザイナー マイクロサービスと 小さなチーム 短いリリースサイクルを 実現するプロセス これらを実現する クラウドサービス DevOpsや、クラウドを活用して、小さなチームで開発できるようにする
45. ご清聴ありがとうございました l ウェビナー終了後ブラウザが下の画面に切り替わります。 「続行」を押してアンケートにお進みください。ご質問・ご相談も受け付けております。 45