Blog

お客さんの言った通りに作るのは、たぶん仕事じゃない

お客様から「この機能を作りたい」と言われたとき、そのまま作れば一番話は早いです。

でも、自分はそこですぐに作り始めるのが苦手です。なんで？と聞きたくなります。

要望と問題は、普通に違う

「AIを入れたい」「検索を良くしたい」「管理画面を作りたい」。こういう相談はよくあります。でも、その言葉は解決策であって、問題そのものではないことがあります。

例えば「AIで問い合わせ対応を自動化したい」という話でも、本当に困っているのが回答を書く時間なのか、担当者によって答えが違うことなのか、過去の回答を探せないことなのかで、作るものは変わります。

ここを飛ばして「AIですね、作りましょう」と進むと、ちゃんと動くけど役に立たないものができます。技術的には成功、事業的には知らん。これは避けたいです。

これは会社の営業手法というより、自分の思考の癖に近い気がします。何か問題があると、表面の現象より「なんでこうなっているのか」を掘る方です。

システム開発でも同じで、画面や機能の話を聞いていても、その裏の業務や判断を知りたくなります。誰が使うのか。今はどうしているのか。どこで止まるのか。代わりに何を使っているのか。

そこまで聞くの？と思われることもあるかもしれません。でも、ここを分からないまま作ると、目の前の要望には応えていても、全体ではお客様の利益を削ることがあります。だから掘ります。

要件定義という言葉は少し堅いですが、自分の中では「何を作るかを決める作業」より、「何を解決するかを一緒に決める作業」に近いです。

お客様自身も、最初から問題を完璧に言葉にできるわけではありません。現場では当たり前になりすぎて、どこが不便なのか説明できないこともあります。

だから会話しながら、実際の資料や業務を見ながら、問題を一緒にほどいていきます。

この考え方を突き詰めると、少し変な開発会社になります。

既存のサービスで十分なら、それを使えばいい。表計算で解決するなら、それでもいい。運用を変えるだけで済むなら、システムを増やさなくてもいい。

開発会社なのに作らない。商売どうした。とは思いますが、そっちの方がお客様の利益が大きいなら、それが正解です。

自分たちが売りたいものではなく、お客様の利益を最大化するところから考える。その結果として開発が必要なら、そこで初めて作る。

結局、自分がやりたいのは御用聞きではなく、一緒に問題を定義して、全体として一番利益が出る解き方を探す仕事なんだと思います。