ICONIXプロセス実践指南

前書き

ICONIXプロセスは、「 ユースケース駆動開発（UCDD） 」と呼ばれる開発手法である。

「 Doug Rosenberg（ダグ・ローゼンバーグ） 」によって開発された、ソフトウェア開発のためのUMLモデリング手法である。

すなわち、 モデリング によって要件の 定義・分析 を行い、それを元に 設計・実装 に落とし込んでいく。

世界共通（ 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. ある程度書いた時点で、 次の工程 に進める
   • 「 今の段階だと、これ以上書けないな 」と思ったら、次の工程に進む
   • 次の工程に進まないと明確にならない要素が出てくるので、次の工程に進んで明確にしていく
     • 明確になった後、 前工程にフィードバック していく
     • 成果物が最新の状態に保たれる（ 価値がある成果物 となる）
     • この作業を繰り返すこと、これがまさに「 アジャイル 」である

ポイント

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