プロジェクトチームの中のプロセスを作るのはメンバを守るためなんだ

ウォーターフォールにしろ、スクラムにしろ、カンバンにしろ、エンジニアがインプットをプロセスとツールで変換してアウトプットするという所作は変わらないものです。顧客の品質要求、プロジェクトチームの所属する組織文化、プロジェクトマネージャの志向、チームメンバの考え方、など、一つの所作を取り上げても多くのプロジェクトがあるのに何一つ同じプロセスというものは存在しないのは、プロジェクトは唯一無二であることを表す側面なのでは、などとそんなことからも思ったりもするものです。

ワタシはプロセスをワタシが経験したり、見聞きしたりしてきたワタシが持っているナレッジを元にプロジェクトに適用されるルールなの度の制約の上で、プロジェクトチームがふるまうプロセスを設計します。設計という大げさではないけれど、メンバがだれでも同じ段取りで振る舞うことができなければ、作業の結果で得られる品質のラインがチームのアクティビティのアウトプットとしての期待値を維持できないと考えているからです。

これは遠回しに作業の標準化を表現しているのでは、と気づく人もいるかもしれないけれど、まぁ、平たく言えばそのとおり作業の標準化を定めて、プロセスで得られるアウトプットのレベルを確保しよう、ということであって、それは作業品質の確保ということを目的にしているともいえます。

チームメンバにプロセスを守らせる理由
本質的な狙い、目的は、先に述べたように作業品質のラインを揃えることでのアウトプットされるdeliverableの品質確保、です。これはプロジェクトで顧客と合意したdeliverableを約束した日までに届けるために必要なことです。

このほかに、副次的な目的もあるのです。プロジェクトチームで決めたプロセスで得られるdeliverableは少なくともチームの中でオーソライズされているプロセスであって、プロジェクトマネージャも同意している“しくみ”で生み出されたものです。

チームで決めたプロセスはメンバがやらないといけないふるまいであって、そのふるまいではチームメンバがそのふるまいを守っている限り、作業品質は担保されいるわけです。プロセスの中にセルフチェックが組み込まれていれば、そのチェックはされているということが前提となるので、それはコンテキストの中に組み込まれるのでセルフチェックをしたかどうかだけを問えばよく、セルフチェックの具体的なチェックの項目をレビューの中で確認することは必要なくなるわけです。

チームで決めたルールでもあるのでそのプロセスを守ることが義務化されるし、それを果たせないのであればそれなりの理由が必要だし、無断でルールを破ればチームの中での信頼を失うことになるのである程度の自制心が働くことも期待できます。

そうしたチームの中でのプロセスがコントローラブルな期待も得られるのですが、プロジェクトチームのメンバの立場からすればもう一つ得られるメリットがあります。

“チームのプロセスを守っていればプロジェクトマネージャが守ってくれる”

ワタシがプロジェクトマネージャをする場合、チームで決めたプロセスを守っているのであればメンバを何があっても守ると必ず言います。プロセスは最終的にはプロジェクトマネージャであるワタシが同意しているものであり、すべてはワタシの責とするからです。だから、守ると言い切るのです。ただ、それにはチームのプロセスをメンバが守っていることが前提であって、前提から外れたことがあればそれは「守らないよ。」ともメンバには公言します。

チームのプロセスを守って、やるべきことをやっていて間違ったのならプロジェクトチームのプロセスである“しくみ”がオカシイのであって改善を要求されるのはプロセスなのですから。ただ、チームのプロセスから逸脱しているのであればそれはメンバに対してルールを守るように矯正しなければなりません。

まぁ、ホントのところは、メンバが間違いを犯したら守りますけどねぇ。