１．お話の概要

これは私がコンサル時代に実体験から学んだお話し。
クライアントに「データ移行計画をたててー、まずは移行方針からもってきてね」といわれサクッとつくってみると、先輩やクライアントからダメ出しをうけました。「方針」ってわかるようでわからなくてけっこうはまりました。
方針は数行レベルでpptに表現されてて、数分でできちゃうみたいに思いがちですが、けっこう奥が深かった。

２．私がやったこと

移行方針計画の作成自体が初めてだったので私がやったことは、以下2点です

ネットで移行計画とか移行方針とか調べる
社内の他PJでの移行計画書を拝借する

上記を調べると、移行方針ってのは以下のようなことをお題目として書きましょうと出てくる。

移行対象（スコープ）
移行方法（一括移行か段階移行かとか、手動かツール作るのかとか）
移行スケジュール
移行体制

なるほどーと思って私がやったことは上記のお題目に対する穴埋め。専門コンサルじゃない人がやりがち。

３．ダメ出し

そして以下のようなダメ出しを受けました。

移行対象にXXっていうデータを移行しますとしか書いてないけど、そんなの当たり前じゃん。逆にどういうのが移行対象外なのか？
移行方法が一括移行ってこの規模なら当たり前じゃん。。。
↓
要するに「教科書に載ってるようなこと拾って、穴埋めしただけで、全然考えてないじゃん」って言われた感じです。

4．学んだこと。「方針」ってどう考えて何を書くんだろう。

そもそも方針って何のためにあるんでしょうか。
私は方針とは実際にもっと具体的な方法を考えるときの指針であり、要するに「具体的な方法論に落とし込むときに迷わないようにするための」だと考えます。
だからあとでやり方に迷ったり、揉めそうなことを方針に書くのです。逆にいうとそんなの当たり前じゃんみたいなことは方針にはいらないのです。

例えば上記でいうと移行スコープで後で迷ったり揉めたりするのは、過去分のデータって大量にあるし移行するにはツールとか作る必要があってコストかかるけど移行するか？とかだったりするので、何を移行しないのかという対象外にする線引きがとても重要だったりします。
あと一括移行か段階移行かなんてある程度システム規模が大きくないと迷わないことで、当時のPJはシステム規模が大きくなかったため、一括移行ってことで誰も迷わないんですよね。

ということで、”方針”って一番最初の方に検討することなんですけど、プロジェクトとかシステムの特徴捉えつつ、最後の最後の方まで見通し作らないといけないので、奥が深いなあ（難しいなあ）というお話でした。

ちなみにそんなの当たり前じゃんという品質のことを当たり前品質と呼び、狩野モデルというモデルの中で説明されているのでご参考までに。
参考：https://ja.wikipedia.org/wiki/%E7%8B%A9%E9%87%8E%E3%83%A2%E3%83%87%E3%83%AB