« DB設計セミナー開催します(東京7/30-31) | トップページ | 特定ドメイン向け開発環境の意義 »

2012.07.10

Excel方眼紙がダメな2つの理由

 悪名高い「Excel方眼紙」について、「そうそう。あのやり方は最悪だ。まだWordのほうがいい。なぜなら」なんて議論が始まったりすると残念過ぎて泣けてくる。ExcelやWordを使って仕様書を書くことの問題を、改めてはっきりさせておきたい。

 私の言う「Excel方眼紙」はいくぶん象徴的な言い方である。正確に言えば、Excelを使って仕様書を書くことそのものが間違っているわけではない。Excelで書かれた仕様書の内容にもとづく「自動生成」や「動的制御」を実現しているのであれば、それはまともな職場といっていい。

 そのような合理化を模索しようとせず、ExcelやWordやパワポやネット上の文書作成ツールあたりを使って仕様書を書いて、さらに別途プログラミングをやっているとすれば、大いにカイゼンの余地がある。あまりに生産性が低いし、仕様書とコードが分離しているゆえに遅かれ早かれ両者の整合性が失われるからだ。

 つまり私は「Excel方眼紙」という言い方で「仕様書作成工程とプログラミング工程とが泣き別れになっている開発体制」を問題視しているのである。仕様書書きにExcelを使わなければいい、という単純な主張ではない。

 ソフトウエア開発の専門家が寄ってたかって、仕様書書きとプログラミングの工程を統合できないままに開発作業を続けている――それは私に言わせれば「英語を使えないセールスマンが英語教材を売ろうとしている」ようなものだ。そんな商品もそれを売る会社も信用されない。せめて「2つの工程を融合させる技術をかつて開発したものだが、我々の人月ビジネスとソリが悪いことがわかって泣く泣くお蔵入りにした」くらいの語りはできたほうがいい。「やればできる子」であることは伝わるであろう。

 それでは、Excel等で仕様書情報を書くだけでなく、それをもとにして「自動生成」なり「動的制御」なりの方式でプログラミング工程を合理化できたとしよう。それでカイゼンがまっとうされたかと言うと、まだ大きな課題が残っている。あまり語られることがないのだが、そのレベルでは仕様情報に関する定義要素間の整合性維持やクロスレファレンスが不如意なままなのだ。

 仕様書の作成・維持が業務システムの保守フェーズにおいて決定的に重要であることは、経験者なら身に染みている。業務システムほどに複雑なソフトウエアの仕様情報は、「コード」よりも高次の様式に沿って管理される必要がある。自由度の高いコードベースでは、保守要員が交代してゆく過程で可読性や保守性が低下するからだ。そのために「仕様書」の形での仕様管理体制が求められる。ところが、管理されるべき膨大な定義要素間には複雑な整合関係が存在し、それを維持することはExcel等の汎用ツールでは手に余る。

 ゆえに、仕様情報を有機的に管理するのであれば、汎用ツールではなく「仕様書の作成・維持のための専用ツール」が要る。それを使えば、業務システムの仕様を端的に理解できるだけでなく、さまざまな定義要素間の整合性を監視できるようになるからだ。たとえばあるフィールド定義を変更したい場合、事前にその影響範囲を確認できる。また、あるフィールド定義が何らかのデータ処理機能によって利用されているのなら、これをテーブル定義からドロップしようとすれば「既存機能で利用されているので削除できません」とエラーが示される。

 そしてこれは大事な点なのだが、そんな有機的な働きをする「仕様書作成のための専用エディタ」があるとすれば、これを用いて作成された仕様書が「そのまま実行可能でない」ことはむしろ想像しにくい。仕様情報を様式化して専用ツールで編集できるようにすることは、アプリを仕様情報にもとづいて制御することとじつはほぼ一直線なのである。「仕様書専用エディタ」のアイデアはそれほどに啓示的で、私はあるときそれを想像してしまったゆえに、仕様書の専用エディタと解釈エンジンとがセットになったOSSプラットフォーム「XEAD Driver」を開発してしまった。

 仕様書専用エディタを用いることで、プログラミングだけでなく仕様情報管理までが合理化される。そのやり方の最大の効用は、システムの保守フェーズや刷新の際に顕れる。なにしろ「実行可能な仕様書とミニマムなコード」でシステムが記述されているので、第三者にとっての可読性が良好であり続けるからだ。その反対に保守や刷新にもっとも苦労させられるのは、仕様書.xlsがお飾りのように添えられた(またはそれさえ添えられていない)コードの山のようなシステムである。

 そしてこれは「想像力と倫理性の問題」でもある。「自分ほどには賢くない誰かが、ある日突然にシステム保守を引き継いだときに何が起こるか」をとことん想像しながら、業務システムの開発・保守は進められるべきだ。なぜなら、誰であっても職場から(あるいはこの世から)突然いなくなることがあるからだ。ゆえに、システムの仕様は行き届いた仕様書によって管理されるべきである。

 また、こんなことも想像してみてほしい。自分が乗る予定の飛行機がExcel方眼紙で設計されているとしたら、あなたはそれに乗る気がするだろうか。家、ビル、車、電化製品、なんでもいい。それらが専用ツールを使わずにExcel方眼紙で設計されていると知ったら、そのメーカーを信頼する気になるだろうか。「業務システムは特殊だ」とあなたは言うかもしれないが、それは子供っぽい思い込みである。業務システムもごくふつうの複雑でおおがかりな工学的構築物でしかない。

 まとめると、「Excel方眼紙」がダメな根源的な理由は2つある。プログラミングが合理化されない点、そして仕様情報管理が合理化されない点だ。これらに比べたら「Excelでは保守しづらい」とか「印刷するとずれる」など可憐なほどに瑣末である。そういうわけで、この問題への対応状況には次の3段階がある。使っているツールがExcelだろうがWordだろうがパワポだろうが、せめてレベル1を目指そう。レベル0の職場で人生を無駄使いしてはいけない。

<レベル0>
汎用ツールで仕様書を書いて、いちいちプログラミングしている

<レベル1>
汎用ツールで仕様書を書いて、プログラミングを合理化している

<レベル2>
専用ツールで仕様書を書いて、プログラミングと仕様情報管理とを合理化している

|

« DB設計セミナー開催します(東京7/30-31) | トップページ | 特定ドメイン向け開発環境の意義 »

コメント

ExcelとかWordとかを全角で書くのもどうかと思うけどなwww
(嫌悪感)

投稿: 通りすがり | 2012.07.10 21:16

確かに(^^; 修正しました。

投稿: わたなべ | 2012.07.11 08:04

実行可能な仕様書とプログラム言語で記述されるソースコードの本質的な違いってなんでしょうか?

投稿: cz hong | 2012.08.17 07:19

本質的な違いというものはなくて、「関数化度」の量的違いでしかないと思います。喩えるなら、2つの日付の日数差計算をいちいちスクラッチコーディングするやり方と、「日数差計算関数」をあらかじめ作っておいてパラメータを渡すやり方との違い。

「実行可能な仕様書」は、処理パターン毎にあらかじめ用意してある「関数」にパラメータを渡すことで所定の動きをエミュレートさせる、という手法です。パラメータの様式は処理パターン毎に定まっていて、専用のエディタでパラメータ値を読み出せば「仕様書」に見える、というわけです。

投稿: わたなべ | 2012.08.17 09:07

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: Excel方眼紙がダメな2つの理由:

« DB設計セミナー開催します(東京7/30-31) | トップページ | 特定ドメイン向け開発環境の意義 »