「つまり、こういう機能ですね」と言いたくなる前に

ユーザーの曖昧な言葉を、すぐに機能や画面やナレッジベースへ変換してしまう。システムエンジニアリングでは、その速さがかえって本質を見えにくくすることがあります。

※執筆にあたり生成AIとの対話を活用しています。
※公開後、タイトルとリード文を一部見直しました。初出時のタイトルは「答えが出る前に、失われるもの」でした。

「2」には、もう結果しか残っていない

「1+1」を式として評価すると、答えは「2」になります。だから、計算結果としては同じです。けれども、意味としては同じではありません。

「1+1」には、「1と1を足す」という途中の姿が残っています。一方で、「2」には、もう結果しか残っていない。

「2」からは、それが「1+1」から来たものなのか、「3-1」から来たものなのか、「6÷3」から来たものなのかはわかりません。

式を評価するということは、答えを得ることです。しかし同時に、そこにあった過程や意図の多くをそぎ落とすことでもあります。しかも、それはかなり不可逆な操作です。

早く答えるように、私たちは慣らされてきた

私たちは長いあいだ、問題を早く正確に解くことに慣らされてきました。

「1+1=?」

そう問われたら、なるべく早く、「2です」と答える。

計算ができること、問題を解けること、正しい答えにたどり着けること。それらは確かに、ひとつの能力です。

けれども、その反射神経をそのままシステムエンジニアリングに持ち込むと、少し危ういことが起きます。

ユーザーは、まだ式を探している途中かもしれない

ユーザーが、「こうやって、こうやって……」と、自分のしたいことを話し始める。

まだ輪郭ははっきりしていない。言葉も揺れている。本人も、何に困っているのかを、完全にはつかみきれていない。

そのとき、こちらがすぐに、「はいはい、つまり2ですね」と言いたくなる。

もちろん、整理が必要な場面はあります。どこかでは形にしなければならない。ただ、それが早すぎると、まだ見るべきものまで落としてしまう。

たとえば、「暗黙知の継承が課題です」と聞いた瞬間に、頭の中ではもう解法の棚卸しが始まっている。

ナレッジベース、業務手順の整理、AIの活用。

どれもそれらしい。そして実際、どれも役に立つ場面はあります。

けれどもその時点では、継承したい暗黙知が何なのかを、まだ問えていない。作業手順なのか、判断基準なのか、異常を察知する感覚なのか。それによって、必要な式はまったく変わります。

「暗黙知の継承」という言葉は、まだ答えではありません。それどころか、問題文ですらないのかもしれない。

そこにいきなり「2」を置いてしまうと、何かを解いたような気持ちにはなります。しかし、本当に見なければならなかった式は、その手前に残されたままになります。

答えの中に沈んでしまう問い

なぜ、その人は1と1を足そうとしたのか。なぜ、それを今、足さなければならなかったのか。足した先に、何を期待していたのか。そもそも、その二つは本当に足すべきものだったのか。

そういう問いが、「2」という答えの中に沈んでしまう。

問題を解くことに慣れた人間は、しばしば「考えること」と「問題を解くこと」を同じものだと思ってしまいます。

けれども、システムエンジニアリングの入口では、まだ問題が問題の形をしていないことが多い。あるのは、業務の流れの中で生じている違和感や、手間や、言葉になりきらない期待です。

答えにする前のものを、持ちこたえる

必要なのは、答えを出す力だけではない。答えにする前のものを、持ちこたえる力です。

曖昧な話を、すぐに仕様にしない。揺れている言葉を、すぐに機能名にしない。ユーザーのつぶやきを、すぐに自分の知っている解法へ回収しない。

少し立ち止まって、「いま、この人は何を式にしようとしているのだろう」と見る。

早く答えなさい、正しく答えなさい、迷わず答えなさい。そう訓練されてきた人間にとって、答えを急がないことは、案外むずかしい。

「2」と答えたくなる体質を、少しだけ脇に置く。そして、そこにどんな「1+1」が生まれようとしているのかを、もう少しだけ見てみる。

持ちこたえることが、すでに入口に立つということなのかもしれません。

※似た問いを、別の記事でも考えています。ノーコード／ローコードという便利な道具に、私たちはつい早く答えを見てしまうことがあります。作れることと、見えていること。その間にある距離について書いた記事です。