やって良かったアジャイル開発。でもたいへんなことも……

株式会社ソニー・ミュージックエンタテインメントで業務アプリケーション開発のプロジェクトマネジメントおよびリーダーを担当している[そると]です。よろしくお願いします。

私の部署では業務アプリケーションを担当しており、多くの案件でウォータフォール開発が採用されています。今回はそうした中でアジャイル開発を試したあれこれをお伝えできればと思います。

どのような業務/経緯でアジャイル開発を試したのか

今回取り上げる案件は「音楽配信」に関するものとして、以下の情報を管理するシステムの開発です。

• どのアーティストが
• どんなタイトルで
• いつから
• どこのプラットフォームで配信するか

数年前よりサブスクリプションサービスが主流となっているように、音楽配信を取り巻く業界内の変化は早いというのが現状です。

もちろん、ソニーミュージックも以前より音楽配信を行っていますので、既存のシステム基盤はあるのですが、「CD/DVDを想定して設計されている」「追加改修を繰り返したことによる複雑化」という課題を抱えていました。

そのため、以下を目的としてシステムリニューアルを行いました。

• 市場/業務の変化に即応できるシステム構成
• 「配信」を主軸に置いた業務フローの再設計
• ディレクターや制作担当者らが入力で迷わないためのUI/UX向上

まずは【ウォータフォール開発】でやってみた

冒頭で述べたように、私の部署で採用されている開発手法がウォータフォール開発のため、初期開発では従来と同じフローで着手していました。

ウォータフォール開発において、（とくに私の立場で）最も重要となるのが「要件定義」フェーズになります。この時点でどれだけ具体的かつ詳細に業務フローおよび必要な機能を洗い出せるか、というのが腕の見せ所になりますが、ここで大きくつまずくことになりました。

たとえば……

• 既存システムの設計書がない
• ソニーミュージックの最上流システムとして周辺システム連携が複雑
• 各部門での要望が相反する、かつ潜在ニーズをタイムリーに引き出せない

こういったさまざまなハードルを乗り越え（今回の記事の主旨とは異なるのでここでは割愛します）、開発開始から1年後にリリースできました。

次は【アジャイル開発】を試してみた

新システムリリースにより音楽配信タイトルを拡充することができた一方、システム保守では新たな課題が生まれました。

というのも、先ほど述べた「要件定義でつまずいた要因」を内包したまま、再び複雑なシステムを構築してしまったためです。

約1年間の運用保守を経て、上司たちに「データベースを再構築しつつ、システム拡張性/保守性を担保するためのシンプルな構成」「より使いやすいUI/UXの実現」という目標を伝え、改めて開発プロジェクトが始動しました。

その際に、一番の課題と認識していた「各部門での要望が相反する、かつ潜在的な要望がある」をどう解決しようかとチーム内で検討を重ねました。その中で「エンドユーザーが要望を出すには実際に動く画面を操作してみることが必要なため、『アジャイル開発』で次々画面を作っていき、議論しながら修正していく方がうまくいくのではないか」という意見があり、開発手法を切り替える判断をしました。

以降、開発中の事例紹介となります。まずは苦労ポイントから……。

【アジャイル開発】で大変だったこと

１：開発パートナー会社探し

前述したように私の部署ではウォータフォール開発が主流でして、すでに取引のあるパートナー会社含めアジャイル開発の知見がなく、経験のあるパートナー会社探しからスタートしかなければなりませんでした。

２：開発スケジュールの並行

ウォータフォール開発において、私の部署のメイン業務は「要件定義」と「プログラム受入/検収」になります。つまりは、最初に業務フローの整理やシステム開発の内容を確定させ、最後にそれが実現できているかの確認をするということです。

アジャイル開発においては、上記を開発期間中繰り返すのが基本となりますが、開発サイクルを並行させすぎてスケジュールが詰まってしまう、ということもありました。

【アジャイル開発】でうまくできたこと

１：エンドユーザーとのコミュニケーション改善

ExcelやAdobe XDで作成した画面サンプルを見ながら話していても、要件確認先のエンドユーザーが手元で試せないため、要件定義フェーズでは意見が出なかったのに、ユーザー受入テストで追加要望がどんどん出てくる、というのがウォータフォール開発でありがちなことかと思います。

これに対してアジャイル開発では（多少のバグがあろうとも）動く画面をエンドユーザーに次々渡すことができるため、「最初はいいと思っていたが、やはり見直したい」「ここも困っていることを思い出した」といった要望を開発途中で拾うことができるようになり、そのつど、対応したり、次回開発で対応することにできたりといった仕分けと説明が早い時期に行えました。

エンドユーザー側からしてみても、これまではユーザー受入テストまで「実際にどうなったか」がわからなかったのですが、定期的に確認できるようになったことで、不安感も軽減できたと思われます。

２：要望未確定でも開発が進む

もちろん要望/要件が確定していることがベストではあるのですが、本件のように利用する関係者が多い案件では、その調整にかなりのコストを要していました。たとえば、毎週の打ち合わせで画面イメージを持っていき、次週に修正したものを持っていく……というものです。

その点、アジャイル開発では「この部分は確定している」「共通パーツを先行で開発する」といった、作れるものから作っていくという発想でタスクが並行できるため、プロジェクト全体で見るとスケジュール短縮できるメリットがあります。

アジャイル開発には向き、不向きがある

ここまでアジャイル開発への経緯や事例について述べてきましたが、まとめると案件やパートナー会社、チーム構成によって向き/不向きがあると感じています。

というのも、本記事のアジャイル開発は「フロントエンド開発＝UI開発」のみを対象にしていまして、バックエンド開発はウォータフォール開発を採用して現在も進行中です。

要望/要件が明確に決まっていて、スケジュールに余裕がある場合は、品質担保の観点からもウォータフォール開発が向いていると考えています。

本記事で取り上げていたアジャイル開発の特徴としては、システム側とエンドユーザーの【距離の近さ】があると思います。これまでの開発では、エンドユーザーは要望を言うだけ、システムは作るだけ、という構図ですが、【ひとつのチームとしてより良いものを作り上げていく】という共通認識を持つことができたなら、特に画面開発といったエンドユーザーに近い部分は効果を発揮できると感じています。

このように、アジャイル開発についてはメリットがある一方で、「終わりが決めにくくスケジュールと費用が膨らみがち」というデメリットもあります。

プロジェクトのゴールを決めて、チーム内（プログラマー、エンドユーザー含む）の業務調整をし、スケジュール＆予算内におさめる、というかじ取りが要求されますので、プロジェクトリーダーに求められる役割が増えると思われます。要件がコロコロ変わるのもアジャイル開発の特徴の1つであるため、そこをうまくハンドリングするスキルなどがあるとなお良いかもしれません。

最後に

ソニーミュージックグループは、考えていることをきちんと伝えればGoサインを出してくれます。

新しいことを試すことが好き/何かを変えるのが得意という方、一緒に働けるとうれしいです！