前回までの第十五章
ドメインビジョン声明文
多くのプロジェクトでビジョン声明文、プロジェクト憲章、インセプションデッキなどを作ると思います。
作ってます？作りますよね。
そして、それって維持されてます？されてますよね。
プロジェクトが始まったら、軌道に乗ったら、捨てられたりしてませんか？
プロジェクト初期でしか価値のないものであれば、それでもいいかと思いますが。。。
コアドメインとコアドメインがもたらす価値に関する簡潔な記述を作成することで、開発のあらゆるフェーズで、リソースの割当やモデルの選択の指針とすることができて、チームメンバの教育にも使用できます。
プロジェクト開始時から開発に集中する必要があり、後期では、モデルを詳細に調べなくてもシステム価値を説明する必要があります。
なので、経営陣も開発メンバーも直接使用することになる文書です。
当然、焦点はドメインモデルの本質とビジネスにどのように役に立つかが内容として書かれることになるでしょう。
書籍の例を読むとわかるとおり、ここには、技術的なことは書かれず、単純にコアドメインが、ビジネスにおいて何をするもので、どんな価値をもたらすのかが書かれます。
プロジェクト初期のうちに作成し、新しい洞察を得た時点で修正することが大事です。
自分はまだ、ドメインビジョン声明文を作ったことがないのですが、書くことによる効果は大きいだろうなと思いました。
インセプションデッキを作った後、ストーリーマッピングを作る過程、最初のリリースプランニングをする過程、最初の概念モデルを作る過程、コンテキストマップを作る過程などでドメインビジョン文書を作って、インセプションデッキと一緒に保守していくのがいいかもしれませんね。
インセプションデッキより高頻度で修正されると思いますが、そのたびにインセプションデッキの見直しもするきっかけになるでしょう。
あとから揉めるところを文書化しておく(変更があることを前提に)
ドメインビジョン声明文の価値は、大抵あとから揉めることを事前に文書化しておくところにもあると思います。
ここは自分の経験的にもそうです。
プロジェクトの中盤になっても、「結局このアプリの価値ってなんでしたっけ？」という会話したことがありませんか？
この時期になっても明文化されたものがないと、永遠に終わらない会話が、しかも繰り返しなされることになります。
こうなってくると、コアドメインはどこ?となっても、人によって違ったり、コアドメインなのに、他のチームやSIerさんに出してしまったりということもあるかもしれません。
この文書があることで、チームに共通の方向性を与えることができます。
逆に、このような文書を作らないチームも多いと思います。その動機としては、「どうせ後から変わるから、変わったら揉めるから」という点だと思います。
インセプションデッキもそう。作らないチームの動機は同じものだと思います。
でも揉めてませんか？作ったら揉めるといいつつ作ってないのに揉めてる。
あとから変わる、それはその通りなのですが、揉める原因は変わったからではないのです。
変わる前の元々の定義が曖昧であること、または、勝手に誰かが変えてしまうこと
これが原因なんです。
なので、大事なのは今！現時点!でわかっていること、わかってなくても現時点ではこうしておこうというのを残していくことだと思います。
変更ありき。変更が当然としてあること。
変更は文書が修正され、チームで合意を得ることで変更されること、これを継続することが大事です。
コアドメインも変化していきます。変化に対応していくためにもドメインビジョン文書はあったほうがいいと思います。
インセプションデッキも
このように考えるようになったきっかけは、インセプションデッキを作らなかった結果、その内容について後から揉めることがあったためです。
プロジェクト中盤で「そもそもなんでアプリ作ってるんだっけ？」「他の人にこのアプリの価値が説明できない」「これはやらないって言ってたよね」「またステークホルダが増えた？まだ増える？」「いつの間にか期間も機能も固定になってる」なんて揉めるんです。
そして、大抵揉める内容はインセプションデッキで書かれるべき内容のことだったんです。
これも揉める原因は変わったことに対してではなくて、そもそも決めてない、曖昧にしてた、勝手にいつの間にか変わってたことが原因でした。
なので、インセプションデッキも後から変わる前提で、現時点での、決まってなかったらこうしておこうという内容を文書化しておくのは非常に大事です。
ドメインビジョン文書とインセプションデッキは作ったらプロジェクト期間を通してとても価値のある文書になると思います。