【有識者コラム】DXプロジェクトにおける要件定義の落とし穴と、現場を動かす合意形成

DXプロジェクトのつまずきを振り返ってみると、根本の原因が要件定義にあることは少なくありません。開発が始まってから、業務部門から「こんなはずではなかった」という声が上がる。リリース直前になって、稼働後の運用を誰が担うのか決まっていないことに気づく。見積の前提が関係者の間で食い違っていて、追加費用の話がこじれる。いずれも、要件定義の工程は予定どおりに終わっていたにもかかわらず起きる問題です。

筆者はSIerの立場で、スマートフォンアプリやWebシステムの構想検討、提案、要件定義から開発・保守まで携わってきました。その経験から感じるのは、要件定義書が完成していることと、関係者の認識がそろっていることは別物ということです。

本記事では、要件定義が形骸化しやすい理由、業務部門・情報システム部門・ベンダーの三者で認識を合わせる方法、そして非機能・運用・移行まで含めて要件を整理する重要性について、実際のプロジェクトで経験してきたことを踏まえてお伝えします。

執筆者

要件定義が形骸化しやすい3つの理由

「やりたいこと」が固まる前に要件定義が始まる

従来型のシステム更改であれば、現行システムという手本があります。現行の機能を棚卸しし、変えるところと変えないところを決めていけば、要件の大枠は見えてきます。ところがDXプロジェクトで目指すのは、業務の置き換えではなく、業務やサービスのあり方そのものを変えることです。手本がないぶん、「何をしたいのか」が固まらないまま要件定義の工程に入ってしまうことがあります。

たとえば、新しいアプリを作ることは決まっているのに、業務部門から実現したいことがなかなか挙がってこない、ということがあります。この状態で要件定義を始めても、ベンダーがヒアリングの場を設け、業務部門がその場で思いつく範囲で答え、それを文書にまとめるだけになりかねません。できあがるのは、要件のかたちをした「思いつきの一覧」です。

このような場合は、要件定義の前に構想検討の工程を置くことを考えるべきです。構想検討の段階で、すべての機能を確定させる必要はありません。まず共有すべきなのは、誰のどの課題を解決し、何をもって成果とするかという判断の軸です。この軸があれば、具体的な機能は検討や検証を重ねながら詰めていけます。発注側としては、要件定義に入る前にこの軸が自組織のなかで言葉になっているかを、ベンダー任せにせず確かめておきたいところです。

要件定義書の完成が目的になる

要件定義の成果物は文書です。そのため、いつの間にか「要件定義書を期日までに仕上げること」が目的にすり替わりがちです。分量の多い要件定義書が完成し、関係者のレビューも形式上は済んでいる。それでも、実際には業務部門の担当者が内容を読み込めておらず、開発の後半になって認識の違いが表面化する、というのはよくある話です。

以前、ある案件で顧客から、要件定義書に承認欄を設けてほしいと求められたことがあります。ここで区別したいのは、契約上の業務の完了を確認することと、次の工程に進むために要件の内容に合意することです。要件定義で欠かせないのは後者であり、何を確認し、誰がどの範囲に合意したのかを明確にすることです。承認欄もその手段のひとつですが、印が並んでいるだけで関係者の認識がそろうわけではありません。合意の証跡は、「何が、いつ、誰の判断で、どういう理由で決まったか」を後から追えるかたちで残す必要があります。

関係者の「言葉」がずれたまま進む

DXプロジェクトには、少なくとも業務部門、情報システム部門、ベンダーの三者がかかわります。業務部門は業務の言葉で、情報システム部門は既存システムと運用の言葉で、ベンダーは機能と工数の言葉で話します。たとえば「顧客情報を連携する」という同じ一文でも、業務部門は画面に表示されれば十分と考え、情報システム部門は夜間バッチでの連携を想定し、ベンダーはリアルタイムのAPI連携で見積もっている、ということが起こり得ます。

また、既存サービスの認証基盤はA社、連携機能の改修はB社、ネットワークの通信許可は情報システム部門、というように担当が分かれる構成は、大きな組織のシステムでは珍しくありません。こうした構成では、担当範囲の境目にある要件が、誰にも拾われないまま抜け落ちやすくなります。各社が自分の範囲は正しく理解していても、システム同士をつないだときにどう動くかは誰も決めていない、ということになりかねないのです。

三者の認識を合わせるために

画面イメージを使って、要件を具体的にする

業務部門の担当者に要件定義書を隅々まで読み込んでもらうのは、正直なところ難しいものです。ところが画面を前にすると、話は一気に具体的になります。「この項目は入力しない」「この順番では使いにくい」といった意見が、画面を見ながらであれば自然に出てきます。

あるスマートフォンアプリの案件では、前フェーズの開発と並行して、アプリ保守の週次定例を行っていました。その定例の時間を使って次期開発の要件を検討し、デザインツールのFigmaで画面レイアウトを項目レベルまで具体化していきました。画面と機能一覧の対応が取れていると、業務部門は画面を、ベンダーは機能と工数を、それぞれ自分の言葉で確認しながら、同じものについて話すことができます。

ただし、画面だけで要件定義が終わるわけではありません。画面で得られた認識は業務フローや機能一覧に戻し、例外処理や権限、画面に現れない処理も併せて確認します。

機能の要否を「入れる・入れない」の二択で決めない

要件の議論が止まる典型的な場面は、ある機能を入れるかどうかで意見が分かれたときです。複数の組織や部門がかかわる場合は、なおさらです。それぞれの要望をすべて入れれば費用が膨らみ、どれかを外せば反発が起きます。

複数の組織が共同で利用するアプリの構想策定では、機能を次の3つに分けて整理しました。

• 標準として全組織に載せるもの
• 理由を明示して今回は実装しないもの
• 各組織の個別要件として別途見積にするもの

全員が納得するまでひとつの機能を議論し続けるのではなく、標準に載せない理由と、個別に対応する道を明示しておく。そうすることで、合意できる範囲から先に固めていけます。

決める人と、決めたことを明確にする

認識合わせの仕組みとして見落とされやすいのが、意思決定者の明確化です。業務の変更を判断するのは誰か、予算や範囲の変更を承認するのは誰か、画面の細部を決めてよいのは誰か。これがあいまいだと、打ち合わせのたびに結論が持ち越され、あとになって「聞いていない」の一言で覆ります。業務の変更や予算の判断は発注側のなかで下すものですから、判断する人を要件定義の開始前に自組織で決めておくことが重要です。

決めたことは、決定事項の一覧として残します。議事録のなかに埋もれさせず、決定の内容、日付、判断した人、理由を一か所で追えるようにしておくと、仕様変更の議論になったときに「なぜそう決めたのか」に立ち返れます。

未決事項には、判断する人、判断に必要な情報、決定の期限を付けます。決まっていないことよりも、誰がいつ決めるのか分からないまま後工程が進んでしまうことのほうが問題です。合意した内容を後から変える場合も、費用・納期・関連する要件への影響を確認したうえで、決定事項と関係する文書を更新します。

見積の前提条件を書き出し、システム連携の責任者を決める

見積や計画は、必ず何らかの前提のうえに成り立っています。その前提は「既存システムの改修は最小限」のような表現で済ませず、守られているかどうかを後から確かめられるかたちで書きます。たとえば、どのシステムを誰がどこまで改修するのか、連携仕様と試験環境をいつまでに誰が用意するのか、データの品質を何で確認するのか、といった書き方です。そうしておけば、前提が崩れたときに、それが範囲の変更なのか当初の想定の範囲内なのかを、感情的にならずに話し合えます。

複数の会社がかかわる場合は、つなぎ目の責任も最初に決めておきます。要件と連携仕様を誰が取りまとめるのか、システムをつないだ状態での全体試験を誰が統括するのか。この二つの役割を明確にし、それを踏まえて各社の分担を決めます。ここがあいまいなままだと、問題が起きたときに各社が自分の範囲の正しさを主張し合うだけになってしまいます。

非機能・運用・移行まで含めて整理する

機能の議論だけでは要件定義は終わらない

DXプロジェクトの要件定義では、どうしても目に見える機能や画面に議論が集中します。しかし、性能、可用性、セキュリティといった非機能要件、稼働後の運用、そして現行からの移行は、費用と構成を大きく左右します。これらを「後で詰めればよい」と先送りすると、設計や試験の段階になって構成の見直しや追加作業が発生し、見積の前提が崩れます。

非機能要件も、合意の仕方は機能と同じです。たとえば性能であれば、「快適に使えること」だけでは合意したことになりません。対象の操作、利用が集中する条件、許容する応答時間、試験での確認方法まで具体化し、業務部門・情報システム部門・ベンダーの三者で共有します。

運用・保守の体制は、稼働後の変化を見込んで決める

スマートフォンアプリでは、運用要件の重みが特に大きくなります。OSは毎年のようにアップデートされ、そのたびに動作確認や対応が必要です。筆者自身、iOSのアップデートに伴う動作確認を、関係する他社と調整しながら進めてきました。また、アプリが利用するAPIに既存の動作との互換性を損なう変更が入ると、アプリ側にも改修が必要になる場合があり、その改修はストアの審査を経て利用者に届きます。そのため、稼働後の変更の頻度、APIの互換性の保ち方、変更時の影響確認と調整の担当は、要件定義の段階で決めておきます。

公開後の改修に対応できる保守体制も、最初から要件として扱うべきです。誰が問い合わせを受け、誰が障害に対応し、改修の要望をどう受け付けて優先順位をつけるのか。運用の体制と手順は、開発の早い段階から用件と並べて設計しておくものです。

移行と新旧の併存では、業務の変化まで考える

移行というと、データの移し替えや切り替え当日の作業を思い浮かべがちですが、要件定義で考えるべきことはもっと広くあります。たとえば、紙の手続きを残したまま、Webの受付経路を新たに追加する場合です。このときは新旧のどちらかに切り替えるのではなく、二つの経路が併存します。受付の状況をどう突き合わせるのか、問い合わせにはどちらの経路の情報で答えるのか、業務部門の作業はどう変わるのか。移行期間中の業務に加えて、紙とWebを継続して併用する場合の役割分担や情報管理まで設計しておくことで、システムの稼働後も現場の業務が滞りなく回ります。

要件定義は「決める場」をつくる工程

要件定義を形骸化させないために必要なのは、決めるべきことを決めるべき人が根拠をもって決め、その結果を関係者が同じ理解で共有することです。

目的と判断の軸が固まっていなければ、構想検討から始める。文書だけでなく画面で話す。結論の出ないものは期限付きの未決事項として見える化し、決める人と決めたことを明確にする。前提条件とつなぎ目の責任を言葉にする。そして、機能だけでなく非機能・運用・移行まで含めて、稼働後の姿を描く。いずれも特別な手法ではありませんが、プロジェクトの現場で徹底するのは簡単ではありません。

要件定義は、業務・システム・運用など、異なる立場の関係者が認識を合わせる重要な工程です。ここで生まれた合意の質が、その後の設計と開発、そして稼働後の運用までを左右します。現場を動かすのは要件定義書の厚さではなく、関係者が納得して下した判断の積み重ねだと、筆者は考えています。