kintone開発組織の DevOpsへの移り変わりと実践 サイボウズ株式会社 上岡 真也 / @ueokande #jjug_ccc #jjug_ccc_e 

はじめに サイボウズのクラウドサービス「kintone」は、近年までサービス運用を専用の運用部署が担当。事業拡大 とシステムの複雑化により、開発組織と運用組織が別になっていることによる課題が顕著になってきた。 今まではアーキテクチャの制約により、DevOps体制を作るのが難しかった。しかし近年、社内のクラウド プラットフォームを刷新して技術的な課題をクリア。運用権限を製品開発チームに広く渡せる状態となった。 運用業務が定着していない製品開発チームに、単に「運用よろしく」では、サービスの信頼性維持が難しい。 運用できる開発組織を作るために様々な準備が必要になる。 本日はkintone開発組織に運用業務を定着させるまでのストーリーを紹介。 概要 kintone開発組織のDevOpsへの移り変わりと実践 2 

3 01 02 03 04 サイボウズという会社 サイボウズのクラウドサービスの運用 運用できる開発体制に まとめ P03 P10 P16 P26 目 次 

はじめに サイボウズ株式会社 開発本部 2016年にサイボウズに入社。社内のクラウド環境 （プライベートクラウド・パブリッククラウド）や、 バックエンドサービスの開発・運用を経験。 2023年からマネージャー。サイトリライアビリティや プラットフォームエンジニアリングを軸に活動。 自己紹介 上岡 真也 う え お か し ん や X/GitHub: @ueokande kintone開発組織のDevOpsへの移り変わりと実践 4 

サイボウズという会社 5 

サイボウズという会社 チームワークあふれる 社会を創る サイボウズの理念は「チームワークあふれる社会を創る」こと。 私たちはその理念に沿ってチームワークを支えるソフトウェアを 開発し続けてきました。 6 

主力製品 開発の知識がなくても 業務に合わせたシステムを かんたんに作成できる クラウドサービス 7 

サイボウズという会社 サイボウズの歩み（決算報告から抜粋） クラウドビジネス転換 kintoneをリリース パートナービジネス開始 Garoonリリース メールワイズリリース kintone成長 1997 2002-2003 2011 2017- 2022 創業 サイボウズ Office リリース 創業期 販売網開拓期・M&A期 クラウド転換期 kintone成長期 kintone 連結売上高 100億突破 kintone開発組織のDevOpsへの移り変わりと実践 8 

サイボウズという会社 サイボウズのクラウドサービスは、国内データセンターのプライベートクラウドで構築。ベアメタルサー バー上に、自社の仮想化基盤を構築し、アプリケーションを展開。 近年はパブリッククラウドを活用した新機能開発も推進。 クラウドサービスの運用環境 kintone開発組織のDevOpsへの移り変わりと実践 9 

サイボウズのクラウドサービスの運用 10 

サイボウズのクラウドサービスの運用 サイボウズのクラウドサービスのサービス運用は、長らく専用の部署が担ってきた。 • 運用チームは、インフラ基盤、ミドルウェア（MySQL、L7LB、etc）の構築、製品の運用までカバー。 • 製品開発チームは、成果物を運用チームに受け渡すまでが責務、本番環境の権限を保てない。 これまでの開発・運用体制 本番環境 VM基盤 MySQL L7LB Blob FTS kintone Garoon .... 製品開発 チーム 運用チーム エスカレーション オペレーション・調査依頼 kintone開発組織のDevOpsへの移り変わりと実践 11 

サイボウズのクラウドサービスの運用 課題1: 運用難易度の向上。システム規模の拡大によって、運用チームの認知負荷の向上や、オンボーディ ングの課題が顕著に。 • インフラ、VM基盤、L7LB、MySQLなどを運用する知識が要求される。 • 異なる技術スタックを採用（Javaアプリケーション&Jettyサーバー、PHP&CGI、等）した製品の運用。 課題2: 製品の開発チームと運用チームが、組織構造上の距離がある。 • 本番環境のオペレーション実施は製品開発チームはできない。メトリクスの追加や運用ツールの導入など の運用改善は依頼ベース。 • 運用業務が開発プロセスに組み込まれていない。開発チームが運用環境からフィードバックを得られる動 機の減少。 運用体制の課題 kintone開発組織のDevOpsへの移り変わりと実践 12 

サイボウズのクラウドサービスの運用 kintoneローンチ当時のアーキテクチャは、サービス運用者にインフラや製品の運用知識を求めるモデル。 本番環境の管理権限は限られたメンバーのみが持ち、 製品ごとの運用権限は分離されていない。 そのため 製品開発チームに広く展開できなかった。 ログやメトリクスは徐々に開発チームに展開してきたが、運用に必要な権限は運用チームのみが持つ。 DevOps実現する上での技術的制約 VM基盤 MySQL L7LB Blob FTS kintone Garoon .... kintoneのオペレーション権限を付与すると、 他の製品やインフラ基盤の管理権限もついてくる kintone開発組織のDevOpsへの移り変わりと実践 13 

サイボウズのクラウドサービスの運用 事業規模の拡大に伴い、インフラ面・組織面でスケーラビリティの課題が出てきた。長期的な事業継続のた めにも、VMベースからKubernetesベースのアーキテクチャに刷新する。 権限モデルを見直して、各製品やコンポーネントごとに名前空間を定義。各チームは名前空間内のリソース に責任を持ち、他チームの名前空間内にあるリソースは書き換えができない。 新プラットフォームへの移行 Kubernetes MySQL L7LB Blob FTS kintone Garoon VM基盤 MySQL L7LB Blob Blob kintone Garoon 他チームのリソースには アクセスできない デプロイや運用は各チームの 名前空間内で自由に実施可能 kintone開発組織のDevOpsへの移り変わりと実践 14 

サイボウズのクラウドサービスの運用 新しいアーキテクチャによって開発チームに運用権限を渡せるようになった。しかし単に「運用よろしく」 はできない。大前提として、体制やアーキテクチャは変わっても、サービスの信頼性は変えない。 製品開発チームが運用するためには準備が必要。新しいアーキテクチャ上で、開発組織が運用できる体制を 作る必要がある。 • 運用スキルの課題。製品開発チームでは運用経験が少ない。 • 運用に携わるチームが増える。障害解決のためにチーム間の連携が必要。 仕組みは揃ったが... kintone開発組織のDevOpsへの移り変わりと実践 15 

運用できる開発組織に 16 

運用できる開発組織に 製品開発チームを運用できる開発組織にするために、「仕組み」と「体制」の二軸で考える。 • 「仕組み」 ... 運用容易性を担保するための技術的アプローチ。モニタリングやアラート。 • 「体制」 ... 運用を実行可能にするための人やプロセスの設計。 製品開発チームと今の運用チームから人を集めて、以下の狙いを持って部署横断 （本部横断） のプロジェ クトを発足。 • 今までの運用プラクティスのスキルトランスファー。 • 開発チームと運用チームの両者の業務を円滑に変更できる。 • 他のマネージャーからのスポンサーシップを得やすい やったこと kintone開発組織のDevOpsへの移り変わりと実践 17 

運用できる開発組織に 現在の体制の課題やDevOps体制を作ることのメリット・トレードオフを、関係者と繰り返しディスカッシ ョンする。今の社内の体制、社内のDeｖOps事例、kintone開発組織への業務への組み込み方を伝えて解像 度を上げてもらう。 知識として 知っている「DevOpsって必要なんですね」から認識を一段上げる。 取り組み1 | 心を動かす kintone開発組織のDevOpsへの移り変わりと実践 18 社内資料抜粋 

運用できる開発組織に 新しいアーキテクチャやツールを知ってもらうための勉強会を実施。社内のマルチテナントアーキテクチャ やオブザーバビリティ、Kubernetesエコシステムのツールや製品のトラブルシュート事例を紹介。 • kintoneのアーキテクチャ • ログ、メトリクス、オブザーバビリティ • Kubernetesエコシステム • kintoneのトラブルシュート事例 • 社内運用ルール 取り組み2 | メンバーへのオンボーディング kintone開発組織のDevOpsへの移り変わりと実践 19 

運用できる開発組織に 新しいプラットフォームでは、開発チームがKubernetes上にモニタリング・アラートを設定して、自分た ちで運用改善する。製品チームが旧アーキテクチャと同等の水準で監視できるようガイドラインを定義。 例 • サービスの正常性。Kubernetes Deploymentが正しくレスポンスを返すか。 • ロールアウトの正常性。Podが再起動を繰り返してないか。正しいReplica数か。 • SLO/ユーザービリティに基づく監視。応答時間やエラー率。 • OSやJVMのリソース監視。ディスク使用率の上昇など放置すると障害につながるもの。 取り組み3 | モニタリングポリシー kintone開発組織のDevOpsへの移り変わりと実践 20 

運用できる開発組織に 設定したアラートそれぞれに対応する、障害対応手順書（Runbook）を準備する。アラート発生からスム ーズに障害対応を始められるよう、アラート本文に手順書へのリンクを貼る。対応者の習熟度に依存せず、 緊急時に焦らず手順を実行できる狙い。 障害対応手順書には以下の事項を含む • 原因切り分け手順。ダッシュボードへのリンクやメトリクスの説明。 • 障害を是正する手順。オペレーションや切り戻し手順。 取り組み4 | 障害対応手順ポリシー kintone タイトル: エラー率向上 サービス: Worrker Runbook: https://...... 監視 通知 対応者 kintone開発組織のDevOpsへの移り変わりと実践 21 

運用できる開発組織に 各サービスのインシデント発生状況を、単一のダッシュボードで可視化。他チームのサービス稼働状況やイ ンシデント発生元の特定に役立てる。ためらうことなくエスカレーションをして、チーム間で連携して障害 対応に取り組める狙い。 取り組み5 | 社内ダッシュボード kintone開発組織のDevOpsへの移り変わりと実践 22 

運用できる開発組織に サイボウズの組織構造: 製品開発とプラットフォーム開発をする部署が組織的に異なる。前者は各製品やコ ンポーネントごとのチーム。後者はKubernetes基盤、データベース、ストレージなど、製品の運用に必要 な仕組みを提供。 従来は運用チーム（プラットフォーム開発の部署）が製品の障害対応と、オンコール体制を回していた。製 品チームも巻き込んだ24/7オンコール体制を考える必要がある。 取り組み6 | オンコール体制の設立（1/2） kintone 認証基盤 バックエンド Storage Database Kubernetes ・・・・ ・・・・ kintone開発組織のDevOpsへの移り変わりと実践 23 開発本部 クラウド 基盤本部 

運用できる開発組織に チーム単位、チーム合同、部署合同など様々なオンコール体制を評価。最終的に部署単位のチーム合同でオ ンコール体制を設立。 • チーム単位のオンコール: 開発と運用をするメンバーが一致するので、運用環境のフィードバックが最も 得やすい。小さなチームではシフトを回すのが難しく、過剰な体制となる。 • 部署合同: 小さなチームをカバーできて運用負荷が低い。技術スタックが全く異なるチームの成果物を運 用をすることの技術的・心理的ハードルが大きい（例:製品チームがインフラ運用をできるか）。 取り組み6 | オンコール体制の設立（2/2） チーム単位 部署合同 チーム合同（本部独立） kintone開発組織のDevOpsへの移り変わりと実践 24 

運用できる開発組織に 障害対応の教育や訓練には様々なやり方がある。 • 関係者全員を含めた訓練 • 対応手順の確認のためのドリル • 実際に障害を起こす訓練 • 障害対応シナリオのロールプレイ 障害対応を始めて行うメンバーがほとんどだったので、障害対応シナリオのロールプレイを実施。 取り組み7 | 障害対応ロールプレイ（1/2） kintone開発組織のDevOpsへの移り変わりと実践 25 

運用できる開発組織に ロールプレイは事前に準備した障害シナリオに則って障害対応を実施。 ２つの役割に分かれて実施。 • ナビゲーター: ロールプレイの案内役。シナリオの読み上げやインシデント発生状況を伝える。 • 対応者: ロールプレイのシナリオに沿って障害対応を行う。 取り組み7 | 障害対応ロールプレイ（2/2） 障害が発生しました。PagerDuty確認してSlackで応答してください。 （PagerDutyでAcknowledge、Slackで返答） 障害対応手順に従って対応を開始ます。まずはGrafanaでメトリクスを確認 してSlackで観測報告を報告してださい。 （Slack「本番環境でエラー率が上昇してます」） 本番環境でお客様影響があります。社内連絡と社外告知の準備を進めてくだ さい ナビゲーター 対応者B ナビゲーター ナビゲーター 対応者A kintone開発組織のDevOpsへの移り変わりと実践 26 

まとめ 27 

kintone開発組織のDevOpsへの移り変わりと実践 まとめ オンコール対応は誰がしも簡単に受け入れできる業務ではない（プライベート、休暇、育児、etc）。その ため各部署のマネージャーと、それぞれの選択肢を比較。オンコール開始前、開始後は、労務（安全配慮義 務）、チームの工数管理、心理的ハードルなどを、メンバーとマネージャーに丁寧にフォロー。 オンコール体制もそれぞれのチームにヒアリングして、技術的なハードルや管理上の難しさを考慮。それを 元にオンコール体制を選定。 運用開始後も定期的に振り返りを実施。異なる製品開発チームで、普段のコミュニケーションはオンライン が基本。ふりかえりなどの機会を意図的に作り、継続的に運用体制そのものの運用改善を行う。 Lesson learned | オンコール体制の設立 28 チーム単位 部署合同 チーム合同（本部独立） 

まとめ 新プラットフォームへの移行後も、運用チームが持っていた外形監視などの一部モニタリングが利用可能。 開発部署による運用体制がスタートしてもしばらくは、製品の監視に両部署で並行運用した。 並行運用期間を設けたことで以下を確かめる事ができた。 • 製品開発チームで設定した新しいプラットフォーム上の新しいアラートの精度を検証できる。新しいアラ ートが、もともとあるアラートと同じ水準で動作するか。 • 製品開発チームのオンコール体制がうまく運用できるか。 Lesson learned | 並行運用期間の設定 kintone開発組織のDevOpsへの移り変わりと実践 29 kintone 監視 製品開発 チーム 監視 プラットフォーム チーム 

kintone開発組織のDevOpsへの移り変わりと実践 まとめ オンコール開始前に運用を始める人といっしょに実際に手順をロールプレイを実施。ランスルーすることで 障害対応時に詰まるポイントを事前に知ることができた。運用開始前に手順書をブラッシュアップにつなげ る事ができた。 Lesson learned | ロールプレイによる事前チェック 30 障害が発生しました。PagerDuty確認してSlackで応答してください。 （Acknowledgeボタン...どれだ？？） 障害対応手順に従って対応を開始ます。まずはGrafanaでメトリクスを確認 してSlackで観測報告を報告してださい。 （どのメトリクスが、どれくらいに達してたら異常なんだ？） 対応者B ナビゲーター ナビゲーター 対応者A 

まとめ 2025年Q1に、製品開発チームが、オンコールや運用業務をスタート。それから実際の障害対応や運用業務 を経験したが、完全な定着までは時間を要する。これから答え合わせのフェーズ。 これまで開発に集中していたチームに運用業務が割り込む事象が増える。開発チームが運用環境からのフィ ードバックを活かせるには時間がかかる。事実検証ができるのは。 実は運用スタートしたのはkintoneとそのサブシステムのサービスのみ。これから新アーキテクチャに移行 するプロダクトもある。その体制を含めた、真の開発組織の運用体制はこれから。 運用体制の結果...！？ kintone開発組織のDevOpsへの移り変わりと実践 31 

告知 サイボウズの企業理念に共感し、一緒にkintoneの開発に取り組んでいただける方を募集しています。 We’re hiring kintone開発組織のDevOpsへの移り変わりと実践 32