2023/10/28 Vue Fes Tokyo Vue.js プロジェクト設計のベストプラクティスを求めて

Transcript

1. ©MNTSQ, Ltd.
   2023/10/28
   Vue.jsプロジェクト設計の
   ベストプラクティスを求めて
   Vue Fes Japan 2023
   クラウドサイントラック
   

   View Slide

2. ©MNTSQ, Ltd. 2
   自己紹介
   MNTSQ株式会社
   ソフトウェアエンジニア フロントエンド担当
   安積洋（Azumi Hiroshi）(@cyber_snufkin)
   エンジニア的変遷
   LAMPでバックエンド > フロントエンド
   > ネイティブアプリPjM > アナリティクス
   > フロントエンドに戻る（今ここ）
   Vue.jsはv0.11からv1, v2, v3
   2023/08 のv-tokyoでもお話させていただきました
   Vue.jsの今までをざっくり
   https://speakerdeck.com/cyber_snufkin/vue-dot-jsnojin-madewozatukuri
   

   View Slide

3. ©MNTSQ, Ltd. 3
   フロントエンドにおける設計とは
   

   View Slide

4. ©MNTSQ, Ltd. 4
   いきなりですが
   まず設計フェーズのアウトプットの例
   

   View Slide

5. ©MNTSQ, Ltd. 5
   設計フェーズのアウトプットの例 (1)
   Vue SFCの命名規則
   

   View Slide

6. ©MNTSQ, Ltd. 6
   設計フェーズのアウトプットの例 (2)
   分割されたVue SFCの論理名、Componentのname属性と構造
   

   View Slide

7. ©MNTSQ, Ltd. 7
   設計フェーズのアウトプットの例 (3)
   APIアクセス部分 処理シーケンス（現在はここから新しくなっています）
   

   View Slide

8. ©MNTSQ, Ltd. 8
   設計はなぜ必要なのか
   何故こんなものが必要なのか
   誰得？
   

   View Slide

9. ©MNTSQ, Ltd. 9
   ゼロイチの次のMNTSQ
   フェーズの境界を超えるために、自らを変化させる
   

   View Slide

10. ©MNTSQ, Ltd. 10
    ゼロイチの次のMNTSQ
    MNTSQは現在多くのエンタープライズ企業様に導入頂いています。
    PMF (Product Market Fit) 前の0→1フェーズで必死に探索する時期からその後、
    如何にスケールさせるかを考えるフェーズに入っています。
    

    View Slide

11. ©MNTSQ, Ltd. 11
    コードレベルでの変化
    ゼロイチの次のMNTSQ
    書く速さが重要
    使われて初めてPSF (Problem Solution Fit)
    しているか判断出来る
    PMF前
    プロダクトの価値を決めるのは市場
    とにかく使ってもらえるものを
    早く出したい
    Scrap & Build !
    Feedbackはすぐに反映させたい
    コードレベルでも、価値観は随分変化しました。
    

    View Slide

12. ©MNTSQ, Ltd. 12
    コードレベルでの変化
    ゼロイチの次のMNTSQ
    読む速さが重要
    書く速さが重要
    PMF前 現在
    プロダクトの価値を決めるのは市場
    とにかく使ってもらえるものを早く
    出したい
    プロダクトはすでにBizの前提に
    なっている
    新機能も既存コードとの界面は
    意識しながら書く
    改修はもちろん
    既存コードを読んで直す
    コードレベルでも、価値観は随分変化しました。
    使われて初めてPSF (Problem Solution Fit)
    しているか判断出来る
    Feedbackはすぐに反映させたい
    Scrap & Build !
    

    View Slide

13. ©MNTSQ, Ltd. 13
    人を増やすと加速するプロジェクトとは、
    満たさなければならない幾つかの条件があります。
    読む速さの重要性
    読む速さが重要な理由
    ゼロイチの次のMNTSQ
    チームの人数が増える
    人数を増やす事で逆に減速するPJ、ありますよね？
    新メンバーが参加してAdd Valueできるまでのリードタイムをどう短縮するか
    

    View Slide

14. ©MNTSQ, Ltd. 14
    読む速さが重要な理由
    ゼロイチの次のMNTSQ
    読む速さの重要性
    動くものが早く出来たとしても、読む事にコストが掛かるコードは
    じわじわと真綿で首を締めるようにプロダクトとチームを蝕みます。
    読むことにコストが掛かるコードは
    

    View Slide

15. ©MNTSQ, Ltd. 15
    チームが読めるものを
    チームで書くために
    設計をする
    

    View Slide

16. ©MNTSQ, Ltd. 16
    もちろん、チーム全員が読む技術を持っている事も重要です。
    エンジニア入社時の業務オンボーディングにはデバッグの講習も行います。
    デバッグ手法の共有
    速く読める事に拘る
    ゼロイチの次のMNTSQ
    

    View Slide

17. ©MNTSQ, Ltd. 17
    現在のMNTSQのフロントエンドは、「高速に開発するため」に「遅くならない事を担保する」ための施策を行っています。
    速くする前に、まず遅くならないように
    速くするより、遅くならない
    ゼロイチの次のMNTSQ
    遅くなる要因として読めないコードの他に
    ● 考慮漏れ
    ● 外部要因
    ● 想定外の事態
    等があります。
    どれも踏み抜くと、一気に想定完了時期の精度が下がります。
    (見積もりが難しくなってしまう)
    

    View Slide

18. ©MNTSQ, Ltd. 18
    あとは何と言ってもやっぱりこれですね。
    質を上げることでスピードも手に入れたい。
    本当にこうありたい、と日々思っています。
    質とスピード
    ゼロイチの次のMNTSQ
    https://speakerdeck.com/twada/quality-and-speed-aws-dev-day-2023-tokyo-edition
    

    View Slide

19. ©MNTSQ, Ltd. 19
    自分自身の一日の振り返りの中で「今日は捗ったな」と思う日であっても、
    エディターで書いている時間は思った以上に長くないと思っています。
    エディター上で書く以外の時間に自分は何をしていたのか調べると、「ドキュメンテーション」と「コミュニケーション」
    に続いて、「構造と名前」について考えている事が多いことに気が付きました。
    きちんと作ろうと思うとこの時間、しっかり取る事が多いと思うのですがそれは迷っている時間とも言えると思います。
    チーム内でそれぞれが個別に考えているとすると、それは最初から高めの解像度で考えておいた方が
    結果的にスムーズにゴールにたどり着けるのではないか、と考えました。
    迷わないために決めておく
    速くするより、遅くならない
    ゼロイチの次のMNTSQ
    

    View Slide

20. ©MNTSQ, Ltd. 20
    工数の中身は、コードの行数やドキュメントの量ではなく、
    思考の深さと量
    最初に決める事で考える量と迷う時間を削減して
    「遅くならない事」を実現できるのではないか、
    と考えました。
    工数の中身は「思考の深さと量」
    速くするより、遅くならない
    ゼロイチの次のMNTSQ
    

    View Slide

21. ©MNTSQ, Ltd. 21
    決めておくという事は
    コードを書く際のエンジニアの自由を奪う
    という見方もできます。
    コードを書くという行為は実際の所、様々な決断をする事も含まれています。
    選択肢の前では、設計者と同様の目的に向かって結論を導けるように
    「なぜ」の部分も含めてドキュメントで提示する
    という目的意識も設計者に求められると考えています。
    迷わないためには「なぜ」も必要
    速くするより、遅くならない
    ゼロイチの次のMNTSQ
    

    View Slide

22. ©MNTSQ, Ltd. 22
    設計と開発においてチーム内では、以下の2つを意識するようにお願いしています。
    Principle
    開放閉鎖の原則（SOLID原則の１つ）
    ● 拡張に対しては開いている
    ○ ファイルを追加するだけで機能を拡張できるのがベスト
    ○ 既存ファイルへの改修は最小限になるように
    ● 修正に対しては閉じている
    ○ 修正が必要な場合は、その対象が限定されている
    YAGNI (You ain't gonna need it)
    ● いま必要ないものは実装しない
    

    View Slide

23. ©MNTSQ, Ltd. 23
    遅くならないために、設計をする
    

    View Slide

24. ©MNTSQ, Ltd. 24
    ドキュメントの力を活用する
    良いドキュメントは、書いた人の知らない所で
    勝手に見つけてもらえて
    勝手に疑問に答えて
    勝手に課題を解決してくれる
    

    View Slide

25. ©MNTSQ, Ltd. 25
    ドキュメントの力を活用する
    良いドキュメントは、書いた人の知らない所で
    勝手に見つけてもらえて
    勝手に疑問に答えて
    勝手に課題を解決してくれる
    勝手に仕事をしてくれる
    

    View Slide

26. ©MNTSQ, Ltd. 26
    良いドキュメントは、書いた人の知らない所で
    勝手に見つけてもらえて
    勝手に疑問に答えて
    勝手に課題を解決してくれる
    勝手に仕事をしてくれる
    ドキュメントの力を活用する
    そうする事で、ドキュメントを書く者は
    自分の力にレバレッジを掛ける事が出来る
    何人分もの仕事が出来る
    

    View Slide

27. ©MNTSQ, Ltd. 27
    まとめ
    開発サイクルを速く回すために
    まず遅くならない事を担保する
    改修と機能追加が遅くならないために読めるコードを書く
    開発作業が遅くならないために開発者の思考量と迷いを減らす
    設計はそのためにする
    設計フェーズの成果物は、設計者の代わりに勝手に仕事をする
    

    View Slide

28. ©MNTSQ, Ltd. 28
    設計と開発の中で考えていること
    流行とのおつきあい
    標準との乖離のコントロール
    機械学習プロダクトの設計
    

    View Slide

29. ©MNTSQ, Ltd. 29
    ©MNTSQ, Ltd. 29
    流行とのおつきあい
    迷ったら「楽な方」ではなく「楽しい方」に倒します。
    

    View Slide

30. ©MNTSQ, Ltd. 30
    MNTSQのSLAで定めている対象ブラウザは
    Microsoft Edge（Chromium版）と Google Chrome の最新バージョンです。
    何と言ってもブラウザ
    ブラウザの進化を追いかける
    流行とのお付き合い
    新しい事はどんどん試せます。
    ブラウザの進化を味方につけたい！
    FrontendチームではChromiumの更新タイミングに合わせて、
    その内容を皆でチェックする会を開催しています。
    あまりに面白いのでmtg時間が伸びる傾向に
    

    View Slide

31. ©MNTSQ, Ltd. 31
    スタイルシートの進化にも注目しています
    やはりStyleSheet
    ブラウザの進化を追いかける
    流行とのお付き合い
    やはり難しいものですし（敷居の低さが、タチが良くないとは思いますが）
    Baselineの進化を先取りできれば、という動機でCSSは（一部を除いて）PostCSSとしています。
    ちなみに2023年現在のBaseline機能の例としては
    ● :focus-visible 擬似クラス
    ● 新しいViewport 単位
    ○ svh
    ○ lvh
    ● 要素
    Nesting ModuleもCSS Valiablesも標準で使えるようになったので、
    PostCSSもネタは探し中ではあります
    

    View Slide

32. ©MNTSQ, Ltd. 32
    ©MNTSQ, Ltd. 32
    標準との乖離をコントロールする
    時代の移り変わりに負けないために
    

    View Slide

33. ©MNTSQ, Ltd. 33
    現在MNTSQのフロントエンドはVue.jsで書かれています。
    使い続ける理由としては幾つかありますが、
    フロントエンド領域での標準的なエコシステムと、乖離が比較的少ない
    と考えている事も大きな理由です。
    Vue.jsを使い続ける理由
    標準との乖離をコントロールする
    ● ブラウザのレンダリングエンジンがパースするのはHTMLであってJSXではない
    ○ JSX、Pug等は使っていません
    ○ エディタで書いているものをDevToolsでもそのまま見たい
    ○ 最後の手段でDOMを弄る選択肢も残しておきたい
    ■ そんな時は余裕なんて無いのでサクッと出来るようにしておきたい
    ● 将来的な視野にWebComponentsを入れたい
    ○ 現在すでに大きな開発はComponent志向
    ■ PageComponentではなく、個別のComponentから開発するスタイル
    ● 親から作ると、子コンポーネントに親の知識が入ってしまいがちなのが理由です。
    

    View Slide

34. ©MNTSQ, Ltd. 34
    Sass/LESSは、依存しているUIコンポーネントのカスタマイズに限定しています。
    個別のライブラリの事情に左右されることは避けたいと考えています。
    実はCSSも
    CSSプリプロセッサー
    標準との乖離をコントロールする
    

    View Slide

35. ©MNTSQ, Ltd. 35
    ©MNTSQ, Ltd. 35
    機械学習プロダクトでのフロントエンドの設計
    課題感だけちょっとお話します
    

    View Slide

36. ©MNTSQ, Ltd. 36
    どのような情報なのか
    機械学習プロダクトのフロントエンドの設計
    これらのデータを画面上に表示する中には、
    様々な条件分岐があります。
    このケースの爆発を整理することも
    フロントエンドのミッションです。
    MNTSQ Company Deckより抜粋
    https://speakerdeck.com/mntsq/mntsq-careersdeck?slide=19
    

    View Slide

37. ©MNTSQ, Ltd. 37
    どのような情報なのか
    機械学習プロダクトのフロントエンドの設計
    MNTSQ Company Deckより抜粋
    https://speakerdeck.com/mntsq/mntsq-careersdeck?slide=19
    ● 構造解析
    ○ 文書の木構造
    ○ 条項分解
    ○ 照応解析
    ○ 当事者抽出（契約書上の「甲」「乙」）
    ● NER
    ○ 契約締結日
    ○ 契約期間
    ● 文書分類
    ○ 契約類型分類
    ● 紐付け
    ○ 新たに契約書を作成する際に、内容が似てい
    たり、同一当事者と取り交わした過去の文書
    を抽出
    

    View Slide

38. ©MNTSQ, Ltd. 38
    実際にケースの爆発に立ち向かうために、
    エンティティの型と輪郭（境界）をはっきりさせて、
    複雑なリレーションを整理することが重要としてアプローチしています。
    （リレーションって境界を跨ぐものですしね）
    リレーションの境界で爆発するケースと、エンティティに閉じて起こるケース、分けて考えます。
    フロントエンドエンジニアもE-R図を見ます。
    基本的方針として
    ・今あるAPI設計を信じて乗っかる（追加、改善は一緒にしますが）
    ・エンティティの定義はバックエンドと共通化する
    ・新たな世界を作ったりはしない（勝手にリレーションを想定しない）
    としています。
    機械学習プロダクトのデータを扱う
    ディテールについて公開するのはやはりちょっと難しく、ここでは割愛します。
    

    View Slide

39. ©MNTSQ, Ltd. 39
    最後に
    MNTSQは「すべての合意をフェアにする」という目標を掲げています。
    「すべての合意」は、即ち「すべての人にとっての合意」です。
    A11Y(Accessibility) も重要な課題となります。
    その一方で「機械学習の社会実装」という文脈も、組織の成り立ちから色濃くDNAに持っています。
    これはこの尖った技術を社会に届ける事、誰が見ても気持ちが持てるものにする事を意味します。
    これらはフロントエンドエンジニアの重要なミッションです。
    一緒に取り組んでいける仲間を、本気で探しています。
    We are hiring!
    

    View Slide

40. ©MNTSQ, Ltd. 40
    オープンオフィスやります！
    

    View Slide

41. ©MNTSQ, Ltd. 41
    

    View Slide

42. ©MNTSQ, Ltd. 42
    MedPeerさん、hakomonoさんと
    Vue Fesアフターイベントやります！
    なんと！
    @kazuponさんも登壇！
    

    View Slide

43. ©MNTSQ, Ltd. 43
    ご清聴ありがとうございました！
    

    View Slide

44. View Slide