はじめに
こんにちは、バックエンドのテックリードをしている澤路です。
この記事は、株式会社asken (あすけん) Advent Calendar 2024 の12/19の記事です。
askenでは開発プロセスの一環として「概念モデル」というものを取り入れています。 この記事ではaskenの「概念モデル」とは何なのか、どのように作られ活用されているのかを紹介します。
導入の背景
askenでは今リアーキテクチャを進めており、レガシーなPHPからKotlinへシステムの移行を進めています。業務委託の方に協力してもらい進めているのですが、その業務委託の方に「あすけん」全体像を素早く知ってもらうことが必要でした。そういった理由から、システムの構成要素を一覧で見ることができる「概念モデル」を導入することにしました。
概念とは？
概念モデルの話をする前に「概念」というものについて整理しておきましょう。
ChatGPTにわかりやすく説明してもらったところ、下記のような答えが返ってきました。
簡単に言うと、「概念」というのは、人が目の前で起こっている出来事や物事を観察して 「これってこういうことだよね」と頭の中で整理して名前をつけたものです。
要するに、「概念」とは「ある物事に名前をつけて同じ認識をもてるようにしたもの」と言えるでしょう。
概念モデルとは？
どのようなものか？
askenで作成している概念モデルは、サービスを構成する「概念」を書き出し、それらの関係性を線で結んだシンプルな図です。さらに、各概念に対して仕様やバリエーション、説明などを追記して使用しています。
上述の「概念」の説明と組み合わせると、概念モデルとは「サービスを構成する要素に名前をつけて同じ認識を持てるようにしたうえで、それぞれの関係性を線で結んで一覧で見れるようにしたもの」になります。
簡略化した例ですが、下記のような図になります。
凡例
- 白い四角: 概念
- 黄色い付箋: バリエーション
- 水色の付箋: 仕様・説明
実際のサービスはもっと巨大で複雑なので、図があることでサービスの構造を直感的に把握できるようになります。
どうやって作っているのか？
概念モデルの理解ができたところで、次に、askenでの具体的な作成手順を説明します。
作成のタイミング
最初に作られるタイミングは、要件が大まかに固まった段階から始まります。ここで「最初に」と書いたのは、概念モデルがその後の設計〜実装を通じて更新され続けるためです。
作成のプロセス
最初の作成では、関係者を集めて1 ~ 2時間のミーティングを設定します。askenでは同時編集ができることと、色々な表現ができることから、Miroを使って作成しています。
具体的な手順は下記のとおりです。
ディスカッションで概念を書き出す
関係者で話しながら、関連しそうな概念をMiroに書き出します。
概念同士を線で結ぶ
概念の関係性を示す線を引き、必要に応じて多重度を記載します。
概念の認識を合わせる
各概念について仕様やバリエーション、説明が必要であれば追記し、認識を統一します。
仕様には例えば下記のようなものが書かれています。
- 値の取りうる範囲
- 年齢はX歳〜X歳まで登録可能
- 画像解析機能は課金している会員にのみ表示される
- 算出のための計算式
- 摂取カロリー = タンパク質(4kcal/g) + 脂質(9kcal/g) + 炭水化物(4kcal/g)
- BMI = 体重(kg) ÷ (身長(m) × 身長(m))
- 値の取りうる範囲
違和感のある部分を再検討
名前や関係性に違和感があれば、その場で見直します。
見直しのタイミング
概念モデルは一度作って終わりではなく、その後の設計や実装からフィードバックを得て更新されていきます。下記のケースで更新されます。
- 新しい概念を追加することで理解しやすくなる場合
- サービスの仕様が想定していたものと異なることがわかり概念モデルと相違がでた場合
- 概念を表す、より良い名前が思いついた場合
修正をして関係者に共有を行います。また、ディスカッションが必要であれば関係者で再度認識を合わせていきます。
ポイント
重要なのは「名前付けに時間をかけすぎない」というところです。関係者間で概念の認識があっていれば名称は後で見直していけばよいでしょう。実装が進むにしたがって、より認識に合った名前が思い浮かぶこともあります。
どういった効果があったか？
関係者が同じ用語で話せるようになる
概念モデルを作成することで、概念の名前と認識が関係者間で統一することができます。これにより、用語のずれによる認識齟齬を防ぐことができます。
これは、ドメイン駆動設計で言うところの「ユビキタス言語」として機能します。加えて、概念間の関係性が表現されているため、文字情報だけよりも理解しやすく認識のずれが起こりにくくなっています。
例として、文章だけで表現した場合と図を用いた場合を比べてみましょう。
文章で表した例 (一部の概念は省略)
- 食事
- 食事全体を表す。朝食、昼食、夕食、間食など、1日に摂取する食事の単位。
- 食事区分
- 食事の種類を分類する要素。
朝食、昼食、夕食、間食のように、1日を通して行われる異なる食事の種類を表す。
- 料理
- 食事の中に含まれる具体的な料理
食事を「食べなかった」場合は、食事に属する料理は0個となる
図で表した例 (再掲)
どちらのほうが理解しやすく、認識のずれが起こりづらく感じるでしょうか？
図の方がひと目で概念の全体像が把握できたと思います。
文章の方は、それぞれの説明は明確ではあるものの、それぞれの関係性が見えづらくなっています。そうすると全体像を理解するのが難しく、認識のズレが起こりやすくなります。
本来のサービスはもっと巨大で複雑な概念で構成されています。文章だけで理解するのは難しくなってきます。
オンボーディングの資料として利用できる
askenの概念モデルには、概念の仕様や説明が網羅されています。これにより新しいメンバーのオンボーディング時に非常に役に立ちます。サービスを構成する概念が一覧化されており、関係性も可視化されているため、新メンバーが全体像を理解しやすくなります。また、初見では理解しづらい概念には説明が記載されているため説明の効率が大幅に向上します。
まとめ
今回はaskenの「概念モデル」について説明しました。シンプルな図ですが、非常に強力な効果を発揮します。記事を読んでくれた人に「作ってみようかな〜」と思っていただけたら幸いです。
さいごに
askenでは「あすけん」を一緒に盛り上げてくれる仲間を絶賛募集中です！！
(会社名がasken、サービス名が「あすけん」となっています)
