au Webポータルをスクラムで 100 Sprint 廻してみて思ったこと

こんにちは。メディアシステム開発部の土方です。

最近社内でも色々なプロジェクトに関わらせていただくようになったのですが、その中でも長く携わっているプロジェクト、「au Webポータル (スマートフォン版)」についてご紹介させていただきます。

上記サービスでは開発プロセスとしてスクラムを採用してもうすぐで丸3年になります。先日100Sprintを超えたということもあり、ちょっと振り返ってみようと思います。

「スクラム」「アジャイル」自体の情報は本もたくさん出ていますし、 検索すれば簡単に触れることが出来ると思うので、 そのあたりの用語や概念はそちらに譲らせていただき、 ここでは現場での自分の体験や思い出を中心にお伝えしたいと思います。

はじめに

まず、現時点での開発プロセスの選択思想は大筋以下となります。


要件の内容や優先順位が1週間/2週間くらいの周期で変更され続ける開発現場で、

  • より効率的にアウトプットを出したい。
  • 継続的にアウトプットを出し続けたい。

そのために、

を大事にして、

  • 「アジャイル開発ソフトウェア開発手法」の一つとして
  • 「スクラム」のプラクティスを採用しています。

という整理です。  
 
時系列的にはなんかイイ開発手法らしいぜ→「スクラム」のプラクティスを導入。それから開発宣言や原則を学んで理解していった、という流れなのですが、、チームが自己組織化されていって、チーム内部で定期的に細かな改善が為されるようになっていったのは、開発宣言/原則 に触れるようになってからじゃないかなと感じています。

なので、いま実践しているけどなんか上手く行かないなぁ、 と思ったら、プラクティスやTODOを確認するのもいいんですが、 まずは何のために何を大事にしてどうやってるんだっけ?ってアジャイルソフトウェア開発宣言、アジャイル宣言の背後にある原則から振り返ってみることをお勧めします。ただ妄信的にプラクティスをやるだけじゃなくてそのプラクティスの意味を考えなおす機会にしたらいいんじゃないでしょうか。先週も朝会で使っているカンバンが、形骸化してうまく対話の元になっていない気がしたので改善しないとね、と話をしてみました。

100Sprint体験記

導入期(2013/08頃):

この時期に乗り越えた壁:導入

乗り越えるための鍵になったこと:
上役からの支援、これまで達成してきた成果などから、関係者に信頼してもらって導入に協力してもらった、という感じです。やっぱり新しいこと始める時に銀の弾丸って無いですよね。参考にならなくてゴメンナサイ。

思い出

開発チームとして「スクラム」を導入したい!と提案

「要員が固定されている(社内特有の事情による)のに、納期と要件ありきで激務続きだと長期的にはチームが保たないよ!要員を固定しているんだから、作業量が増減したらリリース日が一緒に動くっていうことだよ!」というメッセージとともに、「スクラム」は無駄な開発を抑止して、効率的により多くのユーザバリューを届けるためのよい手法で、要件変更が頻繁に起きる現場に適切だ、と説明した記憶があります。

もちろん、「約束したリリース日を後から調整するプロセスなんておかしくないですか?」などの質問含め議論になりました。いままでのウォータフォールのプロセスで考えたらそれは真っ当な疑問。

でもプロジェクトは現実に色々変更が起きるの常だし、メリットデメリットを整理した上で、納得してくれてとりあえず導入してもらうことにしました。リリース日は一度決めたら変更が困難であるということなのであれば、
最初にそれよりも短い期間でバーンダウンしきれるように計画/提案することにしました。

当時の印象的な調整

「リリース日はもっと細かく出来ないの?文言変更とかどう考えても3営業日もあればできるでしょう?」

確かにそれだけみればそうですよね。でも当初はできるだけ断ってました。
Sprintを1week単位に設定して、細かく要件の状況をヒアリングできるようにチームのリズムを設計はしたものの、チームのリズムや、開発者達が継続的に安定してアウトプットを出すことを大事にしようとしたからです。
どこまでは割り込んでいいのかの基準が曖昧になっていって、際限なくイレギュラーな割込みが入り込むことでリズムが崩れることを嫌ったというのが正直なところです。

でもいま振り返ると、スクラムのプラクティスに偏重していてアジャイルソフトウェア宣言に従ってなかったんじゃないか、とも思ったりします。この辺りの時期はお客さまや社内のプロダクトオーナー役によく我慢してもらったと思います。

講師を招いてアジャイル研修会

開発担当だけではなく、ディレクション担当も含めてアジャイル研修会を受講しました。何となく社内でも「アジャイル」という用語が認知されるようになった頃かなと思います。

学習期(2013/10〜2014/03):

この時期に乗り越えた壁:教科書からの脱却

乗り越えるための鍵になったこと:
私が頭でっかちタイプなので、本を読んではそのプラクティスを極力厳密に適用しようとしていました。スクラムを実施する際の細いルール(例えばユーザストーリーの書きっぷり)に拘って、現場が疲弊しがちだったんですが、講習や勉強会など様々な実践例などを聞いて、現場現場でやり方は工夫していけばいい、教科書通りにしなくてもうまくいくまで改善すればいい、とわかってきて少し肩の力を抜けるようになった気がします。拘るべきはプラクティスじゃなくて、ユーザに継続的にvalueを届けるにはどうしたらよいのかいつでも考えるコト、困ったり良くないことがあったら改善していけばいいんだというコト、に気が付いてきました。

思い出

とにかく試行錯誤

「SCRUM BOOT CAMP THE BOOK」や「アジャイルサムライ」を読みながら、ああでもないこうでもないと実践と改善を繰り返していたように思います。社内で同じようにスクラムを採用しているチームのメンバと情報交換などしながら、デイリースタンドアップについて議論したり、計画/振り返りのMTGが長くなりがちなのでバックログの精査のタイミングを調整したり・・・ととにかく手探りですが意識的にトライアンドエラーをしていました。

安定期(2014/08〜2016/03):

この時期に乗り越えた壁:お客さまに「スクラム」を認知してもらう

乗り越えるための鍵になったこと:
プロダクトオーナー役兼お客さまとの調整役から、粘り強く「スクラム」によるメリットを伝えて続けて貰った結果、一定の理解と協力を頂けるようになりました。

具体的には、

  • プロダクトバックログの優先順位の整理実施の協力
  • ベロシティを基に各要件のリリース時期の見通しが分かることの理解
  • 割込みでの要件差し込みはなんらかのタスクとのトレードになること

など。

納期ギリギリまで頑張りきったけどやっぱり無理です、ということが減り、 どうして計画を変更しないといけないのか、が伝わりやすくなったのが大きいように思います。これにより、安定/安心して開発に集中でき、チーム内での信頼関係の構築、変化への対応力などが改善されたように感じていました。

思い出

チームに自律性が育ってきた

要員を固定する、とはいったものの、ベロシティを中長期的に増大させていくため、メンバが徐々に増大していき、徐々に情報共有のコストが高まり始めた時期でもありました。メンバの入れ替わりもありましたが、全体の仕組みが定着してきているので、新規参画メンバも比較的すぐに慣れることが出来るようになってきた時期だったように思います。

チームの要員が増大することで出てくる問題も、以下の様なチーム内での改善で対処するようになりました。

  • デイリースタンドアップで、今日のTODOと合わせて帰る時間を宣言する→忙しさが何となく伝わる→助け合える
  • Sprintの途中で全員の進行状況を明示的に確認する係を立てて、輪番で廻してみる
  • 開発の時間をよりまとめて確保するためにSprintの単位を1週間から2週間に変更してみる

変動期(2016/04〜):

これから乗り越えないといけない壁:

お客さまの担当変わっちゃったし、その流れでデカイ要件がガッツリ納期ありきで入ってきた!(これまでの現場のアウトプットのペースは評価されていないのかも!?という不安とともに)

乗り越えるために頑張ってること:

  • なぜその納期でこの要件をやり切らないといけないのかについて、開発メンバへの説明
  • 要員を急激に増員してもアウトプットは急激には上がらないことをお客さまに説明
  • タスクを分割して作業量の見える化
    → 達成できるアウトプット量を見える化することで、優先順位下位の要件の整理
  • デカイ要件が変更なし、で進められるのであれば、細かく要件を変更するための時間は削減して良いハズ
    → タイムボックスのバランスを変更して一時的にでもアウトプットを上げる

などなど・・・。

おわりに

アジャイルは死んだ?

アジャイルは死んだ、なんて記事をよく見かけるようになりました。「アジャイル宣言の背後にある原則」は全面的に正しいかと言われるとちょっと悩ましいところもあるものの、いまのところは出会えてよかった考え方だなと感じています。開発のプロセスやプラクティスは解決したい課題や状況に応じて選ぶべきものとは理解しているつもりですが、スクラムは細かく情報共有しながら進んでいくので、楽しいなぁと感じることが多く、もうしばらくは贔屓にしたい気持ちです。会議の時間がちょっと多すぎる嫌いもあるので、そのあたりはプロジェクトごとに調整しながら、ですね。

また、アジャイル/スクラムを通して、小さく速くPDCAを廻していくことが如何に大事なのかを考えさせられることが多いです。100Sprintを振り返るにあたって、導入、学習、安定、変動と分けてみたものの、考えたらいつもその瞬間は変動期だったなぁと思います。イライラしながらストレスフルにお仕事している時間は勿体無いから、上手くいかなかったら継続して改善していくしかないですよね!

求む!永続改善スタイルエンジニア!

ということで、medibaでは、共に問題を見据えて改善に取り組み続けることが出来るエンジニアを求めています。少しでも興味を持って頂けましたら募集ページより詳細をご確認頂けるとなによりです。