「ソフトウェアアーキテクトの挑戦 -技術選定を成功させるために-」に参加しました

# 概要
勉強会に参加し、非常に学びが多かったのでイベント中に取っていたメモをまとめました

## イベントリンク
https://offers.connpass.com/event/289340/


# LT
## 1. pospomeさん(DMMプラットフォームさん)
発表資料はコチラ

https://speakerdeck.com/pospome/120ming-nokai-fa-zu-zhi-wozhi-eru-ji-shu-manezimentotoxuan-ding

 DMMプラットフォームさんは有名なプラクティスに沿ってたけど開発効率がうまく上がらなかった

そして原因 を**チームが独立しすぎたこと**。また、**技術選定や環境がバラバラすぎた** と仮定した
バラバラすぎて<font color="red">チームが変わると別会社になってしまう</font>という問題はあった。なので使う技術の統一を実施

統一されたもの
|  どの領域を  |  何に統一したのか |
| ---- | ---- |
|  プログラミング言語  |   Go(サーバー) / TypeScript(フロント) |
| コンテナ | k8s |
|  ログ周り  |  Datadog  |

統一されなかったもの
* クラウドサービス (GCP と AWS を使っている)
理由：クラウド統一を今からするのはコスパが悪いと判断した
* フレームワークやライブラリ
理由：使用用途で変わることがあるのでフレームワークやライブラリは統一しなかった。


Q. 技術選定の結果っていつ出るの？
A. すぐは出ない。また、技術選定の良し悪しは結果論になりやすい

pospomeさんはよくいただく「なぜGoなんですか？PHPはダメだったんですか？」のようなプログラミング言語の選定に関する質問に対して「**言語だけ変えて他の前提を同じにした状態で比較したことがないから答えられない**」と話していました。

私がLTの中で勉強になったのは下記の言葉です
「どんな技術選定においても<font color="red">**当時の選択に対して論理的に説明できる必要がある**</font>」

## 2. 伊藤さん(カウシェさん)

発表資料はコチラ

https://speakerdeck.com/110y/platform-team-at-kauche

LTで気になったこと
* プラットフォームグループは認知負荷を下げるために働くこと
* 作って終わりではない。社内で使ってくれてる方にフィードバックを求めて改善すること

[余談] 上記内容、弊社の技術標準化プロジェクトに通ずるものを感じました

#  パネルディスカッション

## 1. 技術選定における判断軸は何ですか？ 組織規模ごとの違いなどあれば

### 伊藤さん
すぐ使っていけることを意識した(スタートアップで人が少ないため)

### pospomeさん
自分が使うではなく**チーム全員が使うこと**を意識した
例えば120人全員が使うとかを考えなくてはいけない。また、世の中のトレンドとかを取り入れる


## 2. 選定した技術を組織を浸透させる際の工夫は？

### 伊藤さん
とにかく認知負荷を下げる

:::note info
例
* ドキュメントのダッシュボードを作る
* 新メンバーに対して伊藤さんがオンボーディングをする(人数が少ないからできてる気がする)
* 技術の背景や思想も話している(なぜなのか？を把握してもらうことを大事にしている)
:::


### pospomeさん
* 0→1はトップダウンでやってしまうのが良い
浸透させるのは簡単

* 問題は1→10(実装力の洗練)
「手を動かしてもらう」、「相談室を設ける 」などとにかく慣れてもらうようにしてる。pospomeさん曰く「脳筋スタイル」とのこと

## 3. どこまで社内のスタンダードを決めているのか？
### pospomeさん
みんなの要件を満たせるものは作る

:::note info
例
* Goやk8sは社内のスタンダードにしたので絶対使う。だからスタンダードを決める
* 機械学習やビックデータは全チームが使うかわからないのでチームに任せて社内スタンダードをきっちり設けない
:::


### 伊藤さん
全体的にガッツリ決める

:::note info
例
* Linterやディレクトリ構成、使うインフラも全部
* ビジネス要件に関係ないところ全てでスタンダードを決めていきたい
:::


## 4. アーキテクトに必要だと感じる能力や、向いてる方の特徴は？

### 伊藤さん

* <font color="red">広く見れる人(技術のことに限らない)</font>
* 「〇〇という法律に対してどう技術でアプローチしていくのか」や「会社の利益を技術でどう上げていくのか」、「今のトレンドをどうやって既存に取り入れてくのか」 etc...
* 技術ももちろん知っておくべき
* <font color="red">技術感度</font>大事。あと、<font color="red">技術を布教できる力</font>も大事

### pospomeさん
* ドキュメンテーション能力とコミュニケーション能力があること。そしてドキュメント書くこととコミュニケーションすることを<font color="red">嫌がらない人</font>
* もちろん技術が好きなこと
* アーキテクトは技術に全部詳しい必要はない。<font color="red">**自分のバックグラウンドを理解し、詳しい人を巻き込んでいけることが大事**</font>


#  質疑応答
## Q. 言語選定の部分詳しくお聞きしたいです 
### A. pospomeさん
#### サーバーサイド 
[前提]選ぶ時に重視していたこと =>  1.型があること 2.スピードがはやいこと

既にJavaの利用があったためKotlinかGoで悩んだ。そんな時、内部からJVMのツラミに対する声が上がっていることに気づく。またGoはバイナリで動かすことが可能。なのでGoを選んだ

#### フロントエンド
JavaScript or TypeScriptの二択だった
型が欲しかったのでTypeScriptを選んだ


## Q. 「社内で決めたデファクトスタンダードを外れる権利」について詳しく教えてください
### A. pospomeさん

基本的には外れないようにしてもらってますが、どうしてもというのであれば社内のデファクトスタンダードから外れても良いとしている。しかし、「**外れる場合は全部あなたたちで面倒みてください**」というルールがある。

:::note info
例
特例で「AWS使いたーい」となったらアカウントの払い出しからやってもらう。
:::

スタンダートから外れることに対してハードルを高くしている。チームに責任を持ってもらうのは **外れた特例もプラットフォームチームで面倒みてたらプラットフォームチームが<font color="red">疲弊してしまう</font>** ため

## Q.選定した技術を嫌がる人がいたらどうしますか？
### A. 伊藤さん
カウシェさんでは今までにしぶられたことはない
社内勉強会とかがあるのでもししぶられた場合はそれで対応は可能 例) 「週1勉強会」や「linterのドキュメント」

### A. pospomeさん
「勉強の時間がない」というのであれば学習の時間をしっかり設けます

# ひとくち感想
* 弊社の標準化プロジェクトに対する理解が深まった
* 「社内で統一すべきこと / 社内で統一しなくても良いこと」 の一例を知る
* 技術選定は組織の規模とフェーズを考える必要がある
* アーキテクトに向いてる人の人物像が少しわかった