Scalaの新規事業でScalaの未経験者をオンボーディング

by Tatsuya Iwamatsu

Slide 1

Slide 1 text

クラウドリスク評価ビジョナル・インキュベーション株式会社 1 Scalaの新規事業で Scalaの未経験者をオンボーディング 2022.03.19　岩松竜也　内山陽介

Slide 2

Slide 2 text

自己紹介 2 岩松竜也いわまつたつや内山陽介うちやまようすけ Scala歴7年 (=社会人歴) Scala Daysにも2回行った(コペンハーゲン /ローザンヌ) 最近の趣味はカロリー管理と筋トレ Scala初心者元々はiOSエンジニア, サーバーサイドのメイン言語は Java 息子と電車旅 , お酒チョットノム 2015年株式会社ビズリーチ新卒入社 HRMOS採用で開発全般を担当 2020年 Assured へ異動開発全般を担当 2012年株式会社サイバーエージェント新卒入社主にモバイル向け SaaSの開発全般、プリセールス、テクニカルサポートを担当アマゾンウェブサービスジャパン合同会社入社ソリューションアーキテクトとして、クラウド導入支援や技術支援を担当 2019年 Assured にエンジニアとして参画 2022年

Slide 3

Slide 3 text

Scala歴7年 (=社会人歴) Scala Daysにも2回行った(コペンハーゲン /ローザンヌ) 最近の趣味はカロリー管理と筋トレ Scala初心者元々はiOSエンジニア, サーバーサイドのメイン言語は Java 息子と電車旅 , お酒チョットノム自己紹介 3 岩松竜也いわまつたつや内山陽介うちやまようすけ今日はどんどんツッコミしていきます 2015年株式会社ビズリーチ新卒入社 HRMOS採用で開発全般を担当 2020年 Assured へ異動開発全般を担当 2012年株式会社サイバーエージェント新卒入社主にモバイル向け SaaSの開発全般、プリセールス、テクニカルサポートを担当アマゾンウェブサービスジャパン合同会社入社ソリューションアーキテクトとして、クラウド導入支援や技術支援を担当 2019年 Assured にエンジニアとして参画 2022年

Slide 4

Slide 4 text

Visional グループとは 2020年2月の経営体制移行に伴い「ビズリーチ」から「 Visional グループ」として新しいスタートをきりました。

Slide 5

Slide 5 text

クラウドサービス開発に携わる方へセキュリティチェックシートの記入を依頼されたことはありませんか？ [PR] Assured とは 5

Slide 6

Slide 6 text

煩雑なセキュリティチェックシートの回答に多くの手間を割いたことはありませんか？ [PR] Assured とは 6

Slide 7

Slide 7 text

Slide 8

Slide 8 text

セキュリティリスク評価情報を集約することでセキュリティチェック対応業務を効率化します [PR] Assured とは 8

Slide 9

Slide 9 text

[PR] Assured とは 9 気になった方は「Assured」で検索！ https://assured.jp/ アシュアード

Slide 10

Slide 10 text

Assured の技術スタック 10 インフラバックエンドフロントエンドその他ツール

Slide 11

Slide 11 text

新規事業でScala？ 11

Slide 12

Slide 12 text

Scalaはオワコン？ 12

Slide 13

Slide 13 text

オワコンかどうかはさておき Scala経験者を採用しづらいのは事実… Scalaはオワコン？ 13

Slide 14

Slide 14 text

なぜScala？ 14

Slide 15

Slide 15 text

スキルセット 15 なぜScala？ 15 早く作る

Slide 16

Slide 16 text

スキルセット 16 なぜScala？ 16 早く作るセキュアな作りがわかるセキュリティドメイン適切な品質が不明

Slide 17

Slide 17 text

注意した事 17

Slide 18

Slide 18 text

これらは担保したい 18 ビジネスに集中できる Scala未経験者も受け入れられるリライト・リアーキの選択肢を残せる PMF まで Product Market Fit

Slide 19

Slide 19 text

ありたい姿 19 捨てやすいコードである

Slide 20

Slide 20 text

意識したいこと 20 捨てやすいコードである読みやすい

Slide 21

Slide 21 text

具体的な指針 21 捨てやすいコードである読みやすい認知的負荷を下げる

Slide 22

Slide 22 text

認知的負荷とは ”心理学者ジョン・スウェラーが 1988年に「ワーキングメモリで利用される心理的労力の総量」として提唱したもの” 22 Matthew Skelton, Manuel Paisほか.「チームトポロジー価値あるソフトウェアをすばやく届ける適応型組織設計」 .日本能率協会マネジメントセンター .2021年.354ページ強調等は引用者による

Slide 23

Slide 23 text

“課題内在性負荷：問題領域の本質的なタスクに関連するもの ” “課題外在性負荷：タスクが実施される環境に関連するもの ” “学習関連負荷：学習を進めたり高性能を実現したりするうえで、特別な注意が必要なタスクに関連するもの ” 3種類の認知的負荷 23 Matthew Skelton, Manuel Paisほか.「チームトポロジー価値あるソフトウェアをすばやく届ける適応型組織設計」 .日本能率協会マネジメントセンター .2021年.354ページ強調等は引用者による

Slide 24

Slide 24 text

24 それぞれの例(自分なりの解釈) 24 学習関連負荷課題外在性負荷課題内在性負荷

Slide 25

Slide 25 text

25 それぞれの例(自分なりの解釈) 25 学習関連負荷課題外在性負荷課題内在性負荷 Scalaの文法を覚えたりプロジェクトコードの読み方に慣れるための負荷ビルド・テスト方法(sbtの使い方)や外部ツールのコンソールコマンド(マイグレーション手順など)を覚えるための負荷セキュリティ評価のロジックやサービス間の連携など、ビジネスドメインに関連した知識を得るための負荷

Slide 26

Slide 26 text

26 「読みやすい」とは 26 学習関連負荷課題外在性負荷課題内在性負荷 Scalaの文法を覚えたりプロジェクトコードの読み方に慣れるための負荷ビルド・テスト方法(sbtの使い方)や外部ツールのコンソールコマンド(マイグレーション手順など)を覚えるための負荷セキュリティ評価のロジックやサービス間の連携など、ビジネスドメインに関連した知識を得るための負荷こちらに集中しやすい状態

Slide 27

Slide 27 text

具体的な対策 27

Slide 28

Slide 28 text

一貫性をつくる課題(内|外)在性負荷を下げるためのTips 28 広く認知されている知識を利用する明瞭な意図を表す選択肢を絞る

Slide 29

Slide 29 text

一貫性をつくる課題(内|外)在性負荷を下げるためのTips 29 広く認知されている知識を利用する明瞭な意図を表す選択肢を絞る ① アーキテクチャ ② ビジネスロジック ③ リファクタリング ④ ドキュメントそれぞれに適用する

Slide 30

Slide 30 text

① アーキテクチャよく見る構成にする 30 Controller (Presentation) Service (Business Logic) Repository (Data Access) 広く認知されている知識を利用する選択肢を絞る Spring Boot等のレイヤードアーキテクチャに合わせる → どこを見れば何が書いてあるのか共通認識を持ちやすい → 各層の役割や依存関係はちゃんと制御する

Slide 31

Slide 31 text

② ビジネスロジック 31 ユーザ招待再送信処理のサンプル

Slide 32

Slide 32 text

縦に読めばほぼわかるよう徹底 ② ビジネスロジック 32 ユーザ招待再送信処理のサンプル ① 招待IDでDBから検索 ② 招待IDが間違っていれば NotFoundエラー ③ 招待が有効でない場合 BadRequestエラー ④ ログインユーザの組織情報を DBから検索 ⑤ 論理的に必ず存在する Option値を取り出す ⑥ メール再送信処理一貫性をつくる明瞭な意図を表す

Slide 33

Slide 33 text

Infrastructure(ORM)と密結合も辞さない → 疎結合で得られるメリットより「簡単さ」を重視 → cats.effect.IO や ZIO へ切り替える余地は残しておく (補足) for式の徹底を支えるクラス拡張 33

Slide 34

Slide 34 text

③ リファクタリング 34 Controller (Presentation) Service (Business Logic) Repository (Data Access) Model (Domain Logic)

Slide 35

Slide 35 text

Controller (Presentation) Service (Business Logic) Repository (Data Access) Model (Domain Logic) ③ リファクタリング 35 命名/パッケージ構成を頻繁に見直す一貫性をつくる明瞭な意図を表すドメイン理解は頻繁に変わる → どこに何が書いてあるか察せるようにする =ルール化 → 早すぎる最適化(ルールの暗黙知化)は避ける

Slide 36

Slide 36 text

36 ④ ドキュメント 36 手が空いたらなるべくまとめる明瞭な意図を表すバックエンド開発用のドキュメント負債になりにくい箇所はある → アーキテクチャは仕様ほど頻繁に変わらない → 変更の少ない箇所ほど思想 (暗黙知)が反映されがち

Slide 37

Slide 37 text

37 ④ ドキュメント 37 オンボーディングコンテンツ「 Daily Scala」原典

Slide 38

Slide 38 text

オンボーディングコンテンツ「 Daily Scala」原典 38 ④ ドキュメント 38 “オン”ボーディングも欠かさないプロジェクトに入るための最低限を担保する → 「Scala 勉強しておいてね」では選択肢が広すぎる → ドキュメントはPULL、初期はPUSHが重要明瞭な意図を表す選択肢を絞る 3年間のオンボーディングで培われた、リモートでも効果的な7+3のプラクティス

Slide 39

Slide 39 text

Scalaは使い方次第でちゃんとオンボーディングできるどれも特別な取り組みではないが徹底が重要まとめ 39

Slide 40

Slide 40 text

Scala経験者の採用に振り切ってもよかったのでは？ 40

Slide 41

Slide 41 text

新規事業における認知的負荷 41 学習関連負荷課題外在性負荷課題内在性負荷

Slide 42

Slide 42 text

課題外在性負荷性荷新規事業における認知的負荷 42 情勢の変化学習関連負荷影響ビジネス変化によって必要な技術も変化するピボット

Slide 43

Slide 43 text

特定の課題(内|外)在性負荷に強い人を集めたとしても状況がひっくり返ることを想定する必要がある Scala採用に振り切るべきか 43 結局、課題(内|外)在性負荷の小さい環境を作りにいくことになる

Slide 44

Slide 44 text

課題(内|外)在性負荷に強い人ではなく学習関連負荷の変化に強い人が望ましい特定の課題(内|外)在性負荷に強い人を集めたとしても状況がひっくり返ることを想定する必要がある Scala採用に振り切るべきか 44 もっと言えば

Slide 45

Slide 45 text

大事なのは事業共感 45 学習関連負荷の変化に強い人にとってモチベーションの源泉となるのは事業への共感！

Slide 46

Slide 46 text

セキュリティチェックに課題感を持つ皆様世の中の仕組みを変えてみませんか？大事なのは事業共感 46

Slide 47

Slide 47 text

※アンケートにご協力頂いた方に　Daily Scalaの内容をプレゼントさせていただきます。 We are hiring!! 47 47 採用ページです Thank you for listening！アンケートへご協力お願いします。 https://careers.assured.jp