チーム運営の現在地 - 「真のアジャイル開発」を超えて（2024 Advent Calendar 25日目）

この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の25日目の記事です。このアドベントカレンダーは「ある機能開発チームでスクラム, XP, DevOps を一度に実践したら真のアジャイル開発ができた」という内容です。執筆者は全てプログラミングをするパンダです。

「真のアジャイル開発」の経験に基づくチーム運営

25日間続けたアドベントカレンダーのラストは、「真のアジャイル開発」ができたという経験を活かして自分がどのようにチームと向き合っているのかという姿勢を紹介します。

このアドベントカレンダーで紹介したプロジェクトの後、ある新規機能を開発するプロジェクトにアサインされました。チームメンバーはままです。そこにもう一つ別のチームが合流しました。合計2チームで1年半、リリースを3回に分けて実施した大きなプロジェクトでした。

エンジニアリングマネージャーの提案により大規模スクラム（LeSS。Large-Scale Scrum）の手法を取り入れ、2チームでスクラム開発をしました。プロダクトオーナーとデザイナーとエンジニアたち全員が一緒になって仕様を策定するところから始まり、数日間かけてユーザーストーリーマッピングという、ユースケースをユーザーストーリー形式で記述して全て洗い出して見積もりをしました。すると2年かかるという見積もり結果になりましたが、結果的には1年半でリリースができました。

自分はこのプロジェクトにシニアエンジニアとして参加しました。ドメインモデリングやデータモデリングを主導したり、フロントエンドのコードを書いたり、バックエンドのコードをレビューしたり、一歩ずつ後ろに下がっていったスクラムマスター（エンジニアリングマネージャー）の代わりにスクラムイベントをリードしました（ただし、流石に2チームとも全部は見切れないため、1チームに主軸を置いてもう1チームは別のメンバーが主導していたため自分は統括の役割をしていました）。

開発期間は1年半、関わった人はプロダクトオーナー2名（メインとサブ）、デザイナー3名（同時ではなくフェーズごとに入れ替わり）、エンジニアはヘルプの方も含めて10名以上の関わった長いプロジェクトでした。もちろん全てがうまくいったわけではありませんでしたし、自分も「新人シニアエンジニア」として未熟なところから色んなことを学ばせてもらった1年半でした。

この大きな機能のリリース後、今は別の機能開発チームに所属しています。このチームは自分も含めてエンジニアが5名で、そのうち新入社員が2名という構成です。2024年の5月ごろから本格的に開発が始まりました。2024年の年末の今はリリースに向けて佳境です。そんな中でまた自分は別のプロジェクトにアサインされ、今は開発を進めつつ兼務で両方のチームを見ています。

チームメンバーによってチームのあり方は様々である

前出の1年半にわたる機能開発が終わった2024年2月ごろ、自分はある程度のプロジェクトならうまく回せるだろうと思い込んでいました。しかし、それは過去に学んだことを適用するだけであり面白みがありません。どのようなメンバー構成であったとしてもうまくいくチーム運営の手法はないだろうか、その手法は自分がすでに体得して使いこなせる手法の外に何かないだろうかと漠然と考えていました。

このように考えていたところ、「哲学対話」という身近なことをテーマにした実践的な哲学の手法（当初は子供のための哲学として考案された手法です）を実践するサークルに参加した時に、ああ、求めていたのはこれだと思いました。哲学対話の詳細は省きますが、会話の中で知っていると思っていたことを改めて探究すると言う哲学対話を実践することで、結局自分は何も知らないのだな、自分も知らないし他の人も知らないのだと言う感覚を得ました。ソクラテスの無知の知（不知）です。

そして人は知らないからこそ探究するのです。「すべての人間は、生まれつき、知ることを欲する」とは大哲学者アリストテレスの言葉です。知らないからこそ、知ろうとする。知っていることで現実に対処するのではなく、知っていると思っていた現実に改めて向き合って、現実をつぶさに観察してより良く知ろうとする態度、それを元に考え抜く態度。これこそが哲学的な姿勢だと理解しました。

この姿勢が重要なのはチーム運営でも同じです。

チームメンバーの一人一人を知り、チームに合わせて適切な手法を選ぶ

ここで紹介したプロジェクトでは、スクラム、XP、DevOpsをすべて一度に実践しました。しかし、「ゆとり」の項目で紹介したように後半はペアプログラミングばかりだと自分一人の時間がなくなると疲弊したメンバーもいました。彼は鋭い発言をするし人に対して前向きなものの、物静かで考えるのが好きなタイプです。

このように、良いとされるプラクティスを最初から導入することは危険があります。そうではなく、チームメンバーの一人一人と向き合い、自己を開示して相手を知る対話をすることで、より良いチームを作ることができるのです。一人一人と向き合うという点ではマネージャーの仕事と似ているかもしれません。

例えばあるプラクティスを導入するにしても、一度チームで失敗してから導入することを心がけています。開発初期に取り返しのつかない失敗というものはほとんどありません。この時期にチーム内でたくさん失敗をした後、振り返り会で「ここは良くなかった」「どうしたら良かったのだろう」という疑問をチームメンバーが持つように見守ります。

チームの課題が一人一人の自分ごとになったら、人の課題を当事者として考えられるようになったと判断したら、自分が知っている手法の中から「こういうやり方をすると解決できそうだ。これをチームで実践してみるのはどうか」と提案するのです。その際に注意するのは、その課題が表出するきっかけを作ったのが個人であっても絶対に個人の責任にしないことです。

そうではなく、「これはチームの誰にとっても起きうる課題だった」と一言添えて、チームみんなで解決していこうと伝えるのです。これを毎スプリント繰り返していくことで失敗しても怒られない、怒られないから何でもチームに相談できる。怒られないから新しいことに挑戦しようという前向きな文化が形成できるのです。

しかも、チームに必要なプラクティスだけを自然と導入できるので、やっていても意味がないとみんなが感じるようなプラクティスは自然と採用されないことになります。こうすることで「儀式」に時間を取られることを避けられるのです。

自分はこれを積み上げ型のプラクティス導入と呼んでいます。最初から「ずっとペアプロをしよう」など決めてしまって、チームメンバーそれぞれの特徴を考慮せずにトップダウンでプラクティスを導入してしまうのは悪手です。積み上げ型のプラクティス導入をしたチームは、その時の自分たちにフィットしたプラクティスだけを実施します。このようなチームは導入したプラクティスにより弱みを押さえ、強みを伸ばすことになるため、より強いチームになります。

良いチームのあり方は一通りではない

いいチームを作るためには何をすればいいのでしょうか。それはチームビルディングです。チームビルディングをしっかりしましょう。

チームビルディングがうまくいき、これを言ったら馬鹿にされるかもと恐れることなくチームで発言ができる心理的安全性が醸成されたら、そして「これ何か変だな」「これもっとうまくやれるな」と感じたことをチームで改善を続けることができたら、人間関係の面倒さはほとんどなくなってしまいます。

人間関係の面倒さがなくなると、チームみんなが開発に集中できます。開発に集中できるとベロシティが安定し、リリースの見通しが立てやすくなります。すると突発的なことにも柔軟に対応できますし、誰かが困っている人を助けるというチームワークも発揮できるようになります。そうなれば、みんながいいチームだと言ってくれるようになるでしょう。

トルストイのアンナ・カレーニナは「すべての幸せな家庭は似ている。不幸な家庭は、それぞれ異なる理由で不幸である」という有名な書き出しから始まります。チームメンバーの一人一人と向き合うことができると、次の言葉の意味も自ずと明らかになるでしょう。

「いいチームの作り方は似ている。しかし、いいチームはそれぞれ異なる理由でいいチームなのである」

以上、「私をシニアエンジニアにしてくれた『真のアジャイル開発』体験記」でした。25日間にわたってお読みくださり、ありがとうございました。