初めまして、モンスター・ラボのMr.ポポです。
デザインテクノロジストとしてスタートしましたが
最近はWebサービスの開発・保守などほとんど
テクノロジストとしての内容が中心です。
現在携わっているプロジェクトでテストケースを作成しています。
テストケースの作成にこれまで自分がやったことのない方法を取っており、
また本案件では要件開発フェーズから従事しているのですが、
現在の作業のことまで通して見えていたらもっと効率化できたのになと
思うことがあったので共有したいと思います。
実はテストケースの作成に限らず、プロジェクト全体の
知識の共有にZeetaというツールを使用しています。
このZeetaについてのもっと奥深い話はZeetaの作者である
Zeeta博士が今後のエントリーで触れてくれるかもしれませんので
割愛しますが、共有したいことを説明するのに最低限のことだけ記述します。
Zeetaは階層構造で情報を管理するツールで、一つ一つの情報の要素を
「ノード」と呼ぶのですが、このノードが複数の親を持ててなおかつ
「逆ツリー」といってノードの親のツリー構造を辿って参照することができます。
また、ツリーの内容をテキストで検索することができます。
こう書くとシンプルなのですがこの構造が「つかそもそも何でこんな機能
実装するんだっけ？」とか「確かあの時そんな話をお客さんとした気がした」
といった事の事実関係を辿る必要があるような場合に相当威力を発揮します。
CMMI(v1.2)の「要件管理」プロセスの中に下記のようなSPがあります。
-----------
SP 1.3 要件変更を管理する（以下一部抜粋）
プロジェクト実行中、要件はさまざまな理由で変更される。ニーズの変化および
作業の進行に伴い、追加の要件が導出され、既存の要件に対して変更を行
うことが必要になる場合がある。このような追加および変更を、効率的かつ効
果的に管理することが必須となる。変更の影響を効果的に分析するには、各
要件の出所が把握されており、すべての変更の論理的根拠が文書化されてい
る必要がある。
典型的な作業成果物
1. 要件の状況
2. 要件データベース
3. 要件決定データベース
SP 1.4 要件の双方向の追跡可能性を維持する（以下一部抜粋）
要件がうまく管理されていれば、原要件から下位レベルの要件、
および下位レベルの要件から原要件への追跡可能性を確立できる。
このような双方向の追跡可能性は、すべての原要件が完全に取り上げら
れているかどうか、およびすべての下位レベルの要件を有効な出所まで追跡で
きるかどうかを判断するのに役立つ。
典型的な作業成果物
1. 要件の追跡可能性マトリクス
2. 要件追跡システム
-----------
要件がコロコロ変わるのでプロジェクトのスケジュールがどんどん圧迫される
というのは良く聞く話なのですが、元の要件をきちんと管理していれば
変更を変更として顧客と交渉する余地が生まれるはずです。
実際この要件の管理には変更の頻度や全体のスピード感を考えると
どえらい手間がかかるので腰が及びがちなのですが
プロジェクトの死線とも言える大事な管理項目ですよね。
このCMMIで書かれていることもわかっちゃいるけどじゃあどうやって実現
すりゃいいの？という気になります。字面だけ見ると「要件データベース」やら
「要件追跡システム」やらそりゃ必要でしょうよと思うのだけれど
このプロセスをどのように実装すればというのが大きなクエスチョンです。
その点で前述のZeetaを使った要件の管理は制約が多くスピード感が
求められることが当たり前のWebサービス開発プロジェクトの中で、
最小限の管理コストでやりくりすることができる可能性のある
優れたツールだなと使っていて感じています。
冒頭に触れたもっと現在の作業が通して見れていたらなと思ったのは
要件開発の際にノードを作成する際に最初からテストケースで使用する
言葉としてかけていたらそのノードをテストケースとして共有して
使用可能なものがたくさんあったなという実感です。
さらにもっと言えば、画面設計がだいたい終わって機能がおおよそ
確定できたところでそれを詳細化するという作業を要件を詳細していく
という作業ではなくテストケースを作成するという作業で行ってしまえば
良かったなと今では思っています。
テストケースは色々なケースを想定して具体的にここを押すとどうなるの
ということを詳細に決めていないと書けないため、要件の落としが
不完全であったことが後からわかって要件を追記するようなことがまま
あるし、色々なテストパターンに対して並列的に考えることが多いため
抜けていた要件が見つかるということが多いのです。
もちろんなぜそのテストパターンになるか、というのは要件から
派生するのがふつうなのですが、要件があいまいなことも多いので
固めたことを提案して承認を取るという進め方が主なプロジェクトでは
特に有効な手段だと思います。
また、テストケースと要件の結びつきがより強固になるので
要件の妥当性確認もより確実になるのも嬉しいですね。
実際使い込まないと伝わりづらいかもしれないので興味を持った方は
Zeetaに触れてみるのも良いかと思います。
http://sites.google.com/site/zeetahp/