このブログ記事は、芝本秀徳著『誰も教えてくれない計画するスキル』を参考に、物語形式でプロジェクト計画の実践方法を解説したものです。
プロローグ：ある月曜日の朝
「山田さん、ちょっといいかな。」
月曜日の朝9時、コーヒーを片手にデスクに向かったばかりの山田太郎は、上司の営業部長・鈴木に呼び止められた。山田は中堅IT企業「テックソリューションズ」のプロジェクトマネージャーとして5年目を迎えていた。
「実は、大手小売チェーンの『スマートストア』から相談があってね。在庫管理システムを何とかしたいらしいんだ。君に任せたいんだが。」
鈴木部長の表情は、いつになく真剣だった。スマートストアは全国に300店舗を展開する急成長企業。もし成功すれば、会社にとって大きな実績になる。
「分かりました。詳細を教えていただけますか？」
「それがね...『とにかく在庫管理を改善したい』としか聞いていないんだ。明日の午後、先方を訪問することになっている。君も同行してくれ。」
最初の訪問：曖昧な要求の嵐
翌日、スマートストア本社の会議室。山田の前には、情報システム部の田中部長、商品部の佐藤課長、店舗運営部の高橋マネージャーが座っていた。
「我々の在庫管理は本当にひどい状態でして...」田中部長が口を開いた。「各店舗から『在庫が合わない』『発注ミスが多い』といった苦情が絶えません。何とかシステムで解決できないでしょうか。」
「新しい在庫管理システムを入れれば解決するはずです！」佐藤課長が力強く言った。
「いや、問題はシステムじゃなくて、店舗スタッフの教育不足では？」高橋マネージャーが反論する。
三者三様の意見が飛び交い、議論は平行線をたどった。山田は、このままでは要求が定まらないと直感した。
「皆さん、少し時間をいただけますか。個別にお話を伺って、状況を整理させてください。」
6Rフレームワークとの出会い
会社に戻った山田は、かつてメンターから受け取った資料を引っ張り出した。そこには「要求を正しく理解するための6Rフレームワーク」と書かれていた。
【解説】6Rフレームワークとは
6Rフレームワークは、プロジェクトの真の要求を体系的に把握するための手法です。多くのプロジェクトが失敗する原因は、表面的な要求だけを聞いて、本質的な課題や目的を理解せずに進めてしまうことにあります。
6つのRとは：
- Real Situation（現実の状況）：今、実際に何が起きているのか
- Recognition（問題認識）：関係者は何を問題と感じているのか
- Requirement（要求）：何を求めているのか
- Reason（理由・意図）：なぜそれが必要なのか
- Range of Work（作業範囲）：どこまでやるのか
- Result（期待成果）：何が達成されれば成功なのか
この6つを順番に明らかにすることで、プロジェクトの全体像が見えてきます。
山田はノートに6Rのフレームワークを書き出し、明日からの調査計画を立て始めた。
「まずは現場の実態から把握しよう。Real Situationだ。」
Real Situation（現状）を探る：現場調査の極意
翌朝、山田は都内の旗艦店を訪問した。店長の木村が現場を案内してくれた。
「山田さん、まずはバックヤードをご覧ください。」
そこには、段ボールが山積みになっていた。商品には手書きのメモが貼られている。
「これは...」
「在庫の実数をメモしているんです。システムの数字が信用できないので。」木村店長が苦笑いした。
【調査のポイント】Real Situationの把握方法
1. 現場観察（オブザベーション）
- 実際の作業現場を見る
- 作業者の動きを観察する
- イレギュラーな対応（手書きメモなど）に注目する
2. 数値データの収集
- 問題の規模を定量化する
- 頻度や影響度を数値で把握する
- 比較可能なデータを集める
3. 具体例の収集
- 実際に起きた問題事例を聞く
- いつ、どこで、何が起きたかを記録する
- 写真や画面キャプチャを撮る
山田は木村店長に詳しく質問していった。
「在庫の差異はどのくらいの頻度で発生しますか？」
「毎日です。特に売れ筋商品ほどズレが大きくて...」木村店長がパソコンの画面を見せた。「例えばこの人気スニーカー、システムでは在庫50個ですが、実際は43個でした。」
「この差異によって、どんな問題が起きていますか？」
「先週、お客様がネットで在庫を確認して来店されたんですが、実際は売り切れていて...大クレームになりました。」
山田は具体的な数値をメモしていく：
- 在庫差異発生率：全商品の約30%（月間延べ3,000SKU）
- 顧客クレーム：週平均15件（在庫関連）
- 在庫確認作業：1日3時間×3名＝9人時
- 機会損失：推定で月間500万円
Recognition（問題意識）を引き出す：本音を聞き出すテクニック
午後、山田は本社で田中部長と1対1の面談を行った。
「田中部長、先ほど店舗を見てきました。現場はかなり苦労されているようですね。」
田中部長は深いため息をついた。「ええ、実は私も元店長なんです。現場の苦労は痛いほど分かります。」
【調査のポイント】Recognitionの引き出し方
1. 共感を示す
- 「大変ですね」「お困りですね」と相手の立場に立つ
- 批判や否定をしない
- 相手が話しやすい雰囲気を作る
2. オープンクエスチョンを使う
- 「どのように感じていますか？」
- 「最も困っていることは何ですか？」
- 「理想的にはどうあるべきだと思いますか？」
3. 感情に注目する
- 不満、不安、怒り、諦めなどの感情を読み取る
- 感情の背後にある真の問題を探る
- 「なぜそう感じるのか」を深掘りする
「正直なところ、このままでは競合他社に負けてしまいます。」田中部長が本音を漏らした。「ECサイトの売上は伸びているのに、在庫が合わないせいで機会損失が膨らんでいる。経営陣からのプレッシャーも相当なものです。」
「具体的にはどのような影響が？」
「売上機会の損失が年間で推定5億円。さらに、余剰在庫の廃棄コストが2億円。合わせて7億円もの損失です。これは営業利益の20%に相当します。」
田中部長の問題認識をまとめると：
- 競争力の低下：在庫切れによる顧客離れ
- 経済的損失：年間7億円の機会損失
- 組織の疲弊：現場の負担増とモチベーション低下
- 経営への影響：利益率の大幅な低下
Requirement（要求）を整理する：要望の構造化
次に、山田は商品部の佐藤課長を訪ねた。
「佐藤課長、具体的にはどのような改善を望まれていますか？」
「そうですね、まずはリアルタイムで正確な在庫が分かるシステムが欲しいんです！」佐藤課長の要求が次々と出てきた。
【整理のポイント】Requirementの構造化方法
1. 要求を分類する
- 機能要求：システムが持つべき機能
- 非機能要求：性能、使いやすさ、セキュリティなど
- 業務要求：業務プロセスの改善点
- 制約条件：予算、期限、技術的制約
2. 優先順位をつける
- Must Have（必須）
- Should Have（あるべき）
- Could Have（あれば良い）
- Won't Have（今回は対象外）
3. 具体化する
- 曖昧な表現を避ける
- 数値や具体例を入れる
- 実現可能性を確認する
山田は佐藤課長の要求を整理していった：
機能要求（Must Have）
- リアルタイム在庫把握
- 店舗とECの在庫を統合表示
- 5分以内の更新頻度
- 自動発注機能
- 安全在庫を下回ったら自動発注
- 需要予測に基づく発注量算出
機能要求（Should Have） 3. 店舗間在庫移動の最適化
- 過剰在庫店舗から不足店舗への移動提案
- 賞味期限管理（一部商品）
非機能要求
「ところで山田さん、『非機能要求』って何ですか？」佐藤課長が首をかしげた。
「ああ、すみません。専門用語を使ってしまいました。」山田は説明を始めた。「機能要求が『何ができるか』だとすると、非機能要求は『どのくらいの品質で動くか』です。例えば...」
- レスポンスタイム：3秒以内
- 「在庫照会ボタンをクリックしたら、3秒以内に結果が表示される、ということです。今のシステムだと10秒以上かかることもありますよね？」
- 「ああ、それでイライラするんです！3秒なら待てますね。」
- 可用性：99.9%以上
- 「これは、システムがどれだけ安定して動くかを示す数字です。99.9%というのは、1年間でシステムが使えない時間が9時間未満という意味です。」
- 「月に45分程度なら、深夜のメンテナンスで対応できそうですね。」
- 使いやすさ：研修1日で操作習得可能
- 「新人スタッフでも、1日研修を受ければ使えるようになる、というレベルです。」
- 「それは重要ですね。人の入れ替わりが多い店舗もありますから。」
Reason（意図・仮説）を深掘りする：なぜを5回繰り返す
「ところで佐藤課長、なぜリアルタイム在庫把握が必要なのですか？」山田は核心を突く質問を投げかけた。
「在庫が正確に分かれば、欠品がなくなるからです。」
「なぜ欠品をなくしたいのですか？」
「お客様に迷惑をかけたくないからです。」
「なぜお客様に迷惑をかけたくないのですか？」
佐藤課長は少し考えてから答えた。「実は...最近、お客様の購買行動が変わってきているんです。」
【深掘りのポイント】Reasonの探り方
1. 「なぜ」を繰り返す（5 Whys）
- 表面的な理由で満足しない
- 本質的な目的にたどり着くまで聞く
- 相手を問い詰めるのではなく、一緒に考える姿勢で
2. 仮説を立てて検証する
- 「もしかして〜ということですか？」
- 「つまり〜が真の目的ですね？」
- 相手の反応を見て修正する
3. ビジネス価値に結びつける
- 売上向上につながるか
- コスト削減になるか
- 顧客満足度が上がるか
- 競争優位性が生まれるか
「今のお客様は、ネットで在庫を確認してから来店される方が増えています。『オムニチャネル』というやつですね。」佐藤課長が続けた。「ネットで『在庫あり』と表示されていたのに、店舗で『売り切れ』では、もう二度と来ていただけません。」
「なるほど！つまり、真の目的は在庫情報の精度向上によるオムニチャネル体験の実現ということですね？」
「そうです！まさにそれです。単なる在庫管理ではなく、お客様の購買体験全体を向上させたいんです。」
山田は真の目的（Reason）をまとめた：
- 表面的な要求：在庫管理システムが欲しい
- 真の目的：オムニチャネル時代の顧客体験向上
- ビジネス価値：顧客ロイヤルティの向上と売上増加
Range of Work（スコープ）を明確にする：境界線の引き方
店舗運営部の高橋マネージャーとの面談では、プロジェクトの範囲を詰めていった。
「高橋さん、今回のプロジェクトではどこまでを対象にすべきでしょうか？」
【範囲設定のポイント】Range of Workの決め方
1. 段階的導入を検討する
- パイロット店舗から始める
- 成功したら横展開する
- リスクを最小化する
2. 明確に「含む/含まない」を定義する
- 対象店舗、対象商品、対象業務を明確に
- グレーゾーンを作らない
- 文書化して合意を得る
3. 実現可能性を考慮する
- 予算内で実現できるか
- 期限内に完了できるか
- 技術的に可能か
- 組織的に対応できるか
「正直、一度に300店舗は無理です。」高橋マネージャーが言った。「まずは関東の主要50店舗でテストして、問題がなければ全国展開したいです。」
「商品カテゴリーはどうしますか？」
「食品は賞味期限管理が複雑なので、別システムでやっています。今回は非食品に絞りましょう。」
山田は範囲（Range of Work）を整理した：
含むもの（In Scope）
- 対象店舗：関東50店舗（第1フェーズ）
- 対象商品：非食品全般（約10万SKU）
- 対象業務：在庫管理、発注、店舗間移動
- 連携システム：POS、ECサイト
含まないもの（Out of Scope）
- 対象外店舗：関東以外の250店舗（第2フェーズで検討）
- 対象外商品：食品カテゴリー
- 対象外業務：仕入先との直接連携、会計処理
- 対象外システム：会計システム、人事システム
グレーゾーンの扱い
- 返品処理：基本機能のみ含む（詳細は要検討）
- レポート機能：標準的な5種類のみ（カスタムレポートは対象外）
Result（期待成果）を定義する：成功の測り方
最後に、山田は全員を集めて期待成果を確認した。
「皆さんの話を総合すると、このプロジェクトが成功したといえるのは、どのような状態でしょうか？」
【成果定義のポイント】Resultの設定方法
1. SMART原則で定義する
- Specific（具体的）：曖昧さを排除
- Measurable（測定可能）：数値で表現
- Achievable（達成可能）：現実的な目標
- Relevant（関連性）：ビジネス目標と整合
- Time-bound（期限付き）：いつまでに
2. 定量的指標と定性的指標を組み合わせる
- 定量的：数値で測れるもの（売上、コスト、時間など）
- 定性的：数値化しにくいもの（満足度、使いやすさなど）
3. ベースラインを明確にする
- 現状の数値を把握する
- 改善目標を設定する
- 測定方法を決める
議論の末、以下の成功基準が定まった：
定量的成果（6か月後）
- 在庫差異率：30%→5%以下（83%削減）
- 欠品による機会損失：月500万円→100万円（80%削減）
- 在庫回転率：年6回→年7.2回（20%向上）
- 在庫確認作業時間：9人時/日→1人時/日（89%削減）
定性的成果
- 顧客満足度スコア：3.8→4.5以上（5段階評価）
- 従業員満足度：「在庫管理が楽になった」が80%以上
- システム使いやすさ：「研修1日で使いこなせる」が90%以上
測定方法
- 月次でKPIレポートを作成
- 四半期ごとに経営層へ報告
- 顧客・従業員アンケートを実施
6Rをまとめて要求仕様書（SOW）を作成
1週間の調査を終えた山田は、6Rフレームワークで集めた情報を整理し、要求仕様書（SOW）を作成した。
【まとめ方のポイント】6RからSOWへの展開
SOWの基本構成
- 背景と現状（Real Situation + Recognition）
- 現在の問題点を数値とともに記載
- ステークホルダーの問題認識を整理
- プロジェクトの目的（Reason）
- 表面的な要求ではなく、真の目的を記載
- ビジネス価値を明確に
- 要求事項（Requirement）
- 機能要求と非機能要求を整理
- 優先順位を明記
- スコープ（Range of Work）
- 対象範囲を明確に定義
- 対象外も明記して誤解を防ぐ
- 成功基準（Result）
- 定量的・定性的指標を設定
- 測定方法も記載
山田が作成したSOWの要約：
プロジェクト名：スマートストア統合在庫管理システム構築プロジェクト
背景： スマートストアでは、店舗とECサイトの在庫情報の不整合により、年間7億円の機会損失が発生している。在庫差異率は30%に達し、顧客クレームも増加している。
目的： オムニチャネル時代の顧客体験向上を実現するため、リアルタイムかつ正確な在庫情報を提供する統合在庫管理システムを構築する。
主要要求：
- リアルタイム在庫同期（5分以内）
- 需要予測に基づく自動発注
- 店舗間在庫最適化
スコープ：
- 第1フェーズ：関東50店舗の非食品カテゴリー
- 第2フェーズ：全国展開（別途検討）
成功基準：
- 在庫差異率5%以下
- 機会損失80%削減
- 顧客満足度4.5以上
承認への道：関係者の反応
完成したSOWを手に、山田は再びスマートストアを訪れた。
「皆さん、これが6Rフレームワークを使って整理した要求仕様書です。」
田中部長は感嘆の声を上げた。「素晴らしい！我々がモヤモヤと感じていたことが、すべて言語化されています。」
「6Rフレームワークって何ですか？」佐藤課長が質問した。
山田は6Rの考え方を説明し、どのように情報を整理したかを共有した。
「なるほど、だから私たちの本当の想いが伝わったんですね。」高橋マネージャーも納得した。
「最初は『在庫管理システムが欲しい』という話でしたが、真の要求は『オムニチャネル時代に対応した統合在庫管理の実現』だったんですね。」山田がまとめた。
第1章のまとめ：要求理解の教訓
帰りの電車の中で、山田は今回の経験を振り返った。
教訓1：6Rフレームワークの威力 構造的に要求を把握することで、漏れなく、深く理解できる。
教訓2：現場・現物・現実の重要性 会議室の議論だけでなく、実際の現場を見ることで真の問題が見える。
教訓3：「なぜ」を問い続ける勇気 表面的な要求で満足せず、真の目的を探ることが成功への鍵。
教訓4：数値化の重要性 問題も成果も数値で表現することで、共通認識が生まれる。
教訓5：スコープの明確化が後の混乱を防ぐ 最初に「やること・やらないこと」を明確にすることが重要。
山田の手帳には、次のステップへの準備事項が書かれていた：
- プロジェクトチャーターの作成
- キックオフミーティングの準備
- チーム編成の検討
「6Rで要求は明確になった。次はプロジェクトの定義だ。」
山田は、プロジェクトの成功を確信しながら、夕暮れの街を歩いていった。
読者の皆様へ：6Rフレームワーク実践ガイド
第1章では、6Rフレームワークを使った要求理解のプロセスを物語形式でお届けしました。初めて6Rフレームワークを使う方のために、実践的なチェックリストを用意しました。
6Rフレームワーク実践チェックリスト
□ Real Situation（現状把握）
- 現場を直接観察したか？
- 問題を数値化したか？
- 具体的な事例を収集したか？
□ Recognition（問題認識）
- 各ステークホルダーの本音を聞けたか？
- 問題の影響度を確認したか？
- 感情面も含めて理解したか？
□ Requirement（要求整理）
- 要求を分類・優先順位付けしたか？
- 具体的に表現できているか？
- 実現可能性を確認したか？
□ Reason（意図確認）
- 「なぜ」を十分に深掘りしたか？
- 真の目的を見つけたか？
- ビジネス価値を明確にしたか？
□ Range of Work（範囲設定）
- 含む/含まないを明確にしたか？
- 段階的導入を検討したか？
- 関係者の合意を得たか？
□ Result（成果定義）
- SMART原則で定義したか？
- 測定方法を決めたか？
- ベースラインを把握したか？
次回の第2章では、山田がプロジェクトチャーターを作成し、チームを結成していく様子をお届けします。お楽しみに！
