仕事術、3つめの神器を求めて③　〜WBSについての補足

いつまで経っても本題に入れません。前回、念のために、既選の2つについて書いたつもりだったのですが、

WBSについて、ある意味で当たり前過ぎて言及し忘れている観点があることをに気がつきました。

WBSはとても重要で、応用が効く技法だし、その技法自体の特性を分析することでも得るものが大きい、という信念自体については書いたつもりなのですが、そもそも私がその話をしたくなったのは、WBSが過小評価されていると感じているからだと思います。では、何故そう感じるのか。

もちろんプロジェクトの現場で事務的に取り扱われているところを見てきたからということもあります。しかし、それ以上にその印象を強めているのは、アジャイル方法論の台頭によるものが大きいと思います。

アジャイル方法論について詳しく語る資格が自分にあるとは思えないので、その説明もせずに浅く進めてしまいますが、大前提としていわゆるアジャイル手法は基本的に皆素晴らしいものだと考えています。（玉石混淆としておくのが順当な話の進め方なのかもしれませんが、細かく非を出せる知見が自分にある気がしないので）

突然の閑話休題

例によってここでまた話が脇道にそれます。IT分野での起業を考えた20年前、いかに「ミッションクリティカル」と距離を取るかが勝負だな、と考えました。当時のエンタープライズITの世界はオープン化の動きに目処が立ち、ミッションクリティカルなニーズに対応できると標榜するテクノロジーはその火中の栗を拾う姿勢によって高付加価値を認められるという構造がかなりはっきりと見て取れる状況でした。しかし自分は技術の側の人間でいたかったので、市場が見てるリスクよりも自分の見立てによるリスクが低く、また自分が参画することでさらにその差を広げることができる領域に注力すべきだと考えました。当時のIT業界のトレンドは、技術レイヤーでは後のIaaSからはじまるクラウドブームの準備として分散処理と仮想化が流行しはじめていましたが、ビジネスレイヤーではERP統合による中央集権への志向が突出していたと思います。しかし、すべてを一箇所にまとめることによってリスクも問題も肥大化してコントロールが難しくなるわけで、自分が起業を通じてリスクの担い手にまわると考えた時には、一概にその方向に全振りはしたくなった。問題は分割して統治した方がよいし、分割してもとっちらからないようにするためにも技術の力が活用できる可能性があるとも考えたからです。実際、その後に覇権をとったITトレンドのいくつかが（DevOpsとかCIとかある種のアジャイル方法論とか）そのような方向性に合致するものに見えました。

話を戻して

今後、このシリーズでは多分、OODAを推すためにPDCAを否定する語り口が気に入らないとか、デザイン思考によってロジカルシンキングを克服するみたいな話はおかしいとか、って話を繰り返すことになると思うんですが、ここでは別にアジャイルとウォーターフォールを比較してウォーターフォールにも良いところがあるとか、使い分けが大事みたいなふんわりした結論などを言いたいわけではありません。ただ、WBSに関してはアジャイルプロジェクトの比率が増すにつれてそのプレゼンスが低下しているはずだ、というがまずあります。もちろんハイレベルな計画のために利用するとか、修正前提での計画作りのためり利用するケースはあります。その意味では、完全に無用のものと扱われているわけではありませんが、流儀の異なるマネジメントスタイルとの摺り合わせのためにアリバイ的にWBSを作成する、という話もあったりして、邪魔者扱いの憂き目にあうケースもあるわけです。だからこそ、管理ではな計画の手法としての有用性を改めて語りたかった、と。

最後に

アジャイル以後、WBSについての結構重要な指摘として、それがフィーチャ（実現したいこと）ではなく「作業」に着目した手法である、ということが言われています。これは重要な指摘だと思います。必要な作業が漏れない様に計画を組み立てることについては有用だけれども、管理の主体が作業になってしまうことには弊害もありそうです。それも含めて、計画行為そのもののガイドとしてのWBSにはまだまだ光を当てる価値があると思ったわけでした。