© LayerX Inc. プロダクトライフサイクルに合わせた 「技術選定」の実践 2024/04/12 CHUO_TECH #2

© LayerX Inc. 2 X: たか @onsd_ 画像を入れてね 自己紹介 Takamichi Omori バクラク事業部 バクラクビジネスカード エンジニア Go / TypeScript でプロダクト開発をやっています 趣味 - バスケットボール 🏀 - フリースタイルスキー 🎿 - リアル脱出ゲーム・謎解き 🤯

© LayerX Inc. 3 「技術選定」のイメージ

© LayerX Inc. 4 「技術選定」という言葉のイメージ 「技術選定」のイメージ 自分が持っていた「技術選定」 のイメージ - どんな言語でプロダクトを作 のか？ - フロントエンド（FE）とバックエンド（BE)の通信はどう行うのか？ - フロントエンドはどんなフレームワーク・ライブラリを使うのか？ 「技術選定」 の意義 (Claude3 Haiku) - プロダクトの要件やチームの状況に合わせて最適な技術を選定す - 適切な技術を選べ と、生産性や品質が高ま - 不適切な技術を選んでしまうと、開発の遅延や技術的負債が増大してしまう 「技術選定」は、単なる「技術的な方針決定」ではなく、お客様への価値提供に直結する活動

© LayerX Inc. 5 実はたくさんある技術選定のチャンス たくさんある技術選定のチャンス ● プロダクトの立ち上げ ○ 作 プロダクトやチームなどの要件をもとに使用す 技術を選ぶ ● 今使っている技術の置き換え ○ 技術は常に進歩してお 、よ 優 た選択肢がでてく ことがあ ● 新しい課題への対応 ○ プロダクトを運用していくなかで、新しい課題が生ま ことがあ ○ 新しい課題に対して、新しい技術を導入す ことで対応していくことができ

© LayerX Inc. 7 GraphQL スキーマの破壊的変更への対策 新しい課題へ技術の導入で対応した例 たくさんある技術選定のチャンス - 背景 - バクラクビジネスカードは GraphQL を使って FE・BEが通信を行ってい - 誤ってFEが利用してい フィールドを削除してしまい、 スキーマのバリデーションエラーが起こ 状態になってしまう問題が発生 - やったこと - スキーマの破壊的変更は段階を踏んで行うようにガイドラインを設定 1. deprecated ディレクティブをつけ 2. リクエストが来なくなったことを確認して当該フィールドを消す - ガイドラインを強制す ためにCIを整備(Bet Technology) - 選定のポイント - 自動で判定でき こと - GitHubのスターが多いなど、利用者があ 程度い こと

© LayerX Inc. 8 GraphQL スキーマの破壊的変更への対策 新しい課題へ技術の導入で対応した例 たくさんある技術選定のチャンス - CIへ追加した設定 - BE: graphql-inspector の suppressRemovalOfDeprecatedField を活用 => スキーマに破壊的変更をしようとしたときにCIが fail す ように - FE: @graphql-eslint/eslint-plugin の導入・@graphql-eslint/no-deprecated を error に => deprecated なフィールドを利用してい ときにCIが fail す ように - 効果 - GraphQLスキーマの破壊的変更が難しくなった - deprecated なフィールドを使ってい ことに気づきやすくなった - ガイドラインだけでなく、CIの設定に落とし込んだので今後も守られるルールになった → 運用していく中で生まれた課題に適切な技術で対応することができた

© LayerX Inc. 9 技術選定のタイミングはさまざま - プロダクト立ち上げ - 使ってい 技術よ よいものがでたとき - 新しい課題が生ま たとき まとめ だれでもできる技術選定 - 立ち上げじゃなくても技術選定のチャンスはあ - 細かい改善を積み重ねてよ よいプロダクトを作 う まとめ

© LayerX Inc. 10 We Are Hiring!