長期の開発支援では、要望が同時にいくつも発生します。すべてに「できます」と答えるのではなく、事業への影響と実装の順番を一緒に決めることが、外部のシステム担当に必要な仕事だと考えています。
開発中、見積中、待機中を、
同じ場所で話す。
SQairは定例の進捗資料で、案件名、開発状態、予定、発注状況、確認事項を一覧にします。直近の予定だけでなく、新規相談、保留案件、将来候補も分けて整理します。
一覧化の目的は報告ではありません。「今週何を決めれば進むか」「他の案件と競合していないか」「前提となるデータは揃ったか」を顧客と開発チームが同じ情報で判断するためです。
利用頻度が低いなら、
都度対応を提案することもある。
ある管理機能の相談では、大掛かりな改修になる一方で利用頻度が少ない可能性がありました。そこで、すぐに開発するのではなく、必要なときに個別対応する方が合理的ではないかと提案しています。
作れることと、作る価値があることは、同じではありません。
売上だけを考えれば開発を勧められます。しかし、顧客の費用と運用負荷まで考えるなら、既存機能の使い方を変える、小さな自動処理にする、しばらく人が対応する、という選択肢も必要です。
一つの画面ではなく、
会社の情報の流れを見る。
マイページ、Salesforce、物件サイト、メール、SMS、外部サービスは、利用者から見れば一つの仕事です。依頼された画面だけを直すと、別の場所に二重入力や確認作業が移ることがあります。
要望の担当範囲を越えて影響を確認し、前後の業務まで含めて選択肢を出す。
実際のプロジェクトでも、会員画面の改善から顧客履歴、通知、データ連携までを並べ、どの順序なら既存運用を止めずに変えられるかを検討してきました。
相談の解像度は、
関係が続くほど上がる。
業務の背景、過去に見送った理由、現場ごとの例外を知っていると、新しい相談への答えが速くなります。SQairが目指すのは、納品して終わる受発注関係ではなく、「まず聞いてみよう」と思ってもらえる外部のシステム担当です。
技術の話が固まっていなくても構いません。「この作業を減らしたい」「この連絡を忘れたくない」という段階から、一緒に作るべきものを探します。