実物や現場を見れば状況は分かるし、問題が発生しても直接会って話せばそれで済む。前もって書いておいた「文章」を見直す必要などない。「文章」は額に入れて飾っておくか、立派なバインダーに綴じ込んで本棚かロッカーに入れておけばよい。

 一体何の話かと思われたかもしれないが、上記に出てくる「文章」を別な言葉に入れ替えて頂くと思い当たる節があるはずだ。「法律」とか「憲法」を入れると興味深い話になるが、本稿はITproに掲載されるからITに関する言葉を入れた場合について説明する。

 例えば「仕様書」である。実物(ソースコード)や現場(利用シーン)を見れば状況は分かるし、問題(不具合)が発生しても直接(利用者に)会って話せば(相談すれば)それで済む(ソースを直接修正してしまえる)。良いかどうかはさておき、仕様書不要論は存在する。

 例えば「セキュリティポリシー」である。実物(ウイルスに感染したパソコン)や現場(机の上に放置されたノートパソコン)を見れば(セキュリティポリシーを無視している)状況は分かるし、問題(情報漏洩)が発生しても(監督官庁の役人や社長に)直接会って話せば(ひたすら謝れば)それで済む(とまでは言えないが結局は済む)。

 例えば「サービス契約書」である。実物(納品されたソフト)や(運用サービスの)現場を見れば状況は分かるし、(システムダウンなど)問題が発生しても直接会って話せば(代替品の提供か値下げを求めれば)それで済む。揉め事が起きたらさすがに契約書を「見直す必要」があるが、白黒を付ける決め手は発注者と受注者の力関係であることが多く、契約書は軽んじられる。

 「仕様書」「セキュリティポリシー」「サービス契約書」といったITに関係する文書に共通するのは、その文書が対象にしている何かが目に見えないことである。ソースコードをダンプすれば読めるが、そのコードが実現してくれる機能が見えるわけではない。情報やデータは簡単に転送できてしまい、ハードウエアを持ち出す場合に比べて目につかない。サービスは、それを担う人の姿は見えるが品質はなかなか分からない。

 目に見えないからこそ「文書」をしっかり「前もって書いてお」くべきだが、文書はあまり省みられない。その理由は、ハードウエアに対する姿勢のままソフトウエアに接しているからである。

 実物(製品)や現場(工場や生産ライン)を見れば状況は分かるし、(品質の)問題が発生しても(設計者と工場の担当者が)直接会って話せば(対策を検討すれば)それで済む(プロセスの変更で品質を担保できる)。

 ISOマネジメントシステムの導入により、大量の「文書」を書くようになった。だがそれらを「見直す」ことはあまりなく、ISO関連の認証を示す書面を「額に入れて飾っておく」くらい。現場が書いた文書は、「立派なバインダーに綴じ込んで本棚かロッカーに入れ」られている。

 ハードウエアは目に見えるから、文書を軽んじても高い品質を維持できた。しかしその流儀でソフトウエアに取り組んでもうまくいかない。