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

ScalaMatsuri 2022 のスポンサーセッションで発表しました

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

7. View Slide

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

   View Slide

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

   View Slide

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

    View Slide

11. 新規事業でScala？
    11
    

    View Slide

12. Scalaはオワコン？
    12
    

    View Slide

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

    View Slide

14. なぜScala？
    14
    

    View Slide

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

    View Slide

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

    View Slide

17. 注意した事
    17
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

27. 具体的な対策
    27
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide