測定と許可を願うより継続的なリリースが自己組織化のチームを作る

ここ数年、特に今年になってからシステム開発を担うチームに対して自己組織化がさもありなんという感じになってきていると思うのですけれど、さて、実際のところはどうなんでしょうか。

自己組織化するチームは実はそれほど珍しいことはなくてマネージャから裁量を与えられているケースは少なくないのです。例えばプロジェクトのチーム内でのプロジェクトマネージャの方針によりメンバに多くの意思決定を手渡すことはよく見られることです。

エンジニアを受身に慣らす

ではどうして裁量を渡しているはずのエンジニアが受身に慣らされてしまうのでしょうか。

それは、生産的な活動ではない仕事を介してコマンド&コントロールを刷り込むマイルストーンを強制しているからです。

生産的な活動ではない仕事とは、成果の測定と次の行動の許可を得させることです。

成果の測定とは、測定できる定量的な数値の計測であり、時間や出来高で表されます。

次の行動の許可とは、許可を与える組織に対し、成果の測定を報告することで次のアクションへ遷移することを許可を伺う行為です。

こうした権限を持つ誰かに情報を提供し、その状態が適切であるかどうかの判断を委ねてしまうことは自ら考え行動するという自己組織部分を自ら逸してしまうのです。

測定と許可の存在

 成果の測定と次の行動の許可は、組織が過去にプロジェクトがトラブって得た教訓であったり、初めてプロジェクトをマネージするプロジェクトマネージャや経験の少ないメンバで構成されたチームから参考にしたい仕事の仕方の提供を求めて形作られていきます。

こうした積み重ねが組織の中で制度化し、標準化されていきます。

これは普段、作業プロセスの標準化や管理されることに対して敵対意識を持っているエンジニア自身が、状況が変われば自らがそれを求めるということを意味しています。

この状態が長く続くと組織の中でのお作法となり、やがて家風とも言える組織の文化が醸成されてしまうのです。

これを回避するためにもC&Cから測定できる定量的な数値に変わるチームの進捗を表す別の何かで伝える必要が出てきます。

C&Cから逃れるために 

定量的な測定から逃れたい、組織の標準化に縛られたくないとするとき、エンジニアはどのようにすればそれが実現できるでしょうか。

プロジェクトでの作業を繰り返す短いスパンで設計し、その成果を測定できる作業時間やコード量ではなく、プロジェクトの存在意義である目的の部分を動くシステムとしてリリースすることで代替することができるようになります。

ただ、作業を繰り返す短いスパンでのリリースが途切れてしまうと作業が進捗しているかを確認する手段がなくなり、結果的に測定できる何かしらの数値で成果になるまでのしかかり状態を通知し続けなければならなくなります。

 

 

実際は短いスパンでリリースできるようになるまでが大変で、やり方は理解できてもムリぽと思ってしまうのはプロジェクトでリリースするフィーチャのロードマップを企画する力量がないから、という現実があったりするのですけれど。

 

PMBOK対応 童話でわかるプロジェクトマネジメント

PMBOK対応 童話でわかるプロジェクトマネジメント