アーカイブ動画

登壇者プロフィール

森本 数馬氏
セーフィー株式会社
取締役 開発本部本部長 兼 CTO
2001年東京大学工学部を卒業後、ソニーに入社。営業職から開発職にキャリアチェンジし、Walkman、カメラなどのシステムLSI開発からTVなどメディア系プロダクトのソフトウェア開発を経験する。2012年 GREE CTO室勤務を経て、2013年にソニーからスピンアウトしたモーションポートレートに入社。顔認証技術を利用したライブラリ開発に携わる。2014年10月にセーフィー株式会社を創業。Safieの開発全体を統括。

若原 祥正氏
freee株式会社
執行役員/プロダクトコア事業部長
クラウドサービスの開発に携わったのち、2013年6月にfreee入社。モバイルアプリの立ち上げ、freee 会計の開発マネージャを経て、今はプロダクト開発全体を統括。

布施 嘉男氏
株式会社SmartHR
プロダクトエンジニアグループ
2018年10月SmartHR入社。SmartHRの本体開発に従事後、性能改善やデータ構造の見直しを担当。現在はSmartHR全体のプロダクト、PDFの作成や電子申請を送信するプロダクトを担当。

【セーフィー】ハード・アプリ・AI・クラウドなど幅広い領域でサービス展開

「映像から未来をつくる。これが、私たちのビジョンです。人間は何かを判断する際、7割が視覚からの映像情報だと言われています。つまり映像に関する情報やサービスを充実させることで、仕事も生活も今よりも楽で効率的になる。そのような未来を実現したいと考えています」（森本氏）

続いて、セーフィーの開発状況や構成技術や開発要素、サービスの特徴を紹介した。

「自社でサーバーを1000台以上保有している一方で、エッジデバイスやエッジ対応のAIを開発するなど、とにかく幅広い領域の技術開発を手がけているのが特徴です。エンジニアの裁量も大きいので、新しいことにチャレンジしたいタイプにとっては、働きやすい環境だと思います」（森本氏）

セーフィーでは、自社開発したハード/ソフトウェア・インフラ・AIを駆使・連携し、先のビジョンを実現するサービスやソリューションを提供している。病院への導入では、特に昨今コロナ禍で問題となっている、医療従事者と患者が接触することなく、遠隔で患者のバイタルなどをリアルタイムで把握できる。

インターネットさえつながっていれば、数千台規模のカメラを一括管理できたり、クラウドに保管された録画を後から確認することも可能だ。こうした利便性が評価され、大企業や飲食チェーンなど多様な業界での導入が進み、現在の課金台数は約13万台。クラウドカメラシェアにおいては、国内トップクラスを誇る。

携帯電話の販売店など、サービス業への導入も多い。実際、ドコモショップには約1500台のカメラが導入されており、来店者の年齢や性別、来店歴などを瞬時に把握できる。従業員の動線も分析することで、最適な接客に活用されている。

「Safie」のサービスが広がることで、結果として建設業界のDXが実現していくと強調する森本氏。建設現場であれば、ウェラブルカメラを作業員が身につけることで、入退室の管理が可能になる。重機やクレーンにカメラを設置すれば、人が近づいたときにアラートを発信するなど、安全確認が強化される。

さらにこれらの映像情報をクラウドで俯瞰・一体化することで、まさに建設現場全体がDX化していくイメージだ。森本氏は次のように今後の展望を述べている。

「今後は我々の映像DXを幅広い業界に広めたいと考えており、実現には私たちだけでなく、パートナーとの連携や協力が必要不可欠です。このような考えから、APIやSDKの提供はもちろん、新しいパートナーが参画しやすいようなプラトッホームならびにエコシステムの構築を目指しています」（森本氏）

技術負債は、初期の段階から人や組織に投資することが重要

続いて森本氏は、技術負債についてはいろいろあると述べ以下2枚のスライドをもとに、詳しく紹介していった。

具体的には、あるクラウドのポートを閉じると、ほぼすべてのプロダクトやデバイスでトラブルが発生する事態となってしまった事例が紹介された。また、ある箇所を変更したり障害が起きると、システム全体に伝搬、影響を及ぼす技術負債もあったという。

先の展望を実現するにあたり、技術負債を解消することを決め、今まさに取り組んでおり、その手法は以下の通りだ。

• リファクタリング
• マイクロサービス化
• 属人化の排除（スクラム開発、ドキュメント化、勉強会の実施）

森本氏は、これらの負債を振り返ったインサイトについても紹介した。

「開発当初の2018年ごろは、とにかく市場にフィットするプロダクトを開発することに試行錯誤していたため、技術負債のことは考える余裕がありませんでした。またメンバーも数十名規模と少なかったため、ほとんどのメンバーが全ての領域を理解していたことも、技術負債解消の手をつけなかった理由だと思います」（森本氏）

しかし、サービスがスケールしていくにつれメンバーが増加し、全体を俯瞰して見られる人材も少なくなっていった。多くのユーザーが利用するようになり、さらなる高品質化も求められるようになった。こうした変遷から次のように結論を出し、セッションを締めた。

「当時の状況を考えると、技術負債が生じてしまったことは、ある意味仕方ない面もあったと思っています。ただ、技術負債は組織規模との相関性が強いことが分かりましたので、初期の段階から人や組織により投資していれば、より早く解決できたのかもしれません。これからさらにスケールしていくためにも、今後は人や組織に重点的に投資をしていきたいと考えています」（森本氏）

【freee】JenkinsからAmazon EKSにデプロイ周りを移行

続いては、freeeの若原祥正氏が登壇。「freee会計」をはじめとするプロダクトについて紹介した。「スモールビジネスを世界の主役に。」というミッションを掲げるfreeeのサービスは、まさにミッションそのままに、中小企業を中心に導入数が急増している。

「中小企業の割合は企業全体の99.7％にもおよぶため、サービスの対象社はとても多く、毎年約135％で利用者が増加しており、現在の有料課金ユーザーは28万社以上になります。当然、扱うデータ数も増えていっています」（若原氏）

クラウド会計ソフトの印象が強いfreeeだが、現在は2014年にローンチした「freee人事労務」など、全部で11のプロダクトが開発されており、ネイティブのモバイルアプリも提供している。

「freee会計」においては会計業務だけでなく、さまざまなメニューが盛り込まれており、ビジネスにおける業務を幅広くサポートする。そのため多くの機能が、モノリシックな状態となっている。

若原氏は「freee会計」の基本的な構成や技術スタック、コードのボリュームについて詳細に説明。そしてインフラ領域においては、次のように補足した。

「スライドではさらりとAmazon EKSで運用と紹介していますが、実は今年の7月に、以前のJenkinsから移行したばかりです。詳細をご説明すると、GitHub ActionsからAmazon ECRにイメージをアップロードして、Argo CDというツールを使いEKSクラスタ上にデプロイしています。今時の構成になったと思っています」（若原氏）

「モジュラモノリスアーキテクチャ」を採用し、構築を進める

現在は11プロダクトを展開するfreeeだが、もともとは「freee会計」だけを開発していた。そのため、同プロダクトで利用しているサービス、特に認証/認可サービスを、他のプロダクトでも使えるようにしたいと考え、プロダクトから切り離すよう試みた。しかし、データベースだけは残ってしまった。

「当初は技術負債を気にするよりも開発スピードを優先していましたし、トラブルもなかったので、しばらくはそのままの状態で進みました。ところがユーザー数が増えたことで、他のプロダクトにも影響を及ぼすのではないか、と考えるようになりました」（若原氏）

さらには認証/認可だけでなく、共通で使いたいサービスは増えていった。課金、申請・承認などだ。共通で使われるということは、高いパフォーマンスが求められ、この先も必要であり続ける可能性が高い。そこで、データベースが残ってしまったというようなことが起きないよう、完全な切り離しを実現するアプリケーション基盤チームが発足する。

しかし、技術負債はこれだけではなかった。プロダクトはもちろん機能が増えていくことで、コード量は増加。その結果、以下スライドのような技術負債が生まれていった。

こうした技術負債を改善するには、どうすればいいのか。若原氏はテックリードと意見を交わしていく中で、世界最大級のRailsアプリケーション、Shopifyが取り入れた「モジュラモノリス」というアーキテクチャに注目する。

モジュラモノリスとは、モノリスなアプリケーション内でも、ドメイン単位のモジュールに分解することで、モジュールごとの独立性を担保しようというアイデアであり、アーキテクチャである。

モジュラモノリスアーキテクチャを導入することで、実現したかったことは大きく3つある。開発トレンドの一つでもあるマイクロサービス化も検討されたが、境界線を決めることが最も重要な目的であったため、現時点では同アーキテクチャを採用することとした。

• モジュール境界を明確にして安心独立した開発を可能にしたい
• 不必要な結合をなくしたい
• DBへの予期しないアクセスをなくしたい

そこから改めて1年ほどの時間をかけ、テックリードを中心に設計を固めた。そして以下のような構成となる。

「Backend APIを新しく定義しました。そして、Backend APIの内側をモジュラモノリスにおけるモジュールと定義し、移行します。内部APIはProtobuf（Protocol Buffers）を採用し、protoファイルで型定義していきます」（若原氏）

また、一般的なRailsアプリケーションではなくなることや、preload前提のコードが使えなくなるなど、モジュラモノリスに移行するデメリットがあることについても若原氏は補足した。しかしメリットの方が多いことから、今まさに構築している最中であるという。

「freee会計」だけでなく、「freee人事労務」においてもモジュラモノリス的な思想、新たなアーキテクチャに移行する流れで進めているという。若原氏は技術負債、技術課題の解決について次のように総括した。

「2017年以前の業務割合を見ると、技術課題に関してはほぼアプローチしていないことが分かります。機能開発を優先させるフェーズだったからです。しかしアプリケーション基盤チームの発足やモジュラモノリス化などにより、現在では約30％もの業務が技術課題に充てられています。そのため組織全体として、年間目標として具体的には約3カ月間、全メンバーが技術課題に取り組む体制に変わりました」（若原氏）

一方で、個人がさらりと不具合を改善するアクションや、そのような動きが尊重される文化や空気感も重要だという。「カッとしてシュッとやる」という言葉と、開発文化で重要視している5つのキーワードを紹介し、セッションを締めた。

※登壇資料「うちの技術負債2021_freee会計編」
https://speakerdeck.com/waka/utifalseji-shu-fu-zhai-2021-freeehui-ji-bian

【SmartHR】技術負債は小さい段階で解消していくことが重要

続いて登壇したSmartHRの布施嘉男氏は、まず「SmartHR」のサービスについて説明を行った。「SmartHR」は雇用契約や年末調整などの人事業務を紙ではなく、スマートフォンやパソコンに入力するだけで行える、人事労務に関するクラウドソフトウェアである。

その登録社数は現在4万社以上におよび、業界シェア3年連続でナンバーワンを獲得。継続利用率も99％以上を誇る。

「以前は労務に関する作業環境が整っていない中小企業の導入が多かったのですが、従業員のデータが蓄積され、他の業務やサービスでも使えるメリットから、大企業への導入も進んでいます」（布施氏）

布施氏は技術負債に関する考えを、「負債は開発工程で必ず生まれる副作用であり、避けては通れない」と述べている。また、必ず生じるものだからこそ大きくせず、小さい段階で解消するために、ウォーターフォールではなく、アジャイル開発で小さくリリースを行いながら改善を続けることが重要だと続けた。

「新しい機能を開発したら労務に詳しい社内メンバーに確認してもらったり、ベータ版としてリリースすることでお客さんに体験してもらい、得た意見をフィードバックすることを意識しています」（布施氏）

具体的には、課題管理ツールとしてJIRAを活用。タスクとして、技術負債の解消がスプリントに業務として組み込まれている。一方で、スプリントのタスク以外にもエンジニアが自発的に技術負債を解消しているケースもあり、布施氏は「me time（自分の時間）」での解消と説明した。

しかし、導入企業の規模が大きくなるにつれ、こうした対応だけでは技術負債を返済することが難しくなっていた。1000人未満の企業の利用であれば問題のなかったコードが、それ以上の規模の企業では不具合を起こすからだ。「当時のコードはラフだったし、技術負債への対応も牧歌的だった」と、布施氏は振り返った。

コードに関する負債だけではない。従業員が10万人を超える規模の会社への導入も進むようになると、すでにある社内システムとのAPI連携はもちろん、RPAやCSVによるデータ更新なども必要になってきた。当然、その規模の組織は労務担当者数も多い。さらには、品質は以前にも増して求められるようになっていった。大企業への対応が求められるようになっていったのである。

Before

↓
After

まずは管理画面、UIにおける技術負債の解消である。単調でデザイン性の乏しかった画面を刷新。JavaScriptライブラリもjQueryからReactに変更することで、大企業にも対応できる品質を備えたUIに生まれ変わった。

性能面においても、以前の管理画面では1000件を超えるアカウントが並んだり、大量にデータを登録・検索すると、タイムアウトしていた。CSVやエクセルデータのインポートでも、全件対応すると一晩で終わらないために、各所に影響を及ぼしていた。

「PdM主導で新機能や改善の検討を始めることが多いですが、本ケースでは3名のエンジニアが性能改善チームを発足。QAチームの協力も得ながら、3カ月かけて性能問題の解消に取り組みました。基本はリファクタリング作業で、コードを書いてはテストを繰り返しました。また、以前は制限していなかったカスタム項目数を限定するなどの改善も行いました」（布施氏）

5万件の従業員データ、247項目×1万人分のデータのインポートは、それぞれ15時間から5時間に、2時間20分から25分にと短縮された。約7万人の従業員の一覧画面表示も、以前はタイムアウトしていたが、1.2秒で表示されるように改善。現在はパフォーマンスをモニタリングしたり、パフォーマンス観点でもお互いにレビューし合うことで、同じような負債を生まないよう努めている。

だが、技術負債はまだ残っている。創業時から動いているコアなアプリケーション（左側）であり、そこに新しい機能を追加していく（右側）、いわゆるモノリシック状態になっていることだ。

そのため、両開発メンバーの調整が多く生じたり、影響が生じた際の範囲が見えづらい。スピード感のある組織の成長と合致しておらず、エンジニアの成長にも影響を及ぼしていることが一番の問題だと、布施氏は説明する。

そこで現在は、freeeも導入を進めているモジュラモノリス化を検討しており、その事例はまた改めて発表したいと、意欲を見せた。

【Q＆A】参加者から寄せられた質問を紹介

セッション後は、イベント全体を通して参加者から寄せられた質問に回答するコーナーが設けられた。

──ビジネス側からリリース日を指定されることが、技術負債の要因になることはあるか。

若原：あります。解決策としては、その日でなければ本当にだめなのか。逆に、いつまで延ばすことができるかなど、両部門でしっかりと話し合い、すり合わせることが重要だと考えています。

──カルチャーの醸成や公開など。技術負債を返済するために努力していることは何か？

若原：対応してくれたメンバーを、しっかりと評価する仕組みづくりや、カルチャーを明確に定義し、醸成することが大切だと思います。

布施：負債に気づいたらいち早く直す。そのように動けることが「かっこいい」という文化を醸成することが重要。また、コードを一つひとつ丁寧に、手間ひまかけて書くことを評価する制度の整備も必要だと考えています。

──モジュラモノリスへの移行をはじめとして、リファクタリングなどの技術負債の解消は費用対効果の算定が難しいと思うが、経営層や現場をどのように説得したのか。

若原：リファクタリングを目的に説明すると、説得は難しいでしょう。先ほど説明したように、2018年以降は毎年30％の工数を技術課題に充て、実際に成果を出していきました。

もしくは現在の不具合を解消することで、新たな機能開発に工数を取れることを説明します。ただ、エンジニアサイドとしては、技術負債を解決すれば結果が伴うことは分かっているので、ある意味勝手にやっているというのが正直なところです。

森本：若原さんが言うように、これから先のメリットを説明することが重要です。セーフィ―では、新たな開発を行う際に工数を含めています。ただ当社の場合は経営層に開発メンバーがいるため、理解されやすい環境ではあると思います。

布施：2人の意見に同感です。補足するとすれば、似たような事例が他社にあり、負債を解消したことで費用対効果に貢献したことが説明できれば、経営層に刺さると思います。

──日本ではまだ事例の少ないモジュラモノリスをどのように学習していったのか。

若原：たしかに明確な手法が書かれたドキュントはありませんでした。そこで、思想をfreeeのプロダクトに重ね合わせ、まずはテックリードが3カ月ほどかけて、素案を作り、そのアイデアをベースにメンバーで議論を重ね、PoCを行い、1年かけて実現していきました。

──サイズが大きい動画を扱うことによる技術負債の事例を聞きたい。

森本：動画の圧縮技術は日進月歩なので、常にキャッチアップするよう努めています。過去のデータをどのように扱うかについては、今後も考えていく必要があると思っています。

セーフィー株式会社
https://safie.co.jp/

セーフィー株式会社の採用情報
https://safie.co.jp/recruit/