公開前に想定できることには限界があります。利用者、データ量、外部サービス、事業ルールが変わるなかで、直すだけの保守ではなく、判断しながら育てる体制がシステムの寿命を決めます。
「使い方の問題」で、
問い合わせを終わらせない。
操作ミスが起きたとき、利用者だけを原因にすると同じ問い合わせが続きます。ボタンの名称が分かりにくい、重要な状態が目立たない、業務の順序と画面が合っていない、権限によって説明が変わるといった背景を確認します。
個別の問い合わせはその場で解決しつつ、頻度、影響人数、作業時間、誤操作の危険性を記録します。複数の声が同じ原因へつながったとき、画面改善や自動化の候補にします。
開発中だけでなく、
見積中・待機中も同じ場所に置く。
長期支援では、マイページ、Salesforce、Webサイト、通知、外部連携など、複数の相談が同時に進みます。SQairは進捗資料で、開発中、確認待ち、見積中、保留、納品中を分け、予定、発注状況、次に決めることを一覧にします。
直近2週間の作業予定と、中長期の候補を分けることで、緊急の修正だけに追われず、次の改善を準備できます。顧客側の確認待ちも見えるため、「開発が遅れている」のか「判断材料を待っている」のかを混同しません。
声の大きさではなく、
事業への影響で順番を決める。
優先順位は、要望が出た順だけでは決めません。業務停止の危険、対象人数、毎月発生する作業時間、顧客への影響、他案件の前提になるかを比較します。法令や契約期限、店舗開設など動かせない日付がある案件は先に確保します。
大掛かりな改修に対して利用頻度が低い場合は、都度対応や既存機能の活用を提案することもあります。開発会社の売上ではなく、顧客が支払う費用に見合う変化があるかを基準にします。
「作れるか」ではなく、「今作る価値があるか」を一緒に判断する。
本番へ出した日と、
業務で使えると確認した日を分ける。
外部データ連携や大量データ処理では、プログラムが動くだけでは完了ではありません。テスト環境でデータを確認し、本番へ反映し、一定期間の検収で修正を行います。連携先のデータ更新が必要なら、その完了連絡を待って自動処理を開始します。
定期クローラーのように処理時間が長い機能は、取得件数と所要時間を記録し、他の処理と重ならないスケジュールを組みます。障害時にどこから再開するかも決め、公開後の運用を仕様の一部として扱います。
過去の判断を知るチームが、
次の改善を速くする。
同じシステムを長く支援すると、項目名だけでは分からない業務背景、見送った案、外部サービスの制約、繁忙期の優先順位が蓄積されます。新しい要望が既存機能へ与える影響を早く見つけられ、説明を毎回やり直す必要も減ります。
SQairが目指すのは、障害時だけ連絡する保守会社ではありません。定例で相談を受け、作る・作らない・あとで作るを一緒に判断し、会社の変化に合わせて仕組みを育てる外部のシステム担当です。
納品物を守るのではなく、変わり続ける業務を支える。