NCDC_DX-DEV_20211109

DXに取り組むには、最先端のデジタル技術により自社のビジネスをどう変革していくかというアイデアと、ビジネス要求を迅速に・柔軟に取り入れていけるシステムの両輪が欠かせません。

しかし、多くの企業ではまだその準備が整っていないのではないでしょうか。
当社では次のようなご相談を受けることが増えています。
「AI、IoTなど新しい技術をビジネスに活用したいが、企画やPoCから先に踏み出せない」
「内製化により柔軟なシステム開発体制を実現したいが、社内に知識やスキルが不足している」

本セミナーでは、AI、IoTなどを活用するプロジェクトの立ち上げや、システム内製化に取り組む企業へのご支援行っているコンサルタントが講師を担当。
豊富な経験から見出した、DXプロジェクトを成功に導くための「鍵」を解説します。

DXと密接な関係にあるクラウドやアジャイルをうまく取り入れていくためにどんな体制を準備すればいいのか、技術やツールはどのように選択すべきなのか、企画やPoCから先へ踏み出すためには何が必要なのか…。
こうしたよくある課題について、実例も交えて解説いたします。

Transcript

1. DXを成功に導く鍵 クラウドやアジャイルを活用した 迅速なアイデア実現手法とは？ NCDCオンラインセミナー 2021年11月9日 NCDC株式会社 十川 亮平
2. プレゼンター紹介 2 十川 亮平 取締役/CTO NCDCでは、モバイル、API、IoT、機械学習 などを使ったクライアントの新規サービス の企画立案や、プロジェクトの推進を支援 を担当。 Webサービス／モバイルアプリのバックエ ンドプラットフォームであるAppPotプロダ クトマネージャーとして、マーケティング 活動やAPIの開発を行っている。
3. Business 事業領域の推進 Design ユーザ視点での設計 Technology 技術による課題解決 Innovation • コンサルティング • 新規サービス企画 • PoC⽀援 • デザイン思考 • UX/UIデザイン • モバイル・Web先端技術 • IoT / AI / AR • クラウドインテグレーション NCDCのサービス体系 3
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. DXを 成 功 に 導 く た め の ３ つ の キ ー フ ァ ク タ ー と は
7. DXをわかりやすく整理 l NCDCでは２つのタイプに分けて整理 デジタルを活用した新たな収益源を作る。 新たなサービス・事業を作る。 デジタルを活用した既存業務の変革を行う。 新規サービス系DX 業務改⾰系DX 7 こちらは従来からの業務向け大規模シ ステム開発と大差がない印象。 デジタルで 儲かることを考えて・作り・運用する！
8. DXは実行しながら方向転換や、やってみて分かることがある l 前提 l DXではこれまでシステムが存在しなかった領域の業務や、 新しい製品をデジタルで実現するケースが多い。 l そのため、こういう機能を作ったら良いというのを 決めることは難しい そのため、基本的には仮説を立て、検証を行い、 実際に価値があるものは何かを探しながら サービスやプロダクトの開発を行います。 8
9. こんな課題、皆さんの周りにもないでしょうか l 外部に発注しようとしたが、新規サービスでどのくらい需要があ るか分からないのに、いきなり大きな見積もりになってしまって 開発に着手できない l 開発ベンダーに要件を決めてくれと言われるが、現在はない業務、 サービスのため今の時点で明確は要件はない l サービスが具体化してきて要件を変更したら費用が追加になると 言われる l 大きな投資をしたので、失敗できない l クラウドを使い切れていない気がする 9
10. DXのアイデアは見つかった（とします） それではDXの実現のために、どのような手法がよいのでしょうか DXの実現に必要な３つのキーファクター チーム （体制） プロセス （どうやっ てやる か） テクノロ ジー （道具） 10
11. DXを実現するチーム チーム （体制） プロセス （どうやっ てやる か） テクノロ ジー （道具）
12. DXの実現に向けたオーバービュー（体制と構造） ①プロダクトオーナーを 中心とした小さなチーム 基幹システムとの連携 体制とシステムの構造 ②小さく分割された マイクロサービス 12
13. DXの実現に向けたオーバービュー（体制と構造） ①プロダクトオーナーを 中心とした小さなチーム 基幹システムとの連携 体制とシステムの構造 ②小さく分割された マイクロサービス 13
14. DXはビジネスと開発が一体であるのが望ましい l これまでビジネスと開発が分離された体制がよくありました l 事業部とIT部門 l 発注者と受託者 ビジネス側で決まったことを作るだけならこれでいいですが・・・ l DXでは実行段階で方向転換が 頻繁に発生するため、 ビジネスが分かるメンバーと 開発ができるメンバーが 一体となった小さいチームが望ましい l 従来のプロジェクトと異なりリリースしたら 解散ではなく、継続的なチームの維持が必要 14 ビジネスと開発が一体と なったチーム PO エンジニア デザイナー
15. サービス開発におけるプロダクトオーナーの役割 l サービス開発において、プロダクトオーナー（PO）という役割が 一般的になりつつあります l プロダクトオーナーの役割 l サービス（プロダクト）のコンセプト、ビジョンを定義する l ユーザーの調査、競合の調査 l 機能の優先度をつける l このサービスのコアな機能は。差別化要因は。 l サービスを方向転換（ピボット） するのかどうか l 開発者に作りたいものを伝える l プログラミングが分かる必要はないが、 開発者とコミュニケーションを取りながら 何が大変で、何は簡単なのかを理解する 15 ビジネスと開発が一体と なったチーム PO エンジニア デザイナー
16. サービス開発におけるプロダクトオーナーの役割 l サービス開発において、プロダクトオーナー（PO）という役割が 一般的になりつつあります l プロダクトオーナーの役割 l サービス（プロダクト）のコンセプト、ビジョンを定義する l ユーザーの調査、競合の調査 l 機能の優先度をつける l このサービスのコアな機能は。差別化要因は。 l サービスを方向転換（ピボット） するのかどうか l 開発者に作りたいものを伝える l プログラミングが分かる必要はないが、 開発者とコミュニケーションを取りながら 何が大変で、何は簡単なのかを理解する 16 ビジネスと開発が一体と なったチーム PO エンジニア デザイナー 重要になってきている アジャイルなどの開発プロセ スでより細かく・早く判断が 求められている
17. 従来のプロジェクトマネージャーとの違い l 従来のプロジェクトマネージャーの役割 l 品質（Quality）、コスト（Cost）、納期（Delivery）が計画通りに進む ようにマネジメントする l もともと想定している予算の枠に収まるように要件を絞り、要件定義 後は予算や納期に影響がでないように、新しい要件や変更要求を管理 l DXのシステム開発は最初から正解がわかっているわけではないと いう問題があります。そのため、最初にすべての要件を細かく定 義してしまうことは、むしろ無駄になる可能性があります 17
18. DXの実現に向けたオーバービュー（体制と構造） ①プロダクトオーナーを 中心とした小さなチーム 基幹システムとの連携 体制とシステムの構造 ②小さく分割された マイクロサービス 18
19. マイクロサービスとは 19 モノリシックな システム マイ クロ サー ビス 様々な機能を１つのシステ ムで実現。 各機能やデータは密に連携 しているため、システム改 修時に影響範囲が大きく、 変更に時間がかかる マイ クロ サー ビス マイ クロ サー ビス 機能の塊で、システムを分割。 各マイクロサービスは独立性を 保ち、他サービスと連携しなが ら全体の機能を提供するという 考え方
20. マイクロサービスと小さなチームは相性が良い 20 マイクロサービス PO エンジニア デザイナー マイクロサービス PO エンジニア デザイナー マイクロサービス PO エンジニア デザイナー 大きなシステムは関わる人数が多く情報伝達や管理を最適化するために PMを頂点とした、階層構造の深い組織となりがち。 マイクロサービスで小さなシステム規模を保つことで、 マイクロサービスごとのフラットで小さな組織で対応可能となる
21. 事例）大手製造業 21 製造部門内にアジャイルチームを設立。 ユーザー（工場）と近い位置で、業務とITを分かっている社員がPOを担当 PO エンジニア エンジニア 企業 IT部門 製造部門 工場 デザイナー （NCDC） エンジニア （NCDC） アジャイルチーム 支援 マネジメント モダンな開発手法と、UX の分析をサービス提供 エンジニアは社外からも 受けれてチームを組成 必要性を上層部に説得 インフラ環境の調整
22. チーム （体制） DXを実現するプロセス プロセス （どうやっ てやる か） テクノロ ジー （道具）
23. 新規サービスの場合、Lean Startupの考え方が有効 l Lean Startupとは l 新規事業を立ち上げる際の方法論 l スタートアップだけではなく、大企業の中で新規事業を立ち上げる場 合にも使える考え方 23
24. DXの実現に向けたオーバービュー（プロセス） アイデア創出 MVP開発 市場フィット検証 継続的な開発 サービス企画 計測 Design Thinking ユーザー分析 UX Lean Startup 本日の対象 サービスや、プロダクトを企画し、検証せずに考えられる全機能を 開発するのは製造業で全く新しいコンセプトの製品を 売れるかどうか分からないのに大規模な製造ラインを作って製造始めるようなもの。 検討したアイデアがユーザーの課題を解決するものなのかどうかを 検証することがとても重要です 24
25. Lean Startupでは次の２つの考え方が重要です l MVP（Minimum Viable Product） l 実行可能な最低限の機能を持ったプロダクトを作って、 ユーザーの反応を計測して、どんなサービスが価値があるのかを 探索する活動を行います l 最低限の機能というのが重要で、何を検証したいのかによって 最低限の機能が変わってきます l ピボット l MVPの結果から改善案を考える際、プロダクトの目的や 対象のユーザーを転換すること l 片足は固定して、片足は別の方向に転換するイメージ 25
26. 事例｜ AIを活用したサービス開発 26 Client｜メーカー（通信機器） Keyword｜新規サービス開発 , PoC , AI（動画解析） AIによる動画解析で クルマの安全性向上に取り組む。 お客さまの課題 | ⾃社の既存ビジネスの枠を超え た、最新のテクノロジーを活⽤したモビリティ関 連の新サービス開発を模索していた。 ソリューション |「動画解析技術を⽤いたシート ベルト着⽤率の改善」というテーマでサービスモ デルを提案。採⽤後は、PoC⽤の試作機（⾞内カ メラ）などを⽤いて試験⽤のデータを取得。約 9,000枚の画像を教師データとしてAIに学習させ、 ⼈やシートベルトを検出するモデルを作成。その 後、評価⽤のデータ約1,000枚にて予測を実施。 NCDCの役割 | 動画解析プログラムの開発だけで なく、試作機製造を担当するメーカーや機械学習 ⽤の教師データ作成を担当する企業との協業も当 社が主導して実施。企画、開発からPoCまでス ムーズなプロジェクト進⾏を実現。
27. 画像からの物体検出プロジェクトの例 27 サービス企画 ビジネスモデル検討 プロトタイプ プロトタイプを使っ た顧客インタビュー サービス企画、 ビジネスモデルの見直し 認識精度の 向上① 製品化のための準備 フィードバック • ターゲット顧客は 正しかったのか • サービスの内容、機能に 価値はありそうなのか • 購入にいたるまでの障害はなにか • 製品版のハードウェアの設計・調達 • ソフトウェアの品質向上 • 運用の計画 認識精度の 向上② • 手法の見直し、学習用データの見直し 投資判断
28. ウォーターフォールかアジャイルか 近年、アジャイルがキーワードになっていますが、 ウォーターフォールは古くて使えない手法なのでしょうか？ 28 要件が決まっている コンセプト ・計画通りに作る ・大規模開発しやすい リスク ・当初の計画がかなり重要 要件を決められない コンセプト ・変更を許容する ・無駄なものは作らない リスク ・柔軟が故に当初の期間、費用、 開発範囲が流動的になりやすい アジャイル ウォーター フォール
29. ウォーターフォールかアジャイルは目的に合わせて使い分けるし、０か１００かではない 29 要件が決まっている コンセプト ・計画通りに作る ・大規模開発しやすい リスク ・当初の計画がかなり重要 要件を決められない コンセプト ・変更を許容する ・無駄なものは作らない リスク ・柔軟が故に当初の期間、費用、 開発範囲が流動的になりやすい アジャイル ウォーター フォール 半年かけて企画して １年かけて開発後、 ユーザーに提供する →これは多分適していない MVPを作るための 3ヶ月間は決まった仕様通り 後戻りせずに作る ミニウォーターフォール →サービス内容によっては良さそう！ 1週間ごとにイテレーションして どんどんリリースもして 検証結果をフィードバックする →サービス内容によっては良さそう！
30. チーム （体制） DXを 実 現 す る テ ク ノ ロ ジ ー テクノロ ジー （道具） プロセス （どうやっ てやる か）
31. クラウドを活用して極力作らない、保守が少ない構成にする 31 クラウドを利用することで、インフラの調達、管理を クラウドベンダーに任せることができるようになりました さらにクラウドを前提としたアプリケーション設計を 行うことで、「俊敏性（アジリティ）」と 「拡張性（スケーラブル）」を得られます クラウドを前提としたアプリケーション、基盤は クラウドネイティブと呼ばれています
32. クラウドを前提としたアプリケーション設計って何？ l コンテナ、サーバレスなどの技術、 クラウドベンダーが提供しているマネージドサービスを 積極的に利用してサービスの設計、開発を行います l 俊敏性 l 自分たちで作る量を減らし、クラウドベンダーが提供している機能を サービスとして利用する l インフラだけでなく、OS、ミドルウェアの運用をクラウドベンダーに 任せ、自分たちの付加価値提供に集中する l 拡張性 l 小さく始めて、利用者の増加に応じて、オートスケールできる基盤、 アプリケーションの設計にする 32
33. 事例）サーバレスとマネージドサービスをフル活用したアーキテクチャ 33 Webアプリ コンテンツ アプリ向けAPI Lambda 業務ロジック DynamoDB 添付ファイル Cognito ユーザー認証 利用者 社内システム 社内システム 社内向けAPI Lambda 業務ロジック マスタ データ連携 バッチによる 日次データ取り込み AWS 自社データセンター Cloud Front S3 自社営業 向け配信 SNS Push通知
34. この構成では自分たちでサーバーを1台も用意していません 34 Webアプリ コンテンツ アプリ向けAPI Lambda 業務ロジック DynamoDB 添付ファイル Cognito ユーザー認証 利用者 社内システム 社内システム 社内向けAPI Lambda 業務ロジック マスタ データ連携 バッチによる 日次データ取り込み AWS 自社データセンター Cloud Front S3 自社営業 向け配信 SNS Push通知 AWS Lambda サーバレスな処理実装 Cognito マネージドな 認証サービス DynamoDB スケールアウト可能な データベース アプリケーションは S3とCloudFrontで配信
35. まとめ 35
36. まとめ 外部に発注しようとしたが、新規サービスでどのく らい需要があるか分からないのに、いきなり大きな 見積もりになってしまって開発に着手できない 開発ベンダーに要件を決めてくれと言われるが、現 在はない業務、サービスのため今の時点で明確は要 件はない サービスが具体化してきて要件を変更したら費用が 追加になると言われる 大きな投資をしたので、失敗できない クラウドを使い切れていない気がする Leanな進め方 POを中心としたビジネスと開 発が一体となったチーム MVPと計測による学習 クラウドネイティブなアプリ ケーション設計 36
37. DXの実現に必要な３つのキーファクター l プロダクトオーナーを中心とした ビジネスと開発が一体となった小さなチーム l Leanなサービス開発プロセスやアジャイルの方法論を 取り入れた変更があることを前提とした開発プロセス l クラウドが提供する各種サービスを積極的に活用した なるべく作らない、保守が少なくて済む アプリーケーション開発 37
38. NCDCではDX推進の方法論を定義 38
39. 事例｜DX推進チームの施策立案支援 39 Client｜建設コンサルタント Keyword｜ DX 経営層への提⾔を⾏う DX推進チームを多⾯的に⽀援。 お客さまの課題 | 官公庁の仕事をはじめ、⽐較的 安定した市場があるため、DXに乗り遅れることへ の危機感が薄かった。他社に先駆けてDXに取り組 むため各部⾨からメンバーを集めた推進プロジェ クトが⽴ち上げられたが、未知の分野が多く⾃社 のメンバーのみでは推進が困難なためコンサル ティングパートナーを求めていた。 ソリューション | お客さまのDX推進プロジェクト チームと定例会を持ち、3ヶ⽉間でシステムアーキ テクチャ、働き⽅改⾰、営業改⾰など多様なテー マのデジタル化推進策を検討。プロジェクトチー ムが経営層に対するDX施策や予算提案を取りまと める⽀援を⾏いました。 NCDCの役割 | 定例会にはNCDCのビジネスコン サルタントやITコンサルタント、デジタルマーケ ティングコンサルタントなどがニーズに応じて随 時参加。⽅針検討から導⼊ツール選定まで幅広い ⽀援を⾏いました。
40. DXに関するNCDCのサービス 40
41. ご相談はお気軽に！ l DX関連、新規サービス企画、UXデザイン、クラウドインテグレーション、 アジャイル等のプロセス支援 l info@ncdc.co.jp 41