事業を支える技術選定 コネヒトマルシェオンライン「事業を支える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