こんにちは、製造業DXプランナーの平松昭良です。
今回は少し実践的なテーマで、システムやツールを導入する前段階にあたる、要件定義についてお話しします。少し地味な工程に思われるかもしれませんが、ここでつまずくと、そのあとに続くすべての工程が静かに狂っていきます。SIerで数多くのプロジェクトに携わり、その後は使う側でもさんざん苦労してきた経験から、現場で本当に使われるものを生み出すための要件定義の考え方を、私なりにお伝えしたいと思います。
平松昭良が考える、要件定義でつまずく本当の原因
多くの導入プロジェクトは、実は要件定義の段階で、すでに失敗の種をまいています。表面上は順調に進んでいるように見えても、出発点がずれていれば、行き着く先もずれてしまうのです。
よくあるのは、現場が何に困っているのかを十分に聞かないまま、入れたい機能の話から始めてしまうことです。あの会社が導入したから、流行っているから、便利そうだから。そうした動機で機能ありきの議論が進んでいき、肝心の現場の困りごとが置き去りにされてしまう。
エンジニア時代、私自身もこの落とし穴に何度かはまりました。便利そうな機能を並べ、それらしく整理して要件として固めていく。会議は活発で、資料も立派で、一見すると順調そのものです。ところが、できあがったものは現場の実際の困りごととどこかずれていて、結局はほとんど使われない。この苦い経験を重ねるなかで、私はようやく理解しました。要件定義とは、機能を決める作業ではなく、現場の課題を正しく言葉にする作業なのだ、と。
現場の声を要件に翻訳するということ
要件定義でいちばん難しいのは、現場の人の話を、そのまま要件にしてはいけない、という点です。これは少し意外に聞こえるかもしれませんが、とても大切なところです。
現場の方に困りごとを尋ねると、たいていは今のやり方を前提にした要望が返ってきます。この帳票をこの形のまま電子化してほしい、今の手順をそっくりシステムに置き換えてほしい、といった具合です。もちろん、その声は何よりも貴重です。ですが、その要望をそのまま受け取って形にしてしまうと、今ある紙の不便さや、長年の手間ごと、まるごとシステムへ持ち込むことになりかねません。不便を高い費用で再現してしまう、という笑えない事態が起こるのです。
大切なのは、その要望の奥にある、本当の目的をくみ取ることです。なぜその帳票が必要なのか。その情報を、誰が、何のために、いつ見ているのか。その作業は、そもそもなくせないのか。そこまで一段深く掘り下げて、はじめて現場の声は、使える要件へと翻訳されていきます。声をそのまま写すのではなく、声の奥にある願いを訳す。これが、要件定義の腕の見せどころだと私は思っています。
平松昭良が実践する、引き算の要件定義
私が要件定義で徹底しているのは、足すことよりも、削ることです。
要望をすべて満たそうとすると、システムは必ず複雑になり、現場の負担が増え、結果として使われなくなります。これは過去の記事でも繰り返しお伝えしてきたとおりです。だからこそ私は、出てきた要望をいったんすべて並べたうえで、ていねいに優先順位をつけ、本当に必要なものだけに絞り込んでいきます。
このとき意識しているのは、これだけは絶対に外せない、という一点を見極めることです。あれもこれもと盛り込んだ要件よりも、これさえあれば現場が回る、と言い切れる要件のほうが、最終的にはずっと長く生き続けます。何を入れるかを考えるのと同じくらい、いや、それ以上に、何を入れないかを決めること。その引き算の判断こそが、要件定義の核心だと私は考えています。削る勇気を持てるかどうかで、システムの寿命は大きく変わります。
要件定義は導入後を見据えて行う
もうひとつ、私が大切にしているのは、要件定義の段階で、すでに導入したあとの運用を見据えておくことです。
たとえば、誰がそのデータを入力するのか。その人に、入力のための作業時間は本当に確保できるのか。入力されたデータを、誰が、どのように使って、どんな判断につなげるのか。こうした運用の現実を、要件を固める前の段階で確かめておく必要があります。これを怠ると、立派な要件はできても、それを支える人の手当てがないまま走り出してしまい、結局は破綻するのです。
受託の立場では、契約上ここまで踏み込むのはなかなか難しいことでした。納品の範囲の外側だったからです。けれども、使う側を経験し、独立して現場に伴走するようになった今、私はこの運用を見据える工程を、もっとも重視しています。要件定義は、未来の運用への約束だと思っているからです。
つくる側を知るからこそできる支援
要件定義は、つくる技術への理解と、現場への理解、その両方がそろって、はじめてうまくいく工程です。どちらか片方だけでは、必ずどこかに無理が出ます。
私はSIerで、仕様を固める作業を数えきれないほど経験しました。そして、そのあとは使う側で、固めた仕様が現場で実際にどう生きるのか、あるいはどう死んでいくのかを、間近で見届けてきました。この両方の経験があるからこそ、私は現場の声を技術の言葉へ、そして技術の制約を現場の言葉へと、双方向に翻訳することができます。
動くDXは、立派な要件からではなく、現場に根ざした要件から生まれます。その大切な入口を、現場の皆さんと一緒に、ていねいに設計していくこと。それが、つくる側を知る私だからこそ果たせる役割だと考えています。
