Non-IT人材でもわかる！DX時代の開発プロセス講座

近年、ビジネスとITの密接な連携が求められるようになっています。
特にDXの文脈においては、 Non-IT人材がアジャイル開発やUXデザインなどの概念を取り入れつつ、システムの企画・開発に関わる機会が増えているようです。

その一方で、開発の進め方（いわゆる開発プロセス）への理解が不足しているために、イメージしていた通りのシステムができない、計画通りの期間・コストに収まらない、トラブル対応ばかりに終始してDXの実現が困難になってしまうといった問題が起こりがちです。

DXを実現させるためにも、Non-IT人材もシステム開発の基本的なプロセスやさまざまな手法を理解し、開発計画や見積の妥当性について検討できるようになることが有効ではないでしょうか。

このセミナーでは、Non-ITの方々を対象に、開発プロセスの基本的な考え方から、DXプロジェクトでよく登場するアジャイル開発やUXデザイン、PoCなどに取り組む際のポイントや注意点をわかりやすく解説します。

Transcript

1. Non-IT人材でもわかる！ DX時代の開発プロセス講座 2022年10月20日 NCDC株式会社
2. プレゼンター紹介 2 代表取締役/ビジネスアーキテクト 早津 俊秀 和歌山大学経済学部 非常勤講師 元グロービス経営大学院 客員准教授 日本電信電話にてエンジニア、新規ビジネスプロ デュースを経験後、HP，BEA、オラクル等の外資系IT 企業にてITコンサルタント、製薬ベンチャーでのIT部 門を統括。ベンチャー支援等の後 NCDCを創業。 ◉執筆 SOA サービス指向アーキテクチャ（翔泳社） ビジネスはSOAで変革する（IDGジャパン） スマートデバイス×業務システム導入ガイド（秀和システム）
3. 私たちにできること① l デジタルビジネスに必要な要素にフォーカスし、⼀元的に提供しています。 l スモールスタートでの検証から、本開発・継続的な改善までサポートします。 3 ワークショップを中⼼とし た合理的なプロセスで、ビ ジネスモデルの検討からUX デザインまで、迅速に⾏い ます。 関係者が多数いる場合の組 織横断、会社横断のファシ リテーションも得意です。 新規性の⾼いプロジェクト ではMVP（Minimum Viable Product）を⽤いた検証を⾏ うなど、⽬的に応じて段階 的な開発を企画します。 早い段階でモックやプロト タイプを⽤意してユーザの 評価を確認します。 ユーザとのタッチポイントとなる各種デバ イスのフロントエンドデザインから、クラ ウドサービスを駆使したバックエンドの開 発まで。多様なテクノロジーをインテグ レーションします。 l AI / IoT / AR l モバイル・ウェブ アプリ開発 l クラウドインテグレーション l システムアーキテクチャコンサルティング など ビジネスモデルのデザイン スモールスタート・PoC システム・インテグレーション ユーザ視点を⼤切にした 課題抽出・企画 モックやプロトタイプ の開発・検証 開発 継続的な改善
4. 私たちにできること② l 社内に最適な組織がない場合の組織づくりや⼈材育成から、⾼度な技術をもったエンジニ アによる技術移管まで、幅広くお客様をサポートします。 4 ビジネスモデルのデザイン スモールスタート・PoC システム・インテグレーション ユーザ視点を⼤切にした 課題抽出・企画 モックやプロトタイプ の開発・検証 開発 継続的な改善 企業のDXやデジタルビジネスの創出に必要なこうしたプロセスを多⾯的にサポート DX戦略⽴案 ⼈材育成 技術移管 リファレンス実装 DX組織構築⽀援 アジャイル導⼊⽀援 ⼿法や技術の選定 ブランディング
5. Design ユーザ視点での設計 Technology 技術による課題解決 Innovation • コンサルティング • 新規サービス企画 • PoC⽀援 • デザイン思考 • UX/UIデザイン • モバイル・Web先端技術 • IoT / AI / AR • クラウドインテグレーション 5 NCDCのサービス体系 Business 新規事業⽴ち上げからの伴⾛ 業務改⾰やIT改⾰の⽀援
6. DXプロジェクトの開発プロセス 基礎編 6
7. さてどうする？ 7 ITのバックグラウンドがないのに DX推進担当になってしまった！ 横文字ばっかりで会話に出てきて、 全くわからない！！
8. 何から勉強したらよいのか？ 8 プログラミング？
9. 何から勉強したらよいのか？ 9 開発プロセスを覚えましょう！ 作るモノの内容 を決める 設計する 作る テストする DXにおけるシステム開発の全体を掴む プログラミング ※ARCHIBLAST社Webサイトから掲載
10. 最も基本的な開発プロセス l 下記のような工程によって開発プロセスが進む。工程の名称は企業によって異なる場合が あるが実施内容は変わらない。 l プロジェクトの内容によって省略されたり、別工程内に包含されるものがある。 10 要求定義 要件定義 基本設計 詳細設計 開発 単体テスト 結合テスト 総合テスト 工程 概要 主な活動 主な成果物 要求定義 システムに対する要望事項を定義する。ここで定義された ものはあくまで要求であり、システム化の範囲に含まれな いものもある システムのオーナーや使用者から要望を幅広くヒアリング して要求事項としてまとめる 要求事項一覧 要件定義 システム化の対象となる要件を定義する。ここで定義され たものが最終的なシステムの成果物となる システムのオーナーや使用者からヒアリングしたり、業務 フローを分析したりして、要件をまとめ、機能一覧を作る ことが一般的 機能一覧 画面モック 等 基本設計 システム設計の中で、システムオーナーが理解できる内容 を基本設計として作成する 設計書をオーナーに確認する。設計時にでてくる不明点も 解決しておく 画面設計書 ER図 API仕様書 等 詳細設計 開発者のための設計書を作成する 各種詳細設計書を作成して、開発者に渡す クラス図 シーケンス図 データ定義書 等 開発 プログラムを作成してアプリケーションを開発する 開発者が詳細設計書に則ってプログラミングする プログラムファイル 単体テスト 開発者が作成したプログラムをテストできる最小単位の状 態でテストする 開発者がプログラムを作成後、詳細設計書の一機能の単位 で正常に動くかテストする 単体テスト結果一覧 結合テスト 実現機能が一通りできた時点で、他システムとの接続など、 他の要素と接続してテストする 外部のシステムなど接続して、実際にプログラムを動かし てテストする 結合テスト結果一覧 総合テスト システムが完成した段階で、使用シナリオやエラーが発生 するシナリオ等を作成し、最終的なテストをおこなう 総合テストのシナリオとテストデータを作成し、シナリオ に則ってテストする 総合テストシナリオ 総合テスト結果一覧 保守運用 企画構想
11. しかし、、、基本だけでは通用しなくなってきた！ 11 要求定義 要件定義 基本設計 詳細設計 開発 単体テスト 結合テスト 総合テスト 基本的な開発プロセス＝ウォーターフォール型 • 要件を決めて、決めたもの を作る • 出来上がったものを確認で きるのは開発プロセスの最 後になる 上記開発プロセスの前提 • DXで期待される新規サービ スは要件が決めきれない。 やってみないとわからない • DXで期待されるAI関連サー ビスなどは実現性や精度が わからないので要件と言わ れても決められない DXプロジェクトの特徴 • スマートデバイスの圧倒的 な普及によって求められる サービスが多岐にわたる • 4G、5G、Wi-Fiの圧倒的な普 及によっていつでもどこで もインターネットに繋がる ことが求められる 外部環境の変化 要件を決めきれない中でスタートして、出来上がったものを確認し、使ってもらおうとしても ニーズに合っていないものができあがってしまう。 しかし、その時点では開発プロジェクトも終了し、多額のコストも発生してしまっている。 つまり、DXに関するプロジェクトでは一般的な開発プロセスではうまく行かない場合が多い 開 発 プ ロ セ ス の 特 徴 と 環 境 の 変 化 そのままではDXの特徴や環境変化についていけない
12. ウォーターフォール開発とアジャイル開発 要求定義 要件定義 基本設計 詳細設計 開発 単体テスト 結合テスト 総合テスト 要求定義 設計・ 実装・テスト 設計・ 実装・テスト 設計・ 実装・テスト 設計・ 実装・テスト 一年以上かかる場合が多い 一つのスプリントは2～4週間 開発プロセス ウォーターフォール アジャイル 基本思想 • 正確であることが前提。前工程は正確なので、それを受 けて文章で次の工程に進む • 正確に要件を定義できないことが前提 定義しても変わるのが前提なので文章は最低限 メリット • 要件が定義でき、常に変化するような環境ではないシス テムの開発には最もコストが低く、品質が高くできる可 能性がある • 要望事項をすぐに実現し、リリースすることができる 継続的に機能追加を行い、システムを拡張・成長させる ことができる • すぐに見て触って確認できるため、リスクを直ぐに発 見・対応できる デメリット • 開発期間中の変更は大きな手戻りが発生する • 最後のフェーズにならないと実際のシステムを見ること ができないため、リスクが最後まで見えにくい • ハイスキルなメンバー構成でないと実現が難しい 終わりが見えないため、結果としてコストが大きくかか る場合がある DX観点での向い ているシステム • 頻繁にリリースが必要なく、ある程度作りたいものが 明確である場合には向いている 例：業務向けのDX新規サービスなど • 2週間や1ヶ月で新機能を常にリリースしていくようなシ ステムには向いている 例：コンシューマ向けのDX新規サービスなど ウォーターフォール型 アジャイル型 12 公開 公開 公開 公開 公開
13. DXプロジェクトはアジャイル型の方が向いている l しかし、メリットと同じくらいデメリットも大きい l ほとんどの場合、期間とコストはウォーターフォールよりかかる l 終わりのない旅が良い場合と悪い場合がある l ハイパフォーマンスな人材を維持することが難しい 13 要求定義 設計・ 実装・テスト 設計・ 実装・テスト 設計・ 実装・テスト 設計・ 実装・テスト 一つのスプリントは2～4週間 アジャイル型 公開 公開 公開 公開 アプリ事業者やSaaS事業者にとってはフィットするが・・
14. 多くの企業がDXに取り組む場合の前提条件は？ l 新しい事業の一部としてDXに取り組もうとしている l ハイパフォーマーのエンジニアが社内やプロジェクト内に十分 いるわけではなく、外部委託が主になる l 予算や期間の計画がある取り組みである l 要件は明確ではなく、柔軟に変わっていく必要がある 14 ウォーターフォールでもアジャイルでも難しい！！
15. NCDCがDXプロジェクトに多く採用している開発プロセス l 要件を2つの大きく分ける 15 基礎部分 （絶対に必要な要件） 応用部分 （必要になると思うが、 詳細要件までは詰められない） ウォーターフォールを採用 アジャイルを採用
16. DXでよく使われるハイブリッドなプロセス 16 基礎部分のプロジェクト 応用部分のプロジェクト 要件定義 設計 開発 テスト 要求定義 Sprint1 Sprint2 Sprint3 Sprint4 第一ステップリリース後は、アジャイル開発を採用し、 継続的に迅速に追加機能をリリース 最初にリリースする要件を定義し、 そのリリースまではウォーターフォール型で開発 公開 公開 公開
17. DXでよく使われるハイブリッドなプロセス l ウォーターフォールの欠点である「最後にならないとアプリケーションを見て確 認できない」を解消。 l 従来の運用フェーズと応用部分の開発を同じメンバーで行い品質を高める。 17 Sprint1 基礎部分のプロジェクト 応用部分のプロジェクト 要件定義 設計 開発 Sprint2 Sprint3 Sprint4 テスト 要求定義 Sprint1 Sprint2 Sprint3 Sprint4 継続的に機能追加してサービス運用 第一ステップリリース後は、アジャイル開発を採用し、 継続的に迅速に追加機能をリリース 開発フェーズのみアジャイルな進め方を採用し、 スプリント単位で開発成果物を確認 最初にリリースする要件を定義し、 そのリリースまではウォーターフォール型で開発 公開 公開 公開
18. DXプロジェクトの開発プロセス 基礎編のまとめ l ウォーターフォール、アジャイル、それぞれの開発プロセスの特徴を押 さえる。 l 開発プロセスは手段でしかないので、対象プロジェクトの性質から考え て、最適な開発プロセスを組み合わせ、自ら作るつもりで進める。 18
19. DXプロジェクトの開発プロセス 中上級編 （MVP、PoC、UXデザイン） 19
20. DXプロジェクトとMVP 20
21. MVPとは？ l MVP（Minimum Viable Product） l 2011年 エリック・リースがトヨタ生産方式などを研究してサービス の新規立ち上げのフレームワークとしてリーンスタートアップを発表 した。 l リーンスタートアップの中で、実行可能な最低限の機能を持ったプロ ダクト（MVP）を作って、ユーザーの反応を計測して、改善案を考え ることが提唱された。 21 早く・短期間で！
22. MVPの変化 l MVPとはいえ、ある程度の品質が求められる傾向に。 22 機能 品 質 MVP MVP 2011年頃のグローバルなMVP 最近の日本のMVP • セキュリティ • イレギュラー処理の不具合 • 複数端末対応 等
23. 基礎部分をMVPと考える l 「実行可能な最低限の機能」のハードルが2011年と比較して、 明らかに高くなっていることに注意。 l 品質含めた顧客の要求レベルは高くなってきている。 23
24. DXプロジェクトとPoC 24
25. PoCとは？ l 本格的な開発プロセスに入る前に、検証が必要と思われる内容について のみ、検証のためのプログラムなどを作成して、被験者に使用してもら い、フィードバックを得る。概念実証。 25
26. DXプロジェクトとPoC l 何をどのように検証する必要があるかを定義して、PoCを行う。 l つまり「PoCで何を作るか、作る必要がないのか」も含め計画が大切。 26 PoC
27. 開発しないでもできるパターンも多くある l できるだけ工数が少なく検証できる部分から進めるのがコツ。 l 開発（プログラミング）するのは最終手段くらいのつもりで計画する。 27 実現方法 工数感 検証例 画面モックのみ（開発が不要） 小 • 画面モックを触ってもらった後にアンケートやインタ ビューを行ってユーザーニーズを検証する • システムの画面遷移などの使用性を検証する 商用のSaaS利用（開発が不要） 小 • SaaSでも検証ができるような場合、アンケートやインタ ビューを行ってユーザーニーズを検証する ノーコード・ローコードツール （多少の開発が必要） 中 • 使用してもらった後アンケートやインタビューを行って ユーザーニーズを検証する システムに組み込まれていないAI モデル 中 • AIの精度の検証を行う Raspberry Piなどの小型コンピュ ターを使ったアプリケーション 中 • 技術的な実現可能性の検証を行う 検証のために必要な部分をPaaS等 を活用して開発する 中 • 技術的な実現可能性の検証を行う • 短期間使用してしてもらい、その後アンケートやインタ ビューを行ってユーザーニーズを検証する
28. DXプロジェクトとUXデザイン 28
29. いまUXが求められている！ 29 基本機能の 充実 大きさ、軽さ、処理スピード等性能の進化 拡張機能の進化 価格の競争 気配り、心配り の競争 User Experience 機能・性能・価格である程度 のユーザーニーズを満たした ユーザーはUXを求める （心地よい体験、満足感） 機能・性能・ 価格競争で差異が出せない https://www.itmedia.co.jp/news/articles/1910/29/news060.html https://www.powerwatch.jp/2020/04/27 https://diamond.jp/articles/-/180183?page=8 https://wired.jp/2019/09/08/wired-guide-to-the-iphone/ 参照） DXの時代
30. UXデザインとは？ 30 ユーザーエクスペリエンス(User experience)デザインの略称で、 ユーザー（顧客）体験を設計することであり、DXの文脈でも関連して語られる。 UXデザインとは 企画・設計 ユーザーの体験 UX デザイン +
31. MVPやアジャイルでの課題 l 実行可能な最低限の機能（MVP）がUXの注目によって、レベルアップ されている。 31 https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp MVP？ 運転していて楽しい車を開発したい！
32. DXプロジェクトとUXデザイン l ユーザーニーズをある程度予測して、UXデザインが必要であれば、 基礎部分のプロジェクトの最初のフェーズに入れる必要がある。 l 応用部分でも必要に応じて最初に組み込む。 32 UXD UXD
33. DXプロジェクトの開発プロセス 中上級編のまとめ l DX時代になり、UXの浸透など、ユーザーニーズが高くなってきて いる傾向が顕著。MVPやPoCを考える時に注意が必要。 l 一方でツールの発展により、開発を伴わなくてもPoCができる場合 が多くなってきた。何を検証するために何でできるのか計画する ことが大切。 33
34. 本セッションのまとめ l 開発プロセスは難しいものではない。その特徴（メリット、デメリッ ト）と自分たちで作る予定のモノの特徴を考えて、最適な進め方を考え ること。 l DX関連のビジネスは進み方が速いので、既存の考えやフレームワークに 囚われすぎず、柔軟に考える。 l 「DXだからアジャイル」、「DXだからMVP」みたいな短絡的な考え方はNG。 34
35. 事例紹介とDX人材育成支援の紹介 35
36. 事例｜「未来の暮らし」を見据えたPoCの実施 36 Client｜製造業（自動車） Keyword｜ サービスデザイン , PoC , アジャイル スマートシティの実現に備えた サービス企画と技術検証。 お客さまの課題 | 数年後のスマートシティ実現に 向けて、そこに住む⼈々の暮らしを豊かにする サービスアイデアの創出から、実現のためのテク ノロジーの検証まで、ともに⾏うパートナーを求 めていた。 ソリューション | UXデザインの⼿法を⽤いた（⽣ 活者の体験を起点とした）サービス検討と、その 実現可能性を検証するためのPoC企画・システム 開発をAgileで⾏う。そして短期間で検証とフィー ドバックを繰り返す 。 NCDCの役割 | お客さまとの定例会にNCDCのビ ジネスコンサルタント、UX/UIデザイナー、エン ジニアが参加。プロジェクトの段階に応じてサー ビス企画から、設計やシステム開発まで担いPoC の⼀元的な⽀援を⾏いました。また、関係者向け にサービスコンセプトを紹介する動画も作成。
37. 事例｜UXデザイン＋アジャイルによる社内ツール作成 37 Client｜製造業（自動車） Keyword｜ アジャイル , 技術支援 , UX/UIデザイン UXを重視した社内ツール開発の 内製化・⾼速化⽀援。 お客さまの課題 | 製造部⾨専属のITチームを⽴ち 上げ、製造現場のスタッフにとって本当に使える サービスを、内製で、⾼速に作っていくアジャイ ル開発体制を構築したい。そのための技術⽀援も できるパートナーを求めていた。 ソリューション | UX/UIデザインや開発を内製化 するための技術⽀援を通じて、お客さまのITチー ムを継続的に⽀援。製造ラインの業務進捗情報を 集約して表⽰するダッシュボードや、製造⼯程で のトラブル情報管理ツールなどの開発にともに取 り組んだ。 NCDCの役割 | コンサルタント、デザイナー、エ ンジニアを派遣し、UX/UIデザインからフロント エンド、バックエンドの実装まで、幅広いコンサ ルティングを実施。技術移管も並⾏し、アジャイ ル開発の体制構築を多⽅⾯から⽀援しました。
38. DX人材育成支援 38 グループワークの様子 デジタルビジネスの知識やスキルを磨き、社員のDX能力を底上げする l 豊富なDX支援の経験を活かして、DX人材育成を支援しています l 豊富なDX支援の経験を活かし、DX人材育成を支援しています l 注目を集める「リスキリング」 l 社内向けの研修など、多数の企画実績があります l UXデザインによるサービス設計 l DX推進に必要なシステム開発 l AIやIoT、クラウドの基礎知識 l 新規サービスの立案や実現の手法 l テーマの検討から時間や参加人数まで、オーダーメイドで設計