プロジェクト事例：レシピ移行
記事を読んで頂きありがとうございます。株式会社Antway システムアーキテクト部の荒井と申します。
本記事では、Antwayのエンジニアがどのような役割を求められており、実際どのように立ち回っているのか、実例を通してお伝えできればと思っています。
Antwayのエンジニアに求められること
まず、エンジニアに求められることを大まかにご紹介します。
当社では「アプリケーションを開発すること」だけではなく、「業務効率化と長期的なリスクを潰すこと」が求められます。
何らかの目的に必要なアプリケーション要件を共有され、設計・実装だけを行うのではなく、開発の前工程である企画や要件定義の段階から参加し、システムに深く関わる者の観点から、ビジネス側のメンバーと一緒にプロジェクトのリスク洗い出しや手段の検討なども行います。
手段を検討した結果、実装がほとんどなく、ツールの導入のみで完結することも多々あります。
対応スコープが広い分大変ではありますが、本質的な課題解決や事業に対してのインパクトを与えやすいところが魅力です。
今回は、具体例として「レシピ移行プロジェクト」を取り上げ、エンジニアの立ち回り方について理解を深めて頂けると幸いです。
レシピ移行プロジェクトとは
弊社の「つくりおき.jp」サービスに関連するプロジェクトです。メニューの企画・調理・配送する際に利用するレシピデータの拡充・FMT化を行い、関連課題を解決する目的でスタートしました。
前提として、サービス概要と、ご家庭に作り置きを配送するまでの大まかな流れをご説明します。
つくりおき.jp は、手作りの作り置き宅配サブスクリプションサービスで、登録して頂いているお客様に、毎週手作り・出来立てのお惣菜をお届けしています。
そのお惣菜をお届けするまで、大まかに以下のような工程をたどります。
- レシピ開発
- レシピ選定
- レシピ試作・レシピの最終確定
- レシピ調理
- お客様へ配送
レシピは、開発-配送までの各工程で利用され、参照・更新する関係者も多いデータで、すでに数千件を超える量があります。
レシピ開発時にはデータを入力し、選定時には企画時に入力したデータを参考に、過去の人気傾向やコストなども踏まえた上で週のメニューを組んでいきます。調理時は、材料の種類・使用量などを参照し、内容の誤りや生産量が不足しないようにします。
関連する工程や関係者、目的の多さ故に沢山の課題がありました。例えば、以下のような課題があります。
| 工程 | 課題 |
| レシピ開発 | 積極的に開発すべき、不足しているカテゴリ(魚・肉など)のレシピが分からない。 しかし、ツールの検索性が悪い・レシピ表記の一貫性がなく、どのようなレシピがどの程度存在するのか数えるのも困難。 |
| レシピ選定 | ・主素材・メニューの栄養バランスなどを加味したレシピを発見・採用したいが、レシピや材料の表記などの問題で、適切なレシピを発見するのが難しい。 ・レシピが原材料のデータと紐づいておらず、原価が分からず、比較検討できない。結果的に、原価管理の精度が低い。 |
| レシピ試作 | 試作による気づき・注意点などを記載するフォーマットが決まっておらず、担当者や感覚によって表記がバラバラに。見落としや、ミスの発生に繋がる。 |
| レシピ調理 | 材料一覧と作成手順の材料表記がずれていることによる勘違い・見落としなどによる、味のブレなどに繋がる。 |
これらはほんの一部ですが、これらの課題を解決するため、レシピを管理するツールの移行やルールの整備を行ったのが本プロジェクトです。
メンバーとしては、全社横断での中長期的な施策の検討や推進を行う経営企画部・キッチンでの調理を管理するロジスティクス部・レシピの企画や管理を行うマーケティング部・システムアーキテクト部の私がアサインされ、課題やリスクの整理・手段の検討・レシピ移行までを行いました。
企画・要件定義フェーズ
本フェーズでは、プロジェクトの目的・課題・仮説の検討や、詳細な課題の洗い出し、対応手段の具体的な検討・実行計画などを行います。
エンジニアである私も、他部署のメンバーと同様にこのフェーズから参加しました。
要件定義時に意識していること
私は、要件を洗い出すにあたり、以下のような情報が洗い出されるべきだと思っています。基本的には1から順番に洗い出す必要があり、後ろの情報は前の情報に依存しているため、可能な限り1から網羅的に情報を洗い出す必要があると考えています。
- システム価値・目的、システムの価値を決める目的や課題感
- システムを取り巻く環境、システムを利用する業務・利用タイミングなどの環境
- システムのインターフェース、利用者とシステムの接点
- システム要件
開始時点での課題感と取り組み
上記を踏まえて、本プロジェクトでは開始時点では「現状の業務とレシピデータの利用方法(システムを取り巻く環境)が不明瞭」という課題を感じていました。
レシピを活用する部署やメンバーが多く、活用方法も様々であるという認識はあったものの、業務担当者の頭の中にのみ断片的な情報があり、全体の情報がなく、リスクや課題・必要なインターフェースなど、要件を考える土台がない状態です。
そのため、プロジェクトの担当者の方々に依頼し、以下のような業務フロー図への落とし込み・業務の現状整理を行ないました。
(画像はイメージです)
これにより、リスク・必要な情報などが漏れなく洗い出せる状態を作ることができ、プロジェクトで対応が必要なスコープの認識合わせ・優先度や要件のすり合わせを行えるようになりました。
業務を洗い出した後は、プロジェクトのメンバーと協力して業務上の課題や考えられるリスク・対応策を洗い出し、対応の可否・優先度などを判断した上で要件に落とし込んでいきました。
結果的に、大まかには以下のような要件が定義されました。
- 原価管理ができること
- 最低限レシピ調理に必要な項目が入力できること
- レシピ・材料名・手順などが統一された表記で追加され、同一種類のレシピ・材料は1つのマスタに統一されること
これら要件と時間的制約を踏まえた結果、外部ツールを使うこととなりました。
広く調査した限りでは、3つ目の「表記ゆれなどを防止」できるツールは存在しなかったため、命名ルールや運用ルールを設計・定義することで可能な限りミスを防止することを取り決めました。
実行(レシピ移行)フェーズ
要件・移行先のツールが決まったため、次は実行フェーズです。大まかには、以下のようなタスクがありました。
- 新レシピ管理ツールの運用ルール策定
- レシピや材料の命名ルール策定
- これまで蓄積したレシピの表記の統一・新ツールへの取り込み
タスクを遂行するにあたり、以下のような課題がありました。
- 運用していたツールのレシピ・材料の一覧性が悪く、命名ルールの定義・表記統一などに活用できない。
- 運用していたツールの制約上、ツールからデータを一括出力することができず、人力でコピペせざるを得ない。過去レシピの種類も膨大で、工数が爆発する。
人力ではあまりに効率が悪く、対応漏れも発生し得る状態だったため、効率化・ミス防止のための移行サポートツールを用意し、データ出力の部分は、スクレイピングのコードを実装し、必要なデータをシステムで取得することとしました。
移行サポートツールは、弊社がGoogleに依存した環境であること、ビジネス側の使い勝手・慣れ、実装コストを踏まえて、Googleスプレッドシートを採用しています。
可能な限り効率化しつつ、移行時のミスを防止するため、工夫した点は2点です。
- 移行作業自体の工程・ルールも定義すること
「過去データからマスタを定義するフェーズ」・「マスタの既存データとの紐付けで表記揺れを解消しつつ、新フォーマットに必要な情報を入力するフェーズ」・「新ツールに入力するフェーズ」の3つの工程を作りました。
マスタを定義することで、確実に揺れを潰し、ついでに命名ルールなども定義しやすいようにしました。
また、新たに定義したデータを、新ツールに直接入力せず、移行用のシートにも記載しておくことで、命名ルールなどの反映の効率・抜け漏れが発生しないようにしました。
- 移行用シートにバリデーションの実装・違反がある場合には色付けを行うこと
人力での表記統一となるため、ミスはつきものです。シートにバリデーションを実装することで、即ミスに気づき、誤った入力が発生しないような仕様としました。
(実際に作成したサポートツールの一部)
結果
これらの取り組みの結果、当初の目的達成に加えて、表記揺れなどのリスクを回避した上で、レシピ管理ツールの移行を行うことができ、現在も運用が回っています。
事業的にも、以下のような効果を上げることができました。
- 例として挙げたような課題解決。
- レシピ企画時点で原価計算が行えるようになったことで、利益率のコントロールが可能になった。
まとめ
上記の例のように、エンジニアには「業務効率化と長期的なリスクを予防すること」が求められます。
そのため、実装だけでなく、企画や要件定義段階からの関わり、システム以外の面に対してのアプローチも必要になります。
関係する範囲が広い分大変ではありますが、業務フロー図・データフロー図・スクレイピングなど、エンジニアがよく使う手法をビジネスサイドに導入することで大きな価値発揮に繋がり、やりがいや面白さを感じられること、事業に対してインパクトを与えられることが魅力だと感じています。
少しでも、弊社のエンジニアポジションに興味を持って頂けると幸いです。