吉祥寺.pm24で発表させていただきました。
受託開発のドメインモデルドメインモデラーにとって受託開発であることは制約なのか？2020/09/18 吉祥寺.pm24末並 晃 @a_suenami
View Slide
自己紹介● 末並 晃 @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が適している領域もあるし、そうでない領域もあるはずである● 「受託は顧客の言われた通りに作るだけ」「受託はつまらない」という認識が減っていくことを願う
創造は 制約好む 名言かな（字余り）一句
ご清聴ありがとうございました。
a_suenami
tk3fftk
hiroyaonoe
misatokii
morikann
ivargrimstad
hollycummins
kazupon
techouse
akkyie
rdmueller
os1ma
keavy
3n
kneath
lara
matthewcrist
scottboms
morganepeng
csswizardry
keithpitt
addyosmani
jeffersonlam
yeseniaperezcruz