はじめに

こんにちは。食べログ開発本部ウェブ開発1部の羽澤です。マネージャーという立場で働いておりまして、案件をリードしたり、一歩引いてメンバーや案件をサポートしたり、その時々で役割を変えながら日々過ごしております。その中でいつも頭を悩ませているのが、いかに早く開発を進めるかということです。これは食べログだけでなくどんな組織でも常に考えている、永遠の課題だと思います。今回は食べログの開発体制を紹介しながら、自分として爆速で進められたと感じている案件を紹介します。「なぜうまく行ったのか」を掘り下げることで見えてきた重要な視点を、「爆速で進める1つのポイント」としてまとめてみました。

プロジェクト体制の紹介

開発の話の前に、前提となる組織の形を紹介します。私の所属するウェブ開発1部では、マトリクス型の組織を採用しております。ウェブ開発1部の事例ではありませんが、以下の記事が参考になるかと思います。

食べログの部署は機能型の組織構造を採用しており、サーバーサイドエンジニア、アプリエンジニア、企画、デザイナーなど、それぞれ職能ごとに部署として独立しています。しかしながらチーム構成は部署を跨いで構成されており、1チームの中に、企画、デザイナー、アプリエンジニア、そして我々サーバーサイドエンジニアが所属しています。

マトリクス型組織を採用している目的は、全員がKPI達成のためにミッションを追うことです。各職種が一丸となり、チームに与えられたミッションを達成していく形になっております。マトリクス型ではなく完全に機能ごとのチーム編成で動いていた時代もありました。その時はKPIに対する案件の優先度や進捗等が見えにくく、我々エンジニアとしては与えられた案件優先度でひたすらこなしていくのがメインでした。 KPI達成のために、エンジニアから企画にもっとこうした方がいいよ、こっちを優先して進めようよ　と伝えたい気持ちはあったものの、エンジニアはシステムや仕様面以外の部分が見えないことが多く、判断する材料がなかった時代だったなと感じています。今はマトリクス型の組織をとっているため、エンジニアからでも自分たちが追うべきKPIや、それに対する進捗状況がよく見えるようになり、全職種が一丸となってKPIを追うことが出来るようになっています。

爆速で開発するためには・・？

マトリクス型組織を採用してから数年が経ちました。当初は混乱もありましたが、いくつかの改善をしながら安定してきたと感じています。そんな中、最近よく耳にするようになったキーワードがあります。

「エンジニア主導」です。

マトリクス型組織になり全員がKPIに対して責任を持ったものの、食べログの開発でボトルネックになりやすいのが要件定義から設計のフェーズです。食べログではシステムの規模はもちろん、それに伴ってサポートや支払い業務等を含めたサービス全体が大きいため、案件によってはステークホルダーが多くなる傾向があります。各所調整しながら要件を決めた上で設計に落とし込む必要があり、ある程度の経験や業務知識が無いと難しく、時間がかかってしまっています。

食べログの特徴のように書きましたが、規模の大きいサービス全般に言えることではないでしょうか。要件定義から設計までを如何に早く行うかが爆速開発の1つの要因になると考えていて、それに対する1つの回答として、「エンジニア主導」に注目しています。

但し、私が注意していることがありまして、エンジニアが企画になってはならないということです。エンジニアはやはり開発力をコアの能力として成長したり、活躍すべきであり、企画立案やディレクション「も」出来るのは強みにはなると思いますが、そこに振り切るのは違うと考えています。このバランスをどううまく取るかが、「エンジニア主導」の鍵だと考えており、後述します。

【事例1】他社連携案件

他社との連携案件の対応をした時の例です。この案件ではユーザーが食べログで予約した際ユーザーに対し、連携している他社からお得サービスを提供するような案件でした。

APIのすり合わせ・・・の前にやることがある！

前述の通り他社と連携してサービスを提供するため、先方から提供頂いたAPIを利用する必要がありました。 APIの基本的な内容は先方から頂くことになっており、API仕様の説明及びすり合わせの会議が設けられました。

会議に先立ち、考えておいたことがあります。それは「サポートをどうするか」です。

サポートの流れ及び、データ連携の可能性と必要事項の確認を実施

連携案件の性質上、ユーザーからの問い合わせが両社に対して行われる可能性があります。この時、食べログでないとわからないこともあれば、先方でないとわからないこともあり、対応が悪いとユーザーをたらい回しにしてしまう恐れがあります。これは絶対に避けなければなりません。

そのためにはサポートの流れを2社間で決めておく必要があります。食べログと先方のどちらが主体となってサポートを行うのかという点が特に重要です。連携案件では2社のそれぞれでデータを保持していますので、情報を共有しながらサポートを行う必要があります。事前にデータを共有しておくことで、随時共有する手間を省くことも可能ですが、考えなければならないことはいくつかあります。

想定される問い合わせへの対応について
- 問い合わせへの回答に必要なデータの所在
- 問い合わせに対する調査主体
  - データを調査して最終結論を出せる方が主体
  - 問い合わせごとに主体が変わることもある
事前データ共有の有無について
- 問い合わせの主体となる会社で対応ができるよう、あらかじめデータを共有する必要があるか
- 事前データ共有する場合、ユーザー同意の要否と実現方法

事前のデータ共有を行う場合、API設計に大きく関わってきます。急ぎの案件ほどサポートのことは後で考えられがちですが、後からプログラム修正が必要になる可能性があるため先に考えておくべきです。またサポートは企画部やサポート部が考えるという組織もあるかもしれませんが、最終的にデータやログを調査したり、最悪データ修正を伴う補填作業を行うのはエンジニアです。ですのでエンジニアも主体となって取り組むべきと私は思います。

サポートの主体はどちらか

本案件においては、サポートの主体は食べログ、事前のデータ共有は無しで都度共有が良いのではないかと考えました。先方に問い合わせがあった場合は食べログのサポートに誘導して頂くか、予約を特定可能な情報をヒアリング頂いた上で食べログに共有頂くというのが主な流れとなります。

考えたポイントは以下の通りです。

ユーザーに対してサービスを提供する画面を持っているのは食べログである。
サービス提供に必要なデータや各種ログも食べログの方が多く持っており、最終結論を出しやすい。
先方が主体になる場合、食べログからデータを共有しておく必要がある。そのデータを共有する場合はユーザー同意が必要な可能性が高い。
ユーザー同意を取る場合、情報の取り扱いについて画面に提示する必要があり、ユーザー体験を損ねるため出来れば避けたい。

念の為、企画担当者に依頼してデータの共有について法務に相談して頂いたところ、やはり他社に共有する場合はユーザー同意が必要となることがわかりました。

APIのすり合わせでサポートの流れを認識合わせ

前述のような準備を行なった上で先方との打ち合わせに臨んだところ、予想通りAPIを呼び出す際にPOSTしてほしいデータについて言及がありました。そのままサポートの流れの話になったため、私が想定していたサポートの流れを説明したところ、先方の持ち帰りとなりました。後日、弊社から提案した流れでOKという回答を頂き、APIを呼び出す際に提供するデータは無しということでAPI仕様が確定しました。

爆速開発の要因

この案件での爆速ポイントは、先方との会議の前にサポートの流れを設計出来ていたことと考えています。これがなかった場合、先方から「サポートのためにこういうデータをPOSTしてほしい。」という依頼を受けた後にサポートの流れを検討し、法務に確認するという流れとなります。しかしこの時は先方がAPI設計をしている最中に先回りして準備したことで、最低限のやり取りでAPI設計、サポート（＝運用設計）を完結することに成功しました。

体感ですが、1週間以上の工期短縮に繋がったと考えています。

先方との会議数を減らせたこと。
法務確認という、他部署を巻き込んだ確認ごとを事前に終わらせられたこと。
エンジニアが主体となってサポートの設計をしたことで、API設計とシームレスに繋がったこと。

以上のことから、エンジニア主導の案件としての成功例だったと考えています。

【事例2】Pontaポイントを貯められるようにした案件

食べログでは以前より、予約することでVポイントを貯めたり、店舗によってはVポイントを利用して予約することで値引きを受けることが出来ていました。それに加えて昨年から、Pontaポイントを貯められるようになりました。（利用は出来ません）この案件にも爆速ポイントがあったので紹介します。

基本はVポイントを踏襲

ポイント系の機能開発はお金に関わるものなので慎重に行う必要があります。しかしながら今まで長く運用してきたVポイントの仕組みがありましたので、それを踏襲することにしました。長く運用されているため仕組みとして問題がないという点が大きな理由です。というわけで、設計の大方針は即決まってしまいました。

今まで1つのポイントのみで運用してきたものが2つになり、ユーザーごとに付与ポイントが異なるようになるという大きな変更がありましたが、正直設計する上での難しさは全くありませんでした。付与ポイントを決める、つまりこのユーザーにはどちらのポイントを付与するかを決めるタイミングが全てでしたので、企画担当者と調整して即決定。その上でシステム構成図を作成し、各チームの役割分担を決めて開発に突入したという流れです。

ここまでは数日で実現可能であり、それほど難しい話はありませんでした。

肝心の運用設計を大きく省略

システムはリリース後に発生する改修案件も含め、開発している期間よりも運用している期間の方が圧倒的に長いです。そのため運用負荷が大きいと、トータルでのコストパフォーマンスは大きく低下します。そのため運用設計が何よりも大事だと考えています。そんな大事な運用設計を、この案件では大きく省略することが出来ました。

ポイントシステムはシステムを開発するだけでは済みません。ポイントの運営会社に対してシステム利用料を支払ったり、内部監査への対応も必要です。そのための各種レポートをシステムから出力し、人が確認すると言う運用を行なっています。これらもVポイントを踏襲して実装することになるのですが、Vポイントは貯まる使える。Pontaポイントは貯まるのみで使えないという差異がありますので、必要なレポートの整理が必要ですし、仮に将来Pontaポイントが使えることになった場合に各種レポートを出力可能かの検証が必要です。それには各種レポートの整理と、各種業務担当者に確認して必要なレポートをまとめておく必要がありますし、それを使った業務の設計が必要です。

日々の運用経験を活かして設計

各種業務担当者と会話してレポートを整理という、本来であればある程度の時間がかかる作業が必要となりました。しかしながら！食べログのエンジニアはVポイントシステムを長年運用保守しており、運用業務を詳細に把握してます。頭にある業務を元に必要なレポートをまとめて合意を得ることで、運用設計を最低限の工数でこなすことが出来ました。

必要なレポートの設計と業務設計を

「これらがあれば大丈夫ですよね？」「そうですね大丈夫です。」

このやり取りだけで完結させたような状態でした。（勿論細かいやり取りはあったものの、負担なく対応できるレベルでした。）

ここでも1週間以上の工数を削減できたと考えています。元々Vポイントの運用をしていたため基本は踏襲すれば良いのですが、踏襲できないものも出てきます。日々の運用経験がなかった場合は以下のステップを踏む必要がありました。

既存の運用と、出力しているレポートを一覧化
既存運用で出力しているレポートを、Pontaでも出せるものと出せないものに分類
Pontaで出せないものがあれば代替案を出す

中々に時間がかかりそうな作業を、一瞬で終わらせられることが出来ました。カッコ良すぎる！

2案件の爆速開発まとめ

2案件紹介しましたが、爆速開発の要因はコードを書く速さではありませんでした。運用やサポートの勘所をエンジニアが理解し、それを設計に活かすことにより要件定義や設計を省けたことが要因だと考えています。そうでない場合、運用やサポートを行っている部署に相談やヒアリングを行い、システム設計する時間が必要です。しかし紹介した2案件では運用やサポートの設計をエンジニア主導で行い、同時にシステム設計も出来ていました。他部署や他職種メンバーとのやり取りが大幅に減ること、システム設計にシームレスに繋がることによって、運用やサポートが決まる＝システム設計も即完了する　という状況を作ることができた事例です。

運用業務を避けたいというエンジニアも一定数見てきましたが、とても勿体無いと感じています。運用を知るものは開発を制すと私は考えていて、提示した案件だけでもそれを実証できているのではないでしょうか。

エンジニアが主導すべき領域

冒頭で、エンジニアが企画になってはならないと書きました。勿論企画立案やディレクションが出来るというのは、エンジニアにとっての強みになり得ると考えています。しかしそこにフォーカスしすぎると、肝心の技術力や設計力というところから離れてしまいます。少なくとも食べログのエンジニアにおける主戦場ではありません。

運用やサポートといった、「システム設計」に大きく関わる部分を主導することで、案件はより早く進むというのが私の考えですし、前述したように実績も出せています。今運用業務に関わっている方は、それを爆速開発に活かせないか考えてみては如何でしょうか。またあまり関わっていない方も、ぜひ運用業務に興味を持ち、爆速開発に寄与出来る武器を身につけてみては如何でしょうか。