【開発生産性カンファレンス 2025】事業成長を加速するエンジニアリング組織の構築：受託型から価値提案型への挑戦と失敗の軌跡

Oisixというサービスについて

菊池：オイシックス・ラ・大地は2000年に創業した企業で、「これからの食卓、これからの畑」を経営理念に掲げ、食に関するビジネスを展開しています。

私たちの事業を一言で表すと、食のサブスクリプションサービスを提供する会社です。生産者から調達した食材を自社の物流センターで加工し、一般家庭や保育園・施設などに提供する仕組みを構築しています。

事業は大きくBtoC事業とBtoB事業に分かれます。BtoC事業では「Oisix」「大地を守る会」「らでぃっしゅぼーや」という宅配型サービスを展開し、BtoB事業では保育園や病院などの施設向け食材卸しや給食・社員食堂の受託事業を手がけています。

売上規模は、BtoC事業が約1,000億円、BtoB事業もおおむね同等程度となっています。

個人向け宅配ECとして3つのブランドを展開していますが、私のチームが主に担当するのがOisixです。Oisixは子育てと仕事の両立に忙しい共働き世帯をメインターゲットとし、「時短だけど誇らしい食事」、つまり私たちが「プレミアム時短」と呼ぶ価値を提供することをコンセプトとしています。

IT部門の「生産性」の定義の変化

Oisixの会員数推移を通じて、IT部門に求められる役割がどのように変化してきたかを説明します。このグラフは2013年の東証マザーズ上場時からの公表数値をまとめたものです。2013年に数万人程度だった会員数が2023年3月にピークの40万人を超えましたが、現在は35万人程度となっています。



この推移と社会情勢の変化を重ね合わせながら、IT部門への要求の変遷を3つの時期に分けて解説します。

第1期：2013年〜2020年頃（共働き世帯増加期）

この時期の社会背景として、共働き世帯が増加していました。Oisixでは時短ニーズに対応するため「Kit Oisix」というミールキットサービスをリリースし、これが市場に刺さって非常に好調でした。会員数は2019年に20万人を超えるまで成長しました。

ミールキットが売れていたため、ビジネス部門はこの商品を効果的に訴求するためのPDCAサイクルに専念していました。「このアプローチを継続すれば売上は確実に伸びる」という確信がある時代でした。

IT部門に求められた役割は、このビジネスPDCAを支えるシステム機能改修を遅滞なく実行することでした。品質、コスト、納期（QCD）を高水準で維持することが生産的な活動と評価されていました。

第2期：2020年〜2023年頃（コロナ禍）

コロナ禍による巣ごもり需要で受注が急激に増加した時期です。しかし供給能力の制約により、受注制限をかけて定期会員のみにサービスを限定せざるを得ない状況となりました。

この時期、「サービスを止めない」ことが最優先課題となり、IT部門にはサービス稼働率の維持がミッションとして課されました。データベースのチューニングやクラウドサービスへの移行など、安定性向上に集中した時代です。インフラの安定化に取り組んでいれば、ビジネス上の成果は自然についてくる状況でした。

第3期：2023年以降（アフターコロナ反動減）

コロナ後の反動減により会員数は35万人程度まで減少し、これまでの「売れるから機能を追加する」というアプローチから「何が効果的か分からない」状況に変化しました。

この変化により、新しい価値の探求が必要になりました。生成AIなど先端IT技術が事業上重要な要素となり、これらの技術をいかに事業に活用するかが問われています。技術を効果的に事業に活かせることが、高い生産性として評価される状況です。



これまでの変遷をまとめると、従来は市場の追い風もあって事業成長しやすいビジネス環境でした。IT部門は仕組みづくりに専念し、その仕組みを事業部門が活用して売上を伸ばすという明確な役割分担がありました。

IT部門はシステムを素早く構築し、拡張性を担保することが生産的な活動と見なされていました。これは期待付加価値の生産性、いわゆるレベル2の生産性に該当します。

しかしコロナ後の現在では、機能を強化してもお客様の反応が得られにくく、投資リターンの見通しが困難な環境となりました。そのため、コストダウンや仕組みづくりだけでなく、売上やビジネス成長に直接貢献する活動をIT部門も共同で実行することが求められています。

現在重視されるのは、特定の活動がどれだけのリターンを生み出すかという実績です。つまり、実現付加価値の生産性、レベル3の生産性が求められているのが現状です。

私たちの活動と発生した問題

このような背景を踏まえ、私たちがどのような組織変革に取り組んできたか、そして様々な失敗から学んだ教訓についてご紹介します。

ビジネスに貢献することを求められても、具体的に何から始めればよいかが分からない。これは多くの技術者が直面する課題です。私たちも全く同じ状態からスタートしました。

システムのデータは確認できるものの、そのデータがビジネス上どのような意味を持つのかを理解するには、売上創出のプロセスに深く関与する必要がありました。実際に取り組もうとすると、施策の効果をどう測定するか、セグメントをどう切り分けるか、流入経路ごとに変わる顧客獲得コスト（CAC）をどう評価するかなど、様々な課題が浮上しました。

そこで私たちが最初に選択したアプローチは、シンプルに事業部との対話から始めることでした。対話を通じて理解を深めることで、具体的なアイデアにつなげていけるという考えからです。



組織変革の第一歩として、まず動きやすい環境を整備することから始めました。

Oisixの事業部は大きく3つのチームに分かれています。定期会員向けサービスを担当する「売り場」チーム、新規顧客獲得を担当する「獲得」チーム、そして顧客体験向上を担当する「CX」チームです。

従来は、これら3つのチームからエンジニア組織に機能開発の要望が寄せられ、空いているプロジェクトマネージャーやエンジニアをアサインして開発を進めるという体制でした。

これを昨年、各事業チームに専任の担当者を配置する方式に変更しました。売り場からの要望はAさんが、獲得系の要望はBさんが対応するという形で、完全に担当制に分けました。プロジェクトマネージャーがこの担当者を務め、事業部のミーティングにも参加して、売上や利益創出につながる施策について一緒にディスカッションする体制を構築しました。

組織図上では整理された体制に見えますが、実際には事業チームの業務の中でどのような動きをとっていくかのような戦術面を詳細に決めきれていなかったこともあり、「走りながら考える」という姿勢で頑張ってもらいました。

行動していく中で様々な課題に直面しています。最も大きな課題は、エンジニア側が事業部の議論に参加できないことでした。例えば、何らかの実験結果について議論する際、事業部メンバーは様々なアイデアを出しますが、エンジニアリング組織から参加しているメンバーは、どのような観点で分析すべきか、どう評価すべきかが分からず、議論に貢献できませんでした。

この課題を克服するため、私たちは保有するスキルを最大限活用して、まず役に立つことから始めました。



具体的には、エンジニアのプロジェクトマネージャーがデータ分析やデータ抽出を積極的に引き受けました。自分事として事業目線でデータを見ることで、これまで理解できなかったデータの見方や評価方法が徐々に分かるようになりました。

このプロセスでドメイン知識が蓄積され、「こういったやり方はどうでしょうか」という提案ができるようになると、事業部からは「それは良いアイデアですね」という反応が得られます。そこから新しい分析依頼を受け、さらなるドメイン知識を獲得するという好循環が生まれました。



手応えを感じたため、今年に入ってからさらなる組織変更を実施しました。

従来の職能別チーム編成から、売り場、獲得、CXというビジネスドメイン別のチーム編成に完全移行しました。窓口を務めていたプロジェクトマネージャーをPdM（プロダクトマネージャー）として再定義し、各チームが担当領域のすべてを責任を持って実行する体制を構築しました。

特に重要な変更として、利益や解約率といったビジネス指標を、開発チームでもKPIとして持つことにしました。これにより事業部チームとの真の意味での協働体制を目指しました。

しかし、組織構造を変えるだけでは根本的な解決にはならず、新たな課題が次々と発生しました。

最初に直面したのは、PdMの業務範囲が広すぎることでした。プロダクトマネジメントトライアングルで説明すると、当初はプロダクトを中心とした開発計画、価値訴求、デリバリーをPdMが担当することを想定していました。しかし、もともとプロジェクトマネージャーだった人員がいきなりビジネス領域のすべてを担いながら開発も見るのは現実的ではありませんでした。

そこでPdMの役割をビジネス側に寄せて調整しましたが、今度は開発計画の責任者が不明確になり、コミュニケーションが円滑に進まない問題が発生しました。最終的に、PdMとプロジェクトマネージャーの役割を明確に分離し、RACIチャートで各役割の責務を詳細に定義することで解決を図りました。



次に、ビジネスドメイン別に組織を分割したことで、技術的に共有すべき情報の連携が困難になりました。例えば、獲得チームが新しい決済手段を追加した場合、売り場チームの定期会員向け決済システムも同様の対応が必要ですが、縦割り組織のためそれぞれが独立して検討するという非効率が発生しました。

この問題に対しては、横断的な定例会を設置し、Slackでの情報共有チャンネルを統一することで、他チームの動向をキャッチアップできる仕組みを整備しました。



さらに、ビジネス価値の追求に重点を置いた新組織では、技術的負債の解消や大規模なバージョンアップが後回しになってしまう課題にも直面しました。

この課題への対応として、技術的負債解消の事業価値を可視化することに取り組みました。例えば「負債解消によりページスピードが向上し売上アップにつながる」「システム改善によりコストダウンし利益に貢献する」といった具合です。

また、技術的負債解消チームとプロダクトチームの人材交流を促進し、情報の偏在を防ぐとともに、経営層・現場の双方に対して「負債解消とビジネス価値追求の両方を実行する」というメッセージを継続的に発信しました。

これらの課題に対する対応策をまとめると以下のようになります。



PdMのリソース不足については、役割定義の明確化と外部コンサルタントによる指導を通じてPdMのケイパビリティ向上を図りました。チーム間連携の問題については、横断的な定例会による共通理解の醸成で対処しました。技術的負債解消の停滞については、事業価値との関連付けと人材交流、そして「両方やる」というメッセージの継続発信で解決を試みました。

問題を乗り越えた今、どのようになっているか

まず率直にお伝えしますと、このタイトルには語弊があります。問題は完全に乗り越えられてはいません。しかし、エンジニアからの提案が増加し、うまく進展しそうな兆しが見えてきているのが現状です。

現在、エンジニアからの提案と実行が活発になっており、ようやくスタートラインに立てたという手応えを感じています。具体的な成功事例を通じて、この変化を説明します。

最初の事例は、カート放棄（かご落ち）の問題です。お客様がカートに商品を入れたままサイトを離れてしまい、機会損失につながるケースが多く発生していました。

この課題に対して、エンジニアから能動的な解決策の提案がありました。具体的には、かご落ち対策のソリューションツールを導入し、「商品をお忘れではありませんか」といったリマインドメールを配信する仕組みを構築しました。また、そもそもかご落ちを発生させないためのコミュニケーション改善も併せて実施しています。

これらの施策により、従来は離脱して終わっていたお客様に再度アプローチし、購入完了につなげることができるようになりました。

二つ目の事例は、注文し忘れの解決です。サブスクリプションサービスという性質上、お客様の週間受注金額は比較的安定して推移することが多いのですが、特定の週だけ急激に落ち込み（逆スパイク）、その後元の水準に戻るという現象が発生していました。

エンジニアがデータパターンを調査している中でわかったことで、「お客様がうっかり注文を忘れて締切時間を過ぎてしまった」という仮説を立てました。注文締切時間付近でのアクセスログを確認すると、実際にアクセスが少ない傾向が確認できました。

この仮説に基づき、コホートデータをさらに深掘りして顧客行動を分析し、お客様とのコミュニケーション手法を見直しました。こちらはまだ検証中で、具体的な成果に至っていないですが、こういった事業インパクトのある提案が増えてきています。



組織変革は継続的なプロセスであり、今後も様々な課題が発生することは間違いありません。課題に対して、引き続き対処を続けていく必要があります。

まとめ

外部環境の変化により、IT部門はレベル3の生産性、すなわち実現付加価値の生産性での評価が求められるようになりました。この要求に対応するため組織変革に着手しましたが、当初は問題が山積していました。

問題解消のために実施した主要な取り組みは3点です。ミッションと役割をRACIチャートなどで明確に定義すること、コミュニケーションパスを整備すること、人材シャッフルと継続的なメッセージ発信を行うことです。

本日の資料をまとめる中で改めて実感したのは、結局のところ、人の頑張りが最も大きな要素だったということです。組織構造や制度も重要ですが、最終的には現場のPdMやエンジニアの努力が成果につながりました。

この場を借りて、頑張ってくださったチームメンバーの皆さんに感謝を申し上げます。引き続き課題は残っていますが、今後もよろしくお願いします。

アーカイブ動画も公開しております。こちらも併せてご覧ください。
※ご視聴には登録が必要です