小さく作って育てる業務システムの進め方

業務システムで一番多い失敗は、機能が足りないことではありません。

完成したのに、誰も使わないことです。

この記事では、それを避けるための進め方を書きます。

なぜ「一度に全部作る」と失敗するのか

よくある進め方はこうです。

関係者を集めて要望を出し切る → 仕様書にまとめる → 半年かけて作る → 完成

一見きちんとしていますが、次のことが起きます。

最後の点は特に重要です。
「あったら便利」を全部入れると、毎日使う機能が埋もれます。

「全部の業務」ではなく、一番時間を取られている作業ひとつを選びます。

選び方の基準は「毎日やっているか」「間違いが起きやすいか」の2つです。
月1回の作業は、後回しで構いません。

画面数でいうと3〜5画面程度。費用は数十万円が目安です。

この段階では、便利機能は入れません。
「その作業が終わる」ことだけを目指します。

ここが一番大事です。

使ってみると、想定と違うことが必ず出てきます。

これは机上では分かりません。使わないと分からないことです。

使って分かったことを反映し、次に困っている作業を足していきます。

この繰り返しなら、作った機能が無駄になりません。

小さく作ること自体は簡単ですが、後から足せる構造にしておく必要があります。

ここは技術的な話なので、依頼時に「あとで機能を足していく前提です」と伝えてください。
それだけで、作り方が変わります。

画面は後から変えられますが、データの構造は後から変えるのが大変です。

「将来どこまで管理したいか」だけは、最初に共有しておくとスムーズです。

Gibbleでは、この「小さく作って育てる」進め方を基本にしています。

フルリモートでのやりとりなので、画面を共有しながら
「ここをこう変えたい」をその場で確認できます。