ICONIXプロセス実践指南

# 前書き

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

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

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

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

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

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

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

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

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

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

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

# 実践的な書き方

## ユースケース図

![ユースケース図（サンプル）.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/91620/4f745c27-f42f-570a-3117-ff03c88ada76.png)

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

### ポイント

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

## ロバストネス図

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

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

![ロバストネス分析_説明用.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/91620/5a3a7bde-0ff8-cb6a-3fa3-a3014d89edc2.png)

![【仮想ECシステム】ロバストネス図（01.会員登録）.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/91620/b39e34ce-5542-abc6-4777-f1ce46e58c41.png)

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

### ポイント

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