［計画の技術］　構造化する（structure）　～うまく構造化できれば、計画者の意図が計画から浮かび上がる～

私は計画のポイントを「ＯDISQ（オーディスク）」と表現します。

Ｏ　 俯瞰する（overlook）
Ｄ　 決める（determine）
Ｉ　 想像する（imagine）
Ｓ　 構造化する（structure）
Q 　 問い掛ける（query）

今回は「構造化する（structure）」を深堀します。
※ 「俯瞰する（overlook）」「決める（determine）」「想像する（imagine）」はバックナンバーをご覧ください。

計画は実行段階に何度も変更されるものですが、変更の規模が大きいと、その都度、周囲とのタフな調整に見舞われます。この調整が計画者の工数を奪い、精神的な負担にもなります。計画が放置される原因になるばかりか、この経験がもとで計画嫌いになる人もたくさんいます。
では、どうすればいいのでしょうか…

答えは、計画の質を高めることです。計画変更をゼロにすることはできませんが、計画の質が向上すれば計画変更の回数は減り、変更の規模は小さくなるはずです。
計画の質を高める上で特に心がけたいのが網羅性です。ところが、初期段階は情報が少ないため容易ではありません。
そこで大切なのは、論理的に考え、考えた内容を構造化することです。
構造化すれば系列で物事をとらえることができるようになるため要素の抜けや重複に気付き易くなりますし、そこを起点に上位構造や下位構造をイメージできるようにもなります。

計画を構造化するのには、もうひとつ理由があります。
計画は自分ひとりのものではなく、チームのためのものです。計画内容は、自分が理解できていればそれでいいというわけではありません。チームメンバーや関係者が計画を目にしたとき、計画者の意図（＝計画性）を目で追うことができるような計画は秀逸です。
そうありたいなら、計画者は、自分の意図を、誰が見てもわかるように計画に織り込まなければなりません。
ところが、この “わかり易さ” が難題です。漠然と計画していたのではダメで、論理的に考え、構造的に組み立てることが大切です。しかも、できあがった構造はシンプルでなければなりません。

「構造化」と聞いて「自分には無理だ」と腰が引ける方がいらっしゃるかもしれませんが、そんなことはありません。なぜなら、構造化の基本形は3つしかないからです。

［構造化の基本形］
・　ツリー型
・　マトリックス型
・　フロー型

これらの基本形を頭に思い浮かべて「どれに当てはめようか」と考えればいいのです。「どのように構造化しようか」というオープンクエスチョンに答えるのは難しいですが、「どれに当てはまるだろうか」というクローズドクエスチョンで臨めば、恐れるに足りません。

ツリー型では、対象をツリー構造で整理することにより、要素の親子関係や包含関係を分析します。プロジェクトマネジメントで使用するWBS（Work Breakdown Structure）や演繹ツリーがツリー構造の代表例です。
マトリックス型では、対象を2軸の表で整理することにより、要素間の依存関係や類似性を分析します。課題と原因のマトリックスがマトリックス型の代表例です。
そしてフロー型では、時系列や順序をもつ要素間のつながりを示すことで、要素間のつながりを分析します。業務フローがその代表例です。

構造化についてもっと詳しく知りたい方は、ブログ「正解のない問題を解く力」の中で説明していますので、ぜひご覧ください。

ブログ「正解のない問題を解く力」

ところで、計画を構造化するにあたり「大雑把＝シンプルで意図が伝わり易い」と安易に考えてはいけません。大雑把な計画はわかり易くはありますが、計画者が意図を織り込もうとすると、なかなかうまくいきません。計画者の意図は「段取り」や作業の「優先順位」によく表われるのですが、これらは計画の「細部」に当たります。これらが計画上で顔を出す程度の詳細化は必要です。

心がけたいことは他にもあります。
最終成果物としての計画（プロジェクトマネジメントでいえば日程表やタスクネットワーク図、担当者割り当て表など）以外に、計画根拠を構造化して表現しておくのがよいでしょう。これらは、最終成果物よりも雄弁に計画者の意図を語ってくれます。

いろいろと書きましたが、論理的に深く考え、それをシンプルに構造化して表現する技術は、計画者には欠かせません。

★★★　概念化.com を立ち上げました　★★★

　　　　　　　 https://www.gainenka.com/
★★★ 　ぜひ、お立ち寄りください　　★★★