ときどきソフトウェア技術者の適性とは何か、その適性を見抜くにはどうしたらよいかで悩むことがある。ある技術者に対して「明らかに適性がない」という判断は下せても、それでは具体的に適性とは何かと聞かれるとはたと困ってしまうのである。ソフトウェア技術者としての適性がないことが分かれば、できるだけ早く他の職種に転身させてあげた方が本人のためにもなるし、それは（適性があると思って）採用した側の責任でもあると思う。しかし何よりも大切なことは採用前に適性を見抜くことであろう。

　ソフトウェア技術者の適性として求められる必要十分条件をあげることは難しいが、必要条件の内のいくつかをあげることはできそうである。自分がソフトウェア開発という分野に足を突っ込んで以来、ずっと「これは必要な能力ではないか」と思ってきたことがある。それは「推理力」である。

　ソフトウェア技術者が携わる仕事には色々な分野があり、いずれの分野でも対応できるような能力を持つスーパーマンは望むべくもないが、どんなソフトウェア技術者でも最初はプログラム作りから経験を積まなければならない。そしてどんな優秀なソフトウェア技術者でも、本人の意に反してプログラムに虫を作り込んでしまうという事態に直面する。そのとき自分で虫を発見して、それを修正できなければならない。どんなに立派な設計をしても、どんなに優れたアルゴリズムを展開することができたとしても最終的に虫を潰して完成させない限り、そのプログラムは存在しないのと同じだからである。したがって「自分で虫を潰す」能力は、必須の能力だと思うのである。

　我々の職場では、若いソフトウェア技術者が日々プログラム作成とデバッグ作業に追われている。残業と徹夜が続くこともある。そういうときソフトウェア技術者は孤独である。デバッグを他人に頼むことはできない。上司などまったく助けにならない。上司の存在は精神的な支えにはなっても（それすらあやしいときもある）、虫を発見するとかそれを解決するとかいう直接的な作業の手助けにはならない。実務に詳しい直属の上長なら問題の部分のロジックを本人に説明させて、その説明の間にヒントを与えることができるかもしれない。しかしその場合であっても真に解決の糸口を見付けられるのは、説明している本人以外にはいないのである。自分の仕込んだ虫は、基本的には自分で発見し自分で解決するしかないのである。

　そのデバッグという孤独な作業を行う場合、虫の原因が単純なロジックの記述漏れに起因するものであれば話は簡単である。しかし普通は、複数のコーディング部分の設定が複雑に絡み合い微妙に影響し合って、結果として思わぬ現象となって発現することの方が多い。

　最近は、デバッグのための各種ツールが備わっているので、それらを駆使することによって問題解決に有用なデータを収集することができる。したがって、デバッグにコンピュータを活用するのは当たり前のことになっている。その影響からか解決策を見付けるのに、ロジックをよく理解して根本的な問題解決をはかることをしないで、とにかく闇雲に変更してみて結果を見るというデバッグ姿勢が目立ってきている。その変更でたまたま良い結果が得られたとしても別のデータを与えると不具合が再発するかもしれない。あるいは全く別の部分に副作用として変な現象が現れるかもしれない。根本的な問題解決には結び付かない対症療法が多いのである。“じゅうたん爆撃”で片端から変更を繰り返し結果を見るというやり方は、もはや破れかぶれの行為と言ってもよく、ソフトウェア技術者のとるべき態度ではない（数学の世界では、これは問題解決の方策をすべて失ったときにしかやらない方法である。４色問題の解法がよい例であろう。ましてやソフトウェアの世界である。方策がないはずはない）。

　デバッグを行う場合、それまでに得られたデータを（現象も含めて）冷静に分析し、現在のロジックでは必ずこのような現象になるということを、すべての現象に渡って推理、確認することが必要である（どんな些細な現象でも無視してはならない）。怪しい所が一つ見付かったからといって安心して追及の手を弛めてはならない。すべての現象が矛盾なく説明でき、その現象が起こらないようにするにはどうしたらよいか、どこにどんな伏線を張っておけばよいかを机上推理で構築・確認できて初めてコンピュータ上で試してみるという慎重さが必要である。最近のようにコンピュータを何時でも利用できるという環境は、デバッグ段階でのこの「推理」に時間をかける上でかえって障害になっている。昔のようにコンピュータを利用できる時間が限られていて、使えるときには一気に問題を解決しなければならないという厳しい環境のもとでは、技術者の机上推理に掛ける時間も、気迫も、気構えも今とは全く違っていたのではないかと思う。コンピュータに直ぐ取り付いてじゅうたん爆撃のデバッグを繰り返す体力派技術者よりも、こうした推理力を働かせる頭脳派（技巧派）技術者の方が、結局のところ早く問題解決に辿り着くことができるのではないだろうか。

　では、推理力のあることを見抜くにはどうしたらよいか。これは難しい。将棋や囲碁の得意な人が向いているという説は全くあてにならない。棋士が長考して無限にある枝分かれした「手」の中から最良の次の一手を考え出すのは、過去の経験に裏打ちされた直感にもとずいて可能性の枝を（何ら検討を加えることなく）切り落としているのであって、推理力にもとずいて理詰めで可能性の枝を切り落としている訳ではない。そうでなければ短い時間内で何百手も先を読めるはずがない。直感でデバッグしたのではソフトウェアの問題は解決しないのである。

　誰でも思い付く方法かもしれないが、推理小説の好きな人を選ぶというのはどうであろうか。それも、最後のどんでん返しでだまされるのを楽しむ人ではなく、理詰めで推理していくのを好む人の方である。推理小説の種類もシャーロック・ホームズのような“おとぎ話”的なものではなく正統派の本格推理小説でなければならない（熱烈なシャーロッキアンには叱られそうだが）。たとえば、本格推理小説の古典ともいうべきヴァン・ダインの「グリーン家殺人事件」やアガサ・クリスティーの「アクロイド殺し」などを読んで、何ページ目で犯人を正しく推理できたかを見ることにするというのはどうであろうか^（注）。

　これを採用試験でやるという案は、私の衰えた推理力を最大限に駆使するまでもなく不可能であることが容易に推測できる。むしろ、これからソフトウェア技術者を目指す若者は、こういった方法で自ら推理力の有無を自己判断してから会社訪問してきて欲しいものである。

　では、推理力のない者はソフトウェア技術者になれないのかというと、そんなことはない。要はプログラムに虫を（それも、たちの悪い虫を）作り込まない技術者になればよいのである。そして、推理力を要する場面に遭遇しないようにすればよい。もっとも、デバッグ以外の場面でソフトウェア技術者が推理力を必要としないかどうか、そのあたりはよくは知らないが。■

【注】この文を読んだ先輩Ｙ氏から、本格派の推理小説を挙げるのであれば、物語の途中で「読者への挑戦」を掲げたエラリー・クィーンを抜かす手はあるまい、とのご指摘を受けた。確かにその通りであろう。残念ながら私は、エラリー・クィーンの作品は「x の悲劇」（x={Ｘ，Ｙ，Ｚ}）位しか読んでいなかったので、代表作を自信をもって挙げることができなかったのである。

［］