４年あまりの長期にわたって、「２０１の鉄則」の解説を続けてきました。その結果、原著の項目の１／４を越える項目を解説することになってしまいました。この本は、おそらく多くのソフトウェア開発の関係者に読まれていることと思われますが、その人たちに少しでも役に立つことがでたとすれば、私としても、嬉しいかぎりです。
しかしながら、５０回を越えたこともあって、原著の項目の中での主な部分は、概ね解説し終えたのではないかと思われます。また、この間の時代の変化もあって、新しいテーマも私の前に現れてきましたので、「２０１の鉄則」の解説も、このあたりで一旦終えることにしたいと思い、今回を最終回としました。
最終回では、もう一度、この本の意義や、この種の本の読み方などについて整理しておきたいと思います。また、「５０回」目の「原理４１＝今すぐ要求仕様書の誤りを直せ」のところで、解説が不足していましたので、ここで、補足しておきたいと思います。
原理４１は、「要求分析の原理＝今すぐ要求仕様書の誤りを直せ」というものでしたが、これには非常に大きな意味があります。要求の誤りに気付くのは、主として３つの場面です。一つは、要求仕様のレビューのタイミングで、この場合は、もともと要求仕様を書いていた流れがあるために、仕様書の修正にはあまり抵抗はありません。２番目は、要求仕様を受けて設計に入ったところで、仕様の不足や矛盾に気付くという場面です。ただ、現実には、「設計」という作業が省かれていることが多いため、この機会は明確ではありません。３つ目は、テストによって、仕様が漏れていることが判明したときです。この場合、構成管理（変更制御）が行き渡っていない組織では、目の前のソースの修正が優先されるため、要求仕様書の修正が“後回し”になります。
この“後回し”が確実に実行されれば良いのですが、実際には、実行されないまま放置されることが多いようです。でも、ここで書き直されないために、多くの人は、次の機会でも同じ過ちを繰り返すことになるのです。仕様の誤りと言っても、単なる誤記や値の違いなどの場合は修正に支障は無いのですが、この機能が実行される際の条件の定義が抜けていたり、ある状況でのパフォーマンスの規制が抜けていたというような場合、実は、間単には要求仕様書に追記できないことがあります。
ソースが修正されたのだから、要求仕様書への追記も問題ないと思って、いつでも訂正できると思っていることが、“後回し”の根拠と成っているようですが、実際に仕様に書いてみれば直ぐに分かります。もともと適切に構成されていなければ、そのことを何処に書けば良いか迷ってしまったり、どのように書けば良いか困ってしまいます。特に、そのような記述を漏らした分けですから、仕様書がうまく構成されていないと考えられますので、この種の仕様の追加や訂正が、スームースに行かないことが少なくないのです。
前提事項を追記するために、仕様書の構成を変更したり、整理し直す必要が出てくることがあります。このステップを経て、はじめて次回には同じ過ちをしない確率が高くなるのです。つまり、今回漏らした仕様が漏れることなく考えられる仕組みを手に入れることになります。このステップを経ないかぎり、毎回、同じような前提事項のモレを繰り返してしまうのです。
「２０１の鉄則」は、じつに多くの示唆を含んだ本です。幾つかの場面に分類され、そこで起きる問題を整理して、“このような過ちを侵そうとしていないか？”と、問い掛けてくれます。実際に、一人ののエンジニアが、２０１項目の全てが必要になるわけでありません。今回、解説してきたように、１／４程度で十分足りると思います。
問題は、この本をどう読むかです。少なくとも「読んだことがある」という状態では、ほとんど意味がありません。せっかく、分かりやすい工程単位で分類されているのですから、やはり、実際の作業に入る前に、その工程において、この本に書かれていることに遭遇する可能性があるかどうかを検討し、危険な項については具体的に対応する方法を考え、実施していただきたいものです。あまり多くを一度に取り組もうとすると、うまくいかない可能性が高くなってしまいますので、それぞれの工程ごとに、２〜３の項目に絞った方が良いでしょう。そのかわり、それらの項目については、前の状態から「変化」させることになります。
『実際に体験したことと、自分の頭で考えたこと以外は、いざというときに役に立たない』
これは、私の基本的な姿勢であり、今日まで、この方針を貫いてきたつもりです。新しい手法も、早く帰って自宅でやってみることで手に入れることができました。２０１の鉄則も、一つの項について、実際の作業の中にどのように取り入れるかというところまで具体的に考えます。場合によっては、テンプレートや取り組みの方針書なども、その時点で用意します。このように、自分の頭で考えたり、事前に「ミニ体験」することで、ようやく本番の作業に使うことができるのです。
このような読み方は、何も「２０１の鉄則」に限ったことではありませんが、「鉄則」は、要領良くまとめられていますので、取り組み方を考える行為に入りやすいはずです。同じようなことを一般の文献で行うには、まず、その節で何が述べられているのか、そして何をすべきというのか、と言ったことを読み取らなければなりません。
文章を読むということは、著者の頭の中を歩き回ることで、そのままでは、自分の頭で考えたことにはなりません。そうして著者の頭を散歩しているうちに、自分の頭で考えるという本来の目的を忘れてしまう可能性があります。特に、このような読み方が身についていない状態では、その危険が高いのです。その点、「２０１の鉄則」は、予め要領良くまとめられていますので、著者の頭の散歩から早く開放されて、本来の目的に戻りやすいのです。
どうか、このような本を大事に読み込んで頂きたいと思います。そして、同時にこの種の文献の読み方というものを身に付けていただきたいとおもいます。一人でも多くの方が、適切なソフトウェア開発のあり方を身に付けることに、少しでも役に立てることを願って、この企画を終えることにします。
長い間、お付き合いいただいてありがとうございました。 ［完］