システムの開発や導入を依頼したことがある場合、必ずと行っていいほど、ヒアリングの時間を取られると思います。

しかし、ヒアリングで「何をしたい」「何が欲しい」という種の話をしてしまうと、着地点がぶれてしまうことが往々にしてあります。ヒアリングに慣れていない人は、ユーザーから答えを引き出そうと躍起になってしまいます。

何をしたいって言われても、御社のシステムを入れることがしたいのではなく、その先にある課題を解決したいわけですが、この「課題」というのが曲者です。

自社の課題を正確に他者に伝えることは、難しいことです。

例えば、システム開発の検討を開始するとします。企業規模にもよりますが、各部署、各担当者に社内でまずヒアリングを行い、課題だと感じていることに対して共通認識を持った上で、細部を詰めていく。その中でも、次から次へと問題が発覚して、優先順位を付け、業務や作業をどう変革できたらよいかを詰めて…

上記は現状分析の一貫ですが、この内容を共有していない他者に伝える難しさ、面倒くささ、想像に難くないと思います。

課題解決の立脚点がブレてしまうと、ゴールがぶれてしまいます。この怖さは、ブレた状況に身をおいたものではないとわからないものなのです(笑)

ITで業務上の課題解決を図りたいと願うのであれば、その立脚点にすべき点は1つだけ。ここを詰めてください。

「なぜ、その状況のままにしておくことができないのか」これを明文化してください。

なんでこのままではダメなのかを詰めていくには、その業務に携わっている当事者の体験談を聞く必要があります。感想ではなく体験です。体験は事実です。実際に起った都合の悪いことに目を向けてください。目を向けると「その体験が引き起こされた環境」で解決すべきものが見えてきます。これが立脚点になります。

システムは融通が効きません。人間よりも圧倒的にアドリブが効かない。

人間であれば「この得意先の場合は欠品があると総キャンセルくらうので、先にちゃんとすべての商品で在庫があるかチェックしよう」みたいな先回りができます。でも、システムは命令の集合体なので、チェックルールを作って命令を実行させることしかできません。例外という概念はありません。

この場合ですと、得意先A者の注文受注時、注文明細の全ての在庫が満たされているかをチェックし、欠品がある場合はエラーとして入力をストップする、というルール作りが必要です。

このような感じで、組織としての意思決定の間違いがないように、作業ミスが起きないように、どんな機能を作ればよいかを考えて、自分たちの欲しい機能の解像度を上げていくと、業者からも突っ込んだ提案をもらいやすくなりますし、提案とのズレもわかるようになります。

ほとんどの会社さんはまず情報を集めようとします。集めたところで判断軸が定まっていないなら、検討が進みません。判断軸が明確な上で情報が欲しいと伝えると、情報の質が変わります。フィットしている・していないが肌感覚で見えてくるようになるので、まずは、そこから！