使う前の要望より、使った後の不満を優先する

システムやWebサービスの開発では、最初の打ち合わせで多くの要望が出てきます。

「この機能も欲しい」
「こういう画面もあった方がいい」
「将来的には、ここまでできるようにしたい」

話し合っているうちにイメージが膨らみ、最初に考えていたものより大きな仕組みになることも珍しくありません。

もちろん、将来を見据えて考えることは大切です。

ただ、Bitでは、使う前に出てきた要望をすべて最初から作ることが、必ずしも良い開発だとは考えていません。

使う前の要望は、まだ想像の中にある

開発前の要望は、実際に使った経験から出てきたものではありません。

多くの場合は、

「こうなったら便利そう」
「念のため、この機能も欲しい」
「将来使うかもしれない」

という想像をもとにしています。

そのため、実際にはほとんど使われない機能まで作ってしまうことがあります。

機能が増えれば、開発費も納期も増えます。

画面や操作も複雑になり、かえって使いにくくなることもあります。

高機能であることと、使いやすいことは、必ずしも同じではありません。

使った後の不満は、現場から生まれる

一方、実際に使い始めてから出てくる不満は具体的です。

「この入力だけ毎回面倒」
「ここが分かりにくい」
「この情報が一覧で見たい」
「同じ内容を二度入力している」

こうした声は、実際の業務の中から生まれています。

誰が、どの場面で、何に困っているのかが見えやすいため、改善すべき優先順位も判断しやすくなります。

つまり、使う前の要望は想像から生まれ、使った後の不満は現場から生まれます。

Bitが後者を重視するのは、そのためです。

次のフェーズに回すことで、本当に必要かが分かる

打ち合わせの段階で出た要望を、すぐに否定する必要はありません。

「それは次のフェーズで検討しましょう」

と一度保留にして、まずは最低限の形で使い始めます。

すると、しばらくして二つに分かれます。

一つは、使い続けてもやはり必要だと感じる機能です。

もう一つは、当初は欲しかったけれど、今のままでも十分だと分かる機能です。

開発前には重要に思えた要望でも、実際に運用すると、それほど必要ではなかったと気づくことがあります。

反対に、最初は想定していなかった小さな不便が、毎日の業務では大きな負担になることもあります。

時間を置くことで、本当に必要な機能が自然に選別されていきます。

最初から完成品を目指さない

Bitでは、最初からすべてを盛り込んだ完成品を作るのではなく、まずは小さく使える形を作ることを大切にしています。

これはMVP、Minimum Viable Productという考え方です。

必要最低限の機能で実際に使い、現場の反応を見ながら育てていきます。

例えば、音声で報告内容を集める仕組みであれば、最初から複雑な管理画面や権限設定まで作る必要はないかもしれません。

まずは、

• 音声を送る
• AIが内容を整理する
• スプレッドシートに保存する

という基本的な流れだけでも、現場で役立つ可能性があります。

実際に使ってもらい、

「担当者別に見たい」
「期限を自動で抽出したい」
「管理者だけが見られる画面が欲しい」

という不満が出てきた段階で、次の開発を考えればよいのです。

作らない判断も、開発の一部

開発というと、機能を追加することばかりに目が向きます。

しかし、必要性が確認できるまで作らないことも、大切な判断です。

使われない機能を作らなければ、予算を抑えられます。

納期も短くできます。

運用も複雑になりません。

その分、本当に困っている部分に時間と費用を使えます。

「できるから作る」のではなく、「必要だから作る」。

この違いは、長く使える仕組みを作るうえで、とても重要です。

Bitは、使いながら育てる開発を大切にしています

使う前の要望を軽視するわけではありません。

最初の要望は、方向性を考えるために必要です。

ただし、それをすべて最初から実装するのではなく、まず使える形にして、実際の現場で確かめる。

そして、使った後に残った不満を優先して改善する。

Bitでは、この進め方を大切にしています。

使う前の要望より、使った後の不満を優先する。

それは、作る側の都合ではなく、お客様にとって本当に必要な仕組みを、一緒に見つけていくための考え方です。