XP, ICONIX, ウォーターフォール : 要件定義 全体像を描く

要件定義はソフトウェア開発プロジェクトで「役に立つ」ソフトウェアのイメージを関係者で共通理解にするための活動ですね。

「役に立つ」は「良い」「欲しい」「価値のある」「顧客が満足する」とか言うこともできる。

XP, ICONIX , 伝統的な方法論 のどれにでも共通するやり方は

機能 : ○○する。 ◇◇できる。 動詞に注目したコミュニケーション。
画面 : 実際に見える部分に注目したコミュニケーション。
データ: 情報の名前に注目したコミュニケーション。

だと思います。

伝統的なウォーターフォール系の方法論

詳細に定義されたドキュメント形式、作成手順、レビュー・承認手順、を使って網羅的に、「機能」「画面」「データ」のイメージを固めようとする。

「ドキュメント&レビュー」と「網羅性」が基本価値ですね。

XP

「ユーザーストリー」として機能を簡単な文章で書く。
画面は、現在開発対象の「ユーザーストリー」に関係する画面を、手書きとかしながら、ユーザとおしゃべり(ブレスト)して具体像を掴む。 データも、いま対象の「ユーザーストリー」について、簡単なクラス図を描いたりしながら、ユーザや開発者同士で話をして、イメージを固める。
ある程度イメージが固まったら、実際にコードにして、動かしてみる。動くソフトウェアを使って、さらに要件を確認していく。

「動くソフトウェア(とコード)」、「一度に一つ」、「おしゃべり」が基本価値ですね。

ICONIX

関係者で共通の用語集としてドメインモデル(概念クラス図)を描く。その用語を使って、ユースケースパッケージ図で、機能を洗い出す。
重要なユースケースからシナリオを記述して、実装していく。作業の途中で、関係者でいろいろおしゃべり(ブレスト)しながら、モデルを改良していく。ユースケース記述を書いたら、関係者で公式の要求レビューをやって、お互いの理解に不一致がないか、確認していく。

「モデル&レビュー」、「全体像」、「一度に一つ」が基本価値ですね。

全体像の位置づけ

伝統的なウォーターフォール系のやり方では、最初に全体像や一覧をきっちり作成して確認することを重視する。

XP はそこにはこだわらない。重要だと合意できたものから順番に片付けいくイメージ。

ICONIX は、全体像や一覧は最初にラフスケッチはやる。それは、確定を意味するものではなく、不完全な宝島の地図、というようなイメージ。開発しながら、だんだん、より具体的なことが明らかになってくるし、地図の修正も当然あり。

XP は全体像の把握については、プロジェクト開始前に議論されていて、参加するのもビジネス側も開発側もそれなりの視野と判断力を持っているメンバーを(暗黙の?)前提にしているよう気がする。 だから、特に説明していないだけで、全体像の把握を無視しているのではないと思う。
「事前の議論」や、「レベルの高いコアメンバー」という前提が崩れると、XP はムリっぽい。

まあ、XP や ICONIX は、全体像の境界線の細部の確定には時間をかけない。 どうせ変わると思っているから。

受託開発だと、そうは言っても、契約範囲という概念がでてくるから、一定の決め事は必要。だから、大きな単位の契約をする開発会社は、どうしても、伝統的なウォーターフォール系のやり方で、全体範囲や一覧定義に時間とエネルギーをかけることになる。

アメリカだと XP でやる場合、契約範囲とかどうしているでしょうね?

XP, ICONIX, ウォーターフォール : 全体最適化

ウォーターフォール系のアプローチは「全体を見通すことで、最適なシステムを構築できる」という価値観だと思う。
全体を見ないと「部分最適」になり、システム全体ではさまざまな問題が発生すると考える。全体を「一度」に設計しよう、という発想が強い。

XP や ICONIX などアジャイル系は「手探りで小さく始めて、足場を固めながら変更を繰り返すことが結局は最終ゴールへの近道」という価値感だと思う。
乱暴に言えば「部分最適」の積み重ねが「全体最適」につながる、という発想。

では、某証券取引所の「次世代システム」のような規模を XP や ICONIX で実現できるのか?

理論的にはできると思う。
実際には、できないと思う。 XP でやろうと提案する人がいないだろうし、いたとしても関係者で合意はできないでしょうから。

理屈としては、問題領域を分割して、それぞれの問題領域ごとに、 XP や ICONIX プロセスを実施することは可能。

問題領域の分割と、分割した領域間の連携は、Domain-Driven Design の 「戦略的な設計」の考え方を適用する、格好のテーマですね。

このほうが、早く、低予算で新サービスが提供できそうな気がするけど、それを関係者で合意するのは現実的にはムリでしょうね。

「部分最適化」が最も良いやり方とは思いません。
でも、最初から全体を見渡すことで、本当に「全体最適化」ができるんだろうか? 

問題領域の分割戦略は、ウォーターフォール系でも重要な課題。でも、分割して疎結合、という発想は弱いようにも見える。 企業システムは一体であるべき、みたいな先入観が強すぎる感じがする。

複数のアジャイルプロジェクトを並行して進めるのは、おそらく難しい。
方法がアジャイルであろうが、ウォータフォール系であろうが、ある規模以上の人数で、同じ価値観、手法、用語を共有するのは難しい。

バベルの塔で、神様を怒らせてしまったので、人間は、大勢で同じ言語・価値観を共有することはできなくなっちゃったんです。

ウォーターフォール系の方法論は、様式やルールを統一し、不整合の検出手順を徹底することで、なんとか、がんばろうという発想なんだと思います。

XP , ICONIX , SCRUM 、ドメイン駆動設計などは、顧客と開発がひざづめで話し合うことで、プロジェクトで共通の言語、価値観をもてるように頑張ろう、という発想。

要件定義の3点セット : 画面、機能、データ

XP は「要件定義」という言葉は使わないかな。

ユーザーストリー「ユーザは○○ができる」を出発点にして、画面スケッチや、簡単なクラス図を作ったりしながら、ユーザ(要求側)と開発者の間で「何を作るか」を確認していく。

ICONIXプロセスだと、画面の紙芝居や要求メモを出発点にして、用語集としてドメインモデル(概念クラス図)を作って、ユースケースパッケージ図に機能をまとめて、ユースケースでシステムの動き(振る舞い)を確認していく。

ウォーターフォール系の方法論だと、
・画面定義書(一覧、画面遷移、主要画面、...)
・業務用語集
・業務フロー図
・機能体系図
・概念データモデル
・主要データ一覧
などがでてくるかな?

どのやり方にも共通しているのが、
・画面の情報は必須である。
・機能の情報も必須である。
・情報(の構造)も必須である。
ということである。

画面

画面の模型で話をしよう、というのは、XP も ICONIX も ウォーターフォール系もいっしょですね。

機能

名前も書き方も違うけど、「ユーザが○○する」という動詞に注目した定義として、機能定義をしている。

XP だと、ユーザーストリー。 ICONIX だと、ユースケースパッケージ図に機能を並べる。 ウォーターフォール系だと、業務フローや機能階層図などで機能を並べる。

情報の一覧や構造

これも名前や記述方法は違うけど、共通している。

XP だと概念クラス図など、ICONIX だとドメインモデル、ウォーターフォール系だと概念データモデル、主要データ項目一覧、用語集などがこれに関連する。

まるで違う世界ではなく、役に立つソフトウェアを楽に作ろうという発想も共通していると思う。

もちろん、いろいろ価値観が違っている所もある。その違いは別の記事で考えてみたい。

要件定義 基本設計 実装

開発プロセスは、それぞれの作業内容は、名前も定義もばらばら。同じプロセスを使っていても、現場で実践する場合、さらにばらばら。そもそも、教科書どおりにできるわけがない。

アジャイルでも重厚な方法論でも、基本はいっしょだと思っている。役に立つソフトウェアを楽に作るために、要点がそんなずれるはずはない。

基本は三つだと思う。

要件定義 役にたつソフトウェアのイメージを関係者で共通理解にするための活動。 (ゴールの共有)

基本設計 ソフトウェアを楽に作るために、作り方を考え、共有する活動。(作り方の共有)

実装 実際に作って、使えるようにする活動。

この売上げデータの拠点別の総件数をとりあえず調べる、なんていう使い捨てソフトウェアを一人で書くなら、SQL文一行でおしまい。要件定義や基本設計は、頭の中。ほとんど無意識かな。

某証券取引所の新システムだと、要件定義書は、4000ページだそうです。50人で書いたらしい。動くまでがたいへんそうですね。

実践 ICONIXプロセス : 中途半端な開発プロセス?

ICONIXプロセスはマイナーな(有名ではない)開発手法ですね。
アメリカでも、それほど有名ではないと思う。(日本よりは知られている)

開発のやり方・方法論はいろいろあるけど、大きく2つの系統に分けることができる。

・アジャイル系のやり方
・ウォーターフォール系のやり方

ICONIXプロセスは、両方の良さを融合しようとしている、と私は感じている。

でも、こんな意見も...

ピュア(?)なアジャイル派から見ると ICONIXプロセスの「設計」や「レビュー」は鈍重な、アジャイルではない、やり方に見えるらしい。

大手SIerなどで、りっぱ(?)な開発手法を使っている人たちから見ると、簡略すぎて、ちゃんとした方法論ではないらしい。

(自分が信じる道以外は邪道、ていう人が時々いますね)

ICONIXプロセスは、次のような人たちには参考になるやり方だと思う。

・アジャイル系のやり方の価値観に共感する。
 でも実際にやろうとしてもうまくいかない。わからない。

・網羅的な方法論に疑問を感じている。でも、アジャイルなやり方は現実的に思えない。

ICONIXプロセスは、価値観は、まちがいなくアジャイル系です。(XPは嫌いみたいですけどね) 要件定義や基本設計の考え方は、ウォーターフォールに近い。

ウォーターフォール系のやり方を、思い切ってアジャイル的にやるのが、ICONIX プロセスなんだと思っています。 そして、それがとても実践的で現場で役に立つ。

実践 ICONIXプロセス : 要件定義から実装まで

 ICONIXプロセスは、開発プロセスを大きく三段階に分けている。

・Requirements Definition (要件定義)
・Analysis, Conceptual Design, and Technical Architecture
 (分析、概念設計、技術方式)
・Design and Coding (設計と実装)

開発プロセスという問題領域(ドメイン)の中核のキーワードがこの6つというモデルですね。「モデリング」とか「モデル」という言葉は入っていない。これは、ちょっと興味深い。

「モデル」は中核の概念でなく、もう一つ下のレベルで出てくる概念。

例えば「要件定義」を分解すると、

・ドメインモデリング     (問題領域の模型)
・ユースケースモデリング (使い方の模型)
・要求レビュー  

となって「モデリング」が登場する。しかも名詞の「モデル」ではなく、動詞で現在進行形の「モデリング」。

現在進行形は、味のある表現で「未完成」「終わっていない」という意味合いが強い。常にベータ版、てな感じです。

最近「モデル」という言葉に引っ張られすぎて、もっと上位の「要件定義」から「実装」という大きな流れをきちんと指導できていなかった気がする。反省。

実践 ICONIXプロセス 動的+静的の2層構造

ICONIX プロセスは この図 のように、上段の「動的」なモデリングの流れと、下段の「静的」なモデリングの流れがあり、上下を常に同期させることが成功のコツという考えです。

コードは、下段の静的モデルの流れの最終結果です。
概念クラス図(ドメインモデル)から出発し、属性などを追加して更新したドメインモデルを経過して、操作まで記述した実装クラス図を経て、実際のコードになる。

上段は、この下段の流れを「駆動」するためのモデリングです。
利用者から見るのは画面で、利用者がやることは、クリックやフォームの入力。ソフトウェアは、この利用者のアクションに応答して、画面を表示したりメールを送ったりする。

この上段のシステム利用の動的な側面(ソフトウェアの実行時の動作)と下段のソフトウェアの静的な(構造の)側面をモデリングの初期の段階から、いつも同期をとるので、良いソフトウェアの設計と実装が速く確実にできる、というのがICONIXプロセスの基本哲学ですね。

そのため、
・上段の画面の紙芝居から、下段の初期のドメインモデルを作成する。
・上段のユースケースモデリングでは、常にドメインモデルの用語を意識して使う。

この「ユースケース」と「ドメインモデル」の上下2層構造で、かつ、上下の同期を重視することが、ICONIXプロセスの特徴です。

ドメインモデル(クラス図)だけ睨みながらモデルを改良する、逆に、紙芝居やUIデザインだけでソフトウェアを開発する、どちらも偏りすぎている。ちょうどよいのは、ドメインモデルもやって、振る舞いモデルもやって、いつも両者を同期させること。しかもアジャイルに。

それが空論ではなく、実践としてガイドしているところがICONIXプロセス、「ユースケース駆動開発実践ガイド」を私が気に入っている理由です。

実践 ICONIXプロセス ドメインモデルからユースケースへ

ドメインモデルのこと、いろいろ書いてきたけど、ICONIXプロセスの次のステップ、ユースケースモデリングに進みます。

ICONIX プロセスでは、初期のドメインモデリングが、ユースケースモデリングの準備作業と位置づけています。用語集(初期のドメインモデル)を準備してから、ユースケースを書き始めよう、ということ。

また、ユースケースを書きながら、ドメインモデル(用語集)も随時、更新しながら、いつも、ドメインモデルとユースケースは同期をとるべき、としている。

モデルの動的な側面(ユースケースなど)と静的な側面(ドメインモデル)をいつも連携させることが、良いソフトウェアを、速く、確実に作る秘訣である、というのが、ICONIXプロセスの基本思想の一つですね。

「ユースケース駆動開発実践ガイド」を何度も読み返しながら、実際にやってみると、ほんとうに、このやり方が空論ではなく、実践的であることが実感できます。

今まで、なんどか、ユースケース関係の書籍を使って、要求分析などやってきましたが、正直いってどれもぴんとこなかった。
「ユースケースモデル」だけが浮いた感じになって、実際の開発の手順にはまり込まない。書くだけムダ、という評価だった。

ところが「ユースケース駆動開発実践ガイド」を読んで、ユースケースの評価がいっぺんしました。 ユースケースはとても実践的な設計手段だという手ごたえを始めて感じました。

ICONIXプロセスでは、ユースケース記述に徹底的に画面名やボタン名というUIの実装を取り入れます。一般的なアプローチではないと思いますが、実際にやってみると、ユースケースがとても書きやすくなり、また、早い段階で仕様のモレ・ヌケを発見できるようになりました。

また、準備として用語集(ドメインモデル)を用意して、しょっちゅう同期をとるやり方なので、ユースケースを書きながら、ドメインモデルが成長していく様子が実感できます。

また、ドメインモデルで良い発見や改良があると、ユースケースがすっと書きやすくなる、ということが実際に体験できた。

本を最初に読んだときは、正直に言って、「ドキュメント&レビューかあ?」ちょっとなあ、という否定的な印象でした。

ところが、ほんとうに実践的で、また実際にやってみて1ヶ月後くらいには、手ごたえがでてきた。

ポイントは、
・ユースケースは画面を意識して書くべし
・ユースケースとドメインモデルは徹底的に同期すべし
の2点だと思います。

Domain-Driven Design ドメイン駆動の設計

ドメイン(domain)の語源は、「支配している場所と」か「領地」という意味らしい。この線からこっち側はオレ様の領地、という感じですかね。
Domain-Driven Design(DDD)に、Bounded Context(コンテキスト境界)パターンがある。個々のドメイン(領地)の境界線をきちんとして、境界を越えて干渉しないようにすべし、という考え方ですね。これ、ドメインのもともとの意味を、再確認して強調しているだけなのね。

ソフトウェアは、何かを解決するために開発する。だから、ソフトウェア開発は、まず、その問題(の領域)を正しく理解することから始まる。そういう意味では、どんなソフトウェア開発も Domain-Driven Design なんだと思います。

まあ、問題領域の理解が浅かったり、関係者間で理解がばらばらだったりすると、悲惨な結果になるわけですが、ドメイン駆動というのは、ソフトウェア開発の基本ですよね。

ただ、実装つまりプログラムのコードレベルの話がからんでくると、Domain-Driven Design は実践的ではない、とか、メリットがわからない、という意見や感想がでてくる。
日本には向かない、なんていう議論もあるらしい。まあ、日本のIT業界の多くの開発の現場では、ドメイン駆動じゃないのが実態なんでしょうね。

問題領域の分析や理解よりも、いきなり作り始めるか、逆にとてもりっぱな仕様書作りに入るか。どちらの場合も、問題はそんなに複雑ではない、というのが前提になっているんだと思う。

実際、そんな複雑ではない問題の解決が期待されているのかもしれない。

私が最近関わっているのは、IT的にはまだまだ未開拓の領域だから、Domain-Driven Design にはまっているのかな?
転職、(国際)マーケットプレイス、機械翻訳、プロジェクトコミュニケーション ...
発注者側も、どんな情報やサービスが必要なのか模索しながらソフトウェア開発をやっている。問題領域についての議論の機会は多い。ごく自然に Domain-Driven Design になる。

ほんとうは、どんな分野も奥は深いし、新しい発見や新しいソリューションはいろいろあるはず。ソフトウェア開発するからには、ドメインの分析・理解が良いソフトウェアづくりの基本だと思う。
でも、受託開発型のビジネスや下請け開発では、言われたこと、決められた開発範囲を予算内でとっとと片付けていくしかないんでしょうね。
(それが誰も喜ばないソフトウェアになってしまっても、金はとりあえずかせげる)

マーチンファウラー「エンタープライズアプリケーションアーキテクチャパターン」(PoEA)のトランザクションスクリプトとか、Domain-Driven Design のSmart UI(利口なUI)アンチパターンとかも、メリットはあるし、むしろ、世の中の多くは、Domain Model パターンではないのでしょうね。

実装まで考えると、Domain-Driven にならない、ドメイン駆動は実践的でないという意見も多そう。実装してなんぼだし、プログラム設計を考えたら、Domain-Driven は実装が複雑になるだけ、という意見も聞いたことがある。

私は、でも、やっぱりドメイン駆動だよなあ、と漠然と思っていた。印象として、それが、問題解決の正しいアプローチに思えた。

それが過激(?)な、Domain-Driven Design 実践者になったのは、Spring フレームワーク 特に Spring MVC と Spring Web Flow と出会い、ICONIX プロセス、特に「ユースケース駆動開発実践ガイド」に出会ってからです。この2,3年の話です。

Spring フレームワークは、ドメイン層のオブジェクト(POJO)を組み合わせてビジネスアプリケーションを実装することが基本思想。IoC とか DI とかで説明されることが多いけど、私にとっては、ビジネスオブジェクトのコンテナとしてとても便利、アプリケーション開発がとても楽になることが気に入っている。
Web アプリケーションを開発する時に、Spring MVC + Spring Web Flow + Velocity テンプレートエンジンを使ってみて、ほんとうにビジネスオブジェクトの設計してPOJOで実装すれば、アプリケーションができてしまったのが新鮮な驚きだったし、これだ、という確信になった。

ICNOX プロセスの「ユースケース駆動開発実践ガイド」は、本の名前とは違って、徹底的にドメインモデル、問題領域の概念の把握を重視した開発手法です。
しかも、めちゃくちゃ実践的。この本で例として使っている実装アーキテクチャが私たちと同じ Spring フレームワークベースだったのも大きい。

もともと、分析・設計はきちんとやるべき、という考えだったので、この実践的なドメインモデリングを重視した開発手法は、すっかり気にいってしまったし、実際に使い始めてみて、若手の分析・設計能力の向上にすごい手ごたえを感じている。

実践 INONIXプロセス ユースケース駆動開発実践ガイド トレーニング

最近「ユースケース駆動開発実践ガイド」と Enterprise Architect を使ってトレーニング(ワークショップ)をやっているんだけど、これがとても面白い。

「ユースケース駆動開発実践ガイド」は「体験による学習」と「誤りから学ぶ」を重視している。著者たちの豊富なトレーニング提供の経験から、現場の技術者がやりがちな間違いや、理解の勘所が、随所に盛り込まれている。

この本を教材に、若手に実際にトライアルしてもらい、Q&Aをやってみると、いまさらながら、実に良く出来た教材だと関心するばかりです。
勘のいい受講者がひっかかる所は、だいたい、意図的にもぐりこませた誤り。そこが、勘どころの説明の良いネタになる。
質問がでた箇所に関係する説明が、本の前のほうや、後のほうに必ずでている。
そこを参照しながら、説明すると、質問者が納得する答えになることが多い。

あと、翻訳本なので、どうしても微妙なニュアンスとか、表現や用語の違いが、うまく書かれていない箇所がある。正直言って、単純な誤訳もある。
で、教え役の私としては、一所懸命に、原文を読んで、なんとか、答えを見つけようとする。こんなに英語の専門書をまじめになんども読み返すのは、たぶん、大学以来。
でも楽しいんですね。読めば読むほど、勉強になる。経験したことばかり、といえば、経験したことばかりなんだけど、若手にうまく伝えられなかったり、自分で意識していないかったテクニックや考え方がより具体的になって、とても説明しやすくなった。

また、ICONIX プロセスは、最初にざっとドメインモデルを作成し、分析から実装へのプロセスの中で、このドメインモデルを進化させていくやり方。
このプロセスの中で、 Eric Evans の Domain-Driven Design (ドメイン駆動設計 DDD ) にでてくるモデリングパターンの応用例がたくさんでてくる。
Aggregates ( 集約 ) パターンなんかは、DDD で読んだときは、概念的な理解だったけど、ICONIXプロセスを実践してみると、モデリングの重要な要素だということが実感できる。集約によって、問題領域がすっきり理解できるうように図が進化するのが実感できる。

トレーニングは離れたオフィス間でやっているので、基本は、メールでのQ&A。
書くのがたいへんだけど、質問する側も、答える側も、わかりやすく書こうとすること自体が、ドメインモデリングの最高のトレーニングになっている。

書くいて伝えるには、ぼやっとした言葉では伝わらないので、自然と、言葉の選び方、使い方が洗練されてくる。
これが、Domain-Driven Design の Conceptual Contours(概念の輪郭)パターン なのかな?

calendar
      1
2345678
9101112131415
16171819202122
23242526272829
3031     
<< July 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM