Slide 1

Slide 1 text

事業を支える技術選定 コネヒトマルシェオンライン「事業を支えるWeb開発」@itosho 1

Slide 2

Slide 2 text

自己紹介 ■伊藤 翔 @itosho ・コネヒト株式会社 執行役員CTO ・Backend Engineer / PHP, Go ・stand.fm はじめました ・https://stand.fm/channels/5ec2e733f654bbcab4c123a2 Follow me!

Slide 3

Slide 3 text

今日のテーマ「技術選定」

Slide 4

Slide 4 text

4

Slide 5

Slide 5 text

何故、技術選定は難しいのか? ■正解がない ・判断軸が多岐に渡り、会社の状況によっても変わる ・イデオロギーが対立しやすいトピックであり、合意形成が難しい

Slide 6

Slide 6 text

難しいからこそ向き合う価値がある ■今日話すこと ・技術選定をするにあたり、どうやって意思決定をしているか ・正解がないトピックなので一つの考えとして聞いてください ※話のトピック的に、何かを「選ぶ」ので必然的に何かを「選ばない」という構図になりますが、  この技術の方が上だとか下だとかを主張するものではないです。

Slide 7

Slide 7 text

①判断軸の整理

Slide 8

Slide 8 text

8 6つの判断軸で考える

Slide 9

Slide 9 text

1. サービス要件 ・厳格なトランザクション管理、非同期処理の必要性 ⇒マストに近い軸ではあるが、昨今においてこの軸だけで絞ることは難しい 2. コスト ・サーバー費、ライセンス料 ⇒予算や会社のステージ(スタートアップ、大企業)に依る部分が大きい 6つの判断軸(ビジネス観点)

Slide 10

Slide 10 text

3. 生産性 ・エコシステムが整っているか、素早くリリース出来るか ⇒エンジニアのスキルに依る部分も大きい(コストとも密接に関わる) 4. 将来性 ・数年後も存続、メンテナンスされているか ⇒高度な審美眼が要求される(個人的にはめちゃくちゃ難しい) 6つの判断軸(エンジニアリング観点)

Slide 11

Slide 11 text

5. 技術アセット(資産) ・過剰な採用技術の乱立を避ける ⇒ナレッジの蓄積や学習コストなどの面からも会社としては一定の数に抑えたい 6. 情熱 ・担当エンジニアがその技術に情熱を持てるか ⇒個人的にはかなり重視すべき軸ではあると思うが、その人が辞めたら? 6つの判断軸(組織観点)

Slide 12

Slide 12 text

5. 技術アセット(資産) ・過剰な採用技術の乱立を避ける ⇒ナレッジの蓄積や学習コストなどの面からも会社としては一定の数に抑えたい 6. 情熱 ・担当エンジニアがその技術に情熱を持てるか ⇒個人的にはかなり重視すべき軸ではあると思うが、その人が辞めたら? 6つの判断軸(組織観点) 軸を言語化することで議論を始めることが出来る

Slide 13

Slide 13 text

■それぞれの判断軸が立体的かつ不可分 ・一次元ではない情報から優劣を判断することは出来ない ・単純な加点方式で決めるのはアンチパターン(だと思う) ・例えば、以下の場合どちらの技術を選ぶべきか? それでもまだ意思決定は困難 ビジネス観点(y) エンジニアリング観点(x) 組織観点(z) 候補 要件 コスト 生産性 将来性 資産 情熱 合計 技術A 60 60 60 60 60 60 360 技術B 80 20 80 40 40 80 340

Slide 14

Slide 14 text

■それぞれの判断軸が立体的かつ不可分 ・一次元ではない情報から優劣を判断することは出来ない ・単純な加点方式で決めるのはアンチパターン(だと思う) ・例えば、以下の場合どちらの技術を選ぶべきか? それでもまだ意思決定は困難 ビジネス観点(y) エンジニアリング観点(x) 組織観点(z) 候補 要件 コスト 生産性 将来性 資産 情熱 合計 技術A 60 60 60 60 60 60 360 技術B 80 20 80 40 40 80 340 では、どうするか?

Slide 15

Slide 15 text

②方針と詳細に分ける

Slide 16

Slide 16 text

■アーキテクチャの考え方を技術選定に適用する “あらゆるソフトウェアシステムは、大きく2つの要素に分割できる。「方針」と「詳細」だ。方針の要素 は、ビジネスのすべてのルールや手順を含んでいる。方針には、システムの本当の価値がある。詳細は、 人間・そのほかのシステム・プログラマが、方針についてやり取りするために必要なものだが、方針の振 る舞いに影響を与えるものではない。” (『Clean Architecture 達人に学ぶソフトウェアの構造と設計』より) 方針と詳細

Slide 17

Slide 17 text

17 ケーススタディ: コネヒトの場合

Slide 18

Slide 18 text

■前提 ・バックエンドの技術スタックは創業時からPHP / CakePHPを採用 ・「技術は手段」という文化が根付いている ⇒現時点での選択肢 ・無限 ・これまで通りPHPを採用するという選択肢も当然ありえる 新規プロジェクトにおけるバックエンドの言語選定

Slide 19

Slide 19 text

■方針(原文ママ) ・「技術は手段」を言い訳にしないぐらいの選択肢と力量を持っている  ・「技術は手段」であることは変わらないが、組織を大きくするために一定技術ブランディングも意識する ・特定の技術だけで頑張るのではなく、つくりたいものや課題に対して適切な技術を選択する  ・一つのドラムヘッドで七色の音を鳴らすより、鳴らしたい音に合わせてドラムヘッドを変えていく ⇒現時点での選択肢 ・PHP以外の新しい技術を選択することが有力になってくる ・6つの判断軸の中で「サービス要件」が最優先であることが分かる 方針を決める

Slide 20

Slide 20 text

■選定基準(方針と詳細を繋ぐもの) ・一定何らかの「制約」があるもの(チーム開発のしやすさ) ・PHPが苦手なところを補える ・担当するエンジニアがその言語に対して熱量があるか ⇒現時点での選択肢 ・6つの判断軸の中で「生産性」「技術アセット」「情熱」が重視されている ・実際に出た候補: Go, node.js, Python ・具体的なレベル(≒詳細)で議論が出来るようになった! もう少し絞る

Slide 21

Slide 21 text

■方針はトップダウン、詳細はボトムアップ ・結果的にはGoが選ばれた ・その技術を触るのは結局現場のエンジニアなので、詳細はボトムアップで決めたほうがよい ・ただし、組織としてのバランスをとるために方針や基準はある程度トップダウンで決める 結果

Slide 22

Slide 22 text

■方針はトップダウン、詳細はボトムアップ ・結果的にはGoが選ばれた ・その技術を触るのは結局現場のエンジニアなので、詳細はボトムアップで決めたほうがよい ・ただし、組織としてのバランスをとるために方針や基準はある程度トップダウンで決める 結果 これで十分か?

Slide 23

Slide 23 text

③方針を浸透させる

Slide 24

Slide 24 text

■方針は方針でしかない ・冒頭にも述べたように技術選定は宗教戦争になりやすい ・また、好奇心旺盛なエンジニアほど新技術に目移りしやすい(一概に悪いことでもない) ・きちんと方針(≒ビジョン)を明文化し、組織に浸透〜定着させていくことが重要  ※このあたりはまだ出来ていなくて、これからやっていかなければいけないことの一つです その方針に実効性はあるか?

Slide 25

Slide 25 text

■採用する時から技術選定は始まっている ・無下に同質化する必要はないし、多様性も重要だが「方針」への理解は重要  ・俗に言うカルチャーフィットと呼ばれるもの ・技術スタックはその組織の映し鏡なので、何故その技術を採用しているか?は丁寧な説明が必要  ・どういう人を採用するかで、技術スタックも変わってくる 浸透させるために採用活動は超重要

Slide 26

Slide 26 text

まとめ

Slide 27

Slide 27 text

■技術選定をするための3つのアクション ①まずは判断軸をつくる ・これだけではまだ意思決定は難しいが、最初の一歩として重要 ②その軸をもとに優先度を決めていく ・ 方針はトップダウンで、詳細はボトムアップで決める ③方針が絵に描いた餅にならないように浸透させる ・ 採用がめちゃくちゃ大事 今北産業

Slide 28

Slide 28 text

■技術選定をするための3つのアクション ①まずは判断軸をつくる ・これだけではまだ意思決定は難しいが、最初の一歩として重要 ②その軸をもとに優先度を決めていく ・ 方針はトップダウンで、詳細はボトムアップで決める ③方針が絵に描いた餅にならないように浸透させる ・ 採用がめちゃくちゃ大事 今北産業 あれ、これ何かに似てる…!?

Slide 29

Slide 29 text

29

Slide 30

Slide 30 text

■技術選定はプロダクト開発に似ている ・プロダクト開発と同じように意思決定行うといいのかもしれない  (案)インセプションデッキを使って、技術選定を行う ・ユーザーのためのプロダクトであり、プロダクトのための技術である ・ユーザーに価値を提供する技術選定が出来るように、  これからも試行錯誤を繰り返していくぞ 今後の展望 顧客(ユーザー) 事業(プロダクト) 技術

Slide 31

Slide 31 text

『エンジニアのためのマネジメントキャリアパス』 ・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 参考文献 / サイト

Slide 32

Slide 32 text

32