LayerXのフロントエンドの現状の課題と理想の技術戦略

Transcript

1. LayerXのフロントエンドの現状の課題と 理想の技術戦略 株式会社LayerX 加藤 健太 2023.2.22
2. © 2023 LayerX Inc. 2 自己紹介 • 加藤 健太 (@tatane616) • 株式会社LayerX バクラク事業部 エンジニア • 2022年7月に入社して以来、 「バクラク申請・経費精算」の開発に従事 • 2019年にSaaS事業会社に新卒入社し、 現職に至るまで主にフロントエンド領域を担当
3. © 2023 LayerX Inc. 3 • 事業と開発体制について • 現状のフロントエンドの課題 • 理想のフロントエンドに向けて 今日はなすこと
4. © 2023 LayerX Inc. 4 まだまだ四苦八苦しており、カイゼンの途中です！！ 今日はなすこと
5. 事業と開発体制について
6. © 2023 LayerX Inc. 6 バクラク事業 企業活動のインフラとなる法人支出管 理（BSM）SaaSを開発・提供 LayerXの提供プロダクト Fintech事業 ソフトウェアを駆使したアセットマネジメ ント・証券事業を合弁会社にて展開 PrivacyTech事業 パーソナルデータの利活用とプライ バシー保護を両立するソリューション の提供
7. © 2023 LayerX Inc. 7 バクラクシリーズラインナップ * 経費精算のSlack連携は申請内容の通知のみ 稟議・支払申請・経費精算・ワークフロー ・AIが領収書を５秒でデータ化 ・承認はチャットアプリから ・シームレスな内部統制構築 仕訳・支払処理効率化 ・AIが請求書を５秒でデータ化 ・仕訳データを自動学習、 手入力ゼロへ ・改正電子帳簿保存法に対応 ・利用料無料 ・即時追加発行 ・最大1億円決済可能 法人向けクレジットカード ・無料で始められる ・手入力ゼロで証憑管理 ・改正電子帳簿保存法に対応 帳票保存・ストレージ
8. © 2023 LayerX Inc. 8 • バクラクシリーズの扱うスコープが急速に拡大している ◦ 2年ほどで4つのプロダクト （＋共通基盤、社内管理画面） をリリース • 他プロダクト （社内外問わず） との連携が多い • 決済や稟議申請など、センシティブな情報を扱っている • toBの業務システム • ユーザーや利用環境が増加、多様化している • 「圧倒的な使いやすさ」を大切にしている プロダクトの特徴
9. © 2023 LayerX Inc. 9 • 各プロダクトに1人〜4人ほどのエンジニア • プロダクト横断で、DevOps、OCR、Enabling(※)チームが存在 • フロントエンド専任のエンジニアはおらず、バックエンドと兼任 • デザイナーを挟まない開発フローが多い ※ Enablingチーム： 　 特定のプロダクトに縛られず、エンジニア組織全体の技術的なイネーブルメントを推進していくチーム 開発体制
10. 現状のフロントエンドの課題
11. © 2023 LayerX Inc. 11 • Vueのプロダクトで2系を使い続けており、移行に本格着手できていない • バックエンドメインの人が多いので、最初フロントの開発に入りづらい ◦ 特にCSS周りがむずかしい。 • プロダクト間で同じロジックやUIを共通化できておらず、 メンテナンスコストの増加や、意図しない仕様のズレが発生する • テストが書かれておらず、リファクタリングが怖い • dev server立ち上げやbuild, lintに時間がかかる などなど。。。 現状のフロントエンドの課題
12. 理想のフロントエンドに向けて
13. © 2023 LayerX Inc. 13 去年の8月から 「フロントエンド・カイゼンWG」 を開催 • チーム横断でフロントエンドに興味のある人を集めて、不定期に開催 • 困っていること・やりたいことなどを予め収集してNotionにストック • 上記で出たトピックについて直接議論して方針・アサインを決める • Slackチャンネルなどで進捗確認 フロントエンド・カイゼンWG
14. © 2023 LayerX Inc. 14 フロントエンド・カイゼンWG
15. © 2023 LayerX Inc. 15 実際にWGの活動として対応したこと • Vue2どうする問題 ◦ Vue3で非推奨になる構文を検知するESLintルールを導入 ◦ Vue2.7へのバージョンアップやVue3への移行ビルドの検証 ◦ Vue3未対応のライブラリの対応状況のキャッチアップ • NodeをLTSへバージョンアップ フロントエンド・カイゼンWG
16. © 2023 LayerX Inc. 16 実際にWGの活動として対応したこと • Vue2どうする問題 ◦ Vue3で非推奨になる構文を検知するESLintルールを導入 ◦ Vue2.7へのバージョンアップやVue3への移行ビルドの検証 ◦ Vue3未対応のライブラリの対応状況のキャッチアップ • NodeをLTSへバージョンアップ 最初に細かいのを数個やっただけで、大玉の議論は進まず放置され気味に… フロントエンド・カイゼンWG
17. © 2023 LayerX Inc. 17 このままだとまずいと思い、フロントエンドに興味のあるエンジニア数名と 理想のフロントエンド環境についてわいわい話す会をやりました。 理想のフロントエンドとは？
18. © 2023 LayerX Inc. 18 いろいろ出たものの、全部大事そうだけど何からやって良いのかわからない。。。 本当に全部やるべき？ 開発者のエゴではない？ 理想のフロントエンドとは？
19. © 2023 LayerX Inc. 19 いろいろ出たものの、全部大事そうだけど何からやって良いのかわからない。。。 本当に全部やるべき？ 開発者のエゴではない？ → 本当にやるべきこと、優先度を決める軸が欲しい！ 理想のフロントエンドとは？
20. © 2023 LayerX Inc. 20 理想のフロントエンドとは？ → 理想のフロントエンドアーキテクチャとは？ を考えてみる 理想のフロントエンドとは？
21. © 2023 LayerX Inc. 21 ソフトウェアアーキテクチャは以下の組み合わせから構成される • 構造 ◦ システムで使われているアーキテクチャスタイル • アーキテクチャ特性 ◦ システムがサポートすべき 「-ility」 • アーキテクチャ決定 ◦ システムを構築する際のルール • 設計指針 ◦ システムを構築する際のガイドライン 「ソフトウェアアーキテクチャの基礎」
22. © 2023 LayerX Inc. 22 ソフトウェアアーキテクチャは以下の組み合わせから構成される • 構造 ◦ システムで使われているアーキテクチャスタイル • アーキテクチャ特性 ◦ システムがサポートすべき 「-ility」 • アーキテクチャ決定 ◦ システムを構築する際のルール • 設計指針 ◦ システムを構築する際のガイドライン 「ソフトウェアアーキテクチャの基礎」 ここに注目！
23. © 2023 LayerX Inc. 23 まずは、重要な 「アーキテクチャ特性(-ility)」 を考えることで 現在の自社の状況 （事業・組織） にマッチしたアーキテクチャの方針が定まりそう！ 「ソフトウェアアーキテクチャはトレードオフが全てだ 　　　　　　　　　　　　ー ソフトウェアアーキテクチャの第一法則」 実現したいことはたくさんあるが、最善を狙わず、選択と集中をする必要がある 「ソフトウェアアーキテクチャの基礎」 ※「ソフトウェアアーキテクチャの基礎」. p19
24. © 2023 LayerX Inc. 24 「アーキテクトは、ドメインの関心事、要件、暗黙的なドメイン知識という 　　　　　　少なくとも3つの方向からアーキテクチャ特性を明らかにできる」 アーキテクチャ特性を明らかにする ※「ソフトウェアアーキテクチャの基礎」. p67
25. © 2023 LayerX Inc. 25 • バクラクシリーズの扱うスコープが急速に拡大している ◦ 2年ほどで4つのプロダクト （＋共通基盤、社内管理画面） をリリース • 他プロダクト （社内外問わず） との連携が多い • 決済や稟議申請など、センシティブな情報を扱っている • toBの業務システム • ユーザーや利用環境が増加、多様化している • 「圧倒的な使いやすさ」を大切にしている (再掲) プロダクトの特徴
26. © 2023 LayerX Inc. 26 • バクラクシリーズの扱うスコープが急速に拡大している ◦ 2年ほどで4つのプロダクト （＋共通基盤、社内管理画面） をリリース • 他プロダクト （社内外問わず） との連携が多い • 決済や稟議申請など、センシティブな情報を扱っている • toBの業務システム • ユーザーや利用環境が増加、多様化している • 「圧倒的な使いやすさ」を大切にしている (再掲) プロダクトの特徴 ドメインの関心事
27. © 2023 LayerX Inc. 27 アーキテクチャ特性を明らかにする
28. © 2023 LayerX Inc. 28 余談： 「開発速度が速い #とは」 by LayerX mosa（榎本） 「顧客への提供価値が速い」 ＝ 「使われないものを作らない」 に加え、 「機能開発速度が速い」 についても、 「質とスピード」 的に開発速度を上げていきたい
29. © 2023 LayerX Inc. 29 • 再利用性 (Reusability) • モジュール性 (Modularity) • テスト容易性 (Testability) • デザイン設計・実装容易性 理想とのギャップが大きいアーキテクチャ特性
30. © 2023 LayerX Inc. 30 あるリソース (ソースコードなど) の再利用のしやすさ。 現状 • 同じようなロジック・スタイルを各プロダクトで独自実装している箇所が多い 理想 • 共通化すべきロジック、スタイルなどを、プロダクト内外を問わず再利用できる 再利用性 (Reusability)
31. © 2023 LayerX Inc. 31 １つの構成要素に対する変更が他の箇所に与える影響が最小になるように、 コードが別々の疎結合な要素から構成されている度合い。 現状 • リファクタリングやロジックの修正の際に、影響範囲が大きくなってしまう 理想 • リファクタリングやロジック修正の影響範囲が最小化される • フレームワークなど特定の関心領域の置き換えを、現実的な工数で実現できる モジュール性 (Modularity)
32. © 2023 LayerX Inc. 32 テストのやりやすさ （書きやすさ、実行容易性、安定性、観測容易性など）。 現状 • テストのない既存コードが多く存在 • テストデータの用意、実行に時間がかかる 理想 • 「テストを書いた方が開発速いよね」 の共通認識がある テスト容易性 (Testability)
33. © 2023 LayerX Inc. 33 開発者が、良いUIデザインをどれだけ負担なく設計・実装できるか 現状 • バックエンドメインでやっていた人が、CSSで苦労する • 新しく入った人が 「バクラクらしいUI」 がわからない 理想 • 複雑なUIを必要としない機能は、デザイン・スタイリングを得意としない 開発者でも仕様定義〜開発まで担当できる デザイン設計・実装容易性
34. © 2023 LayerX Inc. 34 アーキテクチャ特性の具体的なカイゼン方針 ギャップの大きいアーキテクチャ特性について、対策をガッと出している途中
35. © 2023 LayerX Inc. 35 具体的に、どうやってカイゼンを実行し、浸透させていくか アーキテクチャ特性の具体的なカイゼン方針
36. © 2023 LayerX Inc. 36 具体的に、どうやってカイゼンを実行し、浸透させていくか →「型に投資する」 「LayerX 羅針盤」より (カルチャーデッキ) アーキテクチャ特性の具体的なカイゼン方針
37. © 2023 LayerX Inc. 37 ソフトウェアアーキテクチャは以下の組み合わせから構成される • 構造 ◦ システムで使われているアーキテクチャスタイル • アーキテクチャ特性 ◦ システムがサポートすべき「-ility」 • アーキテクチャ決定 ◦ システムを構築する際のルール • 設計指針 ◦ システムを構築する際のガイドライン （再掲） 「ソフトウェアアーキテクチャの基礎」
38. © 2023 LayerX Inc. 38 ソフトウェアアーキテクチャは以下の組み合わせから構成される • 構造 ◦ システムで使われているアーキテクチャスタイル • アーキテクチャ特性 ◦ システムがサポートすべき「-ility」 • アーキテクチャ決定 ◦ システムを構築する際のルール • 設計指針 ◦ システムを構築する際のガイドライン (再掲) 「ソフトウェアアーキテクチャの基礎」 理想のアーキテクチャ 実現のための「型」となる
39. © 2023 LayerX Inc. 39 アーキテクチャ決定 の例 • hoge配下のディレクトリでのみAPIの呼び出しが許可される • 指定したESLintルールをPASSしたコードだけマージする • 新規プロダクトはReactで開発する 設計指針 の例 • TypeScriptの型システムを最大限活用できるコード、技術選定を意識する • フレームワーク依存のロジックは極力避ける • デザイン原則を決める アーキテクチャ決定と設計指針を決め、型に投資する
40. © 2023 LayerX Inc. 40 • 今後は、Enablingチーム(※)と協業して、不定期から定期開催に変更 • 中長期的なカイゼン ◦ アーキテクチャ決定・設計指針を策定し、浸透活動をおこなう • 短期的なカイゼン ◦ 直近で困っている細かい課題を拾っていき、都度対応 ※ Enablingチーム： 　 特定のプロダクトに縛られず、エンジニア組織全体の技術的なイネーブルメントを推進していくチーム フロントエンド・カイゼンWGの再始動
41. © 2023 LayerX Inc. 41 • LayerXのフロントエンドは課題が盛りだくさん • いくつかカイゼン活動を試みたものの、影響範囲が広いものは推進が難しい • 「ソフトウェアアーキテクチャの基礎」 をヒントに改善の方針を決めた ◦ 「アーキテクチャ特性」 によって、優先すべき領域を決定 ◦ 「アーキテクチャ決定・設計指針」 によって、型を決定（している途中） • これから、型を組織に浸透させ、理想のフロントエンドアーキテクチャに！ まとめ
42. © 2023 LayerX Inc. 42 ご清聴ありがとうございました！ 参考文献 • Mark Richards, Neal Ford. 「ソフトウェアアーキテクチャの基礎」 . 島田浩二訳. オライリー・ジャパン, 2022 • 和田 卓人. 「質とスピード（2022春版）」 • mosa. 「開発速度が速い #とは」 • 日本工業規格. 「ISO/IEC 25010 システム及びソフトウェア製品の品質要求及び評価 （SQuaRE）−システム及びソフトウェア品質モデル」 おしまい