技術選定の仕方 - FLEXYウェビナー / How to select technology

Transcript

1. 理論と実践から知る、良い技術選定 〜採用にも成長にも使える技術選定の観点〜 shinden tomohiro 2025/05/21 Meetup
2. 理論と実践から知る、良い技術選定 〜採用にも成長にも使える技術選定の観点〜 shinden tomohiro 2025/05/21 技術選定の成功とは？ 成長のための技術の観点は？ 採用で聞く技術選定の質問は？ 幅広い実践の経験から 事例で見る技術選定 SIer・メルカリ・サイバーエージェント ・スタートアップ・バーティカル SaaS Meetup
3. 自己紹介 名前：新田智啓 (Shinden Tomohiro) 　　　ふりがなが無いと99%読み間違えられます 経歴：SI系とWeb系の両方で開発を経験 　　　新規システムの開発、新規事業の開発も経験　　　 2001年〜 SIer数社 ・エンジニア、テックリード、エンジニアチームマネージャなど 2014年〜 サイバーエージェント ・アドテクスタジオ、エンジニア、開発責任者、技術責任者、子会社 CTOなど 2018年〜 メルペイ ・バックエンドエンジニアリングマネージャ、テクニカルプログラムマネージャ 2020年〜 カケハシ ・エンジニアリングマネージャ、開発ディレクター 現在 株式会社Datachain - 新技術を活用し、世界の金融システムをアップデートする
4. 技術選定を上手くやりたい
5. 技術選定を上手くやりたい 5 技術選定が上手くいったときってどんなとき？ 上手くいった技術選定 • 機能を開発するスピードが早かった • チームのスキルセットとマッチしていた • 技術が古くならずに使いやすくアップデートされている • 新しい機能を追加するときに開発しやすい • 新しい技術を身につけることができた • ドキュメントやコミュニティが充実していて、問題発生時に対処ができた
6. 失敗な技術選定 • 流行ってるからという理由だけで採用する • 特定のメンバーの趣味で選定される • 実績の少ない技術を採用する • 将来のスケーラビリティを見て過剰な構成 • 技術選定プロセスをドキュメント化していない • 他社事例を安易に真似する 失敗の結果 → プロダクトとの相性を考慮せず導入して苦労する → その人が抜けたらメンテできない／属人化する → 情報が少なくてトラブル時に困る → 初期開発が複雑になりすぎて開発スピードが出ない → なぜ選んだのか誰も分からなくなり、変えれない → 背景や規模が違いすぎて全く活かせなかった 技術選定を上手くやりたい 6 技術選定が上手くいかなかったときってどんなとき？
7. ▼成長したいエンジニア エンジニアとして成長の方向性を知れる • 自分の足りない技術要素を知ることができる • 新しい考え方の気付きが成長につながる 技術選定を上手くやりたい ▼成長を支援したいマネージャ マネージャとして成長を促すときに伝えられる • 整理、言語化されることで、成長を促す観点を伝える ことができる 7 技術選定が上手くできるエンジニアは良いエンジニア ▼転職の候補者 面接を受けるときに自分の力を適切に伝える • 技術の取り扱う観点を伝えることで、技術の理解の深 さを伝えることができる • 未知の技術が現れたときにどのように技術に対して アプローチするかを伝えることができる ▼採用の面接官 選考のときに技術を使いこなすエンジニアを見極める • 技術選定の考えを見ることで、どこまで深く技術を理 解して取り扱っているかが分かる • リードエンジニアの役割を任せられるかを見極められ る • 技術に対しての自社でどのような観点で取り扱ってい るかを伝えることができる
8. 第１部 - 技術選定の理論を知る
9. 技術選定を成功させるには 9 技術選定を成功させるには「技術選定の成功の条件を決めること」 どういう状態が成功か決めずに進んでも、成功かどうか判定できない 技術選定の成功はどういう状態が成功なのかは全てのケースで「場合による」 • 事業的な価値が重要なときもあれば、組織を優先したいケースも有る • 小さく始めて試したい場合と、大きなシステムを失敗なく作りたい場合がある • 技術的に使いやすいだけでは、事業戦略に合わない場合もある • 計画が大事なときもあれば、実験と経験が大事なこともある では、どうやって成功の条件を決めればよいのか？
10. 技術選定を成功させるには 10 技術選定の成功の条件を決めるための基本的な理論 • 目的思考 ◦ 何を達成したいのかをぶらさない • 制約思考 ◦ 現実的で合理的なトレードオフの実現 • 進化適応 ◦ 未来の変化に対応する
11. 技術選定を成功させるには 11 「技術選定の成功の条件を決める」ために必要なこと 　技術の周辺まで含めて見る 技術を外から見る 　利害関係者、リスク許容度、フェーズなどの軸を見る 複数の軸で技術を選定する 　制約、障害、実現したいことの関連を整理する 重要項目を明確にする
12. 技術選定を成功させるには 12 「技術選定の成功の条件を決める」ために必要なこと 　技術の周辺まで含めて見る 技術を外から見る 　利害関係者、リスク許容度、フェーズなどの軸を見る 複数の軸で技術を選定する 　制約、障害、実現したいことの関連を整理する 重要項目を明確にする
13. 技術チームしか見ていない 13 技術を外から見る - 　技術の周辺まで含めて見る 技術の周辺も見る 技術 開発組織 技術 システム ユーザー価値 開発組織 エンジニア 採用・育成 人的流動性 技術的負債 将来性・PoC 開発契約 事業の実現 営業　　 マーケティング 市場
14. 14 技術を外から見る - システムをつくる目的に、実現したい価値がある ユーザー価値 実現したいこと システム 利用される やりたいことは システムをつくること ではない エンジニア的には こちらに 注目しがち 本当はこちらが 大事なときが多い
15. 技術を外から見る - 　技術選定が与える影響の力学を知る 15 技術が価値を発揮するまでにはステップがある 技術 開発組織 事業の実現 ユーザー価値 システム エンジニア 選択して 取り入れる 実現する 利用される やりたいことは システムをつくることではない ほとんどの場合は制約条件に当たる 実現したいことは 価値を実現すること 目的思考 技術そのものがシステムをつ くるのではなく チームのメンバーがつくる 世の中で数多くの 新しい選択肢があり 絶対的な正解はない
16. 技術選定を成功させるには 16 「技術選定の成功の条件を決める」ために必要なこと 　技術の周辺まで含めて見る 技術を外から見る 　利害関係者、リスク許容度、フェーズなどの軸を見る 複数の軸で技術を選定する 　制約、障害、実現したいことの関連を整理する 重要項目を明確にする
17. 17 複数の軸で技術を選定する 今回の例：４つの軸を紹介 • 時間軸　リリースするまで、リリースした後 • 事業軸　事業を立ち上げ、PMF模索、グロースフェーズ • 組織軸　今できること、将来できるようになること、採用 • 技術軸　流行り廃り、使い勝手、将来性
18. 成長模索 運用 追加開発 複数の軸で技術を選定する - 時間軸 18 定義された目標までの期間と目標から先の期間がある 開発中 リリ ｜ス グロース 運用 追加開発 開 発 開 始 短期的 機能要件がある つくり方を考える 中長期的 機能要件がない 何をつくるかを考える
19. 成長模索 運用 追加開発 複数の軸で技術を選定する - 時間軸 19 定義された目標までの期間と目標から先の期間がある 開発中 リリ ｜ス グロース 運用 追加開発 開 発 開 始 短期的 機能要件がある つくり方を考える 中長期的 機能要件がない 何をつくるかを考える なぜつくるかを考える 技術選定の力学 から逆算する
20. 複数の軸で技術を選定する - 事業軸・組織軸・技術軸 20 それぞれの軸と時間軸を掛け合わせてみる 短期 中長期 事業 組織 技術 事業を立ち上げ、PMF模索 グロースフェーズ、安定域 今使えるスキル、早くできる エンジニアの成長、組織ブランディング 今ある機能、使い勝手 流行り廃り、将来性、コンセプト 進化適応 未来の変化に 対応する
21. 複数の軸で技術を選定する - 色々な軸と掛け合わせる 21 時間軸と掛け合わせるとそれぞれに違う技術の選び方が見える 今必要ないからと言って、今やらなければ、 いつかの未来は来ない 事業のための大きな技術的負債を積むか 事業としては成長しても組織として成長しない広がりのない組織を許容するか 枯れた技術ばかりを選ぶことで組織が持つ技術スキルが進化できなくなってしまう
22. 技術選定を成功させるには 22 「技術選定の成功の条件を決める」ために必要なこと 　技術の周辺まで含めて見る 技術を外から見る 　利害関係者、リスク許容度、フェーズなどの軸を見る 複数の軸で技術を選定する 　制約、障害、実現したいことの関連を整理する 重要項目を明確にする
23. 23 重要項目を明確にする - 実現したい価値がある ユーザー価値 実現したいこと システム 利用される やりたいことは システムをつくること ではない こちらに 注目しがち こちらが 大事なときもある
24. 重要項目を明確にする - 制約、障害、実現したいことの関連を整理する 24 技術が価値を発揮するまでには制約や障害がある 技術 開発組織 事業の実現 ユーザー価値 システム エンジニア 選択して 取り入れる 実現する 利用される 人は足りる？ 採用はできる？ 能力はある？ 運用コストは低い？ 想定通りできる？ 期待通り動く？ ちゃんと使われる？ 届けれている？ 目的に 届くまでの技術をど う選ぶ？
25. 重要項目を明確にする - 全てを選べない中で決める 25 無限の時間や無限の資金を使えることはない • 全てを満たすものは存在しない、全ての選択にトレードオフがある • 検討が多いほど技術選定の精度は上がるがコストも上がる 　↓ 「重要な項目」 と「重要ではない項目」を精査し、技術を選ぶ基準を作る • 目的・制約・未来などのバランスを自分たちで定義することで 何が重要であるか、自分たちの価値観を明確にしていく
26. 最後に 「技術選定の成功の条件」を決める ３つの手法紹介
27. 良い技術選定を進める方法１ 27 技術選定の成功の条件を確認するために 「ADRを書こう！」 なぜADRを書くのか？ • いつも完璧に技術選定が出来るわけではない ◦ 時間的制約や不確実な状況で技術を選ぶ必要があるときもある • 重要項目のチェックをテンプレートに入れよう ◦ 今回の観点の中からチームの重要な項目をテンプレートに入れて考慮漏れを減らそう • みんなの叡智を集めよう ◦ 知識を集めることができる・目的をはっきりさせる ◦ 議論を発生させ合意を取れる・意思決定の記録を残す
28. • タイトル ◦ 意思決定の内容を簡潔に • コンテキスト ◦ 決定を行うに至った背景や状況、関係する要素や制約などを説明する ◦ 議論した観点や時間的な制約で整理しきれなかったことなど • 決定 ◦ 実際に決定した技術の方針や手法 • ステータス ◦ このADRの現在の状態（下書き、提案、承認、非推奨） • 結果 ◦ アーキテクチャの状態や影響 ◦ 得られた効果（プラスの影響）や問題点（マイナスの影響）など 28 ADRの基本的なまとめ方
29. 良い技術選定を進める方法２ 29 技術を選ぶための意思決定の基本ステップを実行する (デザイン思考でも使われるステップをベースしたもの ) ① 共有する ②発散 各個人で持っている 情報を全体に共有する ③収束 ④発散 ⑤収束 見るべき 観点を 出し合う 重要項目を 絞り込む ⑥ 意思 決定 重要項目を 満たす 手段を出す 最も最適な 方法を選ぶ
30. • 情報の共有せずに失敗 ◦ アイデアを募っても、情報が足りなくてアイデアを出せない ◦ アイデアを出しても、出来ない条件の情報が後出しで共有される ◦ システムで実現したい価値が分からないまま決めてしまう • 重要項目を出さずに手段を選ぶ失敗 ◦ 重要ではない項目のメリットを見て意思決定 ◦ 技術・事業・組織のバランスに戦略がない ◦ 星取表で丸が多いものを選んでしまう • 手段を複数出さずに決め打ちで選んで失敗 ◦ もっと良い選択肢があったのに検討できていない ◦ 考慮できていない観点で技術的負債の発生源になる ◦ pros/consを整理せずに良いことだけで決めてしまう 自分たちのチームの議論がどのステップにいるか意識しながら進めることが重要 30 技術を選ぶステップでの失敗
31. 良い技術選定を進める方法３ 31 技術選定なのに技術の話が少ない？ 技術選定の話なのに プログラミング言語 フレームワーク アーキテクチャ ライブラリ などの話がない？
32. 技術選定を成功させるには 32 技術選定なのに技術の話が少ない？ AIに聞いたらいい
33. 技術選定を成功させるには 33 AI 時代に 技術選定はどう変わるのか 安定した技術を使おうと思ったら AIが知っている情報で十分足りる それを元に深堀りして調査するので良い 観点を整理できていれば pros/consの表も作ってくれる 説明内容は 間違っていることも 多いので 確認は自己責任でする 生まれたてホヤホヤの技術を 使うことはほぼない。ユーザ が増えて安定したものを使う ケースがほとんど
34. 技術選定を成功させるには 34 AI 時代に 技術選定はどう変わるのか AIは価値観は答えはくれない AIを活用しても 技術選定の成功の条件 は 自分たちで決める必要がある！ 技術の価値を自ら定義できる 価値の高いエンジニアになろう！
35. 第１部完 技術選定の理論を知る 技術選定の成功には 技術選定の成功条件を決めよう
36. 第２部 - 技術選定の実践を知る
37. • 新田が技術選定していないものもあります ◦ あくまで個人的な観点での意見であり、技術選定したメンバーの意見や情報は十 分に理解せずにお伝えするものもあります • 当時と今の知識には大きな差があるため、現時点の知識で解説します ◦ 技術や開発フローも世の中での進化もあるため、現在ではもっと良い方法が多く ある可能性がありますが、当時は最適な選択の可能性があります 37 技術選定の観点から見てみる
38. 38 経験してきた会社 My History 2001 アドテクノロジー 広告配信システム Engineer 開発責任者、技術責任者 子会社CTO 2014 スマートフォン決済 Engineering Manager Technical Program Manager 2018 薬局向けSaaS スタートアップ 開発ディレクター Engineering Manager 2020 2024 複数の顧客先で システム開発 Engineer TechLead ブロックチェーンを 実社会に適応する スタートアップ Engineering Manager CyberAgent Kakehashi Small SIers Merpay Datachain 38 now student
39. 39 経験してきた会社 My History 2001 2014 2018 2020 2024 CyberAgent Kakehashi Small SIers Merpay Datachain 39 now student SIer・SES メガベンチャー スタートアップ エンジニア エンジニアリングマネージャー
40. 40 経験してきた会社 - SES・SIer • 事業 ◦ 契約管理、交通系ICカード在庫管理、不動産物件の申請書管理、映画館チケット 販売Webサイト、不動産賃貸Webサイト、旅行パッケージ管理 ◦ システムに目的の機能が実装できるまでが契約 • 開発組織 ◦ プロジェクトごとに開発現場に集められ、プロジェクト完了すると解散する ◦ 自社の採用には関わらないし、同じ現場に来る人も多くはない • 技術 ◦ 開発現場で決められた技術を使う、C、Java、Struts、JSP、Velocity、Seasar、 JSF、Click、Tapestry、SAStruts、オンプレしかない時代
41. 41 経験してきた会社 - サイバーエージェント • 事業 ◦ アドテク事業、新規立ち上げや既存事業の推進、RTBのDSP、DMPなど ◦ ハイトラフィック (10万QPS)、低レイテンシ (100ms)、ビッグデータ (１日数億レ コード)などを考慮する必要がある • 開発組織 ◦ JavaやScalaを使うチームが多く、100人規模の開発人員が部署にいる ◦ 当時は既に技術ブランドがあり、Scalaでは国内のトップレベルの発信組織 • 技術 ◦ Java、Scala、Redis、Aerospike、BigQuery、Redshift、Finagle、Cats、 Dataflow、KinesisStream、Fluentd、ProtocolBufferなど
42. 42 経験してきた会社 - メルペイ • 事業 ◦ スマートフォン決済事業、リリース前の立ち上げ期 ◦ 金融事業のため、１リクエストも落とせない、１円もズレてはいけない ◦ 新規立ち上げの部分と既存のメルカリからの切り出しの部分があった • 開発組織 ◦ 100人規模の開発組織、既にメルカリ文化がベースにある ◦ GoやGCPで非常に注目を集める認知がある組織になっていた • 技術 ◦ Go、マイクロサービス、Kubernetes、Spanner、Stackdriver、Dataflow、 Terraform、BigQuery、Datadog、 Spinnakerなど
43. 43 経験してきた会社 - カケハシ • 事業 ◦ スタートアップ、コンパウンドスタートアップとして拡大中のフェーズ ◦ 薬局向けSaaSを提供、医療系ドメインでありミッションクリティカル • 開発組織 ◦ ３年で100人規模から300人規模の会社になる急拡大の時期 ◦ スタートアップ界隈ではキャッチアップが早い人にはかなり知られていたが、エン ジニアからはほとんど知られていない、フルリモート • 技術 ◦ Python、TypeScript、Terraform、Glue、AppSync (GraphQL)、Aurora、 Lambda、Cognito、Fargate、Datadog、Databricksなど
44. 44 経験してきた会社 - Datachain • 事業 ◦ 大きな挑戦を目指し、技術ドリブンの会社で５年間の研究開発を経て、直近は サービス開発を強化し、複数事業の立ち上げを行っている真っ最中 ◦ 金融事業が中心であり、次世代の金融プラットフォームになるものを作る • 開発組織 ◦ まだ少人数の組織だが、１つ１つの事業がユニコーン級 (時価総額 1500億円) 以 上を狙う事業のため、それなりの規模の組織が必要になる計画。 ◦ エンジニアから知られていないが成長が必要な会社 • 技術 ◦ ブロックチェーン技術の実社会への適応、新技術の発明、新技術のサービス適応 のための開発、Go、Solidity、Azure、Argo Workflows、OpenTelemetry、 Chainlink、getblock、IBC、LCP
45. どれか１つでも当てはまる人は是非 Datachainに来てください！ • Webの技術に少し飽きて、新しい技術にチャレンジしたい方 • コモディティ化していない技術を使い、事業を推進したい方 • グローバルの金融を変える大きな挑戦に興味がある方 募集中 45 Datachainではハイレベルなエンジニアを募集しています
46. FAQ
47. 47 重要な項目って例えばどういうもの？ (要件の技術的トレードオフ以外) • 短期と中長期のトレードオフ ◦ 短期的な機能の開発のために中長期的なリスクを追うのか ◦ 中長期の効率的な成長のために運用に耐える仕組みを作り込むのか • つくりやすさ vs つかいやすさのトレードオフ ◦ 僅かな使いやすさ向上のためにコストが数倍高まることもある • 変更のしやすさ ◦ 失敗したときに戻せる状態でつくるか (可逆可能な意思決定) ◦ 検証を行う意思決定やリリース様子をみて決める小さな意思決定 • 安定的な技術選択と挑戦的な技術選択 ◦ 慣れた技術は短期的には最速 ◦ だが、安定的なものばかり選んでいると技術の進化ができない組織になる
48. 48 事業を深く理解してシステムをつくるにはどうすればいいの？ • 事業をシステム化する手法を使うと良いでしょう ◦ DDD ◦ イベントストーミング ◦ ユーザーストーリーマッピング ◦ RDRA ◦ ICONIX ◦ BABOK ◦ など • いきなり実装を始めたくなりますが、まずは整理することで価値がわかります • つくることがゴールではなく、成功することがゴールの場合は急がば回れです
49. 49 技術負債のない技術選定をするにはどうすればいいの？ • 未来予知ができるようになるしかない！ • 無理なら精度は100%にはならない • 僕らは予知はできず、予測しかできません • 技術負債がなくならない前提で、技術的負債がなるべく少なくなる選択をする • 加えて、技術選定が失敗だったとしても、当時の分かっていた情報の範囲での意思決 定しては最適であったと納得できる状態になること • 捨てやすく作っておく、変更しやすく作っておく
50. 50 興味あったり、好きだからという理由で技術を選んでも良い？ • 良いと思います！ • 興味というモチベーションや慣れている技術を使うことは生産パフォーマンスに大きく影 響するファクターです • 重要項目の中に入っているか確認しましょう
51. 51 成功の条件ってそんなに大事？ • 大事だと考えています • もやもやする技術が選択されそうになったら、それを言語化することが大事 • おそらく考慮、議論されていない重要項目がある可能性があります • この工程はみんなの知識を集めてより良いものを作るという意味と自分たちの現時点 での知識と情報を検討しきったという納得を得るために必要です • それを客観的な情報としてADRにまとめることが重要です • ADRを書くことがゴールではありません • 重要なポイントがどこにあるかを議論し、記録することが重要です
52. 52 FLEXY meetup - 技術選定を知る FLEX meetup Finish • 資料のSNS拡散歓迎 • コメント・感想お待ちしています