« 複数の視点で描かれた図面同士の牽制が重要 | トップページ | わかりやすさと論理性を両立させる(後編) »

2005.10.30

わかりやすさと論理性を両立させる(前編)

成果物の「わかりやすさ」と「論理性」を確保することは、システム開発の全工程を通じて重要な課題だ。とくに、上流工程では「論理性」が、下流工程では「わかりやすさ」が意識されなければならない。

 プログラミングにおいて「論理性」をことさら重要視する必要はない。それは重要でないということではなくて、成果物が論理的でなければコンパイルエラーになるかアベンドするかで仕事にならないくらいに本質的ということだ。プログラムのような機能的要素に限れば、下流工程成果物はほっといても論理的なものにならざるを得ない。それは成果物が基本的に「コンピュータ」向けに用意されるものだからだ。

 そのためかどうか、下流工程の成果物は「人間が理解しやすいかどうか」がおろそかなものになりがちだ。いまだに「少量のトリッキーなコード」がクールと思われがちだったりするが、それはプログラムに割り当て可能なメモリー領域が小さかった時代のなごりでしかない。現代のマシンに業務システムを載せるのなら、コードが人間によって保守される限りは、多少くどいとしても「本を読むようなわかりやすさ」にこだわるべきだ。ゆえに、下流工程においては「わかりやすさ」を強く意識したほうがよい。

 なお、「わかりやすさ」と「論理性」とは必ずしも二律背反な性質ではない。「論理的(厳密)であることを目指したのでわかりにくくなった」とか「わかりやすさを重要視したため、多少論理的でない部分がある」といった言い訳が常に通用するとは限らない。じっさいのところ、「論理的であることだけ」とか「わかりやすいことだけ」を目指すことが許されるのなら、システム開発はそれほど難しい仕事ではない。それらの二兎を追って二兎ともに得ることが、システム開発では求められる。

 上流工程に目を向けると、その成果物は「論理性」が軽視されがちだ。「論理的でない論理設計」なんてシャレにもならないがそれが実態だ。軽率な構成、支離滅裂な文章、安直な図解がしばしば見受けられる。それは成果物が基本的に「コンピュータ」ではなく「人間」に対して用意されるものであるゆえに、論理性が強制されないからだ。

 「わかりやすさを重要視したため、多少論理的でない部分がある」という言い訳がとくに乱用されるのが「業務定義」まわりだ。

 前回の記事で、業務フローにおいて「順序を示す矢印」と「流れる方向を示す矢印」を厳密に使い分けるべきだという話を書いたが、現実には「無神経な矢印」と筆者が呼ぶ表現が多用される。「A→B」が「Aの次にBを実施する」だったり、「AがBに渡される」だったり、「Aの結果がBに入力される」だったり、「AはBにビミョーに影響を与える」だったり、はたまた「AはBに片想いしている」だったりする。このような図面は工学的というよりは「文学的」なもので、後続する工程では使い物にならないし、じっさい参照されることがほとんどない。それにも関わらずその種の業務フローが今日もどこかで描かれている。構文エラーの心配もなくドンドン描けるので、設計作業がドンドン進捗したように思えるからだろう。

 では、構文が厳密な表記法を使えば自動的に論理的な図面が出来上がるかというと、そうとも限らない。矢印の意味が「データやモノの流れる方向」に限定されているデータフローダイアグラム(DFD)を使っても「論理的(形式的)にすっきりしない業務フロー」は描けてしまう。後編ではその具体例を示そう。

|

« 複数の視点で描かれた図面同士の牽制が重要 | トップページ | わかりやすさと論理性を両立させる(後編) »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: わかりやすさと論理性を両立させる(前編):

« 複数の視点で描かれた図面同士の牽制が重要 | トップページ | わかりやすさと論理性を両立させる(後編) »