前書き
本記事では、ICONIXプロセスの理念を踏まえ、改良を加えながら実践している内容を記述します。
メンバー層とマネージャー層、それぞれの視点におけて実践したこと、および、今も引き続き実践している内容になります。
基本の考え
以下を基本の考えとして、実践しています。
◇ ユースケース図を作成する
- 要件を図で見える化し、システム境界を明確にする
◇ 詳細設計の成果物は作成しない（シーケンス図、クラス図など）
- 作成しても良いが、残す成果物とはしない
◇ 画面遷移図を作成する
- UMLの状態遷移図で表現する
◇ ロバストネス図を作成する
- ロバストネス図でユースケースと実装を紐付ける
- ロバストネス図を見れば、おおよその要件、および実装がわかる
- 結合テスト項目を抽出できる粒度で書く
- ロバストネス図を設計図としてコーディングする
◇ しっかり設計を行えば、実装は容易に完了する
- 品質が良いコードが書ける
- 長期的に見て、大幅なコスト削減になる
- 品質が良いので不具合が発生しにくい
- 不具合や変更が発生しても対応が容易になる
- 新規メンバーが参入した時のコストが少なく済む
メンバー層で実践したこと
時期的なこともあり、メンバーとして参画したプロジェクトは、どちらかと言えばウォーターフォール的な進め方が主でした。
取り入れたことによって、過分な時間を要してしまうことは許容されません。
そのような環境下でも充分な成果を出す ことを目標に掲げ、改良を加えていきました。
タスクの中で 要件分析、予備設計、実装・テストを繰り返し 、完成させていきました。
◇ アジャイルを取り入れていない現場でも導入する
- ウォーターフォール開発であっても取り入れられる
- 個人レベルで導入が可能
◇ 自身のタスクの中でイテレーションする
- 要件分析←→予備設計←→実装・テスト
◇ ユースケース図を作成し、おおよその予備設計（ロバストネス図）ができた時点で実装を開始する
- しっかりと要件を分析することで、実装は容易になる
◇ 実装を進めて出てきた点を、ロバストネス図、ユースケース図にフィードバックする
- フィードバックを細かく繰り返すことで、システム化の実現性 および、 要件の確実性を高めていく
◇ ロバストネス図をインプットとして、結合テスト項目を抽出・検証する
- 要件と実装が乖離していないことを確認する
マネージャー層で実践したこと
メンバーの時にやっていたことをチームのメンバーにやってもらうため、まず 全機能のざっくりとした図を作成 して展開しました。
実装をフィードバックさせるロバストネス図の更新はメンバーに依頼し、それ以外の図へのフィードバックは、プロジェクトマネージャーである私が行いました。
ロバストネス図 を起点として、 上流工程と下流工程の成果物を検証 していき、 実装フェーズで検出した課題を素早く解決 させていきました。
図によって実装を見える化 していることで、 要件の確認 も簡単に行うことができました。
◇ 要件定義からユースケース図を作成する
- 要件を把握している人物（プロジェクトマネージャー等）が作成した
◇ 画面遷移図、ワイヤーフレームを作成する
- サンプリング対象のアプリを参考にした
◇ ざっくりとしたロバストネス図を作成する
- 書き方の粒度を合わせる意図も含む
◇ ユースケース図、ロバストネス図で顧客と合意を取る
- 図の見方を伝えることで、円滑に認識をあわせることができた
◇ 実装しながらロバストネス図を更新していく旨をメンバーに依頼する
- ロバストネス図の更新はメンバーに任せる
◇ ロバストネス図をインプットとして、結合テスト項目を抽出・検証する旨をメンバーに依頼する
- 要件と実装が乖離していないことを担当者が確認できる
実践によって生じた成果
実践によって、以下の成果を実感しました。
いずれも、 ソフトウェア開発を成功させるために必要不可欠なこと だと思います。
◇ 要件把握
- 図を書いて見える化する ことにより、 要件を正しく把握できているかを分析する ことができた
- 書いた図を元に顧客と話しをする ことで、 容易に顧客と認識を合わせる ができた
◇ 品質向上
- 必要な設計を行った上でコードを書く ため、 システムの品質が向上 した
- 要件からテストまでが乖離せず一貫している ため、 要件から外れた実装になることを防ぐ ことができた
◇ 情報共有
- コーディング知識を持っていなくても図で内容を理解できる ため、 容易に情報を共有する ことができた
あとがき
ICONIXプロセスは、 ウォーターフォール開発のようにかっちりと工程を進めることに違和感を感じている が、かと言って、 アジャイル開発のようにスプリントで区切って進めてもなかなか上手くいかない 、と言うケースに向いている手法だと考えます。
例えば、新規サービスを一から作り上げていく、 不確実性の大きいプロジェクト など。
個人的主観としては、 ウォーターフォール開発とアジャイル開発のハイブリッド であり、 いいとこ取り をする印象です。
特に理念については、「 これが正解だと自信を持って言える 」と思っています。
実践にあるように、個人レベルでの導入も可能です。
ぜひ一度、取り入れてみてはいかがでしょうか。