読者です 読者をやめる 読者になる 読者になる

Specification By Exampleの読書中(4)

前回の続きです。

 

第5章「ビジネスゴールからスコープを導出」の

Collaborating on scope without high-level control

からです。

 

大企業等で、「ビジネスゴールは上から渡されるものなので、

俺らにはどうしようもないよね。」という感じで、文句があっても前提をひっくり返せるような権威がない場合、どうすればよいかという話題です。

具体的な手段についてざっくりまとめます。

 

どんなものが役に立つか聞いてみる

ユーザにヒアリングして本当に必要なものが何なのか見極める。

ユーザがこうしたいといったこと以外にも、いい解決策があるかもしれない。

 

代替手段がないか聞いてみる

本当の目的をしるために代替手段について議論してみるのもいい。

代替手段を尋ねることによって、提案した解決手段がベストなものなのか

考えるきっかけにもなる。

 

低レベルのところだけ見ない

細切れになった作業にとらわれて全体を見失わないようにする。

 

完璧な機能を提供する

スコープとどんな機能を作るのか、ちゃんとユーザとお約束しましょう。

無駄な作業をせず、ユーザに本当に必要なものを提供するため。

 

 

 

 

 

Specification By Exampleの読書中(3)

久しぶりにSBE読書中です。

 

今回は、

「ビジネスゴールからスコープを導出」

の方法についてです。

いきなり5章までとびます。

 

間の3章4章にもいろいろ書いてありますが、大まかな思想的な話なので、具体性があって面白そうな章にとびました。

 

ここでは、

「まず最初に何を作るのか決めなきゃいけないよね」というのがテーマです。

もっともポピュラーな方法であるユーザーストーリーを使用して、

スコープを定義します。

 

どうやってビジネスゴールからスコープを導出するか以下の方法があります。

 

なぜ? だれが? を理解する

As a ~ I want ~ inorder to ~.構文を利用していろんな方向から考えてみる

価値はどこから来るのかを理解する

ビジネス価値と何がコア機能なのかを考える

どんなアウトプットをユーザが期待しているのか理解する

目標を決めることが難しい場合は、システムの期待されるアウトプットから考えてみる

ユーザーストーリの"I want"の部分は、開発者に考えてもらう

ビジネスユーザは、As a と So that を考えて、I wantは開発者が考える。ビジネスゴールを満たすための方法を開発者やテスターに議論させるため。

 

 

 

 

 

 

 

User#saveの件の補足

以前の記事に対しての補足です。

http://fusatsukatsujin.hatenablog.com/entry/2014/03/10/224421

 

前回の例では、「ユーザを登録する」というのをあげました。

この「登録する」というのは、ただ単にDBに永続化するという意味のつもりです。

永続化というか、システム的なライフサイクルについて、ドメインエキスパートは

もちろん興味を持っていないはずですので、ドメインモデル上にそれを定義するのはあまり意味がないです。

 

一方で、「会員を会員名簿に登録する」という文脈に登場する「登録する」

については、上記のケースとは異なります。

永続化するという意味ではなく、業務的に意味を持った言葉ですので、

これについてドメインモデル上に定義するのは意味があると思います。

 

「ユーザを登録する」の「登録する」はユビキタス言語ではないが、

「会員を会員名簿に登録する」の「登録する」はユビキタス言語として

定義してもおかしくないというわけです。

 

 

 

 

 

詳細設計書

 

詳細設計書ってよくわからない

http://d.hatena.ne.jp/hyoshiok/20140310/p1

 

いや、本当によくわからないんです。

なんで、いまだにこんなことに貴重な工数を費やさないといけないのか。

 

自分もかつてコードの一行一行に対応するようなEXCEL詳細設計書を作らされたことがありますが、なんともやりきれない気持ちになりました。

「ドキュメントをおろそかにしたプロジェクトが成功したためしはない」とかおっしゃる方がリーダだったのですが、目的も何も考えずにドキュメントをひたすら書かせた結果、だれも必要としない大量のEXCELが出来上がりました。

特にひどい記述だと、「○○オブジェクトをnewして、そこに××を格納する」というものもありました。

とりあえず処理を詳細に記述することが目的になっていて、

実装者以外がこれを読んでも意味分からんでしょというような感じでした。

もちろん、その処理のつまるところの目的なぞ記述されていません。

ただ単に処理を並べただけです。

最後には納品物として徹夜で印刷してファイルに閉じて客先(エンドユーザ)に持っていったらしいですが、今後誰もこの資料に目を通すことはないでしょう。

プログラマが読んでも分からないし、プログラマならコードを読んだほうが早いですから。

 

やっぱり、だれのため、何のためのドキュメントなのかということについて、ちゃんと考える必要がありますね。

 

「コードは暗黙知だから、形式知化するためにドキュメントを作らないといかん」みたいな記述をなにかの本で見たような気がします。

コードは所詮処理の塊ですから、意味するところ(What)を伝えるためには、

なんらかの情報を補完してやらないといけないってことです。

こういう類のドキュメントなら必要だと思います。

それをどういう形で記述するのか、いろいろな方法があると思いますが。

 

# コードで表現できるならコードでもいいのでは? と言っても納得してくれない人も多いでしょうねぇ・・・。

 

 

DDDにおいて、なぜUser#saveがいけてないのか考えてみるテスト

数週間前にDDD勉強会(羊)に参加したのですが(なんとじゅんいち☆かとうさんがしゃべってくれました!)、なにも成果をまとめていなかったので、その後、思ったこと考えたことを、今までの読書範囲で自分なりにまとめたいと思います。

 

で、テーマは一点のみで、

掲題の通り、なんでUser#saveがいけてないのかです。

ドメインを永続化する場合には、Repository に対してドメインを格納するというアプローチを取り、

ドメインに自分自身を永続化する責務を割り当てないというのがDDDです。

勉強会では、「User#saveはユビキタス言語じゃないからだめ」ということでした。

ユビキタス言語として定義されていないものをドメインの責務に割り当てるのはおかしいというわけです。

 

でも、よくよく考えてみると、「ユーザを登録する」という文章は成立します。

ユーザを登録するという機能自体あるわけで、違和感はそんなになし、ユーザとその言葉を使用して会話をしていても不自然じゃないわけです。

オブジェクト指向的に考えても、ユーザドメインに対して、自分自身を永続化する責務を割り当てるのは、間違っているとは言えなさそうです。

でも逆に、モデル(ユーザとコミュニケーションをとるための)に「登録する」
という操作を記述するかというとやっぱりしないわけです。

相当な違和感があります。
ためしに、手元にあった「実践UML」をざーっとみてみましたが、register とか save なんていう
メソッドは見当たりませんでした。
当然な話です。ある概念をDBに永続化するということを記述する動機があるわけないですから。
# 逆に、AからBをcreate(またはmake)するというパターンは有ります。
# 何の情報を基にしてこれを作ればいいのかということと、ライフサイクル自体には興味はあるわけです。

考えてみれば、

ユーザとモデルを通じてコミュニケーションする際に、
「○○ドメインには、自分自身を永続化する責務を割り当てます」
なんてことを言ってしまったら馬鹿だと思われます。
なんか、ずれてます。

 

ドメインに責務を割り当てるということは、
ドメインの知識としてみんなと共有したいという意図があることを意味します。

そう考えた場合、User#save はちょっとずれてるわけですね。

 

みんなが知っても意味のないことはモデルには記述しないし、
ドメインにも責務として割り当てない。

みんなが知りたいことを書きましょうってことでしょうかね。

 

 一応、こちらで補足しました。

 

 

 

 

 

 

 

 

 

 

Specification By Exampleの読書中(2)

前回の続きです。

 

では、SBEのプロセスってどんなものかということですが、

これが2章に書いてあります。

おおまかには

http://en.wikipedia.org/wiki/Specification_by_example#Key_practices

に書いてあるとおりです。

つまり大雑把に和訳してみると、

 

ビジネスゴールからスコープを導出

みんなで仕様決め

例を挙げて仕様を説明

仕様を洗練

例に基づいてテストを自動化する

テストを使用してソフトウェアを頻繁に検証

将来の開発を支援するためのSBEのドキュメントシステムを進化させる

 

という流れでしょうか。

仕様決めにいたるまでの流れは、従来の手法とあまり違いはないですが、

仕様を「例」を用いて記述するところが、大きな特徴となります。

「例」をもちいて仕様を記述することにより、「実行可能な仕様」を作成することが可能となります。

その「実行可能な仕様」によりソフトウェアが、仕様どおりの振る舞いをしているかどうかを検証可能にすることが、

SBEのメリットのようですね。

 

 

 

 

 

 

 

Specification By Example読書中

話題の「Specification By Example」ですが、

とりあえず1章から読み始めています。

Specification By Exmapleは何なのかということと、おもなご利益について記述されているのですが、なんとなく理解できました。

 

まず、Speicfication By Exampleは、なにかというと、

「正しいソフトウェアを作る」ためのプロセスであるということです。

ソフトウェアの正しい作り方ではなくて、正しいソフトウェアというところが味噌です。

正しくソフトウェアを作るためには、

ユーザの要望どおりにシステムが作られているかどうか検証する、

仕様変更に効率的に追従する

等についてどうすれば効率的なのか考慮する必要がありますが、

このプロセスを利用することにより、その辺りでご利益があるということです。

 

とりあえず大まかな内容は、

http://yatsusoft.com/wiki/index.php?Chapter1%20Key%20benefits

へまとめました。