食べログに見る、成長し続けるサービスの「業務的負債」との向き合い方

※2021年4月15日に開催されたエンジニアHubウェビナー「食べログエンジニアに聞く！大規模サービスの裏側エピソードを限定公開」より、全文書き起こしレポートをお届けします。

• 「課題解決」と「運用」の乖離が引き起こす生産性低下を回避する
• 食べログの業務的負債について｜Go To Eatキャンペーンの事例
• なぜ、業務的負債は発生するのか
• 業務的負債と向き合うために大切なこと
• システム開発という枠の外から目的を俯瞰

「課題解決」と「運用」の乖離が引き起こす生産性低下を回避する

はじめに簡単に自己紹介をします。普段の仕事は、主に食べログの飲食店の皆様向けに提供している店舗情報の編集機能やネット予約システムの開発です。その他、販売管理などを扱う業務システムも担当しています。

食べログでは、いろいろな領域に携わってきましたが、現在はシステムの裏側（あまりユーザーからは見えない部分）の開発に携わることが多くなっています。

今日お話するのは「成長し続けるサービスの【業務的負債】との向き合い方」というテーマです。

最初に「業務的負債」に関してですが、ここでは「解決すべき課題と実際の運用業務の乖離が引き起こす生産性の低下」と定義しています。世間一般で広く使われる用語ではないのですが、ここでは「業務的負債」と呼ばせていただきます。

また、ここでの「運用業務」は、営業担当者やサポート部門など、システムを利用する側の業務を指しています。

私たちはエンジニアとして、当然システムの開発改善を行うことが多いですが、注文されたシステムを単に作るのではなく、もう少し踏み込んでできることがあると私は考えています。

「業務的負債」の例として、いくつか上げさせていただきます。

【例(1)】

本来実現したいことから捻れているが、業務をシステムに合わせて運用している。

本来であれば、業務に合わせてシステムを作ることが望ましい状態ですが、逆の状態になってしまうこともあると思います。

この場合、現場のテクニックを駆使して何とか業務を補完しながら運用したり、あるいは実現したいことが充分にできずに妥協している状況が考えられます。

また、「業務」と「システム」がマッチしていないと、システム的に意図していない性質のデータが登録されることがあり、システム面でカオスになることもあります。放置すると、業務やシステムのリプレースを行う際、業務整理や要件の洗い出しの難易度が上がり、後々想定外のコストが発生することが考えられます。

【例(2)】

手作業による個別対応が多い運用業務

これは発生しやすい問題かと思います。あるべきシステムが作られていない、という状態です。

もちろんシステム化をするにもコストや何らかのリスクが発生します。そのため、何でもすぐにシステム化すれば良いというものではありませんが、場合によっては（システム化していなかったために）単純な作業ミスが生じて大きな二次被害につながってしまうこともあります。

たとえば、取引先にメールを送る業務です。これらを手作業で行なっている場合、宛先を誤って送信してしまうというトラブルが想定できます。メール1本で、関係者に大きな迷惑をかけ、場合によっては情報漏えいのリスクにもつながってしまいます。

さらに突発的な業務が増えると「運用」の現場は混乱し、結果的にサービスそのものの品質低下に繋がってしまいます。

他にもさまざまな例が考えられますが、ここで少し食べログで実際にあったことについて紹介します。

食べログの業務的負債について｜Go To Eatキャンペーンの事例

Go To Eat キャンペーンでの事例を用いてお話しさせていただきます。

Go To Eat キャンペーンに伴い、飲食店の皆様向けに固定費無料でネット予約が利用できるプランを提供することになり、ネット予約を導入していない飲食店の皆様から、多くの申し込みが予想されました。

当時は、飲食店の皆様が「オンライン申込み」をされた場合、営業担当者を介さないため、審査などに多くの工数がかかり、そのため短期間で多数の申込みがあると対応することが難しいという、通常時には気付きにくい業務的負債が隠れていました。

そのため、申込みの審査や社内手続きにかかる工数を削減できるように、財務や法務と連携し、運用工数を削減する仕組みをつくりました。その結果、素早いサービス提供を実現でき、最終的に多くの飲食店の皆様にネット予約の利用を始めてもらうことができました。

なぜ、業務的負債は発生するのか

ここからは、なぜ業務的負債が発生するのかを考えていきます。

まず、1つ目に、

開発時に要件が出揃っているとは限らない

ということが挙げられます。

要件定義の教科書などの教えでは、要件をちゃんと最初に伝えきる、受け取り切る、ということが書いてあります。ただ、実際には開発が進んでから変更があったり、新しい要件が見つかったりすることも珍しくありません。やむを得ず、場当たり的な開発をしたり、当面は運用側で何とかしたりといった判断になりやすいと思います。

２つ目に、

要件に対する認識のズレや考慮漏れ

が、挙げられます。

これもよくある話ですが、たとえば同じ言葉を使っていても、人によってイメージしているものが違ったり、逆に違う言葉を使っているけれど同じものを表していたりすることがあります。

ドメイン駆動設計の考えを用いれば、コンテキスト／業務の領域ごとに言葉やモデルを統一するのが良いとされていたりもします。関係者間で「言葉」と「実態」が一致するよう、コミュニケーションをとる際は、図表を使ったり、実例を示したりして、そのズレを修正したいところです。

３つ目は、

業務も変化、多様化する

ということです。

サービスリリースから時間が経てば、現場でやりたいことが変わり、以前はレアケースだったことがそうではなくなることもあります。

4つ目は、

今あるシステムや業務を変えることが出来ると考えられていない

ということです。

いつの間にか「解決すべき業務上の課題に対し、システムによる適切な対応がなされていない」という状態になることもあります。

では、こういった課題を解決していくために、どのように行動していくかを考えていきます。

業務的負債と向き合うために大切なこと

細かなテクニックはお伝えしきれないですが、まず重要なのは、運用側とのコミュニケーション機会を作り、そして増やしていくということです。

普段は話題に上がらなかったけれど、直接話してみると「実は・・・」という話がぽろっと出てくることも。そういった話の中に、「簡単に改善できること」と「なかなか根深くて難しい課題」が隠れている可能性があります。すべて解決できるわけではありませんが、まずは実情の把握するために、コミュニケーションの場を持つことが大切だと思います。

続いて、エンジニアも業務を理解し、業務整理を一緒に行うことが重要だと考えています。依頼者や企画担当者が責任を持って進めていたとしても、エンジニアだからこそ提案できることあります。業務を深く理解することで、設計から最終的な成果物まで、より効果的で意味のあるものが作れるはずです。

最後に、業務企画担当者を立てるよう提案することを挙げさせていただきます。

先の2つと少し軸の異なり、組織の体制やあり方に関わる話です。

食べログでも、業務企画担当者を介さず、エンジニアと営業担当者、サポート部門が直接話をし、システムの改善を進めることはありますが、この場合は場当たり的な変更になってしまう可能性があります、

直近の課題を解決するために必要な場合もありますが、やはり業務企画の専門職である担当者が間に立ち、サービスの全体的な整合性や将来像を考慮した施策を考えていく方が、諸々の業務改善につなげやすいと思います。

エンジニアとして、システム改善を頑張るだけでは業務的負債の解消には限界が出てきます。だからこそ、組織の改善にも踏み込んでみてはいかがでしょうか。

システム開発という枠の外から目的を俯瞰し、提案を

まとめると、サービスが成長し続けるためには、エンジニア自身も業務領域や事業に対する理解を深めることが重要だと思います。時には、システム開発という枠の外から目的を俯瞰し、提案していく。そうすることで、自身の仕事がより大きな価値を届けることにつながっていくはずだと考えています。