暗黙知とプロジェクトマネジメント

知識には2種類あることを知っていますか?「暗黙知」と「形式知」です。

「暗黙知」は最近よく耳にする言葉ですね。プロジェクトを推進する上で困ることになるのが、この2つの言葉で表される内容の取扱いの仕方です。

「暗黙知を0%にできればプロジェクトは100%成功!」となるのですが、残念ながら、それはできない相談です。

いかに、苦しめられるかを、ちょっと書いていきますのでお付き合いください。

「形式知」と「暗黙知」の定義

まずは、「形式知」と「暗黙知」についての定義を確認しましょう。PMBOKガイドから引用します。

形式知

単語、絵、数字を使って容易に文書化できる知識

暗黙知

信条、洞察、経験、「ノウハウ」など、個人的で表現するのが困難な知識

「形式知」と「暗黙知」をマネジメント?

両方の知識をマネジメントすることはできない

PMBOKガイド第6版では、両方の知識を「知識のマネジメント」として取り上げています。理想はそうかもしれませんが、管理人の考えでは、実践は不可能と考えています。

暗黙知の例

なぜなら、暗黙知は表に出てこないためです。

よくある例ですが、業務分析のヒアリングをしていても、その組織が「当り前」として行っていることは、話として出てこない、ということです。

確かに、管理人もとあるプロジェクトの要件定義で業務ヒアリングをした結果をレビューしていたのですが、どうしても伝票がつながらない箇所があり、再度現場に確認しました。

すると「この伝票は複写をしてxx部門と○○部門に送っている」と平然と答えました。文化としてそのようなことをしているようです。

「送付している意味は何ですか?」と聞いても「昔から」としか答えてもらえません。

このように、その人しかわからないこと、意味や用途がわからず続けているものなど、至る所に「暗黙知」と呼べるものが転がっています。

形式知の例

また、形式知として表現されている場合でも、そのまま鵜呑みにはできません。

例えば、現行システムの業務フローは、一見「形式知」としては成り立っているように見えますが、内容をきちんと評価しないと、実は違っていることもあるため危険です。

また、形式知として表されている内容には、実は「暗黙知が含まれていない」という可能性もあります。

自分も同じ

そういうみなさん自身も、暗黙知を相当抱えているのではないですか? 自分しかわからない手順だったり、知識だったり、いろいろあるでしょう。

個人的なことならば、それでもよいのですが、いざ仕事、組織で動くと考えると、それは望ましいことではありません。

数ある暗黙知をみんなで出し合えば、組織としては非常に強力になると思います。誰でもその仕事ができるようになり、属人性が排除されるため、リスクが減りますよね。

自分の存在を守るため?

個人的には、自分の存在が危うくなるため、自分ノウハウは出したくないという気持ちも働きます。

それが、システム構築時に噴出してくるのです。頭では新システムにして業務効率を図りたいのですが、自分で持っている暗黙知を吐き出すと、自分が不要になるのではないか?と思われてしまうのです。

そのまま、暗黙知が引き出せぬままシステムを構築すると、結果として業務が回らないシステムとなってしまいます。

利用部門のテスト時に、その暗黙知を保持した担当者から「これでは業務が回らない」などということになってしまうのです。

聞き出せないのはSEの問題?

われわれベンダー側としては「聞き出せなかったのだからしょうがない」と開き直りたいのは山々です。

しかし、そうはみてくれないのが世の中です。ヒアリングがへたくそなSEやプロジェクトマネージャのスキル不足と、とらえられていまいます。

暗黙知を引き出すためには?

では、いかにして暗黙知を引き出していくか、これはすぐに効果的な対策がないのが実情です。

業務責任者レベルのヒアリングでは、概要レベルの荒い業務内容になりがちです。

現場担当レベルだと、逆に細かすぎて全体が見えてこない(なぜか自分はこんなに大変なんだという苦労自慢を聞かされることが多いのですが)ということになりかねません。

そこで、いくつかの手を管理人は打つことがあります。

PMBOKでもさまざまなツールと技法が取り上げられていますが、現在の管理人のスキルでは、いまいち使いこなせそうもないので今回は取り上げません。

みなさんももっと効率的な策を実施しているかもしれませんね。

内部監査資料を見せてもらう

他人のふんどしを借りるようで、あまりやりたくないのですが、内部監査チームを持っている場合、監査用の業務フローを作成しています。

そこでは業務手順のすべてが網羅されていますので、これを見せてもらいます。

内容をよく理解したうえで、業務ヒアリングができれば、一からヒアリングしてくよりも効率的でモレも少なくなります。

業務リーダクラスをヒアリング担当者にしてもらう

業務ヒアリングの対象者が、業務責任者や現場担当レベルの方であれば、業務リーダクラスの方に変えてもらうことを依頼したりします。

結果としてヒアリングのやり直しになるなら、この方が得策だったりします。業務リーダークラスの方は、現場れべるのかたよりは全体を見渡しているし業務のつながりも意識されています。

また業務責任者の方よりも粒度が小さい仕事のレベルも把握されているので、必要十分条件を満たしていると思います。しかし、それでも暗黙知は出てこない場合もあります

デシジョンテーブル化

最後の手段は、時間がかかるのですが、とにかく現行システムで、区分・コードと名のつくものを片っ端から洗い出し、組み合わせを作成します。

現行システムのコード区分を洗い出し、デシジョンテーブル化して、ひとつひとつパターンをつぶしていきます。

そして、その内容に該当する業務手順を聞き出していきます。半分くらいの組み合わせは実際には存在していなかったりしますが、それはそれでそういうパターンはないと確認することもでき一石二鳥です。

ただし、ベンダー側も顧客も体力と時間が必要ですが、どこかのタイミングで行うことは必須だと考えています。

まとめ

いろいろと手を打ってはいますが、結局のところ暗黙知を100%引き出すことはできませんし、その労力は無駄になるでしょう。

しかし、極力根幹につながるところは力を入れてつぶしてください。枝葉については、最悪、システムテスト(総合テスト)段階で出てもよいというスタンスで望みましょう。

その際、ただ漫然と出てくるのを待つのではなく、リスク管理の一環として、コンティンジェンシー予備を十分に確保しておく手を打つことが重要です。

コンティンジェンシー予備とは「プロジェクトマネージャの裁量で使用できるバッファ(特にコスト)」のことです。

スケジュールにもあらかじめその対策分のバッファも組み込んで置けると余裕が出てきます。

 

PM

Posted by wpmaster