ncdc-techseminer-20200115

DXを成功に導くための
３つのキーファクターとは
2 0 2 0 / 0 1 / 1 5
N C D C 株式会社
⼗川亮平

View Slide

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

View Slide

NCDCのサービス
l CX/UXと先端テクノロジーによってデジタルイノベーションを推進します
3
NCDC
CX/UX
デザイン
先端
テクノロジー
自社
サービス
• 新規サービス企画
• CX/UXデザインコンサルティング
• IoT/AI
• クラウドインテグレーション
• モバイル・Web先端技術
• モバイルプラットフォーム
[AppPot]の製造・販売
• IoTプラットフォーム
• [AppPot IoT]の製造・販売

View Slide

NCDCのサービスの特徴
4
ビジネスモデルのデザイン PoC・検証システム・インテグレーション
ワークショップ中⼼にビジネスモデル
からUXデザインまでを迅速に⾏いま
す。組織横断、会社横断のファシリ
テーションも得意です。
モックによる検証から現地検証まで、
PoCをその⽬的に応じて企画・実施
します
センサーから、AI、クラウド、
モバイルの標準技術まで、多
くのテクノロジーをインテグ
レーションします
ビジネスモデルの検討からデザインによる可視化、
先端テクノロジーの組み合わせでシステムを構築します

View Slide

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

View Slide

今日のテーマ
DXのアイデアは⾒つかった。DXの実現のために、どのような
⼿法がよいのでしょうか
DXの実現に必要な３つのキーファクター
l どのような体制を準備すべきか
l プロセス
l テクノロジー

View Slide

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

View Slide

DXを実現するチーム

View Slide

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

View Slide

DXはビジネスと開発が一体であるのが望ましい
l 体制上、ビジネスと開発が分離されることがよくあります
• 事業部とIT部⾨
• 発注者と受託者
ビジネス側で決まったことを作るだけならこれでいいですが・・・
l DXは実⾏段階で⽅向転換が
頻繁に発⽣するため、
ビジネスが分かるメンバーと
開発ができるメンバーが
⼀体となった⼩さなチームが望ましい
• メンバーを外部から受けいれる
ことは問題ない
11
ビジネスと開発が⼀体と
なったチーム
PO
エンジニアデザイナー

View Slide

プロダクトオーナーって誰？
l サービス開発において、プロダクトオーナー（PO）という役割が
明確化されるようになってきました
l プロダクトオーナーの役割
• サービス（プロダクト）のコンセプト、ビジョンを定義する
ユーザーの調査、競合の調査
• 機能の優先度をつける
このサービスのコアな機能は。差別化要因は。
• 開発者に作りたいものを伝える
• サービスを⽅向転換（ピボット）するのかどうか
l プロダクトオーナーは他業務との掛け持ちは⼤変・・・。
外部に依頼することも現実的ではない
• プロダクトオーナーは複数いてもいい
12

View Slide

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

View Slide

DXの実現に向けたオーバービュー（体制と構造）
①プロダクトオーナーを
中⼼とした⼩さなチーム
基幹システムとの連携
体制とシステムの構造
②⼩さく分割された

View Slide

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

View Slide

マイクロサービスと小さなチームは相性が良い
16
PO
PO
PO
⼤きなシステムはPMを頂点とした、階層構造の深い組織となりがち。
マイクロサービスで⼩さなシステムを保つことで、
マイクロサービスごとのフラットな⼩さな組織で対応可能となる

View Slide

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

View Slide

DXを実現するプロセス

View Slide

DXの実現に向けたオーバービュー（プロセス）
アイデア創出 MVP開発
市場フィット検証
継続的な開発
サービス企画計測
Design
Thinking
ユーザー分析
UX
Lean Startup
本⽇の対象

View Slide

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

View Slide

スタートアップの３つのステージ
21
第１ステージ
課題/解決フィット
第２ステージ
製品/市場フィット
第３ステージ
拡⼤
• 顧客が必要としている課題か
• お⾦を⽀払ってくれるか
• 解決可能な問題か
MVPの開発
• 作ったものに顧客が
どのくらいいるのか
計測
• どうやって成⻑を拡
⼤させるのか
検証による学習とピボットに集中成⻑と最適化に集中
資⾦調達（⼤きな投
資）に適した時期

View Slide

MVPとピボットの説明
l MVP（Minimum Viable Product）
• 実⾏可能な最低限の機能を持ったプロダクトを作って、ユーザーの反応
を計測して、改善案を考える
• プロトタイプという概念を定義づけした
l ピボット
• MVPの結果から改善案を考える際、プロダクトの⽬的や概要を転換する
こと
• ⽚⾜は固定して、⽚⾜は別の転換するイメージ
22

View Slide

事例）製薬メーカー付加価値の高い営業支援アプリ
23
MVP開発
計測と学習
ピボット
• 利⽤者数
• 何⼈の医師とあっているか
• ⼀⼈の医師と何回話せているか
• 聞き取りした項⽬の⼊⼒率
• UXの変更
構造的に整理された⼊⼒項⽬から
必ず簡易⼊⼒版と、詳細⼊⼒版に分けた
運⽤
これまでなかった業務のデジタル化に、どれだけユーザーに使ってもらえるかが
ポイントだった。
• ⾃社のお薬を使ってい
る症例情報について医
師から聞き取とり、
情報提供などを⾏う
必須で⼊れて
ほしい項⽬の
⼊⼒率向上

View Slide

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

View Slide

DXを実現するテクノロジー

View Slide

クラウドを使い倒すために
l クラウドを利⽤することで、インフラの調達、管理をクラ
ウドベンダーに任せることができるようになりました
l さらにクラウドを前提としたアプリケーション設計を
⾏うことで、「俊敏性（アジリティ）」、「拡張性（ス
ケーラブル）」を得られます
l このような構成がクラウドネイティブと呼ばれています
26

View Slide

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

View Slide

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

View Slide

事例）サーバレスとマネージドサービスをフル活用したアーキテクチャ
29
Webアプリ
コンテンツ
アプリ向けAPI Lambda
業務ロジック
DynamoDB
添付ファイル
Cognito
ユーザー認証
利⽤者
社内システム
社内システム
社内向けAPI
Lambda
業務ロジック
マスタ
データ連携
バッチによる
⽇次データ取り込み
AWS ⾃社データセンター
Cloud
Front
S3
⾃社営業
向け配信
SNS
Push通知
AWS Lambda
サーバレスな処理実装
Cognito
マネージドな
認証サービス
DynamoDB
スケールアウト可能な
データベース
アプリケーションは
S3とCloudFrontで配信

View Slide

まとめ
30

View Slide

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

View Slide

DXの実現に必要な３つのキーファクター
l プロダクトオーナーを中⼼としたビジネスと開発が⼀体と
なった⼩さなチーム
l Leanなプロセスで、MVPの開発と計測、ピボットの⾒極め
l クラウドを使い倒すクラウドネイティブなアプリケーショ
ン

View Slide

本日のセッションに関連するNCDCのサービス
33
サービス企画・
UX/CXのコンサル
ティング
PoC、アプリケー
ションの開発
プロダクトオー
ナー⽀援
クラウド化の推進
⽀援

View Slide

NCDCのサービスの特徴
34
ビジネスモデルのデザイン PoC・検証システム・インテグレーション
ワークショップ中⼼にビジネスモデル
からUXデザインまでを迅速に⾏いま
す。組織横断、会社横断のファシリ
テーションも得意です。
モックによる検証から現地検証まで、
PoCをその⽬的に応じて企画・実施
します
センサーから、AI、クラウド、
モバイルの標準技術まで、多
くのテクノロジーをインテグ
レーションします
ビジネスモデルの検討からデザインによる可視化、
先端テクノロジーの組み合わせでシステムを構築します

View Slide

View Slide

ncdc-techseminer-20200115

ncdc-techseminer-20200115

NCDC

More Decks by NCDC

Other Decks in Technology

Featured

Transcript