「アンチパターン」

野瀬純郎

 コンピュータという道具には、過去に人間が発明してきたものとは大きく異なる特徴があります。それは、こういうことをしなさいと機械に分かる言葉でいちいち命令してやらなければ、梃子でも動かない“ただの箱”だという事です。この命令の集まりをプログラム、プログラムを作る作業をプログラミングといいます。
 コンピュータは電子計算機と呼ばれ、生まれてしばらくは文字通り計算をする道具として使われました。ところが、次第にいろいろな命令を組み合わせて、複雑なことを猛スピードでできるようになり、為替交換、天気予報、ネット販売、原子炉制御、DNA解読等々、もうコンピュータ無しでは社会が動かぬところまで来てしまいました。それにつれて、新たに作るプログラムも、過去に作ったメンテナンスしなければならないプログラムも、手がつけられないほど膨大な規模になり、今後もさらに加速していくでしょう。
 ところで、このプログラミングはどのようにして行っているのでしょう。実は数十年前とほとんど同じ、手作りなのです。命令を一つひとつ並べていくのです。その規模はひとつのシステムでも何千万、何億となります。おまけに規格や標準というものがほとんどありません。家の建築に例えると、システムキッチンやユニットバスはおろか、ドアノブやコンセントの類まで毎回手作りです。○○システムが止まったとか誤動作をしたというニュースがよく報道されますが、ある程度やむを得ない(誤りがあることを前提として対応)面があります。
 もう少し何とかならないかとソフトウェア工学なるものに取組んだり、知恵を絞って様々な手法を考えてきました。そのなかに「デザインパターン」というのがあります。過去のお手本となる良い設計ノウハウを集め、みんなで再利用し易いようにしたパターン集です。“銀の弾丸(魔法の杖)”ではありませんが、生産性や保守性の向上が少しは期待できます。
 この「デザインパターン」の向うを張って「アンチパターン」というものが登場しました。失敗した開発プロセスに焦点を当てて、失敗に陥るパターンを類型化し、問題の早期発見と対応策の提案に資することを目的としています。先の「デザインパターン」とは違い、プログラムの設計に止まらず、システムのアーキテクチャやプロジェクトのマネジメントなどにもこの考え方を広げています。
 さて、前置きが長くなりましたが、長年ITプロジェクトマネジメントのコンサルをしている中で、私が現場でしばしば目にしてきた「アンチパターン」を少し紹介しようと思います。ネーミングは私が勝手につけたものです。
 まずトップバッターは『陣立てごっこ』です。あるプロジェクトがスタートする時点でチームの体制を決めます。大概、体制図は立派なものが出てきます。役割と組織間の関係およびその陣容は、一見きちんと書かれているように見えます。問題は担当者欄で、よく見ると未定のため空白だらけ、あるいは同じ人名があちこちに散在する兼務だらけ…。もちろん、再検討を求めます。プロセスの進行に伴って見直しや補強などがあるでしょうから、最初から完全なものは期待できませんが、人員がいないのに、餅の絵を描いただけで安心しているようなプロジェクトがうまくいくはずはありません。
 次は『つまみ食い』です。システム構築の最終段階でテストを行います。システムの規模が大きくなると、テストの数は何万項目にもなります。最初は易しい、簡単なものから実行しますので、消化数だけを見ると順調に進捗しており、管理者も安心しています。ところが終盤に差し掛かる頃には難しい内容のテストばかりが残っており、たちまちペースは大幅にダウンします。納期を守れなくなりそうだ、それは許されないからテストを省略しよう、と恐ろしい判断がされます。カットオーバー後のある日、突然大トラブルが発生し、テスト不十分が露見しても、それは後の祭りです。重要度、緊急度を考慮した順序付けが肝要ですね。
 もう一つは『骨粗しょう症』です。システムの開発は多くの工程を経て実行されますが、それぞれの工程毎に大量のドキュメントが生産されます。××計画書、××定義書、××設計書、××説明書、××報告書…。この進捗管理ですが、全体の目標ページ数の○○%が完了、などという担当者の報告を鵜呑みにして安心してはいけません。テスト実施時に発見される多くの問題の原因が、肝心なことが書かれていないスカスカのドキュメントにあったというのは日常茶飯事です。厚さ(量)より内容(質)をチェックしてください。
 このような問題の根本を見ると、IT業界に限った話ではなく、それ以外の分野のみなさんにも参考になると思います。それぞれの立場で「アンチパターン集」をつくり、みんなで共有することをお勧めします。最近流行の「失敗に学ぶ」です。リーダーたるもの、ゆめゆめ油断と情断は禁物ですよ。