各工程の全体像
システム開発における、各工程を簡単に説明しておきたい。システムとは何か？については、下記を参照されたい。
下図は、一般的なシステム開発における工程を図示したものである。工程はとてもシンプルで、①何を作るかを決め、②それをどう作るかを決めて、③実際に作り、④決めた作り方通りに動くかを確認し、⑤作ったシステムでやりたいことができているかを確認するという工程だ。専門的な用語で表現すると、①は要件定義、②は設計、③は実装と呼ばれる。④と⑤はいわゆるテスト工程であるが、テストにもいろいろな種類があり、人によって解釈が異なるので、筆者は④と⑤をそれぞれ、「設計動作の確認」、「要件動作の確認」と呼んでいる。決めたとおりにシステムが動くことを確認する行為が大切なのであり、テストであれ、確認であれ、呼び方はどうでもよい。見た通りで工程はシンプルなのだが、システム開発は、非常に難しいとされている。
では、なぜシステム開発が難しいと言われるのかというと、筆者の考えとしては、「システムは、みんなで作り上げるものだから」と考えている。できあがるシステムは一つしかないにも関わらず、その一つのシステムを作るために関わる人たちは、たくさんいる。その多くの人たちは、それぞれ、自分の頭の中に、出来上がるシステムというのを想像している。各々の頭の中にあるシステム像を、完全に一致させることはできない。一致させることができないからこそ、認識の相違は発生し、指示伝達ミスが起こりうるのだ。
これらの、各々の頭の中にある認識の相違をいかにして排除するのか？がシステム開発の勘所であり、これまでも課題とされてきたし、今後も課題となり続けるであろうものなのだ。ツールが進化すれば、開発における失敗はなくなるであろうと思いがちだが、それは誤りだ。システム開発の関係者の頭の中を整理することなしに、システム開発の成功はありえないのだから。
ポイント：システム開発の工程はシンプルだが、システム開発を成功させることは難しい
要件定義の位置づけ
開発の要所として、まずは、要件定義の位置づけを整理しておきたい。要件定義というのは、「何を作るかを決める」工程である。言うのは簡単だが、実行するのは非常に難しい工程だ。
https://atmarkit.itmedia.co.jp/ait/articles/1507/02/news009.html
から引用をさせてもらうと、
そこで「カカシ」を使う。カカシとは、トム・デマルコ共著の『アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン』（日経BP社刊）に紹介されているアイデアである。資料が生煮えの状態で「これでどうだろう？」とユーザー部門へ聞いてみるのだ。人は白紙から答えを作り出すのは嫌がるが、すでにあるものは平気で批判するものだ。アイデアを提示すれば、間違えを指摘してもらいやすい。その分だけ早く正解にたどり着ける。
というのがある。人は白紙から答えをだすことを嫌う。つまり、何もない状態から、何かを生み出すというのはとても難しいのだ。難しいからといって、この工程をさぼってはいけない。難しくても、やってみることが大事だ。
重要な点は、「要件定義は、システム開発における最上流工程である」という点だ。「やりたいことを決める」というプロセスを曖昧に進めてしまうと、どう作るかも決められないし、何を確認すればいいのかわからない。やりたいことを具体的に決めることが大切なのだ。よくあるプロジェクトの典型的な失敗例として、プロジェクトの日程を先に決めたものの、要件定義がしっかり行われず、なし崩し的に設計工程に移行し、ボロボロのシステムが出来上がる、という例がある。そのような事例に陥らないように、要件定義をしっかり行っていく必要がある。じゃあどうやって、要件定義をしっかり行えばよいかについては、まだ筆者としては整理しきれていない。しかしながら、やらなければならないことと考えている。本書を通じて、要件定義をしっかり行うための方法論を、整理していきたい。
ポイント：要件定義は、何を作るかを決める工程のことであり、システム開発における最上流工程である
設計の位置づけ
設計に関して説明する。Wikipedia(https://ja.wikipedia.org/wiki/%E8%A8%AD%E8%A8%88)によると、
設計（せっけい、英: design）とは、建築物や工業製品等といったシステムの具現化のため、必要とする機能を検討するなどの準備であり、その成果物としては仕様書や設計図・設計書等、場合によっては模型などを作ることもある。
という説明となっている。よく、設計書がない開発現場を見かけるが、論外だ。なぜならば、設計とは、どう作るかを「決める」工程であるので、ドキュメントがないというのは、決めたことが不明確であることを意味する。今動いている動作が仕様です、動かせばわかります、という言い方をたまに聞くが、このような言い方が通るシステムは、設計工程が不足しているシステムであることを意味する。動かさなくても動作がわかるようにするのが、設計なのだから。「どうしたいのか」を明確に関係者へ意思表示するために、設計書を書こう。
設計工程は、外部設計と内部設計に分かれるのだが、この点については、下記記事を参照されたい。
上図に、設計の位置づけを示す。設計工程の特徴的な点は、前工程が要件定義であり、後工程が実装であるという点だ。要件定義側とも、実装側とも接点があるという点で、設計という仕事は、大変難しいことがわかる。設計におけるポイントは下記2点だ。
- 要件定義側から、要件を正しく伝えてもらう
- 実装側に、どう作るかを正しく伝える
①に関しては、顧客が何を作りたいかを正しく捉えることが重要だ。ここの認識が間違っていると、品質の良いシステムは完成しない。だから、何を作りたいかに関して
、要件定義側としっかり認識合わせをしておくことが大事だ。
②に関しては、実装側に対して、どう作るのかをしっかり伝えることが大事だ。最終的なシステムを実現させるのは、実装側なので、彼らに、作り方を正しく伝達しないと、品質の良いシステムは完成しない。どう作るかを決めることも大事だが、認識合わせという意味でのコミュニケーションも、同じくらい大事なのだ。
ポイント：設計は、要件を正しく捉え、どう作るかを決める工程である
実装の位置づけ
実装と言えば、イメージしやすいのは、プログラミングのことだ。ただし、この工程で行われるのは、プログラムだけではない。プログラムをコンパイルしたり、サーバーの設定をしたり、システムが動くまでの面倒見をするまでのことを指す。理想を言えば、実装が完了した段階で、不具合はゼロとなっていてほしい。よく、テスト工程でバグを検出云々という会話を聞くが、筆者の考えとしては、テスト工程はうまく動作していることを確認する工程であって、バグを見つける工程ではない。実装工程を担当する者が持たねばならない認識は、システムは動いて当たり前という認識だ。設計フェーズや要件定義フェーズに対応するテストが仮に実施されなかったとしても、システムの動作を保証する意識が大切だ。
筆者の考えとしては、要件を定義した者は、要件通りかどうかの確認に最終責任を持つべきだし、設計者は、設計通りかどうかの確認に最終責任を持つべきだという認識だ。では実装者はどうかというと、設計者が設計通りかどうかの確認時にすべてOKとなるように、システムを完成させるべきという認識だ。「実装」という単語を調べると、「実際に動く状態にする」という意味合いが含まれている。
大まかに実装フェーズ(ソフトウェアに限る)でやるべきことは以下と考える。
①システムの環境構築
②プログラムの作成
③プログラムの環境へのプログラムへの組み込み
Windows10で動作するアプリケーションを開発する場合を例にすると、まず、動作保証内のパソコンを用意し、パソコン上にWindows10をインストールし、アプリケーションが動作する前提としての環境変数類を設定するまでが①の作業となる。そして、実際に作成したプログラムを作成するまでが②となる。作成したプログラムをexe形式に変換し、所定の置き場に配置するまでが、③の作業となる。あとは、exeファイルを起動するだけだ。これら①、②、③の作業を終えた段階で、システムは動作しなければならない。その後の工程(いわゆるテスト工程)は、システムが動作することを証明する作業であり、バグを発見する工程ではない。くどいようだが、実装が終わったら、システムは完成していなければならない。
ポイント：実装は、システムを完成させる工程である
設計動作の確認の位置づけ
設計動作の確認で大事なことは、システムが設計通りに動作するかどうかを確認することだ。設計書に書いてないことは確認するべきではない。設計書から読み取れないことを確認しなければならない場合は、その事項を設計書として記載しなおすべきだ。
テスト仕様書を作成する際、確認パターンを網羅的に抽出した際、設計書を読んでも期待値が明確でない場合がよくある。この場合は、設計不備なのであるから、設計書を直さないといけない。そうなると、設計書を直すことにより、実装工程の修正必要性も出てくる。また、設計工程のテスト仕様書ももちろん直さなければならない。そのような事態を防ぐために、テスト仕様書は、原則として設計書の作成が終わった段階でテスト仕様書を書くのが良い。そうすれば、テスト実施の段階で動作が不明確な個所を洗い出すことができるので、手戻りによる設計書の書き直しリスクを低減することができるのだ。
特に注意していただきたいのは、動作確認(設計)フェーズで参照すべきものは、設計書のみとすることだ。要件定義書に書かれている内容は、設計書で網羅されているべきである。そのため、設計書に書かれている内容を網羅的に動作確認すれば、要件はすべて満足されるはずである。また、実装を見て動作確認してはならない。実装は、あくまでも実装であって、そもそも実現したかった機能であるかどうかは、設計書を見ないとわからないからである。設計動作の確認フェーズ終了までにやるべきことは２つある。
①設計動作確認書の作成
②設計動作確認書実施結果報告書の作成
①に関しては、上位文書を設計書として、動作確認書を作成する。理想としては、この文書を作成した後、設計書を作成した者に承認印をもらうことが望ましい。設計者の意図通りに設計動作確認書が作成されれば、認識の相違は発生しないからだ。ポイントは、この作業は、設計完了後すぐに着手できるという点だ。設計動作確認書を作る過程で、設計に不備があるかわかることもあるので、この作業は、設計完了後、なるべくはやくとりかかるほうがよい。
②に関しては、〇×をはっきりつけることが望ましい。動作確認できないから「対象外」という類の記載をよく見かけるが、確認できないなら、別の方法で〇×を判定すべきである。結果を曖昧にせず、はっきりとつけることが大事だ。
ポイント：確認(設計工程)は、システムが設計通りに動作することを確認する工程である。理想的には、設計書に書いていないことを確認してはならない。
要件動作の確認の位置づけ
要件動作の確認で大事なことは、システムが要件通りに動くかどうかを確認することだ。要件定義書に書いてないことは確認するべきではない。要件定義書から読み取れないことを確認しなければならない場合は、その事項を要件定義書として記載しなおすべきだ。なぜならば、設計者は、要件定義書を上位仕様書として設計を行う。要件定義書に書かれていないことを、動作確認の段階で確認し、不具合と言われても、書いてないのだから設計しようもないじゃないかという話になる。この辺りは、しょっちゅうトラブルになる部分だ。要件定義側は、「書いてなくてもできて当たり前だろう」という理屈を主張する。設計側は、「書いていないから設計できないだろう」という理屈を主張する。「当たり前」のレベルをどこに置くかがポイントとなってくる。この「当たり前のレベル」については、事前に合意しておく必要がある。それらは、非機能要件として整理しておくのがよいだろう。
要件動作確認書の作成は、非常に簡単だ。要件定義書をコピペするだけでよい。なぜならば、理想的な要件定義書が作成されていた場合、要件というのはすべて「○○できること」のような表現になっている。要件定義の段階で「〇〇できること」という要求をしている場合、動作確認の段階で、「〇〇できること」を確認するだけでよいのだ。
要件動作の確認フェーズ終了までにやるべきことは２つある。
①要件動作確認書の作成
②要件動作確認書実施結果報告書の作成
設計動作の確認フェーズとやることはほとんど同じとなる。①に関しては、上位文書を要件定義書として、動作確認書を作成する。理想としては、この文書を作成した後、要件定義書を作成した者に承認印をもらうことが望ましい。要件定義者の意図通りに要件動作確認書が作成されれば、認識の相違は発生しないからだ。ポイントは、この作業は、要件定義完了後すぐに着手できるという点だ。要件動作確認書を作る過程で、要件に不備があるかわかることもあるので、この作業は、要件定義完了後、なるべくはやくとりかかるほうがよい。②に関しては、〇×をはっきりつけることが望ましい。動作確認できないから「対象外」という類の記載をよく見かけるが、確認できないなら、別の方法で〇×を判定すべきである。結果を曖昧にせず、はっきりとつけることが大事だ。
ポイント：要件動作の確認は、システムが要件通りに動作することを確認する工程である。理想的には、要件定義書に書いていないことを確認してはならない。
