Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

4e1f5a8e5bdb0fffe48d0224144faf1f?s=128

Tatsuya Iwamatsu

March 19, 2022
Tweet

More Decks by Tatsuya Iwamatsu

Other Decks in Technology

Transcript

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

  2. 自己紹介 2 岩松 竜也 いわまつ たつや 内山 陽介 うちやま ようすけ

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

    息子と電車旅 , お酒チョットノム 自己紹介 3 岩松 竜也 いわまつ たつや 内山 陽介 うちやま ようすけ 今日はどんどん ツッコミしていきます 2015年 株式会社ビズリーチ新卒入社 HRMOS採用で開発全般を担当 2020年 Assured へ異動 開発全般を担当 2012年 株式会社サイバーエージェント新卒入社 主にモバイル向け SaaSの開発全般、 プリセールス、テクニカルサポートを担当 アマゾンウェブサービスジャパン合同会社入社 ソリューションアーキテクトとして、 クラウド導入支援や技術支援を担当 2019年 Assured にエンジニアとして参画 2022年
  4. Visional グループとは 2020年2月の経営体制移行に伴い「ビズリーチ」から「 Visional グループ」として 新しいスタートをきりました。

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

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

  7. 7

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

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

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

  11. 新規事業でScala? 11

  12. Scalaはオワコン? 12

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

  14. なぜScala? 14

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

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

  17. 注意した事 17

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

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

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

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

  22. 認知的負荷とは ”心理学者ジョン・スウェラーが 1988年に 「ワーキングメモリで利用される心理的労力の総量 」 として提唱したもの” 22 Matthew Skelton, Manuel

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

    23 Matthew Skelton, Manuel Paisほか.「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」 .日本能率協会マネジメントセンター .2021年.354ページ 強調等は引用者による
  24. 24 それぞれの例(自分なりの解釈) 24 学習関連 負荷 課題外在性 負荷 課題内在性 負荷

  25. 25 それぞれの例(自分なりの解釈) 25 学習関連 負荷 課題外在性 負荷 課題内在性 負荷 Scalaの文法を覚えたりプ

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

    ロジェクトコードの読み方に 慣れるための負荷 ビルド・テスト方法(sbtの使 い方)や外部ツールのコン ソールコマンド(マイグレー ション手順など)を覚えるた めの負荷 セキュリティ評価のロジック やサービス間の連携など、 ビジネスドメインに関連した 知識を得るための負荷 こちらに 集中しやすい状態
  27. 具体的な対策 27

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

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

    ビジネスロジック ③ リファクタリング ④ ドキュメント それぞれに適用する
  30. ① アーキテクチャ よく見る構成にする 30 Controller (Presentation) Service (Business Logic) Repository

    (Data Access) 広く認知されている 知識を利用する 選択肢を絞る Spring Boot等のレイヤードアーキテクチャに合わせる → どこを見れば何が書いてあるのか共通認識を持ちやすい → 各層の役割や依存関係はちゃんと制御する
  31. ② ビジネスロジック 31 ユーザ招待再送信処理のサンプル

  32. 縦に読めばほぼわかるよう徹底 ② ビジネスロジック 32 ユーザ招待再送信処理のサンプル ① 招待IDでDBから検索 ② 招待IDが間違っていれば NotFoundエラー

    ③ 招待が有効でない場合 BadRequestエラー ④ ログインユーザの組織情報を DBから検索 ⑤ 論理的に必ず存在する Option値を取り出す ⑥ メール再送信処理 一貫性をつくる 明瞭な意図を表す
  33. Infrastructure(ORM)と密結合も辞さない → 疎結合で得られるメリットより「簡単さ」を重視 → cats.effect.IO や ZIO へ切り替える余地は残しておく (補足) for式の徹底を支えるクラス拡張

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

    Access) Model (Domain Logic)
  35. Controller (Presentation) Service (Business Logic) Repository (Data Access) Model (Domain

    Logic) ③ リファクタリング 35 命名/パッケージ構成を頻繁に見直す 一貫性をつくる 明瞭な意図を表す ドメイン理解は頻繁に変わる → どこに何が書いてあるか察せるようにする =ルール化 → 早すぎる最適化(ルールの暗黙知化)は避ける
  36. 36 ④ ドキュメント 36 手が空いたらなるべくまとめる 明瞭な意図を表す バックエンド開発用のドキュメント 負債になりにくい箇所はある → アーキテクチャは仕様ほど頻繁に変わらない

    → 変更の少ない箇所ほど思想 (暗黙知)が反映されがち
  37. 37 ④ ドキュメント 37 オンボーディングコンテンツ「 Daily Scala」 原典

  38. オンボーディングコンテンツ「 Daily Scala」 原典 38 ④ ドキュメント 38 “オン”ボーディングも欠かさない プロジェクトに入るための最低限を担保する

    → 「Scala 勉強しておいてね」では選択肢が広すぎる → ドキュメントはPULL、初期はPUSHが重要 明瞭な意図を表す 選択肢を絞る 3年間のオンボーディングで培われた、リモートでも効果的な7+3のプラクティス
  39. Scalaは使い方次第で ちゃんとオンボーディングできる どれも特別な取り組みではないが徹底が重要 まとめ 39

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

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

  42. 課 題 外 在 性 負 荷 性 荷 新規事業における認知的負荷

    42 情勢の変化 学習関連 負荷 影響 ビジネス変化によって必要な技術も変化する ピボット
  43. 特定の課題(内|外)在性負荷に強い人を集めたとしても 状況がひっくり返ることを想定する必要がある Scala採用に振り切るべきか 43 結局、課題(内|外)在性負荷の 小さい環境を作りにいくことになる

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

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

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

  47. ※アンケートにご協力頂いた方に  Daily Scalaの内容をプレゼントさせていただきます。 We are hiring!! 47 47 採用ページです Thank

    you for listening! アンケートへご協力お願いします。 https://careers.assured.jp