Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
事業を支える技術選定 / Engineering Decision Making Proces...
Search
itosho
June 04, 2020
Programming
12
5.3k
事業を支える技術選定 / Engineering Decision Making Process For Business
コネヒトマルシェオンライン「事業を支えるWeb開発」の登壇資料です。
itosho
June 04, 2020
Tweet
Share
More Decks by itosho
See All by itosho
打線組という個人サービスを Goで開発している話 / Indie Service Development by Go
itosho
1
150
Components Reconsidered
itosho
1
2.1k
組織をスケールさせるためのTech Vision / Connehito Tech Vision for Growing Our Team
itosho
2
590
Gopher道場アフターストーリー / Gopher Dojo After Story
itosho
0
130
3分で分かるConnehito Tech Vision / Connehito Tech Vision in 3 minutes
itosho
0
430
CakePHPで学ぶDIコンテナ / Learn a DI Container through CakePHP
itosho
1
1.4k
Bリーグにおけるホームアドバンテージ / Home Advantage in B.League
itosho
0
2.2k
Deep Module in PHP
itosho
2
11k
Let's start your first OSS with CakePHP
itosho
3
4.4k
Other Decks in Programming
See All in Programming
Snowflake x dbtで作るセキュアでアジャイルなデータ基盤
tsoshiro
2
420
RailsのPull requestsのレビューの時に私が考えていること
yahonda
5
1.7k
リリース8年目のサービスの1800個のERBファイルをViewComponentに移行した方法とその結果
katty0324
5
3.5k
From Subtype Polymorphism To Typeclass-based Ad hoc Polymorphism- An Example
philipschwarz
PRO
0
160
のびしろを広げる巻き込まれ力:偶然を活かすキャリアの作り方/oso2024
takahashiikki
1
400
Webの技術スタックで マルチプラットフォームアプリ開発を可能にするElixirDesktopの紹介
thehaigo
2
910
Progressive Web Apps für Desktop und Mobile mit Angular (Hands-on)
christianliebel
PRO
0
110
Boost Performance and Developer Productivity with Jakarta EE 11
ivargrimstad
0
810
推し活の ハイトラフィックに立ち向かう Railsとアーキテクチャ - Kaigi on Rails 2024
falcon8823
6
2.1k
GitHub Actionsのキャッシュと手を挙げることの大切さとそれに必要なこと
satoshi256kbyte
5
390
Tuning GraphQL on Rails
pyama86
2
1k
Amazon Neptuneで始めてみるグラフDB-OpenSearchによるグラフの全文検索-
satoshi256kbyte
4
310
Featured
See All Featured
Being A Developer After 40
akosma
86
590k
Imperfection Machines: The Place of Print at Facebook
scottboms
264
13k
How to Ace a Technical Interview
jacobian
275
23k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
How To Stay Up To Date on Web Technology
chriscoyier
788
250k
Ruby is Unlike a Banana
tanoku
96
11k
GraphQLとの向き合い方2022年版
quramy
43
13k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
107
49k
Visualization
eitanlees
144
15k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
328
21k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
10 Git Anti Patterns You Should be Aware of
lemiorhan
654
59k
Transcript
事業を支える技術選定 コネヒトマルシェオンライン「事業を支えるWeb開発」@itosho 1
自己紹介 ▪伊藤 翔 @itosho ・コネヒト株式会社 執行役員CTO ・Backend Engineer / PHP,
Go ・stand.fm はじめました ・https://stand.fm/channels/5ec2e733f654bbcab4c123a2 Follow me!
今日のテーマ「技術選定」
4
何故、技術選定は難しいのか? ▪正解がない ・判断軸が多岐に渡り、会社の状況によっても変わる ・イデオロギーが対立しやすいトピックであり、合意形成が難しい
難しいからこそ向き合う価値がある ▪今日話すこと ・技術選定をするにあたり、どうやって意思決定をしているか ・正解がないトピックなので一つの考えとして聞いてください ※話のトピック的に、何かを「選ぶ」ので必然的に何かを「選ばない」という構図になりますが、 この技術の方が上だとか下だとかを主張するものではないです。
①判断軸の整理
8 6つの判断軸で考える
1. サービス要件 ・厳格なトランザクション管理、非同期処理の必要性 ⇒マストに近い軸ではあるが、昨今においてこの軸だけで絞ることは難しい 2. コスト ・サーバー費、ライセンス料 ⇒予算や会社のステージ(スタートアップ、大企業)に依る部分が大きい 6つの判断軸(ビジネス観点)
3. 生産性 ・エコシステムが整っているか、素早くリリース出来るか ⇒エンジニアのスキルに依る部分も大きい(コストとも密接に関わる) 4. 将来性 ・数年後も存続、メンテナンスされているか ⇒高度な審美眼が要求される(個人的にはめちゃくちゃ難しい) 6つの判断軸(エンジニアリング観点)
5. 技術アセット(資産) ・過剰な採用技術の乱立を避ける ⇒ナレッジの蓄積や学習コストなどの面からも会社としては一定の数に抑えたい 6. 情熱 ・担当エンジニアがその技術に情熱を持てるか ⇒個人的にはかなり重視すべき軸ではあると思うが、その人が辞めたら? 6つの判断軸(組織観点)
5. 技術アセット(資産) ・過剰な採用技術の乱立を避ける ⇒ナレッジの蓄積や学習コストなどの面からも会社としては一定の数に抑えたい 6. 情熱 ・担当エンジニアがその技術に情熱を持てるか ⇒個人的にはかなり重視すべき軸ではあると思うが、その人が辞めたら? 6つの判断軸(組織観点) 軸を言語化することで議論を始めることが出来る
▪それぞれの判断軸が立体的かつ不可分 ・一次元ではない情報から優劣を判断することは出来ない ・単純な加点方式で決めるのはアンチパターン(だと思う) ・例えば、以下の場合どちらの技術を選ぶべきか? それでもまだ意思決定は困難 ビジネス観点(y) エンジニアリング観点(x) 組織観点(z) 候補 要件
コスト 生産性 将来性 資産 情熱 合計 技術A 60 60 60 60 60 60 360 技術B 80 20 80 40 40 80 340
▪それぞれの判断軸が立体的かつ不可分 ・一次元ではない情報から優劣を判断することは出来ない ・単純な加点方式で決めるのはアンチパターン(だと思う) ・例えば、以下の場合どちらの技術を選ぶべきか? それでもまだ意思決定は困難 ビジネス観点(y) エンジニアリング観点(x) 組織観点(z) 候補 要件
コスト 生産性 将来性 資産 情熱 合計 技術A 60 60 60 60 60 60 360 技術B 80 20 80 40 40 80 340 では、どうするか?
②方針と詳細に分ける
▪アーキテクチャの考え方を技術選定に適用する “あらゆるソフトウェアシステムは、大きく2つの要素に分割できる。「方針」と「詳細」だ。方針の要素 は、ビジネスのすべてのルールや手順を含んでいる。方針には、システムの本当の価値がある。詳細は、 人間・そのほかのシステム・プログラマが、方針についてやり取りするために必要なものだが、方針の振 る舞いに影響を与えるものではない。” (『Clean Architecture 達人に学ぶソフトウェアの構造と設計』より) 方針と詳細
17 ケーススタディ: コネヒトの場合
▪前提 ・バックエンドの技術スタックは創業時からPHP / CakePHPを採用 ・「技術は手段」という文化が根付いている ⇒現時点での選択肢 ・無限 ・これまで通りPHPを採用するという選択肢も当然ありえる 新規プロジェクトにおけるバックエンドの言語選定
▪方針(原文ママ) ・「技術は手段」を言い訳にしないぐらいの選択肢と力量を持っている ・「技術は手段」であることは変わらないが、組織を大きくするために一定技術ブランディングも意識する ・特定の技術だけで頑張るのではなく、つくりたいものや課題に対して適切な技術を選択する ・一つのドラムヘッドで七色の音を鳴らすより、鳴らしたい音に合わせてドラムヘッドを変えていく ⇒現時点での選択肢 ・PHP以外の新しい技術を選択することが有力になってくる ・6つの判断軸の中で「サービス要件」が最優先であることが分かる 方針を決める
▪選定基準(方針と詳細を繋ぐもの) ・一定何らかの「制約」があるもの(チーム開発のしやすさ) ・PHPが苦手なところを補える ・担当するエンジニアがその言語に対して熱量があるか ⇒現時点での選択肢 ・6つの判断軸の中で「生産性」「技術アセット」「情熱」が重視されている ・実際に出た候補: Go, node.js, Python
・具体的なレベル(≒詳細)で議論が出来るようになった! もう少し絞る
▪方針はトップダウン、詳細はボトムアップ ・結果的にはGoが選ばれた ・その技術を触るのは結局現場のエンジニアなので、詳細はボトムアップで決めたほうがよい ・ただし、組織としてのバランスをとるために方針や基準はある程度トップダウンで決める 結果
▪方針はトップダウン、詳細はボトムアップ ・結果的にはGoが選ばれた ・その技術を触るのは結局現場のエンジニアなので、詳細はボトムアップで決めたほうがよい ・ただし、組織としてのバランスをとるために方針や基準はある程度トップダウンで決める 結果 これで十分か?
③方針を浸透させる
▪方針は方針でしかない ・冒頭にも述べたように技術選定は宗教戦争になりやすい ・また、好奇心旺盛なエンジニアほど新技術に目移りしやすい(一概に悪いことでもない) ・きちんと方針(≒ビジョン)を明文化し、組織に浸透〜定着させていくことが重要 ※このあたりはまだ出来ていなくて、これからやっていかなければいけないことの一つです その方針に実効性はあるか?
▪採用する時から技術選定は始まっている ・無下に同質化する必要はないし、多様性も重要だが「方針」への理解は重要 ・俗に言うカルチャーフィットと呼ばれるもの ・技術スタックはその組織の映し鏡なので、何故その技術を採用しているか?は丁寧な説明が必要 ・どういう人を採用するかで、技術スタックも変わってくる 浸透させるために採用活動は超重要
まとめ
▪技術選定をするための3つのアクション ①まずは判断軸をつくる ・これだけではまだ意思決定は難しいが、最初の一歩として重要 ②その軸をもとに優先度を決めていく ・ 方針はトップダウンで、詳細はボトムアップで決める ③方針が絵に描いた餅にならないように浸透させる ・ 採用がめちゃくちゃ大事 今北産業
▪技術選定をするための3つのアクション ①まずは判断軸をつくる ・これだけではまだ意思決定は難しいが、最初の一歩として重要 ②その軸をもとに優先度を決めていく ・ 方針はトップダウンで、詳細はボトムアップで決める ③方針が絵に描いた餅にならないように浸透させる ・ 採用がめちゃくちゃ大事 今北産業
あれ、これ何かに似てる…!?
29
▪技術選定はプロダクト開発に似ている ・プロダクト開発と同じように意思決定行うといいのかもしれない (案)インセプションデッキを使って、技術選定を行う ・ユーザーのためのプロダクトであり、プロダクトのための技術である ・ユーザーに価値を提供する技術選定が出来るように、 これからも試行錯誤を繰り返していくぞ 今後の展望 顧客(ユーザー) 事業(プロダクト) 技術
『エンジニアのためのマネジメントキャリアパス』 ・https://www.amazon.co.jp/dp/4274064069 『エンジニアの知的生産術──効率的に学び、整理し、アウトプットする』 ・https://www.amazon.co.jp/dp/4774198765 『Clean Architecture 達人に学ぶソフトウェアの構造と設計』 ・https://www.amazon.co.jp/dp/4048930656 「理想の技術選定」 ・https://note.com/timakin/n/n2d9eaa02e633
「Kibela開発における技術選択の指針を全部教える。必要十分に新しい技術を維持するための考え方」 ・https://employment.en-japan.com/engineerhub/entry/2019/04/05/103000 参考文献 / サイト
32