企画立案からシステム開発まで 本当に使えるDXプロジェクトの教科書

著者 : 下田幸祐 飯田哲也

• 日経BP (2020年3月26日発売)

作品紹介・あらすじ

DXプロジェクトを成功に導く羅針盤！

　自社ビジネスの変革を目指して多くの企業が取り組むDX（デジタルトランスフォーメーション）。プロジェクトを成功させて成果を上げる企業が現れている一方で、苦戦している企業も少なくありません。「PoC（概念実証）ばかりで具体的な成果が出ない」「手掛けているのは一部の部門だけで、全社的な取り組みにつながらない」という声も多く聞かれます。

　AI（人工知能）やIoT（インターネット・オブ・シングズ）といったデジタル技術を用いて新たなサービスを生み出したり、既存事業の収益構造を変革したりするには、従来の業務システム開発とは異なるノウハウが必要です。

　本書は、複数企業のDXプロジェクトの運営を手掛けてきた筆者が、DXプロジェクトをうまく進めるためのノウハウを豊富な経験を基に解説します。DXプロジェクトは従来型の基幹系システムの開発とどう違うのか、DXプロジェクトではどんなプロセスが必要になるのかなどを体系立てて解説。何をつくるのかを決める構想フェーズや実現性検証のためのPoC、要件定義、設計など、DXプロジェクトを実践するときのプロセスを分かりやすく解説します。

　サービスを開発、活用するユーザー企業側の方、ユーザー企業と共にシステム開発などを請け負うSI企業やシステム開発会社の方、両方の立場の方に役立つようにまとめています。企画担当者やプロジェクトマネジャー、エンジニアなどDXプロジェクトに取り組むすべての人に必携の一冊です。

　イメージがわきやすいよう、具体的な例を挙げて解説しているので、実際にDXプロジェクトを進める上で役立つノウハウが満載です。ぜひご活用ください。

感想・レビュー・書評

[けべんさんの感想 · 2023年11月7日]

やってみないとわからないものの、実態の流れに沿った形で、想像できるレベルの仔細さが良かった．

実例を用いたケースで照会していくのは良いが、オンライン(EC)のパン屋(toC)というのがピンとこなかった．大きな企業で扱うtoBケースが例となっていればよかった．

読者の前提としては、DXプロジェクトの対比として出される基幹系(情報系)システム開発プロジェクトの一連を経験してないと想像できないかもしれない．また、DXの２種：新商品・サービス系DXと事務系DXのうち、前者が対象となっている．

[ととせひさんの感想 · 2023年5月14日]

●一分野マスター読書「DX」19冊目。DXを始める際のシステム開発の段取りについて解説した本。要件定義などの話が小難しく感じてしまう。

[SESGAKさんの感想 · 2021年1月31日]

積読になっていたけど今更ながらに読んだら、2020年に業務で悩んだことと繋がって納得する部分が多くあったので、良書だったんだなぁと今更ながらに思ったりした。

[a0019447さんの感想 · 2020年12月3日]

各種dxプロジェクトにおける大事な考え方を整理してくれている良著。


メモ
・pmに求められる3つの行動
aiなど最新技術の使い方を理解する
競合類似事例を常に把握しておく
要求課題を積極的に整理提案する

・サービスの企画とは以下の3つを明確化すること
　顧客は誰か、どんな課題を解決するか、何を使って解決するか

・アジャイル開発を成功させる条件
　システム開発規模が大きくない
　高品質が求められるシステムでない
　プロダクトオーナーがいて意思決定できる
　スキルの高いエンジニアが確保されている

・部分的なアジャイル
　　企画から要件定義、設計から実装は導入可能な部分。

・タスクフォースを組織し、縄張り争いやお見合いを防ぐということ
プロダクトオーナーを置くことにより素早い意思決定と製品サービスの整合性確保を行う。

・構想フェーズで決めること
　サービス企画
　サービス要求定義
　事業戦略・計画
　次フェーズ計画

・サービス企画プロセス
　何をするかから定義。保有技術があればそれによって解決しうる顧客や課題を定義。
　仮説は質的量的に評価する。
利用者規模推定。インタビューや生の声から質的にも仮説を具体化。
サービス案絞り込みの評価基準例
　想定効果＝課題解決度合い
　コスト、実現難易度

・サービス要求定義プロセス
　アイデアを具体化。どのような機能をつけるか、業務は何が必要になってくるのか
　ユースケークの整理。どんな人のどんなユースケースが想定されるのか。対象者はいつ何をするのか。利用シーンを具体化する。フロー図を作成してみる。そこからサービスの要求項目が決まってくる。さらにはシステム機能やデータ一覧を作成。その後の事業計画策定時の定量化にもつながる部分。
システム構成図を作成し、俯瞰的にみられるようにしておく。

・事業計画、戦略策定プロセス
　3c4pなども活用し、収益性や優位性構築していくための計画をたてる。
　システム構成図や機能一覧から開発コストを洗い出し、見積を行う。
さらに、初期費用回収時期、顧客獲得数などマイルストーンや目標をたてつつ、収支計画をたてていく。

・フェーズ計画作成。プロジェクト計画書の作成
　サービス企画、スコープ、開発フェーズ、スケジュールをおりこむ。
　要件定義。作業、役割分担、体制、リスクと対応方針、マイルストーン、管理計画

・pocについて
　規模が大きい場合はpocを行ってから要件定義を行う。要件定義が無駄にならないようにするため。

・poc計画書に記載すべき内容
　目的、目標
　スコープ
　実施内容
　システム・環境
　準備実施作業
　体制役割
　スケジュール
　管理運営方法

・スコープはサービス全体のどの部分をpoc検証するかを示すもの。図示がおすすめ。
・実施内容はどんな検証を行うかをまとめるもの。
・準備実施作業は関係者のタスク。データの抽出条件、データ依頼、連携環境構築、モデル構築など。　

・ですとマーケティングはpocよりも先に行う。仮説やサービス案が変わったら利用する技術も変わりうるため。

・新サービス開発の要件定義で必要な作業
　フロントエンド機能要件定義　
　業務要件展示も管理機能要件定義
　ai機能要件定義
　バックエンド機能要件定義
　非機能要件定義

・構想フェーズで広げた風呂敷を、要件定義では一定度とじていく。具体化とともに。

・非機能要件定義
　可用性要件　継続稼働をどこまで担保するか、冗長性含む。
　性能拡張性要件　アクセスユーザー数、レスポンス要件。サーバーダウンしないよう。
　セキュリティ要件　なりすまし、認証機能など

・デザインは即断体制をつくる。改善点一覧でリリース判定。
　デザイン確定に向けた現場責任者を明確にし権限委譲する
　トンマナを現場責任者とデザイナーの間で合意する
　全てのデザインを現場責任者が確認し、デザイナーとの間で合意する。

・