週末はいい天気に恵まれた北摂地方です。日中は暑くなりますが、朝晩は肌寒いほどで快適な気候でした。まるでカリフォルニアにいる感じでした。
今日の南関東地方も爽やかでいい天気となりました。気持ちがいいです。
プロジェクトの作業を構造化するメリットについて考えています。
構造化することでプロジェクトの全体像をモデル化（抽象化）し、タスクの見落としや漏れを防ぐことができるようになると考えました。なぜそうなるのか、もう少し掘り下げてみましょう。
そのためにはまず、作業基準でプロジェクトのタスクを考えたときの欠点を考える必要があります。
ここでもまたチャーハンを作るプロジェクトの例で考えてみることにしましょう。
キットPMは子供の頃初めて、自分で料理を作ったときのことを覚えています。家にあったなんだかおいしそうな料理が載ったレシピ本を見て、「これを食べたい！」と思ったら矢も楯もたまらず今にして思うと無謀な挑戦をしてしまいました。
料理の基本も知らずにやるわけですから無謀も無謀なわけですが、それよりもまずレシピの読み方を理解できていなかったという致命的な問題がありました。何を言っているかというと、下ごしらえという概念を理解していなかったのです。
本には当然ですが、料理を作る手順が書いてあります。ですがその前に材料をきったり、調味料を用意したりという準備作業がありますが、それを完全に無視していきなり作り始めてしまいました。
そのためレシピ本の手順通りに作り始めました。①プライパンに油をひいて②そこに溶き卵を投入して（フライパンを熱したまま卵を取りにいって、溶き卵をつくる）③すかさず冷やご飯を入れる（炊飯器までご飯をとりに行く）④予めみじん切りにしたハムとネギを入れ（ネギとハムを冷蔵庫から出して切り始める）という、泥縄テクニックを駆使して料理しようとしたのですが、ネギを投入する頃にはご飯は黒焦げということになりました。
今にして思うと相当”アホ”なわけですが、そのときは一生懸命で疑問を感じませんでした。
ここで言いたいのは、プロジェクトの実行においてもWBSに抜け漏れがあったとき、プロジェクトはたちまち危機に陥るわけですが、このとき実はご紹介した私の失敗例（子供の頃です！）にあったことと同じことが起きているということです。
これはプロジェクト作業全体の構造が、WBSに表現できていないために起きていることになります。
作業基準でWBSを考えると、どうしても思考がリニア（時間的に直線）になってしまいます。直線的であるということは物事を多方面から立体的に考えることの妨げにあります。
プロジェクトのような複雑な営みを直線的にとら得るのではなく、立体的にもしくは俯瞰的に捉えないと、どうしても構成要素の見落としが発生する可能性が高くなります。
作業基準で作業の流れにだけ捕われると、WBSが不完全になる危険性が高くなるということがお分かりいただけたでしょうか。
さて、次回は成果物基準の何がいいのかについて考えていくことにします。