ユースケース

本節では，問題事例集より過去に発生した事例を挙げ，次にIZMIでどのように その問題を推測するのかについて述べる．過去事例の事例番号は，事例集[28]に掲 載されている事例番号と対応する．推測の手順としては，IZMIにて観測できる特 徴的なセルの並びを挙げ，要求仕様・設計段階でIZMIにより観測されうる事象を

図19 編集期間が空いてから再度編集が行われていないか

図20 何日にもわたり編集されているファイルがないか

述べる．次に，それぞれの事象が観察されたときにどのような問題が発生している と思われるかもあわせて考察する．これらの流れを1つのユースケースとして定義 し，以降IZMIを用いることで推測が可能な6個のユースケースを記述する．

1. 編集期間が空いてから再度編集が行われていないか 過去事例

• ユーザ側にて要件定義を実施して，その要件定義の結果を受けてベンダ 側で開発することになっていた．しかし，要件が小出しにされ，また提 示された要件の変更も多発し，基本設計の手戻りが多発した．(事例番 号5，36)

• スケジュールの遅れを取り戻すために，基本設計の承認を得ないままに 詳細設計に着手した．途中，変更を要請されたために設計をやり直すと いう二度手間になってしまった．(事例番号8，9)

この推測は成果物表示モードでイベントビューを横に見ていくことで確認で きる．図19のドキュメントは，はじめ何日か編集が行われていたが，その 後しばらく編集が行われていない期間が存在している．これは空白のセルが 連続して並んでいることから容易に確認することができる．その後編集が再 開されていることから，一旦そのドキュメントを変更する必要はなくなった が，再度編集する必要が出てきたのではないかと推測する．つまり，「開発 が下流工程に移行し開発が完了したはずの要件が変更された」のだと推測す ることができる．

図21 期間中に大量の新規作成・削除が行われていないか 2. 何日にもわたり編集されているファイルがないか

過去事例

• 基本設計での仕様確定に時間がかかり，他に影響する可能性がある機能 の詳細設計が遅れた．(事例番号19)

• 顧客側メンバの体制が弱く，仕様決定のための十分な時間を確保するこ とができなかったため，仕様の確定が遅れた．(事例番号20)

この推測も，同様に成果物表示モード時にイベントビューを横に見ていくこ とで確認することができる．図20のドキュメントは何日にもわたり繰り返 し編集がなされ，一日あたりの編集回数も非常に多いことが確認できる．以 上より，「顧客側の要件が確定していない機能がある」と推測することがで きる．顧客側の要件が確定しているのであればベンダはその要件に従って開 発するだけなので何度も編集を繰り返す必要はほとんど無い．開発が難しい 機能であったとしても，その他の機能と比較して極端に開発期間が延びると いうことは多くはない．そのため，開発を難しくさせている原因が要件が確 定していないことに起因するものである可能性があると推測できる．

3. 期間中に大量の新規作成・削除が行われていないか 過去事例

• 開発を受注したものの顧客側より不条理な予算圧縮要請を受け，大幅な 仕様変更をせざるをえなくなった．(事例番号21，24)

• 顧客側の開発体制が弱く，要件定義を詳細に詰めることができなかった．

そのため要件が小出しに追加され，開発規模がどんどんふくれあがって しまった．(事例番号36，49)

図22 上流工程のドキュメントが下流工程の開発者に改訂されていないか これは成果物表示モードでイベントビューを縦に見ることで確認することが できる．図21を見ると，ドキュメントが存在している区間は色の帯で表現 されるため，色の帯の開始地点を見ることでドキュメントが新規作成された ことを，終了地点からドキュメントが削除されたことをそれぞれ確認するこ とができる．プロジェクトの開始時点でドキュメントが大量に作成されるの は正常な状態といえる．しかし，プロジェクトがある程度進行した段階で，

大量の新規作成や削除が行われていた場合，プロジェクトの正常な進捗を妨 げる何かが発生したと考えられる．新規作成は要件を満たすための成果物を 作成する際に発生し，削除はプロジェクトに不要な要件に関連する成果物を 取り除く際に発生する．このことから「プロジェクト進行中に要件の大幅な 変更や規模縮小が起こった」のではないかと推測することができる．

4. 上流工程のドキュメントが下流工程の開発者に改訂されていないか 過去事例

• 既存システムに対する追加機能の開発において，契約範囲外であった既 存システムに修正を加えた．ところが，その修正に起因した不具合が多 発して手戻りによる工数増と工期の遅れが生じた．(事例番号22)

この事象は開発者表示モードで確認することで読み取れる．図22を見ると，

赤色のセルはドキュメントのみを編集している状態を表しているため，上か ら4番目の開発者は上流工程のドキュメントを主に開発している事がわか る．灰色のセルは下流工程のソースコードなど，ドキュメント以外の成果物 を編集している状態を表すため，2番目と3番目の開発者は上流工程の開発 に関わっていない．しかし，この開発者に青色のセルが存在していることか ら，下流工程の開発を担当しているにもかかわらず，上流工程のドキュメン

図23 モジュール開発の中心人物は誰か

トを編集していることがわかる．下流工程の開発者が上流工程の編集を行っ ている状態は，開発プロジェクトにおいて正常な状態であるとはいえず，上 流の開発者の許可を得ずに修正を加えているのではないかと推測することが できる．このような時には，編集の内容が他の開発者に周知されず，潜在的 なバグとして以降の開発で大きな問題の引き金になる可能性がある．

5. 開発の中心人物は誰か 過去事例

• 大規模プロジェクトを受注したが，プロジェクトマネージャに大規模開 発の経験が無い人を選定した．計画通りに順調に進んでいるように見え ていたが，テスト工程段階から調整不足が露呈してテストが停滞した．

(事例番号29)

• 大規模なシステム開発を分割して，数社で独自に開発を行った．個別に 開発してできあがったシステムを結合したところ，システム全体で整合 性がとれていない状態だった．(事例番号46)

大規模ソフトウェア開発プロジェクトでは，複数の開発者が1つのモジュー ルの開発に携わることが考えられる．開発を進める過程でバグが発見された 際に，バグの報告を誰に行えば良いかという問題が起こる．開発者表示モー ドでイベントビューを確認すると，図23のように4人の開発者のうち，2 人が該当モジュールの開発に携わっていることがわかる．特に3人目の開発 者は編集回数が最も多く，モジュール開発の中心人物であることがうかがえ る．この開発者にバグの報告をすれば，最もスムーズにバグの対応にあたる ことができるのではないかと推測される．

6. プロジェクトに追加されたメンバに関する情報を調べたい 過去事例

図24 プロジェクトに追加されたメンバに関する情報を調べたい

• 開発コストを抑えるために，社員の比率を抑えて協力会社の開発者で補 充することにした．しかし，改めてハイスキルの開発者を補充する必要 に迫られ，コストをあまり下げることができなかった．(事例番号10)

• 要件定義の担当者に業務知識が無く，要件定義は日を追うごとに遅れて いき，成果物の品質もきわめて低いものになった．(事例番号11) 開発プロジェクトが佳境に入ると遅れている箇所にメンバが増員される場合 もある．その際に，増員されたメンバがどの程度プロジェクトの内容を知っ ているかを開発者表示モードで確認することができる．図24の休日の翌日 から遅れている箇所に図24の3人目と4人目のメンバが増員された．この とき，3人目は増員前のセルが灰色であり，増員されるまでは別の箇所を担 当していたことがわかる．以上より，プロジェクトについての知識を有して おり特別のフォローは必要ないであろうと予想される．一方 4人目のメン バは増員日に初めてセルに色がついていることから新規人員であることがわ かる．そのため，プロジェクトについての知識は全くないため，特別なフォ ローをする必要があることが伺える．

このような形で，IZMIは上流工程における進捗状況の把握や，事後分析に活用 することができる．また，過去の開発プロジェクトにおいて発生した事例につい て，IZMIを用いることで対応可能な候補を挙げることができた．