「こういうことをしたい。でも、何から説明すればよいかわからない」。システムの相談では、その状態が自然です。業務の専門家はお客様であっても、それをシステムの言葉へ翻訳することまでお客様の仕事ではありません。
仕様書より先に、
現場の判断を見る。
最初に確認するのは、欲しい機能の一覧だけではありません。誰が、どの情報を見て、何を判断し、次の担当へどう渡しているかを追います。表計算、メール、電話、紙のメモなど、正式な業務フローに現れない作業にも重要な判断が隠れています。
例えば「顧客一覧が欲しい」という要望でも、必要なのは一覧画面とは限りません。対応漏れを見つけたいのか、担当者を割り振りたいのか、売上の見込みを判断したいのかによって、表示する情報も次の操作も変わります。
機能名ではなく、その画面を見た人が次に何を判断するのかを確認する。
要望と、本当の課題を分ける。
「この作業を自動化したい」という要望を、そのまま実装するとは限りません。入力項目を減らすだけで解決することもあれば、前工程で情報を確定した方がよいこともあります。既存サービスとの連携で十分なら、新しい機能を作らない判断も必要です。
SQairでは、現在の作業時間、ミスが起きる場所、例外時の対応、利用者ごとの権限まで確認します。そのうえで、システムに任せる部分と、人が判断する部分を分けます。
自動化することよりも、迷わず仕事が進む状態を作ることが目的です。
文章ではなく、
画面から対話を始める。
ヒアリングした内容は、早い段階で画面案にします。ボタンの位置や項目名が見えると、「この場合は別の担当が処理する」「ここでは金額を確定できない」といった、文章だけでは出にくい条件が見つかります。
画面案は完成デザインではなく、会話を前に進めるための道具です。早く見せ、修正しながら精度を上げることで、開発後の大きな手戻りを防ぎます。
システムは、公開後に完成へ近づく。
実際に使い始めると、想定していなかった使い方や改善点が見つかります。すべてを最初から盛り込むのではなく、重要な流れを先に動かし、利用状況を見ながら改善する方が、結果として使いやすい仕組みになります。
SQairが目指しているのは、一度納品して終わる関係ではありません。業務や事業が変わったとき、内部事情を理解したうえで次の改善を相談できる、社外のシステム部門です。