利点の大きいソフトウェア開発プロセスのフレームワークとして、世の中に広く知られるスクラム。多くの企業がこの手法を組織に導入・実践して、開発生産性や開発者体験を向上させてきました。株式会社Algoageも、スクラムを取り入れて組織を改善した企業のひとつです。
かつて私たちは、開発プロセスをうまく整備できておらず、メンバーにかかる負担が大きく業務の属人性が高いといった課題を抱えていました。その状況を変えるため、アジャイル開発のスペシャリストである角谷信太郎さんにアドバイザーとして参画していただきました。さらに、メンバー同士で力を合わせて組織全体の方針転換を行い、スクラムに注力してきたのです。
今回はスクラムマスターの日高尚美とエンジニアの若菜実農、石塚大策、纐纈優樹、そして角谷信太郎さんにAlgoageにおけるスクラムの改善の歴史について聞きました。
開発体制を整備する前は「なんちゃってスクラム」状態だった
――開発プロセスの改善前は、どのような流れでプロダクトを作っていましたか？
若菜：「DMMチャットブーストCV」のファーストリリースが2022年5月なので、まずはその前の話からしますね。纐纈さんと石塚さんの2人が2021年の10月に、その1カ月後に私がAlgoageにジョインしました。当時はプロジェクト・タスク管理ツールの「Asana」を使って、かんばんボードでタスクをシンプルに管理していました。
纐纈：かんばんボードに思いついたタスクを入れて、それを担当者にアサインしていく。週に1回の30分の定例会で進捗を確認するという開発方式でした。
――2022年5月に「DMMチャットブーストCV」をリリースしてからはいかがですか？
石塚：それまではタスクのチケットのみで業務を管理していたのが、ストーリーの概念を取り入れるようになりました。そして、開発工数をポイントで管理していました。これはよくあるスクラムポイントではなくて、「仮にCTOの安田（洋介）が担当して1時間かかる作業ならば1ポイント」を割り振るというものでしたね。角谷さんがアドバイザーとして入るまでは、まだまだ“なんちゃってスクラム”のような状態だったと思います。
纐纈：当時は安田さんが開発組織のワントップで、開発のすべてを管理する体制でした。時間単位のポイント制を導入していたのは、そのほうが安田さんにとって管理しやすかったからです。実際に各タスクのポイントをつけるのは安田さんではなく開発者本人で、脳内に小さい安田さんを飼って「安田さんが見積もるとしたらこれは○○時間くらいかな」という感じにポイントをつけていました。
ただ、実際にはいろいろな要因で作業がそんなにスムーズに進まないので、見積もりと実績がズレることが多発していました。それに、CTOの立場になってからあまり開発に時間を割けていない安田さんの見積もりを基準にしていたのも、見積もりと実績の解離に拍車をかけていたと思います。
石塚：そのころ発生していた課題はいくつもありました。まず、全体的にレビューが滞っていたこと。各々が自分の抱えているタスクで手一杯で、レビューに時間を割けない状況でした。担当するタスクの種類も偏っていたので「この種類の作業はこの人しかできない」というケースが多く、それが業務の属人化やレビュー遅延のさらなる原因になりました。
それから、見積もりの精度が低かったことで特定のストーリーが予想より肥大化してしまうことが多発していました。1スプリントで終わる予定だったものが全く終わらなくて、結果的に4スプリントくらいかかってしまうようなことが発生していました。
作業の優先順位を決めることもうまく行っていなくて。社内やクライアントからの要望に急ぎで対応するなど、突発的に優先度が変わるケースがよくありました。それによって、もともと予定していたタスクを期限内に終わらせることができず、スケジュールが後ろ倒しになるなど課題がたくさんありました。
纐纈：改善のための体制変更なども何度かあったんですが、なかなか状況が変わらなくて、開発組織のメンバーの負担が大きい状態が続いていました。
日高：私は前職で認定スクラムマスターの資格を取得して、Algoageに来てからスクラムマスターを担当しましたが、実務経験が無かったこともあり当時はうまくスクラムを回せているとは言えない状態でした。開発チームのみんなが長時間労働を強いられながら、なんとかタスクの期限を守ってくれていました。スクラムマスターとして本当に未熟だったと思います。
アドバイザーとして、角谷さんが参画
――そんななか、スクラムの体制を整備するために角谷さんに参画してもらったのだとか。
日高：アドバイザーを誰にするか社内で検討していたときに、安田さんが「第一候補は日本で一番良い人にしよう。角谷さんはどうかな？」と言ったんですよ。アジャイルの世界では本当に有名人なので「え、角谷さんを呼べるんですか？」とびっくりしました。
角谷：安田さんと私の共通の知人を介して「Algoageがスクラムに本腰を入れて取り組むために、アドバイザーを募っている」と教えてもらったんですよ。私はちょうど時間の余裕ができたタイミングだったので「お手伝いできますよ」と返事をして安田さんにつないでもらって。トントン拍子に話が進み、その週のうちに参画することになりました。
――Algoageのメンバーから見て、角谷さんはどのようなスキルを持った方だと感じますか？
日高：角谷さんはバランス感覚が素晴らしい人だと思っています。一緒に働くなかで、勉強になることが多いです。スクラムでは、スクラムガイドという型を守らなければならない部分と、スクラムガイドに書かれていない自分たちで決めていくべき部分の両方が存在します。角谷さんはその線引きや実行することの決め方が画一的でなくて、状況に応じてより良い策を決めるような柔軟さがあります。これは、いろいろなチームを経験してきたからこそできることだろうなと思って、いつも感動しています。
石塚：角谷さんが参画する前も、自分たちでレトロスペクティブミーティングなどを運用してはいました。でも、あるべき正しいチームの姿を誰もわかっておらず、思い思いに意見を言う状態なので、収集がつかずに困っていたんです。
でも角谷さんが参画してからは、ミーティングのファシリテーションや論点の整理などをしていただいて、議論がまとまりやすくなったように思います。
纐纈：もともとスクラムの進め方を暗中模索していて、みんなが「私の思う最強のスクラム」の意見を押し付け合っていたんですよ。でも、角谷さんがそこにガイドラインを導入して、みんなが納得できる形でスクラムのイベントを進められるように整備したのがすごかったです。
角谷さんは、普段の生活からアジャイル的な考え方が身に付いていると感じます。たとえば、これまでは何かの変更をする際に、一気に0から100に変えてしまうような極端なケースが多かったです。でも、「まず小さく変えて少しずつ改善していく」という考えを角谷さんが取り入れてくれました。
若菜：経験豊富な角谷さんが、気軽に「アジャイルなんだし、まずは1週間だけ試してみれば？」とアドバイスしてくれるのが、すごくいいんですよね。
日高：角谷さんは開発チームにおける北極星のような存在です。私たちが自己流のスクラムをやっていたところに、「正しいスクラムはこの方角なんだよ」と道を示してくれました。
スクラムガイドをチームで読み込み、その概念を浸透させる
――スクラムの体制を改善するために、角谷さんは何から手を付けましたか？
角谷：どんな会社のアドバイザーをする場合でも、まずはスプリントプランニングやスプリントレトロスペクティブなど、一通りのスクラムイベントに参加します。そうすると、何の改善から手を付けるべきか、だいたいわかるんですよ。
余談ですが、Algoageの開発チームはスプリント周期が最初から1週間でした。これは、すごく良かった点ですね。「1週間のスプリントでは機能開発を終えられない可能性があるから」という理由で、スプリント周期を2週間に設定するチームに出会うことが多かったです。
でも、まだスクラムに慣れていないうちに2週間分の計画を立てても、なかなか見積もりがうまくできないんですね。それよりは、スプリント周期を1週間に設定して、改善のためのフィードバックの回数を増やしたほうが成功しやすくなります。
石塚：角谷さんが参画して間もない頃に、スクラムガイドの読み合わせ会を実施してくれたことが記憶に残っています。当時、私たちはスクラムに関連する用語の意味や、各種のスクラムイベントの目的などを正しく理解できていない状態でした。そこから、読み合わせのなかで角谷さんが説明をしてくれて、不明点を私たちが角谷さんに相談し、だんだんとスクラムの考え方が染み付いてきました。
纐纈：読み合わせ会は本当に良かったです。それまでは各々が「自分の思うスクラムのあり方」を提案するけれど、みんな正解がわからないから、何を指針にするべきか迷っていたんですよ。それを、「まずはスクラムガイドを遵守する」という方針ができて、メンバーの認識を合わせられるようになったことで、相当に動きやすくなりました。
日高：私が読み合わせで良かったと思うのが「これはスクラムガイドに書いてあるから、その内容を守る」「これは書かれていないから、私たちが話し合って決める」という感じに、定められていないことを明確化できたことですね。
――スクラムガイドの読み合わせを実施したのは、どのような意図があったのですか？
角谷：みんなが話してくれたとおりで、スクラムイベントに参加して話を聞いているうちに「スクラムの解釈が、チームとして定まっていないんじゃないか」と感じたんですよ。そこで、全員の認識を合わせる目的で、スクラムガイドを1行ずつ読んでいくことにしました。
スクラムガイドは、先人たちの実践が蓄積された集合知です。特に2020年11月版は非常によくできているので、スクラムガイドを中心にチームの認識を合わせて、実践を重ねていくことが大切です。
なかには、スクラムガイドの記載内容を一部分だけ取り入れてしまう開発チームもあります。でも「チェリーピックしてはならない」ことが、まさにスクラムガイドに書いてあるんですよね。記載された内容をそのままやることで、スクラムの成功確率が高まります。スクラムの基礎をみんなで理解するために、スクラムガイドの読み合わせを実施していきました。
日高：余談ですが、たとえスクラムの知識があっても実際にチームに導入するのは一筋縄ではいかないと、Algoageに来てから痛感しています。こういった地道な取り組みが、チームにスクラムの考え方を浸透させるうえで重要だと感じました。
メンバー同士の信頼関係を生み出すために
――スクラムガイドの読み合わせ以外にもさまざまな改善を行ったと思いますが、印象深いことはありますか？
纐纈：開発者としてつらかったのが、組織体制の変更がかなり激しかったことです。スタートアップなので、急ピッチでいろいろなものを変えなければならないのは仕方がないんですが、かつてのAlgoageは0を100にするくらいのレベルで日常的に体制を変えていたんですよ。そこに適応していくのが大変でした。
大変な状況のなかで体制の改善についての議論をすると、メンバー同士で意見がぶつかります。体制変更に関する混乱や不満があるので、雰囲気が険悪になるんですよ。今はこうしてみんなで和やかに、ポジティブなこともネガティブなことも振り返れていますが、当時はミーティング中にメンバーの意見がバチバチにぶつかり合うこともありました。
それに疲れてきて、だんだんと「ミーティングなどで意見を言うのをやめようかな」という気持ちになっていました。でも、日高さんがメンバーと雑談をする1on1を開催するようになって、そこからチームの雰囲気がかなり良くなりました。
1on1では、日高さんが「今の状況、ぶっちゃけかなりつらくないですか？」と踏み込んだ質問をしてくれて、それが「他の人たちに本音を話してもいいんだ」という心理的安全性につながったと思います。
角谷：1on1を実施したのは2022年の末くらいですよね。アドバイザーになってからしばらく経って、だんだんと良くなってきたけれど「チームワークをどうやって生み出すか」が課題だという話を日高さんたちとしていました。
私が立てていた仮説は「そもそも、会話の量が足りなくて信頼関係を生み出せていないんじゃないか？」ということでしたね。だから、目的を決めずに雑談をしましょうとアドバイスしました。すると日高さんが「メンバー全員とやります」と言ってくれました。
日高：全員との1on1は本当に良かったですね。信頼関係が生まれましたし、みんなもつらく感じているんだという目線合わせができたのは良かったです。
それと併せて、とても申し訳ないですがCTOの安田さんにスクラムイベントから外れてもらうことにしました。安田さんはその立場上、開発者の帽子やプロダクトマネージャーの帽子ではなく、どうしても「神様の帽子」をかぶった状態の発言になってしまいます。
それに、何かの施策に取り組む前にメンバーのことを心配して、「○○を考慮していますか？」とか「○○が発生したらどうしますか？」というブロックをかけるところがありました。もちろんリスクがゼロになるに越したことはないですが、プロダクトの立ち上げフェーズではケアする必要性が低そうな指摘や、課題が抽象的すぎて具体的な方針を話し合うだけでも1時間近くかかりそうな指摘を投げかけられることが多かったです。
そのため「まずは小さく始めて、少しずつ軌道修正していく」というアジャイルの思想をチームに適用するために、まずは私たちを信じて任せてもらえないかと伝えました。これが結果としてうまくいったため、安田さんが「神様の帽子」を脱いでも私たちのスクラムチームは回っていくという信頼を得て、適切な権限委譲が達成されたのかなと思います。
良いプロダクトを作るための健全な議論ができている
――2023年に入ってからはどのような改善をしましたか？
角谷：スクラムのスプリントレビューに、カスタマーサクセスや営業などのステークホルダーを呼ぶようになりましたね。
若菜：角谷さんから「スクラムチームの外部のステークホルダーへの単なる進捗報告の場ではないから、双方向でコミュニケーションをしてほしい」とアドバイスしてもらいました。
日高：スプリントレビューでなるべくステークホルダーの方々にも発言してもらうために「この前に作ったあの機能って、どう使われていますか？」とか「この機能をリリースしてから売り上げは伸びましたか？」など、なるべく相手に質問をすることを心掛けています。
石塚：ステークホルダーがスクラムイベントに参画する前は、みんな自分自身の「開発業務」にばかり目が向いていました。でも、スクラムの体制が整ってきて他の部署の人とも意見交換をすることで「より良いプロダクトのあり方」を考えられるようになったと思います。
日高：他にもモブワークや業務の1つ持ち制限などを取り入れました。1つ持ち制限というのは、仮に5人いたら「5人で5つのタスクを並行で走らせる」のではなく「5人で1つのタスクに合同で取り組む」ということです。
若菜：モブワークを行うことで、みんなでナレッジシェアできるのが良いですね。それに、モブワークが始まる前や休憩の時間などに雑談もできますし、コミュニケーション不足が解消されるのが優れています。
石塚：チームとしてひとつのタスクに取り組む形になった結果、冒頭で挙げたレビューの遅延や業務の属人化などの課題が解消されました。私たちの開発組織ではリリースサイクルを計測しているんですが、作り始めてからリリースされるまでの期間が明らかに短くなりましたね。
纐纈：これまでずっと「メンバーが複数のタスクを並行で抱えていること」が課題になっていたものの、なかなか解消できませんでした。でも、モブワークや業務の1つ持ち制限を取り入れてから、それが改善しました。明確に改善速度が上がっていますね。現在は、良いプロダクトを作るための健全な議論がきちんとできている感じがします。
若菜：スクラムの改善を行う前までは、ポイント式で開発業務を管理していたことが示すように、主に“アウトプット”を見ていました。でも今は、どうやってアイデアを価値に変えるかという“アウトカム”を重視できるチームになったと思います。
日高：私もみんなと同じ意見ですね。スクラムガイドにもあるように、スクラムイベントは「検査と適応、透明性」のためにあると思っています。イベントで検査して、状況に適応していくことで透明性を上げていく。透明性が上がると、チームが何に困っているか、次に何をしなければならないかの目線が揃う。改善のスピードが速くなって、さらにスループットが上がる良いサイクルになりました。
開発者体験の向上とアウトカムの最大化
――今、角谷さんはどのような方針でアドバイスやスクラムの運用をしていますか？
角谷：前半パートで出ていた課題であるポイントや見積りについては、現在は業務の1つ持ち制限を行っており1つのプロダクトバックログアイテム（以下、PBI）に全員で取り組んでいることから、「見積りポイント」などを割り当てていない状態です。
では、見積りをしていないかというとそうではありません。スプリントで取り組むPBIは、リファインメントを通じてなるべく1スプリント以内で完成できる大きさにしています。つまり、PBIの大きさを見積もるのではなく、1スプリントで完成できそうな大きさに合わせてPBIのサイズを調整してほしい、と伝えています。といっても、スクラムガイドに「作業を行う開発者は、その作業規模の評価に責任を持つ」と書いてあることそのままですが。
モブワークによってチームとしてPBIを完成させるという形態に移行したので、プランニングでは細かいタスクへの分割はしていません。管理するタスクが無いので、タスク個別での詳細な見積もりもしていません。その代わり、日々のデイリースクラムやモブワークで「PBIを完成させるためにどう進めていくのか」という作戦をチームで話し合って決めてもらってます。
ユーザー向けに機能をリリースする期日については、プロダクトチームとステークホルダーとで対話してターゲットとなる日程を定めて、その期日に間に合うようにリリースの目的を達成できるようにスコープを調整しています。
目の前のスプリントよりも先の“計画”は、現状ではPBIの優先度を適宜メンテナンスすることで、プロダクトチームとステークホルダーとの間で合意できています。しかし、「なぜその優先度になるのか」という根拠づけやその透明性が足りていないと感じています。スプリントゴールとプロダクトゴールとの結びつきに課題があるような状況です。それらを、また次のステップとして変えていきたいですね。
――今後、さらに改善したい部分はありますか？
日高：私が個人的に掲げているミッションは、この組織を持続可能にすることです。たとえば、もし私がいなくなってもチームが円滑に回るように他のメンバーにもミーティングのファシリテーションなどをお願いしたり、私に直接来ていた問い合わせを、なるべくチームに対する問い合わせに変えられるようにツールを導入したり。それから、新しく来たエンジニアを受け入れる体制作りのために、みんながドキュメント作成などをがんばってくれています。そういった整備を続けていきたいです。
纐纈：開発生産性はかなり安定したんですが、「良いプロダクトを作れているか」については改善の余地があると感じています。先ほど角谷さんも言ってくださったように、プロダクトとしてのゴールとスプリントとしてのゴールのひも付けに課題があります。機能をただ作るだけの、フィーチャーファクトリーの部隊になってはならないと感じており、オーナーシップを持って取り組めるチームにしていきたいです。
日高：たまに他部署の人たちの話などを聞くと、「本当は○○の機能を改善してほしいんだけれど、今は我慢してマニュアルを整備したり現場のオペレーションでどうにかしたりしている」といった意見をもらうことがあるので、そういった課題も解消したいですね。
角谷：みなさんが言ってくれたとおりで、開発体制は整ってきたものの、良いプロダクトにしていくにはまだまだ足りないことも多いです。中長期的なゴールを達成するためにはプロダクトチーム以外のチームとも力を合わせなければならないので、企業全体としての組織的な整備も行っていく必要があります。かなり良い流れになっているので、今後も組織をより良くしていく仕組み作りができるとベストですね。
――まとめとして、スクラムプロセスの改善を行う意義について、みなさんからコメントをいただきます。
日高：私は開発チームの人たちがすごく好きなので、その人たちが苦しまないで、楽しく、成長できる環境を作ることに全力を注ぎたいと思っています。そのための手段を常に模索して、ゴールに向けて進みたいです。
石塚：スクラムプロセスの改善に挑戦することで本質的な業務にみんなが注力する時間が増えるとか、話し合いをするためのベースができます。だからこそ、取り組む価値はとても大きいと思います。
若菜：個人的には、開発者体験がとても良くなったと感じます。個々人がタスクを抱え過ぎているとか、コミュニケーションをうまく取れないとか、レビューがなかなか進まないといった課題を仕組みとして解消できました。アウトカムを最大化するための手段として、すごく有効です。
纐纈：他の人たちが話しているとおりなんですが、開発者体験が向上することや本質的な価値と向き合えることなどが魅力です。エンジニアたちが前向きに働けるようになるし、機能を作ったけれど誰にも使われなかったなどの事態が起きにくくなるのが、大きな利点だと感じます。
