最近は開発チームのリーダーを任せてもらいみんなでワイワイ楽しく仕事をしている。
特に意味のない青い池（北海道 美瑛町）
4月から結成されたチームで、最初の1週間はスプリントゼロと称して設計とドキュメンテーション、チケット作成・見積りを進めた。全員で同期的に、だ。2週目は実装に進んだが原則全員でモブプロ。3週目には二手に分かれて原則ペアプロで開発を進めた。4週目にはペアプロを基本としつつも、スプリントゴール達成・スプリントタスク完遂のために最適なアロケーションを適宜試す、みたいな感じでやっていた。結果、かなり良い雰囲気でチーム開発を進めることが出来ているような気がする。
これまで在籍してきたチームでは、スキルセットやドメイン知識、コードベースの理解の偏りがあり、タスクがお互いに交換可能になっていないという、いわゆる属人性の高い状態が続いていた。その状態を脱しようといろいろと施策を試してみても、いろいろな理由で結局うまくいかない。これは現職に限らずどこの職場でもそうだった*1。
スキルや知識の平滑化には時間と体力がいる。一人で気持ちよくコードを書く時間を捨ててペアプロ・モブプロをするのは大変なストレスのかかる行為*2だし、さっさとコードを書いてリリースすれば良いと思ってしまうような実装タスクについてチケットを書くのはひたすらにめんどくさい。互いに「自分がやった方が早い」「○○さんにやってもらった方が早い」と思っているチームにおいては、多大な労力をかけてスキルや知識の平滑化をしたとして「その先に何があるの？」がよくわからず、このコストをかけることへの納得感が醸成されないのだ。
結果、スプリントゴールに紐づく重大タスクなのに1人しか出来る人がおらず、重大タスクにアサインされたメンバーが爆死するのを指をくわえて見つめることしか出来ないチームメイト……という構図が出来上がっていく。もちろん、代わりに問い合わせ対応を取るとかそういう間接的（かつ、超重要！）な貢献はしているのだけど。
そんな中、4月から新しいチームで新しいプロダクトを作るというチャンスが舞い降りてきた。しかもリーダーを任せてもらえるということだったので、これは大チャンス。というわけで、冒頭に書いたような進め方をやらせてもらった。まずは遅さを許容し全作業を同期的に全員でモブプロ・モブ作業するという制約を設けた。チーム内での目線を合わせるためだ。ここでいう目線を合わせるとは、開発対象の事業やプロダクトはもちろん、プロセスや互いのスキルセットなどチームに関わる全てだ。そしてみんなの目線が合ったところで徐々に制約を外しつつ、最終的にはその瞬間で最善の手をチームで話し合って決めて取る、というやり方をとった。
その瞬間の最善を取る、を愚直に実行しているので、さっきまでやっていたタスクのペアを組み替えてやる、なんてこともある。そういえばスプリント初日に切ったチケット通りではうまくいかないということが判明して、いきなりチケットの書き直しをしたこともあった。それでもコンテキストスイッチのコストを最小限にすることが出来ていると思っている。これはスプリントゼロで設計・ドキュメンテーションをじっくりやったことに加えて、開発開始以降もチケット作成・見積りやプランニングにしっかりと時間をかけてみんなの目線を揃えたからこそだ。
スクラム開発の三本柱に透明性・検査・適応というのがあるけれど、この1ヶ月はまさにこのループをうまく回せていたんじゃないかという気がしている。やるべきことについてみんなの目線を揃えチケット化するというのは透明性を確保するということだし、透明性があれば問題が小さなうちから検査で発見することが出来る。正しい検査で小さなうちに問題を発見できれば、それだけ適応もしやすい。透明性・検査・適応が大事、という話はそれこそ耳にタコができるほどされてきたけど、それらが担保された状態がどういうものなのかを体験したことがなかった。そして今回、体験することが出来た。
これは僕たちチームにとって非常に大切な成功体験だと思う。僕に進め方を任せてくれた上司、スピード低下を受け入れ属人性排除のためのチャレンジをすることを許してくれたPdM、そして常に自分たちの仕事を良くしたいという気持ちを忘れず、共にプロセスにフォーカスして改善することに付き合ってくれたチームメイトに感謝だ。
あとは、この流れを今後も継続し改善していくことが重要だ。正直、今回は新しいチームかつ全く新しいプロダクトでまっさらな状態から始めることが出来たからうまくいった（と思っている）だけなのでは感もある。だから、今回得た成功体験を元に、なぜうまくいったのか・もっとよく出来るところは何かを振り返って、再現性を持たせる必要がある。たまたま今は新規プロダクトの開発に集中させてもらっているけれど、徐々に既存プロダクトの改善や運用保守業務も入ってくるし、この新規プロダクトですらしばらくしたら改善フェーズに入っていく。チームのメンバーだって今のまま変わらないとは限らない。
人間にとって、これまでのやり方考え方を変えるのは非常にコストがかかる。他人から求められるならなおさらだ。今までの僕は人にやり方考え方を変えることを求めるばかりで、そのコストを払ったその先についてきちんと説明出来ていなかった。今回のこの体験によって、コストを払ったその先のベネフィットを得ることが出来た。これで今までよりは少しくらい高精度な説明が出来るようになるだろう。
この1ヶ月とても大変だったけど、上記の成功体験を得ることが出来たのは、僕のキャリアにとって、そしてチームにとってなかなか良い通過点だったと思う。
