シェア
はてブ
2023年7月13日、ファインディ株式会社が主催するイベント「開発生産性Conference」が、開催されました。
本記事では、オンラインでも配信されたセッションのうち、FastLabel株式会社とセーフィー株式会社による「スタートアップと上場企業、二つの視点から見る技術的負債との向き合い方 〜リアーキテクチャとDevOps改善〜」の内容をお届けします。
このセッションでは、異なるフェーズの両社がどのように技術的負債に取り組んでいるかをはじめとして、技術的負債に割くリソースや体制、経営陣やビジネスサイドとの合意形成をテーマにお話しいただきました。
■プロフィール
FastLabel株式会社
エンジニアリングマネージャー
風見 亮（かざみ りょう）
慶應義塾大学卒業後、ワークスアプリケーションズで大規模な会計・生産管理システム開発に携わる。
FastLabelの創業期から参加し、混沌とした初期ステージを乗り越えた。
現在は、エンジニアリングマネージャーとしてMLOps関連機能開発を主導し、同時にアノテーション代行サービスのテクニカルサポート責任者を務める。
Development Dept. Software Engineer
姉川 純一朗（あねがわ じゅんいちろう）
九州大学大学院卒業後、株式会社ワークスアプリケーションズで大規模ERPシステムの開発に従事。その後転職し、atama plus株式会社にて塾向けのSaaSプロダクトの開発に携わる。
現在はFastLabelでAI開発を効率化するためのプラットフォームの開発を担当している。
要件定義、インフラ、バックエンド、フロントエンドなど、幅広く担当。
セーフィー株式会社
第1開発部部長
遠藤 貴弘（えんどう たかひろ）
専門学校にて3Dゲーム開発技術を学んだ後、独立系SIerに就職。その後複数社にてWebアプリケーション開発やマネジメントに従事し、前職は国内最大級の医療系ポータルサイトを運営するIT企業にて製薬企業向けサービス開発・運営をリード。約9年間勤務した後、実世界で触れることができるIoT関連のデバイスやサービスに魅力を感じ、2022年3月セーフィーへ入社。現在は第1開発部部長としてバックエンド、インフラエンジニアなどを統括しつつ、企画・開発案件のマネジメント業務なども担当する。
サーバーサイドエンジニア・テックリード
鈴木 敦志（すずき あつし）
大学でコンピューターサイエンスを学んだ後、学生時代からインターンで働いていたITベンチャーに入社し、医療機器の相互接続性の検証システム開発など、様々なソフトウェアの受託開発を経験。同社が他のベンチャーと合併した後も勤務を続けるが、PoC（実証実験）フェーズの開発よりも、実際にユーザーが存在するサービスやシステムの開発に携わりたいと考え、2019年1月セーフィーへ転職。
以降はエンジニアとして「Safie Visitors（セーフィービジターズ）」「Safie Pocket2（セーフィー ポケット ツー）」「Safie AI People Count（セーフィー エーアイ ピープル カウント）」などの新サービス開発を担当。
現在は第1開発部のサーバーサイド開発チームにて、スクラム開発のプロダクトオーナーを務めている。
■モデレーター
ファインディ株式会社 DevRel
北川 雅士
スタートアップと上場企業、フェーズの異なる2社から登壇
――モデレーターを務めさせていただく、ファインディの北川と申します。このセッションでは技術的負債をテーマとして、シリーズAのベンチャー企業であるFastLabelさんと、創業約10年の上場企業であるセーフィーさん、フェーズの異なる2社をお呼びしました。まずは登壇者の皆さんの自己紹介からお願いします。
風見：FastLabel株式会社の風見と申します。弊社はAI開発のためのプラットフォームやサービスを展開しているスタートアップ企業で、私は開発のエンジニアリングマネージャーをしています。今日のテーマでは、皆さんとぜひつらみを分かち合い、学びのある会にできればと思いますので、よろしくお願いいたします。
姉川：FastLabel株式会社の姉川と申します。風見さんのチームで、ソフトウェアエンジニアとして働いています。実は、僕は3ヶ月前にFastLabelに入社したばかりで、風見さんが残した技術的負債をどう返すかといったところを、突っ込んで話せたらと思います（笑）。よろしくお願いします。
遠藤：セーフィー株式会社の遠藤と申します。セーフィーは、クラウド録画ができるカメラのサービスを展開しています。私は、主にバックエンドのエンジニアが所属する第1開発部で、部長という名のエンジニアリングマネージャーのような役割をしています。よろしくお願いします。
鈴木：セーフィー株式会社の鈴木と申します。セーフィーに入社して4年目くらいで、バックエンドのソフトウェアエンジニアやテックリードをしています。サーバー側で多種多様なシステムがあるのですが、配信からAIまで手広く担当させていただいています。よろしくお願いします。
ーー本日は、両社の技術的負債の状況についてお話いただいたのち、技術的負債に割くリソースと体制について、そして技術的負債に取り組むうえでの経営やビジネスサイドとの合意形成について、ディスカッションしていければと思います。
FastLabelの展開する事業と技術的負債への取り組み
――それでは、さっそく両社の会社紹介を踏まえつつ、技術的負債についてお話いただければと思います。では、FastLabelさんからお願いします。
風見：まずは、弊社の事業を簡単にご紹介します。FastLabel株式会社は「AIインフラを創造し、日本を再び『世界レベル』へ」というパーパスを掲げ、AIをより効率的に開発するためのプラットフォームをSaaS型で展開しています。加えて、アノテーション代行やデータ収集、既存のAIモデルのデータコンサルティングといった、周辺サービスも展開しています。
下記左側の画像が、AIデータプラットフォーム「FastLabel」のアノテーション画面と呼ばれるものです。AIを作るためには、学習させる教師データが必要になります。下記の例で言えば、これは車、これは自転車に乗っている人、というように物と座標をAIに学習させることで、AIが「これは人だ」とわかるようになっていく。そういった大元となるデータに強いプロダクトです。
AIを作るためには、さまざまなプロセスがあるのですが、その一連の流れをすべてワンストップでカバーできる、AIソリューション「AIPaaS」も提供させていただいております。
風見：開発環境については、フロントエンドはReact、TypeScriptを採用しています。バックエンドはNode.js、それから機械学習がありますので、そのあたりの処理はPythonですね。認証基盤はAuth0、データベースはAurora MySQL、インフラは基本的にAWSに乗せる形になっています。
下記が簡単なシステム構成図で、詳細な説明は省きますが、基本的にはスタートアップ企業ですので、今のところあまり複雑な構成は取っていません。何か問題があれば、そこの部分をすぐに直せるような、シンプルなアーキテクチャを心がけて開発しております。続いて、姉川から技術的負債についてお話します。
姉川：もともとFastLabelは、アノテーションから始まった会社で、当初は機能しかなかったのですが、3年が経ってものすごく機能数が増えてきています。それに伴って、もともと1チームしかなかったチームも、最近3チームに分割されました。
そのなかで、1つのモノリシックなパッケージのなかに、すべての機能のソースコードが配置されており、かなりメンテナンス性が低下しているという意見が開発側から上がっていました。そのため、適切な機能モジュールごとにパッケージを分割するという、ソースコードレベルのリアーキテクチャを実施しました。これがつい先週のことで、まさに取り組んでいる最中ですね。
姉川：もともとソースコードのアーキテクチャが、ビジネスロジックが手続き的にサービス内に記述されていて、重複ロジックが発生したり、サービスクラス自体が肥大化したりしている状況がありました。
これがリファクタリングしようにもしづらいということで、リファクタリングしやすい基盤を整えようと、クリーンなレイヤーを切ったアーキテクチャを導入しているところになります。
セーフィーの展開する事業と技術的負債への取り組み
――続いて、セーフィーさんからもお願いします。
遠藤：まずは会社の紹介からさせていただきます。セーフィー株式会社では、クラウド録画型の映像プラットフォーム「Safie」の提供を行っています。「映像から未来をつくる」というビジョンを掲げ、監視カメラや防犯カメラ以外にも、業務の効率化などに踏み込み、AIを活用しながら社会貢献を目指している会社です。社員数は現在、約370人です。
「Safie」はクラウドプラットフォームなので、どこでも映像が見れて、セキュリティが高く、かつ値段も安いという特徴があります。対応しているカメラは1000機種以上。SafieViewerというアプリケーションがあり、Webやアプリから映像を確認することが可能です。
遠藤：クラウド録画サービスの国内シェアは56%で、カメラ台数は19万台を超えています。これだけ見るとすごいのですが、監視カメラや防犯カメラは、NASなどのストレージにデータが保存されているケースもあり、それが660万台くらいあります。
鈴木：続いて、システム内部の話をさせていただきます。「Safie」のクラウドプラットフォームにはいろいろなサービスがあり、ストリーミングの配信系やカメラ内のファームウェア、それと通信するサーバー。あるいは、セーフィーはカメラを売る業者という側面もあり、そこを制御するドメインなど、さまざまなところが関わってきます。
そのなかでも、最もコアとなるのが、カメラの管理と録画のサーバー、および動画配信のアーキテクチャです。カメラは約20万台あり、その接続を管理するサーバーも2000台と、かなり膨大な数になります。トラフィックはインバウンドで1日900TBくらい。録画データは、現在では27～30万PBくらいになっています。
鈴木：この管理において、ストレージの方はスケーラブルなのですが、データベースの方をうまくやる必要があります。今はAurora MySQLを水平分割してゾーンという単位で管理していて、今は1万3000台くらいのカメラを、15～16くらいのゾーンで管理しています。
このあたりにはいろいろなつらみがありまして、システム構築時点で接続品質を向上するために、独自の仕組みを入れてあったんですね。負荷分散やスケーリングのところが、ほぼ自前で組んでありました。自前といってもAWSの上で動いているのですが、AWSのオートスケーラーではなく、AWSのAPIを使って自前で負荷を監視し、台数を足したり減らしたりするシステムになっていました。
あとは、PythonスクリプトとAnsibleが組み合わさった、かなり扱いの難しいデプロイスクリプトがありました。これは最近の流行りの技術を使っていないので、なかなかみんなが触ることができない。中身を完全に理解していないと触れないこともあり、このデプロイにだいたい45人時かかるという問題がありました。先ほどお話したゾーンあたり、15～16かける3時間という計算ですね。
これを実行している間、エンジニアが付きっきりで操作をしなければなりません。ずっと集中して操作しなければならないわけではないのですが、そこそこの確率でエラーが起きて、これをどうしますかというプロンプトが出てくる。なので、ここのコンポーネントを触るとなると大変で、1人が2週間くらい拘束されてしまうような状況でした。
そうなると、みんなこのコンポーネントに機能を追加するのを避けるようになります。作りたい機能のために、このコンポーネントに触るから1人月追加、となるとかなり大変なので、そのつらみを回避するために、さらに技術的負債を作り込む状況が生まれてしまいます。
具体的に言いますと、新しい機能を作るのに、このコンポーネント関連の接続サーバーに手を加える必要があるので、全然スピードが伸びない。それなら、そこは迂回して新しくHTTPのAPIサーバーを立てて、そこで直でやろうという話になってしまうんですね。そうすると新しいサーバーの種別が1個増えてしまう、というわけです。
鈴木：なぜこうなってしまったかというと、スケーリングなどいろいろなところで独自の仕組みを使っていて、CI/CDへの移行がかなり難しかったからです。これをどうにかしなければと一念発起し、関連するシステムごと作り直して、CodeDeployの上に置き換えました。
具体的には、EC2 AutoScalingに移行しました。スケーリングの判断自体はオートスケーリングではなく、既存の仕組みを使っているのですが、その既存のインスタンスを足したり引いたりするサーバーのところを作り変えて、オートスケーラーのキャパシティを書き換えるようにしました。
あとは、CodeDeployのスクリプト上から、スケーリングのコンポーネントを制御するようにしました。また、先ほどデプロイ中にたびたびエラーで止まるという話をしましたが、そこを何とかするために、Prometheusで監視のところを作り込んで、手放しでデプロイしても耐えられる品質にまで持っていきました。
これによって、デプロイ時間は45時間から2～3時間に減らすことができました。検証環境のデプロイ頻度は、0.3回/日から2.6回/日まで、約9倍に増やすことができています。7月初めに仕組みができあがったばかりなので検証環境と書いていますが、プロダクション環境のデプロイ回数も、これと同様に増加していくものと考えています。
技術的負債へのリソースの割き方と体制
――続いて、ディスカッションの1つ目のテーマに入っていきたいと思います。「技術的負債にどのくらいのリソースを割くべきか？ どのような体制で取り組むか？」といったテーマですが、まずはFastLabelさんいかがでしょうか。
風見：常設のチームではなく、都度人を集めて取り組んでいます。責任者を立てて、できるだけ少人数で、本当に1～2人くらいですね。まずは最終形を描いて、各ユニットのリーダー陣と合意を取ります。次に工数を取る期間の合意を取って、一気に進めるイメージ。長く少しずつやるというよりは、定期的に一気に進めるようにしています。
――セーフィーさんも大掛かりな取り組みだったかと思いますが、さまざまな問題があるなかでどう優先順位をつけ、どこから手をつけていきましたか？
鈴木：まず1つは、明確に期限が決まっているものからですね。Python 2系を長いこと使っていたのですが、2020年にEOLになっています。それに加えて、Ubuntuの配布パッケージを使っていて、2年くらい猶予があったのですが、それが本当のデッドラインだということで、結構な量のコードを書き換えてPython 3に対応しました。
もう1つは、一番困っているところですね。先ほどお話した、カメラと接続するサーバーのところは、難易度が高いけれどもやっていこうということで、チームの枠を外れたワークグループの体制で進めました。
――どこから手をつけていくかについて、FastLabelさんではいかがでしょうか？
姉川：FastLabelでは、最近3チームに分かれたこともあり、週1でDev横断のミーティングを実施しています。そこでDevで気づいた技術的な負債や、やりたいことの要望を上げて、各自持ち帰ったあと、先ほど風見さんが話したような形で進めています。
――新規案件や追加案件など、さまざまあるなかで取り組むのが難しいと思うのですが、そのあたりはどういったすり合わせをされていますか？
風見：おっしゃる通りで、どうしてもやらなければならないビジネス的な要件が積み上がっているなか、折り合いつけてやっていく必要があります。理想があっても、やはり完璧にやるのは無理なので、まずは第1ステップとして1～2週間という期間で工数を取ります。
いつまでも何ヶ月もかけてゆっくりやるのではなく、1週間なら1週間。そして、その他の開発スケジュールを踏まえて、必要案件には影響がないことを伝えるようなやり方で進めています。
――セーフィーさんでは、周囲の方々とどのようにすり合わせしながら進められていますか？
遠藤：創業当初からあるようなコンポーネントは、当然ながら長くある分、いろいろとゴミがたまりやすい状態になるので、チーム自体を分けています。プロダクトを見ているチーム、技術負債がたまりやすい基盤を見ているチーム、あとはAI系のチームといった形ですね。
負債がたまりやすいチームは、負債を返却する活動を頻繁にやっていて、それを全社にロードマップとして提示して進めています。ただ、それをやりすぎると他のチームから隣の芝生が青く見えてしまう傾向があり、そういったところは1on1などでケアしています。
1つの部のなかに3つのグループがあって、部の裁量で異動は割と簡単にできるので、実際に異動してもらうケースもあります。Python2系の移行で、そればかりやっていると飽きてくる人もいて、そういう場合には逆にプロダクトの方に行ってもらったりしていますね。
経営陣やビジネスサイドと、どのように合意形成するか？
――2つ目のテーマに移りたいと思います。「技術的負債に取り組むうえでの、経営・ビジネスサイドとの合意形成について」です。そもそも技術的負債に対してどういった考え方を持たれているかについて、お伺いしてもよろしいでしょうか。
風見：スタートアップなので、やはりビジネス的な要件というのは必須で、それをやっていかなければ会社が潰れてしまいます。技術的負債に対する取り組みは、スピードとトレードオフになりがちですが、中長期的に効いてくるものです。ただ、そればかりやっていては足元が崩れてしまうので、そこのバランスが重要だと考えています。
今のところ、弊社はまだ規模が30～40人くらいで、かつ非エンジニアの方も理解がある人が多いので、そこは助かっていますね。リファクタリングなどをやりたいと言っても、周囲の理解が得られない経験は、結構あるあるかなと思いますが、そういったところは全体としてのスケジュール感をしっかりと提示していくことが大事だと思っています。
――セーフィーさんでは、こうした部分の考え方についていかがでしょうか？
遠藤：大きな話になってくると、どうしても工数が問題になってきて、リプレイスとなると数百人日かかるようなことが、ざらにあると思います。なので、3年後のアーキテクチャというような形で大きな画を描いて、そのなかでサービスレベルの向上や人員計画などを含め、意思決定してもらえる情報を伝えて、工数を確保するようにしています。
これは上場しているからというわけではなく、事業貢献という前提で、そこを味方につけないと難しいかなと。例えば、「開発効率が25%上がります」といった提案だと、経営側からすると本当かどうかわからないと思うので、あまりそこに終始しないように考えています。
昨今は、エンジニアの採用自体が経営課題だったりするので、開発者体験がどう上がるかを伝えることはプラスになると思っています。定量化するのは難しいですが、それが難しいことは経営陣もわかっているので逆に理解されやすく、今はそういうやり方をしています。
来場者からの質問に答える、質疑応答タイムへ
――ここからは、来場者の方からの質問に回答していきたいと思います。まず1つ目は、「事業価値と負債返済による価値の優先度判断は難しいと思いますが、負債返済によるメリットの定量化などはされていますか？」という質問です。いかがでしょうか？
遠藤：工数が小さいものであれば、スクラムイベント中にPOが、そのスプリントでできるものをやるといった判断をします。大きいものは、やはり定量化しなければならないので、どれくらいの価値があるかを示していこうとしています。
そうすると、実効性がないとスケジュールに入れられなくなってしまうのですが、セーフィーでは「これでいくらになります」と示すのは難しい。なので、「これくらいUUが増えます」とか、そういった指標で話すこともあります。
――技術的負債の解消が、どういった形でUUの増加につながるのでしょうか？
遠藤：月額課金型なので、使い勝手が良くなれば使う頻度が上がり、LTVが上がることにつながると考えています。
鈴木：実際に負債の返済という形で、配信サーバーのリプレイスを行ったことがあるのですが、再生開始までのタイムラグが1～4秒減ったり、再生の失敗率が減ったりといった、ユーザーへの良い影響がありました。
――ありがとうございます。こちらについて、FastLabelさんではいかがでしょうか？
姉川：メリットの定量化はあまり行っていません。というのも、代表の上田がプロダクトの機能の優先順位を決めているのですが、代表がエンジニア出身なので、技術的負債に関する理解があります。なので、ありがたいことに、メリットを定量化しなくても実施できているという状況です。
――次の質問です。「技術的負債に向き合ううえで、長くやるのではなく短期間に一気に進めるというFastLabelさんのお話がありましたが、この理由を教えてください」とのことです。
風見：私は前職でメガベンチャーにいて、いろいろなユニットに何十人も担当者を立てて進めるような取り組みをしたことがあるのですが、結構グダグダになるんですよね。1～2ヶ月の期間を決めて、その間に進めようとしても、なかなか進みません。
チームによって事情が違ったりもするので、こういう場合はどうすればいいか、というのが次々に出てきて、うまく動かないんですね。なので、短期間で一気に進めるのが最も効果があって、ちゃんとしたものができあがるので、今のところはそうした意思決定をしています。
――続いて、「負債解消に取り組む過程で得られた経験や学びはありますか？ それらを今の開発に活かせていますか？」という質問です。
鈴木：どう書いたら良いコード、悪いコードなのかは、人から話を聞いて思うことはあっても、こうやって技術的負債として表面化するまで、実際には何が悪いのか、なかなか体得しづらいところがあります。
なので、こういった経験を積むことで、「このアーキテクチャが流行っているのは、こういう問題を解決しているからいいんだな」とわかるようになったりして、見る目が養われたのではないかと思います。
――最後の質問です。「何をもって技術的負債と定義されましたか？ ビジネス的なプロダクトの生産性はデプロイ頻度などですが、エンジニア視点の負債はテスト容易性の確保や、コードカバレッジなどの内部品質だったりします。内部品質の改善が、結果として機能開発の容易さにつながったりしますが、そこの関係性などは分析されていますか？」という内容ですが、いかがでしょうか。
姉川：FastLabelでは、まだそうしたカバレッジなどについて、定量的に分析できるようなツールや指標は取り入れていません。開発者がまだ少ないこともあり、現場レベルで感じたことを、技術的負債として取り組んでいる状況ですね。
鈴木：弊社でもそういったところは、まだ定量化できていません。なので、デプロイ頻度とか、あるいは循環的複雑度とか、そういう定量化できるものを測定していって、負債返済の取り組みをメトリクスとして表せるようにしていきたいと思っています。
――それでは、最後にFastLabelさんよろしくお願いいたします。
姉川：FastLabelは全然人が足りておらず、全職種で積極採用中です。最近イベントにも積極的に出て認知を拡大しているところなのですが、もしご興味あればカジュアル面談など気軽に応募していただければと思います。
――以上で、セッションを終了させていただきます。登壇者の皆さん、参加者の皆さんありがとうございました。
