こんにちは、ラクス技術広報です。 2026年7月15日、主催イベント「RAKUS AI Conference 2026 Summer」を開催しました。本記事では、楽楽精算 開発3課の平川裕多さんが発表した「仕様駆動開発、導入半年。『本当に速くなってるの?』にデータで答える」について、技術広報がレポート記事でご紹介します。 この記事はこのような方におすすめです AI活用で実装は速くなった気がするのに、なぜか設計やレビューの負荷が増えていると感じているエンジニアの方 仕様駆動開発(SDD)の導入を検討している、あるいは導入したものの効果を数字で説明できずに悩んでいる方 「AIネイティブな開発」を、感覚ではなくデータで語りたいと考えているエンジニアの方 【目次】 「それ、本当に速くなってるの?」に答えられなかった半年 仕様駆動開発に"飛びついた"というのが実態でした 上司とメンバーからの"ツッコミ"と、1年分のデータを掘る決意 データを掘って初めて分かった、3つの指標の意外な共通点 指標①：時間 指標②：レビュー 指標③：バグ（事故） 3つの指標から見えてきたもの 正直に語られた課題と、「仕様を決める力」への投資 終わりに 「それ、本当に速くなってるの?」に答えられなかった半年 平川さんのチームが担当するのは、経費精算クラウドサービス「楽楽精算」のモバイルアプリです。iOS、Android、バックエンド、フロントエンドという複数のプラットフォームを、6名のエンジニアがアジャイルの2週間スプリントで開発しています。 ここ1〜2年でAI活用が本格化し、個人の実装スピードは体感としても数字としても間違いなく上がったといいます。コードを書く作業は、以前ほど開発のボトルネックではなくなりました。 ところがその裏で、3つの問題が起きていました。 意図のよく分からないコードが混ざるようになったこと レビューの負荷に偏りが出るようになったこと テストフェーズになって初めて「考慮漏れ」に気づく事故が多発するようになったこと 設計段階で気づかず、後工程で発覚するほど、修正のコストは高くつきます。 「早くはなったけど、何か別のものを払っている感覚があった」 この違和感から生まれたのが、「AIで早くなった裏で、本当は何を払っていたのか」という問いでした。 仕様駆動開発に"飛びついた"というのが実態でした この問いに対して、平川さんたちがたどり着いたのが仕様駆動開発(SDD)でした。ただし、最初からSDDを狙って導入したわけではなかった、と平川さんは振り返ります。 最初にやっていたのは、今まで手で書いていた設計書をAIに書かせて時短できないか、という「AI設計テンプレート」的な試みでした。それを1ヶ月ほど地道に作り込んでいたそうです。ちょうどそこに、世の中で「仕様駆動開発」という言葉が流行り始め、「これ、自分がやりたかったやつだ」と思ったといいます。慎重に比較検討して選んだというより、飛びついたという感覚の方が実態に近いと振り返ります。 飛びついたあとで、あらためて「なぜ他のやり方ではなくSDDだったのか」を整理しました。 Planモード ：AIがタスクを組んでくれて便利だが、結局それを使うエンジニア個人の能力に依存する点で、直接指示と本質的に変わらない テスト駆動開発(TDD) ：リファクタリングには強いが、そもそも仕様がブレていればテスト自体が空中分解してしまう Planモードの質もTDDのテストの質も、たどっていくと結局は「仕様」に行き着く。だったら一番上流の「仕様」そのものを中心に据えるのが筋が良い、という腹落ちだったとのことでした。 具体的には、マークダウンで構造化した自然言語の仕様書を使い、設計そのものをPRとしてレビューする運用を敷きました。とはいえ、自然言語の成果物にはコードのようなリンターもテストも効きません。「問題ない」と判断するにはしっかり読む必要があり、コストがかかります。仕様を構造化したり重複を減らしたりという地味なチューニングを、今も積み重ねている最中とのことでした。 上司とメンバーからの"ツッコミ"と、1年分のデータを掘る決意 SDDを始めてすぐ、突っ込まれる日々が始まりました。 上司からは「それ本当に早くなってるの」「設計に時間をかけている分、トータルで遅くなっているんじゃないの」という声。メンバーからは「設計フェーズが大変になった」「一番頭を使う部分が重くなった」という声が上がりました。 この2つのツッコミに、感覚で「いや、早くなっていますよ」と返しても説得力がありません。そう考えた平川さんは、1年分のデータを本気で掘り返して検証することにしました。 なお、平川さん自身「そもそもSDDを品質のために入れたわけではなく、狙いは実装を誰がやっても同じ質にして属人性をなくすことだった」と前置きしています。この後の検証結果は、当初の狙いとは別のところで平川さんたちを驚かせることになります。 データを掘って初めて分かった、3つの指標の意外な共通点 AIもアジャイルも定着した時期以降のデータに絞り、フェアな比較を心がけたうえで、3つの指標を見ていきます。 指標①：時間 実装フェーズの数字は、確かに速くなっていました。ただし、その「速さ」の正体を追うと、後工程にあった意思決定の負荷が、設計フェーズに前倒しされただけでした。たとえば「複数ある実装方針のどれを採用するか」という判断は、SDD以前は実装しながら決めることもありました。今はそれを設計のタイミングで行います。AIが選択肢を出してくれる分、考えるのは楽になった場面はあるものの、最終的にどれにするかを人間が決め、レビューやステークホルダーの合意を得る必要がある点は変わりません。SDD自体は時短策ではない、というのが平川さんの見立てです。 指標②：レビュー 1つのPRあたりの他者からのコメント数は、中央値がずっと1でほぼ横ばいでした。レビューの総量そのものは減っていません。ただし中身は変わっていました。実装PRで「この仕様どうなってるの?」という揉め事が減り、その議論が仕様レビューの場に前倒しされたのです。レビューが純粋なコード品質チェックに近づいたという意味では狙い通りですが、「楽になった」わけではなく、「議論する場所が移った」というのが実態に近い、と平川さんは説明します。 指標③：バグ（事故） バグの発生件数そのものは、劇的には変わっていませんでした。ただし2つの変化がありました。1つは、1件あたりの対応時間（※着手からテスト完了までのリードタイム）が17時間から11時間に短縮したこと。もう1つが、平川さんいわく「これが大きい」変化でした。以前は1スプリントで20件を超えるような"バグの大爆発"が起きることがあったのが、最大でも8件程度に収まるようになりました。事故の数ではなく、事故の振れ幅が小さくなったということです。 なお、この集計はテストまで完了したスプリントのみを対象にしており、サンプル数はまだ多くありません。平川さん自身、断定ではなく傾向として見てほしいと、数字の限界を率直に語っていました。 3つの指標から見えてきたもの 3つの指標を並べると、見えてくるものがあります。時間もレビューも、内容は移っただけで総量は変わらず、バグは件数こそ横ばいながら振れ幅が縮みました。 ここから導かれる結論を、平川さんはこう言い切ります。「SDDの本当の成果は、速さじゃない」。開発そのもののスピードは、AIをガムシャラに使っていた1年前とほとんど変わっていません。得られたのは、予測可能性でした。裏を返せば、以前ガムシャラに速度を出していた頃、代わりに払っていたのは、この予測可能性だったのです。 平川さんはこれを具体的なエピソードで語っていました。怖いのは、バグ修正にかかる時間そのものより、「何件出るか読めないこと」だそうです。2週間スプリントの7日目まで予定通り進み、残業もせず帰れていたとします。それなのにテストでバグがたくさん出ると、残り数日で焦って対応するか、別スプリントに送るかという判断に迫られ、計画が崩れます。SDDによって仕様の検討が上流に寄った結果、この「予想外の大爆発」が起きにくくなったのです。平均的な件数は大きく変わらなくても、最悪のケースが消えて振れ幅が縮み、立てた計画が、そのまま計画として機能するようになりました。 そしてこれは、働きやすさだけの話ではありません。事故で開発が止まらないということは、顧客に安定したペースで価値を届け続けられるということでもあります。予測可能性は、顧客への価値提供の土台でもある。平川さんはそう位置づけていました。 正直に語られた課題と、「仕様を決める力」への投資 SDDは時短の手法ではなく、決めごとの総量も変わりません。それでも品質と予測可能性への投資だった、というのが平川さんの結論です。実装スピードそのものは変わらなくても、速さの出方が変わりました。昔は事故が起きるかどうか読めないまま勢いで速度を出していたのに対し、今は上流で足場を固めてから、同じ速度を読める形で出している。アジャイルを捨てたわけでもなく、2週間スプリントという枠のなかで「決める位置」を前にずらしただけだ、という整理も印象的でした。 ここで終われば美談ですが、平川さんは課題も正直に語っていました。時間もレビューも総量は「移っただけ」で減ってはおらず、総量そのものをどう減らすかは宿題のままです。さらに、レビューを上流に寄せた結果、今度は仕様レビューの方が渋滞するという新しいボトルネックも生まれています。 興味深かったのは、仕様が設計段階で固まることで、そこからテストを作るのも楽になるという発見です。固まった仕様を起点にすれば、テスト設計やユニットテストを考える時間も減り、AIに任せられる部分も増えます。上流で固めた仕様を、テスト作成の自動化にそのまま流し込む。この接続を今まさに模索しているそうです。 またメンバーの「設計フェーズが大変」という声の実体は、仕様書を作ったあとのモブレビューではなく、その前段階、個人がローカルで仕様を練っている時間が最も頭を使う、というものでした。ここに「ループ」や「ハーネス」といった仕組みを当てはめ、機械的に拾える考慮漏れはモブレビュー前に潰しておきたいとのこと。ただし、モブレビューそのものは残したいとも話していました。人を育てる場であり、テックリード一人がすべてをレビューしなくても、メンバー同士でレビューが回るようになる効果もあるからです。自動化するのは生成の負荷にあたる部分で、人間の判断や育成の機会は残す。この線引きを大切にしているとのことでした。 この先の展望として、平川さんは「ループエンジニアリング」という考え方も紹介していました。海外のAI開発ツールの責任者が「もうAIに指示は出していない、自分の仕事はループを書くことだ」と話しているそうで、その考え方の提唱者とされる人物も「これは仕事が簡単になったわけではなく、レバレッジの効く点が移っただけ」と釘を刺しているとのことでした。これは平川さんが今回データで語った「決める場所が上流に移っただけ」と、驚くほど重なる指摘です。その人物はさらに、全部を自動ループに任せればプロダクトの品質は落ちるとまで話しているそうです。つまりループは「何が正解か」の判断までは代わってくれません。その「何が正解か」を上流ではっきりさせるのが、まさにSDDです。ループの時代が来るほど、その前段にある「仕様を決める力」の価値は上がっていく。開発をAIに委ねても、「何が正解かを決めるカロリー」だけは人間に残る、という見方を示していました。 予測可能性が手に入るということは、AIに安全に任せられる範囲が見えてくるということでもあります。読めないものは任せられませんが、振れ幅が小さく読めるものなら任せられます。その範囲を安全に広げていけば、いずれボリュームが増え、トータルのリードタイムも縮んでいくはずです。平川さんは、今回手に入れた予測可能性を、その先の自動化を安全に広げるための「足場」だと位置づけていました。 終わりに 時短にはなっていない、新しいボトルネックも生まれた。それでも正直に数字と向き合う姿勢そのものが、AIネイティブな開発組織のリアルなのだと感じます。「なんとなく速くなった気がする」で終わらせず、データで自分たちの仮説を裏切る勇気を持てるかどうか。仕様駆動開発を検討している方にとって、平川さんの検証プロセスそのものが参考になれば幸いです。 当日の発表資料はSpeakerDeckで公開しています。ぜひあわせてご覧ください。 発表資料 speakerdeck.com なお、8月下旬ごろに発表のアーカイブ動画をラクスエンジニア情報ポータルサイトにて公開予定です。 ラクスエンジニア情報ポータルサイト career-recruit.rakus.co.jp 「RAKUS AI Conference 2026 Summer」の他レポート記事 ・ AIを載せることはゴールではない。ラクスCTOと開発副本部長が語った、組織とプロダクトの変革 ・ 顧客の声から生まれた『AI返信補助機能』の開発プロセス ・ 楽楽精算AIエージェントを支える、LLMOpsとインフラの選択肢 ラクスでは、こうした「顧客志向」と「AIネイティブ」の両方を大切にしながら、地に足のついた検証を重ねる開発組織を、一緒に作っていく仲間を募集しています。ご興味を持っていただけた方は、ぜひ採用ページもチェックしてみてください。 最後までお読みいただきありがとうございました！

ニフティの開発手法はチームやプロダクトの特性によって異なりますが、現在、多くのチームで導入されているのがスクラムです。 スクラムとは、決まった期間（スプリント）ごとに価値を少しずつ届け、検査と適応を繰り返しながら進めていくフレームワークのこと。 「プロダクトオーナー（プロダクトの価値の最大化に責任を持つ）」、「スクラムマスター（スクラムの確立とチームの効果性に責任を持つ）」、「開発者」という3つの役割があり、それぞれに認定資格が存在します。今回はそのうち、プロダクトオーナーとスクラムマスターの資格を持つ、エキスパートたちにインタビュー。ニフティにおけるスクラム開発の導入事例や効果を語ってもらった前編に続き、後編では組織全体としてのスクラムの浸透度合いや、今後の課題について聞きました。 数年前の「内製化」を機に、スクラム開発へとシフト ――ニフティにおけるスクラム開発の浸透度や、導入による変化について教えてください。 西野さん プロダクトとの相性を鑑みて、あえてスクラム開発をやっていないチームもありますが、開発組織全体で見ると浸透度は高いです。スクラムマスターの資格保持者も年々増えていて、現時点で十数人。それまでにもチーム内でスクラム開発は取り入れていたけれど、より本格的にやっていきたいということで資格を取るケースもあります。 現状やっていないチームも、いったんは導入してみたけどあまりフィットせずに中止したケースや、一時は断念したけど、またトライしてみたいと私のところへ相談に来られるケースもあり、少なくとも前向きではあると思いますね。 ――以前に比べて開発組織全体でスクラム開発の導入が進んだことで、プロダクトの開発期間の短縮や、ニフティのサービスの質向上などにつながっている実感はありますか？ 清水さん そもそもの背景として、スクラム開発を導入する以前に、2018年あたりから開発を内製に切り替えていったというのが大きくて。それまでのニフティって、どちらかというとサービスのシステムは外部の開発会社の方に作っていただき、社内のエンジニアは仕様を決めたり、できあがったシステムのテストや調整だったりが主な役割でした。 私が入社したあたりから、少しずつ内製にシフトしていく動きが出てきた時に、開発方法そのものの見直しを迫られたんです。それまでのやり方は、最初に仕様をがっちり固めて外部パートナーに発注。ある程度の工期をかけてしっかり作り込んだものを最終的にこちらでテストするという、いわゆるウォーターフォール型の開発手法でした。ただ、内製でやるならスクラム開発のほうが、社内のエンジニア同士のコミュニケーションが増える利点をより活かせるのではないかと。 ――エンジニアとしてのスタンスも、大きく変わりそうですね。 清水さん そうですね。それまでは「エンジニアは企画の人に言われたことをやればいい」というスタンスでしたが、途中で違うことを言われた時に困ることもありました。最初に仕様をガチガチに固めず、小分けで実装・開発・テストを回していくスクラム開発にシフトすることでそうしたストレスも減りましたし、エンジニアのマインドセットにも影響を与えたのではないかと思います。 西野さん 私が入社した15〜16年前のニフティって、「振り返り」の文化がほぼなかったんです。せいぜい半年に一度の評価のタイミングで、それまでにやってきたことや成果を振り返るくらいで。 それがスクラムを導入して以降、早ければ1週間でプロジェクトを振り返る文化が色んなチームに根付いてきたと感じます。チーム単体のみならず開発組織全体としてもそうした動きがあり、それはスクラム文化が浸透してきたことも一因ではないかと。 吉田さん 現代のような変化が激しく複雑性の高い状況では、アジャイルな考え方が有効な場面が多いと感じています。その意味で、開発組織にスクラムが浸透してきたのは良い傾向ですが、それを真に効果的にするためには、プロダクトオーナーを輩出する企画側の深い理解が欠かせません。 単に開発側の働き方に企画側を従わせるのではなく、どうしたらスクラムのプロセスが有効なのかを一緒に考え、自分たちのプロダクトに対してアジャイルの原則と価値が機能するように落とし込んでいく必要があります。 そのあたりのはしご役は、企画側のプロダクトオーナーである私の役割だと思っています。 スクラムを開発チームだけでなく、会社全体に浸透させていく ――いま吉田さんから課題について少しお話しいただきましたが、西野さん、清水さんはいかがでしょう？　今後、ニフティのスクラム開発をより深化、あるいは企画側も含めてさらに浸透させていくためには、何が必要でしょうか？ 西野さん 吉田が言うように、スクラム導入が開発側だけで先行している点は、課題だと感じています。前回も少し話しましたが、企画と開発のフロアが別々になっていて、物理的な距離があるのも一つの原因ではあると思うので、もっと対話の機会を増やしていきたいですね。（※） 私たちポイントチームの場合は、企画側に吉田がプロダクトオーナーとして立ってくれていることもありコミュニケーションは活発ですが、他チームでも企画と開発の垣根をなくしていくことが大事です。今は「同じプロダクトに関わる組織」というだけの関係であって、企画側と開発側が一枚岩で動けているケースはそう多くないと思いますので。それができるようになると、企画と開発がそれぞれ感じているプロダクトの課題を共有できて、「その課題に対処するためにはスクラムがいいよね」といった具合に、自然とスクラム開発を導入する方向に進んでいくのではないでしょうか。 （※）インタビュー時点。2026年5月にオフィス移転し、現在は同フロアになっています。 清水さん 私も開発側の人間なのでスクラム開発を当たり前のようにやっていますが、開発組織以外の、ニフティ全体で見るとまだまだ十分に浸透しているとは言えません。特にビジネスサイドでスクラムの知見を持った人って、現状は吉田さんくらいなのかなと思っています。とはいえ、こちらがいくら「企画側もスクラムをやりましょう」とか「プロダクトオーナーの資格を取ってください」と言ったところで、課題の本質が分からないまま導入してもあまり意味がない。 吉田さんがおっしゃったように、スクラムの意味やメリットを企画側にも納得してもらうことが重要です。そのためには、スクラム開発の本質や、開発側が感じている利点、ビジネス側がそれをやることでプロダクトやサービスにどんな影響があるかといったことを言語化して、丁寧に伝えていく必要がある。それはスクラムマスターである私の役割の一つだと思いますので、ボトムアップでじわじわと組織全体に浸透させていきたいですね。 自分自身の現状を知って初めて、チームの課題が見えてくる ――最後に、みなさんが今後、ニフティのなかでチャレンジしたいことを教えてください。 吉田さん まずは自分自身が、プロダクトマネジメントというものをより理解し、実践できるようにならなくてはいけないと考えています。また、自分一人だけではなく企画側も含めた組織全体として、ニフティにあるべきプロダクトマネジメントとは何なのか、どう進めていくべきかを考え、構築していく必要がある。 そのために、たとえば開発側、企画側の上長や同僚が参加するプロダクトマネジメントの勉強会などに自分も参加しているのですが、そういった場で何かしらの発信をして、プロダクトマネジメントやスクラムに関する知見を開発以外の部署にも広げていくような活動ができればと考えています。 清水さん 先ほど話したことにも通じますが、開発内だけでなく会社の誰もが部署の垣根を超えて、自分の考えをシェアできるような場や文化を作りたいと思っています。たとえばニフティでは年2回、全社会議の場で経営陣から活動方針を伝えられるのですが、現状は一方通行というか「聞いて終わり」になってしまっているのが、もったいなく感じていて。 もっと現場の社員同士でディスカションして、「自分はこう受け取ったけど、あなたはどう思う？」といった話ができるといいのかなと。そうやって経営陣のメッセージに対する理解を深めた上で、「じゃあ自分は今期、こういう活動をしていきます」みたいなことまでシェアできると、組織全体が一枚岩になれるのではないかと思います。今はAIの活用が進み、業務時間が短縮できているので、そこで空いた時間は組織全体でもっと本質的な問いについて考えることに使いたいですよね。 西野さん チームや組織を変えるためには、まず個々のメンバーが自分自身の現状や課題に気づく必要があると考えています。自分がいま何に悩んでいるのか、何にチャレンジしたいのか、何が成長を阻んでいるのか。それが理解できて初めて、チームにも目を向けられるようになる。組織をより良い方向に変えていこうという思考が生まれる。メンバーそれぞれがチームの課題を言語化できるようになり、チーム全体にシェアされる。その結果、場合によっては課題解消のアプローチの一つとしてスクラムの導入へと至るかもしれません。 スクラムを単に形骸化したフレームワークに終わらせないためには、そうしたプロセスを踏んでいく必要があると考え、そのファーストステップとして2年前から社内コーチングを始めました。今は私だけでなく吉田と清水にもコーチングの研修を受けてもらっていて、チーム外活動としてコーチングを提供していこうと考えています。最終的にスクラムの導入というゴールに至らなかったとしても、一人ひとりが気づきを得ることで仕事へのモチベーションがアップし、組織全体の活性化にもつながっていくはずですから。 前編もご覧ください！ 今回はニフティのスクラム開発を牽引するエキスパートたちのインタビューの様子をお届けしました。あわせて前編もご覧ください。 【インタビュー】サービスを発展させるために「あらゆること」をやる。ニフティのスクラム開発を牽引するエキスパートたち【スクラムマスター 前編】 ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ このインタビューに関する求人情報/ブログ記事 ニフティ株式会社 求人情報

ニフティの開発手法はチームやプロダクトの特性によって異なりますが、現在、多くのチームで導入されているのがスクラムです。 スクラムとは、決まった期間（スプリント）ごとに価値を少しずつ届け、検査と適応を繰り返しながら進めていくフレームワークのこと。 「プロダクトオーナー（プロダクトの価値の最大化に責任を持つ）」、「スクラムマスター（スクラムの確立とチームの効果性に責任を持つ）」、「開発者」という3つの役割があり、それぞれに認定資格が存在します。今回はそのうち、プロダクトオーナーとスクラムマスターの資格を持つ、エキスパートたちにインタビュー。ニフティにおけるスクラム開発の導入事例や効果、アジャイル文化の浸透度合い、今後の課題について語ってもらいました。 自己紹介 吉田 龍太郎さん 2018年10月に入社（子会社より転籍）。ニフティポイントの企画チームに所属し、「ニフティポイントクラブ」のプロダクトオーナーを務める。趣味は服飾、サッカーゲーム、生け花、美術鑑賞、読書。 清水 利音さん 2017年4月に新卒入社。会員基盤チームに所属し、スクラムマスターとして「シングルサインオンシステム」の開発に従事。趣味はボルダリング、ウクレレ。 西野 香織さん 2009年4月に新卒入社。ニフティポイントの開発チームに所属し、「ニフティポイントクラブ」のスクラムマスターとして従事。N1!制度のスクラムエヴァンジェリストとして、社内各チームのスクラム導入やサポートを実施。スクラムマスターギルドを主催し、社内のアジャイル文化の醸成にも貢献している。趣味は漫画を読むこと、絵を描くこと。アフタヌーンティーめぐり、ボードゲーム。 ニフティのスクラム開発における「スクラムマスター」の役割とは？ ―― はじめに、みなさんの略歴と業務内容を教えてください。 吉田さん 2018年に子会社からニフティに転籍し、2020年から現在のポイントチームに所属しています。現在は企画側のプロダクトオーナーとして、「ニフティポイントクラブ」というポイントサイトの運営と方針の策定や、各ステークホルダーとの調整などをメインに行っています。 清水さん 2017年にエンジニアとして新卒入社し、2年目から会員基盤チームで働いています。現在、メインで担当しているのは、「シングルサインオンシステム」という、ニフティのさまざまなサービスにログインする際の認証システムの開発や刷新です。開発チームのリーダーでもあり、チーム内のアウトプットの最大化に注力しています。 西野さん 2009年に新卒でニフティに入り、現在は吉田さんと同じポイントチームで、スクラムマスターとして「ニフティポイントクラブ」の開発に携わっています。また、社内のN1!制度（※1）のスクラムエバンジェリストとして、別チームのスクラム導入を支援する活動も行ってきました。 （※1）N1!制度……特定の分野で突出した知識とスキルを持って活躍している社員の中から、 「N1！（NIFTY No.1）」として任命する制度。自身の知見を社内にシェアし、組織全体に新しい開発文化を根付かせる役割も担う。 ――ちなみに、ニフティのスクラム開発における「プロダクトオーナー」「スクラムマスター」の役割とは、具体的にどのようなものでしょうか。 吉田さん プロダクトオーナーは、シンプルに言うと「何を作るか」を決める役割です。顧客が何を求めているかを整理し、やるべきことの優先順位を決める、プロダクト全体の責任者ですね。 西野さん スクラムマスターの仕事は多岐に渡りますが、最も重要なのは、企画側と開発側のコミュニケーションをスムーズにするためのサポートや、対話を生むための環境づくりです。プロダクトをグロースさせる上で障害になることを取り除くと同時に、サービスを発展させるためにあらゆることをやる役割だと思っています。 また、自チームの改善だけでなく、組織全体にアジャイル文化やスクラム開発を浸透させるのも、スクラムマスターの使命。ニフティには私や清水くんのように別チームに所属するスクラムマスターが集まるギルドがあり、定期的に意見交換しながら社内のスクラムをより深化させる活動を行っています。 スクラム開発をより理解したい。スクラムマスターの資格を取った理由 ――吉田さんはプロダクトオーナーの資格を、西野さん、清水さんはスクラムマスターの資格をそれぞれお持ちということですが、資格取得のきっかけを教えてください。 吉田さん プロダクトオーナーの資格を取得したのは2024年の夏です。2022年頃から「ニフティポイントクラブ」の開発チームがスクラム開発を導入したのを機に、スクラムを意識し始めました。その際に企画側からプロダクトオーナーを出すことになり、私の上長がプロダクトオーナーを務めることになったんです。 ただ、上長は忙しくスクラムにコミットすることがむずかしかったので、私が代理として職務を任されるうちに、「ちゃんと学びたい」と思ったことが資格取得のきっかけです。もともと開発チームがスクラム開発を始めた時に、アジャイル開発のマインドセットやプロダクトマネジメント・スクラムといった知識は勉強し始めてましたが、プロダクトオーナーを全うするにあたって裏付けとなる知識やスキルを習得したいと考えました。 西野さん 私はもともとエンジニアではなく、フロントエンドのコーダーから制作ディレクターを経て、スマホアプリの開発チームに入りました。その際、アプリの売り上げが伸びて開発メンバーを補強することになり、私がチームリーダーになってしまったんです。エンジニアの知見がなく、開発そのものを牽引できるわけではない私が、どう開発者とコミュニケーションを取っていくかを模索していた時に出会ったのがスクラムでした。開発チームとステークホルダーの協力体制を作り、メンバーがスムーズに動けるようサポートする。それが自分にできる貢献の仕方と考え、スクラムマスターの資格を取得しました。 清水さん 私は学生インターンとしてニフティに来た2015年に、スクラム開発を体験するワークショップに参加しました。大学の研究室では、基本的に一人で活動するのが当たり前だったこともあって、こんな開発手法があるのかと、良い意味でショックを受けたんです。また、入社後に所属した会員基盤チームでも早くからスクラム開発を導入していて、徐々に「スクラムのことをもっと理解したい」と思うようになりました。そして、2021年に上長に相談の上、スクラムマスターの資格を取得したという流れですね。 私の場合は西野のように自分自身が旗を振ってスクラムを導入した経験はありませんが、スクラムマスターとしての知見を活かし、チーム内のコミュニケーションがより円滑になるよう働きかけを行っています。 「いきなり会議」はNG。コミュニケーションを増やすための泥臭いアプローチ ――西野さんがスクラムマスターとしてチーム運営に携わった、具体的な事例を教えてください。 西野さん 私は1年半前にポイントチームにジョインしたのですが、当時は複数のチームが別々に進めていたプロジェクトが終了し、チームを一つに統合するタイミングでした。当時の課題は、それまで同じポイントチームでありながら別部隊で動いていたため、チーム内で情報の分断が起きていたこと。そして、企画側と開発側の会話頻度が少ないこと。そこを解消するのが、スクラムマスターとしての私の役割でしたね。 ――どんなアプローチで、そうした課題を解消したのでしょうか？ 西野さん やり方自体はわりと泥臭いというか、難しいことは何もしていなくて。たとえば、企画側と開発側のコミュニケーション不足については、1日1回は私のほうから企画チームがあるフロアに足を運び、会話する時間を設けました。（※2）時には私以外の開発メンバーも連れていったり、企画側のプロダクトオーナーやステークホルダー、開発メンバーが打ち解けやすい空気づくりだったり、飲み会を企画して親睦を深めたり。色んなことをやりましたね。 コミュニケーションを深めようとして、いきなり会議を増やしたりすると、みんな嫌がるじゃないですか。会議を設定する前に、まずはシンプルに仲良くなることが大事です。その上で話してみると、企画側も開発側も共通の課題を抱えていることが分かったり、目指す方向が同じだったりすることも多い。そうした、根っこの部分を共有することが何より大事なのだと考えています。 ――企画側も開発側も目指すゴールは一緒。しっかりコミュニケーションさえ取れていれば、お互いに不満を抱いたりすることもなさそうです。 西野さん そうですね。たとえば、企画側としては「こちらは開発に色々と依頼しているのに、なかなか動いてくれない」といった不満もあったようです。でも、困っていてもなかなか言いづらい空気があり、不満だけが募ってしまう。ただ、開発側には開発側の言い分もあるわけです。そこはやはりスクラムマスターが間に入り、風通しをよくしていくことが大事ですね。 実際、今のポイントチームでは企画と開発の垣根を超えて本音が飛び交う、本質的な議論ができていると思います。ミーティングでも「今の話、よく分からないです」「それって本筋から外れていませんか？」みたいなことも遠慮なく言い合えて、互いに目指す方向は同じと分かっているから揉めることもありません。 吉田さん それまでは開発側とのやりとりが少なかったり、基本的にテキストベースだったりで、文章だけでは時に誤解が生じ、感情的になってしまうこともありました。西野がポイントチームに来てくれてから、細かいことまで話し合う文化が生まれ、そうした行き違いや認識の齟齬は減ったと思います。 （※2）インタビュー時点。2026年5月にオフィス移転し、現在は同フロアになっています。 吉田さん ただ、コミュニケーションは活発になったものの、自身も含めまだまだ改善の余地はあると考えています。今後は企画側も、スクラム以前にアジャイルのマインドセットやプロダクトマネジメントに関する理解を深めつつ、開発サイドに寄り添うメンバーをもっと増やしていきたいですし、それは企画チームのサブリーダーでもある自分の役割だと認識しています。 後編に続きます！ 今回はニフティのスクラム開発を牽引するエキスパートたちのインタビュー（前編）の様子をお届けしました。後編は近日中に公開します。 このインタビューに関する求人情報 /ブログ記事 ニフティ株式会社 求人情報