CureApp でも各プロダクトを開発するためにチームを組んでいます。よいプロダクトを開発できるチームとなるためにやってきたこと、そこから得られたことを一度まとめてみます。
チームに権限を持たせる
プロダクトを作るためのチームであれば、そのために必要な権限を対応チームに与えるべきです。要件があやふやなのであればはっきりさせるための施策に必要なコスト・手段がなければいけませんし、出荷テストに工数が必要であればそのための計画的な工数捻出が必要になります。
権限のひとつとして自治権をもたせることも重要です。要件についてはいろいろな条件が絡むのでまったくの自由とはいかないことのほうが多いですが、すべてのことについてチームによる決定を尊重すべきです。
また、権限を行使するためのリソースとして予算・期間などは前もって認識をあわせておくべきです。プロジェクトにはいろいろなフェイズがありますが、各フェイズともスタート前に妥当な条件をチームとすりあわせておくべきです。
もちろんプロダクトを作成するために必要なすべての手順・作業が前もってわかっていれば、必要な権限・予算・期間もわかるとは思いますが、ある一定以上の水準では不可能です。ソフトウェア開発の場合、予算の見積もりはしやすいのですが、チームを組んだ直後だと期間はわりと変動しやすいのでその点も織り込んでフレキシブルな対応をすべきです。
難しいことですが、権限は個人ではなくチーム全体に与えることが重要です。ある特定の方でないと行使できない権限の場合、その方に負荷が集中したり、開発速度を下げてしまいます。もちろん決済などどうしても集中させないといけない場合もありますが、それらも含めてなるべくチームで対応できたほうが全体の経験が上がりやすいです。
必要な権限を持たせることが難しい場合、そのことはチーム外へ共有してまっさきに解決すべきです。チーム外の権限を持つ方に代行を依頼する、権限を持てるように働きかけるなどの方法になります。
頻繁なチーム変更をしない
数ヶ月単位でのチーム組成の変更はやめるべきです。タスクに比べてメンバーが少ないうちはよくあることかもしれません。
まず技術的な知識・スキルの蓄積がなされません。とても優秀な方は 1 日でもバリューをあげるかのように見えますが、ある程度の運用・メンテナンスまで含めてでないと技術的なベストは見つからないことが常です。チームとしても選定した技術がメンバーに馴染むかどうか、プロダクトに馴染むかどうかは期間をおかないとわかりません。
この点に関しては組織全体の技術をあるていど標準化することでなんとかなったりすることもあります。チーム間でベストプラクティスを共有しあうことで組織全体がレベルアップしていきます。ただし、注意すべきはチーム内である程度運用されたプラクティスでなければ意味がないということです。
また、「プロダクト固有の複雑さ」へのキャッチアップに期間が必要です。どれだけ単純なものであってもプロダクトには固有の複雑さがつきまといます。設計上の欠点、選定技術の不得意分野などはまだ対処のしようがあるのですが、要件からくるものは避けて通れません。ターゲット層にわかりやすい表現・アプローチなどについては簡単なものは存在しないでしょうし、プロダクトが専門知識を必要とするものの場合、学習にはそれなりの時間がかかります。
もっとも重要なことは、技術やプロダクトへのキャッチアップに時間を取られてしまうことで、学習する場としての「余裕」がなくなってしまうことです。「学習する場」とは「チームが機能するとはどういうことか」で説明されている概念です。これがなくなることで外部環境へ対応できなくなる、新しい手法を発見できなくなるなどの理由でチームはベストなプロダクトを作成することができなくなってしまいます。
複数チームを兼任しない
いろいろな制約から複数チームを兼任するメンバーが出てきてしまうことがありますが、できるだけ早くその状態を解消しなければなりません。
まず兼任するメンバーの負荷の問題です。コンテキストスイッチは思った以上に負荷がかかります。まったくの単純作業が存在しない仕事で、特定の時間だけこのプロジェクト、というわけにはいきません。そのために必要な知識・勘所の切り替え、再集中の時間などでそれ以上の時間がかかります。
コストとして見落とされがちですが、コミュニケーションパスの増加ということもあげられます。あらたに 5 人のチームにジョインした際、連絡手段を考えると 5 つ以上のチャンネルが増えるわけです。チームによってコミュニケーション方法も違うかもしれません。兼任メンバーの負担と同様にそれ以外のメンバーの負担も増えます。
最終的に行き着く先が、何かの理由で兼任メンバーがボトルネックになってしまうことです。そのメンバーがプロジェクトの進行速度を決めてしまうのです。よくある理由はひとつのプロジェクトでの負荷が大きくなったことでその他のプロジェクトへ参加しにくくなることなどですが、兼任メンバーが責任を果たせないことで精神的にも負担がかかってしまうことは見過ごしてはいけません。
いままでの理由からチームが兼任メンバーにタスクを振りにくくなってしまう状況も考えられますが、そうなるとなぜそのチームメンバーになったのか疑問が生じてしまいます。
個人ではなくチームの役割をはっきりさせる
あるタスクを個人にお願いするのはやめるべきです。
その方にしか対応に必要な知識・スキルがなかったとしても、それをシェアするためにチーム全体にタスクを依頼すべきです。常に特定のメンバーがタスクをこなすことによってトラックナンバーが低く抑えられてしまいます。いい機会だと思ってチーム内の複数人であたるようにすべきです。
本当に緊急の場合は個人への依頼も仕方がないですが、緊急事態を発生させないようにすることも重要です。とはいってもまったくの想定外は対処しようがないので、一度起きたことへの準備はやっておく、ということが重要になります。ポストモーテムの徹底ですね。
チーム内で解決できない問題はチーム間で解決する
権限のところでも少し書きましたが、チーム内で解決できない問題があったときは別チームで似たような課題を抱えていなかったか、その解決方法を共有することで迅速な解決を図ります。
チームが増えてくると PMO のような横串の組織があってもいいのですが、チーム数が少ないうちは都度か、定期的な情報交換がフレキシブルでよいと思います。
まとめ
きちんとデータをとらないとわからない主観的な理由は書かず、客観的にわかりやすいことを書いてみました。各項目に心理的にダメな理由もあるのですが、みんな感じていることでもあるかなと思ったので省略しています。
すべてをしっかりきっちり厳密にできているわけではありません。やっている最中のものもあります。が、目指すべきところは示せているかなと感じています。
さて、こういったチームにジョインしていただいている方々による CureApp advent calendar 、はじまります !! 明日は @kt3k@github さんのテスト関連の記事です。