こんにちは、2022年4月にフォースタートアップスにジョインしたエンジニアの八巻（@hachimaki37）です。主にタレントエージェンシー支援システム（SFA/CRM）のシステム開発を担当しております。現在所属するチームでは、サーバサイド（Ruby,RoR）、フロントエンド（Vue.js）の役割を分けず、2週間のスプリントを切って開発を行なっております。
少し前から興味が湧いていたドメイン駆動設計(以下、DDDと呼ぶ)、ありがたいことに外部研修の参加を募るアナウンスがあったため、DDD Boot Campという外部研修を受講してきました。
詳細は後述しますが、きっかけは、近い未来に訪れる当社の一課題をDDDで解決できないか？と思ったことです。また私自身、DDDについて言葉や概念をなんとなく知っている程度であったため、実践に役立つ知識を養いたいという思いで参加してきました。
今回のテックブログは、近い未来に訪れる組織変化を考えながら、DDDとは何かを初め、DDD Boot Campを受講して見えた学びや見解、そしてアクションなどについて執筆していきたいと思います。
※注記：タレントエージェンシー支援システム（SFA/CRM）とは？
時より、この言葉を使用しておりますが、社内のさまざまな部門の方々が使う業務システムとご認識頂ければと思います。
DDD Boot Campとは？
本題に入る前に、DDD Boot Campとは何かについて簡単に説明します。
講師情報：和智 右桂さん
- 独学ではなかなか全容がつかみにくいドメイン駆動設計についてわかりやすく学べる
- ワークショップ形式での体験を通じ業務にいかせる実践力を身につける
業務フローやシナリオは多くの現場で使われていますが、漫然と書いていても、今ひとつぴんと来ない、ということになりがちです。 単に手を動かして成果物を作るだけでなく、きちんと理解してそれを共有するためにはどうすればよいのか、ドメイン駆動設計（DDD）のバイブルでもある『エリック・エヴァンスのドメイン駆動設計』（翔泳社刊）翻訳者でもある和智右桂氏を講師に迎え、DDDにヒントを得ながら、ワークショップ形式でポイントを学ぶ講座です。
私が参加した回は、参加者20名のオンライン実施。講義に参加してみて、DDDの概念を一から知れたこと、ワークショップがあったことで、知識が一人歩きせず、業務との接続イメージが沸き、全体を通して非常に学び多い時間となりました。
近い未来に訪れる変化と課題
それは、システム利用ユーザーの変化によるコミュニケーションの肥大化です。
以下、当社 2023年3月期 通期決算説明資料から情報を抜粋しています。
引用元：https://pdf.irpocket.com/C7089/bU43/fyL8/CPUq.pdf
入社から現在にかけて、タレントエージェンシー支援システム（SFA/CRM）のシステム開発を担当しておりますが、組織拡大に伴い、今後様々な問題が出てくることが想定されます。その一つが社員数純増に伴う問題です。上記資料を見てわかるように、社員数が前期末比 +51名純増であること、そして4月以降更なる純増が見込まれます。
そこで、現在もなお顕在化しつつある問題の一つが、入社比率の変化です。具体的には、業務システムに慣れてない新人の方々が社員数全体の約40%となる近い未来が見えており、生産性の低下が大きな課題となってきています。
引用元：https://pdf.irpocket.com/C7089/bU43/fyL8/CPUq.pdf
現行システムでは機能しないのか？
決してそう言うことではありません。この先を見据えた進化、それはもっと未来にフィットさせたプロダクトへの進化が必要なのではないかという事です。
あくまで個人的な考えですが、タレントエージェンシー支援システム（SFA/CRM）は、ローンチされてからすでに数年が経っております。当初のプロダクトビジョンと今向かうべきビジョンにギャップが出始めているのではないかと考えております。それもそのはずで、会社としてのフェーズ・組織デザイン（人数・体制）が変われば、システムの課題や価値も自ずと変わっていくことでしょう。
未来に向けた新たなプロダクトビジョン
実は最近、「シンプル」と「安全」をキーワードにした新しいプロダクトビジョンが定義されました。つまりそれは、次の未来へ繋げる「意志」と「価値提供」がプロダクトに吹き込まれたという事です。そして、私どものチームでは、以下テーマを設定し、開発を進める形となりました。
- 人員数の増加（業務システムに慣れてない新人比率の上昇）に対応できる環境
- 業務プロセスの改善（効率的な業務進行）
これらの問題と課題を鑑みた上で、方向性を決め、システム開発に繋げていく必要があります。
どう解決していくのか
とある日、Bizからアイディアを募る連絡が所属チーム内にありました。
エンジニアチームで見える、タレントエージェンシー支援システム（SFA/CRM）の改善ポイント、ブレストレベルで構いませんので、ぜひアイディアをよろしくお願いします！
的外れなアイディアも多々ありますが、いくつか考え、Bizへ提案してみました。
テーマ：情報を「探す」プロセスを改善する
数ヶ月前に情報の「集約」と「透明化」を目的とした、比較的大きいリリースが行われました。次に課題となるのは「情報伝達」だと考えました。情報を人へ伝え届けるためには、「探す → 見つける → (自身が)理解する → （論理や体系を立てる） → 伝える → (相手が)理解する → 伝わる」といったプロセスがあると考えており、そもそも「探す」行為に相当なコストがかかっている（当社ではUXリサーチを実施しており、そこで得た情報から見えてきた課題感）のではないかと考えました。
情報収集のプロセスを改善することで、業務プロセスの改善（効率的な業務進行）に繋がると考えました。
テーマ：ユビキタス言語を使う
人の増加や入社時期の違いから、コミュニケーションコストが以前に比べ、倍以上に増加することが想定されます。なぜなら、バックグラウンドが人によって異なるため、言葉の定義や理解の違いから意思疎通が困難になるからです。
つまり、本来使うべき時間的コストが失われるため、共通言語化を図り、コミュニケーションコストを極力減らしていく策が良いのではないかと考えました。
など、さまざまなアイディアを考えてみました。
うっすら見えてきた課題感と解決の光
Bizとの共通認識である課題、それはユビキタス言語（共通言語）の活用です。「共通言語が少ない、もしくは合っていないか」そういった課題をBizは抱えておりました。私どもの新たなプロダクトビジョンであるシンプルとは何か。詳細は割愛させて頂きますが、一つの意味合いには「言葉の意味整理と統一（ユビキタス言語）」という概念があります。
少し糸口が見えてきた気持ちでした。そして、その課題解決を実現する手段の一つがDDDであると考えました。ようやく、DDDの話です。
ここからは、DDDとは何かを初め、参加してみての気づきや学びについて書いていきたいと思います。（具体的な方法論は述べていません）
重要な観点
ドメイン駆動設計は、「Design」である。よく見かける〇DD（例えば、TDD, MDD, UCDD…）は、Development（開発やテスト）の話ですが、Domain-driven design（DDD）は、開発手法ではなく、デザイン手法・設計の話であることを念頭に置く必要があります。よく出会う問題とそれにうまく対処するための設計であり、将来の変更や発展性に耐え得るかというアーキテクチャ的観点が必要です。
学んだこと
大きく下記4点です。
1. ソフトウェアには、業務知識を反映させる
DDDとは、エリック・エヴァンス氏により提唱され、一言で言うと「ソフトウェアには、業務知識を反映させましょう」という概念です。具体的には、頭の中に構成している業務知識を抽象化して反映させることです。ただし注意点があり、単なる業務知識を反映させるのではなく、不要な概念や知識が省かれ、「選び抜かれている」点がポイントです。
2. 隠れた概念を見える化し、ドメインモデルに（境界線を）反映させる
「どういう業務であるか」という概念の見える化を行う手法を様々知ることができました。例えば、業務フロー図、ユースケース図、ロバストネス図などです。ここでのポイントは、選び抜かれた業務知識の業務構造に関する理解を、「そのままソフトウェアで表現する」ことです。 業務知識を表現することで、業務理解とプログラム設計を直接的に関連づけられることで、プログラムがわかりやすく整理させ、ソフトウェアを柔軟に拡張したり、安全な変更を可能とします。
3. 1と2を実現するには、ユビキタス言語（共通言語）の認識と理解が重要である
Devだけで、完結するものではありません。Bizが選び抜いた業務知識を反映するだけでは物足りません。DevとBiz、双方がドメインモデル（選び抜かれた業務知識）への共通認識と理解が重要なのです。そのためにはまず、業務フローの中で使われている言葉の定義と認識を合わせることが、ファーストステップとして必要です。
4. 大切という感覚は、抽象化した自分の解釈における価値観である
言葉スケッチというアイスブレイクを冒頭に行いました。1対Nの関係で、1がお題となる写真を言葉だけでNに伝え、その情報を元にNがスケッチするといった内容です。私は、Nの立場で参加しましたが、思いの外難しい。1の立場からすると、そもそも描かれている全ての情報を説明することは困難であり、目に映るモノの中で、大切だと思うモノを自身で選択して説明しています。つまり、伝えている情報は、そのモノ自体ではなく、自分の理解（＝モデル）なのです。
ユビキタス言語の認識と理解を合わせるためには、言葉だけのコミュニケーションではなく、上記で紹介した〇〇図などを使い、双方の概念やモデルの見える化を行い、共通のイメージを合わせる過程が必要です。どの言葉を選択し、どのように相手の頭の中を整理しながらモノごとを伝えていくのか、このような「言葉で作りたいモノを伝える」ことは非常に重要なスキルです。
実践してみようと思うこと
1. 言葉の意味整理と統一（ユビキタス言語）
ここは欠かせないと感じました。DDDをやるやらないに関わらず、言葉の共通理解の重要性を改めて感じました。まずはチーム内から、そしてユーザーとのコミュニケーションをユビキタス言語で図れる世界に近づけるよう、ファーストステップを踏んでいきたいと思います。
2. 業務フロー図、ユースケース図、ロバストネス図、ホワイトボードなどを使って、図でイメージを伝える
私自身、（例えばロジックなど）テキストや言葉だけで結構伝えていたなぁと痛感しました。つまり、イメージの理解がおそらく合っていないということです。伝え方もあるかとは思いますが、根本的に各々が見ている視界や視点（DevとBizなども含めて）が異なるため、捉え方・理解の仕方がバラバラになっていると感じました。共通のイメージや認識を持てるよう、図や表現でイメージを伝え、見ている世界がより鮮明になるようにしていきたいと思います。
3. ソフトウェアには、業務知識を反映させる
共通言語の認識を合わせた上で、設計してみるといった内容です。今までは、Dev視点でDevにとってわかりやすいER、クラス、命名などにしておりましたが、少なからず業務フローで使用している言葉を使い、共通認識を持って進めていきたいと思います。その前のファーストステップは、ユビキタス言語やコンテキストマップ作成などから計画的に進められると良いかもしれません。
まとめ
これら3点が少しずつ浸透し、形になって行くだけでも、前述した組織の一課題解決に近づいていくのではないかと考えます。
講義を聞いていて、DDD＝オブジェクト指向ではないか？と思った節はありましたが、オブジェクト指向との違いは、やはり「ドメインモデルがエンティティに反映されているかどうか」が大きな違いであることを知りました。何度も言いますが、DDDとは、ソフトウェアに業務知識を反映させることが重要です。つまり、「現実 → モデル → ドメインモデル → コード」を実践することで、ソフトウェアの価値を高めることを目指すものなのです。
ただし、全てDDDにすればいいじゃん！というものでもありません。不向きなシステム、不向きな開発サイクル、場合によっては損益分岐点を下回る可能性もあります。つまり、ドメイン駆動設計は、「Development」ではなく、「Design」であることを忘れてはいけないということです。
何をしたいのか、そのために何が必要なのかを考え、どう実現するかの順番が重要です。
あとがき
現状から見る課題のみならず、未来を見据え、何ができるのか、何をしなければならないのかを考え、一つ一つ課題解決に取り組んでいきたいと思います。またDDDは、まだまだ実践できるほどの知識ではないので、引き続き学んでいきたいと思います。
最後に採用情報です。
当社では、まだまだ採用募集中です。ぜひ一緒に成長していきませんか。ご興味ありましたらぜひ一度カジュアルにお話できたらと思います。
採用ページはこちら。（冒頭のTwitterにDM頂いてもOKです！）
