チャプター 1
期限が先に決まっている案件だった
催事買取は、スーパーや公民館、商業施設を借りて期間限定で開く買取会です。どの会場をいつ押さえるかで結果がほぼ決まるため、会場選定がこの事業の心臓部にあたります。
その判断を担っていた社員の退職が決まっていました。引き継ぎ資料を作れば済む話ではありません。ExcelとレポートPDFを目視で突き合わせ、経験から会場を絞り込む工程は、手順として書き出せる形になっていなかったからです。
つまり、期限が先に決まっている案件でした。理想のシステムを設計している時間はなく、退職までに何を形にできるかで区切る必要があります。
チャプター 2
会場選定より先に、実績入力から作る
最終的に作りたいのは会場選定の仕組みです。それでも、最初に着手したのは実績入力の画面でした。
会場をランク付けするには、過去の催事がどこで何を買い取っていくら利益が出たのか、というデータが要ります。その入力が紙とスプレッドシートに散らばったままでは、どんなに良い選定ロジックを作っても材料が揃いません。
順番を逆にすると、たいてい失敗します。判断の仕組みを先に作っても、入力されるデータが揃わないまま放置される。地味な入力画面のほうを先に置くのが、結果的に近道でした。
チャプター 3
完成品ではなく、プロトタイプを先に出す
要件定義の後、時間をかけずにプロトタイプを出しました。全画面が動く状態のものを触ってもらい、その場で要望を受ける進め方です。
実際、デモの場では想定していなかった要望が複数出ました。ランキング上位の扱い、リピート実績の見方、責任者ごとの集計。仕様書の上では出てこなかった論点ばかりです。
こうした要望は、動くものを触って初めて出てきます。時間が限られている案件ほど、完成品を目指して作り込むより、粗いものを早く出して直すほうが速く着地します。
チャプター 4
退職までに、何が残ったか
過去の催事データを取り込み、複数拠点での運用を始めました。これまで担当者の頭の中と個人のExcelにあった実績が、全員が同じ画面で見られる形になっています。
属人化の解消は、その人を代替することではありません。判断の材料を人の外に出しておくことです。材料さえ残っていれば、判断そのものは残った人たちが引き継げます。
会場選定の自動推奨は、この土台の上に次のフェーズとして載せていく予定です。
- 課題
- 催事買取は、どの会場でいつ開くかで結果がほぼ決まります。ところがその会場選定は、Excelとレポートを目視で突き合わせる属人業務でした。判断できる担当社員の退職が決まっており、時間の制約がはっきりしている状態です。
- 打ち手
- 会場選定そのものより先に、判断の材料になる実績データの入力から着手しました。スプレッドシートとチャットツールに分散していた業務を1つのWebアプリに集約し、まずプロトタイプを出して週次で改善しています。
- その後
- 過去の催事データを取り込み、複数拠点での運用を開始しました。担当者の頭の中にあった判断材料が、誰でも同じ画面で見られる状態になっています。
