「スモールチーム」による、ヤフーのアジャイル開発
変化の激しい社会情勢に対応し、的確なサービスをスムーズに提供するための開発手法として「アジャイル開発」は広く普及しつつある。ヤフーでも、荒瀬氏をはじめとする導入リーダーが現場チームへの導入・改善サポートなどを行い、アジャイル開発の積極的な活用が進みつつあるという。
ヤフーでは、アジャイル開発を実践中のチームの大多数が、手法としてスクラムを採用している。荒瀬氏はその理由として、まずフレームワークが明確で、未経験者でも導入しやすく成果を上げやすいこと、さらにヤフーの組織体制になじむことを挙げた。ヤフーでは、現在プロジェクト単位で少人数チームを構成、いわゆる「スモールチーム」でアイデアから運用まで一括して担当するスタイルをとっている。そうすることで、ものづくりに必要な権限をメンバーに委譲し、かなり自由度が高いジャッジが可能だという。そうした組織体制がスクラムに向いているというわけだ。
現在、ヤフー社員の半数に当たるクリエイター、約2500名のうち48.3％がスクラムを用いたアジャイル開発を実践している。2010年に導入を開始し、いわゆるイノベーター理論でいけば、アーリーマジョリティからレイトマジョリティに差し掛かる時期、普及期に突入したタイミングだ。そのため、自然に普及が進んでおり、荒瀬氏ら推進チームの仕事は改善活動へとシフトしつつあるという。
アジャイル開発の普及活動とチームに訪れた4つの変化
それでは、導入後、これまで約6年間のアジャイル開発普及活動はどのように行われたのか。また、アジャイル開発を導入したチームには、どのような変化が表れたのか。
当初、アジャイル開発を導入する前は、プロダクトマネジャーとチームが分かれていた。プロジェクトマネジャーは「何をつくるのか」というプロダクトの定義を考え、チームは「どうつくるのか」と考えプロダクトを製品化する。つまり、プロジェクトマネジャーから依頼が来て、チームが製品化するという分担だった。それがアジャイル開発チームとして一つになったことで、ともに「何を作るか」「どう作るか」を考えるようになり、さらには、全員が「なぜ作るか？」を考えるようになったという。つまりはチーム全員でプロダクトマネージメントをするようになったわけだ
荒瀬氏の体験によると、変化の傾向は4段階あったという。1つめは、チーム状態が可視化されたことが挙げられる。アジャイル開発前は職種やコンポーネントが分かれており、メンバーにとって必要な情報は、担当箇所に影響があるコンポーネントの作業進捗や作業結果のみ。つまりは、担当外の作業内容や全体の進捗は気にしない、気にならないのが普通だった。
しかし、アジャイル開発導入後は、コンポーネントごとに担当者を固定せず、優先順位の高い要件にメンバー全員で取り組むようになる。つまり、第一の変化として、全員が全ての内容、進捗、結果を把握することになり、状況が可視化されたわけだ。
次に現れた変化が「開発サイクルの安定化」だ。スクラムという開発手法においては開発サイクルが固定化される。いわゆるスプリントと呼ばれる期間だ。スプリント期間はプロダクトを取り巻く環境に依存する、例えばリモートワークで顔を合わせる機会が少ないチームはスプリントを１週間に設定しコミュニケーション頻度を増やし、同じロケーションで腰を据えて作業に取り組みたいチームは2週間を採用する。いずれの期間にせよ「作業のムダはどこ？」「もっと良い方法は？」などを繰り返し、自分ごととして捉えることにより自主的に開発プロセスを改善するようになったという。
「たとえば、ものづくりには、広報や営業等いわゆる社内のステークホルダーと協力し合う取り組みが多いが、ワークスタイルが異なる彼らとの調整は困難だ。そこで、定例化したレビューミーティングを設け、確認の工程を効率化したり、さらにメンバー間の依存タスクによる待ち時間を極力減らしたりすることによって、 このようなムダの改善により開発サイクルが安定し、チームはリズムを掴み、開発サイクルが速くなっていく」（荒瀬氏）
3つめの変化が「チームの自律」だ。サイクルが安定してくると、チームに少しずつ余裕が生まれ、個人に関連する改善からチーム全体の改善へと視野が広がる。結果、自分たちでチームを良くしようというマインドに大きく変化するという。チーム全体の課題、たとえば、スキル向上や生産性、プロダクト品質といったものに目が届くようになり、チームの成長にチームが責任を持つようになる。
そして、最後の変化が「プロダクトマネージメント」だという。スプリントのプランニングにおいて、プロダクトオーナーは、「ターゲットユーザーについて」「ユーザーの抱える課題」「課題を解決することによりユーザーが得る価値」そして「価値の定義」を、計画時にメンバーに共有する。レビュー時、「ユーザーの課題を解決しているか」「ユーザーの価値を満たしているか」「開発チームとの認識の齟齬は起きていないか」の確認を行う。
このように計画とレビューを繰り返すことにより、開発チームはプロダクトオーナーの描いているビジョンを共通理解するようになるという。そうなったとき、開発チームがビジョンに沿ったアイデアを提案するようになってくるだろう。つまり、全員がプロダクトオーナーの視点でものづくりをするようになるというわけだ。
