ABEJA Tech Blog

中の人の興味のある情報を発信していきます

ABEJA システム開発グループと取り組みのご紹介

はじめに

こんにちは、CS(カスタマーサクセス) 統括部の近藤&小笠原です。本日は、CS 統括部のシステム開発グループの仕事について紹介しようと思います。CS 統括部では、お客様の描く将来像をどのようにすれば実現できるかを検討するところから始め、最終的に DS チームの開発したモデルを組み込んでシステムインテグレーション、さらには運用までを行っています。

システム開発グループはその中の主にシステムインテグレーションを担当しますが、お客様の求める状態に繋げるにはどのようなシステム構成を整えれば良いか、を考える為にはエンジニアが直接お客様とコミュニケーションを取った方が良い場合も多いので、最近はプリセールスの段階からセールスチームと一緒にお客様とのミーティングに臨むことも増えてきました。

本記事では、AI の社会実装を行うエンジニアチームの紹介と、これまで多くの本番実装案件を進める中で培ってきたノウハウ・作ってきた仕組みを紹介していきます。ABEJA のエンジニアチームに興味がある方にご一読いただけますと幸いです。

ABEJA におけるシステム開発グループの仕事

どんな仕事?

前述の通り、主な職務は AI を用いたシステム/サービスのシステムインテグレーションになります。

一番シンプルな場合は WebAPI の提供、場合によっては WebUI によるフロントエンドも提供することもありますし、また別の場合にはエッジデバイス上で推論するような iOS/Android のネイティブアプリを作成することもあります。

案件によりますが、システム/サービスのデプロイ先は、弊社の AI プラットフォームである ABEJA Platform / お客様管理のクラウド上 / IoT デバイス / モバイルアプリ (iOS/Android) と多岐に渡ります(稀にお客様管理のオンプレミス環境もあります)。

また、これも前述の通り、最近はプリセールスに同行する(といっても、最近はコロナ過のおかげでオンラインミーティングの場合がほとんどです)ことも増えてきました。

どんな人たち?

f:id:seiro-ogasawara:20211220161740p:plain

DS チームに負けず劣らず色んな人が在籍しています。ABEJA 黎明期に顔画像解析サービスを立ち上げた人や、某 SNS サービスの基盤システムを設計開発運用した人、自転車で日本一周しつつ夜はテントの中でコードを書いて GPS で自分の位置情報をリアルタイムで発信してた人など、ちょっとそんな人いる?と疑うレベルの人であふれています。

全員がテックリードや CTO 級の知識レベルやマインドを持ち、高い視座で複合領域にまたがる課題解決に挑んでいます。

業務の進め方

プロジェクトが始まる際に担当メンバーをアサインし、 PM/DS と共に仕事を進めていくことになります。

以前の DS チームの記事 ABEJA Data Scienceチームと取り組みのご紹介 に詳しいので、そちらを参照していただくと良いでしょう。

アセスメントフェーズ

アセスメントフェーズとはどういうフェーズか?という話は DS チームの記事 に任せるとして、ここではシステム開発グループのアセスメントフェーズへの関りについて述べていきます。

といっても、実はシステム開発グループのアセスメントフェーズでの出番はあまりありません。エンジニアのプロジェクトへの関わりは、エンジニアレビューと呼んでいる要件定義のレビュー会からスタートします(していました)。

アセスメントフェーズを経て、どのような分析を行ってどういった成果をお客様に提供できそうか、がある程度見えてきたところで PM が作成した要件定義書を、お客様に提案する前にエンジニアがレビューする会を開きます。詳細は後述していますので、そちらを参照してください。

DS チームとの作業分担や大まかなインタフェース等もこのタイミングで決定します。

再三の繰り返しになりますが、前述の通り最近はお客様の要望を聞く段階(プリセールス)から PM に同行することも増えてきました。

インテグレーションフェーズ

アセスメントフェーズを経て、DS チームがデータ分析やモデル構築( PoC フェーズ)を行っている間に、我々はシステムインテグレーションの準備/事前検証を進めていきます。

AWS/GCP 等のクラウドサービスを利用する場合はインフラ構築の terraform 化や API の細かい調査/検証を行いますし、あるいは別のサービスを使用する場合も同様に API 等の調査/検証をあらかじめ行っておきます。新規のプロジェクトであれば使用するプログラミング言語やフレームワークの選定等も行います。

この辺りは一般的なシステムインテグレーションと同様ですね。プロジェクト期間が短い場合はプロダクションコードを書きながら検証も同時に行う場合もありますが、その辺も万国共通ではないでしょうか…

事前検証が終わったら、インテグレーションを進めていきます。DS チームからモデルが提供されればそれを組み込むことになりますが、その際ライブラリの形で提供されることはあまりなく、モデルのバイナリと Jupyter Notebook ファイルが渡されて、 Notebook のコード片を元にモデル呼び出しのコード部分をインテグレーションコードに組み込んでいく場合が多いのが、一般的な SI と違うところでしょうか。

インテグレーションが完了したら、テスト/検収を経て納品、という流れは一般的な SI と同様です。保守運用も弊社で行う場合は死活監視等の監視システムを組むことになります。

システム開発グループの特徴

フルスタック

割と広い知識が求められます。

インフラ(ABEJA Platform, AWS / GCP 等クラウドサービス, オンプレ環境等)、インタフェース(WebAPI, WebUI, ネイティブアプリ等)、モデル実行場所(サーバーサイド or クライアントサイド)とシステム提供形態は多岐に渡るからです。

時には IoT デバイス上でリアルタイムに推論を実行し結果をディスプレイに表示したり、あるいは定期的にバッチ実行したモデルの実行結果を RDB に蓄積しておき BI ツールで表示したり。それぞれのプロジェクトでお客様の要望に沿ったシステムを作り上げていく必要があります。

もちろん、全メンバーがこれら全てに精通しているわけではなく、複数メンバーで補い合っているのが現状です。

日々の取り組みや制度

日々行っているインテグレーション開発以外のことについて挙げてみます。
あ、そもそもの前提として、現在 ABEJA はフルリモート可なので、以下の業務も基本的に全てリモートから行っています。

朝会

全社での朝会もあるのですが、それとは別にシステム開発グループメンバーでの朝会も行っています。

メンバー各人の軽いプロジェクト進捗共有と、その他共有事項の確認、後は困りごとなど相談事項があれば解決に向けて動きます。短時間で終わりそうならそのまま相談、時間がかかりそうなら別途 MTG を予約する、といった流れになります。

明示的にスクラムしているわけではないですが、要素を取り入れて活用している感じですね。

エンジニアレビュー

セールス & PM メンバーがお客様に提案する資料を、事前にエンジニアを交えてレビューします。

ここでは主に、

  • 提案するシステム構成は妥当か
    • この構成だと実現が難しい、こうした方がお客様の希望により沿うのでは、など
  • 工数は妥当か
    • そもそも工数見積もってほしい、と依頼されることもあります

といったことを確認します。

最近は前述のようにプリセールスの段階からエンジニアが同行することも増えてきて、その場合は開発グループ内でエンジニアだけでのレビューになることもあります(複数エンジニアの目で見て内容を担保するためです)。

プリセールス

アセスメントフェーズを経てエンジニアレビューを行う、と前述しましたが、そのレビューで大きめの改善提案が発生すると、そこから要件定義を修正して再度エンジニアレビュー、という流れになり、お客様への提案がスピーディに行えない、という事態が発生することがままありました。

だったらプリセールスの段階からエンジニアが同行すれば手戻りが減らせるんじゃない?という考えのもと、行い始めた活動です。

システム開発グループが関わるプロジェクトのフェーズは、PoC の段階から、実運用に向けてのシステムの繋ぎこみの段階まで多岐に渡ります。

PoC フェーズの提案であれば、効果検証のためのミニマムな要件は何なのか、システムを組まないで実現する方法は無いか等、PoC のモデル開発と効果検証に注力できるための実現方法の提案を目指します。一方で、実現運用を見据えた提案であれば、誰がどのくらいの頻度で使うのか、非機能要件はどのレベルかと言ったヒアリングを行い、利用する機械学習モデルの特性と照らし合わせてシステムを考えます。

フェーズや内容によってお客様が期待されている結果はそれぞれなので、お客様が本当に必要としているものを見極め、受注後のシステム構築を見据えて概要設計と見積もりを行います。プリセールスを通して、実はシステムを作る必要が無くても効果検証ができるという事もあり、その分モデル開発の方に注力いただけるというケースもあります。

プリセールスを通して作成したログや概要設計のドキュメントは担当エンジニアが記録し、受注後にスムーズにシステム開発に入れるようになっています。また、受注に至らなかった案件も記録・回覧する事でチームとしての共有認識を持てるようにしています。

f:id:seiro-ogasawara:20211220140823p:plain

社内ツール開発

社内でも積極的に業務効率化を行っています。

不定期に各チームからツール作成の相談が来るので、社内で使用しているツールの API などを使用し、集計・分析用のスクリプトや効率化するためのツールを作成しています。 下記、直近で実装した社内用ツールをいくつか紹介しましょう。

Google スライドのフォント一括変換スクリプト

SlackAPI と GAS を使用し、Google スライドのフォントを一括で変換するためのスクリプトを作成しました。主に提案書作成時の Sales メンバーや PM メンバーが活用しています。

チャットツールの自動翻訳スクリプト

ABEJA にはグローバルなメンバーも多いため、SlackAPI と DeepL を使用し、文章を自動翻訳するためのスクリプトを作成しました。

工数管理ツールの作成

NotionAPI やその他のツールと連携し、メンバーのアサイン状況やプロジェクトの予実を管理するためのスクリプトを作成しました。

f:id:seiro-ogasawara:20211220151525p:plain
自動翻訳スクリプトの動作例

モデル開発テンプレート

ABEJA ではシステムへのモデル組み込みはエンジニアが担当します。

PoC で作成されたモデルはインテグレーションを目的としたモデルではないため、いざ本番システムへ組み込みを行うぞっ!となった際には、本番用のシステムから利用できるインターフェースへ整えるための開発工数が発生します。

この開発工数を削減するため、 Cookiecutter を利用したモデル開発用のテンプレートを作成、利用しています。テンプレートで作成したプロジェクトはシステムから submodule として利用できるインターフェースをモデルに提供することができ、モデル組み込み時のコストを削減することができます。

また、テンプレートを利用することでモデル開発において以下のメリットもあります。

  • ディレクトリ構成の共通化
  • ユーティリティライブラリの提供
  • Lint, Formatter, 単体テスト環境の提供

まだまだ使い勝手がよくない部分もありますが、DS サイドからフィードバックをもらいつつ、日々改善に努めています。

テンプレート利用で作成されるプロジェクトのディレクトリ構成

.
├── conf
├── data
├── docker_files
├── docs
│   └── images
├── notebooks
│   ├── integ
│   │   ├── target
│   │   └── work
│   └── poc
├── scripts
│   └── dev
│       └── docker
├── src
│   ├── abeja_platform
│   └── engine
│       ├── common
│       └── core
└── tests
    └── engine
        ├── common
        └── core

おわりに

本記事では、前回の記事 ABEJA Data Scienceチームと取り組みのご紹介 に対抗して、DS チームの作った機械学習モデルを実際のシステムに組み込んでいるシステム開発グループの業務を紹介しました。

少数精鋭のメンバー、というと聞こえが良いですが、慢性的な人手不足とも言えます…

切実に仲間を募集していますので、もし興味をお持ちいただけたら、是非ご連絡ください。グループメンバー一同、HR メンバー共々心よりお待ちしております。

hrmos.co

参考: 取り扱っている技術スタック

システム開発グループ内で取り扱っている技術スタックを下記にまとめております。ご興味があればご一読ください。

ABEJA System Dev- ABEJA Tech Stack