3つのボトルネックを解消し、リリースエンジニアリングを再定義した話

【DevOps Days Tokyo 2026登壇資料】
セッションURL: https://confengine.com/conferences/devopsdays-tokyo-2026/schedule/rich#session-34363-info

私たちの会社には「今、“いいもの”を作る」というValueがあります。完璧さを求めて時間をかけるのではなく、70%の完成度でも世に出し、フィードバックを得て高速に改善するという文化です。

しかし、開発組織が3チーム・20名規模に拡大したとき、私たちはこの文化を体現できなくなっていました。 当時のリリースの仕組みは「隔週に1回の定期イベント」。原因は「ダウンタイム必須のデプロイ」による調整コストと、「git-flow」によるチーム間のマージ待ち・CI渋滞でした。これらがボトルネックとなり、私たちは作りたいスピードで作れないジレンマを抱えていたのです。

この「隔週リリース」という制約を一つずつ破壊し、リリース頻度を「1日3回（約40倍）」に引き上げるまでの、組織と技術の変革プロセスをお話しします。

Transcript

1. DevOpsDays Tokyo 2026 2026.04.14 隔週1回から1日3回へ 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話 株式会社ニーリー 大木 建人 / 高 直我
2. 月あたりのリリース回数
3. 本日の登壇内容 プロダクト成長速度の速いスタートアップにおいて、 成長を妨げず、加速剤となるリリースエンジニアリングについて そのための開発者体験の向上施策と、 高速かつ安全に開発するための技術的ガードレールの話 改善のリソースを「いつ」「どこに」「どれだけ」 投下するのが最適なのか、という話 「スタートアップの我々がこうだった」という話をするが、 スタートアップに限定した話では決してないので、ぜひともお楽しみください 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
4. 自己紹介 Kento Ogi 株式会社ニーリー プロダクト統括本部 プラットフォームエンジニアリングG SRE / プラットフォームエンジニアリング チームリーダー 2020年 合同会社DMM.comへ新卒入社。 SREとして大規模なプロダクトのSREing、クラウドネイティブ化に取り組む 2023年 6月に株式会社ニーリーへ入社。 開発者体験の向上やサービスの信頼性向上に従事 現在はSREチームのチームリーダーを担う こんなアイコンをしていて意外と思われますが、実はスノボが好きです @2357gi @2357gi 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
5. 何をやってる会社なの？ BtoBtoCのVertical SaaS「Park Direct」を運営 モビリティプラットフォームを目指す 月極駐車場のオンライン契約を可能にする Mobility SaaS 紙の契約書対応電話対応をなくし 業務負荷を92%削減 集客強化による 売上UP & 月極駐車場 コインパーキング 給油・洗車 通常約14日かかる契約手続きを オンラインで最短約5分に 借主様 （駐車場ユーザー） 駐車場検索 契約サイトの提供 自動車サービス 駐車場情報を Park Directに登録 管理会社様 車両購入・売却 充電スタンド付 駐車場 金融 EV オンライン契約・顧客管理 収納代行（保証付き） 簡単オンライン契約 クレジットカード支払 自動車保険 充電スタンド マップ カーローン 車両整備 オンライン 車検 EC メンテナンス ライドシェア 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
6. あなたの組織が 大切にしている価値観は?
7. あなたの組織の カルチャーは?
8. 今、”いいもの”を作る
9. 今、”いいもの”を作る とは何か① 課題に関しての解像度を上げ、 必要なものを考え抜く
10. 今、”いいもの”を作る とは何か② 完璧を目指さず、 まず作り上げて価値を生み出していく
11. 今、”いいもの”を作る 今、”いいもの”を作る とは何か 課題に関しての解像度を上げ、必要なものを考え抜く 完璧を目指さず、まず作り上げて価値を生み出していく 例えば、70点のモノを作る工数と100点のモノを作る工数は単純に1.4倍ではない 2ヶ月かけて100点を作るよりも、2週間で70点でも良いので作り上げ、 なるべく早くリリースする →早くリリースすることで、複利を生かす。 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
12. これらは割と当たり前なことだけど... Valueとして言語化し、カルチャーとして背負い、
 カルチャーを重視した採用・組織作りを行うことで、 当たり前が当たり前にできる組織が生まれる
13. 今、”いいもの”を作る 組織のスケール→アウトカムの増加 を妨げるボトルネック カルチャーの標榜と浸透、カルチャーマッチを重視した採用の徹底して、
 成長するスタートアップとして、組織もスケールさせていった しかし、人月神話の話も然り、人数を増やすだけではアウトカムは増えなかった。 組織のスケール→アウトカムの増加 を妨げるボトルネックがある →開発の流れの中で、どこにボトルネックが生じたかを洞察し、 　丁寧に解消することでアウトカムを加速させていくことができる 開発の流れのイメージ 開発 リリース ボトルネックは...? 設計 アウトカムの発生 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
14. 3つのボトルネック ボトルネック解消① ゼロダウンタイムでの リリースの実現 月あたりのリリース回数 第一の壁 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
15. 3つのボトルネック ボトルネック解消① ゼロダウンタイムでの リリースの実現 ボトルネック解消② feature環境の整備と技術的ガードレールの導入 月あたりのリリース回数 第二の壁 第の壁 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
16. 3つのボトルネック ボトルネック解消① ゼロダウンタイムでの リリースの実現 ボトルネック解消② feature環境の整備と技術的ガードレールの導入 月あたりのリリース回数 ボトルネック解消③ github-flowの導入と トランクベース開発の実現 第三の壁 第の壁 第の壁 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
17. ボトルネック解消① ゼロダウンタイムでの リリースの実現 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
18. 当初の状態 ゼロダウンタイムでの リリースの実現 FEATURE - YY FEATURE - 最初は隔週に一回の深夜に、 ダウンタイムを取ってしかリリースできなかった CD自体は構築済み 一度developブランチに変更を集約 まとめてstagingブランチへmergeしてリグレッションテストを実施 問題なければ、その日の深夜にダウンタイムを設けてリリース作業を実施 DEVELOP STAGING MASTER 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
19. ゼロダウンタイムでの リリースの実現 当初の状態 ビジネス観点から、日中にダウンタイムリリースは出来ない ダウンタイムなしのリリースはそもそも出来ない設計 課題 人数が増えて開発量が増えたはずなのに、 リリースがボトルネックになった 設計 開発 リリース アウトカムの発生 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
20. ゼロダウンタイムでの リリースの実現 改善の前準備 ローリングアップデートを行ってもシステム整合が取れる変更とそれ以外を整理 ビジネスサイドと運用方法のすり合わせ developを介さず、stagingへ直接mergeできるようにブランチ運用を変更 Before After FEATURE - YYYY FEATURE-B FEATURE-D FEATURE-C FEATURE - XXXX DEVELOP FEATURE-A STAGING STAGING MASTER MASTER 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
21. ゼロダウンタイムでの リリースの実現 ゼロダウンタイムリリースの運用 STAGINGに、ローリングアップデートを行ってもシステム整合が取れる変更を貯める リリースしたい時にstagingブランチでリグレッションテストを実施 問題なければmasterにmergeしてリリース Before After FEATURE - YYYY FEATURE-B FEATURE-D FEATURE-C FEATURE - XXXX DEVELOP FEATURE-A STAGING STAGING MASTER MASTER 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
22. 3つのボトルネック ボトルネック解消① ゼロダウンタイムでの リリースの実現 メンバー増加に負けないくらいリリース回数は増えたが、 次なるボトルネックがまた別の箇所で発生し始めた 月あたりのリリース回数 第一の壁突破🎉 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
23. 自己紹介 Naoga Taka 株式会社ニーリー プロダクト統括本部 プラットフォームエンジニアリングG SRE / プラットフォームエンジニアリング 2019年からバックエンドエンジニアとしてキャリアスタート 2025年2月にニーリーに入社 SREとしてプロダクトの信頼性向上 その他活動に従事 DevOpsDays 初参加です 🙌 @_nogtk_ @nogtk 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
24. ゼロダウンタイムでの リリースの実現 速度と品質の両立 先ほどあったように、隔週に1回、ダウンタイムを設けてリリースするという サイクルで開発をしてきた ダウンタイムゼロリリースを目指したのはデリバリの速度を最大化するため →速度を上げるだけではなく品質も損なわない両取りを目指したい 開発サイクルをより高速にかつ安全に回すための技術的取り組みについて紹介します 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
25. ボトルネック解消② feature環境の整備と 技術的ガードレールの導入 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
26. Feature環境の提供 DBマイグレーションリハーサルの提供 複製DBを使った検証環境の提供 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
27. Feature環境の提供 の提供 環境の提供 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
28. Feature 環境の導入 当初の状態 1つの検証環境を開発チーム内で共有 開発チーム内で共有している検証環境は1つしかなかった 一定の開発規模がある、息の長いプロジェクトを検証するために、 共用の検証環境を占有する必要があった その間、通常開発の検証を行う環境がなく、都度発生するコミュニケーションコストも 高かった 設計 開発 リリース アウトカムの発生 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
29. Feature 環境の導入 Feature環境とは？ GitHub の PR 単位で、独立して立ち上がる検証環境 ニーリーでは GitHub Actions を利用し、Feature 環境構築を行うワークフローを定義 し、開発者に Feature 環境を提供 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
30. Feature 環境の導入 Pull Request 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
31. Feature 環境の導入 GitHub の PR に付与する ラベルで環境を選択 ECS タスクは AWS スポットインスタンスを 活用しコストチューニング 基本は環境共通のDB を使いつつ、 共通DBからコピーした 独立DBも利用可能に 株式会社ニーリー 大木 建人 / 高 直我 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話 DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
32. Feature 環境の導入 開発者体験の向上 検証待ち・都度発生していたコミュニケーションからの解放 自律的な開発サイクルの実現　 各開発者が自分のタイミングで検証環境を立ち上げることができる ローカルでの開発者検証中に、PR を先に出しておいて、 QA メンバーが Feature 環境を構築し探索的テストを実施 ということも可能に 2026年1月〜3月の直近3ヶ月で150件超 の Feature 環境が作成されている 開発フローにおける “インフラ” となっている 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
33. の提供 DBマイグレーションリハーサルの提供 DBの提供 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
34. マイグレーションリハーサルの導入 ゼロダウンタイムでのリリースは “条件付き” だった DBへの変更を伴う差分がある場合は一律NGとしていた 軽微なDB変更を伴うリリースはゼロダウンタイムに混ぜ込みたい 直近15回のリリースで約80%は実質影響のない、数秒で完了するリリースだった “軽微” をどう定量的に判断する？ ダウンタイムリリースをするなら、DBマイグレーションの時間見積もりもしたい メンテ時間どれくらいかかるか計算したい 本番DBを複製して、リハーサルとして DBマイグレーションを流し、計測する仕組みがほしい！ 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
35. マイグレーションリハーサルの導入 構成について 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
36. マイグレーションリハーサルの導入 技術的な補足 ロック時間の計測には pg_locks テーブルの情報を取得 0.1 秒間隔でポーリングし、ロックされたテーブル・時間を取得 pg_locks を利用しており PostgreSQL 前提の実装となっている 復元するDBのスナップショットは最新時刻を指定して、なるべくギャップが無いように RDS Aurora Postgres を使っており、Point-in-time-Recovery(PITR)※1 により、 5~10分前の本番DBデータに対するマイグレーションを実施可能 マイグレーションリハーサルによって得られた具体のロック時間をベースに、 メンテイン中にリリースするかジャッジできるようになった 個別ジャッジが必要な場合は都度ディスカッションしている ※1 PITR: 過去の任意の時点のデータベースを復元できるAuroraの継続的バックアップ機能 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
37. 環境の提供 DBの提供 複製DBを使った検証環境の提供 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
38. 本番DBを使った検証環境の提供 本番DBを用いての検証も行いたい 本番固有なデータ・不整合データに対する 仕様不備やエッジケースの考慮をリリース前に打ち取りたい 実際の本番データを使ったパフォーマンスも検証したい かつ、セキュリティ的に安全な環境を担保したい データ漏洩やメール誤送信などへの対策 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
39. 本番DBを使った検証環境の提供 構成は、前述したマイグレーションリハーサルのものとほぼ同等 リハーサルを流すか、マスキング処理を流すか 必要な処理を自動化することで、対応漏れに伴う漏洩リスクの低減 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
40. 本番DBを使った検証環境の提供 セキュリティへの考慮 マスキング + ネットワークレベルでの制御で多層防御の考え方 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
41. Feature 環境の導入 リリース前の本番データ検証が可能に 前述したFeature環境上で、本番データを使った検証ができる 機能リリースだけではなく、様々なユースケースで利用されている バージョンアップの動作確認 特定日時の断面によるデータ整合性のチェック 断面データを用いることができる 本番DB に直接クエリを投げるリスクの低減 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
42. feature環境の整備と技術的ガードレールの導入 feature環境の整備と技術的ガードレールの導入 ダウンタイムなしリリースを実現した上で、 高速なサイクルを安全に回し続けるために、 3つの技術的ガードレールを整備した ダウンタイムなしリリースを実現した上で、 高速なサイクルを安全に回し続けるために、 3つの技術的ガードレールを整備した PR単位の独立したfeature環境 DBマイグレーションのリハーサル 本番DBの安全な複製利用 株式会社ニーリー 大木 建人 / 高 直我 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話 DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
43. 3つのボトルネック ボトルネック解消① ゼロダウンタイムでの リリースの実現 ボトルネック解消② feature環境の整備と技術的ガードレールの導入 月あたりのリリース回数 開発セクションの ボトルネックは改善 第二の壁突破🎉 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
44. ボトルネック解消③ github-flowの導入と トランクベース開発の実現 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
45. github-flowの導入とトランクベース開発の実現 ボトルネックが解消し、開発速度が向上した。 →しかし、再度リリースがボトルネックに 開発速度が上がり、1日に多くのリリースが発生 stagingに変更を貯めることにより、リリースタイミングの調整などコミュニケーション コストが発生していた ゼロダウンタイムリリースが増加するにつれ、無視できないコストになってきた 設計 開発 リリース アウトカムの発生 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
46. ゼロダウンタイムでの リリースの実現 再掲 ゼロダウンタイムでの リリースの実現 STAGINGに、ローリングアップデートを行ってもシステム整合が取れる変更を貯める リリースしたい時にstagingブランチでリグレッションテストを実施 問題なければmasterにmergeしてリリース Before After FEATURE - YYYY FEATURE-B FEATURE-D FEATURE-C FEATURE - XXXX DEVELOP FEATURE-A STAGING STAGING MASTER MASTER 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
47. github-flowの導入とトランクベース開発の実現 解決方法 stagingを経由せず、直接masterにmergeできるプロセスの整備を実施 つまり、git-flow から github-flowへ移行と、 トランクベース開発への移行を決意 Before After FEATURE-B FEATURE-D FEATURE-C FEATURE-B FEATURE-D FEATURE-C FEATURE-A FEATURE-A STAGING MASTER MASTER 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
48. github-flowの導入とトランクベース開発の実現 実施したこと 開発ブランチのマージ先をstagingからmasterへ変更 今までstagingで行っていたリグレッションテストなどはfeature環境で実施できるように Before After FEATURE-B FEATURE-D FEATURE-C FEATURE-B FEATURE-D FEATURE-C FEATURE-A FEATURE-A STAGING MASTER MASTER 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
49. github-flowの導入とトランクベース開発の実現 実施したこと 今までとやってることは実質的に同じという形まで整えた しかし...! 開発者体験が大きく変わるので、SREがエイヤで変えるのは難しい 愚直に対話を実践 繰り返しステークホルダーと議論を行う 一部のチームだけトランクベースを導入し効果検証を実施 細かく変更を加えてから、徐々に全チームに導入 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
50. 3つのボトルネック ボトルネック解消① ゼロダウンタイムでの リリースの実現 ボトルネック解消② feature環境の整備と技術的ガードレールの導入 月あたりのリリース回数 ボトルネック解消③ github-flowの導入と トランクベース開発の実現 第三の壁突破🎉 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
51. まとめ 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
52. まとめ 3つのボトルネックを解消して ゼロダウンタイムリリースが思った以上に増えない
 過去のリリースを洗い出し、ボトルネックを探る 小さなマイグレーションでもダウンタイムありのリリースをしていた →マイグレーションありのゼロダウンタイムを整備する必要がある → マイグレーションリハーサル リリースしたいものは多いけど、実際日々の開発をトラッキングすると コミュニケーションコストが多く発生していた → github-flow・トランクベース開発の導入 課題に関しての解像度を上げ、必要なものを考え抜く 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
53. まとめ 3つのボトルネックを解消して 一回のアプローチではうまく行かず、 手を変え品を変え繰り返してボトルネック解消につながった箇所もある 今回発表した内容も、時間の都合上省略したけど 実際はもっと細かいステップ踏んでいる箇所がある 小さく緩やかに変化していけば、FBも軌道修正も低コスト 100点を目指さず、まず70点でもいいので作って出して運用してみる 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
54. つまるところ...
55. 今、”いいもの”を作る
56. そして 言語化し、体現することで当たり前になる
57. まとめ リリースのボトルネックは組織・プロダクトの状態によって移り変わる 丁寧に洞察し、愚直に一つ一つ小さく潰していく その中でも、複利を生かせるものは早めに仕込んでおく 今、”いいもの”を作る
58. おまけ ちなみに... 今までは1つのプロダクトについての話 現在ニーリーでは複数のプロダクトを高速で立ち上げ & 共通基盤の構築を推進中 それに伴い、本格的に募集を開始する為プラットフォームエンジニアの求人票の刷新 と、合わせて募集記事を公開しました。 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
59. おまけ 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
60. 採用関連資料 会社・サービスについて 採用や職種について メンバーの発信 株式会社ニーリー コーポレートサイト https://www.nealle.com/ 株式会社ニーリー 採用サイト https://jobs.nealle.com/ 株式会社ニーリー 公式note https://note.nealle.com/ 募集中のポジション一覧 https://herp.careers/v1/nealle エンジニア向け 会社紹介資料 https://speakerdeck.com/nealle/ nirienziniaxiang-kehui-she-shao-jie-zi-liao Park Direct サービスサイト https://www.park-direct.jp/ ニーリー Dev el op er’s Bl og https://nealle-dev.hatenablog.com/ 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話
61. Join the mission. Join the mission. Nealleでは、一緒に社会の解像度を上げていく仲間を募集しています。 Nealleでは、一緒に社会の解像度を上げていく仲間を募集しています。 © Nealle Inc. All rights reserved. 株式会社ニーリー 大木 建人 / 高 直我 ©Nealle Inc. DevOpsDays Tokyo 2026 - 3つのボトルネックを解消し、 リリースエンジニアリングを再定義した話