従来手法で開発してきた社内でもっとも古いWebサービスを良くするため、お客様の要望を早く実現できるように意を決してアジャイルに取り組んだビジネスぐる地図チーム。Agile Japan2017で発表した『古参Webサービスのアジャイル化、DevOps化への奮闘記』の講演内容に基づいて、初めてアジャイルに取り組んだ時に突き当たった壁、それをどう乗り越えて行ったか、などチームの皆さんにお話を伺いました。チームワークの良さを感じる楽しいインタビューの時間でした。
チームメンバー
プロダクトオーナー
(株)オージス総研 髙橋 佑介
スクラムマスター
(株)オージス総研 西口 知久
開発チーム
(株)キューブシステム 山富 晃司
開発チーム
(株)キューブシステム 畑 和夫
今までのやり方では限界、アジャイルやるしかない！からのスタート
―― きょうは西口さんがAgile Japan 2017でお話しされた講演に基づいて、いろいろお話を伺いたいと思いますのでよろしくお願いします。
全員― お願いします。
―― 講演ではまず、アジャイルを始める前の状況として、プロダクトのリリース頻度が少なく契約数も伸び悩んでいたビジネスぐる地図チームが、お客様の要望を早く実現できるよう、意を決してアジャイルに取り組んだという話がありました。
出典) Agile Japan2017講演スライド『古参Webサービスのアジャイル化、DevOps化への奮闘記』
―― 通常、チームの中にアジャイルに否定的なメンバーがいることも多いと思うのですが、今回、メンバーの合意はすぐに取れたのでしょうか。
西口（スクラムマスター）― スクラムを取り入れることをメンバーに周知したのはキックオフの場だったのですが、そのときは「ふうん、それやるんだ」というような、批判的でもなく、かといって拍手喝采という雰囲気でもなかったです。
―― 特にプロダクトオーナーの立場になる方が、自分の仕事がどのように変わるのか気になるところだと思うのですが、その辺りはどうだったのでしょうか。
高橋（プロダクトオーナー）― そういう意味ではもともとアジャイルでサービスを開発したかったんです。西口君とやりたいねという話をしていて上司に話したらぜひやるべきだとなって始めたので、自分の中では全然抵抗はありませんでした。逆にそれまでのやり方の限界が見えてきたので変わらないといけないな、と。ビジネスぐる地図はサービスビジネスなので、アジャイルが絶対合ってるはずで、極端に言うと、アジャイルやって駄目ならもう駄目じゃないかなぐらいの気持ちで始まったものですね。
―― なるほど。比較的すんなり始めようということになったのですね。アジャイル開発を進めるにあたって教育はどうされたのでしょうか。
西口― みんな初めてなので何か教育をできるわけもなく、本を回し読んだぐらいですかね。
―― どんな本を読まれたんですか？
全員― 『SCRUM BOOT CAMP』！
西口― 声そろってます。『SCRUM BOOT CAMP』は分かりやすかったですね。他には『アジャイルサムライ』や『リーン開発の現場』などを読んだりしました。あとは行き詰まったら、アドバイザーとして、アジャイル開発や改善の現場に詳しい当社の山海さんが来てくれたので、そこはすごく心強かったです。
―― アジャイルを始めて、従来のやり方と異なったところなどありましたか？
西口― ものすごくありますね。少なくとも私は精神的にすごく楽になりました。自分で綿密に計画を立てたり、計画をやり直したりするのが大嫌いで、開発の中に入りたい人間なので、そこはすごく楽になりました。
―― プロダクトオーナーはもともとやりたかったので抵抗がなかったという話でしたが、開発メンバーの方はどう思われましたか？
山富（開発チーム）― 抵抗感は全くなかったですね。
―― 他のチームを見ていると、ベテランのパートナーさんの中には従来とやり方が変わると戸惑う方もいらっしゃるように思うのですが、そういうことはなかったのでしょうか。
山富― 始める前からアジャイルは結構いいと聞いてはいて、実際ほんとうに良くなるのか疑問はありましたが、私自身は一度やってみたいという気持ちがあったので抵抗感なく始めました。
畑（開発チーム）― 私自身は、お客様の価値が高まる方がいいとすごく思っていたので抵抗はありませんでした。ウォーターフォールだと一度計画すると後工程でこうした方が良かったとなってもなかなか対応できないところがありますが、アジャイルはチームで話し合いながら短いスパンで良い方向に舵を切ることができて、そういうところがいいと思っています。
初めてのスプリント計画、時間はかかったけれどチームの仕事の中身を共有できた
―― それで皆さんスクラムを実践し始めたわけですが、講演の話にあった最初のスプリント計画の話が衝撃的でした。
出典) Agile Japan2017講演スライド『古参Webサービスのアジャイル化、DevOps化への奮闘記』
高橋― あれはすごかったですね。
―― スプリント計画の参加者はどなただったのでしょうか。
西口― ここにいるメンバーと、当時は東京のメンバーがいたのでTV会議から参加して総勢7名でした。今思えばスプリントゼロとかスクラムの立ち上げのフェーズをすればよかったと分かるのですが、あの頃はスプリントを2週間で回すなら初日にスプリント計画をするものだ、とスプリント計画を始めたので、やってみたら全然終わらない！となったんです。
―― スプリントゼロを設定してもどれくらいの期間やるかというところで難しさがあるので、いきなりスクラムを始めることが必ずしも悪いことではないと思います。ただ、スプリント計画に3日間かかったというのがすごく不思議で、何にそんなに時間がかかったのでしょう。
西口― プランニングポーカーで、プロモーションとセールス、開発、運用という4種類のユーザーストーリーを全部出したんです。
―― チーム全体のユーザーストーリーを、開発以外のものも全部出したのですね？
西口― そうです。全部のユーザーストーリーを出すとプランニングポーカーで見積る前に、その仕事は何をしてるのか、という情報交換から始まります。例えばお客さんの所に提案に行きます、であれば、ただ単に提案書を作るのかというとそうではなくて、ヒアリングの準備などいろいろあるんです。そういう細かいところまで情報交換をしないとポーカーで見積りの数字が出せないんですよね。なのでポーカーを出す前の情報交換に時間がかかりました。どんな仕事があるのか、その仕事の中身は何なのか共有し合うというところが大きかったかな。
―― 3日間のうち大半の時間をそういうところに使われた？
西口― そうですね。あとはスプリントで何をやるか、細かいタスク割りですね。
―― お話を伺うと、それって結果的にはチームビルディングしてるようなもんですよね。
高橋― そうですね。プランニングポーカーで見積りすると、そのユーザーストーリーの有識者が結構大きい数字を出すんです。でも周りは知らないから小さい数字を出して「なんでそんなに大きいの」って聞くと中身はあれもこれもあって、と。「何だそんなの分かんなかったよ」みたいなことの繰り返しでした。東京、大阪だとそれがより大きいんですよ。大阪だと小さいけど東京だと大きいとか、逆もまたしかり。その仕事をやることに意義はあるけどお互い中身はよく分かっていないという状況でした。
―― 開発メンバーの方はそういう議論を聞いていて、自分が関わる開発とはあまり関係ないから退屈だなとか思われませんでしたか？
山富― ないですね。逆に今まで東京側でどんな作業をしているかが全く見えていなかったので、それが見えただけでも良かったですし、こちら（大阪側）がこんな作業でこれだけ苦労してるんだ、というのを東京側に分かってもらえたのも良かったと思います。
西口― あとはやっぱり仕事内容を聞いておかないと、その仕事内容が今後自分に回ってくるので。
高橋― みんな自分だけ守れてお互い知らなくてもいいやっていうマインドセットじゃなくて、いや同じことやってるんだから知っておかないとやばいよね、と多分思っていたと思います。
―― そこもすごいです。
西口― 少人数で運用やセールスを回していたので、正直一人でやるにはいっぱいいっぱいだったんですよ。みんながいっぱいいっぱいだったというのが本当のところだったんじゃないかという気はしますね。
割込作業に阻まれた、初めてのスプリント
―― 講演では、最初のスプリントでバーンダウンチャートが下がり切らず、割込作業が大きいことが原因だと分かったと言う話がありました。
出典) Agile Japan2017講演スライド『古参Webサービスのアジャイル化、DevOps化への奮闘記』
―― 最初から割込作業が大きいことが原因だということは見えていたのでしょうか。
西口― いえ、全く見えていませんでした。計画作業が8割、9割のイメージでスタートしていたのが、ふたを開けてみるとその逆だったので、いやちょっと待てよ、と。
―― それを定量的に把握しようとされたのはいつ頃だったのでしょう。
西口― スプリント2で計測しました。スプリント1がぼろぼろだったのでなぜだろうって話をしたときに、計画作業に全く手を付けられないというのが挙がってくるんですよ。じゃあどれだけ手を付けられていないのか計ってみよう、と。当時、アドバイザーの山海さんから、計れるものは何でも計ってしまえ、何が使える値かは分からないけど取れるデータは全部取ったほうがいいと言われていたので、じゃあ計画外の作業もどれだけ手を取られているか計ってみよう、と計ったのがスプリント2でした。
―― なるほど。それであの内訳が分かったということですね。そこから計画作業と割込作業を色分けして、タスクボードで管理するようになったと。ただ、少し疑問があって、バックログ項目の優先順位を明確に設けて作業をしていくというのは、価値の高いものをできるだけ早くリリースするには有効な方法だと思うのですが、バックログの消化を促進する方法ではないんじゃないかと思ったのですが。
高橋― そういう意味ではちゃんとしたベロシティがまだ計り切れていなかったので、ベロシティを計るために重要なものからきちんと作っていって、僕らのベロシティを出そうという取り組みだったと思っていただければいいと思います。
―― ビジネス価値を出しながらベロシティを見ると。
高橋― はい。だから結果的には最初のスプリント2とか3とか、残業してものすごく頑張っていた頃は詰め込み過ぎていたということが後になって分かりました。そういう意味では最初の頃より少し作業ボリュームを落として計画を立てて、スプリント内で終われるようにしていったところはあるかもしれないです。
タスクボードと仕掛ボードを併用して作業の無駄をなくす
―― そうしてバーンダウンチャートがダウンするようになりましたが、後半の追い込み傾向と作業負荷の偏りを改善すべく、仕掛ボードを導入されたという話がありました。仕掛ボードというのはどのようなものでしょうか。タスクボードとの違いを教えていただけますか。
西口― タスクボードはユーザーストーリーごとのタスクの把握、仕掛ボードはスプリント内のタスク全体の仕掛状況を把握するのに使っています。タスクボードも仕掛ボードもパワーポイントで作っているのですが、まず、タスクボードはユーザーストーリー1つに対して1スライド（1ページ）作ります。たとえば、今タスクボードは10スライドありますが、今、誰が、何個、仕掛中のタスクを持っているか、これだとパッと見て分からないんです。
出典) Agile Japan2017講演スライド『古参Webサービスのアジャイル化、DevOps化への奮闘記』、左の写真はインタビュー時
西口― なので、作業に着手するとき、タスクボードの付箋を仕掛ボードに持ってくるんです。仕掛ボードはユーザーストーリーに関係なく、Doingのタスクがすべて1ヶ所に集まるんです。仕掛ボードのDoing列のタスクには、誰が作業しているか書かれていて、一人2枚までしか作業できないというWIP制限も設けています。仕掛ボードを導入する前は、一人5枚も仕掛りになっていることが大いに見られたのですが、そこで無駄ができてしまうので。
―― 細かい話をすると、割り込みで優先度が高い作業が来たら、作業がオーバーしないんでしょうか。
高橋― そのときは、仕掛ボードの仕掛中の作業をタスクボードに戻します。
西口― 仕掛中だった作業が手を付けられる状態になっていればタスクボードのReadyという列に戻します。タスクボードの列はToDo、Ready、Doneなんですよ。Readyに入っていれば他のメンバーがこれ作業すればいいなって取れますし。タスクには仕掛時点で名前を入れているので、途中から引き取る人は最初に仕掛かった人に話を聞けばいいんです。
高橋― もともと東京と大阪の遠隔地でやっていたので、パワーポイントでの運用は苦肉の策とも言えるんですが。でも、一度アナログボードにしてもパワーポイントに戻ってきたので、こちらの方がチームには合っているのかなと。
畑― 遠隔地と言えば、あの頃やっていて良かったのは、常時iPadでTV会議をつないで東京、大阪の状況が見えるようにしていたことですね。最初は面倒かなと思ったのですが、やってみると向こうの状況がよく見えて話しかけやすくなるんです。そうすると、それまでだったらよく分からないけどまあいいかで済ませていたようなことでも気軽に話して解決できて。ビジネスぐる地図のチームとしてすごくよかったと思います。
西口― あれよかったですね。テレビ越しにうなり声が聞こえて「どうした？」って声かけたり。面白いですよ。
スクラムがうまく回ってから取り組んだDevOpsとインセプションデッキ
―― 講演の中では、スクラムとして計画を達成できるような状況になったところでDevOpsに取り組まれたと発表されていました。その最初のところで、改めて製品と向き合って製品の目的を明確化するということをされていますが、なぜこのタイミングで行ったのでしょうか。
西口― 結果的にはタイミングとして一番よかったんじゃないかと思っています。というのは、ひとまず始めてみようと始めたスクラムなので最初はスクラムを回すので精一杯でした。だんだんうまく回り始めたタイミングで、お客様の欲しいものをどんどん世に出すにはDevOpsがいいらしい、やってみよう、となったのですが、DevOpsって何なんだ？と悩み始めて。じゃぁ先にインセプションデッキをやったら何か見えてくるんじゃないかとやってみたらうまいことつながったという感じで。結構運が良かったと思ってます。
―― 確かに講演資料を見ると、従来のフロー通りに実行することが重要だと思っていたところが、本当の目的は何かと考え直してそれを実現するためにはどうすればよいかという発想に切り替わってますね。この「チームの成果を全員が喜べる状態」というゴールはすごく良いゴールだと思います。このゴールが結果的にはDevOpsの話につながるんですね。
西口― そうですね。
出典) Agile Japan2017講演スライド『古参Webサービスのアジャイル化、DevOps化への奮闘記』
プロダクトバックログはプロダクトオーナーと開発チームが協力して手入れする
―― 従来のフローの見直しや自動化でリリース作業が効率化し、バージョンアップの頻度も増えたという話でAgile Japanでの発表は終わったのですが、そこで少し気になったのは、プロダクトオーナーとしてDevOps以降で効率化したことを、ビジネス的な成果にどうつなげていくか、という辺りで工夫などはされたのでしょうか。
高橋― 工夫、というところはないですが、世の中どんどんサービスが進化していく中で、ビジネスぐる地図の歩みがすごく遅く、やりたいこととの差がどんどん開いている状況だったんです。なので、それをいかに埋めるか、追いついて追い越すか、みたいなところでちょうど良い取り組みだったと思っています。今までの課題だったところやお客様に喜んでいただけるものから意識して進めていった形です。
―― 世の中でよく聞くのはプロダクトオーナー対開発チームという話で、プロダクトオーナーはバックログにやりたいことをどんどん詰め込んで、開発チームから見るとせっかくスクラムをやってるのに苦しくなる一方だという状況があるみたいなのですが。
高橋― そうなんですか。苦しくなりました？
畑― ベロシティとか見ていればそんなむちゃくちゃにはならないような気がします。
高橋― 私も、プロダクトオーナーですけど引いてるわけじゃなくてほとんど一緒に入ってやってますし、自分だけで考えずにみんなと一緒にプロダクトバックログ詳細化をする中で、どれが今求められているかというところも認識を合わせているので、あまり詰め込み過ぎとか優先順位が変になるということはないのかなあとは思っていました。
―― プロダクトオーナーの中にはバックログを絞り込むのが難しいので、とりあえずバックログに投入していくというスタンスになる人もいて、バックログが玉石混合になりながら開発チームにどんどん降りかかっていくというのが悪い状況かなと。
高橋― そういう意味では、プロダクトバックログに全部いったん入れて同列に扱って、みんなでどうしていこうか話し合う。当然、最後の決定は私がするにしても、考える過程はみんなで一緒に、「いやこれより、やっぱりもともとあるけどこっちのほうが大事でしょ」とか、「一つのお客さんだけに絞ってそれをやるよりも、たくさんのお客さんに使ってもらえるこっちのほうがいいんじゃない」とか、そういう議論を普段からしています。
西口― 「あのお客さんこんなこと言ってるよ」っていう情報は、そのお客さんから聞いた時点でみんなにリアルタイムに伝わるのでそこでプロダクトバックログが変わることもあります。デイリースクラムや毎日夕方に振り返りをしているので、そこで情報共有してプロダクトバックログが日常から変わっていくという、結構面白い状態かなと思います。
バリューストリームマッピングで日々改善
―― Agile Japan発表の後、ビジネスぐる地図チームではどのような取り組みをされたでしょうか。
西口― 結構いろいろやっていますが。
―― バリューストリームマッピングをされてるんですよね。
西口― そうですね。Agile Japanのときもちらっとは言ったのですが、そのときは今までのウォーターフォールを変えるために、なくせるタスクはなくしていこうという大きなレベルでバリューストリームマップを作ったのですが、今は、例えばバージョンアップやお客様の新規サイト構築というような日々の運用でよくやる作業のバリューストリームマップを作って日々改善しています。すごく効果が大きいですよ。これ貼ってると立ち止まって見て行かれる方が多いです。
実際のバリューストリームマップ（一部加工しています）
―― そうなんですね、人気があるわけですね。バリューストリームマッピングは皆さんでされているんですか？
高橋― はい。年に5回も10回も同じようなことをするのであれば、基準作るより、もう自動化ツール作っちゃおうとか。僕らにとっての改善のやり方がいったん見えたような感じなので、より時間がかかっていたり回数が多いところで、いかに省力化してミスをなくしていくか、という改善をしています。本当に細かなことをみんなで気付いていっぱいやっているので、画期的な何かを改善した、ということは言えないのですが。
―― まさに改善活動ですね。
西口― そうですね。バリューストリームマップはKPTよりもダイレクトにピンポイントで問題と改善の効果が見えます。
高橋― それ以外のこともたくさんあるのでそこは普通にKPTを出しています。
もうあの頃には戻れない
―― 最後に、皆さんアジャイル開発を実践されてきて感想はいかがでしたか？当初の期待と合っていたでしょうか。
高橋― とても合ってますね。私がこのプロジェクトに来た頃は、1年に1回、すごく時間をかけてリリースだけするような状態だったのが、今はなんと効率的か。本当に短いサイクルでたくさん出していけるのですごく良かったと思っています。
―― 開発チームの方はどうですか？
畑― やっぱりみんなと同じ目標を持って進めるという意味でも楽しいですし、柔軟に動いて価値を早く提供できるっていうのは単純に楽しいですね。
山富― 私は今までウォーターフォールでやっていたときは、あまりどうやって改善しようかというのは考えていなくて、もうそれが当たり前の方法だったんですけど、みんなとアジャイルをやって話し合っていく中で改善案が出てくるので、改善に対する気持ちが強くなったっていうのが大きいですね。
―― スクラムマスターの西口さんはどうですか？
西口― 僕はウォーターフォールとか縦割りの役割分担にはもう戻りたくないです。洗濯板と洗濯機ぐらいの違いを感じています。今は、ルールを守っていれば、お客様に喜んでいただけるなら、何をしても良いという発想になるから、便利なものはありとあらゆる手段を使ってどんどん使おうという考え方が普通に生まれるんです。ここに至ると、もう戻れないですよね。
山富― あのころに戻るのは嫌です。さすがに。
西口― 1ヶ月かけて毎晩リリースとか、もう絶対無理です。
高橋― あとは、私はプロダクトオーナーですけど、トップダウンというよりすごくフラットに今はできているかなあと。だから、お客さんがこう言ったからこれを作るんだということではなくて、チームみんなと同じ目線で、サービスとしてどうしていくか、何がお客さんにとって価値があるかというのを、独りよがりにならずに考えるというような、すべてにおいてチームで作り上げていくようになっているかなあと思います。
―― 素晴らしい。今日は皆さんありがとうございました。
参考
- Agile Japan2017講演スライド『古参Webサービスのアジャイル化、DevOps化への奮闘記』 - https://www.ogis-ri.co.jp/pickup/agile/docs/agilejapan170413.pdf
- 『SCRUM BOOT CAMP THE BOOK』 西村直人[著], 永瀬美穂[著], 吉羽龍太郎[著], 翔泳社 (2013/2)
- 『アジャイルサムライ――達人開発者への道』 Jonathan Rasmusson[著], 西村直人[監訳], 角谷信太郎 [監訳], 近藤修平 [訳], 角掛拓未 [訳], オーム社 (2011/7)
- 『リーン開発の現場 カンバンによる大規模プロジェクトの運営』 Henrik Kniberg[著], 角谷信太郎[監訳], 市谷聡啓・藤原 大 [共訳], オーム社 (2013/10)