今日は、気のおけない人達と飲み会。簡易忘年会といった感じ。
その場で、ちょっと話題となったのが、メンバーの中の一人とで「○○○マジック」と呼ばれているもの。○○○は、私の名前というかニックネーム。2，3時間（とか1，2時間）で万件レベルのテスト項目を読むというもので、その人の仲間の間でも、そう呼ばれているみたい。
多少説明はしたけど、色んな他の話題が出たので、うまく伝わったか? また、その細部の手法よりも、以下の件が重要。
つまり、ソフトウェア開発には色んな文書があるけど、誰かが全体を把握する必要があるということ。文書で大きなのが、設計系だと”システム仕様書”や”製品仕様書”といった、設計上の一番上位としてまとまった文書。またテスト系も、それに対応するテストの仕様書。
まず、これがある所と無い所とでは、雲泥の差。というのも、各ブロックとか各ボード、各サブシステムといった類の文書が揃っていても、全体を理解できない。全体の整合性確認のためには、多量のチェックが必要となる。したがって、個人的には、全体の文書作成が難しかったら、各ブロック等の文書作成を犠牲にすべきとの意見。
次は、その全体的な文書のチェックを、誰がやるかということ。多少、誰が作成するかという問題もあるけど。
実は、ソフトウェア規模が大きくなると、この文書作成自体が相当面倒。初級的なプログラマだらけだと、ちょこっとプログラム作成することが楽しいから、そちらに走りがち。というか、初歩的プログラミングしかしてないと、そもそも文書を書く必要性が理解できない。（そんな連中が、外注とかオフショアに作業やらしても、文書がないのを平然としたり、そのチェックを実施できない。破綻原因の一つ。） 書いたりチェックが、各ブロック等どまりになるケースがほとんどである。
全体チェックの必要性が分かれば、後は、それを誰がやるか。複数人で作成したとしても、できれば別の人のチェックが望ましい。そう考えると、リーダー格が実施する方が効率良い。統一性も確保できる。つまり、全体チェックは誰かがやらなくてはならないし、それはリーダー格がやるべきである。
その必要性が理解できれば、後は、どう実施するかを考えればいいだけ。例えば、小説を含めた書籍は、それなりの情報量だけど、理解できる。良い例は、法律書かな。
人は個別の関連性のないものをたくさん並べられても、理解しにくいとか覚えにくい。章とか見出しは、そのためにある。つまり、仕様書もテスト項目も、章立てなどを明確にしておけばいい。そうすれば、どこに書いてありそうか判断できるし、書いてなければ追記する必要がある。（特にテスト項目で重要なのは、非機能要件に対するテスト項目が書かれているか。）
その次は、如何に迅速に読むかだ。迅速に拘るのは、ドキュメント更新が少なくないから。それはシステムであれば、ユーザからの要望追加とか変更も関係する。ユーザからのそれらがないとしても、内部的な細部仕様は結構変わる。ユーザには余り関係しない、サービス向けの仕様とか、いわゆる非機能要件部分の変更もその類。
なので設計系もそうだが、テスト系もテスト仕様書は誰かが、しかも迅速に読むことが必要である。ちなみに如何に迅速にと言っても、最初は整合性が欠如してる部分が多いので、どうしても時間はかかる、それは仕方ない。ただ、中盤～終盤になれば、差分や仕様記載/テストでのポイントに注力して、時間を短くする必要がある。
そのための具体的な方法は、やはりそれぞれの文書作成のインフラとかツールにも若干関係する。ただ注意は、そのツールの方が重要じゃなくて、それを達成すべきとの意識の方だ。（私の場合、文書とかテスト項目のエクセル記述は大嫌いである。100ページの仕様とか1万件クラスのテスト項目を、一挙に読む場合を想定してもらえればすぐに分かると思う。スクロール一つとかを想定してもらえれば幸い。）
まだ細部では伝わりが悪いところがあるかもしれないけど、それはまたの機会かな。
#補足：念のためだが、各ブロック等の文書が重要で、全体文書がさほどでもないケースはある。”摺り合わせ”などの類。ただ、そのためには、各ブロックでの限界などが明確に規定されていたり、その厳密なチェックが行われるケースに限定される。
