読者です 読者をやめる 読者になる 読者になる

メンバが入れ替わって機能しないプロセスはチームに負債をもたらす

on

技術的負債を扱ったブログを読んでいて、ふと頭をよぎったことがこれ。 

 基本的に技術的負債なんてものは人に起因する問題なのだから、ーそれはそうです、だって人の振る舞いの結果について言及しているのですからー、技術の採用から維持に関わる人の判断に難点があった、ということです。

チームメンバを入れ替える、増員するというケースの理由は様々ですが、いずれにしても人の移動にはチームで活動できるようになるまでの立ち上がり時間が必要で、スピードを優先するシステム開発では致命傷になりかねません。

チームのプロセスでついついやってしまうアンチパターンは、ルールを作る際に何かしらのツール、特に、オフィススイート(なんて今も言うのか)に文書として書き上げ、大事にファイルサーバなどに保管しておくことです。

で、チームに参画してきたメンバに対し

「読んでおいて」

と投げてしまうやり方。

まあ、文書化されている分だけましと言えばマシですが、それをどの辺りの人数と共有とするかで判断は違ってくるでしょう。

個人的にはそうしたやり方は避けたいですが。

最良は、新規参加のメンバが見ていることが可視化され、作業自体がプロセスとして組み込まれていることです。

意識せずに、チームのプロセスを実行できている、がベスト・プラクティス。メンバ全員が作業として振る舞うと言うことは、チームのプロセスが機能しているから続けられるわけで、機能していなければ、進捗の障害となるので進捗として機能を検証できると言う見方もできます。

そうした検証はプロセスをインストールする際に先行タスクでサンプリングとして評価する必要がありますし、しなければ進捗がだだ遅れするだけですけど。

ところで、チームのプロセスに不備があり、チームの誰かがそれを補完していたとすれば、いずれ、その不備は表面化され、不備として対処せざるを得ないでしょう。ただ、そうした補完作業を自分の仕事だと思い込んでコツコツと拾っていくメンバが少なからずいることも忘れてはいけません。

そしてそうした活動を続けていくことはチームにとってプロセスの負債を積み上げていくことだと言う認識が必要です。チームのプロセスなのであれば、誰かがそれを巻き取ってしまうことを認めたら、その瞬間からプロセスの負債の増加に加担することになるのですから。

まあ、チーム活動のためのプロセスで得られるリターンは全員で享受するもので、それに伴う負担はプロセスとしての仕組みのコストになっていなければならないのです。