概要

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

イベントリンク

LT

1. pospomeさん(DMMプラットフォームさん)

発表資料はコチラ

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

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

統一されたもの

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

統一されなかったもの

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

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

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

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

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

発表資料はコチラ

LTで気になったこと

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

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

パネルディスカッション

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

伊藤さん

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

pospomeさん

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

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

伊藤さん

とにかく認知負荷を下げる

例

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

pospomeさん

0→1はトップダウンでやってしまうのが良い
浸透させるのは簡単
問題は1→10(実装力の洗練)
「手を動かしてもらう」、「相談室を設ける」などとにかく慣れてもらうようにしてる。pospomeさん曰く「脳筋スタイル」とのこと

3. どこまで社内のスタンダードを決めているのか？

pospomeさん

みんなの要件を満たせるものは作る

例

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

伊藤さん

全体的にガッツリ決める

例

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

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

伊藤さん

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

pospomeさん

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

質疑応答

Q. 言語選定の部分詳しくお聞きしたいです

A. pospomeさん

サーバーサイド

[前提]選ぶ時に重視していたこと => 1.型があること 2.スピードがはやいこと

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

フロントエンド

JavaScript or TypeScriptの二択だった
型が欲しかったのでTypeScriptを選んだ

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

A. pospomeさん

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

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

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

Q.選定した技術を嫌がる人がいたらどうしますか？

A. 伊藤さん

カウシェさんでは今までにしぶられたことはない
社内勉強会とかがあるのでもししぶられた場合はそれで対応は可能例) 「週1勉強会」や「linterのドキュメント」

A. pospomeさん

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

ひとくち感想

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

概要

イベントリンク

LT

1. pospomeさん(DMMプラットフォームさん)

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

パネルディスカッション

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

伊藤さん

pospomeさん

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

伊藤さん

pospomeさん

3. どこまで社内のスタンダードを決めているのか？

pospomeさん

伊藤さん

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

伊藤さん

pospomeさん

質疑応答

Q. 言語選定の部分詳しくお聞きしたいです

A. pospomeさん

サーバーサイド

フロントエンド

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

A. pospomeさん

Q.選定した技術を嫌がる人がいたらどうしますか？

A. 伊藤さん

A. pospomeさん

ひとくち感想

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