仕事術、3つめの神器を求めて②　〜複式簿記とWBS

中年コンサルタントが考える仕事術、的な話の続き。

複式簿記とWBSは当確として、3つめを何にしようかという探索を行うつもりなんですが、今回はとりあえず当確のものについて簡単に触れておきたいと思います。特にWBS。

複式簿記はまあ常識ってことでいいと思うんですよね。単式ではなく複式にしたことで生まれる表現能力には、若者なりに刺激を受けるところがあると思います。勘定科目にカスタマイズ性というか、裁量の余地があり得るとか、決算という手続きを経て「一定期間を区切った」結論というかレポートが生成可能であることとか、そこで生み出された数字に潜む恣意性とか、そこと税を結びつけることの必要悪っぽい妥当性とか、中高生のうちに触れておいて損はないんじゃないでしょうか（と思って自分の子供にも勧めてみました）。完全に話は脱線しますが、もし社会人として他人の教養を評価するような場面があったとすると、そこで求められるのはそれぞれのジャンルの高校レベルの知識なのではないか（それを超えるのは専門性の評価になる）、と思うので、複式簿記はそのレベルの知識とするのが本来は妥当な位置なのではないか、と。

より思い入れがあるのはWBSです。Work Breakdown Structure。プロジェクト管理ツールのガントチャートとかで表現されているあれです。（「ワールドビジネスサテライトではありません」というクリシエを何度目や耳にしたことか）

WBSとはなにか

手元のデジタル大辞泉では「プロジェクト管理の計画手法の一つ。プロジェクトをワークパッケージという個々の作業要素に分割し、階層的な構造に配して管理する。」とされています。進捗管理ではなく計画のツールってことなんですよね。これはとても重要な点だと思いますが、多くの人が最初にこのツールに触れるのは進捗報告の場面ですし、自分で作る立ち場ではないでしょうから、進捗管理のものだと考えている人も少なくないのではないかと思います。

プロジェクトの最終成果物というのは定義からいってユニークなものですから、それをどのように生み出すのかということについても厳密な意味での過去事例は存在しません。参考、お手本になるものはありえますが、そのプロジェクトの成果物はそのプロジェクトによって初めて作られるものです。当然それを作業要素に分解した設計図もユニークなものになります。この設計図を引くことが計画に該当するわけです。

お手本にあたるものをコンサルティングファームなどでは「方法論（メソドロジー）」と呼んでいたりもします。これはちょっと直観的な名前ではない気がするのですが、方法論というとあるタイプのプロジェクトを遂行するためのWBSのテンプレートと、その構成要素であるワークパッケージ毎に作るべき中間成果物（プロジェクト全体の最終成果物をプロダクトと呼ぶのにたいしてデリバラブルと呼ばれたりします。が、この辺りの用語法には流派とか方言が多々あるので、そんな風に言ってる人もいる、くらいの認識で十分だと思います）のテンプレートをまとめたものを意味します。

WBS自体がプロジェクトの成果物を生み出すための設計図であり（一度しか使わないとは言え）雛形であることを考えると、方法論は雛形の雛形になるわけです。そういう抽象度が少し高いレベルで、「果たすべき成果」に向かって作業の計画を組み立てていきます。

WBSの何がすごいのか

計画に階層構造（部分と全体の関係の連鎖）を持ち込んだことが革命的であったと思います。（簿記で言えば単式ではなく複式にしたようなインパクト）

何か計画を立てる必要が生じたとして、自然な発想は作業を一次元的に並べる、ということになるはずです。最初に何をして、次に何をして、……、最後にこれをすると完成！　という形です。もちろんWBSを作る時にも、各ワークパッケージの順番は重要です。部品がなければ組み立てはできませんし、判断材料が揃わなければ判断はできません。ゴール側から逆算して、これをやるためには何が必要か、という形で遡って必要なタスクを洗い出すような作業を行っていきます。ただこのアプローチだと、各作業（ワークパッケージ）の前提となるインプットが複数必要になると、そのインプットを目的とした前段のワークパッケージが複数できてしまい、すぐに収拾がつかなくなってしまいます。そこで、成果物自体を階層的に分解していき、その部分の中だけで一次元的な順番を考える、という方法で整理していくというアプローチが活きてくるわけです。しかも、この方法だと、本当に下層の要素をすべて足し合わせれば上層の要素が完成するのか、という部分と全体の関係性によるチェックが効き、ヌケモレの防止も可能になります。

プロジェクト計画のためのアウトラインプロセッサ

長い文章を書くときにはまず目次から考える、というテクニックがあります。それを突き詰めていった執筆方法と、それを支援するツールとして「アウトラインプロセッサ」と呼ばれるジャンルのソフトウェアもあります。専用のツールでなくてもWordでも基本的には同等のことができます。これも階層構造で部分と全体の関係を整理することで迷子になることを防ぐ手法です。WBSによる計画策定は、アウトラインプロセッサを使った執筆に非常に近い営みであると言えます。

おまけ

どこで覚えたのか記憶が定かでないのですが、私がWBSを作る時に意識していることに「各中間成果物は後続作業で発生するリスクに対するコントロール（統制施策）であるべきである」というものがあります。先ほど、ゴール側から逆算して先行タスクの成果物を考える、という話を書きましたが、組み立て作業に対する個々の部品や判断タスクに対する判断材料のような「原理的に必須な前提条件」になるようなもの以外にも、事前に考えておくべきこと、出しておくべき結論があることは多いです。これはルーチンワークよりも不確実性をより多く抱えているという意味でリスクが高いプロジェクトワークには本来的に備わっている性質であると思います。いわゆるリスクマネジメントと呼ばれる領域においても、その最も中心的な取り組みがブレインストーミング的なその場での具体的なアイディア出しだったりするわけですが、不確実性への立ち向かい方としてこれだけやっておけば完璧というのは原理的にありえないということでしょう。その意味で、各ワークパッケージを考える際に、前提として何がなければ着手できないか、だけでなく、その段階でどのような問題が発生しそうか、それを抑えるためにはどのようなものがあると有り難いか、という発想が求められます。WBSや、それを抽象化して雛形にし方法論としてまとめ様とする人には、こうしたリスク・コントロールについても考慮が必要だと思います。