ベストプラクティスはテラーリングして使うもの

KKD(経験・勘・度胸)とベストプラクティス
Sierがプロジェクトマネジメントにベストプラクティスを導入したがるのは、組織が大きくなり、エンジニアをOJTで経験を積ませるだけでは、抱えるプロジェクトにアサインするプロジェクトマネージャ充足できなくなったことが上げられる。また、組織がエンジニアをOTJというエンジニア本人の良心に丸投げして経験だけで育成するには、個のエンジニアのタレントに大部分を依存することから、組織が期待するPM象に到達しないことも上げられる。
それらがSIerのマネジメントの永年の課題として根底にあって、思うような育成が進まないところに、昨今のプロジェクトの短納期化と低コスト化が複雑に絡みつつ問題を難しくしているように見える。

その課題解決にPMBOK、CMMI、RUPやアジャイルなどのプロジェクト管理のベストプラクティスが出てくると、あたかもソレを導入したらすべてが解決することを願い、一斉に導入しようとして現場を混乱させた上で頓挫するか、導入しても現場の負荷が増えるだけになってしまう。

実践だけでは偏った食生活と同じ
経験・勘・度胸は、個々のエンジニアのキャリアの上に立っている家であって、その上に組織化したSIerが組織として寄りかかるには小さすぎる。
一人ひとりのエンジニアのキャリアはそれこそ千差万別でその組織内でも所属が違えば同じプロジェクトマネージャであっても同じものは何一つない訳で、一人ひとりのプロジェクトマネージャの経験から導き出されるhow toや判断基準になると言わずもがな、である。

第三者の視点で冷静に一人ひとりのプロジェクトマネージャのキャリアをサーベイすれば、そのときの組織の都合による恣意的なアサインにより斑になるものだ。視覚的に実感するためにプロジェクトマネージャのスキルを表すレーダーチャートにキャリアから学んだ経験値を書き込んでみれば、綺麗に円を描けなくても仕方がない。
例え、綺麗に掛けたとしても、経験値が不足しているスキルは、そのエンジニアが自らOffJTで充足しているに過ぎない。

これはまるで、食生活が偏食で栄養状態が偏っているのと同じなのである。健康的ではないけれど、意識的に自分で経験値が足らないところを補うことをしなければ、その内、大病(デスマ)を冒す危険性をはらんでいることに他ならないのではないだろうか、と思うのである。

ベストプラクティスはそのまま導入できない
とはいえ、自組織の家風なり文化なりを見返りもせず、他所で使っている「ベストプラクティスが良いらしい」とか、盲目的に導入しようすれば、それは痛い目を見るのは火を見るより明らかなものだ。

自分自身が何かライフハックのような後々楽チンになるちょっとした伊東家の食卓的なネタを実践しようとして、そのままやって上手く行くことはどれだけあるのだろうかを考えたことがあるだろうか。日々、はてブされるライフハックに“いいね！”をつけてやってみたとして、そのまま上手く行くことなんでいくらあるだろうか。

コト細かく手順になっているものは、そのまま導入できるかもしれないが、それは単なる作業だからであって、プロジェクトマネジメントのようなベストプラクティスとしてなるようなものではない。

ベストプラクティスは、例えばPMBOKのようなものは、建設やプラントエンジニアリング、医薬開発、テレコミュニケーションなど多くの産業の知を蒸留して残ったものであって、概念そのもので、言い換えればフレームワークに他ならない。そこには、how toはない。

ならば、「他社の成功事例を」と言いたくなるところだけれど、それでも上手く行かない。なぜならば、その成功事例には、他社の家風や文化を考慮したプロセス設計が成されており、他社の文化を含んだまま何も考えずに自組織に取り込めば自組織の文化という抗体が働き、抵抗するである。

如何にテラーリングするか
よって、ベストプラクティスを導入するのであれば、自組織の文化を知りつつ、

“ベストプラクティスから何を取り入れ何を取り入れないか”

をハッキリ軸を据えてことをはじめるようにしたほうが良い。それは、ベストプラクティスを導入しようとする組織が何が必要で何が必要でないかをテラーリングしていることに他ならず、それをしないのであれば、現場に本来であれば取り入れなくて良いムダな作業をわざわざコストを掛けて取り入れていることに他ならない。

経験と知とテラーリングのバランスがタイセツです。