2017年4月30日日曜日

2017年4月22日土曜日

ドメイン駆動設計の探求

まず、こんな感じのクラスを作った。
DDDっぽいように思えたのだが、大量データを扱うと破綻。



そこで、今度はデータをページングするような仕組みに変更したのだが、
その途端にDDDっぽくなくなった!
これはダメ、これもダメ、これはもっとダメ。



そんな時にDDDの賢人・増田氏のつぶやき。


そこで書籍『ドメイン駆動設計』に載っていたシーケンス図を手がかりにレイヤーを見直し。
んん、DDDの実装が分かってきた気がする……


ということで、今度はテーマを会計業務に変えてさらに研究する予定。
https://github.com/SasanumaTohru/AccountingSystem






ドメイン駆動の実装研究

 現在使用中の実行環境で、どのようにドメイン駆動による実装を行うかを研究中です。
 一先ず、プロトタイプを作ってみました。

ドメイン駆動の実装研究:プロトタイプ

2017年3月21日火曜日

DDD Alliance! ドメイン駆動設計 RDRA Night!

DDD Alliance! ドメイン駆動設計 RDRA Night! 〜ドメイン駆動設計に適した要件分析手法 RDRA〜 にて、下記発表を行うことになりました。

タイトル
「モデルが導く要件定義、文章が導くプログラミング」

内容
 私のソフトウェア開発史において、ある時までの要件定義とは、文章による要件の記述が中心であり、また、設計はモデルによる記述が中心でした。 しかし近年、これが逆転しています。
 要件定義は要件定義手法RDRAによりモデル中心となり、設計はドメイン駆動開発等のパラダイムに刺激され、文章的プログラミングに変化したのです。
 なぜこのようなことになったのでしょうか? そして、それによってどうなったのでしょうか?
 このようなことをお伝えしたいと考えています。


 DDDの増田氏、RDRAの神崎氏とご一緒させて頂きます。
 大変光栄ですが、ちょっと緊張しますね……

2017年2月25日土曜日

実装サンプルのコンテキストモデル

Blog『ソフトウェア開発戦略』では、私の開発戦略を具体的に説明しようと考えていますので、実装のサンプルとともに記事を書いていくつもりです。
実装サンプルは、具体的かつシンプルなものが良いと考え、下記のコンテキストモデルを定義しました。先に公開したドメインモデルと併せて見てもらうと、実装サンプルのイメージがつかめると思います。

実装サンプルのコンテキストモデル
コンテキストモデル
モデリングにはEnterprise Architectを使用しています。


注意!
実装サンプルは、インクリメンタルに開発していきますので、モデルとコードに差異が生じている場合があります。

実装サンプルのドメインモデル

GitHubにて公開しているサンプル(BusinessObject)のドメインモデルです。
一先ず、サンプルのスコープはこのモデルまでとして開発を進める予定です。


BusinessObjectのドメインモデル
BusinessObject

モデリングにはEnterprise Architectを使用しています。

2017年2月22日水曜日

改善を進めるために必要なこと(その2)~プロセスが見えれば結果の理解が異なる

 自身の考えを他人に認めてもらおうとしたとき、そのストーリーや根拠もさることながら、相手との信頼関係というのも重要な要素である。信頼関係が築かれていれば、相手はあなたの考えに耳を傾け、建設的な議論をすることができるだろう。
 信頼関係を築くための方法に、唯一絶対の方法はなく、それは相手によっても変わってくるだろうが、基本的な方法論というのはあると考えられる。今回は、私の経験に基づく信頼を醸成するためのアプローチを紹介したい。

 あるときの私の上司は、非常に細かい進捗報告を求める人物だった。そこで、毎週定例会議を行うことになったのだが、しばらく続けていると、面白い変化が現れてきた。最初は進捗状況に関して一方的な批判を繰り返していた上司が、定例会議を重ねるうちに、私と一緒の悩んだり考えたりするようになったのだ。つまり、プロセスを知ることによって、遅れている理由や問題解決の妨げとなっている課題などを理解するようになったので、結果だけを見て批判することができなくなったのだ。私は「なるほど」と思った。

 評論家は、プロセスを知ることで当事者に変わるのだ……

 この上司はしばらくして社を去ったが、この体験はとても貴重なものとして私の歴史に刻まれた。

 プロセスを見える化し、しかるべき利害関係者と共有することは、業務遂行上の問題や課題、その中での業務遂行者の困りごとや努力を共有することであり、その共有は現実への理解につながる。多くの場合、当事者ではない人々は正論で問題領域を読み解こうとするが、現実は正論で解きほぐせるほど単純なものではない。しかし、現実を知らなければ正論以外主張しようがないという部分もあるだろう。
 あなたにとって、自分の仕事のプロセスを他者に見せると言うことは、多かれ少なかれ精神的な負担を伴うことかもしれない。しかし、それを乗り越えられれば、個人で抱えてしまっていた問題や課題をチームで対応するという体制に変えることができるかもしれない。そして、他者はあなたのプロセスを知ることによって、あなたの出した結果に対する捉え方が変化するだろう。そして何より、自分のプロセスを可視化することによる他者からの理解は、信頼関係を醸成していくための重要なプロセスになると考えている。

 上司やチームのメンバーが変わったその後も、私は週一回の定例会議を続け、良いことも悪いこともすべて公開してきた。他者の心を正確に知ることはできないが、私は信頼を得ていると感じている。なぜなら、私が提案する改善やチャレンジが、チーム内で建設的に議論されているからだ。

プロセスが見えれば結果の理解が異なる
プロセスが見えれば結果の理解が異なる

2017年2月12日日曜日

改善を進めるために必要なこと

 Enterprise Architect事例紹介セミナーを終えた後、参加された方から次のような趣旨の質問を受けた。

「新しい手法を取り入れるには、どのように組織の中で展開していけばよいか?」

 この質問の背景には、改善後の成果をうまく利害関係者に示すことができず、その結果、改善が進められない、ということがあるように思う。そこで、今回は「改善を進めるために必要なこと」について、私の経験を基に考察してみたいと思う。

 まずは、逆の立場になって考えてみよう。あなたはシステム開発部門のマネージャーで、部下から改善提案を受けたとする。そして、その改善提案は実施するとなると、開発部門全体に影響する性質のものだと仮定しよう。さて、この改善の可否について、あなたはどのような要素により判断するだろうか?

 最初に考えるべきことは、失敗の代償はいくらか? 失敗の責任は誰に及ぶのか? ということだろう。つまり、リスクの評価だ。誰しも失敗はしたくないし、その失敗が取り返しがつかない、多大な損失を被る、というような時、誰もそんなリスクはとりたくない。一方で、物事にはリスクが常に存在し、確率的に顕在化する。リスクをとらずに成果を得ることは難しいという現実がある。さて、どうすればいいか?

 そこで必要になってくるのが、リスクをコントロールするということだ。恐れるに値しない程度までリスクが小さくなれば、あなたのマネージャーもYESと言ってくれるかもしれない。つまり、スモール・スタートという考え方だ。これにより改善の規模が小さくなれば、改善への取り組みに要するパワーも少なくて済む。少ないパワーあるいはコストなら、より多くの協力を得られる可能性もある。
 さらに、改善はステップ・バイ・ステップで進めていき(リスクを分割して進める)、最終的なゴールまでのロードマップについて、利害関係者間で合意することが必要だ。この時重要な観点は、成果よりも失敗について合意することだろう。なぜなら、あなたのマネージャーも、改善に成功すれば良き未来が訪れることくらい、ちゃんと分かっているからだ。

軽いリスクはみんな持てる
軽いリスクはみんな持てる


 次回は、このテーマの続きとして、「信頼の醸成」というようなことについて考えてみたいと思う。

ものこと静動4象限を核としたソフトウェア分析設計の基本モデル

 「ものこと静動4象限」を核としたソフトウェア分析設計の基本モデルを示します。
 これは、私のソフトウェア開発戦略の中核となる考え方です。


2017年2月11日土曜日

Enterprise Architect事例紹介セミナー「ソフトウェア開発戦略史」のスライドを公開します

 2017年2月10日、東京国際フォーラムにて行われたスパークシステムズ ジャパン㈱主催の「Enterprise Architect事例紹介セミナー」にて、「ソフトウェア開発戦略史」と題して講演を行いましたので、そのスライドを公開します。



2017年2月8日水曜日

オブジェクト指向を活かすための戦略 ~ 文章的プログラミング

 オブジェクト指向らしい設計や実装をするための第一歩は、命名にあると私は考える。

名前は?
名前は?

 開発環境が未成熟の頃、タイピング量を減らすためにこんな変数名をつけたことはないだろうか?

 dKeiyaku

  これは契約日を示すものと思われるが、確認するためには命名規約等を参照しなければならない。しかし、

 契約日

 となっていれば、他のものを参照しなくても変数の意味を理解することができる(もちろん、追加のコンテキストが必要な場合もある。例:賃貸借契約日、売買契約締結日)。このような意味のある言葉、業務で使われている言葉で命名することは、オブジェクト指向を活かすための基礎である。特に、パッケージ名、クラス名、プロパティ名、メソッド名は、命名についてしっかりと検討する必要があり、この検討とは設計そのものである。

 具体例を見てみよう。

 ①
 ColSyohin.Zaiko(Syohin)
 ColSyohin.KakakuUpdate(KakakuUpdateList)
 ColSyohin.Add(Syohin)

 ②
 販売情報.在庫数(商品)
 販売情報.価格を変更する(価格変更リスト)
 販売情報.追加する(商品)
 
 ③
 取扱商品.在庫数(商品)
 取扱商品.価格を変更する(価格変更リスト)
 取扱商品.追加する(商品)

 上記の違いが名前だけだとすると、機能要件はいずれも満たしているわけだが、わかりやすく表現されているものはどれだろうか? あるいは、業務の言葉で表現されているものはどれだろうか?
 ①は古き時代の作法であり、今日的ではない。
 ②はそう悪くはないが、「追加する」メソッドが販売情報に何を追加するのかメソッド名だけでは分からない。
 ③はどれも適切な情報を名前から読み取ることができる。

 私の場合は、実際のコードも日本語で命名しているが、このような命名方針によって設計・実装すると、クラスは機能的凝集度を高める方向に自然と向かうはずだ。なぜならば、そのクラスに実装することが不適切なデータやロジックが不自然な文脈として表れてくるからだ。

 取扱商品.本日の売上金額

 取扱商品の責務が売上金額の集計というのは不自然だ。販売された商品とその代金が売上伝票に記録されるのならば、売上伝票のコレクションクラスが売上金額の集計責務を負うべきだろう。例えば、売上帳簿、販売台帳など、実際に業務で使用されている言葉があるはずだ。

 売上帳簿.本日の売上金額

2017年2月5日日曜日

ソフトウェア開発戦略とは何か?

 ソフトウェアの開発をどのように進めるのか、ということについて、世の中にはたくさんの方法論が存在しているが、唯一絶対の方法は存在し得ない。なぜならば、ソフトウェア開発のゴールには、「的確な品質レベルで動作する」というどのソフトウェアにも共通のゴールに加えて、そのソフトウェア固有のゴールが意図されるからだ。
 また、どのような状況でソフトウェアが開発されるのかということも、開発方法の選択に大きな影響を及ぼす。プロジェクトやプロダクトの特性によって、「的確な品質レベルで動作する」こと以外にも、様々なゴールがソフトウェア開発には設定されるので、唯一の方法では、その多様なニーズを満たすことができないのだ。
 そこで、ソフトウェア開発の主体たる人物は、自己の知識と経験から状況を見極め、意図するゴールに合わせて方法を選択し、組み合わせ、改良し、これらを運用することでソフトウェア開発を進めるのだが、この、意図と意図に基づく選択、運用が、ソフトウェア開発戦略と私が定義する部分である。

ソフトウェア開発戦略って?
ソフトウェア開発戦略って?



2017年1月28日土曜日

『ソフトウェア開発戦略史』と題して講演します

 2017年2月10日(金)、東京国際フォーラムにて行われるスパークシステムズ ジャパン主催『Enterprise Architect 事例紹介セミナー』にて、『ソフトウェア開発戦略史』と題して講演します。

講演概要
 ソフトウェアの開発手法は無数に存在しますが、唯一絶対のものは存在しないと考えます。ソフトウェア開発を実践していくためには、自分や組織に合うように、複数の開発手法を組み合わせ、カスタマイズしていく必要があるでしょう。そこで、私が取り組んできた開発手法のカスタマイズの歴史をご紹介するとともに、これをいかにEnterprise Architectが支えてきたかを具体的な事例を交えてご紹介します。

2017年1月27日金曜日

新しいBlogを開設しました

 新しいBlog『ソフトウェア開発戦略』を本日(2017年1月28日)開設しました。