釣りキチプログラマー翔平の備忘録 
はじめに
「ドメイン駆動設計をはじめよう」を読んで、
こういう考え方を持っていればあの現場の失敗は防げたかもしれない、
こういう進め方をしていればあの現場はもっと上手く回っていたかも、
という気づきがいくつかありました。
本記事では
僕が過去に参画したソフトウェア開発プロジェクトの失敗例を
いくつか紹介しながら、
なぜそうなってしまったのか？
その時どう手を打てば良かったか？
などを振り返りました。
過去の現場での失敗の振り返り
システムが中核の業務領域がコロコロ変わる
なぜそうなったか？？
- 事業戦略や中核の業務の認識が関係者でバラバラ
- 事業戦略や中核の業務を明確にできていない
- 顧客獲得のために顧客要望次第で簡単に中核の業務領域が変わる
これらが理由だと考えています。
どうすれば防げたか？？
プロジェクト開始時に、
事業戦略や中核の業務領域を何と仮定するかを決めて、
関係者全員で納得してから開始できれば良かったと考えています。
また、プロジェクトを進めながら少しずつそれらを
関係者全員で足並みを揃えて変更していく必要もあったと考えています。
(少なくとも顧客要望に振り回されてビジネスサイドだけが
中核の業務領域の捉え方を変えているような状況は避けるべきでした。)
そうすれば、
ビジネスサイドは
事業戦略にフィットする顧客に専念して
見積もりや交渉ができたかもしれません。
プロダクトマネージャーは中核の業務領域に専念して
魅力的な機能を検討できたかもしれません。
少なくともあってもなくても良いような機能を検討する時間は減るでしょう。
一方、ソフトウェアエンジニアは事業戦略や中核の業務領域に対して、
変更容易性を高めた設計ができたかもしれません。
中核の業務領域以外にコストをかけ過ぎたり、中核の業務領域を外部ベンダーに丸投げした後で内製化
なぜそうなったか？？
- それぞれの業務領域の特徴をソフトウェアエンジニアが理解していない
- それぞれの業務領域に対して効率的にソフトウェアを開発する意識が低い
これらが理由だと考えています。
どうすれば防げたか？？
中核の業務領域はコストをかけてでも変更容易性を高めるが、
それ以外の業務領域は他のサービス利用を検討したり、
外部ベンダーに開発を依頼することも検討することで、
それぞれの業務領域に対して最適な開発が
無駄なコストをかけずにできたと思います。
そうすれば、
変更が滅多に入らない箇所や、
複雑ではなかったり、競合他社との競争優位性に繋がらない箇所に対して、
大規模なリファクタリングやアーキテクチャ変更などを行って、
コストを浪費することはなかったと思います。
中核の業務領域を外部ベンダーに一先ず丸投げして、
変更容易性が低く、変更が危険で厄介なソフトウェアを
保守開発し続ける事態も避けられたかもしれません。
いつも仕様が複雑で、いつも想定外の変更
なぜそうなったか？？
- 機能要件を満たすことだけを考えてソフトウェアを作っている
- 事業戦略や中核の業務領域が何かをソフトウェアエンジニアが理解できていない
- 関係者のコミュニケーションはいつも伝言ゲーム
これらが理由だと考えています。
どうすれば防げたか？？
事業戦略や中核の業務領域とそれ以外の業務領域を
ソフトウェアエンジニア含めて関係者全員で認識を合わせ、
中核の業務領域になぜ変更容易性が必要かを理解する必要があったと思います。
事業戦略、中核の業務領域、事業が目指す方向性を理解した上で
どこの変更容易性を高めるべきかが判断できてソフトウェアが開発できれば、
ずれた仕様になることも、
要件が想定外と感じることも、
無駄なシステム化も、
変更の影響範囲が広がることもなかったかもしれません。
目的にあった最適で最低限の手段をまずは実現すればいいと自分は考えています。
ソースコードへのベタ書き、
トランザクションスクリプト適用、
システム化しない(手動での運用)という判断は、
業務領域によっては最適な手段になると思います。
全てを綺麗でコストのかかるアーキテクチャにする必要はないのです。
さらに、コミュニケーションは伝言ゲームではなく、
RDRAのような要件定義フォーマットを利用して、
この要件はなぜ必要で誰にどのような価値を提供するのか？
を関係者全員で認識を合わせながらプロジェクトを進められると
表面的な機能要件だけでなく、
その機能が必要な背景までお互いに理解できたかもしれません。
業務エキスパートとの話がいつも噛み合わずソフトウェアの作り直しが頻発
なぜそうなったか？？
- ソフトウェアエンジニアが独自の用語を利用していた
- 業務エキスパートだけが認識している重要な概念があった
- 異なる意味で同じ用語を利用したり同じ意味でバラバラの用語を利用していた
これらが理由だと考えています。
どうすれば防げたか？？
関係者間でコミュニケーションをとる際は
同じ概念を表現する同じ用語をきちんと利用すべきでした。
文脈によって意味が変わる用語であれば、
文脈もセットで明確に整理するとより認識齟齬が減らせたかもしれません。
また、
コミュニケーションで普段利用していない用語が登場したり、
ソースコードで普段のコミュニケーションで利用していない用語が登場したら、
放置せずに、どういう概念を表現した用語なのか？
それは見落としていた重要な概念ではないのか？
を確認することで、
業務エキスパートが伝えようとしてくれている重要な概念を
ソフトウェアエンジニアが見落とすことも減らせたかもしれません。
まとめ
ソフトウェアエンジニアが事業領域や業務領域を理解する努力をし、
ソフトウェアの実装と事業戦略を結びつける意識を持っていれば、
今回まとめたような失敗は減らせたかもしれません。
「ドメイン駆動設計をはじめよう」第I部に書いてある考え方を理解して、
意識して、ソフトウェア開発の現場で実践できれば、
今後作るソフトウェア開発は価値のあるものになり、
コストも最適にできると思います。
今回のテーマについては以上です。
DDD実践のためのきほんシリーズのまとめ記事を作りました。
是非こちらもご覧ください。
初めてドメイン駆動設計を実践する方に向けて〜DDD実践のためのきほん〜
第I部 設計の基本方針
Vlad Khononov
