設計って技術的にも大変だけど組織的な大変さもあるよねという話

Product Team の竹原です。

みなさん、ドメインのモデリングしてますか? 最近私たちのチームでは以下のプレスリリースにある機能の開発に勤しんでいます。

FORCAS、生成AIを活用した新機能「AIセールストーク自動生成」の実証実験を開始 | FORCAS(フォーカス)|営業DXソリューション|企業データベースと顧客分析

その開発において、ドメインの理解をしっかり深めないまま開発を続けたためにちょっとつまづいてしまったので、反省も兼ねて記事にまとめてみることにしました。

ドメインの概要

上記のAIセールストーク自動生成機能には以下の図のように、

  • 課題に悩む企業
  • 自社のプロダクトをおすすめしたい FORCAS ユーザー

の2種類の登場人物がいます。

登場するドメインのイメージ

さらに、「このプロダクトの便益によって、この企業課題を解決できそうだ」というものが見つかれば、それらが1対1で紐付いて「マッチング」になります。

マッチングのイメージ

そして、「マッチング」をもとに企業課題の概要やプロダクトの概要など様々な情報をかき集めて AI に投げると、晴れて「セールストーク」が生まれます。

セールストークのイメージ

今になって図に起こすとシンプルではありますね。

何がどうなってつまづいたのか

つまづいたのは、以下の画像に示す赤枠の領域を実装している最中です。

フロントエンドのイメージ(プレスリリースから引用)

赤枠のところを実装するためには、バックエンドから以下の情報を取得してくる必要があります。

  • 課題に悩む企業の 企業名
  • 上記企業におすすめできるプロダクトの 名称便益
  • 課題の詳細やプロダクトの便益などを駆使して作られた セールストーク (図中の「具体的な提案内容」)

さて、↑この情報のまとまりをなんと呼べばよいでしょうか? マッチング?それともセールストーク?みなさんならどちらだと思いますか?

これをなんと呼ぶべきか、の認識がズレていた or 曖昧だったため、認識合わせとコード修正に時間を取られることになってしまいました。

原因1: 既存コードに何も考えず乗っかった

私達がこの開発作業に取り掛かる時点で、以下のような SalesTalk と名前がついているドメインオブジェクトが存在していました。

export class SalesTalk {
  companyName: string,
  productName: string,
  productMerit: string
}

ここに salesTalk というフィールドを追加できれば、上に示した図の赤枠の範囲を実装しきれそうでした。

export class SalesTalk {
  companyName: string,
  productName: string,
  productMerit: string,
  salesTalk: string
}

ここでチームメンバーが以下のような疑問を持ちました。

「セールストークというドメインがよく分からなくなってきました... これはマッチングというドメインと何が違うんでしたっけ?」

改めて整理すると下記のようになります。

  • セールストークとは
    • 企業課題とプロダクトの便益をもとに生成できる文章
  • マッチングとは
    • 企業課題とプロダクトの便益が紐付いているもの

どちらも企業課題やプロダクトの便益が同じように関係したドメインであり、明確に区別しなければ混乱を招く、ということがこの時点でわかりました。

教訓1: ドメインオブジェクトは常に見直そう (特にプロジェクト立ち上げ時期)

上記の会話をしたあと、チーム内でいろいろ整理をして「もともとあった SalesTalkMatching としたほうがよい」「Matching がフィールドとして salesTalk: string を持つこととしよう」としました。

この結論が正しいか誤りかはさておき、「セールストークとマッチングは何が違うのか」という問題提起があった上で、チーム内で認識を揃えたことが功を奏したと思っています。 ドメインオブジェクトを少しずつ作っていく上で、作ってみてから気づくことというのは多々あるはずです。 気づきを常にコードに反映するために、違和感などあればすぐ会話していくことが重要かと思います。

原因2: 過去の会話内容がロストした

前述した「SalesTalkMatching とするのが正しそうだ」という合意は、実は1ヶ月前に会話され合意済のものでした。 しかし、その合意をとったメンバーが他のチームへ移動していたり、開発とは別の運用作業やミーティングに呼ばれたりして、チームで合意をとったはずなのに実際はその合意をしたメンバーはチームにおらず、新しくチームに入ってきたメンバーしかいなかった、という状況が生まれていました。

「コレって SalesTalk なんですかね? Matching では?」
『あれ?それって前に会話して合意しませんでしたっけ?』
「あれ?そうでしたっけ?」
『......あ、合意とったメンバー誰もいなかったですね...』

という会話をあとになって行いました。

教訓2: 情報共有は大事

上記については情報共有をどうやっていくか?という課題感に終着すると思います。

私達の開発組織では、常にペアプログラミングを実施しており、その中で起こる様々な会話によって情報共有を行なっています。 また、「できるだけドキュメントを書かない」という開発組織の文化もあり *1 、「ドキュメントに書いておいたから読んどいてね」ということはしていません。

ペアプロ中に何を伝えておくとよいか?というポイントの1つとして、今回の件がいい教訓になったと思います。

おわりに

開発者が正しく開発対象を理解するためにも、開発対象の設計を考えるためにも、名前付けは正しく行うのが重要かと思います。 図を描いて分かりやすくする、コミュニケーションを密に取る、など色々工夫ができそうですね。

この記事でとりあげた開発対象はシンプルに見えて意外と複雑なので、設計の練習のサンプルとして面白いかもしれません。 皆さんの知識・組織で開発をしようと仮になった場合、どのように設計が進み、どのように開発作業が進みそうでしょうか?一度考えてみると面白いかもしれません。

*1:こちらの記事もご参照ください: tech.uzabase.com

Page top