LLMの台頭
今年はなんといってもChatGPTやらCopilotやらLLMツールの台頭の一年だったと思います。
開発体験が大幅に変わりましたし、会社の採用方針にも影響がありました。
今後は関数やユニットテストの実装は誰が実装しても品質の差がそこまで大きく出ないようになるので、空いたリソースをシステム設計・ビジネス理解・オペレーション構築などに割いて、プロダクト特有の勘所を鍛えられるかどうかがエンジニアに求められるのかな〜と思います。
また、エンジニア自身の開発スタイルだけではなく各種プラットフォームやOSSの更新頻度もかなり加速したような印象があります。これ自体は嬉しいことですが、技術のアップデートについていくコストも上がった感触もあり、スタートアップ・ベンチャーのような少人数で開発するビジネスでは、これまで以上に安定感のある技術を選定するのが無難になりそうです。
情報発信を始めた
このブログもそうですし、XやZennでの情報発信を始めました。
とはいえまだ方向性がブレてたり更新頻度が疎だったりするので、2024年は計画的に取り組んでいこうと思います。
本業の学びとか
これは別途会社の方でも記事にしたいんだけど、大まかにこんな感じ
- AWSのマルチアカウント運用
- できるならばベストプラクティスに沿ってOrganizationsを分けて、プロダクトや環境ごとにアカウントも分けて運用するのが長期的に良い
- 一方で最初期からそんなところにリソース割けるかという感じもあるので、エンジニアのスキルセットと相談
- 採用とか組織とか。特にLLM系前後の採用方針とか
- 当初はフロント・バック・インフラ全て見れるスキルセットがマストだったが、最近はカルチャーマッチすれば技術力は問わないぐらいに要件を引き下げて見ている
- CRMを初期フェーズから導入する重要性と難しさ
- ここはビジネスモデル次第だけど、自前の簡易なものでも良いから顧客マスターと商談進捗を記録するDBはあったほうが良い。
- なんやかんやで色んなプロダクトからマスターデータを見にいくので、API生やせてメンテ工数かからないのが望ましい
- ビジネスロジックとか持つことはないはずなので、Hasuraとか使って簡単にCRUD処理を実装して、何らか連携が必要な部分やどうしてもロジックを持ちたい部分はクライアント側に実装するか、Lambdaとかに切り出せば良いんじゃないかな
- データ起点での技術選定
- データのライフサイクルの意識してDBや技術の選定をしたかった
- 頻繁に加工して良いのか、監査目線で証跡を残す必要があるのか
- マスターデータかトランザクションデータか