本文へ移動
知恵の一覧へ
運営/DX/AIX事例・判断記録

rhara ドメインスペシャリストへのインタビューテクニカルFB

熟練者の判断は「なぜ」ではなく「何を見て・何を知って決めたか」で聞く

この知恵で考えられること

https://app.tactiq.io//transcripts/geL6SW29s3cnmOawY5Et/ai-chats/MuH9WEQNEDiI?utmsource=tactiq-product&utmmedium=share-meeting&utmcampaign=link

概要

作業実体の観察、エキスパートインタビューの実施

ログはこちら

https://app.tactiq.io/#/transcripts/geL6SW29s3cnmOawY5Et/ai-chats/MuH9WEQNEDiI?utm_source=tactiq-product&utm_medium=share-meeting&utm_campaign=link

総論

全体的に良い。十分聞けてる。

細かい深掘り方については発展の余地があるので書く。

各論

作業の必要性への深掘り

もっと聞いても良さそう。

やらなくてもいい可能性や、やらなくていいかどうかを何で見ているかとかの特定がちょいゆるそう。

作業内容への深掘り

good

  • 判断や行為のそれぞれに着目している点
  • 作業者が今見せていない業務についての例外作業などの確認をしている

more

判断が見られた場合には「なんで?」という判断理由の言語化を求めるのも良いが、最終的にはアルゴリズムに落とし込んでいくことになるので、「何を見たから判断できたのか?」「何を知っているからあなたは決めれたのか?」などの判断材料を明確にすることが重要

作業フロー・単位への深掘り

現在の作業や区分の分け方がベストなものと、工数の都合からしょうがなくそうなっているものなどがあるのかないのかがあまり掴めなかった。

目的に応じた1d、3d区分があるとして、どうあることが望ましくて、どういう都合をもとに今の期間や区分けの数に収まっているのかなどを捉えれると良い。

今人間でやっている都合の上での区分のため、それを機械でやる上で障壁となりやすいのはフローや単位であることが多いので、機会化できるなら週一で良いとか、むしろ区分を10個に分けた方が捌きやすいなどもある。

整理

流れ

要点の流れ(簡潔に時系列で)

  1. 挨拶と目的確認:乙部さんが担当業務(統計プライジング、情報プライジング、1day/3dayプライジング)を説明。録画/文字起こしあり。
  2. 在庫管理の全体像:在庫確保率やストック(表在庫・裏在庫)の概念、目標パーセンテージ、在庫薄・在庫過多時の対応方針を説明。
  3. 統計プライジングの手順説明:対象期間(前日9:00〜当日8:59)で売上データを絞り込み(主に「9枚以上」「1〜8枚かつ在庫0〜3枚」)、優先判断基準を示す。
  4. 実例レビュー(思考の垂れ流し):複数カードを実際に開き、売れ行き・表示回数・買取申し込み・ストック・同名商品の代替性・市場相場(メルカリ等)・オリパ使用状況等を見ながら、個別の価格変更・買取枠設定・露出(新入荷表示)判断を実演。
  5. 買い占め/購入制限の運用:特定ユーザー向けに購入制限を外す例や、ルール上4枚以上入るカードで制限を外す理由を説明。
  6. 情報プライジングの説明:デッキメーカー、X(Twitter)、YouTube、大会結果など外部情報の収集方法と、それらを基にした需要予測・在庫収集の判断(事前収集の重要性)を説明。
  7. 1day/3dayプライジングの違い:1dayは大会トレンドや新商品影響で値動き大・短期対応が必要、3dayは変動小で定期的な確認で良い、という分類と運用感。
  8. 補充リストとロジスティクス連携:補充リスト(月・木作成)/自動抽出と手動追加の運用理由(戦略的に補充しない選択もある)を説明。補充はロジ部門が実行。
  9. 自動化の検討点:統計プライジングの作業量増加(成長に伴う負荷)、自動化できそうな箇所(統計でのスルー判定や情報入力→自動反映など)、AIや属性データベース整備の必要性について議論。
  10. 今後の進め方・優先事項:まず統計・情報・1dayの基礎運用を押さえつつ、属性データ整備→自動プライジング条件の設計→開発実装へつなげる方針。要件定義や画面改善で作業効率化を検討する合意で終了。

以上が会話の大まかな流れです。必要なら各項目をさらに短く/詳細化します。

問いかけの内容

以下、原さん(Ryota)が行った質問を、発言時の状況(何を見ていたか/議論の文脈)を付けて、Markdown(h3見出し)で整理しました。必要なら発言時刻や乙部さんの回答要約も追加できます。

全体感の質問をしてもいいですか?

状況:セッション開始直後、乙部の説明を聞き始めた段階で全体像について質問(導入・確認目的)。

画面共有しているもの見えますか?

状況:乙部が画面共有を始めた直後、表示確認のため。

統計プライジングの説明、もうちょっと質問していいですか?

状況:統計プライジングの解説が始まったタイミングで、深掘りの許可を求める確認。

3dayプライジングとかもありましたよね?

状況:プライジングの種別(1day/3day等)について全体の位置づけを確認する場面。

マニュアルにあった買い占め対応や高価格帯プライジング、在庫型プライジング等はどういう位置づけですか?

状況:マニュアルを見ており、各種プライジングの運用上の役割分担を明確にしたい場面。

これは在庫関連のページですか?(確認)

状況:乙部が在庫ページ(スプレッドシート)を説明している最中の確認質問。

デスマーチみたいな予定で見直しているものですか?

状況:画面に表示されていた予定(デスマーチ等)について、その関連性を確認する質問。

週末発表のカードと相性がいいのはどこで仕入れた情報ですか?(twitter等の情報源か)

状況:統計で注目したカードの需要仮説に関して、情報源(SNS等)を特定したい場面。

先ほどの20円上げる判断はどういう判断ですか?(なぜ20円か)

状況:乙部が価格を小刻みに上げる判断(例:20円)を説明した直後に、理由と感覚値の根拠を問う場面。

2000円以上買わないと購入できないんですか?(最低購入金額の確認)

状況:超特価コーナーの販売ルール説明の流れで、最低購入金額の運用を確認する質問。

まさか1対1の関係になることって他にもありますか?

状況:特定ユーザーが特定カードを継続的に買う事例(1対1の関係)を聞いた直後に、類似ケースの有無を尋ねる場面。

在庫切れなさそうかの判断は何日くらいが目安ですか?

状況:売れペースと在庫補充の見立てについて、時間軸の目安(何日で判断するか)を確認する場面。

(給料日/ボーナスで売れやすくなる)という理解でよいか?

状況:売れの周期性(給料日/ボーナスなど)について、乙部の仮説確認を行った場面。

次は在庫薄い方の説明をお願いします(という依頼)

状況:統計プライジングの概説後、在庫が薄い(0–3枚)群の詳細説明を依頼する場面。

5分ほど休憩を取ってもいいですか?(休憩の確認)

状況:ミーティング中盤で一時休憩を挟みたい旨を申し出た場面。

今日のゴールを決めてほしい(という希望・質問)

状況:休憩後、セッションの進め方・本日の達成目標を明確化したい趣旨での確認。

品質基準(どこまで厳密にやるべきか)を知りたいです

状況:プライジング業務の“必須ライン”と“許容できる緩いライン”を知り、優先順位付けや自動化対象を決めたい場面。

情報プライジングと1day/3dayの触りだけ教えてほしいです(依頼)

状況:統計以外のプライジング(情報プライジング・1day/3day)の概要を把握したい旨で要請した場面。

youtubeのデッキリストを事前に見ているか?(乙部さんは)

状況:情報収集(YouTube)について、乙部が事前にチェックしているかを確認する場面。

情報プライジングで得た情報を入力する画面があれば自動化できるかも、という提案的確認

状況:情報を構造化して管理画面に入れれば自動化負荷が下がるのでは、というアイデアに対する反応確認。

ワンデーに昇格させる基準の自動抽出はあり得るか?(提案の確認)

状況:統計で拾った候補を自動的にワンデー昇格候補として抽出する仕組みの実現可能性を問いかけた場面。

統計とワンデーでかかる時間はそれぞれどれくらいですか?

状況:業務工数把握のため、各プライジングに要する時間(目安)を確認する場面。

メルカリ等のスクレイピングは諦めたのか?(確認)

状況:外部マーケット価格取得の手段(スクレイピング)について、現状の可否を確認する場面。

(総括)プライジングが詰まっているという認識で合っているか?

状況:業務負荷の課題認識について、プライジングがボトルネックという理解が正しいか確認する場面。


補足オプション:

  • 各質問の正確なタイムスタンプを付ける(はい/いいえ)
  • 乙部さんの回答を要約して紐づける(はい/いいえ)
  • CSV/表形式で出力する(はい/いいえ)

どれを追加しますか?

解像度ありきで行われている会話

はい。原さん(Ryota)からは「業務解像度がないと進められない」提案/問いかけがいくつか出ていました。主なものと、実装に高い業務解像度(=詳細要件)が必要な箇所を簡潔にまとめます。

  1. 品質基準(必須ライン vs 許容ライン)の明確化(高解像度必要)
    • どの変更は“多少ミスしても良い”か、どれが“絶対に人の判断が必要”かを定義したいと要請。
    • 自動化の安全弁やエスカレーション基準を決めるため詳細ルールが必要。
  2. 情報プライジング/1day昇格の判定基準(高解像度必要)
    • どの情報(YouTube / X / デッキメーカー / CS結果等)をどの重みで評価し、いつ1dayに上げるかの定量ルール化を想定。
    • 昇格トリガー(売上変化、露出、同名ストック状況など)の明文化が必要。
  3. 情報入力画面 → 自動プライジング連携(高解像度必要)
    • 原さんは「情報を入力すれば自動プライジングに反映されるUI」を提案。実装には入力項目、反映ロジック、優先順位、上書きルール等を定義する必要あり。
  4. 自動化に向けたカード属性/データベース整備(高解像度必要)
    • 「カード属性(採用枚数、流通量想定、レアリティ等)を整理して自動ルールに当て込む」話。属性定義とマッピング設計が要る。
  5. 管理画面や抽出リストの改善(中〜高解像度)
    • 統計で“見る必要のない”カードを自動抽出するUI改善。要件定義(どの条件で抽出するか)は業務ルールに依存する。
  6. 開発運用体制・要件定義の役割(低〜中解像度)
    • 誰が要件定義を作るか(MD側で作るか開発と協働か)の確認。これはプロセス設計が必要だが、まずは責任分担の合意で進む。
  7. メルカリ等スクレイピングの可否確認(低解像度)
    • 規約で不可のため現状断念。代替データ取得の検討が必要。

結論(短く):

  • 原さんの多くの提案は“可能だが実現に業務の詳細ルール化が不可欠”という内容でした。特に「品質基準」「1day昇格トリガー」「入力→自動反映のロジック」「カード属性のデータ化」は、現場ルールを具体化しないと実装や安全な自動化が難しいです。

次に私ができること(提案):

  • 上記のうち優先度の高い項目(例えば「品質基準」と「1day昇格トリガー」)の要件定義のたたき台を作成します。5〜10項目のチェックリスト形式で短く作れますが、作成してよろしいですか?

ご希望があれば、どの項目をまず要件化するか選んでください。