要件定義の進め方

システム開発の大炎上を防ぐために、上流工程(前工程)に位置する「要件定義」について、考えていくブログです。

要件定義書の作り方
PDCAサイクルではなく、PDCサイクルを回そう
あるべきV字モデルについて整理した
スコープを決めてから、QCDの議論をしよう

あるべきV字モデルにおける分業方法について整理した

先日は、自分の中で理想としているあるべきV字モデルについて整理した。今日は、あるべきV字モデルを適用して開発する場合に、どのような分業をするのがよいのかを考えたい。

req-definer.com

分業の必要性

大きなシステムを開発しようとすると、「分業」の必要性が出てくる。要件を定義するにも、設計をするにも、実装をするにも、人の手が必要なのだ。これらの作業は知的な作業であり、頭をフル回転させて作業を進めることとなる。記憶が定かではないが、昔読んだ「ゆとりの法則」という本の中で、「急げと言われた場合、早く動くことはできるが、早く考えることはできない」という記載があったことを思い返している。脳の伝達信号の速度は一定なので、急いで考えることはできないのだ。

ゆとりの法則 - 誰も書かなかったプロジェクト管理の誤解 | トム・デマルコ, 伊豆原 弓 |本 | 通販 | Amazon

知的な作業には速度限界がある。一人で考えられる量には限界があるのだ。そこで、開発速度を加速するために頭数を増やそうという話が出てくる。考える速度に限界があるのなら、考える対象を分割するという発想である。

これは良いアイディアであるが、分業というのは難しい。考える人が違うため、分業により担当者間で認識齟齬が発生するのだ。認識の齟齬は設計書間の整合性を破壊し、システム間のインターフェース整合性を破壊する。その破壊からバグが生まれ、手戻りとなる。手戻りにより、システム開発における余裕時間は徐々に奪われていくのだ。

あるべきV字モデルにおける分業方法について

とはいえ、分業なしに開発を加速することはできない。分業するとするならば、どのように分業をすべきかについてまとめたので、紹介したい。

f:id:req-definer:20220117203114j:plain

あるべきV字モデルにおける分業

上図は、あるべきV字モデルにおける分業体制を示したものである。あるべきV字モデルにおいては、作りこみのフェーズが3工程(要件定義、設計、実装)しかないので、それぞれのフェーズで担当(要件定義者、設計者、実装者)を分けた。進め方としては、下記となる。

  1. 要件定義者は、要件定義書を作成し、要件に対するテスト仕様書を作成し、テスト実施する(③と⑤の矢印参照)
  2. 設計者は、設計書を作成し、設計書に対応するテスト仕様書を作成し、実装者と共にテスト実施する(④と⑥の矢印参照)
  3. 実装者は、実装し、設計者と共にテスト実施する(⑦の矢印参照)

この考えにおけるポイントは、

  • 要件定義書を書いた者は、要件通りに動くまで面倒を見る
  • 設計書を書いた者は、設計通りに動くまでの面倒を見る
  • 実装者は、テスト仕様書を書かない
  • 設計者と実装者は、協力してテストする

という点である。

①②について

要件定義であれ、設計であれ、これらの作業は、システムに対する大なり小なりの要件を出して(こうあるべきと規定)いく作業である。要件通りかどうかの確認は、要件を出した本人が確認すれば、認識の齟齬は発生しない。システム開発における最大の敵は、認識の齟齬である。考えた者が、自ら確認すれば、認識の齟齬は発生しないのである。

③について

実装者はテスト仕様書を書くべきではない。実装者にテスト仕様書を作らせたら、実装を意識してテスト仕様書を書いてしまう。そうすると、認識の齟齬を排除できなくなってしまうのだ。

④について

設計通りかどうかの確認責務は設計者にあるが、効率化という観点で、設計者と実装者が協力してテストをすべきである。

そもそも、モジュールのテストというのは、テストスタブやテストドライバをつくらなければテストできないような状況が往々にしてある。プログラムをテストするためのプログラムを書かねばならないのだ。実装者がプログラムを書き、設計者がテスト用プログラムを書くとなれば、それは非効率ではなかろうか。

そのため、原則として設計者がシステムのテストを行うべきだが、非効率な面もある場合は、実装者の力を借りてテストを進めるというのがよい。

会社間で担当責務を分ける場合

会社間で担当責務を分ける場合はどうであろうか。

要件定義者と設計者を別会社にする場合

この場合は特に問題ない。いわゆる発注者とベンダという関係である。

設計者と実装者を別会社にする場合

この場合はやや問題がある。

実装自体を別会社に任せるという選択肢はありえるが、テストをどう実施していくべきか?という問題が発生する。

単体テストだけ委託した場合は、結合テストをどうやって効率的に実施するのかという問題がある。単モジュールと単モジュールを結合したテストを行うにも、プログラムを書かねばならない場合があるのだ。

結合テストも委託した場合はどうであろうか。この場合は、自分でドキュメントを書いたのに、その通りかどうかを自分で確認できなくなってしまう。ドキュメント通りかどうかを自分で確認していないシステムを顧客に納品する際、品質に自信をもって納品できるであろうか。筆者個人としては、ノーである。

ではどうすべきか。筆者としては、実装者が設計者の会社で派遣社員のような形で作業をするのがよいのではないかと考える。テストフェーズにおいては、設計者と実装者が協力するのは効率的であるので、テスト結果については共同確認/共同承認という形をとるとよい。最後に、こんなこと言ったら身も蓋もないが、全部自社で開発してしまうのが理想ではある。

結論:考えた人が、自分で動きを確認すべし