「経験」だけでは対処できない

昔、プロジェクトの事後分析を初めて行ったとき、私は PMBOK を参考にしました。



つまり、自分以外の（特に先人たちの）知識に頼ったわけです。

人間一人の経験値は浅い

なぜ、PMBOK を勉強したかと言えば、私一人の経験値では対処できないからです。

ソフトウェア開発に 17年関わってきましたが（幅広く関わってきた自負はあるのですが）
プロジェクト数で言えば、大小合わせても 10個ちょっとです。

これだけでは、普遍的な対処方法を捻り出すことはできません。
自分の知識だけで判断するというのは、傲慢というものです。

新しい技術や方法論に対応できない

ソフトウェア以外にも、進化の早い業界は多いと思いますが、経験だけに頼っていると、
当然、新しい技術や開発手法、ビジネスモデルなどに対応できません。

特に技術分野では、新しいことに対応するためには事前の投資が欠かせません。
（ここでいう投資は、設備・人材・技術投資全般です）

特に、マネージャが新しい知識を持っておらず、
経験だけに頼っている組織は、投資が遅れ、
生産性が伸び悩んだり、機会損失を生んだりします。

規模の拡大に失敗する

前述の「新しい開発手法に対応できない」という部分に被るのですが、
開発規模が拡大すると、自社のリソースだけでは対応できなくなるので
以下のような対応を行う必要があります。

• 外部の人材や技術を活用する
• ツールを導入し、自働化等の効率化を図る

このとき、経験のみに頼った開発手法に拘っていると、標準化できる部分が減ってしまいます。
また、外部の企業と協業するにしても、意思疎通に余計な時間がかかってしまいます。

「知識」を上手く使えない

とはいえ、確かに知識偏重というのも良くありません。

知識（≒理論）は、万能ではなく、特に開発手法などの工学の分野では、
現場に適応できないものも多いのです。

前述の PMBOK も、以下のことを踏まえないことによる失敗事例をよく聞きます。

How ではなく Know	知識体系であるため「経験」の代替手段になるわけではない。 問題解決のための経験は、別に積む必要がある。
Rule ではなく Guide	あくまで指針であり、絶対的な規則ではない。 現場の現実を無視せず、柔軟に適応させていく必要がある。
広範囲な知見である	あらゆるプロジェクトに対応するための知識体系であるため、 各現場に合わせて、必要な部分のみ参照すべき。

ところが、どっこい。
経験を積んだベテランも、この罠に陥る危険があります。

「知識」を使う経験が不足しているマネージャ

以前、私が働いていた職場で、標準化された手法を現場に持ち込もうとすると


と頑なに反発するマネージャがいました。

現場のエンジニアは、知識を正しく理解して、上手く運用できる環境だったのですが、
結局、開発プロジェクトは同じ失敗繰り返す羽目になりました。

すると、さすがにマズイと思ったのか、マネージャが勉強を始めました。


ところが、どっこい。
このマネージャは、都合のいい知識だけを掻い摘んだり、独自の解釈をして、
自分のやり方を正当化するために知識を利用してしまったのです。

そして、現場の改善は行われませんでした。


さて・・・
なぜ、このマネージャは、プロジェクト開始前に「知識」の利用に反対したのでしょう？

答え：自分が「知識」を正しく使えない人間だったから

だから、このマネージャは、現場のエンジニアたちのことも信用できなかったわけです。
こうなると、このマネージャに退いてもらわないと、現場の改善は難しくなります。

今日の駄文

• 人間一人の経験値で解決できる問題は、限られている。
• 「知識」の利用を否定する人は、「知識」を上手く使えない可能性がある。
• 「知識と経験」は、ふたつ揃って、初めて役に立つ。

マネージャが、自分のために「知識」を歪曲して利用してしまった例は、
実は、以前の記事でも紹介したことがあります。

わりとよくある例なわけです。
そして、以下のような性質もあるので難しいのです。

• 小規模開発での知識を、そのまま大規模開発に適用すると失敗する
• 開発での知識を、そのまま企業経営に適用すると失敗する
• 企業経営での知識を、そのまま国家経済に適用すると失敗する

適切な知識を選び、適切な領域に適用する、というのは難しいのです。
日本経済の停滞も、実はこれが一因だったりします。

この辺の話は調べると面白いのですが、話が大きくなりすぎるので、また今度。