0→1開発における技術選定において一番大切なこと

不確実性が多い0→1のプロダクト開発において「技術選定」を行うにあたり重要なポイントについて、経験とノウハウを共有します。

Portfolio: bicstone.me
X(Twitter): @bicstone_me

下記で発表した登壇資料の抜粋です。 (著作権の都合で実際に投影したものとは異なります)

- 【増枠！】CHUO_Tech #2 どんな基準でどう選ぶ！？技術選定の話！！ - connpass

このデッキはアクセシビリティに対応しておりません。記事の内容について後日記事にして公開予定ですのでお待ち下さい。

© 2024 Oishi Takanori

Transcript

1. 2024/04/12 | CHUO_Tech #2 技術選定において 一番大切なこと おおいし @bicstone (C) 2024 Oishi Takanori
2. 自己紹介 Certified ScrumMaster® is a certification mark of Scrum Alliance, Inc. Any unauthorized use is strictly prohibited. SaaS大好き Web エンジニア 前世は機械エンジニア
3. 意思決定を言語化して 属人化を防ぎ、透明性を高める 結論
4. 目次 ADRを記録する いつでも切り離せるようにする アノテーションコメントをする コミットはWHATではなくWHYで 議論は横串で 1. 2. 3. 4. 5.
5. 1. 議論は横串で チーム横断の技術Meetupを開催 → 広い視野で議論ができる。暗黙知を減らせる フロントエンド会、サーバーサイド会を毎週交互に開催 技術選定に関する共有、相談で他チームにも知見が共有 業務委託の方など社外からの視点も
6. 1. 議論は横串で テックブログや登壇などで社外に公開 → さらに情報が集まり意思決定が洗練される 記事化するにあたり言語化のプロセスが発生 社外公開されることで、支持を可視化 世界中からフィードバックが得られる
7. 2. ADRを記録する 技術選定に関する意思決定を言語化して記録する → 意思決定の透明性が高まり、属人性が解消 技術選定の意思決定を型にしていく 言語化・仕組み化に注力し、型を作り上げる 当時の背景がいつでも誰でも参照可能に ※ ADR = Architecture Decision Record
8. 3. いつでも切り離せるようにする 環境や人に依存した技術選定をしない → 改善する姿勢を持ち続け、プロダクトの持続性を向上 記憶、勘、人に頼った技術は頼れなくなると崩壊 定期的に振り返り、時には捨てる勇気 過去の型を改善し、仕組み化し続ける
9. 4. アノテーションコメントをする 実装時の温度感をコメントで残す → 後から意思決定が理解され、軌道修正しやすくなる 時間を優先したなどの意思決定(WHY NOT)を言語化 ツールで検出できる仕組みを作る 過去の実装は変えても良いものという認識を持つ
10. 5. コミットはWHATだけではなくWHYで タスク、PR、コミットは、HOWではなくWHYで残す → 説明責任を果たし、将来の意思決定を支える 背景や文脈が形式知化される 「何をした」ではなく、「何故した」のかを残す プロダクトやチームの特性にあったルールを決める
11. 結論 意思決定を言語化して 属人化を防ぎ、透明性を高める