実現したいチームを作ろう

チームを立ち上げたら早速プロジェクトの活動をしないと立ち上げ初日から進捗が遅れてしまうのでついつい準備もたらないままに始めてしまうかもれないけれど、ちょっと待って。

「どんなチームにしたい？」

こう聞かれたら、どう答えるだろう。答えられるチームのイメージは持っているのだろうか。

一般的にはチームの「ビジョン」なんて呼ぶ人もいるかもしれないけれど、呼び方は重要じゃないからここではなんでいい。尋ねたいのは

「どんなチームにしたいと思っているのか」

ただそれだけ。

「バグを出さないチームにしたい」

オーケー、ならプロジェクトマネージャはバグを出さないためのコストを払おう。コストを支払わないでバグがゼロなんてあり得ないのだから。

バグは設計、開発、テスト、リリースと工程が進めば進むほど修正コストは０の桁が増えていく。だからバグを出したくないと思うなら、バグを出さないためのコストを支払おう。

例えば、設計の時間を必要な分だけとる。工期を無理して短くすればその瞬間はコストが削減されるかもしれないが、テスト工程でバグが出たらパーだ。パーというよりは足が出る。だったら、最初から工数を積んでおいて、必要な工期を確保してコストを負担しよう。

「定時で帰れるチームにしたい」

無理をして残業してプログラムを書いても、設計仕様を検討しても、全くもって効率的じゃない。返って、残業代と無理をしたツケがソースコードにも設計書にも混入したまま気づかずに進んでしまう。

案の定、テスト工程まで見つけられずに潜在してテストやリリース後に発現してしまうんだ。

だったら、定時で帰れるような仕組みを工程を始める前に設計しないと。工程が始まってからでは遅いし、定時で帰るというような目標なら、プロジェクトを始める前にそれができる仕組みを考えておく必要がある。

そして、プロジェクトのキックオフをするときに、

「定時で帰る。何があっても帰る。それを実現するためにコストを払うので協力してほしい」

と表明しなくちゃいけない。何を実現するかをはっきりと自分の言葉で伝えることが必要だ。

バグをゼロにしたければ、ゼロになるような方法をとることが必要だし、ゼロにするだけのコストがかかる。実現したい目標にはそれを実現できる方法を選択しなければならないし、選択した以上は、必要なコストも支払わなければならない。

方法は考えていない、コストも支払わないじゃあ、バグはゼロにはならない。中途半端にコストを支払って、中途半端に負担をかけて、テストでたくさんのバグを出して、コストがオーバーランするんだ。

必要なコストは支払おう。

実現したいことを実現できる方法を選ぼう。

実現したいチームを作ろう。