2015.10.28

失敗から学ぶアジャイル開発

皆様こんにちは、アジャイル開発推進担当の川上です。本日はKDDIのアジャイル開発の現場から、いくつかの失敗談をお伝えしたいと思います。これまでは、うまくいった点や、工夫した点を中心にお話してきましたが、あえて失敗例をお伝えすることで、皆様の気付きになればと思います。

1.プロジェクト立ち上げ時のベロシティ(開発速度)の問題

図4 グラフは、プロジェクトのスタートから1stリリースまでのストーリーの消化曲線です。見てお分かりの通り、初期は全くストーリーを消化できませんでした。当然、PO(プロダクトオーナー)やマネージメント層から、顔を真っ青にして「このままでは終わらないじゃないか」という指摘を受け、最初から頓挫するのではという懸念の声が多数上がりました。実は始める前から、開発環境の構築、CI環境の構築、初対面のプロジェクトメンバーによる不慣れなコミュニケーションの中、最初の1ヶ月ぐらいは、ストーリーは思うように消化出来ないだろう想定はしていました。しかし、その想定をふまえた消化曲線を、関係者へ共有していなかったため、「想定と違う」、「大丈夫か?」という騒動を起こしてしまいました。チームメンバーがどのようにアジャイル開発に慣れていくのか、いつの時点で、どれくらいのストーリーを消化できる見込みなのかという情報を、関係者と合意するという手間を怠った為に、プロジェクトの推進が危ぶまれる状況になってしまいました。進捗が芳しくなく見えることには、ほかにも理由があり、まず「ストーリーの規模が大きすぎる」こと、「機能開発に含まれないタスクを、開始当初は見える化できていなかったこと」です。

ログイン機能を作成する場合に、当然IDとパスワードを入れる必要があります。ログイン時にパスワードを規定回数以上失敗したら、IDをロックするような機能も必要になるでしょう。しかし、それを「ログイン機能を作る」という一つのストーリーで実現しようとすると、ログインに関する非常にたくさんの機能を作りこまないといけないですよね。

そのため、最初は
1.「IDとパスワードを入力して、パスワードがOKだったらログインさせる」というストーリーを作り、次に
2.「パスワードが失敗した数をカウントし、一定回数以上でステータスをロックする」
というストーリーに進むとし、仕様をリリース可能な単位で分割し、機能を実現する方法を取りました。

CI環境の構築、リポジトリの作成、開発ルール決めのミーティングなど、直接機能の開発のストーリー消化には影響しないものも、開発チームのリソースを利用することになるので、一つ一つのタスクをチケット化することをルールとしました。これらの失敗から、「プロジェクトスタート初期に試行錯誤をする期間が必要であることを関係者と共有する」開発環境を構築するため、維持するためのタスクもチケット化する」というプラクティスがここで生まれました。とはいえ、いつまでたってもストーリーが消化されないのは、別の原因があるのでKPT(振り返り)をきちんと行い、チームの生産性を上げる施策や改善を繰り返しましょう。

2.市場動向や他社の動向のウォッチと反映タイミング

2

Before

「管理者が利用するUIは、日常的に使う機能ではないので、機能とUIでは機能を揃える方が優先度は高いよね」
メンバー間の合意で、トレードオフスライダー相互にトレードオフの関係)を設定し、開発をスタートをしました。ただ3ヶ月後に実際に出来上がったものを冷静に見直してみると、「このUIでは、わかり辛いのではないか」という雰囲気になり、作り変えるコストとスケジュールをどうするかの議論を重ねた結果、残りコストをできる限りUIの一新を行うことを決定しました。

3

After

また、「この機能、1stリリースでは要らないよね」と話していた機能についても、競合サービスが導入を決めたため、「他社劣位があると、お客様に説明し難い」との営業の声に合わせて、急遽導入を決定しました。この例については、市場動向に合わせて機能開発できるアジャイル開発だからこそ、失敗から早めに方向転換し、改善に繋げられたいい例だと思います。

3.ステークホルダーとの連携不足

KDDIが採用しているスクラム開発において、PO、開発チーム、スクラムマスター以外は、全てステークホルダーという扱いになります。弊社のような規模の会社では、当然ステークホルダーも膨大な数になります。そして、ステークホルダーの中には、多大な影響力を持つ人(商品を企画する際に、作る人、運用する人、売る人と大きく役割を分けた際に、その役割に影響を与える人)もいます。特に導入初期や、プロジェクト初期のアジャイル開発を上手く回すには、この影響力を持つステークホルダーにこそ、プロジェクトに関わってもらうことが重要かと思います。商品を売る人であれば、実際の営業担当だけではなく、営業担当のマネージメント層も巻き込むことが必要です。KDDI Business IDの開発過程においては、ユーザーインタビューの結果を営業担当、マネージメントともに共有し、お客様へ響く提案内容を一緒に作り上げました。

アジャイル開発では、ウォーターフォール開発と違って、製品が徐々に出来上がっていく姿を見せる事が出来るのが強みです。ちょっと変な例かもしれませんが、ステークホルダーに、アジャイル開発の成果物を、孫が育っていく姿を見守るおじいちゃん、おばあちゃんの気持ちになってもらうことが重要です。子の教育は親が責任を持つのだと思いますが、おじいちゃん、おばあちゃんはそれらを温かく支援してもらえますよね。

カテゴリ
タグ

KDDI株式会社 プラットフォーム開発本部
アジャイル開発センター

川上 誠司

新着記事
タグ
アーカイブ
カテゴリー
Contact
TOP