トム・デマルコ「構造化分析とシステム仕様」
0

[14]. トム・デマルコ「構造化分析とシステム仕様」

今回は、システム開発の古典的名著である、トム・デマルコの構造化分析とシステム仕様を取り上げます。

本について

この日本語訳版は、1986年12月5日1版1刷、1994年9月19日新装1版1刷、1999年6月9日新装1版3刷となっています。英語の原書の方が出たのは1979年。36年も前ですね。

具体的な手法には古さが感じられる部分もありますが、考え方や精神は古びることなく、その辺りが古典的名著たるところです。

ユーザー

分析

この本は、主に分析について重点的に扱っています。

分析とは何かについては、次のように書かれています。

分析とは行動をとる前に実施する問題の調査である。コンピュータ・システムの開発に限ると、分析はさまざまな業務分野あるいは適用業務の調査を指し、通常それは新しいシステムの仕様書に発展していく。

ユーザー重視

「ユーザーとの折衝」の項目には、次のことが書かれています。

1960年代には巨大企業が中小企業を吸収し,(中略)機能を集中化したコンピュータ・システムが多数設置された。この目的は権限の集中化を図り,少数の経営者でコングロマリットの全組織を掌握しようという点にあった。(中略)60年代の考え方では,アナリストとユーザーの敵対関係は非常に生産的な効果を持ち、アナリストは経営者の代理人としてユーザーに参加と従属を強いることができるというものだった。

(中略)プロジェクトはほとんどの場合完全に失敗した。(中略)

60年代の教訓は,いかなるシステムもユーザーの積極的,かつ自発的な参加なくしては完成しないことを教えている。

(中略)ユーザーがシステムにもっと熱中できるようにすべきなのである。担当業務に関するユーザーの専門知識こそが,システム開発の鍵となる。ユーザーがシステムの進捗状況に注意を払い,適当な窓口を通して彼らの意見を吸収して開発中のシステムの目標を修正,あるいは調整できるような体制をしかなければならない。(後略)

この本は、現場主義で貫かれています。

上の内容は、システム開発に限ったことではなく、請負仕事一般に言えることでもあります。実際の業務内容に、あるいは消費者により近いところにいるのはクライアントの方であり、クライアントが「自分は専門外だから」と距離を置く(あるいは請負側が「自分が専門だから」と距離を置かせる)ような進め方ではなく、自発的に参加できるような環境を作り、積極的に関わらせてこそ、プロジェクトは成功します。

コミュニケーション

この本では、アナリストとユーザーのコミュニケーションが重視されていて、次のようにあります。

アナリストはユーザーとのコミュニケーションに責任を持たなければならない。(中略)しばしば複数の部署から“ユーザー代表”を指名して協議組織が作られる。この場合,ユーザー代表にシステムを承認する段階になるとユーザー代表達は表舞台から消え,代わりに真のユーザー達が登場してくる。こうなるとそれまでの話し合いはぶち壊しになり,結局は誰もわずらわしさから解放されないのである。

真のユーザーというのがいいですね。結局今までのはなんだったんだろう、みたいなことは、よくありそうです。

(前略)コミュニケーションの問題は,ユーザーとアナリストの間に共通言語がないことに原因がある。(中略)

コミュニケーションが複雑になるのは,結局,対象がその時点では我々の頭の中にしか存在しないシステムだからである。このシステムのモデルは存在しない。そして我々はシステムを具体化しようとしてあまりに安易に物理項目〔CRT(ブラウン管)画面の表示方式,報告書の書式など〕を決定しがちである。

こういうのも、よく分かる話ですね。自分の頭の中にイメージがあるだけで相手と共有できなければ、コミュニケーションは成立しません。それが適切なものかどうか、検証もできません。だから、誰もが理解できるようなモデル化をすることが、大事になります。

専門用語ではなくユーザーの言葉を使うべきである、ということも書かれていて、独り善がりにならないためには、シンプルながら大事なことです。

また、見た目のような表面的なところから入る開発は、完成しない一つのパターンとしてあるように思います。見た目を変えても中身は変えなくて済むことが多いですが、中身を変えたら見た目を変えなければならないことが多くなる、というのも要因の一つと言えます。

データ

データの観点

調査について、ユーザーの観点からではなく、データの観点から業務を調べなければならない。とあります。

これは結構重要なポイントで、業務や何らかのプロセスの目的は、データにあります。何らかの成果物を生み出すのが目的です。

しかし、得てして、本質的に必要でないかもしれないプロセス自体が目的になってしまう手段と目的の倒錯が起こります。

データの観点に立つことで、目的を見失うことなくシステムをモデル化することができます。

データフロー・ダイアグラム

データフロー・ダイアグラム(DFDは、この本を象徴する存在です。

ここでは詳しくは説明しませんが、第1章の冒頭に出てくるボートの組み立て手順のDFDだけ、引用しておきます。

ボートの組み立て手順を示したDFD

矢印がデータを表し、バブル(丸)がプロセスを表します。プロセスが、矢印として入ってきたデータを、矢印として出て行くデータに変える…基本はただそれだけの図です。

シンプルながら、でもシステムの本質を表していて、こんがらがった頭を整理したい時など、今でも十分に有用な道具です。

分割

データフロー・ダイヤグラムはシステムの有効な分割方法を示してくれる。

大きなシステムをただ大きなまま考えようとしても、なかなか理解しきれません。いくつかのサブシステムに分割することで、すっきりと理解できる形にまとまります。

この時、データに注目したDFDが役に立ちます。

システムとは、入力データから出力データを作り出すもの、と言えます。この入力出力はインターフェース、つまりシステムとシステムを繋ぐものになります。あるシステムの出力内容が、別のシステムの入力内容と一致するなら、その2つのシステムは繋ぐことができる、ということです。

DFDの適切な範囲を線で囲えば、それはそのまま、入力と出力を持ったサブシステムとして分割できます。

この分割の考え方は、いろんな場面で身に付けておいて損はない考え方です。議論がかみ合ってない時などは、問題が適切に分割されてないことが多いですから。

政治的効果

分析は高度に政治的な問題である。とあります。ただ技術を振りかざすだけではなく、うまくコミュニケーションを取ることが必要、というわけですね。

導入

新しい方法を導入する際のポイントが書かれているのですが、これは、なんにでも当てはまりますね。

  • 手始めに小規模でリスクの少ないパイロット・プロジェクトでやってみる
  • 新しい方法を好意的に受け入れてくれる人々に試してみる。ただし,無理強いはよくない
  • 結果の記述は簡潔にしてあまり教条的にしない(一人よがりは反発を買う)
  • 全社的に実施する前に技術を確立しておく

ノウハウの蓄積もない段階でいきなり壮大な計画をぶち上げるのは、失敗する可能性が高いですからね。たとえ小さなプロジェクトでも、最後までやりきれば、次に繋がる知見が得られます。逆に、何となく分かった気がして「こんなもんかな」となめて未完成のまま終えてしまうと、いつまでたっても成長しない、というのが、経験則。小さくても完璧ではなくても完成させることは、大事です。

プロジェクト・ライフサイクル

分析に失敗は次のような形であらわれる。

  • いつまでも完了しないプロジェクト
  • なすべきこと(目的)について合意が得られないために着手できないプロジェクト
  • 使用に耐えないシステムを生み出すプロジェクト

開発の序盤である分析に時間がかかると、「ちゃんと進んでいるんだろうか…」と不安になります。しかし、ここをおろそかにすると、後々の修正にかかる手間の方が遥かに大きくなり、下手すれば完成を見ることなくプロジェクトの失敗に終わることもあります。

ユーザーとアナリストとの関係

最後に、新しい仕様書と手法をユーザーに紹介する時の注意点を紹介しておこうと思います。

ユーザーは人形ではない。
リスペクトは大事、ってことですね。
ユーザは専門用語を嫌がる。
無駄に分かりにくいのは、決して知的とはいえません。難しいことでも分かりやすく表現してこそ、知的であると言えます。
ユーザー自身が構造化仕様書の書き方を覚える必要はない
うまく書くのはいろいろコツが要りますが、見て主要な部分が理解できるようになるのは、さほど難しくはありません。逆に言えば、簡単に理解できるようなシンプルなルールの図でないと(触れなかったけど、視覚的な図で表現する、ということ自体が、分かりやすさにとって重要です)、コミュニケーションの道具として使えない、ということです。

おわりに

今読んでも読み応えのある、よい本です。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です