3日で開発&リリース！データサイエンティスト×エンジニアのアジャイル爆速チーム術

はじめに

わずか3日で開発して稼働開始、そして1年間トラブルゼロ。
普通なら半年〜1年かかる開発も、Insight Edgeのデータサイエンティストとエンジニアは、ワンチームで動き、爆速で価値をクライアント企業に届けています。

仕様書の山も、開発ベンダーとの往復メールもありません。
モデルを作ったらアジャイル方式で即アプリ化し、
クラウドにデプロイして、翌日にはクライアントが使い始めることもあります。
この記事では、そんな爆速開発を可能にしているデータサイエンティスト×エンジニアの共同開発の事例を3つ紹介し、最後にポイントをまとめます。

事例1：売上予測アプリを2ヶ月でリリース

PoCで作成した売り上げ予測モデルが一定の性能を満たし、クライアントから「現場ですぐに試したい」という要望が寄せられました。早く、安く、安全にアプリ化する必要がある状況です。

そこでまず、データサイエンティストがざっくりとしたUI案とアーキテクチャ図をパワポで作成しました。それをエンジニアに見せ、「こういうものを作れないか」と相談します。
すると、エンジニアはすぐにAWSのアーキテクチャ案と工数・運用費の見積もりを返してくれました。そのスピード感もあって、提案はスムーズに承認されました。

開発は同じGitリポジトリ上で進めました。
データサイエンティストは予測モデルを呼び出すクラスのインターフェースとサンプルコードを、実装前にMkDocsでドキュメント化して事前に共有。そうすることで、エンジニアとデータサイエンティストはそれぞれの担当部分を並行して開発できました。

Daily MTGは合同で行い、週次でクライアントとのMTGでフィードバックを受け、それを即反映。ベンダー向けの仕様書の山を作ることもQAのラリーを大量に行う必要もなく、アジャイルな形で進められました。

結果、プロジェクト開始からわずか2ヶ月で現場利用が開始され、クライアントの満足度も高く、ベンダー委託時にありがちな遅延やコスト増は一切ありませんでした。

事例2：3日で完成！S3＋Lambdaだけの軽量予測システム

ある案件では、「UIは不要、最低限の機能で良い」という要望がありました。クライアントはとにかく早く動くものを試したいという状況でした。

そこでデータサイエンティストは、わずか一行で要件をエンジニアに伝えました。

「S3にファイルを置いたらLambdaが起動して、予測してS3に結果を返す感じで作りたいんです」

エンジニアはすぐ設計に着手し、S3へのアップロードをトリガーにLambdaが動き、Fargateで予測を実行して結果を保存するというシンプルな構成を実装しました。
※実行時間がLambdaの上限を超えて必要な処理が含まれていたため、Fargateも含む構成になりました。

わずか3日でシステムは稼働を開始。開発・運用コストがあまりにも低かったため、クライアントには驚かれました。運用開始から1年が経過しますが、障害は一度もなく、コード修正も即日で対応できています。

事例3：10時間かかっていた遺伝的アルゴリズムを並列分散処理で高速化

PoC中の最適化計算で、遺伝的アルゴリズムの実行時間が長すぎる（10時間！）という課題がありました。アルゴリズムの根本的な改良には時間が足りない状況です。

そこで、データサイエンティストは既存コードと「ざっくりした並列化のイメージ図（Master-Slave方式）」をエンジニアに共有しました。エンジニアはコードを読み込み、即座に並列分散処理を実装。

初版ができた後には、こんな最高な会話もありました。

結果として計算時間は大幅に短縮され、実用化に必要とされた処理速度を余裕で達成。使いやすさも向上。アプリへの移行も非常にスムーズに進みました。

こちらの事例については、別の記事で技術面を詳しく解説しておりますのでぜひご覧ください↓

10時間かかっていた遺伝的アルゴリズムをAWS Lambdaで高速化

爆速開発を可能にする3つの秘密

このスピードを実現できるのは、大きく3つの要因があると考えています。

1つ目は「ワンチームで動く」こと。
データサイエンティストとエンジニアが同じリポジトリでプルリクを送り合い、Daily MTGも合同で行うため、仕様変更や方針転換が即座に反映されます。
Insight Edgeのコアバリューに「みんなでやる」というものがありますが、まさにそのバリューに則って動いています。

2つ目は「お互いの領域を知る」こと。
データサイエンティストはAWSやGCPの資格を所持しているメンバーも多く、アーキテクチャ図もある程度は描けます。一方でエンジニアはAIやアルゴリズムに理解があり、遺伝的アルゴリズムのコードもすぐに理解し改良できました。この「浅くても相手の言葉がわかる」関係が、やり取りを高速化します。

3つ目は「まず使ってもらう」こと。
完璧なモデルを机上で作り上げるよりも、現場に投入して改善プロセスを回す方が結果的に現場にとって良いモデルができる。小さく作って早く届け、そこから進化させるという考え方です。