ハウツーとノウハウ
＜初めに＞
ハウツーとノウハウと題して、プロジェクトの中でハウツーとノウハウの位置づけまで展開しますね。
ハウツーとノウハウと言っても、いろいろな意味に捉えられるので、まず、ここで言うハウツーとノウハウとは何を意味しているかというところから始めます。
<ハウツー＞
ハウツーは「やり方」や「技術」と言われますが、「技術」というと範囲が広いので、ここでは「やり方」とします。「やり方」は、「同じ環境下」で誰が何度同じ「やり方」をしても、同じ結果が得られるから「やり方」として成立します。
「同じ環境下」で誰が何度同じ「やり方」をしても、同じ結果が得られるので科学的である言えます。また、同じ結果が得られる「やり方」はアルゴリズムが確定していることになります。アルゴリズムが確定しているということはドキュメント化＝メソッド化が可能であり、科学的でありアルゴリズムが確定しているものはAIに委ねることが可能であるとなります。ちなみにドキュメント化＝メソッド 化が可能ということは、教育で展開することができます。車の基本的な操作方法を教習所内で教えることができるのは、車の基本的な操作方法が「やり方」だからです。
このような「やり方」をハウツーとして定義します。
＜ノウハウ＞
ハウツーに対してノウハウは「技術」や「コツ」といわれます。他には「知識」ともいわれています。ハウツーと同じで「技術」というというと範囲が広いので、ここでは「コツ」とします。「知識」は、どう扱うのかとなりますが、これは「環境の状態を判断する能力」とします。なので、ノウハウは、「多様な環境」下で「環境の状態を判断する能力」を用いて展開する能力がノウハウ使用の前提となります。それに加えて、その環境下で最適なハウツーをチョイスして用いることができる能力＝「コツ」をつかむことができる、この「知識」と「コツ」の連携をノウハウとして定義します。
＜ハウツーとノウハウの関係の実際＞
車の基本的な操作方法はハウツーなので教習所内で教えることができるが故に、これらはハウツー＝メソッドに基づく教習となりますが、「多様な環境」に直面する実際の運転のためには、これに加えて、「多様な環境」での適応を「知識」として蓄え、その環境下で最適なハウツーをチョイスして用いる能力＝「コツ」を得るために、教習所内以外に路上での教習が必要になるということになります。
＜ノウハウのハウツー化＞
ちなみに、「ノウハウをドキュメント化する」という言葉がありますが、ここの定義をもちいれば、それはノウハウのハウツー化ということになります。
＜ハウツーとノウハウの違いの例＞
ハウツーとノウハウの違いを理解していただくために、もうひとつの簡単な例を記載します。
釣りで考えた場合、目的の魚を釣るためには仕掛けが必要になります。仕掛けがあれば効率的に目的の魚を釣ることができます。ただし、仕掛けが効力を持つ環境下であればという前提付きになりますので、仕掛けはハウツーとなります。
夜、沖から岸に来る魚を釣る、とします。宵のうちは遠投で仕掛けを投げ込み、夜が更ければ岸近くに仕掛けをたらすとなります。これは「環境の状態を判断する能力」＝「知識」が無いと対応できないとなります。
投げ込みとたらすでは、竿の引き方もしゃくりも変わります。この各々の操作に対するハウツーを選ぶ能力が「コツ」になります。実はこれ以外に汐の流れや、使っている竿のしなり具合でも、操作が変わります。汐の流れも竿のしなり具合もすべて環境＝知識であって、これに合わせてハウツーをチョイスして用いる能力＝「コツ」が載る一連の判断と操作がノウハウとなることになります。
ただ、魚を釣るためには基本的なハウツーである仕掛けが無いと、ノウハウだけでは魚は釣れない。なので、ハウツーが存在して、その上にノウハウが展開されるとなり、双方を知っていて、かつ、運用できることによって、事が成り立つとなります。
＜プロジェクトでのWBSを用いてのハウツーとノウハウの例＞
このブログは、プロジェクトのブログでもあるので、プロジェクト関連で例えれば、プロジェクトで良く用いられるWBSのテンプレートの書き方はハウツーとなります。
ハウツーなのでWBSのテンプレート はだれにでも書けます。また、WBSの書き方は「やり方」がわかっているのでテンプレートを作成してくれるツールは有償無償それぞれにあります。しかし、リソースの状況に合わせて作業を分解し、WBSに落とし込む能力＝「環境の状態を判断する能力」とその環境下で最適なハウツーをチョイスして用いる能力＝「コツ」はノウハウとなります。また、実績を記入する方法だけならだれでもできますが、その実績を見てWBSを運用するのも、ノウハウということにもなります。
ご存じのように、WBSを運用するとは、日々、実績が記載されていくWBSを見てプロジェクトの状況を判断し、今後、どのように進めるかを決定し、場合によってはWBSを変更しプロジェクト自体の動きを変える＝運営する能力の一部になります。
この運営する能力は、一般化されたアルゴリズムで解けるようなものではなくて、過去の経験に基づく知識に紐付くノウハウ＝変化していく環境下で最適を目指してタスクの組み換えやリソースの変更をどうすればよいかを、ハウツー（言い換えれば定石）の塊の中から最適なチョイスを行うことができる能力や、新たなハウツー（定石）を加える能力が必要となります。
単純に納期に向かっての最短経路を割り出すならば、今のAIならば朝飯前でしょうが、動的に変わるリソースの状況（メンバーの病欠等も含みます）やプロジェクトの置かれた環境の変化（会社環境の変化に伴う投入資金量の変化等も含みます）、スケジュールの遅延によるリソースの欠如や、走りすぎたタスクによって生まれた空きリソースの運用、これらの事象の発生に対応するための新しいタスクの挿入やタスクの削除等のタスク調整、足りなかったり余ったりするリソースの移管やリソースの習熟度に合わせたリソースの配置替え等、多くの作業を行う必要があります。
なのでWBS運用を用いたプロジェクト運営には、多くの環境パラメータの理解とその取捨選択、チョイスしたパタメータに基づく対応ができるハウツーの選出、場合によっては、その環境に合った新しいハウツーの創出ができなければ、WBS運用を用いたプロジェクト運営は出来ないとなります。
（が、ゆえに、個人的にはプロジェクトのタスクはできるだけ初期の段階で、できるだけノウハウが必要な場面が出ないように、ハウツー化＝消化計画化するように指導するわけです）
このようにハウツーとノウハウの関係は、ノウハウがハウツーを囲み込む形で存在している言えます。なので、ハウツーは特定の環境との組み合わせで単離でき、特定の同一環境下では同じ働きをする「やり方」ですが、ノウハウは環境全体と関係性を網（ネットワーク）として持ち、その網のもとに存在する部分的な特定の環境単位にハウツーとして展開される。そのような構造と機能を持っていることになります。
＜プロジェクトの中でのハウツーとノウハウの位置づけと実際＞
では、その上で、プロジェクトの中でのハウツーとノウハウの位置づけはどうなるのでしょうか。
キーワードは環境となります。
まず、 環境が変化しなければ、ハウツーを用いて進めるのが一番効率的と言えるでしょう。誰がやっても同じ結果が出せる。マニュアル化できる＝
メソッド化が可能＝教育も育成も確立できます。また、必要なリテラシーもスキルも
分かっていて、リソースに対して、どのように教育すればスキルが確立して、品質的に安定したものが計画通り＝立てたスケジュール通りに作成される。金太郎あめの大量生産というと安っぽく感じますが、効率化と品質の安定を目指す仕組みの極みと言えるでしょう。
しかし、環境が変化しやすいのであれば、ノウハウの登場となります。
ただ、環境の変化に耐えるノウハウのある人材をたくさん集められれば良いのですが、ノウハウは網を構造として持つので、知識と経験が重視されます。このため属人性が高い。
例えて言えば、同じウリ科でもカボチャとスイカは違う実をつけ、同じ種で同じ場所に植えても実の成り様は違います。このように 、同じヒト科で、同じ知識を持って、同じ経験をしていても、同じように育つわけでも同じ実がなるわけではないのです。
ですから、対象のプロジェクトにノウハウがあるような経験をしていると思われる人を引っ張ってきても、外れだったりするわけです。また、その人がキーマンの様に見えても、単にそのプロジェクトに冠として加わっていただけで、必要とするノウハウは持っていなかったということも往々にしてあります。
この様に、適応の範囲が広いノウハウを持つ人は少なく、いても引っ張りだこなので、そう簡単には見つからないし、手が空いているとも限らない。また、これらの人は才が効くがゆえに、環境の変化が多いプロジェクトはしんどい思いをしたり、苦労して成功させても妬みを買う場合もあるので、隠している人もいます。なのでプロジェクトに合うノウハウのある人を見つけるのは難しい。ゆえにライン部門のフロントや基底、スタッフ部門の人までノウハウのある人を投入することは出来ないとなります。
となると、どうするか。棲み分けを行うことになります。
ハウツー対応人材はリソースへの育成ハードルが低く、環境の変化が少ないときに最も高効率、高品質になるので、そのような環境局面と部門に投入し、ノウハウ対応人材は育成のハードルが高く、属人性が強く、かつリソースの少なさから、変化の大きい環境局面と部門に投入することになります。
実際にはどうするのか。
仮に環境に翻弄されているプロジェクトがあったとして、これを海に例えると、海面では嵐で船を飲み込むような波が逆巻いていても、実際数十メートルも潜れば、嵐など関係の無い静かな光景が展開しています。それと同じでプロジェクトもラインのフロントが大荒れであっても、ラインの基底部分やスタッフ部門ではそうなっていないというか、環境からくるアフォーダンスにジャックされて大荒れにならないようにします。フロント以外の環境は、常に安定させる＝粛々と仕事が進められるように、ハウツーが効くように対応します。そして大荒れの波はノウハウを持ったフロントが受けるようにします。
実際には、フロント以外の作業は環境の変化が影響しにくい単位に切り分け、ハウツーが効くラインの基底部分やスタッフ部門に落としていくことになります。逆巻く波が打ち寄せるごとく環境の変化が押し寄せるフロントには、これを切り抜けるノウハウが必要なリソースを集中します。これによってノウハウを持っているけど、少ない数のリソースで対応できるようになります。
間違っても、波をそのままラインの基底部分やスタッフ部門に持ち込んではいけません。ノウハウを持つリソースの少ないラインの基底部分やスタッフ部門までが、直接環境の変化にさらされると、進むものも進まなくなり、プロジェクト組織自体が崩壊する可能性がありますから。
この棲み分けが、プロジェクトの中でのハウツーとノウハウの立ち位置となります。
＜ノウハウとハウツーとコントロールと孫氏の兵法＞
なお、加えて言えば、効率的にハウツーとノウハウを用いることができる状態にするためには、全体が「コントロール」されている必要があります。この全体の「コントロール」に必要なことを記載しているのが「孫氏の兵法」となります。
「孫氏の兵法」にはいろいろなことが書かれていますが、何を準備し、何を確認し、何を考え、どのように行えば、全体の「コントロール」が可能になるのか。また、全体の「コントロール」を行うために必要なプロジェクトマネージャやリーダの持つ資質とは何か、が書かれています。
これを読まれた方は、全文の「孫子の兵法をプロジェクト マネジメントの観点で翻案したら」または、部分解説を集めた「INDEX 孫子の兵法をプロジェクト マネジメントの観点で翻案したら INDEX」を参考にしていただけるとありがたいです。