ScalaMatsuri 2022 Visionalグループ スポンサーセッションで発表させていただきました

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の文法を覚えたりプ
ロジェクトコードの読み方に
慣れるための負荷

26. 26
それぞれの例(自分なりの解釈)
26
学習関連
負荷
課題外在性
負荷
課題内在性
負荷
Scalaの文法を覚えたりプ
ロジェクトコードの読み方に
慣れるための負荷
ビルド・テスト方法(sbtの使
い方)や外部ツールのコン
ソールコマンド(マイグレー
ション手順など)を覚えるた
めの負荷

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

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

29. 具体的な対策
29

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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