Adobe Premiere Pro エクステンションによるレシピ動画編集の効率化

はじめに

DELISH KITCHENでは日々多くのレシピ動画を公開していますが、その動画は全てAdobe Premiere Pro(以下 Premiere Pro)を使用して編集しています。

今回はPremiere Proのエクステンションを作成して動画の編集効率を向上させた話をご紹介します。

これまで発生していた問題

レシピ動画にどのような材料を使っているか、どのような工程があるかは全てダッシュボード(データ管理用Webサイト)で管理しています。 動画編集者は動画データをPremiere Proに取り込み、対象レシピの情報をダッシュボードから開き、見比べながら作業していました。

動画にテロップを表示する際には、材料や工程の文章をダッシュボードからPremiere Proにコピペしながら編集作業を行っていました。

肉巻き半熟卵の動画テロップ例

この作業は地味に時間がかかる上にコピペミスをしやすく、手戻りが発生したりミスが残ったままレシピ動画が公開されてしまうこともありました。

そこで、編集作業の効率化 & ミスの削減のためにPremiere Proのエクステンションを開発しました。

エクステンションの紹介

エクステンションを有効にした状態でPremiere Proを開くと以下のような画面になります。 画像右上のパネルがエクステンションの画面です。 これから編集するレシピの情報が自動的に表示されるため、自分でダッシュボードを開く必要はありません。

Premiere Proでエクステンションを開いたところ

レシピのタイトルを挿入するときはタイトルの項目にある緑のボタンをタイムラインの好きな位置にドラッグ&ドロップします。 そうすると自動的にDELISH KITCHENで決められたデザインのタイトルテロップが挿入されます。 あとは表示する秒数やデザインを微調整すればタイトルテロップは完成です。

タイトルテロップをドラッグ&ドロップで挿入

材料も同様に、表示させたい位置にドラッグ&ドロップすれば材料用のテロップが表示されます。

材料テロップをドラッグ&ドロップで挿入

このようにタイトルや材料などのテロップをドラッグ&ドロップで動画内に挿入できるので、これまでのコピペ作業は必要なくなり、 ポチポチするだけである程度レシピ動画が作れてしまうというのがこのエクステンションの良いところです。

使用している技術

Adobe CEP

このエクステンションはAdobe CEP (Common Extensibility Platform) という技術を用いて作られています。 これはHTML5/JavaScript/Node.jsを使って様々なAdobeソフトウェアのエクステンションを開発できるというものです。

詳しくは以下のGitHubや記事で詳しく解説されています。

• Adobe-CEP/Getting-Started-guides: Getting Started guides and samples for CEP extensions
• Adobe-CEP/CEP-Resources: Tools and documentation for building Creative Cloud app extensions with CEP
• CEP スーパー メガ ガイド： HTML5 ＋ Node.js で Adobe のツールを拡張する | aphall.com

エクステンションの画面はChromium Embedded Frameworkというアプリケーションに埋め込んで使用するChromiumフレームワークを用いて表示しているため、 一部制限はありますがほぼ通常のChromeでHTML5/JavaScriptを実行するのと遜色ありません。 またNode.jsが実行できるためローカルファイルの読み書きも行えます。

AdobeソフトウェアのバージョンによってAdobe CEPのバージョンも変わり、それによって使えるAPIやChromium / Node.jsのバージョンも決まってくるため、 事前にサポートするバージョンを確認しておいた方が開発がスムーズになります。

参考: CEP-Resources/CEP 10.0 HTML Extension Cookbook.md at master · Adobe-CEP/CEP-Resources

Nuxt.js

Chromiumの上でHTML5/JavaScriptが実行できるとなると、ほぼWebサイトを作成するのと変わりません。 そのため、このエクステンションはNuxt.jsを使用しています。 (当初は素のVue.jsだったのですが、最近Nuxt.jsにリプレイスしました)

DELISH KITCHEN WEB を構成する技術のお話 でも紹介したように、 DELISH KITCHENのWebサイトにはNuxt.jsを使用しています。またレシピ管理用のダッシュボードでも同様にNuxt.jsを使用しています。

Nuxt.jsはサーバーサイドレンダリング(SSR)が特徴として挙げられがちですが、SSR以外にもページのルーティングルールやコンポーネント、プラグインの設置場所などが全て定められているというのが大きな特徴で、 Nuxt.jsで開発したことのあるWebエンジニアであればすぐにプロジェクトの構成が把握できるのが強みです。 そのためこのエクステンションでもNuxt.jsを使うことによって自分以外のエンジニアがエクステンションを開発する際にもプロジェクト構成の把握が容易になり、 共通のライブラリやプラグインが使用できるため開発がスムーズになります。

工夫した点

編集対象のレシピ情報を自動的に表示する

動画を編集する際に、毎回ダッシュボードから編集対象のレシピを開くのは地味に面倒な作業なので、Premiere Proを開くと自動的にレシピの情報が表示されるようにしました。

仕組みは単純で、以前からレシピ編集のルールとしてPremiere Proのプロジェクトファイルには <レシピID>_<レシピタイトル>.prprojというような命名規則で名前をつけることが決まっていたので、 Premiere ProのAPIでファイル名を取得し、正規表現でレシピIDを抜き出してからDELISH KITCHENのAPIでレシピ情報を取得し表示しています。

ドラッグ＆ドロップでテロップを挿入

なるべく直感的にテロップを挿入できるようにしたかったため、ドラッグ&ドロップで挿入できるようにしました。 ドラッグ&ドロップ自体は通常のWebと同じくdragイベントをハンドリングしdataTransfer.setData()でテロップのデータを渡せば良いのですが、setData()の第一引数に渡すformatは"com.adobe.cep.dnd.file.0"という文字列でなければいけません。 (複数データを渡す場合は最後の数字をインクリメントしていく)

参考: Samples/ext.js#L84 Adobe-CEP/Samples

PRTL

ドラッグ&ドロップでテロップを挿入、と言いましたが、実際には何のファイルをドラッグ&ドロップで渡しているかというと、PRTLというフォーマットのファイルを渡しています。 これは現在Premiere Proでレガシータイトルと呼ばれているテロップのフォーマットで、XML形式のファイルになっています。

テンプレートとして使用するPRTLファイルは予めエクステンション内に保存してあり、 材料などのテロップ挿入ボタンがドラッグされた瞬間にテンプレートのPRTLを読み込み、指定された箇所の文字列を材料名で置き換えます。再度PRTLファイルとして書き出した後にdataTransfer.setData()にそのファイルパスを指定すると、 ドロップした場所にそのPRTLファイルがテロップとしてインポートされ表示されるという仕組みです。

余談

Premiere Proにはレガシータイトル以外にもエッセンシャルグラフィックスというテロップの機能があります。 こちらもテンプレートがありAPIでPremiere Proに取り込むことができるのですが、若干扱いづらく、XML形式であることや直感的にドラッグ&ドロップで取り込めるという点でPRTLを採用しました。

ただし、PRTLはフォーマット仕様が公開されておらず(公開されていたらどなたか教えて下さい)、独自にパースする必要があります。 また、Premiere ProでテロップをPRTLファイルとして書き出せるのはCS6までで、それ以降のバージョンでは書き出し機能は削除されてしまいました。 このような状況で、将来的にPremiere Proがレガシータイトルをサポートしなくなる恐れもあるため、できればエッセンシャルグラフィックスを使ってテロップを挿入できるようにしたいところです。

エクステンションのパッケージング

Adobe CEPのエクステンション自体はPremiere Proのエクステンション用のディレクトリに配置すれば使用できるのですが、動画編集をするスタッフに毎回その場所に配置してもらうのも手間がかかります。 そこで、エクステンションをインストーラーでインストールできるようにしました。 全員Mac上でPremiere Proを使用するので、インストーラーとしてpkgファイルを生成します。

パッケージングの詳細や使用したコマンド、npmパッケージなどは以下を参考にしてください。

• Packaging and Signing Adobe Extensions
• CEP-Resources/ZXPSignCMD at master · Adobe-CEP/CEP-Resources
• codearoni/zxp-sign-cmd: A JS wrapper for Adobe's extension signer

パッケージングを手動で行うのも面倒なので、GitHub上でPullRequestをmasterにマージした際にCIでパッケージングし、 そのpkgファイルをtcnksm/ghrを使用してGitHub Releasesに自動的にアップロードするようにしました。

これでpkgファイルをGitHub Releasesからダウンロードして開けばMacでおなじみのインストーラーが起動し、エクステンションをインストールできるようになります。

エクステンションのインストーラー

まとめ

このエクステンションを使うことによってPremiere Pro内でテロップの挿入が完結できるようになりました。 また、ドラッグ＆ドロップでテロップを非常に簡単に挿入できるようになり、コピペミスを減らすことができました。 もちろん動画編集作業はこれだけで終わりではないのですが、地味に時間のかかっていた作業を減らすことができ、編集効率を向上させることができました。

このPremiere Proのエクステンションは2018年に作成したものですが、3年弱経った現在も毎日使われています。 自分が作ったものが毎日使ってもらえているというのは開発者冥利に尽きる思いですね。

DELISH KITCHENのサービスも毎日沢山の方に使っていただくため日々開発に励んでいます。

これからもDELISH KITCHENをよろしくお願いします。

MAMADAYS iOSアプリについて

はじめに

MAMADAYSにはiOSとAndroidのアプリがあります。 Flutterなどのクロスプラットフォーム開発ではなく、それぞれネイティブで開発しています。

この記事ではMAMADAYSのiOSアプリの全体的な構成を紹介します。 全体の雰囲気を掴んでもらうことを目的とし、細かい採用技術はまた別の機会に紹介できればと思います。

MAMADAYSアプリの機能

MAMADAYSアプリには大きく次のような機能があります。

メディア

MAMADAYSには動画を含む数千本の記事があり、ユーザーさんの状態やお子さんの月齢に合わせて適切な記事をおすすめする仕組みがあります。 リリース当初は記事を WKWebView で表示していましたが、表示速度向上などのためにネイティブに変更しています。 動画再生には AVPlayer を用いていて、自動再生処理や待ち時間短縮のために、それなりに複雑な非同期的な制御が必要になっています。

育児記録

お子さんの睡眠や授乳などを簡単な操作で記録し、グラフでわかりやすく振り返ることができる機能です。 この機能のみ、 Firebase Cloud Firestore を利用しています。 Firebase Cloud Firestore の採用には以下のような利点がありました。

• サーバーの実装が不要
• クライアントの実装が簡単
• 非同期通信で待ち時間なし
• 入力した記録をパートナーにリアルタイムに同期できる

リリース当初の時間が無い中では、工数削減、品質向上に非常に役立ったと思います。 ただし、育児記録機能と他機能の連携を進める上で障害になってきているため、将来的には独自のAPIに置き換えることになりそうです。

離乳食

離乳食の進み具合を記録したり、時期にあった調理法を探せる食材リスト機能があります。

カレンダー

家族の予定を一つのカレンダーで共有できます。 また、思い出として写真をアップロードし、簡易的なアルバムのようにする機能があります。

パートナー共有

上記全ての機能はデータを家族内で共有できるようになっています。

アーキテクチャー

アーキテクチャーはMVVMとしています。 ただし ViewController から ViewModel の接続はメソッドコール、 ViewModel から ViewController の接続はクロージャーで、Rx等によるバインディングを用いていないので一般的なMVVMとは異なるかもしれません。 Viewはほぼ UITableView で構成されており、Viewの更新は UITableView のリロードですることが多いため、個別のデータをバインディングするメリットを感じなかったためにこのような構成になっています。

また、ViewControllerの階層化を積極的に使っています。 コンテナを使って階層化することによってView Controllerの肥大化を防ぐようにしています。

まとめ

MAMADAYSのモバイルアプリは2019年10月にリリースして以来コンスタントにアップデートを続け、離乳食、カレンダー、妊娠週数と大きめの機能を追加してきました。 今後もユーザーさんの声を聴きながら進化を続けていきます。 開発者としてはコードをできるだけシンプルで変更に強い状態に保つことで、開発速度と品質でサービスに貢献したいと考えています。

Nxを使ってnpm projectをmonorepo管理した話

DELISH KITCHEN RS事業部では、小売向けにサイネージやチラシ等のサービスを提供しています。 従来は、そのサービスの管理が出来るWebアプリのみ運用していたのですが、新たに広告配信設定用のWebアプリが必要になりました。 そこでNxを使って、2つのアプリをmonorepoで管理し、コードの共通化を計りました。

Nxとは

Nxはmonorepo用の拡張可能な開発ツールセットです。堅牢なCLI、キャッシュシステム、依存性管理などを提供すると共に、Jest、Cypress、ESLint、Prettierなどのモダンなライブラリの統合をサポートしています。元GoogleのAngularチームにいたメンバーによって創設されたNrwlが開発しており、Googleは全てのプロジェクトをmonorepoで管理しているという有名な話がありますが（詳細は知りません）、それと似た開発体験を提供することを目的に開発されているそうです。

Nxへの移行

RS事業部で開発しているWebアプリはAngularで作られており、それをまずNxに移行しました。

従来のディレクトリ構成

NxはAngularをサポートしているので、移行自体は簡単でした。 まずNxで新しくworkspaceを作成します。

npx create-nx-workspace --preset=angular

その後、既存のアプリのコードをapps以下に配置し、angular.jsonやtsconfig.json、tslint.jsonなどの設定ファイルを修正し、既存のアプリで使用していたサードパーティのライブラリ（dayjsなど）を新しいworkspaceに追加して、移行を完了しました。

現在のディレクトリ構成

※ 現在のcreate-nx-workspaceは、テストフレームワークにデフォルトでJestとCypressが選択されており、AngularデフォルトのKarma、Protractorを使用したい場合は、別途以下のコマンドでアプリを作成する必要があります。

nx generate @nrwl/angular:app myapp --unit-test-runner=karma --e2e-test-runner=protractor`

ライブラリの作成

複数のアプリから共通のコードを使用するために、ライブラリを作成します。

nx generate @nrwl/angular:lib shared

上記のコマンドでlibs配下にsharedディレクトリが作成されます。

今回は例としてSampleComponentをライブラリに作成します。

nx generate component sample --project=shared

作成したら、shared.module.tsのexportsにSampleComponentを追加します。 次に、アプリからSampleComponentを使用するために、tsconfigにパスを追加します。

{
  ...
  "compilerOptions": {
    ...
    "paths": {
      "@lib/shared": ["libs/shared/src/index.ts"],
      "@lib/shared/*": ["libs/shared/src/lib/*"]
    },
    ...
  },
  ...
}

あとは使用したいモジュールでimportすると、使用可能になります。

import { SharedModule } from '@lib/shared';

@NgModule({
  imports: [SharedModule],
  bootstrap: [AppComponent]
})
export class AppModule {}

また、直接SampleComponentをimportしたい場合は、以下のコードで可能です。

import { SampleComponent } from '@lib/shared/sample/sample.component.ts'

CSSの共通化

上記で作成したsharedライブラリに共通のCSSも置いて、使えるようにします。 場所はどこでもいいのですが、私はlibs/shared/src/stylesにファイルを配置しています。

html,
body {
  height: 100%;
}

body {
  margin: 0;
  font-family: 'Helvetica Neue', Arial, 'Hiragino Kaku Gothic ProN', 'Hiragino Sans', Meiryo, sans-serif;
}

そしたら、angular.jsonの、このスタイルを適用したいアプリの箇所に以下を追加します。

"app": {
  "projectType": "application",
  ...
  "architect": {
    "build": {
      ...
      "options": {
        ...
        "styles": [
          "libs/shared/src/styles/styles.scss", // この部分
        ],
        ...
      }
    }
  }
}

また、partialファイル(_mixin.scssなど)をsharedに置いて参照することも可能です。 これも好きな場所にファイルを配置して、angular.jsonでパスを指定するだけです。

 "app": {
  "projectType": "application",
  ...
  "architect": {
    "build": {
      ...
      "options": {
        ...
        "stylePreprocessorOptions": {
          "includePaths": ["libs/shared/src/styles/partials"], // この部分
        },
        ...
      }
    }
  }
}

ここで注意なのが、指定するのはファイルパスではなくディレクトリパスということです。こうしておくことで、partials以下にあるファイル(_mixin.scss)を@import 'mixin'という形で使うことができます。

CI/CD

monorepoにするとCI/CD周りも変わってきます。おそらく多くの人が、変更があったアプリ、またはライブラリだけをテスト、デプロイしたいと考えると思います。Nxはその希望を叶えてくれます。Nxにはaffectedコマンドがあり、変更の影響があるプロジェクトのみに対してテスト、ビルドを実行する機能があります。

CI/CDはGithub Actionsで行っていて、実際のワークフローを例に紹介したいと思います。Github ActionsはPull Requestを作った時とdevelop、masterブランチにマージされたタイミングで走るように設定しています。

例えば、Pull Requestを作った時に走らせるビルドは以下のように設定しています。

name: build
on: pull_request
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - uses: actions/setup-node@v1
        with:
          node-version: '12.x'
      - name: Run cache/restore node_modules
        uses: actions/cache@v1
        with:
          path: node_modules
          key: v1-${{ runner.os }}-npm-${{ hashFiles('package-lock.json') }}
      - name: Run build
        run: make affected-build BASE=${{ github.event.pull_request.base.sha }} // nx affected:build --base=${BASE} を呼んでるだけ

ここで、affectedはbase optionでブランチやコミットIDを指定でき、baseとHEADの差分から、影響のあるプロジェクトを判断します。その仕様から、actions/checkout@v2ではfetch-depth: 0を指定することで、コミット履歴を全部取得するようにしています。

またmasterにマージされた際のデプロイは以下のように設定しています。

name: deploy
on:
  push:
    branches:
      - master
jobs:
  build:
    ...

  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Run cache/restore dist
        uses: actions/cache@v1
        with:
          path: dist
          key: v1-${{ runner.os }}-dist-${{ github.run_number }}
      - name: Run deploy
        run: |
          app_paths="dist/apps/*/"
          if ! ls -d $app_paths &>/dev/null ; then
            exit 0
          fi
          for app_path in $app_paths; do
            app=$(basename "$app_path")
            if [ "$app" == "appName1" ]; then
            elif [ "$app" == "appName2" ]; then
            fi
          done

差分があるもののみデプロイするという仕組みはNx自体にはないので、buildフェーズで生成されたものをデプロイするというスクリプトを書いて対応しています。

現在のデプロイの仕組みだと、masterに入ったものは全部対象になってしまうので、リリース前に全プロジェクトの確認が必要になってしまいます。またmasterに入ってもリリースのタイミングは調整したいこともあるでしょう。monorepoにして一番の課題で、依然他に良いフローがないか検討中の部分です。

まとめ

今回はNxを使ってnpm projectをmonorepo管理した話をしました。Nxを使ったComponentやCSSの共通化、CI/CDの運用とかは普段聞く機会がないので、誰かの参考になれば幸いです。

MAMADAYSのサービスとバックエンドシステムのお話

自己紹介

はじめまして && あけましておめでとうございます。MAMADAYS開発部長をやっている齊藤です。

開発部長という肩書きですが、マネージメント業務だけではなく、モバイルアプリ開発以外を守備範囲としたユーティリティプレイヤーもつとめ、若い子たちと一緒に草を生やす作業に勤しんでいます。

座右の銘は『枯れた技術の水平思考』です！

閑話休題

弊社オウンドメディアの every.thing にも、CTOのid:kajidaiとの対談が掲載されていますので、時間に余裕がある方は見ていただけると嬉しいです。

【前編】エブリーCTOが聞く！MAMADAYS開発部長のルーツは音楽！？ゲーム開発から組織づくりにも携わってきたこれまでの経歴とは ｜ every.thing（エブリシング）｜ エブリーのこと、ぜんぶ

【後編】エブリーCTOが聞く！『MAMADAYS』を主力事業に成長させたい！と語るMAMADAYS開発部長の今後の展望 ｜ every.thing（エブリシング）｜ エブリーのこと、ぜんぶ

はじめに

App/Webのリリースから1年余りが経過した MAMADAYS の、サービス全体像とバックエンド観点でのシステム紹介を行います。

個々の詳細は、後日、若者たちが書いてくれると思いますが、本記事で少しでも MAMADAYS の開発に興味を持っていただけると幸いです。

MAMADAYSのサービス全体像

MAMADAYSでは『子育てを通じて喜びと幸せを感じられる社会に』をミッションに掲げ、出産・育児に関する課題を解決するため、プロダクト開発を行っています。

出産・育児の課題は多岐に渡るため、複数の機能を提供する多機能アプリとして展開しつつ、データを活用して1人1人に最適化した情報をお届けできるよう日々改善を重ねています。

corp.every.tv

MAMADAYSのバックエンドシステム全体像

基本的な部分は DELISH KITCHEN と同じような感じにしていますが、以下のようにいくつか異なっている点もあります。

• コンテナオーケストレーションとして、AWS ECS ではなく Kubernetes (AWS EKS) を利用
• CI/CDとして、CircleCIではなく github Actions や AWS CodeBuild を利用

リリース時期やサービス規模の違いによりそのタイミングで最適と思う選択であり、どの技術が優れているとかではないです。

利用サービス

MAMADAYSで利用している基盤や外部サービスは以下の通りです。

• インフラ
  • AWS EKS
  • AWS Aurora
  • AWS S3
  • AWS CloudFront
  • AWS Route53
  • Elasticsearch
• ログ/分析
  • fluentd
  • BigQuery
  • metabase
• 開発/運用
  • github
  • github Actions
  • AWS CodeBuild
  • terraform
  • kustomize

APIサーバ

iOS/Android/WEBなど、クライアント向けに提供しているAPIサーバです。

DELISH KITCHEN 同様に MAMADAYS でも、Golang の軽量フレームワークである echo を利用しています。

テスト周りでは、私が元々 Rails 厨だったこともあり Rspec っぽい記述ができる GoConvey を利用し、カバレッジも Codecov で計測してたりします。

• 利用システム
  • Golang
  • echo
  • GoConvey
  • Codecov

WEBシステム

WEBにおけるMAMADAYSサービスを提供しています。

記事の入稿やお客様からのお問い合わせに対応するためのツール類も含め、MAMADAYSのWEB面は React のフレームワークであるNext.jsを利用しています。

リリース1年が経過した頃、開発メンバーが増えたこともあり TypeScript 化を行ったのですが、ものすごく手軽に対応できたので Next.js 様様です。 『もしかして：Nuxt.js』と毎回問われてしまうぐらいググラビリティが低く、検索するたびに悲しい気分になりますが、それはそれで愛おしいです。

• 利用システム
  • Next.js
  • Node.js

検索システム

記事/動画情報の検索を提供するサーバです。

検索エンジンには Elasticsearch を利用しています。

元々は使用したいプラグインが対応されていなかったため独自運用していたのですが、AWS Elasticsearch Service のバージョンも上がったので、マネージドに移行することを検討しています。

• 利用システム
  • Elasticsearch

最後に

かなりざっくりとした内容となってしまいましたが、当たり前の技術を当たり前に、それでいて新しい風を取り込みながら MAMADAYS は開発・運用しています。

まだまだ成長途上のサービスですので、これからも世の中の出産・育児に対する課題に技術でどう解決していくかを考えながら取り組んでいこうと思います。

ここまでお読みいただき、ありがとうございました。

2020年の振り返りと2021年のこと

こんにちは、エブリーでCTOをやっている梶原と申します。

1年の始まりということで昨年の振り返りと今年の取り組みについて書きます。

はじめに、エブリーが提供している中でエンジニアが関わっているプロダクトをご紹介すると、 食の課題解決に取り組むレシピ動画サービスの「DELISH KITCHEN」と育児の課題解決に取り組むママ・パパの365日に役立つ情報やサービスを提供する「MAMADAYS」の２つのプロダクトを開発しています。

2020年の振り返り

開発組織について

まず自分自身の変化として、2020年の春くらいに当時見ていた事業を引き継いで開発業務に専念することになりました。そして開発組織については、当時、各事業部にぶら下がっていたエンジニアチームを、開発本部というエンジニア組織に統合することにしました。エンジニア全体での勉強会やエンジニアブログを開始したのも昨年です。結果、課題としてあったエンジニア間の連携の希薄化、エンジニアのキャリアサポートや適切なアサインメントは徐々に解消されつつありますが、まだまだこれからなので今年も課題の解消に取り組みます。

データに関する取り組み

これまではDELISH KITCHEN事業部のみに存在したデータエンジニアリングの組織を全社の横断組織として再編し、組織のミッションとして「DIKWモデル」の構築を掲げました。 データ基盤からBIツールを用いて各種分析業務は行っていましたが、中にはExcelやスプレッドシートで独自に管理、集計、分析されていたり、手動データを打ち込んでいるもの、データの定義が扱う人により違うものなど、属人的な扱いのデータが様々あり非効率な部分が多くありました。 これらの課題に対してデータ基盤への集約と集計のとりまとめと実施を行い、結果としてデータによる意思決定が格段に進みました。

アーキテクチャの再設計

DELISH KITCHENアプリはリリースから4年が経過して、新しくジョインするエンジニアの初期の学習コストや開発スピードが徐々に低下しつつあり、先んじて対策を打つという意思決定を行いリファクタリングとリアーキテクチャリングを開始しました。

2021年に向けて

データに関しては、集約のフェーズが終わり、次はデータの利活用のフェーズです。機械学習を用いたプロダクトの改善や事業者との取り組みをこれまで以上に推進していきます。プロダクト開発では、息の長いプロジェクトになるであろうリアーキテクチャプロジェクトを昨年に引き続き取り組んでいきます。

また今年は小売のデジタル化が更に進む１年になるであろうと考えています。これまでにもアプリ内のチラシ・クーポン機能による集客支援、スーパー内に設置したデジタルサイネージによる店内販促、ライブコマースによるオンライン購買活動支援など取り組んできました。今年はこれらのものをベースに小売様と協力して新しいユーザ体験を生み出すべくプロダクト開発をできたらと考えています。

2021年もよろしくお願いいたします！