シェア
はてブ
2024年6月28日、29日の2日間にわたって、ファインディ株式会社が主催するイベント「開発生産性Conference」が、開催されました。本カンファレンスは、虎ノ門ヒルズフォーラム（東京）にて実施され、一部のセッションはオンライン配信も行われました。
本記事では、オンラインでも配信されたセッションのうち、株式会社ALGO ARTISでVPoEを務める武藤悠輔さんと、技術顧問の山口徹さんによるセッション「最適化ソリューションサービスにおける VSM分析とチームトポロジー」の内容をお届けします。
DeNAからスピンオフして誕生したALGO ARTISでは、社会基盤の最適化を目的に計画に特化したAIとプロダクトを開発しています。顧客ごとに最適化アルゴリズムとUIをカスタマイズしており、労働集約的かつプロジェクトが長期化することが課題となっていました。本セッションでは、課題解決に向けて取り組んでいるバリューストリームマッピング（VSM）分析とその課題解決に向けた取り組みについてお話しいただきました。
■プロフィール
武藤 悠輔（むとう ゆうすけ）/ @muteua
株式会社 ALGO ARTIS 取締役 / VPoE
スマホアプリ制作会社を起業しCTOとして従事。その後 DeNAに入社し、認証・認可基盤を中心にさまざまなプロダクト開発を行なった。2021年7月にDeNAからスピンオフしてALGO ARTISを設立する際に取締役に就任し、現在に至る。ALGO ARTISでは、「社会基盤の最適化」の実現を目指し、VPoE として組織づくりからプロダクト開発まで幅広く推進を行なっている。
山口 徹（やまぐち とおる）/ @zigorou
株式会社 ALGO ARTIS 技術顧問
東京工業大学中退後、2003年にWeb制作会社でエンジニアキャリアを開始。2005年にガイアックスに入社し、リードエンジニア、マネージャーを務める。2007年にサイボウズ・ラボでR&Dエンジニアとして研究に従事。2009年にディー・エヌ・エーに入社し、Mobageやスマートフォンアプリの開発を推進。2015年に事業副本部長、2016年に専門役員に就任。2018年にスポーツ事業本部システム部部長に。2020年にベルフェイス入社、CTO兼CPOを兼務し、2021年に取締役執行役員就任。2023年より現職である株式会社タイミー入社、執行役員CPOを担当。個人として、マギステル代表取締役で複数の技術顧問を兼任。
最強チームが目指す、社会基盤の最適化
武藤：株式会社ALGO ARTISの取締役VPoEをしている武藤と申します。本日はよろしくお願いいたします。私は以前にスマホゲームの会社を起業して3年ほどCTOとして活動した後、DeNAに転職しました。DeNAでは新規事業を担当していて、その事業がスピンオフしてALGO ARTISが誕生したと同時に取締役VPoEに就任し現在に至ります。本日はよろしくお願いいたします。
山口：株式会社ALGO ARTISで技術顧問を務めている山口徹と申します。ネット上では「zigorou」として活動しています。長くWeb系のサービス開発に携わってきていて、DeNAではゲームプラットフォーム開発のリードを務めていました。DeNAを退職してからはスタートアップのCxOとして活動しており、現在は株式会社タイミーのCPOを本業としつつ、副業でプロダクト顧問や技術顧問もしています。
本日は進行役を務めます。よろしくお願いいたします。
本セッションは下記の流れでお話しします。
山口：本題に入る前に、ALGO ARTISについての紹介をお願いします。
武藤：はい。ALGO ARTISは「社会基盤の最適化」をビジョンに掲げ、サプライチェーンにおける計画業務の最適化を推進している会社です。
武藤：計画業務はざっくりと分けて「計画立案」と「計画運用」といった二つの要素で成り立っています。前者は囲碁や将棋よりもはるかに多い組み合わせの中から計画を立てる必要があり、その複雑さゆえに属人化しがちです。後者では多数のステークホルダーと連携して情報を共有し、時には交渉しなくてはいけません。
武藤：私たちはこれら二つの業務を最適化アルゴリズムとUIで改善する最適化ソリューションを開発し、属人化の解消と収益性の向上を実現しています。
計画を最適化することで生まれるインパクトとしては、大企業2,228社、中小企業を含めて45万社の計画業務における技術継承の課題を解決するだけでなく、売上原価の数%を削減できるとわかっています。企業活動の基本調査などによると売上原価は年間で約250兆円ほどあり、仮に1%しかコストを削減できなかったとしても、年間2.5兆円規模のインパクトを出すことができます。計画を最適化することでCO2排出量を削減できた事例もあり、環境負荷の低減にも貢献できるソリューションだと言えます。
なお、最適化ソリューションの運用事例としては、関西電力や東北電力といった電力会社や、日本触媒や日本製紙といった大手企業にも導入いただいています。
武藤：最適化アルゴリズムの最強チームについても紹介させてください。ALGO ARTISはAtCoder Heuristic Contest上位者の所属数が国内1位であり、AtCoder社が発表した「AtCoder 競技プログラマー就職企業人気ランキング2023」のレーティング別ランキングでは2位を獲得しています。これらの点から、ALGO ARTISの最適化アルゴリズムは最強チームだと自負しております。
ALGO ARTISが抱えていた「全社WIP制限」と「リソース負荷の偏り」
山口：本日の本題に移りたいと思います。「最適化ソリューションサービスの課題」についてお話いただけますか。
武藤：はい。まずはALGO ARTISが開発している計画最適化ソリューション「Optium」について紹介します。
「Optium」では、お客様ごとにUIと最適化アルゴリズムをカスタマイズしたWebアプリケーションを提供しています。化学系の生産計画を例として挙げると、UI上にガントチャートのようなものがあり、日々の動静や実績データを入力したあと、計画を立て直す必要が出てきたとします。そこで最適化ボタンをクリックすると、サーバー側にリクエストが飛び、マスターデータや入力データを最適化アルゴリズムに飛ばして最適化を実行。その結果をサーバーに返却し、ユーザーの手元に反映するといった流れです。
武藤：基本的に一社ごとに作り込むため導入難易度が非常に高く、開発～導入までにかかる期間は、おおよそ1年～1.5年ほどです。
武藤：各フェーズで何をしているのかについてお話しすると、最初のアセスメントでは最適化アルゴリズムを導入した際の効果について簡単な見積りを出します。PoCでは業務を回すために必要な仕様を検証して、プロトタイピングに入ってからは、お客様の手元で最適化アルゴリズムを回せるような環境を提供します。その後の本開発では、UIを含めた最適化ソリューションをお客様に使っていただいて、フィードバックを受けながら実際に使えるレベルのものに磨き上げていきます。
このサイクルにおいて、ALGO ARTISでは二つの課題を抱えていました。一つ目は全社WIP制限です。アルゴリズムエンジニアとソフトウェアエンジニアのキャップがあるため、全社で同時並行できるプロジェクト数には制限があります。
二つ目がリソース負荷の偏りです。プロダクトの特性上、会計年度ごとの予算の都合でプロジェクトの開始タイミングが偏りやすく、似たようなフェーズで複数のプロジェクトが進むことになります。アルゴリズムエンジニアは基本的に全てのフェーズに携わっているため、案件数が増えていくと自然と平準化されていきます。しかし、本開発をメインとしているフロントエンドやサーバサイドのエンジニアは、人員が必要な時期が重なってしまうため、リソース効率が悪くなってしまうのです。
山口：一般的には開発生産性やフロー効率を高めるといった言い方をしますが、ALGO ARTISの場合はリソース効率の最適化がネックになっているのですね。ちなみに、各エンジニアは基本的に一つのプロジェクトを担当する形なのでしょうか？
武藤：アルゴリズムエンジニアは一つのプロジェクトに注力することが多いですが、フロントエンドやサーバサイドのエンジニアは基本的に兼務しています。
プロジェクト長期化の要因はリードタイムの長さ
武藤：ここからは、ALGO ARTISでVSMを実施した事例についてお話します。
武藤：まず導入プロジェクトの本開発における開発フローについてお話しすると、下記スライドのようなフローで開発を進めています。
武藤：VSM分析をするにあたり、ヒアリングによって最適化アルゴリズムの更新が必要だとわかった場合のフローに着目しました。
最適化アルゴリズムの更新が必要な場合、要件が不十分だったことが原因だと考えられます。要件を整理するためには、データスキーマを更新しなくてはいけません。そこで最適化アルゴリズムだけ改修できれば良いのですが、フロントエンドやサーバサイドはスキーマのインターフェースを決めてから開発することが多いため、それらも改修する必要があります。フロントエンドとサーバサイドの改修・開発が終わったら、デプロイ、DBマイグレーションして、お客様に届ける。目安としては、本開発中に10回以上はこのサイクルを回すイメージです。
山口：ここでいうデータスキーマの更新は、一般的なものとは異なりますよね。どんどんインクリメンタルに変えていくというか。
武藤：そうですね。一般的には、最初にDBを設計したら途中で変更はあるものの、そこまで回数は多くないでしょう。しかし、最適化アルゴリズムの場合は、後半に行けば行くほど頻繁にスキーマの変更が入ります。
開発フローをVSM分析したところ、最適化アルゴリズム開発のリードタイムが2日なのに対して、フロントエンドやサーバサイドの開発では5日かかっていることがわかりました。
武藤：フロントエンドやサーバサイドは、最適化アルゴリズムの更新を取り込んでからリリースするため、待ち時間が発生してしまいます。それにより、リードタイムが長くなりやすいことが影響していたようです。
山口：フロントエンドとサーバサイドは並列して開発を進めていて、その間に最適化アルゴリズムの開発も並列進行しているのですね。
武藤：そうですね。場合によっては、フロントエンドとサーバサイドの開発を進めている途中でスキーマの変更が入ることもあります。
ちなみに、スライドでは全体のリードタイムが10日と書いてあるのですが、実際には営業日換算で2週間程度で、実際に作業している時間は数時間～1日程度です。
VSM分析を経て行ったチームトポロジーの見直し
武藤：ここまでの話を整理すると、プロセスタイムに対してリードタイムが長くなっていることで、プロジェクトが長期化しやすくなっていると。それによって全社のWIP制限にも引っかかるため、大きな課題となっていました。
ここからは、VSM分析の結果をもとにチームトポロジーを再検討したことについて説明します。
理想のVSMは、リードタイム長期化の要因であったフロントエンドとサーバサイドの開発を取り除き、アルゴリズムエンジニアだけで最適化アルゴリズムをリリースできる状態にすることだと考えました。
武藤：理想のVSMを実現するための取り組みとしては、スキーマが変更してもフロントエンドとサーバサイドを改修することなくリリースできるよう、プラットフォーム化を推進する必要がありました。
具体的には、最適化アルゴリズムとUIをアドオンに開発し、独立したデプロイフローを持てるプラットフォームを設計したいと考えました。サーバサイドはデータスキーマを疎結合化し、利用者がスキーマを定義できる状態にすることで、アルゴリズムエンジニア自身がスキーマを更新できるようにしたいなと。フロントエンドはユーザーにガントチャートのような形式でデータを見せる際にデータスキーマが必要となるため、そのUIとデータの間に抽象レイヤを入れることを設計時に検討しています。
山口：スキーマレスにはできないのですか？
武藤：私たちは100年スケールでご利用いただくことを目指して開発しているため、開発担当者が変わっていくことも想定すると、スキーマレスで成り立たせるのは難しいと考えています。
山口：なるほど。続きをお願いします。
武藤：ありがとうございます。実際に作っているプラットフォームのイメージが、下記スライドの右図です。
武藤：セキュリティやユーザー管理、インフラ構成といった部分をBackend Coreとして一つのプラットフォームにまとめて、最適化アルゴリズムやUIはデータスキーマを疎結合化した上でアドオンに生やすといった設計にしています。
山口：ちょっとしたSaaSのような感じにしていると。色ごとに分かれていて、テナントのようになっているのですね。
武藤：そうです。お客様それぞれに適したUIと最適化アルゴリズムを使えるような認可設定をするといったイメージですね。この状態まで来ると、理想のVSMを実現できるのですが、チームトポロジーも見直していく必要があります。
VSM分析でターゲット状態と現状を見た時、現状ではストリームアラインドチームの中に、コンサル、アルゴリズムエンジニア、フロントエンドエンジニア、サーバサイドエンジニアの全員が入っている状態です。
しかし、プラットフォーム化すれば、データスキーマの疎結合化によるデプロイフローの分離、マイクロカーネルアーキテクチャによる最適アルゴリズム・UIのアドオン化が可能になります。
山口：プロジェクトベースの開発が並列で進行していて必ず終わりがあるのに、ストリームアライドチームと表現しているのは面白いですね。
ふと思いついたのですが、本来はお客様を顧客をイネーブリングする、という考え方が適しているのかもしれません。
武藤：そうですね。表現については常に悩んでいるところではあるので、後ほど私の方でも考えてみます（笑）。
話を戻すと、プラットフォームチームとしてサーバサイドエンジニアとフロントエンジニアがいる状態で、Backend Coreをストリーマアラインドのチームが活用する形になります。フロントエンドなどで開発が難しい部分については、コンプリケイテッド・サブシステムチームとして有期で入って出ていくと。コンプリケイテッド・サブシステムチームについてはアウトソースする案が出るなど、少しずつリソースの負荷分散を進めています。
山口：なるほど。ここまでの話をまとめると、データスキーマの定義をエンドユーザーが変更できるようにプラットフォームを開発し、データスキーマのマッピングもBackend Coreで提供できるようにすると。UIについては、Backend Coreの上で乗ってくるようなコンプリケイテッド・サブシステムチームとして、そこはフロントエンドエンジニアが単独で開発できるようにするのが理想系ということですね。
中長期的なプロダクト戦略で、全社WIP制限を超えた価値提供を目指す
武藤：最後に「さらなる課題解消に向けたプロダクト戦略」についてお話します。
チームトポロジーの再編によって、プロジェクトの長期化を解消することが期待できますが、アルゴリズムエンジニア数のキャップから生じる全社WIP制限にはまだ解除されていない状態です。
山口：これは経営課題でもありますよね。売り上げを上げるなら複数のプロジェクトを同時に進行した方が良いし、プロジェクトの単価も上げたい。加えて、できるだけ短期間で運用段階まで持っていきたいですよね。
武藤：そうですね。この点は中長期的なプロダクト戦略で乗り越えていきたいと考えていて、現在は各業界に特化した計画運用の業務をサポートするパッケージ型製品「Planiumシリーズ」の開発を進めています。2024年1月には、第一弾として化学業界に特化した「Planium｜化学」をリリースしました。
山口：「Planium」では、最適化アルゴリズムの開発はしていないのですか？
武藤：シンプルな最適化アルゴリズムは開発していますが、ここでポイントとなるのは、お客様ごとのカスタマイズはしないという点です。計画業務において、計画立案についてはお客様ごとのカスタマイズが必要となります。しかし、計画運用は業種ごとに型化できるとわかったため「Planium」の開発に踏み切りました。
プロダクト戦略としては「Optium」で開拓したマーケットを「Planium」でSaaS化し、全社WIP制限を超えた価値提供の実現を目指しています。Backend Coreを基幹システムとしつつ、そのUI上で「Planium」の新サービスを展開していくイメージですね。
山口：ちなみに、スライドでいうと、業務軸がバリューチェーンでその中の左上（調達計画）が川上になっているというイメージですか？
武藤：そうですね。
山口：川上と川下だと、どちらの方がコスト削減できるのでしょう？
武藤：基本的に大きな金額が動いているのは調達計画ですが、最適化することで改善できる金額の大きさは業界ごとに異なります。
山口：川上ほどコスト削減できて、川下ほど売り上げの向上が期待できるのではないかと思ったのですが。
武藤：確かに、川下の販売計画では売り上げ向上といったところにも関わってきますね。ただ、現状では生産計画や配船計画といった部分の最適化をメインとしています。
山口：一つひとつをバーティカル的に攻めていくスタイルを取られているのですね。
武藤：はい。「Optium」で実績を積んでドメイン知識を獲得した後に「Planium」を提供し、各マーケットごとにSaaS化を進めて、シナジーを創出していきたいなと。
山口：BtoB SaaSでお客様ごとのカスタマイズが必要な事業をされている方には、参考になったのではないでしょうか。
最後に、武藤さんより一言お願いします。
武藤：私たちは、生活を支える事業を行っている会社の計画業務の最適化に全力で取り組んでいきたいと考えています。
事業が順調に成長していて、3年前にはフルタイムメンバーが4名だった組織も、現在は約50名の規模になりました。（2024年6月時点）事業をスケールさせるためにも、核となってくださる方の採用に注力しています。Happy Hourというイベントも開催していますので、関心を持っていただけたなら、ぜひご参加いただけると嬉しいです。
本日はご清聴ありがとうございました。
