配車トークの開発を進めていると、スプレッドシートの見せ方についていろいろな要望が出てきた。
もちろん、技術的には対応できるものも多い。しかし今回は、すぐには手を入れず、実際に使う現場から要望が出てくるまでは静観することにした。
MVPとしてスタートする以上、できるだけシンプルにしておきたいからである。
開発していると、「こういうケースもあるのではないか」「ここも便利にしておいた方がいいのではないか」と、実際にはまだ起きていないことまで想定して機能を追加したくなる。
だが、これまでの経験では、想定して作った機能が実際にはほとんど使われないことも多い。
それなら最初はシンプルにしておいて、運用で対応できるものは運用で逃げる。その方が、何か問題が起きたときにも、どこに原因があるのか見つけやすいのではないかと思う。
もちろん、導入してしばらく使ったあとで「どうしてもここは必要だ」という話になれば、その時点で考えればいい。
今回改めて考えたのは、「ニーズ」と「対処療法」を切り分ける必要があるということだ。
エンドユーザーから意見を聞いたとき、目の前の困りごとをそのまま機能追加で解決しようとしてしまうことがある。しかし、その困りごとの背景にある本当のニーズは別のところにあるかもしれない。
要望が出たら作る、ではない。
なぜその要望が出たのかを見る。
そして、本当にシステムで解決すべきことなのか、運用で対応できることなのかを考える。
AIを使った開発では、以前より機能追加そのものは簡単になった。だからこそ、「作れるから作る」にならないようにする必要があると思う。
この日の朝、43号線まで車を走らせたものの、かなり混んでいた。月末の週末であることに気づき、今日必ず行かなければならない用事でもなかったので、鳴尾でUターンして帰った。
交通渋滞の原因になる1台として並び続けるより、今日は行かないという選択でいい。
振り返ると、システム開発も似ているのかもしれない。
できるから進むのではなく、本当に今やる必要があるのかを見る。
機能を増やすことより、増やさない判断の方が難しいこともある。
MVPを作る中で、その判断を大事にしていきたい。