新しいものを試行する風土を作る - ハピネスチームビルディング[6]

この記事の初出は、Software Design 2022年9月号です。

はじめに

前回までは、私のチームで取り組んでいる「楽しいチーム開発をするための様々な施策」を紹介してきました。
それらの施策は、私一人でアイデアを出したのでなく、チームの皆で提案したものであり、そうやって皆で新しいものを試行してチームを変えていくことが、楽しく開発する原動力となっています。
ただ、最初からそれができるチームだったわけではありません。

今回は、チームに新しいものを試行する風土を作るために取り組んだことを紹介します。

3年前のチーム状態

3年前の私のチームは、若手メンバー中心で数人のチームでした。
当時の開発のやり方は、それまで社内でやられてきた過去の古いやり方を踏襲していました。
今のやり方を変えようと思っておらず、ペアプログラミングもモブプログラミングも分報もやったことがなく、ツールに関してもそれまでと同じツールだけを使い続けていました。

3年前のチーム

当時、そのままではチームで開発しているプロダクトのロードマップが実現できないため、もっとチームが成長する必要がありました。

皆でどうなりたいか議論

当時のチームが、もっと成長するチームに変わるために一番重要な事は
「現状のやり方を変える必要性をあまり感じない」というチームの姿勢を変えることでした。

そこで、チーム全員でこれからどうなりたいかを議論しました。
議論の中でチームのメンバーから出てきた言葉の中には、
「世の中の良いプラクティスやツールを全然知らない」
「このままだと世の中から置いてかれそう」
「ずっと同じやり方はつまらない」
というものがありました。
それらの課題を解決する施策として「かたっぱしから新しい技術・ツール・プラクティスを試してみるのはどうだろう」という提案をすると、メンバーの皆が「それは面白そう」「自分たちも成長できるし楽しそう」と乗り気になってくれました。

ハピネスチームビルディング

具体的には、上図のように、世の中の新しい技術・ツール・プラクティスを積極的に施行して、得た知見を社内や社外にアウトプット(技術記事を投稿)し、いいねをもらってモチベーションアップするという活動です。
「試行→アウトプット→いいね」の無限ループで成長できて楽しそうということで、この活動を「ハピネスチームビルディング」と名付けました。

提案しやすくする工夫

活動を始めてみたものの、私以外のメンバーは若手だったため、新しい技術・ツール・プラクティスを提案しようと思っても、どこから何をヒントに情報を探せばいいか分からないという問題がありました。
そこで、若手メンバーに提案してもらいやすくするために、技術やツールやプラクティスを探すためのヒントになるような具体例をいくつか伝えました。
以下がその例です。

• 技術の例

  • 設計(クリーンアーキテクチャ、Enterprise Architect、 CQRS など)

  • 開発に利用する言語で有名なライブラリ

• ツールの例

  • 情報共有するためのツール(Trello、Miro など)

  • Visual Studio Code の便利な拡張機能

• プラクティスの例

  • 振り返りのやり方(KPT、YWT、Lean Coffee など)

  • 朝会の進め方

  • コミュニケーションを促進するプラクティス

とにかく試行して実績作り

チームの皆で大事にしていたのは、失敗してもいいからとにかく試行してみる事が重要という価値観です。
だから、思い付きでも効果見込みが低そうなものであっても、とにかく皆で新しいものを試行しました。
特に最初の1年くらいは、そうやって試行した実績を積み重ねて、チームに「新しい技術・ツール・プラクティスを試行する風土」を作る事を優先しました。

以下は最初の頃に試行したプラクティスの一例です。

• ペアプログラミング

• モブプログラミング

• 分報

• 毎朝15分の勉強会

• インセプションデッキの作成

• ドメインビジョン声明文の作成

• DX Criteriaでの評価

• Lean Coffeeによる振り返り

ちなみに、試行した結果、効果が高いものは継続しますが、効果が低いものはやめました。
とにかく試してみることが重要という価値観なので、やめることになっても気にせずに、どんどん試行しました。

施行件数の見える化

試行を促進するために、新しいものを試行した件数を下図のようにグラフで見える化しました。
グラフで件数が積み上がっていく様が見える事で、「今月もいろいろ試行できたね」という感じにチームの皆で喜び合って、達成感を感じやすくなりました。

施行件数の推移グラフ

試行の後にアウトプット

各自が提案して試行した技術・ツール・プラクティスについて、試行して学んだ事を提案した各自が技術記事に書いてアウトプットしました(記事は業務時間内で書いてもらってます)。
例えば、「分報」というプラクティスを試行した場合は、分報をやってみてどんな効果があったのかを書きました。
それを書くことで「なんとなく良い効果がある」と思っていた根拠が明確になり、その後、より効果的にプラクティスが活用できるようになりました。
また、記事に対して「いいね」をもらったりコメントをもらう事で、自分の知見が人の役に立つという体験を得てモチベーションアップし、もっと試行してみようという契機になりました。

なお、3年前の当時は、私も含めてチーム全員が、技術記事を書いた事がありませんでした。
その状態から全員が毎月技術記事を書くようになった施策については、今後の連載で紹介予定です。

提案タイムの確保

最初の1年くらいは、コーチングのようにメンバーへの問いかけをする中で提案してもらったり(詳細は連載の第1回と第2回を参照)、各メンバーがそれぞれ自分のタイミングで新しい技術・ツール・プラクティスを探して提案していました。
ただ、常日頃からそういうものを探す意識を持ち続けるのは難しいですし、特に毎年チームに入ってくる新人にとっては、そういう時間を確保するのが難しかったです。

そこで途中からは「提案タイム」を確保するようにしました。
具体的には、月に1回、全員で同じ時間に、新しい技術・ツール・プラクティスを探す時間を45分間設けます。その後、各自が5～10分でチームで試行するものを提案します。
提案タイムを設けてからは、新人もなにかしらの提案ができることが多くなりました。

まとめ

3年前にハピネスチームビルディングを始めた後、私のチームには毎年新人が入ってくるため、現在7人のチームとなりました。
新人も含めて、皆で新しい技術・ツール・プラクティスを提案し、毎月なんらかの新しいものをチームで試行し続けています。

新しいものを試行する風土を作ることで、これまでの連載で紹介してきた「楽しいチーム開発をするための様々な施策」が生まれました。
その結果、チームも個人も主体的に成長し続けるようになり、開発生産性も上がりました。
よって、新しいものを試行する風土を作ることは、楽しいチーム開発をする事と開発生産性を上げる事の両方に効果があると思うので、参考にしていただければ幸いです。

---

次回の記事はこちら↓

前回の記事はこちら↓