ソフトウェアを開発するときは、それが要求仕様書や設計仕様書を書いている、コーディングしている、またはテストをしている、といったどんな作業であろうと、かなりの労力を文脈上の誤りを取り除くのに費やしている。この努力には頭が下がる。しかし、ソフトウェアを構築する上での、本当の困難は、概念上の誤りから起こる。大部分の開発者は、文脈上の誤りを探して修正するのに時間が経つのを忘れる。なぜなら、この種の誤りがばかばかしい誤りに見えるので、開発者はどことなくそれを楽しんでしまうからだ。これと対照的に、開発者が概念的な誤りを発見したときは、しばしば何らかの形で傷つき、無力感に襲われる。だが、どんなに優れた人でも概念的な誤りをおかすことがあるだろう。こうした誤りが開発者を待ち受けている。
概念上の誤りを避けるために、開発の各段階で次の重要なことを自問自答せよ。要求分析の期間では、「このシステムは果たして顧客が求めるものだろうか」を自問自答せよ。設計の期間では、「この基本構造は過酷な負荷状態の下でも適切に稼働するだろうか」、または「このアルゴリズムはどんな状態でも正しく働くだろうか」を自問自答せよ。コーディングの期間では、「このコードは私が考えたことを正しくやってくれるだろうか」を自問自答せよ。テストの期間では、「このテストの実行結果ですべてが正しいことを確信できるだろうか」を自問自答せよ
（２０１の鉄則：原理７２＜設計の原理＝概念上の誤りは文脈上の誤りよりも深刻である＞）
多くの設計者にとって、原理７２で提起されている問題は、頭の痛い問題ではないでしょうか。改めて、このように問われると、“もっともです”と答えるでしょうが、実際の作業の中で、このように作業（行動）そのものの根本に関わるような問い掛けは忘れられています。というよりも、毎日の作業が“切れ目無く”連続し、しかも“遅れている”という不安の中で、そのような「自問自答」タイムの入り込む余地が無いのです。
また、私たち「設計者」というのは、どちらかというと自己満足に陥り易い傾向があります。そのために仕様が設計者の個人的趣味の方向に勝手に走り出したりしますが、それを止める方法や仕組みが必ずしも組織の中に存在しません。特に、設計者が、その組織の中である程度の「地位」や「権限」を持っているとなると尚更です。品質的要求を脇に置いたまま、バランスを欠いた設計が行われてしまいます。
私のコンサルティングでは、要求書（仕様ではない）をまとめるときに、個々の要求にそれが必要な「理由」を付けることを勧めていますが、そのとき、合理的で納得できる理由がつかないような要求は、概念上の誤りを内在している可能性があります。このとき、「存在理由」という視点から要求を捉えることをしなかったら、顧客の求めていないものを作ってしまう危険が高くなります。
特に、仕様の展開に入って、視界が仕様のレベルに固定されてしまうと、「そのような仕様が必要なら、こんなことも必要ではないか？」という誘いに乗ってしまうわけです。確かに、そこに並べられた２つの仕様（ＲｎとＲｎ+1）を見る限りでは、それほどの違いがなかったり、両方の存在が妥当に思えることがありますが、その感覚に慣れてしまうと、知らずしらずに大きく反れた仕様も紛れ込んでしまうことになります。
このとき、要求に「理由」が付いていることで、レビューの場で個人的趣味への傾斜を止めることができます。要求だけを見る限り、いろいろな解釈ができることがありますが、「理由」が付いていることで、顧客の求めるところの解釈が絞られるからです。
「この基本構造（アルゴリズム）で耐えられるだろうか」という自問自答をするには、少なくともそこで採用している「アルゴリズム」が表現されたものが無ければ実現しません。場当たり的に考えた（？）アルゴリズムの上にシステムを構築していく途中では、このような自問自答は実現しません。適切なドキュメントの存在が無ければ、この種の自問自答が行われる余地が無いのです。アルゴリズムを自問自答するにも、局面とそこで考えられたアルゴリズムが、たとえば設計書という形の中に表現されているからこそ、後になって、自問自答ができるわけです。ドキュメントは書きすぎても同じようなテーマの記述が点在するだけですが、適切なドキュメントが無ければ、最後まで担当者１人の仕事になってしまい、結局、概念的な誤りに気づくことが遅れてしまいます。
すでに触れましたように、このような「自問自答」が為されない大きな理由は、作業が明確に区切られていないことが挙げられます。昨日の作業と今日の作業が、スケジュールの上でも意識の上でも、まったく連続していて、その間に「自問自答」のような違った性質の作業を挟むことが出来なくなっているのです。適切な成果物に基づいて作業をしていれば、中断しても元の作業に戻りやすいのですが、そのようなものが無ければ、作業を中断することが怖くなったり、おっくうになったりします。
それでも、要求仕様の作成と設計書の作成の間には、明らかに作業上の区切りがあるはずですし、設計書の作成とコーディングも、同様に性質の違う作業ですので、そこで一息入れて「自問自答」できるはずですが、実際には、設計やコーディングという様が混同した形で行われていて、設計を頭で巡らせておいて、その延長上でコーディングに入ったり、さらにその途中で頭の中で設計の見直しをやったりしますので、途中で中断したくないという気持ちがますます強くなってきます。
これは別の項でも触れましたが、作業が計画されていなくて、後ろに押している（と感じている）状態の時は、少しでも「余計なこと」を、自分の巣（領域）の中から放り出したいという気持ちが強くなってきます。そのような状況では、「自問自答」なんて、まったくくだらない行為に見えるでしょう。確かに、「くだらない」と思いながらの「自問自答」ほどくだらないものは無いかも知れません。