　山浦恒央の“くみこみ”な話の連載第170回から、入門者をターゲットとして、「イチから全部作ってみよう」というシリーズを始めました。このシリーズでは、多岐にわたるソフトウェア開発の最初から最後まで、すなわち、要求仕様の定義、設計書の作成、コーディング、デバッグ、テスト、保守までの「開発フェーズ」の全プロセスを具体的に理解、経験することを目的にしています。

　なお、本シリーズ第1回目を読んでいない方は、以下のリンクから一読することをオススメします。

⇒連載「山浦恒央の“くみこみ”な話」バックナンバー

2．前回の振り返り

　過去5回（連載第179～183回）にわたり、文化祭のたこ焼き模擬店を題材とした要求仕様書を作成しています。初めの2回で仕様のたたき台を作り、残り3回で異常ケースも取り入れてブラッシュアップしています。現在、仕様書の文字数は3000字ほどのボリュームになっています。

　前回までで、要求仕様書のドラフトが完成したとして、今回は「セルフチェック」のトピックに移ります。

3．完璧だと思っても実はダメだった

　自分が完璧だと思っても、実はダメだったケースは多くありますね。人間は、誰しも間違いをする生き物で、時には大問題に発展することも少なくありません。

　もちろん、世の中には超天才がいて、ノーチェックでもOKという人もいるでしょう。しかし、大多数は、ノーチェックの結果、後々、「何でもっと早く気付かなかった」と後悔することになります。

　まず、2つの例題から、「自分の完璧がいかにあてにならないか」について考えます。

3.1 満点だと思った期末テストが実はボロボロだった

　「満点だと思った期末テストが、実はボロボロだった」という経験をした人も多いと思います。例えば、中学生レベルの英文法のテストで自信満々に勘違いするケースから考えてみましょう。

例：動詞として正しいものを選べ。

Everyone in the class (is / are) excited about the trip.

解答：are

　「3人称単数はis、複数はareだよね。Everyone（みんな）は、複数人を表すのでareでしょ。完璧！」と自信満々で勘違いするケースです。残念ながら、Everyoneは、一つの集団という意味で単数を表すため、正しくは「is」ですね。このように、自信満々に勘違いをすると、自身で気付くまで自分が正しいと思い込んでしまいます。いわゆる「確信犯」で、「自分では正しいと信じているのに、世の中の常識から逸脱している」犯罪です（なお「確信犯」については、「法に反することが分かっていながら、罪を犯すこと」と誤解している人がほとんどですが、辞書などでの定義ではここで挙げた意味が正しいとされています）。

3.2 塩と砂糖を間違った

　仕事帰りで疲れていた夜、筆者は、晩御飯にオムレツを作ることにしました（図1）。

図1　オムレツのレシピ［クリックで拡大］

※写真はイメージです

　図1の通り、「オムレツなんて簡単だろ」と思いながら作ったのですが、食べると味が変だと気付きました。原因は、塩を入れるはずが砂糖を入れてしまったことで、疲れていて間違えてしまいました。

　3.1と3.2で挙げた2つの例から、自分が完璧と思っても、客観的な視点から確認すると、ミスや勘違いがあることは少なくありません。後悔しないためには成果物を確認する作業が必要です。その第一歩として、自分自身で成果物を確認するセルフチェックをしましょう。

　中間テストや期末テストの時間配分としては、問題の解答に80％、見直しに20％程度が平均的だと思います。しかしながらソフトウェア開発では、筆者の大雑把な感覚として、工数の半分以上がテストや見直しにかかると思っています。仕様書を定義してはチェック、設計書を書いてはチェック、コーディングしてはチェック、デバッグ（自分でチェックすること）、テスト（他人によるチェック）とチェックだらけです。中間テストや期末テストでは、解答を記入した後、時間がなくて見直さない人がいますが、ソフトウェア開発では、時間がなくても、必ず見直さねばなりません。

セルフチェックの方法

　　　　　　 1|2|3 次のページへ