こんにちは、岩松です。先日「Assured」として ScalaMatsuri 2022 にスポンサーセッションで登壇させていただきました。この発表では入社直後だった内山と「Assured」のScalaオンボーディングを振り返ってみたのですが、本記事ではこの発表を改めて要約、整理してみました。
TL;DR
- 「Assured」はScalaを採用したからこそ「捨てやすいコードである」ことに注力した
- 「捨てやすいコードである」ためにアーキテクチャ、ビジネスロジック、リファクタリング、ドキュメントにおいて認知的負荷を下げるよう工夫した
- 新規事業では「どう作るか」という前提は変わり得るので「どんな事業をつくるか」に集中できる環境づくりが大事である
新規事業でScala？
「Assured」ではバックエンドの開発言語にScalaを採用しています。ScalaはVisionalグループで長く活用されており多くの実績もありますが、トレンドとしては下火となっています。(Stack Overflow Insights からも人気が落ちてきていると見て取れます)
トレンドと実用性に相関があるかどうかはわかりませんが、採用(広報)やオンボーディングにおいてはトレンドに乗るほうが有利と考えられます。しかし、セキュリティドメインのサービスを堅牢性を維持しながら素早く立ち上げるためには、チームのスキルセットの中から最も安定して使える技術を選択する必要がありました。だからこそ、Scalaを選んだことが事業の足かせとならないよう「捨てやすいコードである」ことを開発初期から目標としており「捨てやすいコードである」ためには「認知的負荷を下げる」ことが重要だと考えていました。
認知的負荷とは
「チームトポロジー」で紹介されていたことから、よく話題に上がっていますが「認知的負荷」の定義は
ワーキングメモリで利用される心理的労力の総量
とされており「課題内在性負荷」「課題外在性負荷」「学習関連負荷」の3つに分類されています。それぞれあまり馴染みのない言葉かもしれませんが、開発現場(Assured)で例えれば以下のようになります。
- 課題内在性負荷 … Scalaの文法を覚えたりプロジェクトコードの読み方に慣れるための負荷
- 課題外在性負荷 … ビルド・テスト手法や外部ツールコマンド、またはチームのルールや組織の関係性を覚えるための負荷
- 学習関連負荷 … セキュリティ評価のロジックやサービス間の連携など、ビジネスドメインに関連した知識を得るための負荷
「捨てやすいコードである」ためには「課題内在性負荷」「課題外在性負荷」を軽減し「学習関連負荷」に集中できる状態が必要ではないかと考えました。
具体的なTips
では「課題内在性負荷」「課題外在性負荷」を軽減するため具体的には何をすればいいのか。「Assured」を作っていく上では
- 一貫性をつくる
- 明瞭な意図を表す
- 広く認知されている知識を利用する
- 選択肢を絞る
という観点を様々な場面に適用しています。
バックエンドはSpring Boot等で見られるシンプルなレイヤードアーキテクチャにしています。DDDやクリーンアーキテクチャの考え方を適用することで、より変更(不確実性)に強い構成にすることも考えましたが、そういった手法に馴染みのないメンバーが参画したときに学習コストが上がってしまうと考えました。一方でDDDやクリーンアーキテクチャで開発することを強みとするケースもあるとは思いますが、手法の認識が統一できるほど簡単ではないため、結果的にすり合わせ(学習コスト)が一定必要になると思われます。「Assured」ではまず事業を立ち上げるため「どんな事業をつくるか」に集中することを優先しました。
for式はScalaではお馴染みの記法で、処理のまとまりを表現するのに適しています。「Assured」ではこれを活用し、縦に読めば何をやっているのか簡単に掴めるようにしています。意外にもこの形式で可読性を維持するには工夫が必要なので、命名やロジックの責任分離に気を配ったり、処理分岐やエラーケースなど様々な処理パターンでも一貫性を作れる補助関数を用意しています。
DDDは適用していないと前述しましたが、ドメインモデルの整理にはコストをかけるようにしています。初期には曖昧だった理解が開発や運用を重ねていくうちに明確になっていくことが多々あるため、なるべく認識と表現の不一致(暗黙知)は残さないよう意識しています。この過程で命名やパッケージ構成に法則を作れることも多いため「どこに何が書いてあるか察せる」状態を維持する助けとなっています。
仕様が常に変化し続けるソフトウェア開発においてドキュメントは陳腐(負債)化しやすいのですが「Assured」ではアーキテクチャや基盤など変更頻度が低いものを中心として積極的にドキュメント化しています。なぜそうなっているのか、どういう思想なのか、どういった制約を作っているのかといった情報は放っておくと暗黙知化してしまいがちだからです。
また「Assured」ではScala未経験者のために「これだけやっておけば最低限コードを読むに困らない」よう内容を絞ったScala勉強会を開催するようにしています(Daily Scala)。いざScalaを勉強しようと思っても、プロジェクトでただちに役立つコンテンツを選んでいくのは難しいからです。
このようにPULL(ドキュメント)、PUSH(勉強会)を使い分けることで効果的なオンボーディングを狙っています。これについては他事業部(HRMOS)の取り組みを参考にさせていただいています。
どれも特別な活動ではないのですが、事業立ち上げの段階でこれらを徹底することが実際のオンボーディングでも効果的だったと感じています。
まとめ
「Assured」では、トレンドとして下火であるScalaを採用したからこそ認知的負荷を軽減することでScala未経験者でも採用やオンボーディングしやすい環境を作ってきましたが、そもそもScala経験者の採用に特化していれば、より少ないコストで事業成長に向かえたのではないでしょうか？
スタートアップや新規事業では環境やビジネスの変化によって「どんな事業をつくるか」が変化する可能性は高くなります。そして「どんな事業をつくるか」が変化すれば「どう作るか」においてベストな選択肢も都度変化します。もしScalaがベストな選択肢ではないとなってしまったときに「Scalaのプロダクトだから」といった理由で参画したメンバーがいれば、チームに所属する意味をなくしてしまうかもしれません。結果的により大きなコストを払う可能性があります。よって特定の技術や手法に強みがあるよりも「どんな事業をつくるか」に強い関心を持つ人材であることが重要だと考えました(その上で技術的挑戦に取り組んでいけるチームでありたいと考えています)。
したがって、不確実性を考慮すれば「どんな事業をつくるか」に関心を持ち、技術や知識のハードルを越えて参画してくれるメンバーが負荷なく開発に集中出来る環境をつくることが事業成長にとっての近道だったと気づきました。
こうした方針は、どういった仲間を採用したいのか、ということにも繋がってきます。「セキュリティチェックシートの課題」に一家言をお持ちの方、是非「Assured」で解決してみませんか？
