株式会社カミナシは「ノンデスクワーカーの才能を解き放つ」をミッションに、パソコンやデスクのない現場で働くノンデスクワーカー3,900万人の働き方をITの力でスマートにすることを目指す企業です。同社の提供する現場DXプラットフォーム「カミナシ」は、工場や店舗で行われる現場管理業務をノーコードでアプリにできる現場DXプラットフォーム。製造や飲食、小売など、業界を問わず業務改善や品質向上を実現し、現場のDXに寄与しています。

カミナシの開発組織を牽引するのが、取締役CTOであるHara Toriさん。今回はToriさんに、過去に行った技術的意思決定のなかで印象に残るものを聞きました。

革新的だったコンテナの登場。しかし、採用を見送った

――今回のインタビューでは、過去に取り組んだ技術的意思決定のなかで印象に残るものや、そこから得た学びを話していただきたいです。

まず前々職の、Webブラウザで遊べるゲームを受託で開発・運用する会社で働いていた時代の話をさせてください。その会社では、Webブラウザゲームのデプロイを手作業で行っていました。作業の属人性が高く、手順のミスがあれば障害が発生しかねないオペレーションだったんです。そこで、運用改善のためにデプロイ作業の効率化や自動化を推進しました。

そんな折、2014年にDockerのバージョン1.0が登場したんですよ。Dockerはシステムのデプロイに関連する一連のプロセスを、きれいなインターフェースで提供してくれます。そしてdockerコマンドさえ叩くことができれば、コンテナ上に指定したランタイムを構築してくれます。「私たちの欲しいものが来た！」と、当時は感じました。

でも、コンテナを扱うためのサービスが当時まだAWSにはありませんでした。Kubernetesのプロジェクトがアナウンスされて最初期のバージョンがリリースされたくらいの頃です。プロダクションレベルで使えるオープンソースのコンテナオーケストレーターもなく、オープンソース界隈では既存のジョブスケジューラーに対してコンテナを扱えるインターフェースを追加することを試みていたような時代でした。

自分たちの開発チームでコンテナを管理・運用できる仕組みを構築してDockerを導入するか悩みましたが、結局取り入れずにいったん待ったんです。マネージドサービスが出てきたらすぐ移行できるように、準備をしておきました。その後、2014年の末にAmazon ECSが発表されて、「これだ！」と思いました。

そして、2015年の春にGenerally Availableになった直後に本番環境に導入しました。この事例において、Amazon ECSの登場まで待ったのは正解だったと考えています。エコシステムが整っていない新技術を勢いに任せて取り入れるのではなく、自分たちの組織のスキルセットやリソースなどを鑑みながら妥当な時期まで待てたのは、私の成功体験でした。

――新しい技術が登場した際に、「その技術のエコシステムがどれくらい成熟するまで待つか」は、技術選定における重要な点です。この事例を踏まえて、Toriさんが読者に伝えたいことはありますか？

企業や開発組織の状況次第だと思います。当時の私が所属していたチームはデプロイの課題が大きかったんです。Amazon EC2を使っていましたが、そもそもデプロイが手作業でしたし、ステージング環境と本番環境の仮想マシンのランタイムに差分があることで、ステージング環境では問題なく動作したアプリがプロダクションで落ちるといった事態が発生していました。

だからこそ、ランタイムを含むすべてをパッケージングして、それを統一的なインターフェースで扱えるDockerの価値が大きいため、導入したいと考えたんです。とはいえ、マネージドサービスを利用せずに自分たちでコンテナオーケストレーションの仕組みなどを構築すると、かえって運用負荷が上がる可能性がありました。そのため、Amazon ECSの登場まで待ったということです。

一方で、規模の大きな企業や潤沢なエンジニアリングリソースがある企業では、当時からすでに仮想マシンベースの高度なデリバリーパイプラインを既に持っていましたし、ランタイムの差異が見つかれば通知するような仕組みも持っていました。そうした会社は、そのタイミングでコンテナを使うモチベーションはあまり生まれてこなかったはずです。つまり、自分たちが抱えている課題や組織の状況を踏まえて、その技術を導入することでマイナスよりもプラスが大きいかどうかが、技術を取り入れる判断基準になります。

課題を解決するうえで必要十分なアーキテクチャかどうか

――カミナシの事例についてもお話しください。

良さそうな事例が2つあって、両方とも担当したエンジニアが技術ブログやイベント登壇などで詳細を発表しています。1つがバッチ処理のリアーキテクティングの事例。もう1つがFeature Flagsの仕組みを整備してデプロイとロールアウトを分離した事例ですね。

まず前者から説明すると、「カミナシ」にはアプリ内で帳票として記録されたデータをExcel形式に変換して出力する機能があります。もともとこの機能を実現するためのバッチ処理では、Amazon EventBridgeから定期的にAWS CodeBuildを呼び出し、AWS CodeBuild上でDockerコンテナを実行するアーキテクチャになっていました。

しかし、この機能で処理をするデータの量が増えてくると、バッチ処理がリソース不足やタイムアウトで落ちてしまい、エンジニアが丸一日かけて復旧作業を行う事態がランダムに発生するようになりました。この課題に対応するため、しばらくの間はサーバーをスケールアップするモデルで処理可能な量を増やしていくという意思決定を当初はしていたようです。ですが、Excel変換機能の利用ユーザー数は安定して増加傾向にあったため、近いうちにこの方法では解決できなくなることがわかっていたんです。そこで、スケールアウトできるシステムアーキテクチャを検討することにしました。

私のほうで簡易的な方針を立て、ゴールを明示したドキュメントを担当エンジニアに渡したところ、彼が出してくれたのはAWS Batchを使う設計案でした。

余談ですが、担当エンジニアから上記の設計案が出てくる前に「もし自分だったらどう作るか」のアイデアは言語化していました。私が考えた案はこういったAWS BatchのようなコンピューティングをさらにAWS Step Functionsでくるんでエラーハンドリングのような部分まで一定程度自動化し、適度に柔軟にリトライまでやれるようなアーキテクチャでした。システム運用にかかる負担を可能な限り減らしたいという気持ちが背景にはありました。

一方、メンバーが出してくれた案は、リトライについてはAWS Batchによる簡易のリトライに留め、簡易リトライでも成功しない場合はエラーの原因を人間が調べて手作業で再実行する、というものでした。

これは私のアイデアとは異なりましたが、一方で現在の課題を解決するうえでは必要十分なアーキテクチャ、MVPであると感じたんです。そこで、彼が考えてくれた簡易のリトライのみを前提とした設計でGoを出しました。結果として、バッチ処理の総処理時間やインフラの金銭的コストが大幅に改善しただけでなく、本番環境にリリースし始めた2022年12月から現在（2023年11月時点）に至るまで、目立ったバッチ処理の障害は起きていません。

簡易のリトライだけでは不足するシーンもありますが、クリティカルな状況ではまったくなく、このリアーキテクティングによって「エンジニアが丸一日かけて復旧作業をしなければならない」という最大の課題もしっかり解決できたと言えます。

＜リアーキテクティングの事例について取り上げた技術ブログと登壇資料はこちら＞

技術ブログ

登壇資料

――この事例を踏まえて伺いたいことがあります。システムのアーキテクチャ設計において、どのくらい多種多様な事態を想定してシステムを作り込んでおくかは、判断の難しいポイントです。この事例において、Toriさんが「課題を解決するうえで十分なアーキテクチャ」であると判断した理由について伺いたいです。

「解かなければならない課題は何なのか」が明確ではない状態でアーキテクチャを設計すると、どうしてもシステムが無駄に複雑になるんですよ。エンジニアは技術が好きなので、「こういうケースを考慮してこのリトライを足しておこう」などと先ほどの私のように必要以上に作ろうとしてしまうんです。

でも、解くべき課題が何なのかを明確にしてアーキテクチャを考えると、自然とMVPが見えてきます。この事例においては「スケールアウトできる設計にすることや、障害発生時のリカバリにかかる負担を減らすこと」が解くべき課題だったため、メンバーの出してくれた案が良いという判断をしました。

――もうひとつの、Feature Flagsの仕組みを整備した話も聞かせてください。

私たちはスタートアップなので、価値提供のスピードを向上させたいと常に思っています。ですが「とにかく何でもいいから機能を作ってリリースするぞ」という方針にすると、後々に地獄を見るんですよね。なぜなら、機能をリリースすると、その機能の面倒をずっと見ていかなければならないから。顧客が業務で使っているので「リリースしたけれどメンテナンスが大変だし、あまり使われていないからやはり消そう」という選択を安易にはしづらいんです。

とはいえ、一度リリースした機能を絶対に消せないとなると、開発のスピードが犠牲になるんですよね。そこで、特定の新機能を待ってくれている一部のお客様に対して検証を依頼し、フィードバックを聞きながらクイックに改善していける仕組みを構築したいと思いました。やり直しがしやすくなると、チャレンジできるんですよね。そしてチャレンジできる土壌があると、意志決定も早まりますし、安心してコードを書けます。

そこで、影響範囲を小さくしながら高速にやり直しができる状態を実現するために、デプロイとロールアウトを分離することを目指しました。具体的には、Feature Flagsを導入することで、システムを利用する企業様ごとに機能のON・OFFを切り替えられる仕組みを取り入れるという方法を選択しました。

仕組みを整備する前から、簡易的なFeature Flagsの仕組みは実装・利用していたんです。それは、機能のON・OFFの条件をソースコードにハードコーディングする方法でした。その方法では、消し忘れや修正漏れによる事故が発生したり、あるいは単なる機能のON・OFFの切り替えのためにソースコードの修正とデプロイが必要だったりと、デプロイとロールアウトが密結合の状態になっていました。

そこで変更後のアーキテクチャでは、Feature Flagsの設定値をAWS AppConfigに保持する方針にしました。アプリからはAWS AppConfigのAPIを呼び出して設定値にアクセスします。これにより、デプロイとロールアウトを分離でき、より便利にFeature Flagsを活用できるようになりました。

＜Feature Flagsの事例について取り上げた技術ブログと登壇資料はこちら＞

技術ブログ

登壇資料

不定形なデータをユーザーのニーズに基づいて検索するために

――今後カミナシで実現したいことはありますか？

実現したいことはいくつもありますが、私がチャレンジングだと思っていて、かつ顧客への価値提供も大きい見込みがあるビジョンとしては、「カミナシ」の検索機能を進化させることです。

私の個人的な考えとして、ユーザーはSystem of Record（情報を記録することを目的としたシステム）なアプリを利用する際、「これまで格納してきたデータ群に対してイメージした通りの形で検索をかけ、それにより目的のデータを見つけたい、分析したい」という普遍的なニーズを持っています。

これはなんなら人類の生理的欲求に沿った活動ですらあると個人的には思っていて、この情報の発見と活用を強化するプロジェクトやアイデアに対してプロジェクト・マズロー*という名前を付けました。

*…モチベーションに関する理論「欲求段階説」を唱えたアメリカの心理学者マズローにちなむ。

ユーモアを込めてこの名前を付けたんですが、同僚は誰も笑ってくれなくて…（笑）。そのうち、社内の誰かがこっそり名前を変えるんだろうな。でも、こうしてインタビュー記事という形で公の場にプロジェクト名を載せておけば、既成事実ができて変えにくくなる気がするので言っておきます！

――ハハハハ（笑）。では、プロジェクト・マズローで実現したいことを教えてください。

「カミナシ」では顧客が自由に帳票のレイアウトを組んで、データを保存できます。帳票内ではいろいろな形式の項目を組み合わせることができるので、「カミナシ」のデータベース内には顧客それぞれのカスタムスキーマが情報として保存されているんです。

顧客は本来ならば、自分たちが定義したスキーマ情報に沿って検索したいはずです。たとえば、「商品コードというフィールドにXXXから始まる値が入っていて、検品結果がNGになっている帳票を取得したい」などです。でも、「カミナシ」では現在、そういったニーズに対してまだまだ十分な機能を提供できていないんですよ。これを、顧客の定義したスキーマ情報も柔軟に、高速に検索できるように変えていきます。

このためのシステムをきちんと作り切ることは、実は技術的な難易度がそこそこ高いです。「Elasticsearchにすべてのデータを突っ込めば検索できる！」という簡単な話ではありません。スキーマとしてどのようなフィールドを持っているのかは、それぞれの顧客によって全く違います。また、検索面の機能性を重視しすぎてあまりにも複雑なシステムを組んでしまうと、提供できる価値の大きさに対して運用コストがペイしない可能性すらあります。

だからこそ、そもそもどんな検索ニーズがあるのか、それを実現するためにどんな手段があるのかを把握しなければなりません。その仕事は、エンジニアにとって相当面白いと思いますね。（取材音声録音用のICレコーダーに向かって大きな声で）だから、私たちは検索機能の開発に興味があるエンジニアも絶賛募集していまーす！

――レコーダーに向けて大声で話しても意味がないですよ（笑）。

意思決定をするうえで必要な要素を、どれだけ広く深く把握できているか

――カミナシをどのような会社にしていきたいですか？

顧客への価値提供のスピードをもっと上げていきたいです。そのためには、ただがむしゃらにコードを書きまくれば良いわけではなく、今回のインタビューで挙げたFeature Flagsのようなものでより試行錯誤しやすくするなど、根本的な仕組みを変えていくことも大切です。そうした取り組みのなかから成功事例が生まれる会社にしたいですし、サービス作りに関わるメンバー一人ひとりが「いかにしてユーザーに価値を届けるか」というマインドセットを身に付けられるようにしたいです。

あとは、楽しい会社にしたいですね。未知の技術や手堅い技術を適材適所で選定できる、緩急のバランスがとれた状態にしたい。それから、余計な認知コストや非効率的な業務を減らして、より本質的な仕事に時間を使える組織になっていけば、みんな幸せだろうなと思っています。所属するメンバーみんなが、自分のスキルを最大限顧客への価値提供に使えているという感覚を持てるような会社にしていきたいですね。

――カミナシの今後が楽しみです。最後に伺いたいのですが、「what we use」で掲載するインタビューやコラムは「技術的な意思決定」をテーマにしています。エンジニアがこういった事例を学ぶことには、どのような意義があると思われますか？

意思決定をするうえで、その意思決定の良し悪しに影響を与えうる要素が何なのかを、どれだけ広く深く把握しているか。それが、意味のある意思決定をするためには重要だと思っています。世の中のCTOやテックリードの方々は、技術のことだけを考えて意思決定しているわけではないんですよ。たとえば、この技術的な意思決定によってエンジニアリングのプロセスがどう変わりうるのか、CSの業務フローがどのような影響を受けうるのかなど、一見して技術そのものとは距離がある範囲まで含めて思考していることが多々あります。

まだエンジニアとしての経験が浅い頃は、目の前にある技術の情報だけを見て意思決定するケースが多くなりがちです。そこから、さまざまな職種の同僚や、バックグラウンドが異なるチームメンバーと一緒に働いていくことを通して、徐々に会社全体や事業全体、顧客も含めてそれぞれがどのような影響を受けるのかを考えられるようになっていきます。

だからこそ、先人たちの事例を学ぶ際には技術のことだけではなく、意思決定の背景にあった前提条件や会社が置かれていた状況なども含めてトレースすることをおすすめします。そうすることで、自分自身がより良い意思決定を下せるようになるはずです。

取材・執筆：中薗昴

撮影：山辺恵美子

提供：株式会社Haul

「AWS AppConfig」の記事一覧