べつに大きなプロジェクト並みのプロジェクトマネジメントをして欲しいわけじゃない

プロジェクトをキャリーしてきたり、プログラムマネジメントをしてみたり、組織横断的にレビューアなんてやっていると、

「作業品質の作り込みを意識した方がいいよ。」とか「レビュー結果で設計のウィークポイントを探して……。」

とか言おうものなら、

「小さなプロジェクトなんで無理です。」

とか言われたりします。はい。こちらとしてはリスク識別したと思っているので、やっておなかいと後で、

「痛・い・目・に・合・う・よ・！」

と言いたいです。あ、構わず言っちゃうときもありますが、「(ふーん、そうなんだー。)」と思うときもないではないです。

べつに大きなプロジェクト並みのプロジェクトマネジメントをして欲しいわけじゃない
大きなプロジェクトには大きなプロジェクトなりの特性があって、小さなプロジェクトは小さなプロジェクトの特性があるものです。とは言え、どのプロジェクトでもやらなければならないことはあるものだし、プロジェクトの特性で取捨選択するものもあるわけです。それを十派一絡げに「出来ません。」と返されても。

あのですね、出来るできないではなくて、プロジェクトをプロジェクトマネージャが計画したとおりに進めるために必要だと思うことはやらないといけないんですよ。とは言え、プロジェクトの特性として必要のないと判断できることもあるし、その逆もあったりします。それに、何も大きなプロジェクトのようにガッツリと管理をしなければならないというわけでもないし、小さなプロジェクトで出来る程度のカジュアルな管理ではプロジェクトの特性として「拙い」ケースもあるわけです。

と言うことは、プロジェクトの特性にかかわらず必ずやらないといけない義務的なものとプロジェクトの特性で程度を調整したり、取捨選択を判断する必要がある、ということなのです。

テラーリングスキルを身に着けよう
そこに、何がどの程度必要で、何が不要かを判断できるスキルが必要になる。それがテーラリング。

テーラリング 【 tailoring 】
(洋服の)仕立て、仕立て直し、という意味の英単語。ITの分野では、業務プロセスやシステム開発プロセスなどについて、一般的あるいは全社的な標準を元に、個別の部署やプロジェクトに合った具体的な標準を策定すること。
標準規格や大きな組織全体の標準は、どのような場面や組織にも適用できるよう一般的、抽象的な表現で定義されていることが多く、個別にどのように適用するかが必ずしも自明でないことも多い。これを個別の組織や業務、プロジェクトなどに適用する際に、対象に応じて具体化したり、詳細を定めたり、一部を改変したりする作業のことをテーラリングという。

みなさん、無意識に使ているスキルなんですけどね。実際の経験から自分だけのパターンにして、それが習得出来たら自然とそれ以降に経験することは自分のパターンに合うようにテーラリングしているんですよ。

仕事だから、人数の多少の関わらずチームでやることだし、ステークホルダもいることだから明示的にやりましょう、ってことです。そのテーラリングをするためにはやっぱり形式知を学んで全体を俯瞰していないと取捨選択するもの自体がわからないですからね。そうした知識の体系的な取得も必要です。

それに、そうした体系を知のよりどころにしておいた方がいいのは、会話する人とのプロトコルが合わせやすいからです。知識の背景がわかりますから、それを暗黙なコンテキストとして会話が始められるのですね。まぁ、背景の無い人がいたらその分ハードルが下がるのでコストがかかりますが。