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

Slide 1

Slide 1 text

理論と実践から知る、良い技術選定〜採用にも成長にも使える技術選定の観点〜 shinden tomohiro 2025/05/21 Meetup

Slide 2

Slide 2 text

理論と実践から知る、良い技術選定〜採用にも成長にも使える技術選定の観点〜 shinden tomohiro 2025/05/21 技術選定の成功とは？成長のための技術の観点は？採用で聞く技術選定の質問は？幅広い実践の経験から事例で見る技術選定 SIer・メルカリ・サイバーエージェント・スタートアップ・バーティカル SaaS Meetup

Slide 3

Slide 3 text

自己紹介名前：新田智啓 (Shinden Tomohiro) 　　　ふりがなが無いと99%読み間違えられます経歴：SI系とWeb系の両方で開発を経験　　　新規システムの開発、新規事業の開発も経験　　　 2001年〜 SIer数社・エンジニア、テックリード、エンジニアチームマネージャなど 2014年〜サイバーエージェント・アドテクスタジオ、エンジニア、開発責任者、技術責任者、子会社 CTOなど 2018年〜メルペイ・バックエンドエンジニアリングマネージャ、テクニカルプログラムマネージャ 2020年〜カケハシ・エンジニアリングマネージャ、開発ディレクター現在株式会社Datachain - 新技術を活用し、世界の金融システムをアップデートする

Slide 4

Slide 4 text

技術選定を上手くやりたい

Slide 5

Slide 5 text

技術選定を上手くやりたい 5 技術選定が上手くいったときってどんなとき？上手くいった技術選定 ● 機能を開発するスピードが早かった ● チームのスキルセットとマッチしていた ● 技術が古くならずに使いやすくアップデートされている ● 新しい機能を追加するときに開発しやすい ● 新しい技術を身につけることができた ● ドキュメントやコミュニティが充実していて、問題発生時に対処ができた

Slide 6

Slide 6 text

失敗な技術選定 ● 流行ってるからという理由だけで採用する ● 特定のメンバーの趣味で選定される ● 実績の少ない技術を採用する ● 将来のスケーラビリティを見て過剰な構成 ● 技術選定プロセスをドキュメント化していない ● 他社事例を安易に真似する失敗の結果 → プロダクトとの相性を考慮せず導入して苦労する → その人が抜けたらメンテできない／属人化する → 情報が少なくてトラブル時に困る → 初期開発が複雑になりすぎて開発スピードが出ない → なぜ選んだのか誰も分からなくなり、変えれない → 背景や規模が違いすぎて全く活かせなかった技術選定を上手くやりたい 6 技術選定が上手くいかなかったときってどんなとき？

Slide 7

Slide 7 text

▼成長したいエンジニアエンジニアとして成長の方向性を知れる ● 自分の足りない技術要素を知ることができる ● 新しい考え方の気付きが成長につながる技術選定を上手くやりたい ▼成長を支援したいマネージャマネージャとして成長を促すときに伝えられる ● 整理、言語化されることで、成長を促す観点を伝えることができる 7 技術選定が上手くできるエンジニアは良いエンジニア ▼転職の候補者面接を受けるときに自分の力を適切に伝える ● 技術の取り扱う観点を伝えることで、技術の理解の深さを伝えることができる ● 未知の技術が現れたときにどのように技術に対してアプローチするかを伝えることができる ▼採用の面接官選考のときに技術を使いこなすエンジニアを見極める ● 技術選定の考えを見ることで、どこまで深く技術を理解して取り扱っているかが分かる ● リードエンジニアの役割を任せられるかを見極められる ● 技術に対しての自社でどのような観点で取り扱っているかを伝えることができる

Slide 8

Slide 8 text

第１部 - 技術選定の理論を知る

Slide 9

Slide 9 text

技術選定を成功させるには 9 技術選定を成功させるには「技術選定の成功の条件を決めること」どういう状態が成功か決めずに進んでも、成功かどうか判定できない技術選定の成功はどういう状態が成功なのかは全てのケースで「場合による」 ● 事業的な価値が重要なときもあれば、組織を優先したいケースも有る ● 小さく始めて試したい場合と、大きなシステムを失敗なく作りたい場合がある ● 技術的に使いやすいだけでは、事業戦略に合わない場合もある ● 計画が大事なときもあれば、実験と経験が大事なこともあるでは、どうやって成功の条件を決めればよいのか？

Slide 10

Slide 10 text

技術選定を成功させるには 10 技術選定の成功の条件を決めるための基本的な理論 ● 目的思考 ○ 何を達成したいのかをぶらさない ● 制約思考 ○ 現実的で合理的なトレードオフの実現 ● 進化適応 ○ 未来の変化に対応する

Slide 11

Slide 11 text

技術選定を成功させるには 11 「技術選定の成功の条件を決める」ために必要なこと　技術の周辺まで含めて見る技術を外から見る　利害関係者、リスク許容度、フェーズなどの軸を見る複数の軸で技術を選定する　制約、障害、実現したいことの関連を整理する重要項目を明確にする

Slide 12

Slide 12 text

技術選定を成功させるには 12 「技術選定の成功の条件を決める」ために必要なこと　技術の周辺まで含めて見る技術を外から見る　利害関係者、リスク許容度、フェーズなどの軸を見る複数の軸で技術を選定する　制約、障害、実現したいことの関連を整理する重要項目を明確にする

Slide 13

Slide 13 text

技術チームしか見ていない 13 技術を外から見る - 　技術の周辺まで含めて見る技術の周辺も見る技術開発組織技術システムユーザー価値開発組織エンジニア採用・育成人的流動性技術的負債将来性・PoC 開発契約事業の実現営業　　マーケティング市場

Slide 14

Slide 14 text

14 技術を外から見る - システムをつくる目的に、実現したい価値があるユーザー価値実現したいことシステム利用されるやりたいことはシステムをつくることではないエンジニア的にはこちらに注目しがち本当はこちらが大事なときが多い

Slide 15

Slide 15 text

技術を外から見る - 　技術選定が与える影響の力学を知る 15 技術が価値を発揮するまでにはステップがある技術開発組織事業の実現ユーザー価値システムエンジニア選択して取り入れる実現する利用されるやりたいことはシステムをつくることではないほとんどの場合は制約条件に当たる実現したいことは価値を実現すること目的思考技術そのものがシステムをつくるのではなくチームのメンバーがつくる世の中で数多くの新しい選択肢があり絶対的な正解はない

Slide 16

Slide 16 text

技術選定を成功させるには 16 「技術選定の成功の条件を決める」ために必要なこと　技術の周辺まで含めて見る技術を外から見る　利害関係者、リスク許容度、フェーズなどの軸を見る複数の軸で技術を選定する　制約、障害、実現したいことの関連を整理する重要項目を明確にする

Slide 17

Slide 17 text

17 複数の軸で技術を選定する今回の例：４つの軸を紹介 ● 時間軸　リリースするまで、リリースした後 ● 事業軸　事業を立ち上げ、PMF模索、グロースフェーズ ● 組織軸　今できること、将来できるようになること、採用 ● 技術軸　流行り廃り、使い勝手、将来性

Slide 18

Slide 18 text

成長模索運用追加開発複数の軸で技術を選定する - 時間軸 18 定義された目標までの期間と目標から先の期間がある開発中リリ｜スグロース運用追加開発開発開始短期的機能要件があるつくり方を考える中長期的機能要件がない何をつくるかを考える

Slide 19

Slide 19 text

成長模索運用追加開発複数の軸で技術を選定する - 時間軸 19 定義された目標までの期間と目標から先の期間がある開発中リリ｜スグロース運用追加開発開発開始短期的機能要件があるつくり方を考える中長期的機能要件がない何をつくるかを考えるなぜつくるかを考える技術選定の力学から逆算する

Slide 20

Slide 20 text

複数の軸で技術を選定する - 事業軸・組織軸・技術軸 20 それぞれの軸と時間軸を掛け合わせてみる短期中長期事業組織技術事業を立ち上げ、PMF模索グロースフェーズ、安定域今使えるスキル、早くできるエンジニアの成長、組織ブランディング今ある機能、使い勝手流行り廃り、将来性、コンセプト進化適応未来の変化に対応する

Slide 21

Slide 21 text

複数の軸で技術を選定する - 色々な軸と掛け合わせる 21 時間軸と掛け合わせるとそれぞれに違う技術の選び方が見える今必要ないからと言って、今やらなければ、いつかの未来は来ない事業のための大きな技術的負債を積むか事業としては成長しても組織として成長しない広がりのない組織を許容するか枯れた技術ばかりを選ぶことで組織が持つ技術スキルが進化できなくなってしまう

Slide 22

Slide 22 text

技術選定を成功させるには 22 「技術選定の成功の条件を決める」ために必要なこと　技術の周辺まで含めて見る技術を外から見る　利害関係者、リスク許容度、フェーズなどの軸を見る複数の軸で技術を選定する　制約、障害、実現したいことの関連を整理する重要項目を明確にする

Slide 23

Slide 23 text

23 重要項目を明確にする - 実現したい価値があるユーザー価値実現したいことシステム利用されるやりたいことはシステムをつくることではないこちらに注目しがちこちらが大事なときもある

Slide 24

Slide 24 text

重要項目を明確にする - 制約、障害、実現したいことの関連を整理する 24 技術が価値を発揮するまでには制約や障害がある技術開発組織事業の実現ユーザー価値システムエンジニア選択して取り入れる実現する利用される人は足りる？採用はできる？能力はある？運用コストは低い？想定通りできる？期待通り動く？ちゃんと使われる？届けれている？目的に届くまでの技術をどう選ぶ？

Slide 25

Slide 25 text

重要項目を明確にする - 全てを選べない中で決める 25 無限の時間や無限の資金を使えることはない ● 全てを満たすものは存在しない、全ての選択にトレードオフがある ● 検討が多いほど技術選定の精度は上がるがコストも上がる　↓ 「重要な項目」と「重要ではない項目」を精査し、技術を選ぶ基準を作る ● 目的・制約・未来などのバランスを自分たちで定義することで何が重要であるか、自分たちの価値観を明確にしていく

Slide 26

Slide 26 text

最後に「技術選定の成功の条件」を決める３つの手法紹介

Slide 27

Slide 27 text

良い技術選定を進める方法１ 27 技術選定の成功の条件を確認するために「ADRを書こう！」なぜADRを書くのか？ ● いつも完璧に技術選定が出来るわけではない ○ 時間的制約や不確実な状況で技術を選ぶ必要があるときもある ● 重要項目のチェックをテンプレートに入れよう ○ 今回の観点の中からチームの重要な項目をテンプレートに入れて考慮漏れを減らそう ● みんなの叡智を集めよう ○ 知識を集めることができる・目的をはっきりさせる ○ 議論を発生させ合意を取れる・意思決定の記録を残す

Slide 28

Slide 28 text

● タイトル ○ 意思決定の内容を簡潔に ● コンテキスト ○ 決定を行うに至った背景や状況、関係する要素や制約などを説明する ○ 議論した観点や時間的な制約で整理しきれなかったことなど ● 決定 ○ 実際に決定した技術の方針や手法 ● ステータス ○ このADRの現在の状態（下書き、提案、承認、非推奨） ● 結果 ○ アーキテクチャの状態や影響 ○ 得られた効果（プラスの影響）や問題点（マイナスの影響）など 28 ADRの基本的なまとめ方

Slide 29

Slide 29 text

良い技術選定を進める方法２ 29 技術を選ぶための意思決定の基本ステップを実行する (デザイン思考でも使われるステップをベースしたもの ) ① 共有する ②発散各個人で持っている情報を全体に共有する ③収束 ④発散 ⑤収束見るべき観点を出し合う重要項目を絞り込む ⑥ 意思決定重要項目を満たす手段を出す最も最適な方法を選ぶ

Slide 30

Slide 30 text

● 情報の共有せずに失敗 ○ アイデアを募っても、情報が足りなくてアイデアを出せない ○ アイデアを出しても、出来ない条件の情報が後出しで共有される ○ システムで実現したい価値が分からないまま決めてしまう ● 重要項目を出さずに手段を選ぶ失敗 ○ 重要ではない項目のメリットを見て意思決定 ○ 技術・事業・組織のバランスに戦略がない ○ 星取表で丸が多いものを選んでしまう ● 手段を複数出さずに決め打ちで選んで失敗 ○ もっと良い選択肢があったのに検討できていない ○ 考慮できていない観点で技術的負債の発生源になる ○ pros/consを整理せずに良いことだけで決めてしまう自分たちのチームの議論がどのステップにいるか意識しながら進めることが重要 30 技術を選ぶステップでの失敗

Slide 31

Slide 31 text

良い技術選定を進める方法３ 31 技術選定なのに技術の話が少ない？技術選定の話なのにプログラミング言語フレームワークアーキテクチャライブラリなどの話がない？

Slide 32

Slide 32 text

技術選定を成功させるには 32 技術選定なのに技術の話が少ない？ AIに聞いたらいい

Slide 33

Slide 33 text

技術選定を成功させるには 33 AI 時代に技術選定はどう変わるのか安定した技術を使おうと思ったら AIが知っている情報で十分足りるそれを元に深堀りして調査するので良い観点を整理できていれば pros/consの表も作ってくれる説明内容は間違っていることも多いので確認は自己責任でする生まれたてホヤホヤの技術を使うことはほぼない。ユーザが増えて安定したものを使うケースがほとんど

Slide 34

Slide 34 text

技術選定を成功させるには 34 AI 時代に技術選定はどう変わるのか AIは価値観は答えはくれない AIを活用しても技術選定の成功の条件は自分たちで決める必要がある！技術の価値を自ら定義できる価値の高いエンジニアになろう！

Slide 35

Slide 35 text

第１部完技術選定の理論を知る技術選定の成功には技術選定の成功条件を決めよう

Slide 36

Slide 36 text

第２部 - 技術選定の実践を知る

Slide 37

Slide 37 text

● 新田が技術選定していないものもあります ○ あくまで個人的な観点での意見であり、技術選定したメンバーの意見や情報は十分に理解せずにお伝えするものもあります ● 当時と今の知識には大きな差があるため、現時点の知識で解説します ○ 技術や開発フローも世の中での進化もあるため、現在ではもっと良い方法が多くある可能性がありますが、当時は最適な選択の可能性があります 37 技術選定の観点から見てみる

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

39 経験してきた会社 My History 2001 2014 2018 2020 2024 CyberAgent Kakehashi Small SIers Merpay Datachain 39 now student SIer・SES メガベンチャースタートアップエンジニアエンジニアリングマネージャー

Slide 40

Slide 40 text

40 経験してきた会社 - SES・SIer ● 事業 ○ 契約管理、交通系ICカード在庫管理、不動産物件の申請書管理、映画館チケット販売Webサイト、不動産賃貸Webサイト、旅行パッケージ管理 ○ システムに目的の機能が実装できるまでが契約 ● 開発組織 ○ プロジェクトごとに開発現場に集められ、プロジェクト完了すると解散する ○ 自社の採用には関わらないし、同じ現場に来る人も多くはない ● 技術 ○ 開発現場で決められた技術を使う、C、Java、Struts、JSP、Velocity、Seasar、 JSF、Click、Tapestry、SAStruts、オンプレしかない時代

Slide 41

Slide 41 text

41 経験してきた会社 - サイバーエージェント ● 事業 ○ アドテク事業、新規立ち上げや既存事業の推進、RTBのDSP、DMPなど ○ ハイトラフィック (10万QPS)、低レイテンシ (100ms)、ビッグデータ (１日数億レコード)などを考慮する必要がある ● 開発組織 ○ JavaやScalaを使うチームが多く、100人規模の開発人員が部署にいる ○ 当時は既に技術ブランドがあり、Scalaでは国内のトップレベルの発信組織 ● 技術 ○ Java、Scala、Redis、Aerospike、BigQuery、Redshift、Finagle、Cats、 Dataﬂow、KinesisStream、Fluentd、ProtocolBufferなど

Slide 42

Slide 42 text

42 経験してきた会社 - メルペイ ● 事業 ○ スマートフォン決済事業、リリース前の立ち上げ期 ○ 金融事業のため、１リクエストも落とせない、１円もズレてはいけない ○ 新規立ち上げの部分と既存のメルカリからの切り出しの部分があった ● 開発組織 ○ 100人規模の開発組織、既にメルカリ文化がベースにある ○ GoやGCPで非常に注目を集める認知がある組織になっていた ● 技術 ○ Go、マイクロサービス、Kubernetes、Spanner、Stackdriver、Dataﬂow、 Terraform、BigQuery、Datadog、 Spinnakerなど

Slide 43

Slide 43 text

43 経験してきた会社 - カケハシ ● 事業 ○ スタートアップ、コンパウンドスタートアップとして拡大中のフェーズ ○ 薬局向けSaaSを提供、医療系ドメインでありミッションクリティカル ● 開発組織 ○ ３年で100人規模から300人規模の会社になる急拡大の時期 ○ スタートアップ界隈ではキャッチアップが早い人にはかなり知られていたが、エンジニアからはほとんど知られていない、フルリモート ● 技術 ○ Python、TypeScript、Terraform、Glue、AppSync (GraphQL)、Aurora、 Lambda、Cognito、Fargate、Datadog、Databricksなど

Slide 44

Slide 44 text

44 経験してきた会社 - Datachain ● 事業 ○ 大きな挑戦を目指し、技術ドリブンの会社で５年間の研究開発を経て、直近はサービス開発を強化し、複数事業の立ち上げを行っている真っ最中 ○ 金融事業が中心であり、次世代の金融プラットフォームになるものを作る ● 開発組織 ○ まだ少人数の組織だが、１つ１つの事業がユニコーン級 (時価総額 1500億円) 以上を狙う事業のため、それなりの規模の組織が必要になる計画。 ○ エンジニアから知られていないが成長が必要な会社 ● 技術 ○ ブロックチェーン技術の実社会への適応、新技術の発明、新技術のサービス適応のための開発、Go、Solidity、Azure、Argo Workﬂows、OpenTelemetry、 Chainlink、getblock、IBC、LCP

Slide 45

Slide 45 text

どれか１つでも当てはまる人は是非 Datachainに来てください！ ● Webの技術に少し飽きて、新しい技術にチャレンジしたい方 ● コモディティ化していない技術を使い、事業を推進したい方 ● グローバルの金融を変える大きな挑戦に興味がある方募集中 45 Datachainではハイレベルなエンジニアを募集しています

Slide 46

Slide 46 text

FAQ

Slide 47

Slide 47 text

47 重要な項目って例えばどういうもの？ (要件の技術的トレードオフ以外) ● 短期と中長期のトレードオフ ○ 短期的な機能の開発のために中長期的なリスクを追うのか ○ 中長期の効率的な成長のために運用に耐える仕組みを作り込むのか ● つくりやすさ vs つかいやすさのトレードオフ ○ 僅かな使いやすさ向上のためにコストが数倍高まることもある ● 変更のしやすさ ○ 失敗したときに戻せる状態でつくるか (可逆可能な意思決定) ○ 検証を行う意思決定やリリース様子をみて決める小さな意思決定 ● 安定的な技術選択と挑戦的な技術選択 ○ 慣れた技術は短期的には最速 ○ だが、安定的なものばかり選んでいると技術の進化ができない組織になる

Slide 48

Slide 48 text

48 事業を深く理解してシステムをつくるにはどうすればいいの？ ● 事業をシステム化する手法を使うと良いでしょう ○ DDD ○ イベントストーミング ○ ユーザーストーリーマッピング ○ RDRA ○ ICONIX ○ BABOK ○ など ● いきなり実装を始めたくなりますが、まずは整理することで価値がわかります ● つくることがゴールではなく、成功することがゴールの場合は急がば回れです

Slide 49

Slide 49 text

49 技術負債のない技術選定をするにはどうすればいいの？ ● 未来予知ができるようになるしかない！ ● 無理なら精度は100%にはならない ● 僕らは予知はできず、予測しかできません ● 技術負債がなくならない前提で、技術的負債がなるべく少なくなる選択をする ● 加えて、技術選定が失敗だったとしても、当時の分かっていた情報の範囲での意思決定しては最適であったと納得できる状態になること ● 捨てやすく作っておく、変更しやすく作っておく

Slide 50

Slide 50 text

50 興味あったり、好きだからという理由で技術を選んでも良い？ ● 良いと思います！ ● 興味というモチベーションや慣れている技術を使うことは生産パフォーマンスに大きく影響するファクターです ● 重要項目の中に入っているか確認しましょう

Slide 51

Slide 51 text

51 成功の条件ってそんなに大事？ ● 大事だと考えています ● もやもやする技術が選択されそうになったら、それを言語化することが大事 ● おそらく考慮、議論されていない重要項目がある可能性があります ● この工程はみんなの知識を集めてより良いものを作るという意味と自分たちの現時点での知識と情報を検討しきったという納得を得るために必要です ● それを客観的な情報としてADRにまとめることが重要です ● ADRを書くことがゴールではありません ● 重要なポイントがどこにあるかを議論し、記録することが重要です

Slide 52

Slide 52 text

52 FLEXY meetup - 技術選定を知る FLEX meetup Finish ● 資料のSNS拡散歓迎 ● コメント・感想お待ちしています