ソフトウェア開発に役立った古典 『方法序説』
プログラマーやシステムエンジニアであれば、技術書やそれにまつわる関連の書籍を読む機会が多いでしょう。
例えば、C言語使いであればカーニハン＆リッチーの『プログラミング言語C』を、Javaであればジョシュア・ブロックの『Effective Java』といった有名な書籍を読んだことがある方も多いと思います。あるいは、オブジェクト指向のデザインパターンに関してであれば、Gang of Four(GoF)の『オブジェクト指向における再利用のためのデザインパターン』といったところでしょうか。
ブログを書いているエンジニアの方々は、上記のような有名な書籍以外にも古今東西を問わず様々な技術書を紹介していることがあり、私自身もその情報を参考にさせてもらうことがあります。
ここで私も、ソフトウェア開発の仕事で役に立った書籍について書いてみたいと思います。とは言っても、プログラミング言語の解説書や設計手法といった実務に直接的に応用が利いたものではなく、もっと根源的に私の「ものの考え方」に決定的な影響を与えた書籍です。それらから得た「ものの考え方」は、ソフトウェア開発で直面した種々の問題解決の糸口にもなりました。
その書籍はいくつかありますが、今日はそのうちの一つについて紹介します。
- 作者: デカルト,Ren´e Descartes,谷川多佳子
- 出版社/メーカー: 岩波書店
- 発売日: 1997/07/16
- メディア: 文庫
- 購入: 31人 クリック: 344回
- この商品を含むブログ (203件) を見る
この本を私が初めて読んだのは大学生の頃で、確かにそれは平易な文章で書かれてはいるものの、形而上学などの記述の所などは概念的に理解が難しかったのを覚えています。それでも、デカルトが難問を解決する(哲学上の真理をゼロから追求する)ために自ら策定した方法論、いわゆる「四つの規則」については、はっきりと理解できました。
その「四つの規則」は次のように記述されています。
第一は、わたしが明証的に真であると認めるのでなければ、どんなことでも真として受け入れないことだった。言い換えれば、注意ぶかく速断と偏見を避けること、そして疑いをさしはさむ余地のまったくないほど明晰かつ判明に精神に現れるもの以外は、何もわたしの判断のなかに含めないこと。
第二は、わたしが検討する難問の一つ一つを、できるだけ多くの、しかも問題をよりよく解くために必要なだけの少部分に分割すること。
第三は、わたしの思考を順序にしたがって導くこと。そこでは、もっとも単純でもっとも認識しやすいものから始めて、少しずつ、階段を昇るようにして、もっとも複雑なものの認識にまで昇っていき、自然のままでは互いに前後の順序がつかないものの間にさえも順序を想定して進むこと。
そして最後は、すべての場合に、完全な枚挙と全体にわたる見直しをして、なにも見落とさなかったと確信すること。
問題解決というテーマでは、最近でこそクリティカルシンキングやロジカルシンキングと銘打った様々なビジネス書にて、MECEやイシューツリーといった問題解決のフレームワーク(ツール)などが紹介されています。これらは情報を様々な切り口で細分化して、漏れも重なりも不足なく分類し論理を構築していくという方法論を提唱していますが、それはまさにデカルトの「四つの規則」の第二と第四(最後)にその考え方の原点を見出すことができます。
また、「四つの規則」の第三の内容は、最近ではあまり耳にすることが無くなりましたが、川喜田二郎氏が提唱した発想法である「KJ法」の考え方に近いのではないかとも思います。(川喜田氏の「KJ法」は発想法と言われているものの、実際にはフィールドワークから得られた種種雑多な情報をカードなりに転記してざっと並べて、関連しそうな情報をボトムアップで階層構造的にまとめ整理していくものです。)
さらに「四つの規則」の第一は、本書全体を貫く懐疑的精神の一つの現れでもあり、見聞きした情報を取り敢えず疑ってみるということに繋がります。一見正しそうに見える事項であっても、あるいはまた権威ある人の発言であっても、「それは本当か？」「反証例はないか？」という、いい意味で懐疑の目を向けることを示唆しています。また、何らかのグラフなりシステムエラーログなりを見せられて「Aが原因でその結果がBだ」という主張がなされた時に、「それは擬似相関じゃないか？」「AにもBにも共通して影響を与える第三因子のCがあるのでは？」といったチェックの視点が「四つの規則」の第一の懐疑的精神によってもたらされることもあるのです。擬似相関や第三因子の例は認知心理学をベースにしたクリティカルシンキングのテキストで解説されており、ここでもその原点にデカルトの「四つの規則」の考え方が見られます。
もちろん、この本を一度読んだだけですぐに上記の考え方が身につくわけではありません。私の場合は、学生時代に『方法序説』を手にとって以降、その内容の面白さから機を見てはこの本を何度も読み返しました。読み返すたびにデカルトのものの考え方に対する理解が進み、彼の言わんとしたことが、完璧ではないにしても分かっていきました。そして今振り返ると、実生活や仕事で難問に突き当たるたびに、私はこの『方法序説』に記述された考え方を無意識に適用してきたように思います。
ソフトウェア開発の現場は難問の連続です。特に製品出荷後(もしくはシステムのカットオーバー後)に発生する障害は、大規模なシステムであるほどクリティカル(重大)である場合が多く、時間的にも技術的にもシビアな対応を迫られます。そのプレッシャーは、仕様検討や実装あるいはテストの段階におけるものの比ではありません。
例えば過去にこのようなことがありました。某サーバーマシン搭載の某チップを制御するデバイスドライバの開発を担当したときです。そのデバイスドライバはハードウェアとの通信のみならず、いくつかの他のドライバとも連携し、また上位アプリケーションやBIOSからのリクエストも処理する必要があったため、難度の高い設計と実装が求められました。さらにマルチCPU環境で動作するため繊細なスレッド処理を記述しなければならず、私にとって最も壁の高い開発になりました。紆余曲折を経て無事に製品を出荷することができたのですが、出荷後しばらくして、ある大手の顧客から障害が発生したとの連絡を受けました。サーバーマシンを稼働中に突然ブルースクリーンが発生してダウンしたとのことです。フィールドサポートエンジニアから送られてきたメモリダンプを解析してスタックトレースを表示させると、私が実装したファンクションの実行中にマシンがダウンしたことが判明しました。
緊急度が高い障害対応案件でした。胸の奥がヒュンッとしました。こういった緊急度の高い障害報告を受け、自分が担当したモジュールがその障害に関係したことが分かると、その瞬間に胸の奥がヒュンッとなり緊張感が全身を走るものです。それは恋心のような甘美なものではなく、あたかもジェットコースターに乗っていて頂上から急下降するときのような体感。顧客でブルースクリーンが発生するなら、開発担当エンジニアの顔はブルーフェイスになります。(実際の英単語はpaleですが)
すぐに障害解析を始めました。メモリダンプ内から様々なモジュールとやり取りしたデータの流れを確認し、そして自分が実装したコードを精査しましたが、一向に原因が分かりません。持てる知識を総動員させましたが、実装上バグがあるようには見えませんでした。社内からエース級のエンジニアにサポートをお願いし、コードレビューも実施しましたが、やはり処理の記述に問題はありませんでした。ソフトウェアに問題がない場合はハードウェアに問題があるものですが、その場合はバスエラーなどのハードウェア特有のエラーもシステムログなどに記録されるはずであり、今回の障害ではそのような形跡も一切ありませんでした。
私は窮地に立ちました。こういった状況の時には、なまじ専門知識があるゆえに妙に視野が狭くなり、問題解決が遠のくこともあるものです。そしてこのような時に、問題解決者に根付いたもっと根本的な「ものの考え方」が如実に影響してくるものです。私の場合のそれは、デカルトの「四つの規則」に影響されたものでした。大量のログやコードなど様々な情報で錯綜した思考をトイレの便座に座って一旦リフレッシュし、そして自席に戻り別の観点から障害解析に当たりました。この別の観点というのが、私の場合はデカルトの「四つの規則」から導かれた観点でした。そして結局、この障害の原因は私が実装したコード上にあるのではなく、ハードウェアに起因するものであると分かりました。サーバマシンに搭載された2つのCPUのクロック周波数が各々異なっていたため、ドライバ内部で一定間隔でスレッド更新する箇所で不整合が起きたのです。ハードウェアの原因と言うよりは、本来同じクロック周波数のCPUを搭載するはずのものが実際は異なっていたという調達ミスのような感じです。
このように、専門知識だけでななく、その人が培ってきた根本的な「ものの考え方」が問題解決に影響を及ぼすことがあります。そして、その「ものの考え方」は、携わっている領域の専門書だけでなく、様々な領域の書籍も読み込むことによって醸成されていくものと思います。必然的に視野が広がるからです。そしてこのことは、若ければ若いほど効果的なのかなと思います。
