CHUO Techは、中央区に会社のある企業が集まって立ち上げられた勉強会です
今回のテーマは「技術選定」です
背景
4月12日に行われたCHUO_Techに行ってきました！
ここに登壇された方々のLTのスライドを紹介させて頂きます！
全体で方針決めてスモールチームで技術選定
技術選定の目的
チームが楽しく快適に技術を使えること
スモールチーム
- 3~5人
- 1サービス内でもチームが分かれている
- メリット
- 責任範囲が明確
- 素早い技術選定が可能
技術選定をするには使い続ける覚悟も必要
- 数年は使い続ける
- 発生したトラブルを解決する
5年後にどうなっていたいか
- モノリシック目指す
- 必要に応じてマイクロサービス化も検討
- フットワーク軽い技術選定
↓
これが「チームが楽しく快適に技術を使えること」を実現する
ビジネスを加速する技術選定
フルスクラッチ or SaaS
フルスクラッチ
メリット
- 自由度が高い
- 自社でデータを所有できる
デメリット - 将来的に人的コストが高くなる
SaaS
メリット
- 初期コスト、運用コストが低い
- 迅速に導入できる
デメリット
- カスタマイズの限界
- サービス停止リスク
- 機能過剰
何に重きを置くか
フルスクラッチ
中長期的にコア技術になる
SaaS
一元管理によるCSコスト減
プロダクトライフサイクルに合わせた 「技術選定」の実践
「技術選定」の意義
単なる「技術的な方針決定」ではなく、お客様への価値提供に直結する
実は技術選定のチャンスはたくさんある
- プロダクト立ち上げ
- 使用中の技術のリプレイス
- 課題への対応
0→1開発における技術選定において一番大切なこと
意思決定を言語化して属人化を防ぎ、次ある意思決定に生かす
横串で議論する
- フロントエンド、サーバーサイド会の実施
- 他チームにも知見が共有される
- テックブログに技術選定記事を公開し、リアクションをみたりフィードバックをもらう
↓
広い視野で議論ができる
技術選定に関する意思決定を言語化して記録（ADR）する
技術選定の意思決定を言語化、仕組み化し型を作る
↓
背景を誰でも理解でき、属人化を回避できる
いつでも捨てられるようにする
環境や人に依存した選定をしない
定期的に振り返り、時には捨てることも必要
アノテーションコメントをする
当時の実装した際の温度感をコメントに残す
例）時間優先した等の意思決定（WHY NOT）
↓
内容によっては過去の実装を変える為の背中を押してくれる
タスク、PR、コミットはWHATではなくWHYで
背景や文脈が形式知化される
↓
将来の意思決定に活かせる
0→1と1→10の狭間で Javaという技術選定を振り返る
Javaを選定した理由
0→1の開発スピード、コードに注力できることを重視した
- 社内エンジニアの技術スタック
- その言語のエコシステムが成熟していた
Java or Ruby
Javaにした
- 長く使われるプロダクトにする為、静的型付が魅力
- その業界でJavaが使われていた
- バージョン間の後法互換性が高い
Java選定後の苦労
- 参考リソースの不足
- ヌルポ（登壇されてた方がヌルポを連呼されてました😂）
技術選定をし直す
多様なスキルセットを持つ人が増えた
- 1年後に自分達がやりたいことができるか
- 例）ドメインの表現力
- 実現可能性
ドクターメイトがRustを全面採用するに至った経緯
スライドが見つかりませんでしたので内容が簡単になります。すみません。。
技術選定の基準
ワクワクする開発
Rustを全面採用した経緯
TSよりエラーの型が厳密、堅牢
Rustに慣れる
- 毎日15分AtCoderのA,B
- コードリーディング
エンジニア採用と生産性からみた技術選定
スライドが見つかりませんでしたので内容が簡単になります。すみません。。
事業、人事の観点から技術選定をされていました
最後に
- 勉強になることばかりでした、業務に生かします
- できる所から技術選定に引き続き携わっていきたいです！
- 次回もあるそうです！
ハコベルさんのボールペン掴み取りだったんですが、掴みすぎてびっくりされました
本記事を読んで頂き、ありがとうございました。
いいねいただけると記事執筆の励みになりますので、参考になったと思われた方は是非よろしくお願い致します🙏