ID:80671さん

## 問題空間を適切に判断する能力 プロダクトが提供するサービスや機能によって、解決すべき問題は何なのかを見極める能力をつける。 出てくる課題をすべて解決することは現実的に不可能なので、自分たちは何が解決できるのかの判断力は日々高めていく必要がある。 そのためには、対象ドメインそのものやQA、SREとしての観点、各種SaaSサービス、クラウドインフラ、OSS、LLM、下記に挙げている技術の理解を広く、深く追及する必要がある。 ## より深いTypeScript / React の実装力 サービスが成長し続けるためには、フロントエンドにおいては型安全性とReactの思想に沿った実装がどこまで実現できるかが重要。 TypeScript であれば、型システム（ジェネリクス・条件型・mapped type 等）を適切に活用し、 React であれば、再レンダリング制御・カスタムフック設計・コンポーネント設計パターン（Compound Component・Server Components・Feature Sliced Design 等）を実践し可読性の高い構造を目指す。 ## ユースケースを適切に非同期に逃がし統制する技術 LLMを組み合んだプロダクト機能開発を進めていく中で、非同期処理の実装パターンを検討する必要がある。 また、業務要件が複雑化、多岐にわたっていく中で、すべての処理を同期的なDBトランザクションで処理することは拡張性が低い。 その一方で、非同期な処理は疎結合・高凝集なコードベース管理が難しく、認知負荷が高い。 お互いのペインポイントを捉えつつ、技術負債が臨界点を迎えないように、理解容易性、変更容易性の高い実装はどうあるべきか？を追求する。 ## スキーマ駆動開発の実践 人間またはLLMが記述するコードはできるだけ少なくすることが技術負債の抑制に繋がる。 そのためにはOpenAPI / GraphQL 等を用い、仕様を起点にコード生成（またはコード起点の仕様生成）・テスト・ドキュメントを連動させる仕組みを整備し、フロントエンド・バックエンド・外部クライアントとの疎通をいかにスムーズにできるか意識する必要がある。 ## IaC 開発、検証環境の管理コストや問い合わせ対応、その他業務処理の負担はできる限り抑える。 IaCが普及することで、属人化を防ぎ、組織体制、開発チームの流動性確保につながる。 ## エッジコンピューティング、サーバレス インフラコストやレイテンシの良さを考えると、新規開発やリアーキテクチャの選択肢として重要。 ただし技術的な制約やベンダーロックインとなり得る面が懸念されるため、既存インフラと掛け合わせつつ デメリットをリカバーし、なおかつそのメリットを最大限享受できるような提案を積極的に行い経験を積む必要がある。