協力会社とのスクラムをやめてカイゼンが進んだ話

こんにちは。システム開発部のsonohaです。ニフティ温泉のWEBサイトの開発全般を担当しています。

以前にパートナー企業と一緒に取り組むスクラム開発のススメで書いていたように、私はスクラムマスターとして2年前から協力会社とのスクラム開発を推進してきました。
ある課題感をきっかけとして半年ほど前にスクラム開発をやめる決断をし、現在はDevOpsの思想をベースにしたカンバンとチームトポロジーを用いた開発手法を採用しています。手法を変えてから半年が経過し知見が貯まりつつあるので、今回はそのアウトプットをしていきます。

目次

協力会社とのスクラム開発で顕在化した課題

パートナー企業と一緒に取り組むスクラム開発のススメに記載していた課題「組織構造的な隔たり」「物理的な隔たり」「心理的な隔たり」に加え、「運用と複雑性の増大」と「属人化と知見の蒸発」が顕在化してきました。

運用と複雑性の増大

ニフティ温泉では最近、決済サービスの新規開発という大規模なリリースがありました。
これに伴い、様々な機能や運用が加速度的に追加されたことで作業量や難易度がチームのキャパシティを超え始め、その結果、機能リリースや運用作業における不具合発生の頻度が目に見えて増えてきました。
しかし、プロダクトバックログリファインメントにおいて安定性向上や運用改善に関するタスクの優先度が上がらず、スクラムチームとしては施策開発・機能追加を優先していく判断となりました。

なんとか弊社メンバーが自動テストを強化するなど独自にカイゼン活動に着手しましたが、スクラム内のタスクではなかった(＝委託範囲外だった)ため協力会社メンバーは明示的にこれに加わることはできず、チーム全体で見るとカイゼンの文化が育ちませんでした。

※カイゼンとは：ソースコードのリファクタリングやCI/CDの構築など、これまでの技術的負債の解消および今後の開発をしやすくするための環境を整えるような、継続的な一連の改善活動のことを指します。

属人化と知見の蒸発

通常スクラムでは機能横断的なチームを目指すために、メンバーのスキルセットによらず優先度の高いスプリントバックログアイテムに着手していくので、結果的に非属人化していくことが多いです。しかし協力会社との契約においては発注工数を有効活用する力学が働くため、得意な人が特定のタスクを取るという動きが増え、属人化が進行しました。

その上で協力会社メンバーの入れ替えが相次いだタイミングがあり、アジャイル開発の非ドキュメント文化と相まって、蓄積された知見が一気に失われることがありました。

DevOpsの思想の導入

協力会社の持つ制約を許容しつつ新たに生まれた課題を改善するために、スクラムの仕組みを一部残しながらDevOpsの思想を導入し、新しい開発手法で進めていくことにしました。

以下の4つの観点で紹介していきます。

• スクラムから引き継いだ部分
• 新しく取り入れたDevOpsの思想
  • CALMSフレームワーク
  • チームトポロジー
  • DevOpsライフサイクル

DevOpsの概念を実践に落とし込むためのフレームワークについては、Atlassian社の記事が体系的にまとめられていて分かりやすかったので、これを参考にしています。
気になる方は先にこちらをご覧ください。
https://www.atlassian.com/devops/frameworks

スクラムから引き継いだ部分

以下のスクラムイベントは、チーム内外のコミュニケーションを活性させることに大きく寄与していたので、名称を変えて継続することにしました。

• デイリースクラム　→　朝会
  • 毎日朝に開催し、旧スクラムガイドにある3つの質問（昨日やったこと・今日やること・障害となるもの）の他、今日の体調の共有や勤怠連絡を行う場としています。
• スプリントレビュー　→　プロダクトレビュー
  • 隔週で企画・営業・開発・その他ステークホルダー（計15名程度）を招き、直近開発した成果物を披露・解説してフィードバックをもらう場としています。

これ以外の、スプリントプランニング、スプリントレトロスペクティブ、プロダクトバックログリファインメントは廃止としました。

CALMSフレームワーク

DevOpsの原則のひとつであるCALMSフレームワークを借りて、次のような方針で開発チームの動き方の方向性を定めることにしました。

• Culture、Sharing
  • 業務時間内は常に通話を繋いでおくことで、メンバー間の対話と協働を促進しています。
  • 隔日で相談会という開発・企画が集まる会議を設け、開発中の機能の要件や仕様を確認したり、もっと上流の目的や方向性を話し合ったり、逆にもっと下流の具体的な実装方法の壁打ちをしたりする習慣を作っています。
  • 毎週、部長や開発スペシャリストとコミュニケーションを取る場を設け、組織横断での情報交換を可能にしています。
• Automation、Lean
  • 運用と複雑性の増大や属人化を解消する目的で、チームとして明示的に自動化を推進する方針を定めました。
  • 「自動化」に含まれるものは、プロダクトに対するテストの自動化・デプロイの自動化・ドキュメント生成の自動化などです。
• Measurement
  • 開発チームとプロセスのヘルスチェックのために、DORAのFour Keys（変更のリードタイム・デプロイ頻度・変更障害率・平均復旧時間）を自動で測定できるように準備中です。
  • 事業のヘルスチェックのために、事業KPIを自動的に収集・集計・レポーティングする仕組みの導入を進めています。

チームトポロジー

品質（安定性・可用性・性能）向上や運用保守性向上への動きが疎かになりつつあったことを受け、DevOpsと関連のあるチームトポロジーの概念を借りて、「施策開発チーム」と「カイゼンチーム」に分離する方針を取りました。

• ニフティ温泉 施策開発チーム
  • チームトポロジーでいう、ストリームアラインドチーム。
  • 主に協力会社メンバーで構成し、新規機能開発に集中します。
    • 機能開発に必要な業務権限は限られるため、協力会社に委託する業務の境界を定めやすいです。
    • ストリームの生成（＝開発の上流工程）には弊社メンバーが携わります。
• ニフティ温泉 カイゼンチーム
  • チームトポロジーでいう、プラットフォームチーム。
  • 主に弊社メンバーで構成し、既存システムの運用保守をしながら、カイゼンや自動化を推進します。
    • 業務範囲が既存システムの全てになるため全権限が必要になり、協力会社へは委託しにくい内容となります。
• 共通基盤チーム
  • チームトポロジーでいう、コンプリケイテッド・サブシステムチーム。
  • 複数の事業を横断して活用される会員基盤やメール配信基盤の運用保守開発を担当します。
    • ニフティ温泉の会員機能をエンハンスする場合、一部タスクを切り離してこのチームへお願いすることがあります。

DevOpsライフサイクル

DevOpsにおけるライフサイクル（計画、実装、ビルド、テスト、リリース、デプロイ、運用、モニタリング）の中で、特に次の3つにフォーカスして改善を試みています。

• 計画
  • スクラムにおけるプロダクトバックログを2つの粒度に分割しました。
    • プロダクト企画カンバン
      • プロダクト企画に関わる要望を、すべての関係者（企画・営業・その他ステークホルダ）から吸い出して管理するカンバン。
      • 主に企画メンバーが操作をし、開発着手可能でないアイデアを書き出し並べ、優先度を調整しながら企画要件を固めていきます。
      • ツールとしては、企画メンバーが操作しやすいようにJIRAを利用しています。
    • 開発カンバン
      • プロダクト企画カンバン内のアイテムうち要件が固まり開発着手可能となったものをこちらに移行し、以降の開発進捗を管理していくためのカンバン。
      • 主に開発メンバーが操作をし、誰がどの案件を担当しており今どのようなステータスなのかを一覧できるようにしています。
      • ツールとしては、開発メンバーが操作しやすいようにGitHub Projectを利用しています。
• テスト
  • 恥ずかしながらこれまでは手動テストが主だったため、できるところから自動テストを導入していってます。
    • 自動テストのアンチパターンである「アイスクリームコーン型」となる覚悟で、文化形成の最初の一歩として、まずは分かりやすいE2Eテストの自動化から進めています。
    • 次にユニットテスト→APIテスト→インテグレーションテストと、「砂時計型」を経て「ピラミッド型」や「トロフィー型」などのベストプラクティスに近づくように自動化の拡大を検討しています。
• リリース
  • チームトポロジーの概念を導入したことで、複数の開発が同時に並行稼働することが増えました。これによってリモート検証環境での衝突が発生しやすくなったため、これを改善することも試みています。

半年運用してみての所感

スクラムをやめて新たなプロジェクト管理を始めて半年が経過しました。
所感としては以下の通りです。

☀️作業時間が増えた

スクラムイベントに費やす時間が削減された分、メンバーの作業工数が増えました。
具体的には以下の通りです。

• 1ヶ月で増えた作業工数 = 8h x n人 = n人日
  • スプリントプランニング（3h x 2回 = 6h/人）
  • スプリントレトロスペクティブ（1h x 2回 = 2h/人）

n=8人の場合であれば8人日相当の工数が削減されます。これにより小規模の機能改修を1〜3つリリースできますので、小さくない工数です。

☀️カイゼンが進んだ

CALMSフレームワークとチームトポロジーの導入により、チームとして明示的にカイゼンを進めていく宣言をしたので、テスト自動化やドキュメント生成自動化などのカイゼンを複数リリースすることができました。（大小含め半年で20件以上！）
これまでは施策の合間を縫ってちょっとしたリファクタリングを実施したり、施策に混ぜ込む形で割れ窓修繕を実施するなど、なんとなく「隠れて工数を使っている」というような意識があったカイゼン活動ですが、それをチームとして正当化したことで様々な取り組みに踏み出すことができました。

☔️工数見積もりの精度が下がった

これまでのスクラム開発では、少なくとも2週間に1回はリリースできるような粒度まで施策を分解して開発を進めていました。
今回スプリントの概念が無くなったことでリリースの粒度も大きくなり、開発期間が1ヶ月を超える案件も増えてきました。開発期間の長さに伴って要件が大きく複雑になるので不確実性も高くなり、工数見積もりが機能しにくくなるという事象に至りました。

☔️メリハリが減った

スプリントというペースメーカーが無くなったため、施策開発チームは常に施策に追われている状態になりました。息をつく暇が無くなりがちなので、リーダーが上手くタスクを調整していかないとメンバーが疲弊していく印象があります。
そんな中でストーリーポイントによるベロシティやキャパシティといった指標も無くなったため、タスク調整の難易度が上がった印象があります。

加えて、プロセスを振り返るタイミングが無くなったことで、ヒューマンエラーへの反省や工数見積もりの信頼性を考える機会が減りました。
大きな施策をリリースしたときや1ヶ月に1回など、自分たちでタイミングを決めて主体的に振り返りをしていくことが重要になりそうです。

今後の展望

🔥メリットを伸ばしデメリットを抑える

前述の所感のうち、「作業時間が増えた」「カイゼンが増えた」という点を伸ばしていくために、メンバーの役割分担の整理や不要な会議を減らす取り組みは今後も続けていきたいと思います。
一方で「メリハリが減った」「工数見積もりの精度が下がった」を低減するために、あらためてアジャイル開発の思想に立ち戻り、リリース粒度を小さく分解すること、PDCAのPlanとDoだけでなくCheckとActionのプロセスを明確に設けること、などの取り組みを実施していく予定です。

🔥チームの開発力を計測可能にする

現在はDORAのFour Keysの導入が完了しておらず、カイゼンによる効果を定量的に評価できていません。
今後、GitHubのマージ履歴などからFour Keysを自動で集計し、それを開発チームのKPIとして運用できるようにしていきたいです。

🔥大きな技術マイグレーションに挑戦する

先にカイゼンが進んだと述べましたが、これは既存システムの周辺領域で新たな自動化などを構築できたという意味です。レガシーな既存システムの技術スタックそのものに手を加えていくことはまだできていません。
以前からチームとしてレガシーシステムへの課題意識はあるため、このカイゼン活動を拡張していき大規模な技術マイグレーションに挑戦できると、開発チームとしてだけでなく事業としてさらに前進していけると考えます。

🔥組織横断でのSRE展開

さらに、現在こういったカイゼン活動は温泉開発チームに閉じて独自に進めているものになるので、将来的にはこれを横展開し、不動産テック事業やクロステック事業の開発メンバーも巻き込んだ形で、システムの信頼性を向上させたり開発体験を高めたりするSRE活動として推進していければと思います。

まとめ

今回は、協力会社とのスクラム開発をやめ、DevOpsの思想を盛り込んだ開発手法へ移行したお話をしました。まとめると以下の通りです。

• 課題
  • 協力会社の制約により、複雑化と属人化が進んだ
• やったこと
  • スクラムから引き継ぐ部分とやめる部分を決めた
  • DevOpsの思想を借りて、施策チームとカイゼンチームに分けた
• 変わったこと
  • 作業時間が増え、カイゼンが進んだ
  • メリハリが減り、工数見積もりの精度が下がった
• 展望
  • メリットは伸ばしつつ、デメリットは抑えるように取り組んでいく
  • 開発のKPI策定、レガシーシステム刷新、全社でのSRE活動に発展させたい

参考になる部分がありましたら幸いです。
最後までお読みいただきありがとうございました。

---

ニフティ温泉では一緒にプロダクトとチームを盛り上げていく仲間を募集しています。
エンジニアの採用も積極的に行っていますので、ご興味のある方は、ぜひお気軽に採用ページよりご連絡ください。