業務アプリ開発がうまくいかない最大の原因は、ツールの性能ではなく、要件定義の段階での認識不足にあります。業務アプリ開発とは？で触れた通り、要件定義は「何を入力し、何を出力するか」を整理する最初のステップです。本記事では、要件定義で押さえておきたいポイントと、よくある失敗パターンを解説します。
要件定義で整理すべき4つの要素
業務アプリの要件定義では、次の4つを整理しておくと、開発側との認識のズレを防ぎやすくなります。
1. 入力データ
どこから、どのような情報を入力するのかを明確にします。現在Excelや紙で管理している場合は、実際に使っている項目をそのまま洗い出すのが分かりやすい方法です。
2. 処理・計算ロジック
入力された情報をどう処理するかを整理します。自社特有の計算ルールや承認フローがある場合は、できるだけ具体的に説明できるようにしておきます。
3. 出力・表示
最終的に何を表示・出力したいのかを決めます。画面に表示するだけでよいのか、印刷用の帳票が必要なのか、他の担当者に通知する仕組みが必要なのかによって、必要な機能が変わります。
4. 例外処理
通常の流れに当てはまらない場合にどうするかを、あらかじめ決めておきます。「この条件のときは担当者に確認する」「この場合は処理を止める」といった例外を想定しておくことで、運用開始後のトラブルを減らせます。
たとえば受注管理アプリを作る場合、入力データは「顧客名・商品・数量・希望納期」、処理ロジックは「在庫数と希望納期から納期回答を自動計算する」、出力は「受注確認書のPDF出力」、例外処理は「在庫が不足している場合は担当者に通知して手動で調整する」といった形で、4つの要素を具体的な言葉に当てはめていくと、要件が整理しやすくなります。
要件定義のよくある失敗パターン
要件定義でつまずきやすいのは、次のようなケースです。
最初から完璧を求めてしまう
すべての業務パターンを最初から網羅しようとすると、要件定義そのものに時間がかかりすぎてしまいます。まずは主要なパターンを整理し、細かい例外は開発を進めながら調整していくほうが、現実的に進められます。
現場の声を聞かずに決めてしまう
実際にツールを使うのは現場の担当者です。管理者だけで要件を決めてしまうと、現場の実情と合わない仕様になり、運用開始後に「使いにくい」という声が出てしまいます。たとえば、管理者は「入力項目を増やして詳しく記録したい」と考えていても、現場では「入力の手間が増えるだけで、結局使われなくなる」というケースが少なくありません。どこまで詳しく入力するかは、管理者の希望と現場の負担感の両方を踏まえて決める必要があります。
口頭でのやり取りだけで済ませてしまう
打ち合わせで話した内容を文書化せずに進めると、後から「言った」「言わなかった」という行き違いが起きやすくなります。簡単なメモでもよいので、決まったことは記録に残しておくことが大切です。
テストツールを使った要件の固め方
最速3営業日の業務アプリ開発、テストツール先行プロセスの仕組みで紹介した通り、Seldishの業務アプリ開発では、受注前にテストツールを確認できます。要件定義の段階で完璧を目指すのではなく、テストツールを実際に操作しながら要件を固めていく、という進め方もできます。
文章や図だけで要件をすべて固めようとすると、現場の担当者にとっては想像しづらい部分が残ります。実際に動くテストツールを見ながら「ここはこうしたい」と具体的に伝えられるほうが、現場にとっても分かりやすく、要件の精度も高まります。
相談前に整理しておくと役立つメモ
要件定義の打ち合わせをスムーズに進めるために、事前に次の項目を簡単にメモしておくと役立ちます。
- 今、その業務をどうやって管理しているか（Excel・紙・口頭など）
- 1日・1週間あたり、どれくらいの頻度で発生する業務か
- 関わる人数と、それぞれの役割
- 今、困っていること・ミスが起きやすいところ
- 「これだけは絶対に対応してほしい」という最低限の要望
詳細な仕様書を作る必要はありません。箇条書きのメモ程度で十分です。これらが整理されているだけで、最初のヒアリングの精度が大きく上がります。
現場の巻き込み方
要件定義をスムーズに進めるには、実際にツールを使う現場の担当者に、早い段階から関わってもらうことが効果的です。管理者が想定する使い方と、現場が実際に行っている作業には、想定外のズレがあることがよくあります。
現場の担当者全員を要件定義に参加させる必要はありません。日常的にその業務を担当している1〜2名に話を聞くだけでも、実態に近い要件を整理できます。
よくある質問
要件定義に、どれくらいの時間をかけるべきですか？
業務の複雑さによって異なりますが、最初から完璧を目指さず、主要な部分が整理できた段階でテストツールに進む進め方が現実的です。細かい部分は、テストツールを見ながら調整していけます。
ITに詳しくない場合、要件定義はどう進めればよいですか？
専門用語を使う必要はありません。「今、何をどうやって管理しているか」を、現状のやり方に沿って説明するところから始めれば十分です。
要件定義の内容は、後から変更できますか？
テストツールの段階であれば調整しやすいです。本開発が進んだ後の大きな変更は、追加の時間や費用がかかることがあるため、テストツールを確認する段階で気づいた点はできるだけ早めに伝えることをお勧めします。
まとめ
業務アプリ開発の要件定義では、入力データ・処理ロジック・出力・例外処理という4つの要素を整理することが基本になります。最初から完璧を目指さず、現場の声を聞きながら、テストツールを活用して要件を固めていく進め方が、結果的にスムーズな開発につながります。業務アプリケーション開発に関するお悩み事などがあれば、まずはお気軽にSeldishにご相談ください。
