開発チームをゼロから立ち上げ、混乱期を乗り越え機能期に導く
山崎氏がヤフーに入社したのは、昨年の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倍に、ベロシティ（スプリントごとに消化したポイント数）も大幅に向上するなど、開発効率がアップした」と満足そうに語る。
改善がうまくいった理由は、「チームメンバーが自発的に改善を行ったから」と言い切る。ただ忘れてはならないのは、「正しいやり方は対話して見つけていくこと。そしてここで言う正しいやり方とは、チームにあったやり方のこと。それをメンバー全員で考えていくことだ」と山崎氏は強調する。
モダンになったYahoo!カードのシステム。そこで採用された技術とは
このようなプロジェクトを通してモダンになったYahoo!カードのシステム。どのような技術が採用されたのについても山崎氏は解説した。変更前、変更後の技術は図をみれば一目瞭然だが、言語はPHPからJavaに、アーキテクチャはモノリシックからマイクロサービスに、サーバはVMからコンテナへ変わっている。
Javaを採用した理由の第一は可読性を向上するため。「Javaは型が厳格なため変数の値が明瞭になるからだ」と山崎氏は言う。第二はJavaのデファクトスタンダードのフレームワーク「Spring Framework」の存在。「Spring Bootが開発されて、開発がしやすくなったことも大きい」と山崎氏は説明する。
次にアーキテクチャをモノリシックなサービスからマイクロサービスへ移行したのは、次のメリットが得られるからだという。メリットの第一は、「影響範囲が限定されるようになるため」と山崎氏は説明する。例えば言語のメジャーバージョンアップをする場合、モノリシックサービスだと全体に影響するが、マイクロサービスだとサービス単位でバージョンアップができるようになる。「影響範囲が大きいと消極的になってしまうが、影響範囲が小さいと心理的にも安心で、積極的にチャレンジしていける」と山崎氏は言う。
2つめのメリットは、「テスト実行時間の短縮」である。現行のシステムだとテストが1分程度で完了するようになったという。だが、デメリットもある。それは「コードの共有がしにくいこと」。そこで共通コードをライブラリ化し、それを社内のリポジトリ管理ツール（Artifactory）で管理し、各サービスにダウンロードするような形で共有化を図っているという。さらにアプリケーション構築の初期コストの削減も実現している。「初期構築の手順のほとんどを自動化したことで、従来は2時間ぐらいかかっていた初期構築を、約30分でできるようになった」（山崎氏）
また、サーバにDocker＋Kubernetesというコンテナ技術を採用したことで、スケーラブル（アプリケーションのポッドを自由に増減できる）、オートヒーリング（障害が発生したポッドを自動的に削除し新たなポッドを作成するため、ポッドの障害に対応が不要）、ローリングアップデート（アプリケーションを無停止で更新できる）といったメリットが得られるようになったという。このため「サーバの保守運用が非常に楽になった」と山崎氏は言う。
それでも課題もあった。それは「IPアドレスが定まらないので、IPアドレスによるアクセス制御ができないこと」である。この課題を解消するため、ロールベースの認証システムに変更。ログはSplunkに集約し、アプリケーションログの検索や参照はSplunkで行っているという。
こういった刷新を行うことで、「扱いやすいシステムになり、開発スピードも向上した」と山崎氏は言い切る。
最後はアジャイル開発についても、山崎氏なりの考えが語られた。山崎氏はアジャイル開発を「やり方ではなく、より良いやり方を見つけていく姿勢だと捉えている」と言う。よくアジャイル開発をプロジェクトに取り入れると、それをやることが目的になってしまうことがあるという。プロジェクトのゴールは、あくまでもプロジェクトを成功させること。アジャイル開発はそのための手段でしかない。「アジャイルにこだわる必要はない。ゴールが達成できればチームにあったやり方をやっていけばいい」と山崎氏。
アプリケーション開発に正解はない。だが、ゴールに向かって工夫することはできる。そういう工夫ができるから「アプリケーション開発は楽しい」と熱く語り、セッションを締めた。
お問い合わせ
Yahoo! JAPAN
