開発チームをゼロから立ち上げ、混乱期を乗り越え機能期に導く
山崎氏がヤフーに入社したのは、昨年の10月。「天神オフィスの立ち上げメンバーとして入社した」と言う。以来、Yahoo! JAPANのクレジットカード「Yahoo! JAPANカード」を管理するWebサイト・Yahoo!カードの開発に従事している。同プロジェクトは、Yahoo!カードのシステムをモダンにすることを目的としている。モダンにする理由について山崎氏は「機能の提供や改修を早く行うため」と語る。つまり従来のシステムだと、すばやい改修や機能提供がやりにくかったというわけだ。
まずチーム開発のフレームワークとして導入したのがスクラムである。スクラムのプラクティスはいろいろあるが、その中で山崎氏は朝会、ふりかえり、スプリントプランニング、スプリントレビューを採用したという。その理由について「チームメンバーとコミュニケーションを取る機会が増えるため」と説明する。システムが失敗する原因の多くはコミュニケーションがうまくいかないことによって発生すると考えているからだ。
チームの立ち上げから、現在の状態に至るまではさまざまな苦労があったという。Yahoo!カードのシステムは、もともと東京オフィスのメンバーが作ったもの。天神オフィスのチームが立ち上がったことで、2拠点で開発を担当することになった。立ち上げのメンバーは5名。天神チームには全容を把握しきれているメンバーはいなかった。そのため、Yahoo!カードのシステムについて、東京チームへのヒアリングの前に、まずはコードを読んで理解をしてみることから始めたという。
しかし、「そのコードが書かれた意図や背景が読み取れないことがたくさんあった」と山崎氏は続ける。そこで現行のYahoo!カードの開発、保守運用を行っている東京オフィスのメンバーとテキストチャットやボイスチャット、ビデオチャットを使ってコミュニケーションを取ったという。また長くなりそうな話や残しておきたい話は「GitHubのイシューを使った」（山崎氏）と明かす。このような方法でコミュニケーションを取っただけではない。「実際に会うことも定期的に行った」と山崎氏。そうすることで、その後のリモートワークがやりやすくなるからだ。
開発開始当初から2カ月経過した頃、チームが混乱期に陥ったという。混乱期とはタックマンモデルの定義にあるように、「メンバー間で考えや価値観の違いによってぶつかり合う状態」を指す。例えばシンプルに早く作りたい人もいれば、運用する人が困らないように作るのが大事だと考える人もいる。「バックグラウンドの違う人間が集まっていたため当然のことだった」と山崎氏は振り返る。
いずれの考えも正しいと認めながらも、どうすればタックマンモデルの機能期（チームに一体感が生まれ、チームの力が目標達成に向かう状態）に移行できるのか。そのために、チームの課題を見つけ、その課題に向けて全員で進むことを意識したという。
当時の天神チームの課題は、「開発スピードが遅いこと」だった。「開発開始から2カ月たってもプロジェクトオーナーが理解できるような成果物が出来上がらなかった」と山崎氏。その原因を探るため、山崎氏は自身の時間の使い方を分析した。現状を把握するためだ。そこで明らかになったのは、「開発時間が21％しかなかったことだ」と明かす。なぜ開発時間がこれほどまでに短いのか。その理由を考えたところ、チーム立ち上げ時にさまざまなイベントが発生したこと、学習時間が多かったこと、チームのやり方を統一するための認識合わせに時間がかかったことなどが頭に浮かんだ。
現状を把握したことで、定例ミーティングは極力しないことや、ミーティングは一気にやり、また決めた時間内にやり終えること、といった地道な改善に取り組んだという。
「課題はそれだけではなかった」と山崎氏。成果物やアプリケーションの構造、終わらない議論、レビューの手戻り、プルリクエストがたまるなどのチームが抱えるさまざまな課題についても、地道に改善していった。まずは成果物の課題について。山崎氏は「以前は成果物を意識することなく、基盤機能から作成しているため、せっかくの成果を見せてもプロジェクトオーナーには伝わらないことが多々あった」と言う。そこで開発する順番を変更し、まずはプロジェクトオーナーが理解できるところ（例えば、デザインを当てたトップページなど）から作るようになったという。そうすることで「フィードバックが早くもらえるといったメリットもあった」と山崎氏は話す。
次にアプリケーションの構造の課題。「当時はSpring Frameworkの上にドメイン層、インフラ層、サービス層といった形で、DDD（Domain-Driven Design）を参考にして3層構成にしていた。この構造のメリットは各層に役割を分担することで影響を制御できること。機能を変更しやすいことがメリットだった」と山崎氏は言う。しかしあるコードについてドメイン層とサービス層のどちらに置くのかなど、チームメンバーの中で各層の役割について混乱が生じていたという。そこでよりシンプルな構成にしてはどうかと提案。ドメイン層を取り払い、インフラ層、サービス層の2層にした。「レイヤーを減らしたことで、悩むことも減り、その分コードがたくさん書けるようになった」と山崎氏はメリットを挙げる。
また、終わらない議論の改善も必要だった。どうしても議論が長引き、終わらない原因の一つが、議論が発散してしまうことである。それを防止するため、まず行ったのはプロトタイプを作ってから議論をすること。また議論の内容をホワイトボードに書いて可視化することなどにも取り組んだという。
さらに、レビューの手戻りの課題。レビューの手戻りが何度も発生すると、開発効率が悪くなる。そこで「ペアプログラミングを導入した」と山崎氏は言う。ペアプログラミングであれば、2人で開発し、実装とレビューを一気に終えることができる。「手戻りの発生を抑えられることに加え、知識の共有もできる。特に詳しくない人と詳しい人というセットでやると効果が出る」と、今はペアプログラミングを積極的に取り入れているという。
そして最後はプルリクエストがたまるといった課題について。「プルリクエストされている件数を教えてくれるボットがあるが、なかなかマージがされない。レビュー待ちのプルリクエストがたまる状態だった」と山崎氏。そこでレビュータイムを設け、その時間はレビューに集中するようにしたという。
こういった細かい改善をしたところ、「開発スピードが大幅に向上。開発時間も当初の3倍に、ベロシティ（スプリントごとに消化したポイント数）も大幅に向上するなど、開発効率がアップした」と満足そうに語る。
改善がうまくいった理由は、「チームメンバーが自発的に改善を行ったから」と言い切る。ただ忘れてはならないのは、「正しいやり方は対話して見つけていくこと。そしてここで言う正しいやり方とは、チームにあったやり方のこと。それをメンバー全員で考えていくことだ」と山崎氏は強調する。
