前回、DXプロジェクトの具体的な進め方「構想」「PoC・テストフェーズ」についてお話しました。今回はその後のフェーズ「要件定義」以降についてポイントをお話していきます。
(前回記事「DXの上流は「要件定義」ではありません。」)
参考文献はこちら
企画立案からシステム開発まで 本当に使えるDXプロジェクトの教科書 著者：下田 幸祐、飯田 哲也 出版：日経BP
詳細は本書をご覧ください。本記事では、全体像をわかりやすく整理しています。
従来のシステム開発にはなかった工程
従来のシステム開発では「要件定義」が最上流でした。
DXプロジェクトでは要件定義は中流以降。「構想」「テストマーケティング」「PoC」の次に来るフェーズになります。
要件定義とは「構想」をより具体的・詳細に落とし込んでいくこと。
・システム画面・機能
・付随する業務内容
・管理画面の機能
・上記を支えるバックエンドの機能
・上記以外の機能
システム化にあたって必要なことを細かく決めていくことです。
システム画面を作ってから、業務を確定させる
従来のシステム開発における「要件定義」と違うのは、「業務がない」ところからスタートすることです。
従来のシステム開発である基幹系プロジェクトの目的は、既存業務の整理・効率化です。つまり「業務がある」ところからスタートします。
また、RPAやAIを使い業務を効率化させるシステム開発はDXプロジェクトですが、この場合も改善対象となる「業務がある」ところからスタートします。
「業務がある」ところからスタートするシステム開発は「既存業務のどこをどう変えるのか」の整理・業務要件定義から入り、「どこまでをシステム化するか」の整理・システム要件定義という順番で進めます。
ですが、新しいサービスを作るDXプロジェクトの場合「業務がない」ところからスタートします。たとえばアプリを作れば、そのアプリを活用した社内業務があたらしく発生します。
「業務がない」ので整理する業務がありません。そのためシステム要件定義を先に行い、付随する業務はなにがあるのかを整理していくという順番になります。
具体的に、前回に引き続き架空の企業「JQベーカーリー」を例にお話していきます。
■フロントエンド機能要件定義
「ユーザーが見ている画面にキャンペーン表示が出来て、応募できる仕組みを作りたい」という案が出た
■業務要件定義
その案を実現させるためには「応募者を確認する業務」「抽選する作業」が必要
■管理画面機能定義
「応募者を確認したり、当選者をチェックしてメールなど連絡を飛ばす管理画面」が必要
という感じでフロントエンド機能から始まり、さまざまなことが決まってきます。
■バックエンド要件定義
フロントエンドで「口座振替支払いもできるようにしたい」という案があれば、口座振替を代行する業者との連携が必要になります。業者に請求データを送るためにバックエンド機能として口座振替請求データを作成したり、請求結果を取り込む機能を用意する必要が出てきます。
■AI要件定義
フロントエンドでレコメンド表示するパンを3つにするのか、5つにするのかで、AIに取り込むデータ量や難易度が変わり、コストも変わってきます。
すべて、フロントエンドで変わってきます。そのため、新しいサービスを開発するDXプロジェクトでは書面だけでなく、リアルな画面を作ってそれを見せあいながら考えていくのが有効なようです。
非機能要件定義も優先順位高く
非機能要件とは、見えないけど重要なシステム要件です。
・可用性要件
・性能・拡張要件
・セキュリティー要件
が影響の大きい非機能要件と言われています。
■可用性要件
システムをどのくらいの時間継続稼働させるか、を決めます。
たとえば、Webサービスであれば24時間365日稼働させるのが一般的。金融機関のサービスは深夜は稼働していなかったりします。
ネットバンキングなどは停止時間を０にすべく、1つのサーバーが停止してもほかのサーバーが動作できるような構成を採用したりします。その分、コストや作業が発生します。
サービスによって可用性は変わり、コスト・作業量も変わってくるため重要です。
■性能・拡張要件
どの程度のユーザーがアクセスする可能性があるか、どの程度の処理スピードを求めるか、を決めます。
キャンペーンなどで一時期的に大きくユーザー数が増える可能性なども含めて考え、サーバーの設定をどうするかなどを定義していきます。
■セキュリティー要件
確保するセキュリティーレベルを決めます。
個人情報を扱う場合、セキュリティーレベルは強固なモノにする必要があります。侵入検知や、二重認証の仕組みが必要になってくるなど定義していきます。
以上、要件定義フェーズの大まかな流れ・ポイントでした。要件定義フェーズは細かく、また「構想」で広げた風呂敷をたたむフェーズでもあります。詳細はぜひ、本書を読んでみてください。
設計・開発・テストフェーズはウォーターフォールで
DXと言えば「高速リリース・高速改善」。
特に今回の主題となっている「新サービス開発」は、ほかのシステム開発と比べ開発スピード優先です。
ですが、もちろんですが「品質を無視して良い」ということではありません。
そこで、設計以降のフェーズは「アジャイルではなくウォーターフォールをベース」にすることを推奨しています。
「DXはアジャイル開発がセット」という情報が多いため、意外に感じられた方は多いのではないでしょうか。
なぜウォーターフォールを推奨しているのか。アジャイル開発を成功させるためには満たすべき前提条件があるのですが、その条件を満たすことが困難な場合が多いからです。
■プロジェクト内容
①開発規模が大きくないこと
②ミッションクリティカルでないこと
■チーム体制
③プロダクトオーナーがいて意思決定ができること
④生産性が高いエンジニアが確保されていること
新サービス開発の場合、②③は満たしていることが多いです。
課題は①④にあります。
開発規模は、開発フェーズ以降大きくなります。その分多くのエンジニアが必要になるのですが、この時、生産性が高いエンジニアだけを集めることは非常に困難です。
また、規模がさほど大きくならなかったとしても、設計以降は丁寧に慎重に進めるウォーターフォールが適しています。新サービス開発の場合、社内の業務システムや社外のクレジットカード決済基盤などとの連携が発生し、ミスが許されない事象が増えるからです。
もちろん①～④の条件をすべて満たすのであれば、すべてアジャイル開発で対応できます。
また、設計書・ドキュメントは最低限にし、開発スピードを上げるなどの工夫はOKです。
構想・PoCまではアジャイル、それ以降は部分的にアジャイルを活用するというスタイルが適切であると本書では推奨しています。
以上、DXプロジェクトにおける要件定義以降のフェーズのポイントについてお話してきました。
まとめ「経営者理解が重要」
DXプロジェクトの「要件定義」以降のフェーズについてお話してきました。
●「要件定義」とは「構想」を具体的にシステム要件や業務要件に落とし込むこと。新しいサービス開発の場合、先にシステム画面を作り、付随する業務を整理していくことがポイント。
●「設計～テスト」はウォーターフォール・部分的にアジャイルで。アジャイルが成功する条件がすべて揃っていればアジャイルでも良いが、現実問題、なかなかむずかしい。「PoC」は、「構想」が実現可能か検証すること。特に、AIの検証がポイント。
DX推進の一番のネックはやはり経営者の理解。
DXプロジェクトが従来のシステム開発と異なることを知らなければ、引き続き付き合いのあるベンダーに丸投げしてしまうでしょう。
また、従来のシステム開発でもよく起きていた問題が、従来よりも難易度が高いDXプロジェクトにおいてはさらに起きやすくなります。
経営者・マネジメントサイドが中身の難易度を知らずして進捗だけを管理することで、メンバーはカンタンなタスクばかりこなしてしまい、難しい部分は後まわし。その影響で後半になり全体に関わる重大なミスに気づき、プロジェクトが頓挫してしまうという問題です。
この本は、DX推進担当だけでなく、経営者も一度精読すべき一冊です。
■参考：
企画立案からシステム開発まで 本当に使えるDXプロジェクトの教科書 著者：下田 幸祐、飯田 哲也 出版：日経BP
執筆者
リビルダーズ編集部
