第3章 3.1 ← 3.0 計画の基本
スコープは「やること」より「やらないこと」で決まります
スコープが膨らむことを、日本の現場では「仕様変更」と呼びます。ただ、大きく膨らんだプロジェクトを振り返ると、犯人らしい大きな変更は見つかりません。小さな追加が20回積み重なっただけです。しかも、増やした自覚が誰にもありません。
この記事の要点
- 出てきた要望は4つの箱に振り分けます。今回やる／次期にまわす／今回はやらない／言われていない期待。
- いちばん高くつくのは4つ目です。相手にとって当たり前すぎて、要望としては出てきません。
- 「やらないこと」の一覧を見せると、その4つ目が出てきます。これが最も費用対効果の高い30分です。
- 断ることが目的ではありません。増えたぶんを日程か体制に反映することが目的です。
- 「次期にまわす」は断りではなく置き場所の話です。消すのではなく移す、と伝えてください。
要望は、4つの箱に入ります
プロジェクトが進むと、要望は会議からもメールからも立ち話からも出てきます。ひとつずつ判断していると、その場の空気で決まります。先に箱を決めておくと、判断が速く、そして一貫します。
4つ目の箱が、いちばん高くつきます
3つの箱は、要望として言われた時点で扱えます。厄介なのは4つ目、言われていない期待です。
相手にとっては当たり前すぎて、要望として口に出ません。「もちろん既存の帳票はそのまま出るんですよね」「当然、旧システムのデータは全部移るんですよね」。相手はこれを要望だと思っていないので、要望一覧に入りません。そして受け入れテストで出てきます。
これを引き出す方法はひとつしかありません。こちらから「やらないこと」を見せることです。「今回、過去3年より前のデータは移行しません」と書いて見せる。すると「え、それは入る前提でした」という反応が返ってきます。この反応こそが、4つ目の箱の中身です。
「やらないこと」の書き方
相手が期待していそうなことのうち、今回入らないものを10行ほど並べるだけです。「他拠点への展開は対象外」「スマートフォンからの利用は次期」「既存の帳票レイアウトは変更しない」。書きにくいのは、断っているように感じるからだと思います。実際には逆で、いま書かないと、あとで断ることになります。いま書けば、まだ調整の余地があります。
目的は、断ることではありません
スコープ管理を「要望を断る技術」だと思うと、うまくいきません。相手との関係が悪くなるだけで、結局は押し切られます。
目的は、増えたぶんを見えるようにすることです。要望が来たら、断るのではなく次のように返します。
「入れられます。3人日ぐらいなので、テストの開始が3日後ろにずれます。それでよければ入れましょうか、それとも次期にまわしますか」
この形にすると、判断が相手側に戻ります。相手は納期も気にしているので、多くの場合その場で「じゃあ次期で」となります。断ったのではなく、選んでもらった形です。QCDの話をここで使うと、話が早く終わります。
逆にやってはいけないのが、黙って受けることです。「それくらいなら」を20回やると、工数は1.5倍になっています。そして最後に遅れたとき、増えた記録がどこにもないので、遅れの理由を説明できません。
「次期にまわす」は、消すことではありません
次期にまわすと言ったきり、どこにも記録されないケースが非常に多くあります。相手から見ると、それは「なかったことにされた」のと同じです。次回から要望を出してくれなくなり、代わりに直前に言ってくるようになります。
だから、置き場所を決めて、そこに移してください。「次期候補」という一覧をWikiに作り、日付と要望内容と誰が言ったかを書いて、相手にも見える状態にする。これだけで印象がまったく変わります。「消した」ではなく「移した」と言えるからです。
そして実際に、次のプロジェクトの立ち上げ時にその一覧を開いてください。読まれない一覧は、結局のところ消したのと同じです。
増えていることに、気づく仕組み
スコープが少しずつ増えるのは、記録がないからです。増えた記録があれば、増えていることに気づけます。
実務的に効くのは、週報や定例で「今週入った要望」を1行だけ書くことです。件数だけでも構いません。「今週の追加要望：3件、うち今回対応2件」。これを4週続けると、追加が8件になっていることが誰の目にも見えます。誰も責めていないのに、そこから先の追加は自然に減ります。
見えていないから増えるのであって、悪意があって増やしている人はほとんどいません。
ABではこう見えます
AB Projectsでは、「やらないこと」と「次期候補」の一覧を、プロジェクトWikiに2ページ持つのが実用的です。要望が出たらどちらかに追記し、今回やるものだけをタスクとして登録します。この分け方をしておくと、タスク一覧が今回の作業だけで保たれます。
追加でタスクを作るときは、作成日が残ります。あとから「いつ増えたのか」を並べれば、増え方が自分の目にも見えます。感覚ではなく記録で話せると、日程の再交渉がずっと通りやすくなります。
このページで使った言葉
- スコープ
- 今回やること・やらないことの範囲です。文書にしたものを作業範囲記述書（SOW）と呼ぶこともあります。くわしく →
- 仕様変更
- 決まっていた内容を変えることです。日常会話ではこう呼ばれ、多くのスコープ争いの中心にある言葉です。くわしく →
- 要件定義
- 何をつくるのか、どこまでやるのかを決めて文書にする工程です。ここでの曖昧さは必ず後工程で費用になります。くわしく →
- QCD
- 品質・コスト・納期の頭文字です。範囲を増やすなら、どれかが動きます。要望を返すときの共通語になります。くわしく →
- 成果物
- 相手が受け取れる形になった結果です。スコープは、作業ではなく成果物の一覧で書くほうが揉めません。くわしく →
- 議事録
- 打ち合わせの記録ですが、日本の実務では合意の範囲を確定する文書として機能します。くわしく →
あわせて読みたい
6.2 課題と変更の管理
決まったあとに変わってしまったものの、扱い方。
3.2 スケジュールの立て方
増えたぶんを、日程にどう反映するか。
2.1 立ち上げ
「やらないこと」を最初に書いておく5つの欄。