ツールと業務の理解メモ
仕様書・要件定義を読む前に、このメモを埋めながらヒアリング・業務観察を行う。
仕様書に書いてあることは後から読めばいいので、書類に書いていないことを中心に記録する。
📌 1. 基本情報（30秒メモ）
ツール名：
このツールは何？（一言で）：
誰が使う？：
いつ使う？：
❓ 2. なぜ必要？（業務担当者の頭の中）
このツールがないと何が困る？
- 業務が止まる → 止まる理由：
- 時間がかかる → どれくらい？：
- ミスが起きる → どんなミス？：
- その他 → 具体的に：
過去に実際に起きた問題
具体的なエピソードを1つメモ：
🔄 3. どう使われる？（業務の流れ）
簡単なフロー
前に何する？：
↓
【このツール】何をする？：
↓
後に何する？：
データの流れ
どこからデータが来る？：
どこへデータが行く？：
📥📤 4. インプット・アウトプット（ざっくり）
何を入れる？
何が出る？
⚠️ 5. トラブルと注意点
よくあるトラブル
トラブル1：
- なぜ起きる？：
- どうする？：
トラブル2：
- なぜ起きる？：
- どうする？：
絶対に触ってはいけない部分
- 部分： 理由：
- 部分： 理由：
🎤 6. ヒアリングで確認すること
必ず聞く質問
-
このツールが動かなかったとき、どうやって業務を続けますか？
→ 回答メモ： -
このツールで一番困っていることは何ですか？
→ 回答メモ： -
理想的には、このツールにどうなってほしいですか？
→ 回答メモ： -
このツールを使い始めたのはいつからですか？どういうきっかけで作られましたか？
→ 回答メモ： -
データが間違っていたとき、どうやって気づきますか？
→ 回答メモ：
追加で聞いたこと
質問：
回答メモ：
質問：
回答メモ：
📚 7. メモ・気づき
仕様書に書いていない重要なこと
不明点・要確認事項
- [ ]
- [ ]
- [ ]
関連ドキュメント
- 仕様書： [リンク]
- 要件定義書： [リンク]
- 業務担当者： [名前/連絡先]
使い方のコツ
1. 仕様書を読む前に使う
先に仕様書を読んでしまうと、「業務の文脈」が見えなくなります。
まずはこのメモを埋めながらヒアリングを行い、その後で仕様書を読むと理解が深まります。
2. 業務担当者の言葉をそのまま記録する
専門用語や現場の言い回しをそのまま残すことで、後から見返したときに「あの時の会話」が蘇ります。
3. エピソード・具体例を大事にする
「過去にこんなトラブルがあって...」という話は、業務の重要度や優先順位を理解する鍵です。
4. 細かい仕様は書かない
データ形式、項目名、計算式などの詳細は仕様書に書いてあるので、このメモには書きません。
必ず聞くべき5つの質問の意図
① このツールが動かなかったとき、どうやって業務を続けますか？
意図： 業務の重要度と代替手段を理解する
- 業務が完全に止まるのか
- 手作業で対応できるのか
- どれくらい影響が大きいのか
② このツールで一番困っていることは何ですか？
意図： 改修の優先順位を見つける
現場の本当の困りごとは、仕様書には書いていないことが多いです。
③ 理想的には、このツールにどうなってほしいですか？
意図： 本当のニーズを引き出す
現状の不満だけでなく、「こうだったらいいのに」という理想を聞くことで、改善のヒントが見つかります。
④ このツールを使い始めたのはいつからですか？どういうきっかけで作られましたか？
意図： 歴史的経緯と背景を知る
「なぜこの処理があるのか」を理解する鍵は、ツールが生まれた背景にあります。
⑤ データが間違っていたとき、どうやって気づきますか？
意図： 検証方法とエラー検知の仕組みを理解する
業務担当者が日常的にどうやってチェックしているかを知ることで、テストケースや検証ロジックが見えてきます。
まとめ
仕様書だけでは分からない「業務の文脈」を理解するためのテンプレートを紹介しました。
このテンプレートを使うことで：
- 仕様書を読む前に業務の全体像が掴める
- ヒアリング時に聞き漏れを防げる
- 開発中に「なんでこうなってる？」と迷ったときの参考になる
ぜひ現場で使ってみてください！
参考：設計の背景
このテンプレートは以下のフレームワークを参考にしています：
- ジョブ理論（Jobs to be Done） - なぜこのツールが必要か
- ユーザーストーリー - 誰が、いつ、何のために使うか
- SIPOC分析 - インプット/プロセス/アウトプットの整理