――要件定義は、画面を決める前から始まる
Aqua Bouche Systems合同会社 代表 海老原光雄
「依頼した機能はそろった。システムも動いている。それなのに、仕事は思ったほど楽にならず、業績にも変化が見えない」
もし、システムを導入してこのように感じたら、何を見直すべきでしょうか。
操作性や処理速度、教育や運用にも原因はあり得ます。その中で私が最初に立ち返りたいのは、「そもそも、何を実現するために作ったのか」という問いです。
どんな画面を作るかを決めることと、会社の仕事をどう良くするかを考えることは、別の仕事です。
要件定義では、実現したい成果を明らかにし、そのために必要な業務、役割、機能、制約、確認方法を具体化します。画面設計は、それを人が使える形にするための重要な設計です。両者はつながっていますが、画面の項目やボタンを決めただけで、要件定義が済むわけではありません。
例えば、ある卸売会社から「受注入力画面を使いやすくしたい」と相談されたとします。
詳しく聞いてみると、本当に困っているのは、取引先からの問い合わせにすぐ答えられないことかもしれません。在庫を倉庫担当者に確認し、納期を別の担当者に確認し、回答するまでに時間がかかる。その間に、注文の機会を逃しているのではないか。
この場合、入力画面を改善するだけでは、確認待ちの時間は残ります。
まず考えるべきなのは、在庫や納期の情報をどこで管理し、誰が更新し、誰が確認できるようにするかです。一定の条件なら営業担当者が回答できるようにするのか。例外だけを責任者に確認するのか。受注後に同じ内容を別の台帳へ入力する作業は、本当に必要なのか。
そこまで考えた結果、必要なものが「新しい入力画面」ではなく、「情報の共有と、判断のルールの整理」だと分かることもあるでしょう。
この例が示すように、実現したいことと、最初に思いついた実現方法は、一度切り離して考える必要があります。目的が明確になれば、もっと単純な方法や、開発する範囲を小さくできる方法が見つかる可能性もあります。
そのためには、現在の業務を丁寧に理解することが欠かせません。ただし、現在の業務フローを、変えてはいけない前提にはしない。 これが私の考え方です。
今の仕事のやり方には、そうなった理由があるはずです。当時は情報を共有できなかった。紙の書類を回す必要があった。特定の人だけが判断できた。その事情を理解したうえで、今も同じ手順が必要なのかを考えます。
紙の帳票をそのまま画面に置き換えても、二重入力や確認待ちまで残してしまえば、得られる効果は限られます。仕事の順序や担当者の役割を見直すことで、初めて改善できる部分があります。
もちろん、安定稼働や保守性の向上を目的とする開発にも価値があります。業務を変えること自体が目的なのではなく、守りたいことと改善したいことを明確にすることが大切です。
その先に必要なのが、事業としての考え方です。
納期回答を早くすることで、注文の機会を逃しにくくする
転記や確認の負担を減らし、同じ人数でも対応できる件数を増やす
在庫の状況を把握し、余分な仕入れや欠品を減らす
こうした、何を変えれば、なぜ会社が良くなるのかという筋道が必要です。私は、これもシステム開発の前提となる事業戦略の一部だと考えています。
ただし、経営者や現場の方に、完成した戦略や仕様書を最初から用意していただきたいわけではありません。日々の仕事の中にある不便や、うまく言葉にできない問題を一緒に整理し、改善の仮説にしていく。開発を担当する側も、この議論に参加するべきだと思っています。
また、作業時間が減ったことが、そのまま売上や利益の増加を意味するわけではありません。空いた時間を営業に使うのか、残業を減らすのか、増える注文に対応するのか。改善をどう成果につなげるかまで考えて、投資を判断する必要があります。
私は長年、業務システムの開発に加えて、アプリケーションを構築するためのツールや、共通の定義から仕様書とプログラムを生成する仕組みを考案・開発してきました。
その中で大切にしてきたのが、処理の流れや役割を整理し、単純な仕組みを組み合わせて全体を作るという考え方です。
業務には複雑な事情があります。それを扱うためにも、情報を受け取る、確認する、判断する、登録する、例外を人に引き継ぐ、といった役割を明確にしたい。一つひとつを理解し、確かめられる構成にすることが、使いやすさや、後から直せることにもつながると考えています。
この姿勢は、AIを使った開発でも変わりません。
私にとってAIは、実装を支援するだけでなく、問題を深く検討するための議論の相手でもあります。なぜそう考えるのか、前提に誤りはないか、別の方法はないか。AIからの反論も検討し、逆にAIの説明に矛盾があれば問い直します。長年の開発経験をもとに、この往復を通じて問題の構造と判断の根拠を明確にしていくことを大切にしています。
ただし、議論が整っただけで正しいと決めることはできません。確かめられた事実と仮説を分け、残る疑問は試作や実測で確かめる。こうした検討を、実際の業務や設計の判断につなげることに、AIを活用する価値があると考えています。
私自身、AIと開発を進める中で、機能の説明だけでは、操作の流れまで十分に決まらないことを改めて実感しています。「会員情報を編集できる」という機能と、「一覧から対象を選び、編集し、保存結果を確認できる」という使い方の間には、具体化すべきことが残っています。入力を間違えた場合や、保存に失敗した場合も同じです。
AIは、考えたことを試すための力になります。だからこそ、何を作らせ、何を確認するのかという判断が重要になります。
要件定義も、最初にすべてを言葉で決め切ればよいとは考えていません。目的と確認したいことを整理し、小さく作って、現場で使う人と確かめる。そこで見つかった問題を、業務や設計の見直しに戻す。この往復によって、理解を深めていきます。
同時に、最初の開発が、その後の発展を妨げないように考えます。
まず一つの部門で使い、次に他部門へ広げる。商品情報の共有から始め、受注や発注へつなげる。そのような将来像を持ちながら、最初にどこまで作るか、どのデータや仕組みを共通の土台にするかを決めます。将来の機能をすべて最初から作るのではなく、必要になったときに育てられる構成と計画を考えるのです。
そして、導入後には効果を確認します。回答にかかる時間、転記の回数、入力ミス、担当者の負担など、目的に合う指標で導入前後を比べる。期待どおりでなければ、原因を調べ、業務とシステムの両方を改善します。
私が要件定義から関わるのは、事業の目的、日々の業務、システムの設計を、一つのつながったものとして考えたいからです。
Aqua Bouche Systemsの受託開発では、私自身がこの検討から関与し、全体の構成と段階的な開発計画を整理したうえで、設計・開発・検証へ進みます。現在の課題を解くことと、将来の変化に対応できることの両方を考えます。
システムを発注する前に、まず「これが変われば、会社の仕事はどう良くなるのか」を考えてみてください。
まだ画面や機能が決まっていなくても構いません。困っていること、変えたいこと、これから実現したいことをお聞かせください。そこから一緒に整理することが、私たちの開発の出発点です。