職場の小さな「困った！」をシステム要件まで落とす話。
こんにちは。のぐちです。
アミューズメント系ユーザー企業で社内SEやっています。
主に各部門や店舗で起きている業務上の課題を可視化し、システム化企画→委託開発（or パッケージ製品導入）にて解決するといった仕事をしています。
最近は、予算が下りないような小さな課題に対して、既存システム活用やフリーツールを使って解決する！といった試みを始めました。
ユーザーが本当に解決したいことは何なのか
今回は、ユーザーが抱えている課題を、システム要件に落とし込む際に行う、要求ヒアリングの手法と、ヒアリング結果のまとめ方について練習してみたので、その記事になります。
前提：相手が伝えたいことは、大体情報が足りてない。
まず前提として、ユーザーから寄せられる相談のほとんどは、何らかの情報が不足しています。
大抵、「～で困っている」か「こうしてほしい」のみです。 また、出てくる 解決案も粒度が甘く、困っている本人も具体的になんで困っているのかよく分かっていないというパターンも多いため、ヒアリングによって問題の本質と、改善策の具体化を行う必要があります。
「閉じた質問」と「開かれた質問」
このようにユーザーが問題の本質を理解できていない場合は、「開かれた質問」によって、ユーザー自身に課題を気付かせることが効果的です。
このワークを始める前の私もそうだったのですが、SEってヒアリングをするときに、「閉じた質問」を使う癖があります。
閉じた質問は、相手からの回答がある程度限定されてしまうため、ユーザー視点での要件を聞き出すのには適していません。
では、次の章から、実際のシステム化案をベースに、「開かれた質問」を使ってシステム化の要求を具体化してみましょう。
1.景品補充タイミングを知りたい
これまでの検討状況
業務課題
店舗に導入している多くのプライズ機（UFOキャッチャー等）はリアルタイムで景品の獲得状態を通知する機能が無いため、休日等のお客様が多い時間帯は、店舗スタッフによる景品補充の遅れが多く発生します。改善案
スタッフによる目視以外の手段で景品の状態をチェックし、スタッフに通知する様な機能を開発する。現状の実装案
・機械学習を用いて、ブースの状態を常に監視し景品がなくなったら、Node-RED上のプログラムにブース番号を連携する。
・Node-RED と LINE MessegingAPI（これもLINE Notifyで良いかも）を利用し、景品が無い場合は、店スタッフのLINEにブース番号を通知する。
実際に聞いてみた
店舗業務なので、お店で業務に従事している、アルバイトさんとストアマネージャーさんに聞いてみました。
ヒアリング結果を経て
まず、LINE を活用すること自体が思い込みであることに気づきました。
ユーザー側に通知する部分のインターフェースは複数あったほうが、果が高そうですので、出力先のインターフェースは再検討しようと思います。
でも、既存のインカムに音声データ流すとかできるんだろうか…。
2.店の情報を簡単に調べたい
これまでの検討状況
業務課題
情報システム部のパートナー社員が、店舗からの問い合わせに対して、システムサポートを行うときに、店舗の基本情報（開店時間など）や導入されている機器の情報などを調べることがあります。
しかし、利用する情報毎に管理されているデータファイルが異なるので、ので、ファイルサーバー上の様々なファイルを開いて情報を持ってこなければならず、1件当たりの対応に時間が掛かります。改善案
店舗の各情報を人の代わりに探してきてくれるシステムがあると良い。現状の実装案
・ 各データのソースとなっているデータファイルをGCPに格納する。
・ Line Messaging API を用いてデータ検索の為の検索文字列を入力する仕組みを作る。この時に、メッセージをスペース区切りで複数指定できるようにする。
・ Node-REDで 検索文字列から、アクセスするデータファイルを判別し、API経由でGCP上のデータファイルから、必要な情報を検索する。
・ 検索結果をLINEに返す
実際に聞いてみた
ヒアリング結果を経て
LINEで調べるといった方向性は合ってそうですが、LINE上の検索操作はそれぞれ想いがあるようなので、いろいろとやってみて適したものを選定してく必要がありそうです。
また、入力インターフェースとしては、メール受信した添付ファイルをそのままGCPにアップロードする仕組みがあると便利そうです。
ヒアリングしてみてわかったこと
インターフェースの利便性は立場によって変わる
作る側は各ツールで何ができるのかを理解しているので、ツールで実現できそうな範囲の要件設定をしてしまいがちですが、利用者の意見は自由です。
特に、入力インターフェースは1つでも、出力インターフェースは、ストアスタッフだとインカムが便利、ストアマネージャーだとバックヤードにあるシステムが便利など、利用者の立場によって異なるとようで、要件のすり合わせが必要そうです。
不可能では無いけど限界はあるよねって話
私は基本的にITでできないことは無いと思っているのですが、時間とコストの限界はあるので、限られた範囲内でどこまでの機能を実装するかの見極めが開発上のポイントになると思っています。
ただし、利用者にとって本当に必要な要件を見落としてしまうと、使われないシステムになってしまうので、ヒアリングによって問題の本質と、改善策の具体化を行うことは大切だなぁと再認識しました。
今回の記事はここまでになります。最後まで読みいただきありがとうございました！
note では基本的に課題創出から実装計画までのアプローチ、具体的な実装部分はQiitaに投稿していますので、ご興味のある方はQiitaの方も見てくださいね！