NCDC_DX-DEV_20220531

Non-IT人材でもわかる！専門家だけに依存しないDX時代のシステム開発

Transcript

1. Non-IT人材でもわかる！ 専門家だけに依存しないDX時代のシステム開発 2021 / 05 / 31 NCDC株式会社 NCDC Online Seminar
2. 島田 将人 シニアコンサルタント 前職にてシステムエンジニアとしてキャリ アをスタートし、公的機関の大規模な業務 システム開発、及びAIを用いた新規システ ムの開発・保守に従事。 NCDCに入社後もビジネスコンサルティン グやシステム開発マネジメント、データ分 析案件等、多岐にわたる業務に従事。 2
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 事業部門でDX推進のミッションを与えられ、これからシステム開発含 めたDX施策を遂行しようとしている方 l システム開発プロジェクトに初めて参画しようとしているNon-ITの方 l DXの文脈におけるシステム開発の目的には以下の2種類があります が、本セミナーでは主に1の文脈に則って説明を進めます 1. 新規サービスの創出 2. 業務プロセス改革 8
9. 事業企画からシステム開発までの流れ
10. 全体像 l 「アイデア創出」「PoC」「展開」の大きく3つのフェーズが あります 10 展開フェーズ PoCフェーズ アイデア創出フェーズ 事業性 評価 ビジネス モデル 評価 アイデア 創出 PoC 販売戦略・運用方法検討 展開 サービススタート 向けシステム開発 タ ス ク 具 体 的 に や る べ き こ と • アイデア創出 • ビジネスフレームワーク を活用した分析 • 市場動向・他社動向・自 社の特徴、世の中のトレ ンド・技術的トレンドの 把握 • 事業計画立案 • 社内ステークホルダ説得 • UXデザイン • PoC検証計画策定 • PoC予算化 • システム開発 • 販売戦略からの具体的な販路開拓 • 業務運用・システム運用計画 • ステークホルダの巻き込み • 事業計画・予算承認・社内説得 • 撤退方針策定 • 体制作り システム開発を行う部分 PoC 計画 PoC用 システム開発
11. DX時代の到来によるシステム開発のあり方の変化 11 l 今までのパターン l 事業部門が企画書を取りまとめ、システムの開発・改修が関わる部分は情報シス テム部門に依頼 l 情報システム部門が事業部門からヒアリングしながら要件を取りまとめ、内製も しくは外部ベンダーへの発注によって開発 l DXの文脈では l IT人材であるか否かに関わらず、情報システム部門を経由せずにシ ステム開発に関与する機会が多くなってきている l 色々な製品の登場によって、Non-ITでもシステム開発にリーチしやすく なっている
12. 最近よく聞く失敗談 l お金をかけた割には思った通りのものができない！ l ちなみに・・・ l IT投資は100万オーダーだと少額な部類に入ります l 1000万, 1億, それ以上の単位のものも一般的にあります l 高額になりがちなITへの投資を有意義な投資にするためには l 何に気をつければ良いのか？何を考えれば良いのか？ l ベンダーに何を伝えれば良いのか？ 12 本セミナーでお伝えしたいこと
13. アイデア創出フェーズのポイント
14. アイデア創出フェーズで重要なこと l 構想したアイデアを、できる限り具現化することが重要です l システム開発の外注を検討する場合、事業性評価のタイミングで概算見積を出して もらう必要があります l しかし、アイデアレベルだとベンダーから具体的な見積は出てきません l 出せたとしても高い見積になりがち l いわゆるSIerにとっては、新規ビジネス売上規模が小さくリスクが大きい領域であり、あ まり手を出したがりません l 情報システム部門が取引した実績のあるベンダーを紹介してもらうのが安心です l 会社の業務やカルチャーを分かってくれているため 14 展開フェーズ PoCフェーズ アイデア創出フェーズ 事業性 評価 ビジネス モデル 評価 アイデア 創出 PoC 販売戦略・運用方法検討 展開 サービススタート 向けシステム開発 タ ス ク PoC 計画 PoC用 システム開発
15. PoCフェーズのポイント
16. PoCフェーズで重要なこと l このフェーズ以降、ベンダーとの対話が多くなります l 「PoCで何を検証したいか」を明確に設定し、そのために必要なこ と、必要でないことを主体的に選別する必要があります l 検証が不要な場合は、PoCを実施せずにMVPを開発して初回リリースに 踏み切るという進め方もあります l ベンダーに明確な意思を伝えないと、思った通りの成果が出な かったり、過剰な成果物が出来上がったりしてしまいます 16 展開フェーズ PoCフェーズ アイデア創出フェーズ 事業性 評価 ビジネス モデル 評価 アイデア 創出 PoC 販売戦略・運用方法検討 展開 サービススタート 向けシステム開発 タ ス ク PoC 計画 PoC用 システム開発
17. 社内で検討し、開発ベンダーと議論すべきポイント 1. どこまで作る？(機能要件) 2. PoC向け開発物の取り扱い 3. どこまで作る？(非機能要件) 4. PoCのスケジュール 5. どこで作る？ 6. [Tips]PoC期間のベンダー関与について l 検討の順序 17 1 3 4 5 2
18. どこまで作る？(機能要件) l 最低限どのような機能を用意すれば、実証の目的を達成できる か？ l 検証のために必要な機能については、ベンダーは助言はできても 判断はできません l もしかすると、検証のためだけに必要な機能もあるかもしれない l 必要となる開発コストや開発期間をベンダーに聞きつつ、実証を 完遂できる必要最低限の機能を見定めましょう 18
19. PoC向け開発物の取り扱い l PoC向けに開発した物を、展開時も活用するか？あくまでPoCに用 途を絞るか？を考えておきましょう 19 展開時も活用 PoCのみ メリット • 展開時は差分の開発のみにとどめ ることができるため、PoC以降の コストと期間をスリム化できる(可 能性が高い) • シンプルな成果物を、低コスト・ 短期間で開発することができる デメリット • 拡張性の考慮が大変 • PoCの結果、予見できなかった改 善要望や機能追加要望への対応が 必要となった場合には一から作り 直す決断も迫られる • 展開時に、再度初回開発をするこ とになる
20. どこまで作る？(非機能要件) l 非機能要件とは・・・ l 拡張性 l 追加開発・機能拡張のしやすさ l 性能 l 画面表示やデータベース更新等各種処理の速度 l 可用性 l システムの稼働時間 l セキュリティ l 非機能をどこまで充実させるかによって、開発のコストと期間は 大きく変動します l 検証の目的を達成するための最低限の要件を見定め、そのレベル で問題ないか否かを確認しましょう 20
21. PoCフェーズのスケジュール l 計画・開発・PoCそれぞれで必要な期間を算出します l よくある失敗事例 l 計画の最初の段階で全体の期間を最初に設定し、検証期間を割り当て た結果、開発に使える期間が短くなり過ぎてしまう 21 PoC計画 1か月 PoC用 システム開発 2か月 PoC 3か月 計画の最初に、PoCフェーズ全体の期間を6か月と決める 開発期間が 短すぎる！ ① ② ③
22. PoCフェーズのスケジュール l 望ましい計画の立て方 1. 計画を基に検証に必要な期間を定め、更に開発の期間を確保 2. 各フェーズに必要な期間の合算で全体的なスケジュールを決定 22 PoC計画 1か月 PoC用 システム開発 4か月 PoC 3か月 最後に、各フェーズ合算でPoCフェーズ全体の期間を8か月と決める 適切な開発 期間を確保 ③ ① ②
23. どこで作る？ • Microsoft Office365 • Google workspace • Salesforce SaaS(Software as a Service) • AWS/GCP/Azureのマネージドサービス • Kintone • ノーコード・ローコードツール PaaS(Platform as a Service) • クラウド上のレンタルサーバー(EC2(AWS)やGCE(GCP)) • データセンター • 自前のサーバー IaaS(Infrastructure as a Service) 23 すぐに使い始められる 準備にかかる コストや手間が大きい
24. どこで作る？ l SaaS→PaaS→IaaSの順に活用を検討することでスピーディーに実装 し、検証に移れます l 社内の既存業務を対象としたDXの文脈だと、 l 「業務にシステムを合わせる」よりも「製品に業務を合わせる」の考 え方が主流になってきています l 「SaaSありき」の考え方も有効です 24
25. 展開フェーズ PoCフェーズ アイデア創出フェーズ 事業性 評価 ビジネス モデル 評価 アイデア 創出 販売戦略・運用方法検討 展開 サービススタート 向けシステム開発 タ ス ク PoC 計画 PoC用 システム開発 [Tips]検証期間のベンダーの関与 l この時期は事業部門が主体となった検証期間であり、ベンダーが動くこ とは基本的にはありません l しかし、契約の空白期間があると再開時にメンバーが変わる可能性が高 くなります l ベンダーも、このような契約は嫌がりがち l 検証期間中も以下のような作業をベンダーに依頼し、ベンダー側の主要 メンバーを保持しておくことが望ましいでしょう l 保守 l 展開に向けた要件定義 25 PoC
26. 展開フェーズのポイント
27. 展開フェーズ PoCフェーズ アイデア創出フェーズ 事業性 評価 ビジネス モデル 評価 アイデア 創出 PoC 販売戦略・運用方法検討 展開 サービススタート 向けシステム開発 タ ス ク PoC 計画 PoC用 システム開発 展開フェーズで重要なこと l ここではまず、展開プランを考えます l 計画に応じた展開プランを選択したら、そのプランに沿って開発 やリリースを進めていきます l 展開を円滑に進められるよう、このフェーズでも引き続きベン ダーとの密な対話を行います 27
28. 展開のパターン l 展開の方法は、大きく以下の2パターンがあります l 注意点 l 「アジャイルで進めるかウォーターフォールで進めるか」に議論の主 眼が行ってしまうことがありますが、これはあくまで手段の話です l 大切なのはあくまでも「どのように展開していくか」です 28 パターン 進め方 特徴 1 予めリリースのタイミングと各タイミングでリリースする機能を 決めておき、開発・リリースを進める ウォーター フォール的 2 初回リリース後はユーザーからのフィードバックに基づいて、随 時機能リリースを実施する アジャイル的
29. パターン1とパターン2の違い 当初から 開発を予定した 機能A~F 機能A 機能B 初回リリースに向けた開発 2回目リリースに向けた開発 機能C 機能D 3回目リリースに向けた開発 機能E ユーザーからの機能追加要望 機能G 機能H 機能I 機能J 機能F 機能A~Fの開発・リリース予定を予め決めておく 当初予定して いた機能の開 発・リリース 完了後、ユー ザーからの要 望対応を計画 #2 ユーザーからの追加要望を常にウォッチし、サイクルごとに開発機能の選択→開発→ リリースを繰り返す F G 機能A 機能B 初回リリースに向けた開発 #3 E I #4 C D #5 H J #6 まず初回リリースに向けた開発 計画を立てる 弊社アジャイル開発方法論より抜粋、一部改変 パターン1 パターン2 #7 #8 #9 #10 #11 … それぞれの開発サイクルはアジャ イルのプロセスに従って2~4週間 程度で回す 29
30. l 初回開発の要件定義時に予めリリースのタイミングと各タイミン グでリリースする機能を決めておき、開発・リリースを実施して いく進め方です l 1サイクルを半年〜1年程度で定義します パターン1の進め方 30 展開 サービススタート向けシステム開発 ステップ1 要件 定義 実装 テスト リリース 設計 ステップ2 (半年~1年) 実装 テスト リリース 設計 ステップ3 (半年~1年) 実装 テスト リリース 設計 サイクル2以降の開発要件・ リリース計画も決めておく 要件定義時に策定した 各サイクルの計画に従って 作業を進める
31. パターン1で気を付けたいこと l 初回リリース以降は不具合等の保守が開始され、保守と追加開発 が並行となります l サイクル1を担当したメンバーが、保守と追加開発サイクルを担 当するのが良くあるパターン l 余裕を持ったスケジュールをたてましょう 31 展開 サービススタート向けシステム開発 ステップ1 要件 定義 実装 テスト リリース 設計 ステップ2 (半年~1年) 実装 テスト リリース 設計 ステップ3 (半年~1年) 実装 テスト リリース 設計 保守
32. l 初回リリース以降は、各サイクルの冒頭で開発内容を定義し、開発・リ リースを実施していく進め方です l サイクル2以降はアジャイル的な進め方ですが、サイクル1はアジャイルで もウォーターフォールでもOKです l 1サイクルを2〜4週間程度で定義します パターン2の進め方 32 サイクル2(2~4週間) 開発 機能 選択 実装 テスト リリース 設計 サイクル3(2~4週間) 開発 機能 選択 実装 テスト リリース 設計 展開 サービススタート向けシステム開発 サイクル1 要件 定義 実装 テスト リリース 設計 サイクル1の開発要件・ リリース計画のみ決める 各サイクルの開始時に、そのサイクルで開発する機能やリリーススケジュール を決める この際、ユーザーからどのようなフィードバックが来ているかも考慮に入れる
33. パターン2で気をつけたいこと l サイクルの始まりでフィードバックの最新状況を確認し、優先度 をしっかり検討して必要なものから着手するようにしましょう l アジャイルチームで対応していくため、アジャイルな進め方をす るためのスキルセット・マインドセットがチームメンバーに必要 です l サイクルの期間が短くなるため、CI/CDを導入し、DevOpsを実現し ましょう 33
34. キーワード解説：DevOps l アジャイル開発の普及によって短期間でのリリースが増え、従来 は分離されていた開発と運用の境界が曖昧になってきたため、開 発と運用をうまく連携するための手法が考え出されています l DevOps（デブオプス）とは、その手法の総称で、開 発 (Development) と運用 (Operations) を組み合わせた言葉です 34 Kharnagy - 投稿者自身による著作物, CC 表示-継承 4.0, https://commons.wikimedia.org/w/index.php?curid=51215412による
35. キーワード解説：CI/CD(Continuous Integration/Continuous Delivery) l テスト、パッケージ化、デプロイ、リリースを自動で行う仕組み l DevOpsを実現する技術的手段 35 弊社ナレッジコラム「デザインシンキング・アジャイル開発・DevOpsを学ぶ」より抜粋 https://ncdc.co.jp/columns/6354/ 手動 自動
36. l 事業モデルから適切なパターンを選択し、そのパターンを遂行で きる体制を構築しましょう(パートナーの選定含む) パターン 進め方 特徴 メリット デメリット 1 予めリリースの タイミングと各 タイミングでリ リースする機能 を決めておき、 開発・リリース を進める ウォー ター フォール 的 • スコープ・スケ ジュールをコント ロールしやすい • リリース頻度が下が りがち • 最新のフィードバッ クを取り込むのが難 しくなる • 保守との兼ね合いを 考慮する必要がある 2 初回リリース後 はユーザーから のフィードバッ クに基づいて、 随時機能リリー スを実施する アジャイ ル的 • 高頻度でリリースで きる • ユーザーからの フィードバックをタ イムリーに取り込め る • 組織として「アジャ イルを採用する！」 という覚悟・舵取り がないと効果が出づ らい 展開パターンのまとめ 36
37. [参考]開発成果物の評価 l 開発成果物とは l プログラム・開発環境・各種ドキュメント l パターン1の場合 l きれいなアーキテクチャ・設計・コードになっているか l 専門家・システム部門にレビューを依頼しましょう l パターン2の場合 l 成果物評価は、本来は実施しない l アジャイルプロセスによって産み出された価値を評価しましょう l いずれにせよ、DXの文脈ではドキュメントに対する評価に偏重し ないように気をつけましょう 37
38. 本日のまとめ
39. 本日のまとめ l プロジェクトとしての最終ゴールを定義しましょう l 各フェーズで目指すべきゴールを、フェーズ開始時点でなるべく具体化して おきましょう l 企画は実現可能かつ具体的なレベルまで練れたか？ l PoCの目的は定まっているか？ l 方針に合った展開プランを策定できているか？ l これらを、社内はもちろん、パートナーとなるベンダーとも共有しましょう l ベンダーは「打てば響く」 l 具体的なインプットが与えられれば、その分明確な回答を得ることができます l 間違っても、「お任せします」を丸投げしないように l 今日の内容はプロジェクトの進め方の話がメインで、ITの専門家しか分から ないような話ではありません l もちろん、分からないところは情報部門やベンダーといった専門家に質問しましょ う 39
40. NCDCの実績紹介
41. NCDCのサービス領域 l サービス企画からUX/UIデザイン、システム開発まで対応しており、下記 の各フェーズを通した一元的な支援が可能です。 l 次ページ以降、事例をいくつかご紹介します 41 展開フェーズ PoCフェーズ アイデア創出フェーズ 事業性 評価 ビジネス モデル 評価 アイデア 創出 PoC 販売戦略・運用方法検討 展開 サービススタート 向けシステム開発 タ ス ク 具 体 的 に や る べ き こ と • アイデア創出 • ビジネスフレームワーク を活用した分析 • 市場動向・他社動向・自 社の特徴、世の中のトレ ンド・技術的トレンドの 把握 • 事業計画立案 • 社内ステークホルダ説得 • UXデザイン • PoC検証計画策定 • PoC予算化 • システム開発 • 販売戦略からの具体的な販路開拓 • 業務運用・システム運用計画 • ステークホルダの巻き込み • 事業計画・予算承認・社内説得 • 撤退方針策定 • 体制作り システム開発を行う部分 PoC 計画 PoC用 システム開発
42. 事例｜リモート菜園アプリ開発 42 Client｜メーカー（食品） Keyword｜サービス企画 , UX/UIデザイン,アプリ開発 スマート農業の新規事業企画 とプロトタイプ開発。 お客さまの課題 | 遠隔地にある菜園の現地視察に 要する移動コストの抑制やCOVID-19の流⾏によ る地域間移動の制約に対処するため、リモートで 菜園の状況をチェックできるシステムを検討して いた。 ソリューション | 当初検討されていた事業者がリ モートで菜園をチェックする仕組みだけでなく、 ⼀般消費者がモバイルアプリを通じたリモート栽 培で⾃分好みの野菜を育てられるサービスを企画 しNCDCから提案。リモート菜園アプリによる新 たなビジネスの⽴ち上げを⽀援。 NCDCの役割 | サービス企画から、UX/UIデザイ ン、プロトタイプの実装に⾄るまで、アプリ開発 に必要な機能をワンストップで提供。現地菜園へ のネットワークカメラの導⼊もNCDCが⽀援。
43. 事例｜IoTアプリを用いた電力取引サービスPoCの支援 43 Client｜商社 Keyword｜ UX/UI , IoT , AppPot EVを⽤いた電⼒取引を ポイント化するアプリを開発。 お客さまの課題 | 電気⾃動⾞（EV）の充放電活動 に対してポイントを付与する仕組みを構築し、電 ⼒供給・受給の新たなあり⽅、電⼒事業の今後の 展望、⽅向性を模索したい。 ソリューション | コンビニエンスストアやスー パーに設置された専⽤の充放電スポットと連携し、 電⼒供給の（EVからの放電の）時間・回数に応じ てポイントを付与するモバイルアプリを開発。充 放電スポットを設置した店舗の営業上のメリット を検証するために、同アプリでEVユーザーの購買 データも記録し、多⾯的にPoCを⽀援。 NCDCの役割 | 各協⼒会社と連携し、充放電機か らIoTでデータを受け取ってポイント付与を⾏うモ バイルアプリの開発を設計から担当。UX/UIデザ イン、開発、現地テスト、App Storeへの公開、リ リース後の改善までを⼀貫してサポート。
44. 事例｜IoTを活用したサービス開発 44 Client｜金融・リース Keyword｜新規サービス開発 , PoC , IoT IoTを活⽤した 設備稼動可視化サービスの開発。 お客さまの課題 | モノをたくさん保有している リース会社にとってIoTは⼤きなテーマ。デジタル イノベーションによる新規事業の開発が今後必要 となるため、その推進役となるパートナーを求め ていた。 ソリューション | 年間契約でリースされるが、稼 働率が低い時期もあるフォークリフトを、稼働状 況に応じてお客さま同⼠でシェアリングできる仕 組みを開発。（ジャイロセンサー＋Bluetooth＋ SIMで稼働状況をリアルタイムでクラウドに記 録） NCDCの役割 | ワークショップ形式でお客さまと ⼀緒にペルソナづくりやカスタマージャーニー マップの設計などに取り組み、ビジネスモデルの 検討から実施。その後もPoC、プロトタイピング （UIの設計）まで、プロジェクト全体を担当。