受託開発のドメインモデル ドメインモデラーにとって 受託開発であることは制約なのか？ 2020/09/18 吉祥寺.pm24 末並 晃 @a_suenami

自己紹介 ● 末並 晃 @a_suenami ● 生息している界隈: DDDとか、TDDとか、RDBとか ● お仕事で使ってる技術スタック: Rails, React, Java ○ 最近は terraform おじさんです ● 好きな RDBMS: PostgreSQL ● 好きな制約: チェック制約 ● 好きな焼肉の部位: ハラミ ● 好きな（ｒｙ

インターネット上での立場

インターネット上での立場 ひたすら焼肉をタカられるという エンターテイメントをインターネットに提供し ています。 （焼肉を奢るとは言ってない）

今日話すことになったきっかけ

突然のmagnoliaさん登場！！

吉祥寺pmのpmは “P”olidogさんへの“m”essage です。

今日話すこと ● （ドメイン）モデルとは何か ● 受託開発にとってのドメインモデリングとは

今日話すこと ● いわゆる大規模な SIer さんの話ではなく、比較的小規模のWeb 制作会社のイメージです。 ○ 私自身に経験がないのでわからないだけで、同じような状況 にはあるかもしれません。 ● 具体的なドメインの話や実装の話はあまりしません。 ○ だいたい、いつもそう…

ドメインモデルとは

ドメインモデルとは

モデルとは https://speakerdeck.com/a_suenami/moderutohahe-deatute-he-denaifalseka-number-kichijojipm

モデルとは つまり、モデリングとは何を重要な情報と扱い 何を捨てるかを決めること

モデルとは 現実世界にある事象や課題 モデル

よくある問題 現実世界にある事象や課題 モデル 別の モデル

ドメインモデル 現実世界にある事象や課題 モデル

（ドメイン）モデルの例 対象 モデルの構成要素 クラウドインフラ インスタンス、セキュリティグループ、アベイラビリティゾーン バージョン管理 コミット、ブランチ、タグ、オブジェクトツリー メディア・コンテンツ レビューフロー、公開ステータス、公開承認者 広告 インプレッション、クリック、コンバージョン 会計 複式簿記（仕訳、元帳）

受託開発における“モデル”

受託開発であることは“制約”なのか ● よく言われる話 ○ 「うちは受託だから仕様はお客さんが決めるし、設計の自由 度は低い」 ○ 「納期優先になるのでモデリングなんかに時間かけられない」 ○ 本当に？ ● 顧客ごとに異なるビジネスを行っている（ことが多い）ため、構築し たモデルが会社としての資産になりにくい

理想的な状態 顧客の課題 モデル エンジニア 顧客 営業/PM

理想状態を目指すことの難しさ ● 自社（受託開発）側のエンジニア、PM/営業、顧客で単一のモデ ルを構築することは不可能ではないが難易度は高い ● 顧客の課題や業務プロセスに特化したモデルは、自社の立場か ら見ると汎用性がなく資産になりにくい

自社のモデルを持つ場合 顧客の課題 ベンダーである自社の課題や経営方針 エンジニア 顧客 営業/PM

受託開発という名のドメイン ● 受託開発においてドメインモデルとは、顧客のためのモデルでは なく、自社のためのモデルであるべきではないか ○ 当然だがこれは顧客のモデルを理解しなくていもよいというこ とを意味するわけではない ● ソフトウェアを開発そのものを事業としている以上、顧客やプロ ジェクトをまたいだ知見の共有や経験値のストックをしているはず である ○ モデルというものはあくまでそれを言語化、記号化、可視化し ただけのものにすぎない ○ 表現方法はコードとは限らない

自社のモデルでビジネスをドライブする うちはメディアのお客様が多いので、 この知見を抽象化しよう。 そして、良質なコンテンツを持っているけど Webやアプリでの展開ができてない会社さ んにアプローチしよう。 E-Commerceって各社それぞれ努力はして いるけど、根っこの構造は似ているなぁ。 オンライン販売始めたいと思っている会社さ んのお手伝いをできないかな？ 受注を業務のスタート地点にしない！

例 対象領域 モデルの構成要素 顧客ごとの可変要素 記事系メディア 見出し、テキスト、リッチテキスト、画像、引 用・出典 アフィリエイトリンク、計測 レビュー・公開フロー ページビュー（PV）、ユニークユーザー数 （UU） 記事の構造 掲載管理の手順や権限の構造 PV/UUの定義、計測方法・ツール 画像系メディア 画像、クレジット（権利者）、引用・出典、画 像サイズ 画像の表示方法（リスト、タイル、 etc） メタ情報やタグの構造 予約管理システム 商品 予約、予約ステータス、ステータス状態遷 移 決済方法 商品の構成 カテゴリ構成 決済ベンダー EC 商品、商品カテゴリ、商品タグ カート、決済方法 在庫、発送、仕入れ 商品の構成 商品カテゴリやタグの構成 決済ベンダー

ここまでやるなら パッケージ製品やSaaSを 提供すればいいのでは？

受託開発とパッケージ/SaaS 受託開発 パッケージ / SaaS カスタマイズの 可能範囲 原則として要求の通りに実装可能 顧客価値が実装工数と釣り合うかどうか次 第 あらかじめ決められた範囲でのみ可能 カスタマイズの 難易度 顧客視点では容易 ベンダー視点では実装工数次第 大規模になればなるほど困難 専門のコンサルティングや運用代行が必要 になるケースもある モデルの表現方法 どのような方法でも可 顧客にはベンダーのモデルを公開する必 要はない 提供されている UI の影響が大きい モデルの相当範囲がコードとして表現され る 価格/費用 人月での算出が多い ベンダー側にとっては損をしにくい構造 アカウントごと、ユーザー数課金が多い ベンダーとしては開発コストをどれくらいの 期間やユーザー数で回収できるかの検討 と判断が必要

まとめ ● 受託開発でもモデリングは重要である ○ 顧客のモデルだけでなく、自社のモデルを意識するべきでは ないか ● 受託開発というドメインを突き詰めていくと、SaaS/パッケージ製品 に似た性質を持つようになる ○ パッケージやSaaSが適している領域もあるし、そうでない領域 もあるはずである ● 「受託は顧客の言われた通りに作るだけ」「受託はつまらない」と いう認識が減っていくことを願う

創造は 制約好む 名言かな（字余り） 一句

ご清聴ありがとうございました。