こんにちは。 スナックミーで採用を担当している伊藤です。
スナックミーでは今期から「サービス・フルサイクルエンジニアリング」というコンセプトを打ち出しました。 これは、簡単にいえば「エンジニアがよりサービス全体に関与していく体制」なのですが、この背景にはプロダクト開発におけるサイロ化の課題解決と、「おやつ」というリアルな商品を扱うスナックミーならではの考え方があります。
今回の記事では、この「サービス・フルサイクルエンジニアリング」について解説、リアルな商品を扱うスナックミーならではの取り組みについて紹介します。
Netflixが提唱したフルサイクルエンジニアリングとは？
「サービス・フルサイクルエンジニアリング」の基になっているのは、Netflixが提唱した「フルサイクルエンジニアリング(Full Cycle Developers)」という考え方です。
フルサイクルエンジニアリングについて簡単に解説すると、従来のように部門ごとにスペシャリストを配置して局所最適を図るのではなく、プロダクト開発のライフサイクル全体の作業をエンジニアメンバーそれぞれが一貫して行い全体最適を図るというものです。
スペシャリスト配置型体制の問題
設計、開発、テスト、運用等を独立させた体制では、デバッグやシステムの問題解決のために部門をまたいだコミュニケーションが必要となり膨大な時間と労力がかかっていました。 また、プロダクトの運用を考慮しきれずに、リリース後に多くの問題が発生するともしばしばあり、それを解決するのにまた膨大な時間がかかるなど、いわゆるサイロ化問題に苦しんでいました。
＜問題の一例＞ ・課題に関するフィードバックが適切に担当者に届けられない ・他の部門、社外メンバーからの質問に回答できるメンバーが限られていて、回答にたどり着くまでに時間がかかる ・運用チームがシステム変更についての理解がないため、運用における問題検出と解決に時間がかかる ・コードが完成してからデプロイされるまでに数週間もの時間がかかる
フルサイクルエンジニアリングによる解決
こういったサイロ化の解決のためにNetflixが採用したのがフルサイクルエンジニアリングという体制です。 プロダクト開発のライフサイクル全体(=フルサイクル)にまたがって開発を担当することで、部門間のコミュニケーションコストや運用における考慮漏れという課題を解決しました。
フルサイクルエンジニアリングによって、開発チーム内でフィードバックループが完結し、どのメンバーも技術的な質問に回答でき、運用の課題に関してはメンバーが直接システムを改善し、デプロイまでの時間も劇的に短縮されます。
一方で、プロダクトのフルサイクルを理解し責任を負うことには大きな負荷がかかります。 各メンバーには幅広い技術知見が必要とされ、プロダクト全体を把握するには常にアンテナを張っておく必要があります。 これらの課題に対して、Netflixは開発者の生産性を高めるツールを生み出すことや、各部門の責任をローテーションで管理するいった体制によって解決しています。
「おやつ」という商品には、フルサイクルでは足りない
スナックミーでもNetflixのように、サイロ化を防ぐためにエンジニアメンバーが特定の部門に閉じずにサービス全体に責任を負う「サービス・フルサイクルエンジニアリング」という体制をとっています。Netflixの「フルサイクルエンジニアリング」と異なるのは、"サービス"という言葉が加えられていることです。
なぜ"サービス"という言葉が加えられているかというと、スナックミーのサービスはWebシステムだけでは完結しないからです。
スナックミーが展開しているのは、パーソナライズされたおやつのサブスクリプションサービス「snaq.me（スナックミー）」や実店舗等でのオフラインサービスです。
いずれも「おやつ」というリアルな商品をユーザーに届けることがサービス提供のゴールです。 また、「おやつ」の製造という工場と連携した生産管理等のリアルなオペレーションもサービスサイクルの中に含まれています。
Webシステムに限定されたサイクルの最適化では、サービスの一部分にしか影響を与えることはできないため、リアルなサイクルの最適化を含めて「サービス・フルサイクルエンジニアリング」というコンセプトを打ち出しています。
サービス・フルサイクルエンジニアリングの具体的な取り組み
スナックミーのサービスサイクルを簡単に紹介すると下記の図のようになります。
原材料の管理から、製造、ピッキング、出荷、そしてユーザーフィードバックを活用した商品開発のための分析まで、リアルなサイクルはWeb開発以上に多く存在しています。いずれもサービスにとっては重要な工程で、どれを欠いてもサービス成長は達成できません。
サービス・フルサイクルエンジニアリングには、部門を横断して全体最適を達成する、ということに加えて、「リアルなオペレーションの課題をエンジニアリングで解決する」という目的もあります。
＜事例：商品ピッキングの音声システムによる改善＞
スナックミーは自社で倉庫を保有しており、商品のピッキング(ピックアップして梱包する作業)も倉庫内で内製しています。 ピッキングは地道な作業です。Amazonのような巨大倉庫では機械による自動化が進んでいますが、スナックミーの規模では設備投資と事業規模のバランスを考慮して、まだ手動部分が多く残っています。 完全自動化とまではいかずとも、このピッキングを効率化するためにエンジニアリングで改善できることはないか、と考えた結果生まれたのが音声ピッキングシステムです。
従来、商品名、個数、配置場所をメモした用紙を出力し、それを見ながら目視でピッキングするというアナログな作業を行っていました。しかし、その運用ではわずかながらミスが発生し、効率もいいとはいえない状態でした。
音声ピッキングシステムは、「基となるバーコードを読み込むことで、選ぶ商品、場所を指示する音声を流す」というものです。音声ピッキングシステムの導入は、ピッキングの生産性に劇的な変化をもたらしました。出荷効率はおよそ10倍に向上し、商品発送の日数を短縮し、ユーザーへの提供価値を高めました。
※詳細はこちらの記事で紹介しています。
このように、「サービス・フルサイクルエンジニアリング」ではWeb画面に閉じず、リアルなオペレーションをエンジニアリングで改善していくことで、ユーザーの体験、提供価値を高めていくことを目指しています。
課題を見つけ出すための文化づくり
上記のようなリアルなオペレーション上の課題を見つけ出すためには、エンジニアがプロダクトマネージャーの視点を持つこと、他部門とのコミュニケーションを活発にする仕組みが重要です。 スナックミーでも、開発チームがRICEフレームワークを使って優先順位付けをしたり、ユーザーからのフィードバックを毎週確認する共有会を開催したりしています。
しかし仕組みだけでは、すべての課題を見つけることはできません。 スナックミーでは、より多くの課題をエンジニアが見つけられるように、エンジニアと他の部門がそれぞれ歩み寄り、状況を共有する文化を作っています。
エンジニア自らが工場や倉庫に出向いて立ち話をしたり、エンジニアによってオペレーションが改善した事例を社内に広く共有することでエンジニアへ相談しやすい土壌を作ったり、スナックミーの開発チームではそういった愚直な施策を通して、他の部門とのメンバーの距離が近づけて、より多くの課題をテクノロジーで解決しようとしています。
エンジニアが自ら倉庫に出向いてオペレーションメンバーと会話をしています
おわりに
ここまでサービス・フルサイクルエンジニアリングやスナックミーの事例について紹介しましたが、スナックミー社内でも考え方・手法にはまだまだ改善の余地が残っています。 Netflixの記事の中でも書かれていましたが、こういった考え方・手法はそのまま転用しても成功せず、自社の状況に合わせてカスタマイズしていくことが必要です。
スナックミーのサービス・フルサイクルエンジニアリングはまだ未熟ではありますが、それでも自分の領域に閉じずにサービス全体を自身で作り上げていくという開発手法は、面白みもやりがいも大きいものだと考えています。
- サービス全体に携わりたい
- 一つの領域に閉じずに関わる領域を広げていきたい
- 他の部門とコラボレーションしながら開発していきたい
- 何を開発するかを自ら決めていきたい
こういった志向性をお持ちのエンジニアの方には特に楽しんでいける環境があると感じています。 スナックミーはエンジニア採用に注力しています。 もし少しでも興味を持っていただけたら、ぜひカジュアルにお話させてください。
※YOUTRUSTでカジュアル面談を公開しています。お気軽に話を聞きにきてください。
