
この記事に登場している人
DevOpsグループ(開発チーム)
DevOpsグループ CREチーム
樽⽯ 将⼈
Masato Taruishi
イオンネクスト株式会社 技術責任者CTO
レッドハットおよびヴィーエー・リナックス・システムズ・ジャパンを経てグーグル日本法人に入社。システム基盤、『Googleマップ』のナビ機能、モバイル検索の開発・運用に従事。東日本大震災時には、安否情報を共有する『Googleパーソンファインダー』などを開発。 その後、楽天を経て2014年6月よりRettyにCTOとして参画。同社の上場の牽引後、22年1月に退職。22年3月より現職。
荒井 隆成
Ryusei Arai
イオンネクスト株式会社 IT部 DevOpsグループ 技術戦略チーム マネージャー
新卒で大手SIerへ入社し、インフラエンジニアとしてキャリアをスタート。FinTechスタートアップでSRE、クラウドプロバイダーでコンサルティングを経験した後、フリーランスへ。2023年11月より現職。
坂井 勇登
Hayato Sakai
イオンネクスト株式会社 IT部 ユーザーサポートグループ シニアマネージャー
プログラマーとしてキャリアを開始し、国内小売り企業でクラウドインフラエンジニアを経験したのち、2023年11月SREとしてイオンネクストに入社。その後、2024年8月より現職。
イオンネクスト株式会社 技術責任者CTO
レッドハットおよびヴィーエー・リナックス・システムズ・ジャパンを経てグーグル日本法人に入社。システム基盤、『Googleマップ』のナビ機能、モバイル検索の開発・運用に従事。東日本大震災時には、安否情報を共有する『Googleパーソンファインダー』などを開発。 その後、楽天を経て2014年6月よりRettyにCTOとして参画。同社の上場の牽引後、22年1月に退職。22年3月より現職。
坂井 勇登
Hayato Sakai
イオンネクスト株式会社 IT部 ユーザーサポートグループ シニアマネージャー
プログラマーとしてキャリアを開始し、国内小売り企業でクラウドインフラエンジニアを経験したのち、2023年11月SREとしてイオンネクストに入社。その後、2024年8月より現職。
この記事を読むとわかること
・エンジニアと業務部門が共同で議論し、システムと業務フローの理解を深化
・ホワイトボードを活用し、システム未実装の業務プロセスを発見
・Design Docsを作成し、デマンドチェーン開発の指針を明文化
・リモートワークの壁を超え、対面議論でチームの結束力を強化
普段のオフィス環境や日常の業務から離れ、集中的にプロダクト開発や課題解決に取り組むのに最適なのが「開発合宿」です。
また、リモートワークで働く機会の多いエンジニアですが、開発合宿を通してリアルに顔を合わせることで、メンバー同士の信頼関係を深め、チームの結束力を高める場としても活用できるのが開発合宿のメリットだと言えるでしょう。
イオンネクストでも、2024年12月に湯河原の老舗温泉旅館「おんやど恵」で1泊2日の開発合宿を実施。
エンジニアと業務部門のシニア人材が一堂に介し、「デマンドチェーンプラットフォーム」の根本的な仕組みの理解や一連の流れを確認することで、「自らの言葉で言語化できる状態」をゴールに据えました。
開発合宿を実施して得た気づきや発見、生まれたアウトプットについて、合宿に参加したCTOの樽⽯、SREマネージャーの荒井、 CREマネージャーの坂井に話を聞きました。
【目次】
集中的に課題と向き合い、チームの信頼関係を築く場を作りたかった
── はじめに、湯河原の温泉旅館で開発合宿を企画した背景を教えてください。
樽石イオンネクストのIT部門では基本的にリモートワークを中心に業務を進めています。その一方で、特定の領域で深い理解が必要な場合や、多くのメンバーと議論を重ねて正解を導き出す際には、オンラインだとなかなかうまくやりづらいと感じていました。
やはり内容の理解が浅いと、どうしても「課題はこうなっているんです」と細かく伝えることができません。
「複数の人が同じ認識で話せる状態になっていない」
こうした課題を解消するためにみんなが集まって、集中的に課題と向き合い、議論する。そして、しっかりと感度の高いものにしていく試みが必要だと考え始めたのが開発合宿のきっかけになりました。
また、せっかくメンバーが対面で顔を合わせる機会なため、仕事以外の雑談などを交えて相互理解を深め、「チームの信頼関係を築く場も作りたい」と思っていたのも開催した理由になります。
── 開発合宿のようなオフサイトミーティングは以前から開催していましたか?
樽石2024年の夏にオフサイトミーティングを日帰りで実施しました。その時は外部の副業メンバーも集まって、普段の業務ではできない細かいところに集中的に取り組む目的で企画したのです。
この日帰りオフサイトミーティングをアップグレードさせたのが今回の開発合宿となっており、参加者は社員限定にしました。どうしても日帰りだと時間が若干足りないというか。参加者同士の議論が深まり、ちょうど流れに乗ってきたタイミングで時間切れになってしまうんですよね。
それが泊まりの合宿であれば、日帰りに比べて時間的制約にとらわれずに同じコンテキストの中で議論することができるわけです。
今回はイオンネクストのデマンドチェーンを解明していく過程で、ホワイトボードにたくさん書いていきました。普段はなかなかやらないような、かなり細かいところまで探っていくと、「実はこうなっていました」という発見につながったり、自分の知らなかったルートを知ることができたりと、たくさんの気づきを得ることができました。
── 準備はどのように進めていきましたか?
樽石当初は「開発合宿をやりたいよね」という話をしていましたが、日々の仕事に追われてしまい、なかなか具体化しなかったので、まずは先に日付を決めることにしました。そこから組織のいろんな事業課題や技術課題を集めながら、たくさんの人が集まって議論するのにちょうど良いテーマを洗い出していったのです。
ある程度の大枠を決め、そのあとは「こういう人がいないと議論が成り立たない」というのを前提に開発合宿の参加者を決めていきました。
当日の細かいスケジュールは、団体旅行の幹事役を担うのが好きなメンバーがいたので、その人にお願いして“旅のしおり”を作成してもらいましたね。
デマンドチェーンの現状を理解していないと「正しいものは作れない」
── 今回の合宿では「デマンドチェーン全体の仕組みを正しく理解し、自立して開発できる状態を目指す」ことをゴールに掲げていました。
樽石デマンドチェーンのコンポーネントを開発する上では「現状がどうなっているのか」を把握していないと、正しいものは作れません。そのため、第1回目の開発合宿では「デマンドチェーンを理解する」ことに振り切ったテーマを設定したのです。
合宿の具体的な内容としてはシステムの設計や仕組み、現状のワークフローなどを最初から最後まで全部の流れを細かく見ていき、議論をしていきながらホワイトボードに書き出していく作業を行いました。
例えば、商品を提供する供給者(サプライヤー)との契約書は基本契約書と個別契約書の2つがあって、毎日何十万という数の発注業務に基づくのが個別契約書になっています。
このような業務上のワークフローを業務部門の部長が説明したあとに、今度はシステムの設計をIT部門のエンジニアが話すという流れで進めていきました。
荒井普段はSREマネージャーとしてシステム全体を俯瞰していますが、業務部門の実際の動きについては今回の合宿で初めて知ることも多く、今回の合宿に参加したことで自分の中での視野が広がりました。
今まではインシデントが発生した時でも、自分の管轄外の部分に関しては理解が浅いと感じる場面もあったんです。
今回の合宿を通じて業務部門の理解が深まったので、今後はさらに業務部門と連携していく姿勢が大事だと考えるきっかけになりました。
坂井私はインシデントが起きた時に、一番初めに対応するCREチームを見ているため、開発合宿で業務理解が深まったからこそ、「ここでインシデントが生じると商品部はこんなに困るんだ」というところが結構クリアになりました。
商品部側の焦りや緊急性も以前より把握しやすくなり、「いつまでに復旧させるべきか」という話もしやすくなったと感じています。
データの流れを順番に確認しつつ、伝わりやすい言葉で説明するのを意識した
── 合宿中はどのようにしてデマンドチェーンの理解を深めましたか?
樽石今回の合宿ではデマンドチェーン全体の中でも、商品を発注して入荷する部分に特化して議論を進めていきました。
サプライヤー向けに提供している商品情報管理などの様々なシステムのユースケースにはどのようなものがあるのか。基本契約書が結ばれた後にサプライヤーは具体的に何をするのかなど、「データがどういう風に流れてシステムの処理がされていくのか」を順を追って細かく確認していったのです。
たとえ自分が理解している部分であっても、データが流れていく順番に応じて言葉にしていくことをやると、抜け漏れていたことの再確認になりますし、他部門の人でも理解しやすい表現の仕方を考えることにつながります。
要は知っていることを前提とせず、誰が聞いてもわかるように噛み砕いて説明することが肝になるわけですね。これが時間があまりないと、ハイコンテキストな言葉を使いがちで、わかっている人にしか伝わらなくなってしまいます。
一方で、泊まりの合宿のように長い時間を取れる際は、省略せず丁寧に伝えられるので、学ぶ人も理解しやすく、話す人も自分の言葉でわかりやすく説明しようと留意するようになります。
「話す人」と「学ぶ人」の両方にとっても、あらためてデマンドチェーン全体の中での役割や求められていることを振り返る機会になりましたね。
また、時間をかけて見ていくと、アーキテクチャだけ見ていたらわからない「実は間に人がいて処理していた」というのが見えてきたのも面白かったところです。
たとえば「CSVをダウンロードして別のシステムにアップロードする」といったインテグレーション機能が実装されていない部分で人が介在していることが浮かび上がり、システムの不完全さをあらためて認識できました。
これを機に改善の議論に発展させられるのは大きな収穫でしたね。
── チーム内で共通理解を深めるために行った創意工夫があれば教えてください。
樽石大きな枠組みとしては発注から入荷、出荷までの流れを順を追ってシステムのコンポーネントにクローズアップし、数時間かけて丁寧にウォークスルーをやっていきました。
開発合宿には現地参加が7名、リモート参加が2名と約10名ほどの少人数で開催したことで、一つのテーマに対して深く議論することができましたし、矛盾した話も含めて「みんなが意見を言いやすい環境を作ること」を意識していましたね。
何か疑問があれば「これはどういう意味ですか?」と常に質問を投げかけ、その答えがはっきりしない場合でも、仮説を立てながら一旦は進めていき、仮説を検証していく過程で必要に応じて修正していくことを心がけていました。
開発合宿の途中でオンコールが発生......。「エンジニアの苦労を知ってもらえた」
── 2日間の開発合宿の中で苦労した場面はありましたか?
樽石特に最初の段階では、議論している内容とは異なる話題に逸れてしまい、本題に戻していくのが結構大変でしたね。結局、本来話すべき内容よりも飛躍した質問が出てきてしまうと、議論の前提が崩れてしまい、流れを追えなくなることがあります。
なので、そういう場合は一度質問をストップし、元の話に戻って整理するようにしていました。その上で、後からあらためて飛躍した部分の質問に戻り、順を追って理解を深めるようにしました。
荒井合宿全体を通して発注周りの業務の話が多く、あまりドメイン知識がなかった自分にとってはインプットに充てる時間が大半でした。エンジニアという立場で、システム面の議論をするというよりも、業務の流れや使用しているシステムの全体像を理解する内容だったため、本当についていくのに必死でしたね。
正直なかなか積極的にディスカッションに入っていけなかったのが反省点です。
坂井私も荒井と同様に小売・流通における事前知識がなかったので、まさに“インプットの雨”という感じで、自分なりにアウトプットするのが難しかったと思っています。
大勢でやる勉強会だと、一方的にスライドを投影して説明する形式になりがちですが、今回はその場でホワイトボードを使い、内容を整理しながら完成させていくことが合宿の目的だったと理解しています。
異なるバックグラウンドを持つメンバーが集まったからこそ、このような進め方が効果的だったと感じました。
── 合宿の感想や印象に残っているエピソードは何かありますか?
樽石実際に合宿を行った場所は、会場の1番奥の部屋だったこともあり、いい意味で“閉じ込められる感じ”の環境ですごく集中できました。部屋も広くて、昭和のおもちゃみたいのが置いてあったりと、居心地もかなり良かったです。
荒井温泉宿としても快適でしたし、会議室やプロジェクターの完備もあって、開発合宿を行う環境が整っていたのは嬉しかったですね。
ちょっとしたエピソードで言うと、みんなの疲労感が溜まってきた合宿の最後の方に、1回オンコールが発生したのですが、障害対応している姿を業務部門の人が見てくれたので、「IT部門も大変なことをやっている」ということに気づいてもらえたのはよかったです。
開発合宿のアウトプットをもとに、システム開発の指針を明文化した「Design Docs」を作成
── 開発合宿を終えて、どのようなアウトプットが生まれましたか?
樽石ホワイトボードに書いたものをベースに、デマンドチェーンコンポーネントの最上位にあたるDesign Docsを作成しました。
例えば、「デマンドチェーンの本質や目的は何か」というのを数式で表現するとか、数理モデルはこのようにするなど、非常に抽象度の高い状態までアウトプットの質を高めることができました。
まだ全部は完成していないので、これからも随時追記していきながらチーム内で共通認識を持って課題解決に取り組める粒度のDesign Docsを目指していければと考えています。
あとは、今後新しいエンジニアが入ってくることを考えると、自分のチームでコンポーネントを作る時に、全体の方向性や課題感を把握するための指針となるドキュメントが必要になるでしょう。
そういう意味でも、開発合宿では商品を発注している業務部門の担当者も交えながらコミュニケーションを重ねてDesign Docsを作れたのは、とても良い成果だったと実感しています。
── 初めての泊まり合宿をやってみての課題や改善点、次回の開催予定があれば教えてください。
樽石特にオフラインで参加している人たちは一体感を持ちやすかった一方で、オンラインの参加者には議論したい内容の意図が伝わりにくいと感じる部分がありました。
そのため、いかにオンライン参加の比率を下げて開発合宿を行うかが大事だと今回やってみて思いましたね。
それでも今回の開発合宿では、非常に密度の濃い議論ができて良いアウトプットにつながったので、これからも継続して開催していく予定です。
今ひとつ考えているのは、八王子と埼玉の郊外にイオンの大型移動倉庫を作っていて、その見学も兼ねて両エリアの周辺で開発合宿を行うことですね。
── 最後に今後の展望についてお聞かせください。
樽石2024年度はイオンネクストにとって「まず基本はしっかりやろう」と取り組んだ時期でした。「システムが安定していて落ちない」「サクサク動く」などITサービスとして当たり前にできる状態を目指して取り組んできました。
そして2025年度は、もっと革新的なことをやっていきたいと考えていまして、そのためにはエンジニアリングがものすごく大事になってくるわけですね。そのためにも、チーム内のコミュニケーションの量をもっと増やし、メンバーの相乗効果でいろんなイノベーションを起こしていければと思います。
その1つの手段が開発合宿であり、他の取り組みとうまく組み合わせながら、新しい価値を創造していきたいですね。
イオンネクストではエンジニアを中心としたデジタル人材の採用を積極的に行っています。樽石と話をしてみたい、Green Beansの事業が気になる…といった方は、カジュアル面談も実施しておりますので、ぜひお気軽にご連絡ください。
【関連記事】
イオンネクストの取り組みについてもっと知りたい方へ、こちらの記事もおすすめです。
内製×副業のハイブリッド組織を支えるIDPの実践例 “ドキュメント管理と自動化”

1年半で100本。イオンネクストが実現したPostmortem文化の作り方

最先端のプラットフォームを創り次世代オンラインスーパーマーケットをつくる、イオンネクストの現在地と未来

Design Docsをもとに生成AIでサンプルコードをつくり新機能「線香花火クーポン」実装 |イオンの開発生産性

※掲載している所属・役職・肩書きおよび各種情報は、記事公開時点のものです。

インタビュー
2026/7/28
AI活用が進化する未来に、エンジニアは“なぜ作るのか”を問う ──イオン株式会社執行役デジタル担当・太田卓也氏が描く、小売の変化とデジタル戦略

入社・在籍エントリ
2026/7/23
【入社エントリ】東大・リクルートを経てイオンに入社した理由は 10兆円規模のデータ基盤を設計から変えられるから

イベントレポート
2026/7/21
このデータの山を、全員の宝にしたい──ASTがNew Relic MCPで挑んだオブザーバビリティ民主化

インタビュー
2026/7/16
24時間稼働の店舗を止めずにMDシステムを刷新せよ。イオン東北システム統合、若手エンジニアの成長とチームの挑戦
イベント情報
人気の記事

イベントレポート
2026/2/5
データ基盤に銀の弾丸はない──ASTが“Google 検索×自社データ”で現場の200時間を取り戻すまで

インタビュー
2026/2/24
「現場のスピード」と「コストの壁」をどう突破するか──イオンの店舗向け業務システムSmartHHTが選んだ、データ基盤"いいとこ取り"の再構築とは?

インタビュー
2026/2/10
価格の最適化で小売の収益構造を変える──イオンが挑む「スマートプライシング」とは

インタビュー
2025/10/7
イオンの従業員向けAIプロダクト「Query Vision(クエリビジョン)」──開発ストーリーと社会実装のリアル

インタビュー
2026/4/23
