不確実性の高い問題にICONIXプロセスで挑む

こんにちは！ソフトウェアエンジニアの関口です。

私たちHRBrainは、HR領域のプロダクトを展開するスタートアップです。そんな会社のエンジニアの評価指標ってどのようなものか気になりませんか?

結論から言うと、「不確実性が高い問題を解決すること」です。

では、不確実性が高い問題とは何でしょうか？これは色々な考え方がありますが、自分は以下のように解釈しています。

「実現すること」自体が曖昧であること
「実現する方法」も曖昧であること

このような不確実性の高いタスクは、非常に実現が難しいものですよね。要求がかっちりと決まっていて、その実現方法が既に明確になっている(例えば設計済み)物であれば、実現の難易度は下がる気がします。(もちろん実装的な難しさはありますが...)

この不確実性の高いタスクに対しての打ち手はシンプルに以下のようなものになると思います。

「実現すること自体」を明確にすること
「実現する方法」を明確にすること

上記のような打ち手を行うために、皆さんは明確なプロセスを持っていますか?

自分自身は、この記事で紹介する ICONIX プロセスを導入するまで、明確に決まったプロセスは正直持っていませんでした。これまでの経験や書籍で読んで学んだことを断片的につなぎ合わせて、要求定義~リリースまでのプロセスを行ってきました。正直に言うと、最初に仕様を決め、設計を行っていても実装を行った後で抜け漏れや手戻りが発生することもありました。

そんな時に同じチームのテックリードが、ユースケース駆動開発実践ガイドという本をチームに紹介してくれました。チームで話し合った結果、このユースケース駆動開発実践ガイドで記載されている ICONIX プロセスというものをチームの開発スタイルとして取り入れてみることになりました。

この ICONIX プロセスを導入したところ、「実現すること自体」を明確にし、更に「実現する方法」自体も明確にするための体系だった具体的なプロセスが記されており、「不確実性が高い問題」に対する非常に有効な打ち手になると感じました。

そこで、今回はこの ICONIX プロセスについて書いてみることにしました。

ただし、まだ導入しだしたばかりで、全てのプロセスを回し切ったわけではないので(設計が完了したところまでで執筆しています)、今回は以下の3つの話を書こうと思います。

そもそも ICONIX プロセスとはざっくりとどのようなものか
どのようにしてチームで ICONIX プロセスを導入したか
現時点で感じている ICONIX プロセスを実践に導入することのメリット、デメリット

何回かこのプロセスを回し切った後には再度記事を書こうと思います。

1. そもそも ICONIX プロセスとはざっくりとどのようなものか

ここで言う ICONIX プロセスは、ユースケース駆動開発実践ガイドの本で紹介されている物を指しています。

ユースケース駆動開発実践ガイドでは、ICONIX プロセスは以下のように紹介されています。

ユースケースとソースコードの間に存在する領域にフォーカスした、最小限かつ効率的なアプローチです。

引用: ダグ・ローゼンバーグ (著), マット・ステファン (著), 三河淳一 (翻訳), 佐藤竜一 (翻訳), 船木健児 (翻訳) 　(2007/10/16)『ユースケース駆動開発実践ガイド』翔泳社

これだけだと正直わからないと思うので、具体的に言うと

要求の整理~実装までの各々のプロセスで必要最低限のUMLを用いながら、要求と設計をイテレーティブに回していき、最終的に真に要求を満たす実装を行うためのプロセスだと自分は解釈しています。

今回は ICONIX 自体の説明がメインの記事ではないのでかなりざっくりな説明に留めます。ユースケース駆動開発実践ガイドの ICONIX プロセスの各々のプロセスについてざっくりまとめると以下のような物です。

要求定義

ドメインモデリング
- ドメインモデルを作成する
  - 単語間の関係を表現したプロジェクトの用語集
ユースケースモデリング
- ユースケース図を作成する
  - ユーザーのアクションとそれに対応するシステムの応答をシナリオ
要求レビュー
- ユースケースが要求と合致しているか確認する

分析/概念設計/テクニカルアーキテクチャ

ロバストネス分析
- ロバストネス図を作成する
  - ユースケースとオブジェクトを関連づける
  - ユースケースとオブジェクトの再発見、見直し
予備設計レビュー
- ロバストネス図、ドメインモデル、ユースケースが合致しているかどうかを確認する
テクニカルアーキテクチャ
- アーキテクチャの検討、決定

設計/コーディング

シーケンス図
- クラスの振る舞いを割り当てる
詳細設計レビュー
- ユースケースに対してシーケンス図が割り当てられているか確認
実装/単体テスト
コードレビュー

上記のまとめには書きませんでしたが、ICONIX ではイテラブルに要求と設計を見直していくので、各プロセスにはそれ以前のプロセスの UML 等の見直しが含まれています。

2. 導入方法

ここでは私が所属しているチームでの話をします。私が所属しているチームはバックエンド3人、フロントエンドが1人です。導入方法としては1. 輪読会の実施、2.実践、3. チームでのレビューです。

輪読会の実施

その内のバックエンド3人で週1回のユースケース駆動開発実践ガイドの輪読会を行いました。形式としては、以下です。

チームのメンバーが各章のまとめを作成し、発表
質疑応答、思っていること等を話し合う
- 同チームのテックリードが実際に案件で ICONIX プロセスを部分的に適用していたので、そのテックリードが実際にやってみた感想等も聞いていました

実践

実際の案件で、書籍に書いてあったことをまずはある程度忠実に実践してみました。

チームでのレビュー

上述したように ICONIX プロセスでは、コードレビュー以外にも各々のプロセスでレビューを挟みます。

各々の工程でチームでのレビューを実施したことによって以下のメリットを感じられました。

各々の工程での抜け漏れや手戻りを発生させないために非常に有効
レビューする側も ICONIX プロセスの自体のやり方を学べる
チームのメンバーが要求や設計の段階からレビューに参加するので、コードレビューの質も上がる
- 単に表面上のコードの書き方だけではなく、要求や仕様を満たしたコードになっているのかと言う観点でコードレビューができるようになる

3. 現時点で感じている ICONIX プロセスを実践に導入することのメリット、デメリット

これから見えてくることもあると思いますが、現時点で感じたメリット、デメリットを書きます。

メリット

要求~実装まで「不確実性の高い問題」に対処するための体系化された明確なプロセスが確立される
- チームで共通の体系化されたプロセスがあるので、いつ何をしなければならないかが明確になる
全体的なレベルアップにつながる
- 各々のプロセスを明確に決まった方法で進めていけるので、やるべきことの抜け漏れが少なくなる
- 要求から他の人のレビューに参加できるので、すごい人のやっていることを上流工程から明確な成果物ありで学ぶことができる
(チームでのレビューのセクションでも記述しましたが)コードレビューの際に、単に表面上のコードの書き方だけではなく、要求や仕様を満たしたコードになっているのかと言う観点でコードレビューができるようになる

デメリット

慣れるまで時間がかかる
- 慣れると手戻り等が減ると思うので、全体的な工数は減りそうですが、まだそこまで至っていないのでなんとも言えないところです
レビューの工数がかかる
- コードレビュー以外で各プロセスの間にレビューを挟むので
ドキュメントの管理コストがかかる
- ドキュメントは最低限とは言うものの、イテレーションを回す度に変更する必要があるので、管理工数はそこそこあります
  - 現実的にどこまでやるかは、工夫の余地がありそうです