前書き

ICONIXプロセスは、 ユースケース駆動開発（UCDD） と呼ばれる手法に基づいており、ダグ・ローゼンバーグによって開発されたソフトウェア開発のためのUMLモデリング手法です。

このプロセスでは、モデリングを通じて要件の定義・分析を行い、それを基に設計・実装に落とし込んでいきます。

ICONIXは、世界共通の UML（統一モデリング言語） を使用し、シンプルな図で表現することで、以下の利点を提供します。

情報の伝達が容易（チーム間やプロダクト間の合意形成に寄与）
簡単な編集が可能（設計、実装、テストのイテレーションを実現）

これにより、 アジャイル開発 との親和性が高いと考えられます。
日本での普及時期や、数々のアジャイル関連文献を鑑みると、アジャイル開発はUMLによる図示を前提として発案されたと感じます。

要件の定義や分析が不十分であると、設計や実装も不完全となり、バグが発生しやすく、読みづらいコード、いわゆる「 良くないコード 」が生まれます。

逆に、要件の定義や分析を十分に行うことで（ICONIXではこれを 堅牢（ロバスト）にする と表現しています）、質の高い設計や実装が実現され、バグの発生が少なく、読みやすいコード、すなわち「 良いコード 」が生まれます。

あるインタビューで、ダグ・ローゼンバーグ本人が「 十分な要件定義・分析を行うことで、設計・実装が容易になる（実装は単なる変換作業になる） 」と述べていることに、私自身も長年の実践を通じて同様の結論に至っています。

このアプローチにより、開発にかかる工数が減少し（ コストダウン ）、製品の品質が向上する（ クオリティアップ ）という成果が得られます。

さらに、ICONIXプロセスは「 不確実性の高い開発に挑む 」場面で、エンジニアを支える力を発揮します。
熟練エンジニアでなくても、分析とフィードバックを地道に繰り返すことで、一歩一歩確実に進める、まさに「魔法」のような手法だと考えます。

この「魔法」を実感できるよう、実践的な書き方を指南していきます。

実践的な書き方

ユースケース図

モノの名前（ ドメイン：概念 ）、システムで実現すること（ ユースケース：振る舞い ）を導き出す
- 前者が「 静的モデル 」、後者が「 動的モデル 」となる
ユースケース名は、「 A（名詞） を B（動詞） する」と言う形式で統一する
- 「 A（名詞） 」が「 ドメイン：概念 」、「 B（動詞） 」が「 ユースケース：振る舞い 」となる
ユースケース図では、「 利用者（アクター）の視点 」に立って考えて描いていく
- 技術専門用語をなるべく使わず、 利用者 および、そのビジネスの 専門家 にわかりやすい用語を用いる
システムを「 ブラックボックス 」として扱うことによって、アクターとシステムのやり取りを 外部から観測されるもの として描く
システムがどう動作するかではなく、「 システムは何をするのか 」に意識を集中させる
システムの内部を知らなくても、図を理解できる粒度で描く
- 粒度が細かくなりすぎる（ 実装寄り になる）と、理解が困難になる

ポイント

最初に「 ドメイン（概念） 」を導き出すため、「 ドメイン駆動設計（DDD） 」と アプローチ は同じである
- 「 ドメイン（概念） 」と「 ユースケース（振る舞い） 」のいずれに重きを置くか、程度の違いと認識している
- 両方に重きを置いても問題はなく、むしろ 両方を踏まえて 思考を進めた方が、 より良い アプトプットになる
日本では「 ドメイン駆動設計（DDD） 」が注目され始めたが、個人的な印象として、DDDの方が 難易度 が高く、とっつきにくい
- 「 ユースケース駆動開発（UCDD） 」の書籍が日本に出回った頃（2007年頃）は、 アジャイル開発 が日本で 浸透する前 だったこともあり、DDDほどの注目が集まらなかった経緯がある
- そもそも、 開発手法 や 開発方法論 と言った根幹的なものですらも、浸透していない状況だった
- 「 UCDD 」は「 DDD 」よりも とっつきやすい と感じているため、 若手エンジニア や、 エンジニア以外のプロダクトメンバー にとっても、価値のあるものになると見込んでいる

ロバストネス図

「 ロバストネス図 」は、ICONIXプロセスで定義された独自の図であり、UML標準の図には含まれていません。

ICONIXプロセスでは、この図を最も重要な要素と位置づけています。
ロバストネス図を用いることで、 基本設計 から 要求テスト までの幅広いプロセスを、 必要最低限 のステップで実践的に進めることが可能になります。

基本として、ユースケース図で抽出した「 ユースケース 」を「 コントローラー 」とする
- ユースケース と同じ名前の コントローラー を図に出現させる
  - ユースケースと同名のコントローラーを出現させることで、 ユースケース図との繋がり を明確に伝える
要件定義 と設計を紐付けるための「 中間的な成果物 」と言う意識を持って作成する
- ICONIXプロセスでは、ロバストネス図を書く工程を「 予備設計 」と呼称し、「 要件を分析するプロセス 」と位置付けている
図の 粒度（解像度） が 実装に寄りすぎない ように注意する
- 細かく書きすぎると、図の要素が増えて煩雑になり、見づらくなってしまうため、図の意味が失われる
- 結合テスト項目を洗い出せる程度 の粒度を意識する
  - 結合テスト項目と紐づく ことによって、 要件定義と実装が乖離していない かを容易に判断できるようになる
ある程度書いた時点で、 次の工程 に進める
- 「 今の段階だと、これ以上書けないな 」と思ったら、次の工程に移る
- 次の工程で明確にすべき要素が出てくるため、進んで明確にしていく
  - 明確になった後、 前工程にフィードバック していく
  - 成果物が最新の状態に保たれる（ 価値がある成果物 となる）
  - このプロセスを繰り返すことこそが、まさに「 アジャイル 」である

ポイント

熟練エンジニア が脳内で行っている 思考プロセス を、図にすることで「 見える化（抽象化） 」を実現する
- 熟練エンジニアでなくても、不確実性が高く、難易度の高い要件に挑む ことができるようになる
ロバストネス図は、 アジャイル の本質である「 繰り返して品質を高めていく 」ことを実現する
「 要件定義〜テスト 」が シームレスに繋がる ため、 リバースエンジニアリング が容易になる
- 既存の画面を元に、 ロバストネス図 を作成する
- 既存の ソースコード を元に、 ロバストネス図 を作成する
- 作成した ロバストネス図 を元に、 ユースケース図 や 結合テスト項目 を作成する
- つまり、いつでも 最新の成果物 を、 要件定義に遡って 作成することができる