開発生産性を上げながらビジネスも30倍成長させてきたチームの姿
・短期でチームを解散させないこと
・DevOpsをやっていく覚悟
ほんとこれだよなーと思った件。
なぜ短期でチームを解散させるのか
短期でチームを解散させたり組んだりしても、良いことはない。しかし実際にそんなことになってるからみんな困ってる。
これは、案件や課題や機能といった単位でプロジェクトチームを組んでいることに起因しており、兼任者ばかりになってしまう問題とも深く関係している。
プロジェクトチームを最初に組んだ人（恐らくマネージャーヤー組織長といった人）にとって、案件に合わせてチームを組むことが仕事であり、案件が終わればチームを解体して次の案件にメンバーをアサインすることが仕事なのだ。
そのような仕事のプロセスになっているし、評価基準にもなっている。
チームファースト
プロジェクトチームで仕事をしていたら、いつまで経ってもこの負のスパイラルからは抜け出せない。
プロジェクトが先にあり、そこにメンバーをアサインするのではない。メンバーとチームが先にあり、そこに仕事をアサインするのだ。つまりこれは、チームファーストと言えるだろう。
そして、プロジェクトでは期限は先に存在するが、チームファーストではチームのキャパシティに合わせて期限が定まる。
いや、この場合は期限というよりもリリース見込み時期だ。リリース見込み時期を早めたいなら、チームをせっつくのではなく、チームを手助けするべきだ。
チームが主、案件は従
しかし、マネージャーや組織長、営業の人に降りかかる「期限」のフォースは強いだろう。
しかしその期限をプロジェクトチームに押し付けて、とりあえずプロジェクトを開始し、人員が足りなければ兼任してでもチームを組み、とりあえず「着手」の状態にして満足してないだろうか？
同時並行でたくさんのプロジェクトが「着手」した状態となり、しかしなかなか「完了」にならない。期限が近づいたら他のプロジェクトチームから人をかき集めどうにか完了させ、次の期限に向けてまたメンバーを駒のようにあっちへこっちへ。これではプロジェクトが主で、人が従だ。
プロジェクトを完了させることが目的の受託開発なら、もしかしたらこれもアリなのかもしれない。しかし、より良い顧客価値を見つけ出してプロダクトに仕立てていくことを目指すのなら、チームが主・案件は従だ。長期安定存続のチーム、メンバーは比較的長くチームに所属するのが望ましい。
チームが長く存在することで、そこに属するチームメンバーは成長する。チームには文化が形成される。チーム内の協業体制ができ、チームの生産性は上がる。チーメンバー同士の共通認識ができて、コミュニケーションのオーバーヘッドが減っていく。トラックナンバーワン問題も減っていく。
期限と着手のプレッシャー
しかしそれでも、プロジェクトや案件を優先して、チームを解体しよう・チームを組み直そう・人を兼任させようというフォースは確かにある。その背景には「なんで案件を着手してないんだ？」や「ともかく早く欲しい」というプレッシャーがあるのだ。
プレッシャーをかける側にもいろいろ事情はあるが、マネージャーや組織長は、そのような期限と着手に対するプレッシャーをそのまま受け入れたり、とりあえずプロジェクトを開始するというは止めることだ。
プロジェクトや案件は開始してからマネジメントするのではなく、開始する前から開始時期とリリース見込み時期をマネジメントするべきだ。
