ICONIXプロセス実践指南

前書き

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

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

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

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

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

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

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

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

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

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

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

実践的な書き方

ユースケース図

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

ポイント

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

ロバストネス図

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

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

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

ポイント

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