要件が固まっていなくても、システム開発は始められる

システム化を考えて相談したら、「要件をまとめてから来てください」と言われて止まってしまった。この話をよく聞きます。

要件を自分たちでまとめられるなら、そもそも困っていません。ここでは、決まっていない状態から進める方法を書きます。

要件が固まらないのは、当然のこと

要件定義とは、業務のやり方を言葉と図にする作業です。毎日やっている業務ほど、体が覚えていて言葉になっていません。「なんとなく大変」の中身は、外から質問されて初めて見えてきます。

つまり要件は、**相談する前に用意するものではなく、相談しながら出てくるもの**です。

決めるべきは「何を作るか」ではなく「何をやめたいか」

最初に決めるべきなのは機能ではありません。次の3つです。

• いま、いちばん時間を取られている作業はどれか
• その作業が一日・一週間でどれくらい発生しているか
• なくなったら、その時間で何をしたいか

ここが決まっていれば、作るものは後から決められます。逆にここが曖昧なまま機能から決めると、「便利そうだから」で機能が増え、使われないシステムになります。

最初の打ち合わせで、あると早いもの

用意できなくても構いませんが、あると話が早く進みます。

• いま使っている**Excelや帳票の実物**（きれいに整える必要はありません）
• 業務の流れが分かる人が同席していること
• おおよその予算感（金額そのものより「どこまでなら出せるか」の感覚）

いちばん役に立つのは、整った資料より、実際に使っている汚れたExcelです。そこに業務のルールがそのまま残っているからです。

決めきらずに進める、という進め方

私たちは、要件を最初に全部固めきる作り方をしていません。効果の大きい範囲を小さく作って、実際に触っていただき、そこで出てきた「ここが違う」を反映しながら広げていきます。

開発の進め方を5段階に分けているのも、途中でやめる判断ができるようにするためです。提案・見積もりの段階で違うと思われたら、そこで断っていただいて構いません。

「そもそも作らない」も選択肢に入れる

相談を受けて、「それは既製品で足ります」とお答えすることもあります。会計や給与計算のように法改正への追従が必要な領域は、既製品の得意分野です。

判断の材料はSaaSとオーダーメイドの比較にまとめています。作らない判断も含めて、一緒に考えるところからで構いません。