実践 ICONIXプロセス : 最も重要なマイルストーン

予備設計レビューの完了は、ICONIXプロセスにおいて、最も重要なマイルストーンだと思います。

この段階までくると、要求モデルは、実装を開始するために必要な、安定した、強靭な内容にまで洗練されています。開発は、顧客の要求が理解できたと感じ、実装方法は頭の中にかなり具体的にイメージできています。

実際にICONIXプロセスをやってみて、予備設計の内容(ロバストネス分析)がしっかりしていれば、その後の作業は、定型作業に近い感じです。これ以降の実装作業の見積もりと実績の差がほとんどなくなります。

もちろんいろいろ失敗しながら、ようやくそういうレベルになってきた、ということです

最初はうまくいかなかったこと。

実装してからのやり直し

ロバストネス分析をしたはずなのに、要求の理解がロバスト(強靭)ではなく、とても脆弱、という失敗をなんども繰り返しました。 結局、要求分析は時間の無駄なんではないか、という雰囲気がでてくるくらい。

でも、やりかたを反省してみると、手抜きが多いことが発覚。

・画面の模型なしに、ユースケースを書く(特に代替コース)
・ロバストネス図のチェックが甘い(コントロール必須のルールの違反、ドメインモデルと不一致)
・関係者で話をしない。(レビューも手抜きだけど、そもそも、チーム内での会話不足)

画面の紙芝居、ドメインモデル、ユースケースパッケージ図、ユースケース記述、要求レビュー、ロバストネス分析、予備設計レビュー。 それぞれの作業の基本事項を見直すことで、状況は確実に改善しました。

特に重要な変化は、チーム内で、ちょっとした確認作業のおしゃべりが明らかに増えたこと。
しゃべる内容は「業務の用語」つまりドメインオブジェクトの名前を使うことが増えたこと。

ICONIXプロセスは、最初にドメインモデル(業務の用語集)を作って、徹底的にそれを利用し、また洗練させ、詳細化していきます。その結果がそのまま実装クラスになる、というやりかた。

ですから、ICONIXプロセスのやりかたを丁寧にやれば、自然に、あちこちで「業務の用語」を使うようになります。実装クラスの話をしていても、クラスの名前は、業務の用語なんですから。

DDD (ドメイン駆動設計)のユビキタス言語の実践ですね。ドメイン(問題領域)の用語が、チーム内のだれでも、開発工程のどこでも、レイヤアーキテクチャのどこでも、あちこちに登場する。

実装に時間がかかる

単純に言えば、アーキテクチャ(技術方式)が脆弱だったり、アーキテクチャを理解できていないメンバーの学習などで、最初のうちは、かなり実装に時間がかかりました。

アーキテクチャが安定し、フレームワークの使い方のノウハウがチームに浸透してくると、実装時間は大幅に短縮できました。

原因ははっきりしていて、サンプルをコピーして(意味も分からずに)使っているため応用がきかない。ちょっと問題にぶつかると自力で解決できない。

この問題とどうやって戦っているかは、別のカテゴリー(アーキテクチャ)で書きたいと思います。

---

予備設計レビュー完了はほんとうに大きなマイルストンです。
要求も具体的に理解できたし、実装イメージも具体的。チーム全員がようやくここまでたどりついた、そういう手ごたえを持てる場所です。

そう実感できるかどうかで、ICONIXプロセスを自分たちが理解し活用できているかどうかの判断材料になりそうです。ロバストネス分析の目的や効果を実感できれば、ICONIXプロセスを活用できます。

実践 ICONIXプロセス : 予備設計レビュー Tips

レビューの成果は改良ポイントの発見です。
予備設計レビューは、ロバストネス図を改良する作業です。

レビューで改良ポイントが一つも発見できなかったら悪い兆候です。
レビューが形式的な作業になっていて、中身の検討がおろそかになっているのでは?

ロバストネス図の目的を良く理解し、効果的なレビューをやりましょう。

ロバストネス図の二面性

ロバストネス図の作成は、要件定義の最終ステップです。そして、実装設計の最初のステップです。ロバストネス図のこの二面性を意識しましょう。

ロバストネス図は、画面(バウンダリ)だけでなく、ロジック(コントローラ)と実体(エンティティ)も描きます。つまり、システムの内部に踏み込んでいます。

しかし、コントローラとエンティティは、必ず業務の用語、問題領域の用語で記述します。ですから、顧客はロバストネス図を業務の観点で理解し、問題点をチェックできます。

一方、ロバストネス図は、実装構造を意識したルールの制約があります。特に、バウンダリやエンティティ間の通信には、必ずコントローラ(ロジックの入れ物)を介在させます。 この制約によって、技術者は、実装の視点からロバストネス図の正確さをチェックできます。

一歩だけ踏み込む

ロバストネス図が、画面の遷移だけでなく、ロジック(特にビジネスルール)とエンティティ(ビジネスオブジェクト)を描いていることを確認する。ロジックやエンティティが希薄なロバストネス図では、要求と実装の架け橋になりません。

しかし、ロジックもエンティティも、要求レベルの概念です。それ以上踏み込んで、実装の詳細に触れてはいけません。 

・クラスのメソッドの議論をしてはいけません。(それは、次のステップのシーケンス図でやる)
・DBアクセスや画面の実装の技術に触れてはいけません。(これも次のステップ)

構造は強靭(ロバスト)に

バウダンリとエンティティの間に必ずコントローラが介在する構造を守ってください。
画面間の遷移と画面と情報の流れだけのロバストネス図は、脆弱すぎます。

コントローラが介在すると、ロバストネス図をソフトウェアの設計図としてチェックできます。

顧客と技術でいっしょにレビューする

顧客に分かる概念だけで記述されていることをチェックするために、顧客にレビューに参加してもらう。
顧客にとってロバストネス図が理解不能で、レビューが退屈に感じるなら、そのロバストネス図は大幅に描き直すべきです。

ロバストネス図は、ユースケースを絵にしただけです。顧客にはユースケース記述より分かりやすくなっているはずです。

もちろん技術者も参加します。
ロバストネス図を見て、ソフトウェアの実装がイメージできなければ、そのロバストネス図は、欠陥があります。
・コントローラ介在のルールを守っていない?
・処理の順番が曖昧?
・情報の流れが曖昧?

一歩だけ踏み込む(もう一度)

ロバストネス図で、ありがちな失敗パターンは二つです。

・画面中心で、実装に一歩踏み込んでいない (コントローラ、エンティティが貧弱)
・実装に踏み込み過ぎている (技術用語が出てくる。例えばフレームワークのクラス名。)

予備設計レビュー(ロバストネス図のレビュー)で大切なのは、一歩だけ踏み込んでいることをチェックすること。

ロバストネス図は、要求と実装の架け橋です。
ちゃんと、橋がつながっていて、かつ、今は橋の中間にいることを確認しましょう。

実践 ICONIXプロセス : 代替コースを洗い出す

予備設計レビューでは、

・代替コースをすべて洗い出していること
・代替コース時の動作を具体的に描いていること

の2点を必ずチェックする。

代替コースの不備の恐怖

予備設計レビューで、代替コースを見落とすと...

・テスト段階で追加のチェックコードやエラー時の画面遷移の追加開発が発生する。
・最悪の場合、リリース後に障害が発生し、対応に大わらわになる。

また、代替コースを見つけていても、定義内容が曖昧だと...

・コーディングが始まってから、不足していたエラー画面を作成する。
・画面遷移のみなおし。
・他の代替コースとの競合や重複。

が発生する。追加の開発作業がだいぶ増えそうですね。

代替コースを通る回数は少ない(はず)。でも、サービスを安定して提供するには、代替コースを丁寧に洗い出して、丁寧に実装して、丁寧にテストする必要がある。

「丁寧」というと聞こえは良いですが、ようするに、開発がたいへんということ。

どうせたいへんなら、どのくらいたいへんか、最初からすべて見つけて、心の準備をしておきましょう。

不思議なもので、最初からすべて見つけて、具体的に定義できていると、結構、簡単に済みます。
コードを書き始めてから、発見すると、同じ内容でも、とても大変になる。たぶん、コードを書くときの関心事は別のところにあるので、頭の切り替えがたいへんになるからだと思う。

代替コースのモレの発見

ロバストネスは、代替コースの不備の発見でも、役に立つ手段です。

やりかたは、

1.基本コースを蛍光ペンで追いかける。
2.処理ステップ(コントローラ)ごとに、代替コースが漏れていないか、もう一度確認する。
3.代替コースモレチェックOKなら、次のステップに進む。

アプリケーション開発(と障害対応)の経験豊かなメンバーが中心になってレビューする。
ロバストネス図は、そういうシニアのメンバーの経験を、ジュニアのメンバーに伝える良いコミュニケーション手段です。

私が、実際に、若手に ICONIXプロセスのトレーニングをしていて実感したのがこれ。
今まで、うまく伝えられなかった経験やノウハウを、具体的に説明できるようなった。
若手の技術者がおかしがちな、代替コースのモレを、コードやテスト段階ではなく、予備設計の段階で発見・指導できるのは、かなりの作業量削減になります。

代替コースの曖昧さの発見

基本コースとは、別の色の蛍光ペンで、代替コースのステップを順番に追いかける。

重要なのが、
・ユーザにエラーを表示する画面
・エラーを表示した後の操作の流れ
をチェックすること。

エラーを表示しても、行き先が決まっていないことがかなりあります。
エラーメッセージが決まっていない。(補足仕様として、画面の模型や、メッセージ定義がない)
エラー画面に遷移して、また元の画面に戻るのか、元の画面にエラー画面を表示するのか?

代替コースの発見と定義を楽にやる

ここらへんは、個別の検討事項ではなく、プロジェクトで約束事を決め、パターン化すると、設計が楽になるし、見落としや曖昧さが減って、品質も向上しますね。

もっとも、約束事は簡単には浸透しないし、勘違いとかも多いので、ロバストネス図による代替コースチェックが、なくなることはありませんが。

実践 ICONIXプロセス : 画面とエンティティのマッピング

予備設計レビューの作業(続き)

すべての属性を見つけ出す。
画面の項目と、エンティティの属性の対応を一つずつチェックしていく。

準備

・蛍光ペン
・ロバストネス図
・それぞれのバウンダリに対応する画面の模型
・ドメインクラス図

作業

・最初のバウンダリの画面の模型を取り出す。
・その画面で使うドメインクラスを特定する。
・画面項目に対応するエンティティの属性を蛍光ペンでマークする。
・すべてのバンダリに繰り返す。

見逃していた属性を発見したらクラス図に追加する。
名前の不一致が見つかったら、訂正する。

さあ、これで、すべての属性を発見した。コーディングを始めてから、属性名を考える作業は一切なくなる(はず)。

実践 ICONIXプロセス : 蛍光ペンテスト(間違い探しゲーム)

予備設計レビューの基本コース。

準備

・蛍光ペンを用意する
・ロバストネス図(ユースケース記述をノートで貼り付けてある)のプリント。
・ドメインクラス図のプリント

作業

・ユースケース記述とロバストネス図を見比べながら、対応する箇所を蛍光ペンでマーク
・ロバストネス図とドメインクラス図を見比べながら、対応する箇所を蛍光ペンでマーク
・不整合がなければ、終了。

代替コース。

ユースケース記述とロバストネス図が一致しない

一致するようにユースケース記述またはロバストネス図を修正する。

ロバストネス図にあるが、ドメインクラスに無いクラスを発見

ドメインクラス図にクラスを追加し、ステレオタイプをエンティティに指定し、ロバストネス図にドラッグ。

---

単純な作業ですけど、効果抜群です。
名前のちょっとした違いも含めて、間違い探しゲームをやってみましょう。

この間違い探しゲームで、要求モデル(ユースケースとドメインモデル)と設計が驚くほど強靭(ロバスト)になります。

この作業の手を抜くと、実装中やテスト時に、やり直しがいろいろ発生し、工程が乱れます。転ばぬ先の杖。

実践 ICONIXプロセス : 予備設計レビュー

予備設計レビューは、ロバストネス図、ドメインモデル、ユースケース記述の三つのつじつまが全てあっていることを確認する作業。

レビューの参加者は、顧客、開発チーム、プロジェクトの責任者。これは、要求レビューと同じメンバーです。つまり、予備設計レビューは、要求のさらなる確認作業ですね。

また予備設計レビューは、エンティティクラスの属性をすべて洗い出し、画面とエンティティの間のデータの流れを追跡する作業です。

ウォータフォール型の方法論で言えば外部設計レビューですね。顧客から見える部分の詳細までレビューし、確認する作業です。

予備設計レビューの完了後は、今度は、アーキテクチャに依存した実装内容など、内部の設計を行います。
ここから先は、顧客との距離はちょっと離れて、技術的な作業が多くなります。

だからこそ、要求定義、要求レビュー、ロバストネス分析、そしてこの予備設計レビューで、徹底的に、顧客と開発とで要求内容を共通理解にするわけです。

calendar
     12
3456789
10111213141516
17181920212223
24252627282930
31      
<< March 2024 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM