「考える」という行為については、別の項で述べてありますが、要約すると、「その時点で手に入っている知識（体験を含む）を結合して、新しい結論や真理を導きだす（或いは推論する）行為」ということになります。したがって、ある程度の知識の類は、持っていることが必要になってくるでしょう。しかしながら、「ＳＣだより」の「今月の一言」でも触れましたが、知識を得るための「読書脳」と、考える行為の元となる「思索脳」とは別のものです。
ソフトウェアの開発作業の中には、数学の世界のように、必ずしも「正解」と呼べるものは存在しません。Ａさんの回答でもＢさんの回答でも、何れも間違いではない、という世界です。もちろん、Ａさんの回答よりも、（この状況では）Ｂさんの回答の方が優れているということはあります。そして、Ｂさんの回答よりもさらに優れた回答が存在する可能性もあるのです。大事なことは、少しでも不足を感じるなら、考え続けることです。その回答で完全に満足してしまっているのなら仕方がありませんが、そうでないにも関わらず、多くの人は考えることを継続していません。
ソフトウェアの不具合を分析した結果、再発防止のための改善点を考える場面でも、同じようなことが起きています。ソフトウェアのアルゴリズムの問題と違って、プロセスの問題の方は、もっと回答の幅が広くなりますし、組織の状況や担当者によっても、対応策は変わってきます。チェックリストで対応できるケースもあれば、日常の中に組み適当な作業工程を入れなければ改善されないケースもあります。しかも、レベル１の組織にあっては、１回の考える行為で十分な対応策に到達することは殆どないといってもよいでしょう。それならば「継続して」考えるしかないのに、逆にそのような組織に限って「１回」しか考えられません。当然、そこから提起される「改善案」は、不十分な内容であり、実際に次のプロジェクトで活かされることはありません。
ソフトウェア・エンジニアリングに関する文献を読んで、そこに書かれてある方法やモデルに共鳴し、それを自分（たち）の作業に取り入れようとするときも、同じことが起きてしまいます。文献に書かれていることは一つの「雛型」であって、殆どの場合、そのままでは自分たちの世界に取り入れることは出来ません。たとえば「レビュー」一つ取っても、「議論」に対する考え方が違っている可能性があります。そのため、取り入れる際には、それなりに準備や段取りが必要になってきます。
その時点で考え付いた方法や内容が、必ずしも十分ではないと感じるところがある以上、考える行為を継続させなければなりません。にもかかわらず、殆どの人たちは、「１回」限りです。まるで、考えるという行為が「テスト」と一体になって離れないかのようです。「考える」という行為が、中間テストや期末テスト、あるいは入学試験などの「場」でのみ行うものと固定されているかのようです。たしかに、期末試験の解答を、明くる日に再回答することは叶いません。
しかしながら、私たちに求められている「考える」行為は、そんな制限はありません。もちろん、次のプロジェクトの開始までとか、問題の工程の準備に入るまでとか、ある程度の「期限」は存在しますが、それでも、殆どの場合は、そのテーマでは２週間とか１ヶ月という単位の時間があります。その間に別の思索テーマも発生するでしょうが、それもある程度の時間の中で、より優れた「回答」を出せばいいのです。幾つかのテーマを並行して考え、継続して考え、何度も何度も推敲する時間はあるのです。
複数のテーマを並行して考えると言われても、もしかしたらそのこと自体、「どうやってやるか」を考える必要があるかも知れません。それも「１回」では名案は浮かばないでしょう。「行為」と「思索」を連続させることが必要になるでしょう。
大事なことは、考え始めることを遅らせることなく、問題を認識したら直ちに考え始めること、そして、それを何度も形にしながら繰り返すことです。文書の形になっていなければ、考え抜いたことにはならないのです。
そして、考えるという行為が「日常」の中に組み入れるようになることです。