Slide 1

Slide 1 text

DXを成功に導く鍵 クラウドやアジャイルを活用した 迅速なアイデア実現手法とは? NCDCオンラインセミナー 2021年11月9日 NCDC株式会社 十川 亮平

Slide 2

Slide 2 text

プレゼンター紹介 2 十川 亮平 取締役/CTO NCDCでは、モバイル、API、IoT、機械学習 などを使ったクライアントの新規サービス の企画立案や、プロジェクトの推進を支援 を担当。 Webサービス/モバイルアプリのバックエ ンドプラットフォームであるAppPotプロダ クトマネージャーとして、マーケティング 活動やAPIの開発を行っている。

Slide 3

Slide 3 text

Business 事業領域の推進 Design ユーザ視点での設計 Technology 技術による課題解決 Innovation • コンサルティング • 新規サービス企画 • PoC⽀援 • デザイン思考 • UX/UIデザイン • モバイル・Web先端技術 • IoT / AI / AR • クラウドインテグレーション NCDCのサービス体系 3

Slide 4

Slide 4 text

私たちにできること① l デジタルビジネスに必要な要素にフォーカスし、⼀元的に提供しています。 l スモールスタートでの検証から、本開発・継続的な改善までサポートします。 4 ワークショップを中⼼とし た合理的なプロセスで、ビ ジネスモデルの検討からUX デザインまで、迅速に⾏い ます。 関係者が多数いる場合の組 織横断、会社横断のファシ リテーションも得意です。 新規性の⾼いプロジェクト ではMVP(Minimum Viable Product)を⽤いた検証を⾏ うなど、⽬的に応じて段階 的な開発を企画します。 早い段階でモックやプロト タイプを⽤意してユーザの 評価を確認します。 ユーザとのタッチポイントとなる各種デバ イスのフロントエンドデザインから、クラ ウドサービスを駆使したバックエンドの開 発まで。多様なテクノロジーをインテグ レーションします。 l AI / IoT / AR l モバイル・ウェブ アプリ開発 l クラウドインテグレーション l システムアーキテクチャコンサルティング など ビジネスモデルのデザイン スモールスタート・PoC システム・インテグレーション ユーザ視点を⼤切にした 課題抽出・企画 モックやプロトタイプ の開発・検証 開発 継続的な改善

Slide 5

Slide 5 text

私たちにできること② l 社内に最適な組織がない場合の組織づくりや⼈材育成から、⾼度な技術をもったエンジニ アによる技術移管まで、幅広くお客様をサポートします。 5 ビジネスモデルのデザイン スモールスタート・PoC システム・インテグレーション ユーザ視点を⼤切にした 課題抽出・企画 モックやプロトタイプ の開発・検証 開発 継続的な改善 企業のDXやデジタルビジネスの創出に必要なこうしたプロセスを多⾯的にサポート DX戦略⽴案 ⼈材育成 技術移管 リファレンス実装 DX組織構築⽀援 アジャイル導⼊⽀援 ⼿法や技術の選定 ブランディング

Slide 6

Slide 6 text

DXを 成 功 に 導 く た め の 3 つ の キ ー フ ァ ク タ ー と は

Slide 7

Slide 7 text

DXをわかりやすく整理 l NCDCでは2つのタイプに分けて整理 デジタルを活用した新たな収益源を作る。 新たなサービス・事業を作る。 デジタルを活用した既存業務の変革を行う。 新規サービス系DX 業務改⾰系DX 7 こちらは従来からの業務向け大規模シ ステム開発と大差がない印象。 デジタルで 儲かることを考えて・作り・運用する!

Slide 8

Slide 8 text

DXは実行しながら方向転換や、やってみて分かることがある l 前提 l DXではこれまでシステムが存在しなかった領域の業務や、 新しい製品をデジタルで実現するケースが多い。 l そのため、こういう機能を作ったら良いというのを 決めることは難しい そのため、基本的には仮説を立て、検証を行い、 実際に価値があるものは何かを探しながら サービスやプロダクトの開発を行います。 8

Slide 9

Slide 9 text

こんな課題、皆さんの周りにもないでしょうか l 外部に発注しようとしたが、新規サービスでどのくらい需要があ るか分からないのに、いきなり大きな見積もりになってしまって 開発に着手できない l 開発ベンダーに要件を決めてくれと言われるが、現在はない業務、 サービスのため今の時点で明確は要件はない l サービスが具体化してきて要件を変更したら費用が追加になると 言われる l 大きな投資をしたので、失敗できない l クラウドを使い切れていない気がする 9

Slide 10

Slide 10 text

DXのアイデアは見つかった(とします) それではDXの実現のために、どのような手法がよいのでしょうか DXの実現に必要な3つのキーファクター チーム (体制) プロセス (どうやっ てやる か) テクノロ ジー (道具) 10

Slide 11

Slide 11 text

DXを実現するチーム チーム (体制) プロセス (どうやっ てやる か) テクノロ ジー (道具)

Slide 12

Slide 12 text

DXの実現に向けたオーバービュー(体制と構造) ①プロダクトオーナーを 中心とした小さなチーム 基幹システムとの連携 体制とシステムの構造 ②小さく分割された マイクロサービス 12

Slide 13

Slide 13 text

DXの実現に向けたオーバービュー(体制と構造) ①プロダクトオーナーを 中心とした小さなチーム 基幹システムとの連携 体制とシステムの構造 ②小さく分割された マイクロサービス 13

Slide 14

Slide 14 text

DXはビジネスと開発が一体であるのが望ましい l これまでビジネスと開発が分離された体制がよくありました l 事業部とIT部門 l 発注者と受託者 ビジネス側で決まったことを作るだけならこれでいいですが・・・ l DXでは実行段階で方向転換が 頻繁に発生するため、 ビジネスが分かるメンバーと 開発ができるメンバーが 一体となった小さいチームが望ましい l 従来のプロジェクトと異なりリリースしたら 解散ではなく、継続的なチームの維持が必要 14 ビジネスと開発が一体と なったチーム PO エンジニア デザイナー

Slide 15

Slide 15 text

サービス開発におけるプロダクトオーナーの役割 l サービス開発において、プロダクトオーナー(PO)という役割が 一般的になりつつあります l プロダクトオーナーの役割 l サービス(プロダクト)のコンセプト、ビジョンを定義する l ユーザーの調査、競合の調査 l 機能の優先度をつける l このサービスのコアな機能は。差別化要因は。 l サービスを方向転換(ピボット) するのかどうか l 開発者に作りたいものを伝える l プログラミングが分かる必要はないが、 開発者とコミュニケーションを取りながら 何が大変で、何は簡単なのかを理解する 15 ビジネスと開発が一体と なったチーム PO エンジニア デザイナー

Slide 16

Slide 16 text

サービス開発におけるプロダクトオーナーの役割 l サービス開発において、プロダクトオーナー(PO)という役割が 一般的になりつつあります l プロダクトオーナーの役割 l サービス(プロダクト)のコンセプト、ビジョンを定義する l ユーザーの調査、競合の調査 l 機能の優先度をつける l このサービスのコアな機能は。差別化要因は。 l サービスを方向転換(ピボット) するのかどうか l 開発者に作りたいものを伝える l プログラミングが分かる必要はないが、 開発者とコミュニケーションを取りながら 何が大変で、何は簡単なのかを理解する 16 ビジネスと開発が一体と なったチーム PO エンジニア デザイナー 重要になってきている アジャイルなどの開発プロセ スでより細かく・早く判断が 求められている

Slide 17

Slide 17 text

従来のプロジェクトマネージャーとの違い l 従来のプロジェクトマネージャーの役割 l 品質(Quality)、コスト(Cost)、納期(Delivery)が計画通りに進む ようにマネジメントする l もともと想定している予算の枠に収まるように要件を絞り、要件定義 後は予算や納期に影響がでないように、新しい要件や変更要求を管理 l DXのシステム開発は最初から正解がわかっているわけではないと いう問題があります。そのため、最初にすべての要件を細かく定 義してしまうことは、むしろ無駄になる可能性があります 17

Slide 18

Slide 18 text

DXの実現に向けたオーバービュー(体制と構造) ①プロダクトオーナーを 中心とした小さなチーム 基幹システムとの連携 体制とシステムの構造 ②小さく分割された マイクロサービス 18

Slide 19

Slide 19 text

マイクロサービスとは 19 モノリシックな システム マイ クロ サー ビス 様々な機能を1つのシステ ムで実現。 各機能やデータは密に連携 しているため、システム改 修時に影響範囲が大きく、 変更に時間がかかる マイ クロ サー ビス マイ クロ サー ビス 機能の塊で、システムを分割。 各マイクロサービスは独立性を 保ち、他サービスと連携しなが ら全体の機能を提供するという 考え方

Slide 20

Slide 20 text

マイクロサービスと小さなチームは相性が良い 20 マイクロサービス PO エンジニア デザイナー マイクロサービス PO エンジニア デザイナー マイクロサービス PO エンジニア デザイナー 大きなシステムは関わる人数が多く情報伝達や管理を最適化するために PMを頂点とした、階層構造の深い組織となりがち。 マイクロサービスで小さなシステム規模を保つことで、 マイクロサービスごとのフラットで小さな組織で対応可能となる

Slide 21

Slide 21 text

事例)大手製造業 21 製造部門内にアジャイルチームを設立。 ユーザー(工場)と近い位置で、業務とITを分かっている社員がPOを担当 PO エンジニア エンジニア 企業 IT部門 製造部門 工場 デザイナー (NCDC) エンジニア (NCDC) アジャイルチーム 支援 マネジメント モダンな開発手法と、UX の分析をサービス提供 エンジニアは社外からも 受けれてチームを組成 必要性を上層部に説得 インフラ環境の調整

Slide 22

Slide 22 text

チーム (体制) DXを実現するプロセス プロセス (どうやっ てやる か) テクノロ ジー (道具)

Slide 23

Slide 23 text

新規サービスの場合、Lean Startupの考え方が有効 l Lean Startupとは l 新規事業を立ち上げる際の方法論 l スタートアップだけではなく、大企業の中で新規事業を立ち上げる場 合にも使える考え方 23

Slide 24

Slide 24 text

DXの実現に向けたオーバービュー(プロセス) アイデア創出 MVP開発 市場フィット検証 継続的な開発 サービス企画 計測 Design Thinking ユーザー分析 UX Lean Startup 本日の対象 サービスや、プロダクトを企画し、検証せずに考えられる全機能を 開発するのは製造業で全く新しいコンセプトの製品を 売れるかどうか分からないのに大規模な製造ラインを作って製造始めるようなもの。 検討したアイデアがユーザーの課題を解決するものなのかどうかを 検証することがとても重要です 24

Slide 25

Slide 25 text

Lean Startupでは次の2つの考え方が重要です l MVP(Minimum Viable Product) l 実行可能な最低限の機能を持ったプロダクトを作って、 ユーザーの反応を計測して、どんなサービスが価値があるのかを 探索する活動を行います l 最低限の機能というのが重要で、何を検証したいのかによって 最低限の機能が変わってきます l ピボット l MVPの結果から改善案を考える際、プロダクトの目的や 対象のユーザーを転換すること l 片足は固定して、片足は別の方向に転換するイメージ 25

Slide 26

Slide 26 text

事例| AIを活用したサービス開発 26 Client|メーカー(通信機器) Keyword|新規サービス開発 , PoC , AI(動画解析) AIによる動画解析で クルマの安全性向上に取り組む。 お客さまの課題 | ⾃社の既存ビジネスの枠を超え た、最新のテクノロジーを活⽤したモビリティ関 連の新サービス開発を模索していた。 ソリューション |「動画解析技術を⽤いたシート ベルト着⽤率の改善」というテーマでサービスモ デルを提案。採⽤後は、PoC⽤の試作機(⾞内カ メラ)などを⽤いて試験⽤のデータを取得。約 9,000枚の画像を教師データとしてAIに学習させ、 ⼈やシートベルトを検出するモデルを作成。その 後、評価⽤のデータ約1,000枚にて予測を実施。 NCDCの役割 | 動画解析プログラムの開発だけで なく、試作機製造を担当するメーカーや機械学習 ⽤の教師データ作成を担当する企業との協業も当 社が主導して実施。企画、開発からPoCまでス ムーズなプロジェクト進⾏を実現。

Slide 27

Slide 27 text

画像からの物体検出プロジェクトの例 27 サービス企画 ビジネスモデル検討 プロトタイプ プロトタイプを使っ た顧客インタビュー サービス企画、 ビジネスモデルの見直し 認識精度の 向上① 製品化のための準備 フィードバック • ターゲット顧客は 正しかったのか • サービスの内容、機能に 価値はありそうなのか • 購入にいたるまでの障害はなにか • 製品版のハードウェアの設計・調達 • ソフトウェアの品質向上 • 運用の計画 認識精度の 向上② • 手法の見直し、学習用データの見直し 投資判断

Slide 28

Slide 28 text

ウォーターフォールかアジャイルか 近年、アジャイルがキーワードになっていますが、 ウォーターフォールは古くて使えない手法なのでしょうか? 28 要件が決まっている コンセプト ・計画通りに作る ・大規模開発しやすい リスク ・当初の計画がかなり重要 要件を決められない コンセプト ・変更を許容する ・無駄なものは作らない リスク ・柔軟が故に当初の期間、費用、 開発範囲が流動的になりやすい アジャイル ウォーター フォール

Slide 29

Slide 29 text

ウォーターフォールかアジャイルは目的に合わせて使い分けるし、0か100かではない 29 要件が決まっている コンセプト ・計画通りに作る ・大規模開発しやすい リスク ・当初の計画がかなり重要 要件を決められない コンセプト ・変更を許容する ・無駄なものは作らない リスク ・柔軟が故に当初の期間、費用、 開発範囲が流動的になりやすい アジャイル ウォーター フォール 半年かけて企画して 1年かけて開発後、 ユーザーに提供する →これは多分適していない MVPを作るための 3ヶ月間は決まった仕様通り 後戻りせずに作る ミニウォーターフォール →サービス内容によっては良さそう! 1週間ごとにイテレーションして どんどんリリースもして 検証結果をフィードバックする →サービス内容によっては良さそう!

Slide 30

Slide 30 text

チーム (体制) DXを 実 現 す る テ ク ノ ロ ジ ー テクノロ ジー (道具) プロセス (どうやっ てやる か)

Slide 31

Slide 31 text

クラウドを活用して極力作らない、保守が少ない構成にする 31 クラウドを利用することで、インフラの調達、管理を クラウドベンダーに任せることができるようになりました さらにクラウドを前提としたアプリケーション設計を 行うことで、「俊敏性(アジリティ)」と 「拡張性(スケーラブル)」を得られます クラウドを前提としたアプリケーション、基盤は クラウドネイティブと呼ばれています

Slide 32

Slide 32 text

クラウドを前提としたアプリケーション設計って何? l コンテナ、サーバレスなどの技術、 クラウドベンダーが提供しているマネージドサービスを 積極的に利用してサービスの設計、開発を行います l 俊敏性 l 自分たちで作る量を減らし、クラウドベンダーが提供している機能を サービスとして利用する l インフラだけでなく、OS、ミドルウェアの運用をクラウドベンダーに 任せ、自分たちの付加価値提供に集中する l 拡張性 l 小さく始めて、利用者の増加に応じて、オートスケールできる基盤、 アプリケーションの設計にする 32

Slide 33

Slide 33 text

事例)サーバレスとマネージドサービスをフル活用したアーキテクチャ 33 Webアプリ コンテンツ アプリ向けAPI Lambda 業務ロジック DynamoDB 添付ファイル Cognito ユーザー認証 利用者 社内システム 社内システム 社内向けAPI Lambda 業務ロジック マスタ データ連携 バッチによる 日次データ取り込み AWS 自社データセンター Cloud Front S3 自社営業 向け配信 SNS Push通知

Slide 34

Slide 34 text

この構成では自分たちでサーバーを1台も用意していません 34 Webアプリ コンテンツ アプリ向けAPI Lambda 業務ロジック DynamoDB 添付ファイル Cognito ユーザー認証 利用者 社内システム 社内システム 社内向けAPI Lambda 業務ロジック マスタ データ連携 バッチによる 日次データ取り込み AWS 自社データセンター Cloud Front S3 自社営業 向け配信 SNS Push通知 AWS Lambda サーバレスな処理実装 Cognito マネージドな 認証サービス DynamoDB スケールアウト可能な データベース アプリケーションは S3とCloudFrontで配信

Slide 35

Slide 35 text

まとめ 35

Slide 36

Slide 36 text

まとめ 外部に発注しようとしたが、新規サービスでどのく らい需要があるか分からないのに、いきなり大きな 見積もりになってしまって開発に着手できない 開発ベンダーに要件を決めてくれと言われるが、現 在はない業務、サービスのため今の時点で明確は要 件はない サービスが具体化してきて要件を変更したら費用が 追加になると言われる 大きな投資をしたので、失敗できない クラウドを使い切れていない気がする Leanな進め方 POを中心としたビジネスと開 発が一体となったチーム MVPと計測による学習 クラウドネイティブなアプリ ケーション設計 36

Slide 37

Slide 37 text

DXの実現に必要な3つのキーファクター l プロダクトオーナーを中心とした ビジネスと開発が一体となった小さなチーム l Leanなサービス開発プロセスやアジャイルの方法論を 取り入れた変更があることを前提とした開発プロセス l クラウドが提供する各種サービスを積極的に活用した なるべく作らない、保守が少なくて済む アプリーケーション開発 37

Slide 38

Slide 38 text

NCDCではDX推進の方法論を定義 38

Slide 39

Slide 39 text

事例|DX推進チームの施策立案支援 39 Client|建設コンサルタント Keyword| DX 経営層への提⾔を⾏う DX推進チームを多⾯的に⽀援。 お客さまの課題 | 官公庁の仕事をはじめ、⽐較的 安定した市場があるため、DXに乗り遅れることへ の危機感が薄かった。他社に先駆けてDXに取り組 むため各部⾨からメンバーを集めた推進プロジェ クトが⽴ち上げられたが、未知の分野が多く⾃社 のメンバーのみでは推進が困難なためコンサル ティングパートナーを求めていた。 ソリューション | お客さまのDX推進プロジェクト チームと定例会を持ち、3ヶ⽉間でシステムアーキ テクチャ、働き⽅改⾰、営業改⾰など多様なテー マのデジタル化推進策を検討。プロジェクトチー ムが経営層に対するDX施策や予算提案を取りまと める⽀援を⾏いました。 NCDCの役割 | 定例会にはNCDCのビジネスコン サルタントやITコンサルタント、デジタルマーケ ティングコンサルタントなどがニーズに応じて随 時参加。⽅針検討から導⼊ツール選定まで幅広い ⽀援を⾏いました。

Slide 40

Slide 40 text

DXに関するNCDCのサービス 40

Slide 41

Slide 41 text

ご相談はお気軽に! l DX関連、新規サービス企画、UXデザイン、クラウドインテグレーション、 アジャイル等のプロセス支援 l [email protected] 41

Slide 42

Slide 42 text

No content