ユーザーが言葉にできないものを、システムにする

「こんなシステムが欲しい」

ユーザーから、そんな明確な言葉が出てくることは、実はそれほど多くありません。

「今のやり方だと、なんとなく使いづらい」
「毎回この作業が大変」
「もっと簡単にならないかな」
「こういうことができたらいいんだけど……」

でも、そこで止まってしまう。なぜなら、ユーザーはシステムをつくる専門家ではないから。

自分たちが日々どんな業務をしていて、どこに時間がかかっていて、何に困っていて、本当はどうなったら嬉しいのか。

それを「システムの要件」として言語化するのは、簡単なことではありません。

だからこそ、私たちは考えています。

ユーザーが言葉にできないものを、代わりに言語化する。

それも、エンジニアの重要な仕事ではないか、と。

例えば、「この作業を自動化したい」と言われたとします。そこで「では、この機能をつくりましょう」と始めるのではなく

「なぜ、この作業が大変なのか？」
「今は、どんな手順でやっているのか？」
「一番時間がかかっているのはどこか？」
「本当に自動化すべきなのは、この作業なのか？」
「そもそも、この業務自体を変えられないか？」

と、一つずつ掘り下げていく。

すると

「自動化したい」のではなく、「そもそも、この確認作業が必要な業務設計になっていることが問題だった」ということに気づくかもしれません。

そこで初めて、「何をつくるか」ではなく、「何を変えるべきか」が見えてきます。

これは、単純なプログラミングスキルだけではできません。ユーザーの業務を理解する。現場に行く。話を聞く。質問する。違和感を見つける。課題を構造化する。本当に必要なものを定義する。そして、それをシステムとして実現する。

つまり

「技術を使って、ユーザーの曖昧な思いを具体的な仕組みに変える」仕事です。

私たちは、これからの内製化において、こういうエンジニアがとても重要だと考えています。ただ仕様書に書かれたものを実装するだけではない。

「何をつくるか」が決まってから参加するのではなく

「そもそも、何をつくるべきなのか？」

そこからユーザーと一緒に考える。

ユーザー自身もまだ言語化できていない課題を見つけ
「本当に必要なのはこれです」と形にする。

そして、こういうことができる人は、実はとても少ない。技術が分かるだけでも難しい。

業務を理解する力も必要。

人の話を聞く力も必要。

本質を問い直す力も必要。

そして、最後は自分自身がシステムとして実現できなければならない。だからこそ、私たちはこの能力を大きな価値だと考えています。

「つくれるエンジニア」から、
「つくるべきものを見つけられるエンジニア」へ。

実装者として終わるのではなく、現場へ行き、業務を理解し、ユーザーの声を聞き、データを見て、課題を発見し、何をつくるべきかを考え、最適な仕組みを設計する。

そして、その仕組みを自分たちの手でつくる。

ユーザーが言葉にできないものを、言葉にする。
言葉になったものを、仕組みにする。
そして、その仕組みで事業そのものを変えていく。

それが、これからの「内製化」だと私たちは考えています😊