アジャイル開発したら残業がなくなった話

イントロダクション

── こんにちは。採用広報の島津です。
TOWNでは定期的にミートアップを開催しています。今回は、スケジュール管理SaaS『Aipo』のプロダクトマネージャーである岩崎さんが登壇するミートアップの内容を簡単にレポートします。

＜語り手＞
トークゲスト：
岩崎さん（2005年入社）Aipo事業部 プロダクトマネージャー
インタビュアー：
長澤さん（2018年入社）人事

残業時間の変化

── 「残業がなくなった話」がテーマとしてありますが、岩崎さんの肌感覚として、アジャイル開発の導入前と現在までで、残業時間はどのくらい変わりましたか？

岩崎：現状は本当にほぼ残業がないです。大体18時半くらいにはメンバーがみんな帰るんですけど、19時以降は誰もいない状況です。

受託開発を始めた当時は、そもそもその週にどこまでやればいいのか分かっていませんでした。21時過ぎまで働いて、なんとなく「今日はここまで進んだからいいかな」と一日を終えていました。その頃は一日数時間の残業が普通でした。

── じゃあ劇的に変わったんですね。

岩崎：そうですね。家に帰って夕食を食べるか、コンビニで買って会社で食べるかくらいの違いですね。「限られた時間でいかに成果を出すか」という考えに、みんなシフトできたかなと思います。

受託開発から自社開発へ

── 「アジャイル開発をしたら残業がなくなった話」の前段として、まずは当社のビジネスモデルの転換についてお話いただけますか。

岩崎：2013年に受託開発から自社開発に完全に切り替えました。その転換で働き方も大きく変わりました。

完全に自社サービスに転換した時に、代表から「もう受託はやりません。それに伴い、ビジネスモデルを労働時間を増やさなくても会社が成長できる『知識集約型』に変えます。」という話がありました。そこで「残業をしないようにしましょう」となり、働き方を変えていきました。

── まず会社自体の変化が大きくあったのですね。

岩崎：そうですね。受託開発時代は残業が当たり前で、終電まで働くこともよくありました。しかし、自社サービスになってからは、「最初のうちは売り上げが回復するまで時間がかかるかもしれないけど、みんなで頑張って働き方を変えていきましょう。」と切り替えていきました。

ウォーターフォールからアジャイルへ

── それでは今回のテーマの「アジャイル開発」にテーマを移したいと思います。受託開発の時代はアジャイルは導入していなかったのですか？

岩崎：そうですね。受託開発の時はウォーターフォール型の開発をしていました。お客様から最初に発注してもらい、要件定義して、スケジュールを引いて、リリース日を決めるという形でしたね。それで設計、実装、テストして納品という流れで進めていました。

── なるほど。ではどうしてアジャイルを取り入れようという話になったのですか？

岩崎：自社開発の頃も最初はアジャイル開発を知らなかったので、ウォーターフォールのような開発をしていました。

しかし自社開発が受託開発と大きく違うのが「エンドを決めるのは自分達」という点です。

最初の頃はそこの認識があまりなくて、自社サービスでもウォーターフォール型の開発をしていたら、「いつまでたっても何もリリースするものが出来上がらない」みたいなことが起きて（笑）。

きちんと定期的にリリースのサイクルを持たせた方がいいのではないかとなり、アジャイル開発を導入しました。

── 模索しながらアジャイル開発をやってきたのかなと思いますので、その過程をお話いただきたいです。結構失敗したというお話も伺ったのですが（笑）。

岩崎：そうですね。アジャイルを取り入れて10年くらいになりますが、ほとんどが失敗の連続でした（笑）。ほぼ全ての失敗を踏み抜いてきたのではないでしょうか（笑）。

アジャイルでの失敗① リリースサイクルを優先しすぎて、ユーザーの要望が見えず

岩崎：アジャイルを取り入れた最初の頃は、とりあえずリリースのサイクルだけを決めて開発をしていました。一定のサイクルでリリースできるようになりましたが、今度は逆にサイクルに合わせて、作る機能の優先順位を決めてしまっていました。

「本当にお客さんはこれを使うのかな」という機能を、スケジュールが間に合うからという理由で先に作っていくような開発をしていました。ただ、やはりそれだと作った機能がなかなかお客さんに使われませんし、売り上げに繋がらなかったです。

それで、その次に実際にユーザーが欲しい機能は何なのかを見える化して、ユーザーの要望が多い機能から作っていくことになりました。

── ユーザーのニーズの測定や確認はどのように行うのですか。

岩崎：「ニーズカウンター」というものを作って、要望の大きさを測定するようにしています。

Aipoはおかげさまでユーザーがたくさんいて、チャットサポートを全ユーザーに開放しています。そこから要望を吸い上げて、同じ要望を取りまとめて、どのような要望があるかをリストアップしています。

今のところトータルで4,000件程度の要望をいただいています。そこから実際に「この機能で実現できそう」というものをまとめると、約1,000件くらいの要望に集約されます。そこから優先順位の高いものから順番に進めています。

── 1,000件程度になったところから、何を作るのかはどのように決めているのですか？

岩崎：基本的には要望の多いものから順にやっていくようにしています。あとは要望は多いけど、実際に開発すると数年単位のものもあるので、開発スケジュールを考慮しながら最終的な優先順位を決めています。

── 形だけのアジャイル開発から、ユーザーのニーズをちゃんと汲み取った開発にしていく過程を経たのですね。

岩崎：そうですね。最初の頃はアジャイル開発の理念や目的をよく知らないで、見よう見まねで型だけはめていたので、全然成果がでませんでしたね。

アジャイルでの失敗② 大きくリリースしすぎて、ユーザーからお叱りを受ける

── Aipoのユーザーは３万人いますが、ユーザーの数は何か開発の仕方に影響しましたか？

岩崎：開発の仕方として大きく影響があるのは、「３万人にいっぺんにリリースをしない」ことです。

以前、Aipoの画面の左側に50ピクセルくらいのサイドメニューを追加したことがあります。
それを全ユーザーに一度にリリースしたのですが、その時に「今までより２文字表示が減っちゃって困る」などの非常に大きい反響があって。

そのような経験があるので、今はまずは極力少ないユーザーに対してリリースして反響をみて、そして適応するユーザーの範囲を広げています。そしてよりブラッシュアップしてから全ユーザーに展開しています。リリースする対象をいかにコントロールするかを考えています。

── その過程を経て、小分けに開発していく方法を見出したのですね。

岩崎：そうですね。３万人に一気にリリースするとなると、しっかり全部設計しなくてはいけません。しかしAipo事業部では要望をもらったお客様にだけ先行でリリースする仕組みを用意しています。細かく実験や色々試行錯誤できるので、動きは取りやすくなりました。

── なるほど。それも柔軟に開発する一つの方法なのですね。

岩崎：そうですね。要望をもらったお客さんにリリースしてみると全然よくない反応だったら、開発自体を止めるなど、そのようなことも結構早く判断できるようになりました。

残業がなくなった理由① さざ波の開発

── 続いて「アジャイル開発をしたら残業がなくなった話」についてお聞きしたいです。これはどういうカラクリなんでしょうか？

岩崎：先ほどの話に通ずるのですが、１つの機能のリリースに対してインパクトを極力持たせない。「波をつくらない」ことに注意をしております。

大々的に「Aipoにこういう機能を追加しました」のような情報を公開することもあります。しかし実際は、その前段階ですごく細かくリリースをしていて、全体への提供の前に実はもう８割型のユーザーには提供していることもあります。

最後に全体のユーザーに対してリリースするタイミングだけアナウンスしますが、実際はもっと細かく、他に事前に使っている人がいるようにしています。リリースの波を作らないように、なるべく小さくリリースを平均化しています。

一気にリリースするとその分大きな反響があったり、ものによってはサーバーの負荷が急激に上がることもありますが、小さくリリースすることで、負荷状況も細かく確認しながら対応できるようになりました。

通常、リリースした直後は結構忙しくなったり、リリースの山に向けて機能開発でメンバーが忙しくなることがありますが、Aipoではそれが極力起きないようにしています。「リリースインパクトをいかに小さくするか」ということが、残業がなくなることに繋がっていきました。

── 確かにリリースの負担が減ると、それは残業の削減に効果がありそうですね。

残業がなくなった理由② １週間のスプリント

── リリースのインパクトを小さくするということ以外にも理由はありますか。

岩崎：そうですね、開発のスケジュールを１週間単位で組んでいることも、残業がなくなった理由の１つです。

スケジュールも自分達で組んでいて、もちろん最終的に大きい機能のリリースということもありますが、それを極力１週間単位で区分けをしています。

スケジュールの遅れがでた場合は「やる範囲をどのように変えていくか」とか、そのようにコントロールをするようにしています。

そのようにリリーススケジュールや、リリーススコープを柔軟に変えているということが、残業のない働き方に繋がっていると思います。

── お話を伺っていると、やはり「細かくする」というのが肝なのかなと思いました。

岩崎：そうですね。Aipoチームではタスクを最大で２日間までというように細かく分けています。ですので１週間経っても何も成果物がないことが起きません。タスクの単位が最大で２日なので、３日目に同じ作業をしようとしていたら「ちょっと待って」とストップがかけられますし。

１週間は基本的に５日あるので、最初の２日間に進捗がなかったとしても、残りの３日で何かしらの成果が出せます。そのようにタスクをできるだけ細かくして、少しずつでも確実に成果を積み上げていくような体制にしています。

── なるほど。そのような工夫をしているのですね。

岩崎：そうですね。最初の頃は１年かけても何も成果物がないこともありました（笑）。そのような経験を経て、確実に１週間で積み上げていけように改善をしてきました。

10年間かけて失敗を続けてきた結果、ようやく少しずつ成果が出せるようになってきました。

仕事面・生活面で変化したこと

── 最後に、アジャイル開発が浸透して残業しなくなったことで、岩崎さんご自身にどのような変化があったかお聞きしたいです。業務の面ではどのような変化がありましたか？

岩崎：限られた時間でいかに成果を上げるかという観点で、仕事の優先順位付けがよりシビアになりました。いかに無駄なことに時間をかけないかっていう。いかにユーザーに対してインパクトのあるものを優先していくかと、意識が大きく変わりました。

── なるほど。ちなみに岩崎さんご自身の生活面でも変化はありましたか？

岩崎：非常に大きく変化しましたね。受託開発をしていた時は、終電まで働くことや休日出勤もあったので、エンジニア全員が20代じゃないと無理な環境でした。「30代、40代でこの働き方はできないな」という感じでした。

受託開発から自社サービスへ転換して、２年間かけてようやく売り上げが受託のころくらいカバーできるようになりました。受託の頃は、たくさん残業して働いていましたが、自社サービスになると８時間の労働で受託時代以上の売り上げになりました。

自由な時間が増えたので、自分自身もステップアップのために学習の時間をあてられるようになりました。

── ありがとうございます。お客様と一緒に働くメンバーの、両者にとって良い会社であることを目指してきたTOWNの想いが伝わったのではないでしょうか。

記事の中では書ききれない部分や、実際のミートアップでは参加者の方から質問をいただいてそれに応答する形で進めていますので、この記事を読んで気になった方はぜひミートアップに参加してください！