レシピサービス開発部の新井（@SpicyCoffee66）です。いろんなゲームが好きなのでどれも中途半端にしか上手くならないことに 10 年以上悩んでいます。

この記事では、クックパッドのレシピサービス開発に導入している "オーナーエンジニア"と呼ばれる制度について紹介します。

• クックパッドでサービス開発をしているエンジニアがどういう働き方をしているのか知りたい
• ディレクターやデザイナーと上手く協業する方法が知りたい
• サービス開発エンジニアはやることが多すぎてどうやって仕事をすればいいか悩んでいる

といったような方の参考になると思いますので、興味があれば是非ご一読ください。

制度導入の背景

オーナーエンジニアという役割について述べる前に、まずはレシピサービスの開発を取り巻く環境について軽く解説します。
現在クックパッドのレシピサービスは、エンジニアが 10 名と少し、デザイナーが 5 名程度、ディレクター数名の、計 20 名少しのメンバーで機能開発をしています。 開発手法にはスクラムを活用していますが、組織に合うようなチューニングを進めた結果、現在は企画や施策立案を中心に取り組む Discovery Process と、その実装とリリースに取り組む Delivery Process に分かれて運用しています。 前者はプロダクトバックログ（以下 PBL）にアイテムを追加していく役割*1を、後者はそのアイテムをスプリントバックログ（いわゆるカンバン）に落とし込んで実現していく役割を担っています*2。

スクラムの導入自体は、開発組織の持つ課題を解決するために昨年導入されました。それにより、当時抱えていた課題は概ね解消されたと言えますが、新たに以下のような問題が発生するようになりました。

• PBL のアイテムを数時間程度のタスクに分解しようとしたときに、要件や仕様に生煮えの部分が多く分解することができなかった
• ディレクターやデザイナーがエンジニアにラフな相談をしたいときのやり方がわからなくなった
  • スクラム導入以前は施策ごとに担当エンジニアがつくようなやり方で開発を進めていたチームが多く、良くも悪くも個々人のコミュニケーションが多かった
• 企画側から開発の様子が見えづらく、進捗の遅れや意図のズレに気がつくのが遅れてしまった

改めて並べてみると、開発体制の変化によってディレクター・デザイナーとエンジニア間のコミュニケーションに課題が生まれ始めていたことがわかります。この課題を解決するために生まれたのが「オーナーエンジニア」と呼ばれる制度です*3。

オーナーエンジニアの役割

概要

オーナーエンジニアは PBL の各アイテムごとに担当エンジニアがつく制度で、主に以下の役割を担っています。

• 施策の技術仕様を現実的なものに落し込む
• スプリントプランニングでアイテムが見積もりできる状態に持っていく
• 施策の評価指標の設計が必ず行われるように提案・助言する

この他にも、アイテムに関しての技術的な相談窓口だったり、アイディアの壁打ち相手などをやることが多いです。
役割としては技術領域の責任者なのですが、言葉の意味としては「担当施策のオーナーシップを持つエンジニア」という解釈の方が正確で、実装を中心にしながらも施策が滞りなく進行することに自体に責任を持っているという認識です。そのため、求められる知識や能力は幅広く、例えば以下のようなものが挙げられます。

• 施策コンセプトへの理解
• 施策理解をベースにした、実現方法の策定
• 開発のリード
• プロジェクト進行への理解
• 何かあったら自分がなんとかするという気概*4

要素を並べただけではイメージしづらいと思うので、ここからは自分が実際にオーナーエンジニアを担当したときにおこなったことを紹介していきます。

実例

1. オーナーエンジニアのアサインとキックオフ

バックログリファインメントにおいて、優先順位が上がってきたアイテムにはオーナーエンジニアがアサインされます。今回自分にアサインされたアイテムは「つくれぽを投稿することによって自分がつくりたいレシピに出会いやすくなる体験をつくる」といった、規模が大きく抽象度も高いものでした。叩きのアイデアはあるものの、ここから仕様を取捨選択し磨き込む必要があるフェーズのアイテムだったため、ある程度長期間のプロジェクトになることを見越してキックオフの設定を提案しました。
キックオフでは、施策の目的やコンセプト・手法の概要など現時点で決まっていることを施策オーナーからインプットしてもらい、今後の進め方と次のアクションを決定します。今回は、前述したようにある程度長期間の伴走が必要になるアイテムだと感じたため、一時的なプロジェクトと考えて定例ミーティングも設定してその場は解散となりました。

余談ですが、自分はキックオフミーティングに必要な要素を以下のようなモデルで捉えています。このモデル自体は組織や個人によって変わってくると思いますが、こういうイメージを頭の中に持っておくと、自分で設定する時は抜け漏れが減り、キックオフに招待されたときにも足りない部分をフォローすること等ができて便利です。

2. 施策コンセプトの理解

キックオフで聞いた概要をもとに、施策の目的やコンセプトを自分の頭に叩き込んでいきます。開発のフェーズになると他のエンジニアメンバーとコミュニケーションを取ることも増えるため、この施策ではどういう価値を提供したいのか、あるいは検証したいのか、部署の目標とはどう繋がっているのか、その結果どういう手法を取るつもりなのかといったことを自分の言葉で話せるようにしておきます。
具体的には施策オーナーやデザイナーへのヒアリングをしたり、仕様やデザイン案を読み込んだり、ユーザーインタビューの録画を見たりしました。この部分の解像度が低いと、後の仕様を詰めていく工程で削るべき部分や残すべき部分の判断がつかなかったり、設計工程において適切な判断ができなかったりするので、しっかりと労力を割きました。

3. 仕様の相談と決定

施策のコンセプトを理解した上で、ディレクターの仕様やデザイナーのデザインに対して改めて確認や提案をしていきます。最初に出てきている案は検証したい価値に対して機能過多になる傾向があります。そのため、基本的には自分の中で MVP になる体験をイメージしつつ、削れそうな仕様を探したりフェーズ分割できそうなポイントを探したりしながら、仕様をコンパクトにできないか提案することが多いです。

加えて、リリース後にどういう分析をしたいのかを確認し、提案を交えながら埋め込んでおく必要がありそうなログをリストアップしておきます。後で「あ〜〜〜！ログ埋まってなかった！！！」というのはやりがちなミスなので、この時点でケアできていることが望ましいです*5。

また、施策オーナーは仕様の技術的な難易度を認識していないことが多いため、その辺りもすり合わせながら整理していきます。実装難易度が高くなりそうな箇所については、改めて重要性の確認をしたり、ザックリの工数感と代替案を提示した上で再度意思決定をお願いしたりします。逆に、それほど工数がかからないような詳細の磨き込み等は、こちらから仕様追加を提案することもあります。
他にも、施策オーナーの希望しているスケジュール感を確認し、現状開発チームが出せているベロシティによっては、PBL 上での優先順位を上げてもらうよう PO とコミュニケーションを取ってもらうように提案したりもします。開発チームの現状はエンジニアからの方がよく見えるので、プロジェクト進行面でのフォローも効果的です。

ここで心掛けているのは、あくまで施策のゴールを達成するために仕様を煮詰めていくという意識です。仕様を削れば削るほど実装は楽になりますが、それ自体が目的になってしまっては必要な仕様まで削ってしまうことになりかねません。エンジニア目線だけを持つのではなく、施策のゴール達成という目標を同じ目線で見るプロダクト開発者として考えることが重要です。そのためにも 2 のフェーズで施策に対する解像度を高めておくことが重要になります。

4. 概算見積もり

ある程度固まってきた仕様をもとに概算で工数を見積もっていきます。設計方針を決め、コード調査をし、場合によっては他のエンジニアに相談しながら進めていきます。
施策の目的が検証であればデーターソースは YAML でよいと割り切れる*6が、恒常的な機能を開発するなら DB に table をつくる。施策の確度が低く、リリース後もどんどん改善していく想定であれば後から消しやすいように別の table でデータを持つが、そうでないなら今ある table に column を追加する。今後想定している利用者数の推移に基づいてスケーラビリティをどの程度考慮するか決めるなどなど……。このフェーズでも施策理解の解像度に左右される意思決定が多数存在します。繰り返しになりますが、施策意図のインプットが非常に重要です。

参考までに、自分はデザイナーが Figma で描いてくれたデザインをコピーしてきて画面遷移図をつくり、その上に付箋をペタペタする形で見積もりをつくっていくことが多いです。こうすることで、必要実装の抜け漏れが減りますし、視覚的にどういう機能をつくればいいかがわかりやすくなります。Figma 上で仕様やデザインについての質問が完結するのも便利です。

一人でグッと考えていると行き詰まることも多いので、なるべくラフに他のエンジニアに相談するように心掛けています。実際に開発に入る前の段階からエンジニアメンバーに施策概要が浸透することにもつながるので、一人で抱え込むよりは早めに状況を開示することが大事だと考えています。今のチームは #recipe-sekkei-inquiry という slack チャンネルを運用しており、割と雑な質問や相談が飛び交っているのがいい環境だなと思います*7。
最終的にはエンジニアが集まる「概算見積もり会」という会議体に持ち込み、参加者から「ざっくりよさそう」の合意が取れれば、優先順位の高いものから順にスプリントに乗っていくことになります。

5. 開発

ここから先は基本的には一般的なスクラムの進行になります。スプリントプランニングでアイテムの詳細見積もりをし、タスクに書き下してスプリントバックログに貼る。デイリースクラムで進捗を確認しながら、メンバーが各々取り組みたいタスクを選んで受け持っていく。といった流れです。
ただし、少し規模の大きな開発になる場合は、最初に「設計ドキュメントを書く」というチケットを作成し、エンジニアメンバー間で認識をすり合わせるためのドキュメントを執筆します*8。設計ドキュメントのフォーマットは現状規定されていませんが、issue へのリンク、最低限の仕様、デザインのスクリーンショット、レスポンスの形式、実装予定のサービス名や該当ファイルなどが含まれていることが多いです。このチケットは原則としてオーナーエンジニアが取ることが多く、なるべくスプリントの序盤に取り組むことが推奨されています。

開発が始まってからは、他のメンバーが実装してくれた箇所については、積極的にコードレビューに入るなどして、仕様漏れのキャッチや整合性の担保ができるように心掛けます。

6. 分析・評価

機能をリリースした後は、分析・評価をおこなって next action を決定するまでが施策です。といっても弊チームではエンジニアではないメンバーが平気な顔をして分析 SQL を書いたりするので、3 の工程で正しくログを設計できていればあまりやることはないのですが。最近では、機能リリースの目処が立った時点で「数字を見る会」なる会議体が設定され、そこで関わったメンバーみんなが数字を見ながらやいのやいの言いつつ next action が決まるケースが増えてきました。分析・評価が実施されることや、その透明性を担保するための一つのプラクティスになりそうです。

雑感

本記事では、クックパッドのレシピサービスで導入されているオーナーエンジニアという制度について紹介しました。
改めて並べてみるとなかなかやることが多く「これは本当にエンジニアの仕事なのか？」と感じる業務まで含まれているようにも見えます。しかし「専門職が集まって分業する」というのは、得てして下図のように、イメージと現実の間にギャップがあるものです。我々がユーザーへの価値提供にフォーカスする限りは、現実の中で境界にあるような仕事を誰かが拾って進めていく必要があり、そのためにもできることは多い方がいいでしょう*9。

もちろん自分だって凄腕デザイナーに CSS の修正をしてもらったり、視野広ディレクターに考慮漏れを拾ってもらったりしたことが数多くあります。僕は、専門性に軸足を置きながらも役割にとらわれないメンバーが多いチームは強いと信じているので、自分もそうありたいと思います。

また、今年自分でやってみて思いましたが、シンプルにオーナーエンジニアの仕事は楽しかったです。僕は「サービス開発エンジニアになりたい！」と言いながら 2017 年にクックパッドに入社し、エンジニアをやったり PjM をやったり部長をやったりしていましたが、どれもエンジニアリングとサービス開発に対して同時に向き合うことは難しい仕事でした。今年それらの経験を経た上でエンジニアに戻り、オーナーエンジニアをやってみたところ

• プロダクト開発と技術力の両面を同時に求められ、向き合う必要がある
• それぞれの能力が施策のクオリティに直結する実感がある
• その上で、エンジニアリングという専門性に軸足を置いているので（キャリア的な意味で）自我を保ちやすい

という実感がありました。サービス開発にはさまざまな要素が存在するため、日々の仕事の中で自分の役割に迷う方も多いのではないかと思います。そんな方の参考になれば幸いです。

この記事の内容について質問などある方は、気軽に Twitter などにご連絡ください。選考応募はもちろんのこと、カジュアル面談も積極募集しているため、チャネルにこだわらずお声がけいただければと思います。