ーーー
◆構想策定べし・べからず
構想策定についてべし・べからずとしていることを書き残しておく。
1）計画・体制
①計画の前提
・計画は大事だけど計画にこだわりすぎると大事なことを見失う
・1つ1つかかる工数は少なくてもそこそこ期間が必要（1つ1つ熟成が必要）
・構想策定フェーズのプロセスは構築・開発フェーズよりもはるかにシンプルだからこそ、ぶれやすくもある
まず幹のプロセスをおさえると見通しはよくなる
・方法論のアレンジは業務特性・組織特性・PJ特性で説明できるならOK
（工数がないから、XXさんがXXといったからは絶対NG）
②ゴール・CSF・優先度の考え方
・ゴール・CSF・優先度ははじめに決められないのは普通、施策の具体化とあわせてやるのがよい
・決められない状態で決めてくださいってのはなんか嫌だし効率も悪い
（強引に合意形成をつきつけるのはそもそものファシの精神に反する）
・ちなみにCSFは’こんなPJになったらあかん’をだして、’そうならないためには何が必要か’で作るのがわかりやすい
③体制の前提
・構想策定って考えるという料理をするプロセスなので考えられる体制が必須
・人数が少ない方が濃い議論ができる（相互理解・関係構築含めて、濃さが重要なので）
・構想策定なのに下流のように’作業者’をいれてそのレビューをするというやり方は絶対にだめ
（PJとして貴重な思考時間を無駄にし、必要なことをしないまま下流に流すので、まじで罪深い・・・）
④リード力
・このフェーズはプロセスのリード力が必須
・着地までの仮説を複数、先に作ってのぞむこと、それがリード力につながる
・リードすることでプロジェクトは進め方の議論に時間を使わない
・上流では有識者に相談したいことを選別しすぎない方がよい（無知の知、大事）
⑤キャッチアップ
・キャッチアップは業務の幹の理解を優先すること
（PJ内の枝情報がわかっても業務が理解できてないと貢献は難しい）
2）現状調査・分析
①現状調査・分析
・現状調査・分析は課題をだすためのもの＝主要課題・施策まで
・どこまで現状調査・分析を掘り下げるかはそこそこ見えたレベルの課題（仮説）で決める
（自分が知りたいという気持ちだけで聞かないこと）
②ヒアリング
・ヒアリングは聞かれる側の人たち同士の「そういえば、なんでそうしているの？」とか「そうだったの！？」
を引き出せるとナイス（参加者の満足感もあがる）
・ヒアリングはただ聞くだけではなく「一般的にはXXなので、ここは違和感があった」というようなINPUT提供も意識すること（この人たちはただ聞いているだけではないと思ってもらった方がその後の話は早くなる←この信頼がないと’今やっていることは何なのか’とか不信を生むし、その説明・すり合わせに必要以上のコストを使うことになる）
・ヒアリングは1つ1つの情報の正しい理解は必要だけど（適当すぎるとだめだけど）、細かい情報そのものではなく、業務特性・組織特性の粒として昇華させた理解をつむいでいくこと（EAのフレームでいう初めのBA・DA）
③インタビュー
・インタビューとヒアリングは違う
・インタビューは相手の考え・価値観を引き出す、ヒアリングは相手の情報を引き出す
・インタビューはオーナーとの関係構築のためにも早い段階で実施するのがよい
（何かあってこじれてからはやれなくなる）
・インタビューのアジェンダは業務や組織への課題感、PJへの要望が基本
・何もなしに話を聞いた方がよいか、ネタを出して聞いた方がよいか、リーダー同席した方がよいか、コンサルだけで話をした方がよいか、外部・コンサルとどんなコミュニケーションを好むかはきいておいた方が安全
（事前にリーダークラスの人に確認）
・意図的にプロとしての’鋭さ’を見せること（素人と思われたら必要な時に必要な支援がうけられなくなる）
・知ったかぶりは絶対だめ、素直に知らないと言った方がよい（インタビューするような相手はどんなにやわらかめの人でも厳しく人を見抜く）
④現行課題
・現行課題は抽象化のお料理をしてからじゃないと食べてはいけない
（小粒のまま解決策や優先度を議論したり書かせてはいけない）
・抽象化とは具体的なFACTから類推して’誰の何に問題があるか’を言語化すること
（単なる似たもののグルーピングではない）←ここがプロの知識・経験が必要なところ
⑤主要課題・施策
・今できていないこと＝課題ではない
・お客さんが’こうしたい’＝TOBEとしてはいけない
（意図的に発散させるのはよいが、それを整理しただけのものをTOBEとしてはいけない）
・課題とはTOBEに対するGAPである
・とはいえ、いきなりTOBEを描くことは難しい
・なので、まず、課題は業務特性・組織特性・システム特性と照らし合わせてまずいところとする
・抽象化された課題が解決された姿をTOBEのたたき台とするのがよい
・それが本当に目指す姿なのか、違うとしたら今の課題は何かおかしいのではないかっていったりきたりさせること
⑥Before/After
・Before/Afterを絵で書くと現行課題・TOBE、何のために何を変えるのかがすっきりみえてくる
・課題・TOBEは文字だけの表現は限界がある
・言葉のこねくりまわしにはまるのは無駄でしかない
（うまい言葉を探し出したらほんとにまずい状態と自覚するべし）
3）新業務設計
①新業務設計
・施策の大変さ踏まえたロードマップまで
・施策検討はお客さん側の具体的な情報が必要になる
・何をどこまで引き出しておくのかをリードする（全く引き出さない、全部きく、両方違う）
・仮説ベースで範囲・方針を決めるために大事そうな2－3個の論点・確認をもとに浅くたたいて作戦ねる
・聞いとけることは先に聞いとこうというのはまずい（貴重な時間をロスする）
・施策から課題に戻すというが、それは達人の技
・凡人は課題→施策→課題→施策→課題→施策の3巡くらいをいったりきたりさせて質をあげていくのが現実的
②施策検討
・施策検討で施策をちょっと深ぼったり、課題に対する解決策を複数だすことで議論が進むことは多い
・施策検討で本当の課題が明らかになることは多い（なるほど、そうだったのね！と）
・施策検討に入ると、お客さんはスケジュールとか実現性をより強く気にする（当然なこと）
・施策検討はスケジュールや実現性の議論はほどほどに浅く論点たたきながら前に進める必要あり
（全部丁寧に拾ってしまうと浅く叩けないので雑さが必要）
・こんなこと考えないといけないといいう論点の羅列や1つだけの解決策の是非検討では議論は進まない
③集中討議
・集中討議のテーマはここ！ってわかっていても、これが難しい
・議論テーマは自分が思うより10倍強く踏み込むべし
・自分が想像できる（マネジできる）ところまでという前提をおかない方がよい
・チーム内の役割整理といくつかの筋だしをしておくこと
・直前で無理なすり合わせをすると当日も中途半端になる
・自分が思っている以上に掘り下げを優先するべし
・一回発散したらまとめに入りたくなる、でも、それ、まだ早い
・掘り下げずにまとめると納得感は不足する（無理なまとめになる）
・とはいえ、がんばってまとめるべし
・事前に考えていたことにこだわらず、その場で出たことからのまとめが必要
・特にここは、熟練者にでばってもらってよい←この役割分担は重要
4）システム要求定義
①パッケージ開発の要求定義
・パッケージ開発の方針は要求定義で決める
（要件定義が始まってからその議論をすることになったらまずい）
・既存業務がある業務は要注意（全く新規なら新からでよいが）
・業務特性としてみたときの汎用性の高さ、判定が必要
・要件定義をイメージして要求定義をすること
（次フェーズのことだが要件定義）
・設定・検証でつめればよいことは要件定義で詳細をつめない
・結局、ものをみると紙でつめたことは変わる（変わらざるを得ない）
・ものをみて詰める方がはるかに生産性が高いから
・とはいえ、なんでもかんでもアジャイル的でよいわけではない
・根幹はWF・・・システム利用範囲（機能範囲）、組織マスタ・社員区分（肝になるデータ構造）、発令の考え方など
・枝はアジャイル的（前提とかだけつめて後続で詳細つめる）・・・給与計算式、申請画面など
・課題は後から出てくるという前提を許容した方がよい
・A：業務として他の会社でもやっているよね
・パッケージにあわせる・・・苦渋の決断もあるかも（仕方ない）
・パッケージでできないのはおかしいでしょ！代替案教えて！・・・個社課題ではなく製品課題として検討
・B：業務として他の会社ではやっていないし、みなおしできるよね
・業務としてみなおす・あきらめる・外で作る
・Aが8割、Bが2割という見込み（だとしたら前に進める）
5）進捗管理
①進捗管理の難しさ
・このフェーズの進め方については合意を得ることは非常に難しいので、早く進捗を実感してもらう方がよい
・進捗は議論の深さではかることになる
・抽象度の高い検討ほど直線的な議論・確認は難しい
・そのレベルでこれでよいですね（漏れないですね）、はい的な応答はしづらい
・多少回り道感があっても発散・収束のプロセス、いったりきたりは必要
・意図的に’こんなのありえないかも？’というところまでの複数案を出せると健全な発散ができる
・’議論’の状況によるため、計画は結構変わりうる
・よって、セッションスケジュールは変更・調整しやすいフォーマットで管理
②作成物
・作成物は途中の資料、最後にまとめて作ってレビューうけるやり方ではない
・作成物は少ない方がよい（作ることを目的・ゴールにしてはいけない）
・バックオフィス系の業務って実はそんなに無駄なことをしていない可能性が高い
（業務担当者って自分の業務に固執するとか、いろいろ無駄があるでしょって仮説はあってもよいけど、それありきで入るコンサルは甘い）
ーーー
自分的には、