vol. 18『「これはほとんどない話なのですが」がシステムに与えるインパクト』

現在、弊社では、ある大規模な基幹業務システムの要件定義を進めています。

今回は文章で要件を整理するだけでなく、かなり細かな画面までモックを作り、お客様に実際の操作をイメージしていただきながら確認しています。

すると、こんな話が出てきます。

「これは1社の顧客にしか行っていないのですが」

「1年に2～3回あるかどうかなのですが」

お客様としては、発生頻度の低い細かな業務なので、最初に伝えるほどのことではないと思っていたのでしょう。

ところがシステム開発では、この「年に数回しかない処理」が、大きなインパクトを持つことがあります。

請求書の宛先を変えるだけではない

たとえば、要件定義の終盤で、次のような話が出てきたとします。

・何件かの顧客への請求を、別の代表となる顧客にまとめて行っている
・代表の顧客から入金があれば、まとめられていた複数の顧客をすべて入金済みにする必要がある

一見すると、

「請求書の宛先を変えるだけでは？」

と思うかもしれません。

しかし、通常のシステムは、暗黙のうちに次のような構造で作られています。

・顧客Aの売上を登録する
・顧客Aに請求する
・顧客Aから入金される
・顧客Aを入金済みにする

ところが先ほどの例では、顧客A・B・Cの売上を顧客Xへまとめて請求し、顧客Xからの入金によって、A・B・Cを入金済みにしなければなりません。

つまり、

・サービスを利用する顧客
・請求書を送る顧客
・実際に入金する顧客

が一致しないのです。

こうなると、画面に「請求先」という項目を一つ追加するだけでは済みません。

売上、請求、入金をそれぞれ別の単位で管理し、相互に紐づける仕組みが必要になります。

さらに、一部だけ翌月の請求に回す場合、まとめたうちの1社だけ金額を変更する場合、一部入金だった場合なども考えなければなりません。

対象となる顧客や発生件数は少なくても、データベースや入金管理の構造全体に影響する可能性があるのです。

頻度と開発への影響は比例しない

プラムザでは以前から、こうした細かな要望にも、できるだけ真摯に対応してきました。

ただし、開発の中盤や終盤で要望が出てくると、その時点では画面や処理だけでなく、データベースの構造もかなり固まっています。

そこで根本的な例外処理が見つかると、

・関連画面の作り直し
・集計や帳票の変更
・データベース構造の見直し
・テスト範囲の拡大
・開発期間の延長
・追加料金の協議

につながりかねません。

もちろん、お客様が要望を隠しているわけではありません。

レアケースなので、「細かい話だから後でよい」と判断してしまうのです。

しかし、例外処理の重さは、対象顧客の比率や発生回数では決まりません。

通常の業務やデータ構造を、どこまで変える必要があるかで決まります。

AIで要件定義が変わり始めた

従来、要件定義の段階で細かな画面まで作るには、かなりの時間と費用が必要でした。

そのため、最初は文章や簡単な図で確認し、詳細な画面は設計や開発が進んでから作るのが一般的でした。

ところが現在は、AIを活用することで、要件定義の段階から実際のシステムに近いモックを作れるようになっています。

画面を見ながら確認すると、

「この顧客だけ請求先が違います」
「確定後でも、この場合だけ修正します」
「普段は一括ですが、年に数回だけ分割します」

といった話が、開発に入る前に出てきます。

AIの価値は、プログラムを速く書けることだけではありません。

これまで開発の後半にならなければ見つからなかった問題を、要件定義の段階で発見できることにもあります。

もちろん、見つかった例外をすべてシステム化する必要はありません。

・システムに組み込む
・手作業として残す
・既存の業務に合わせる
・そもそもの運用を見直す

影響や費用を確認しながら、早い段階で判断できることが重要です。

ごく一部の顧客にしか行っていない業務が、システム全体の設計を左右することがあります。

プラムザでは、こうした業務の細かな違いまで一緒に整理し、作りすぎと、後から発生する大きな手戻りの両方を防ぐ要件定義をお手伝いしています。

「こんな細かいことを相談してよいのだろうか」と思う内容ほど、遠慮なくお聞かせください。