SESSAME Working Group 2 構造化分析手法教科書 〜イントロダクション〜
最終更新日 2003年5月1日

構造化分析手法教科書のイントロダクションをご紹介します


富士山ここはセサミ電機の図書室。丹沢山系の山々のその上に雪をかぶった富士山がのぞいている。そんな風景は見飽きているのか、たくさんの本を前に溜め息をもらしている人がいる。メイビーさん、34才。組込み機器のソフトウェア開発を任されている中堅管理職。昨日、企画部長に呼ばれて新しい仕事を命じられた。

企画部長 「メイビー君、この前の開発はフラッシュだったから土壇場で徹夜を続けて書き換え作業を頑張ってくれたので何とかトラブルを回避できたが、あれがマスクROMだったら納期遅延を起こしてたぞ。新規開発じゃないんだから、こんな事が毎回毎回続くようだと考えなきゃいけないね。

ところで、企画部門では今まで当社で扱っていなかった電子ポットを手がけようかと考えている。社長の肝いりでなあ。噂では♪母さん朝から押してない♪のコマーシャルが気に入って、ネット対応の電子ポットみたいな話題を呼ぶ企画を考えろと言われていて。企画は我々の部門が考えるとして、基本機能を持った電子ポットを生産コスト見積もりも兼ねて試作することにしている。

誰にやってもらおうかと考えていたのだが、君が丁度仕事を一段落させたところだから、頼もうと思って。ただ試作するだけではもったいないから、最近のドタバタを反省して一度設計方法を見直してみてはどうだね。隣の課にいるシャル君と君のところの新人のウィルさんと3人でチームを組んで勉強も兼ねてやってくれ。ただ試作と言っても、企画が決まればすぐに製品化になるかもしれないので、拡張性と流用性は初めから考えおいてくれよ。この前のようなドタバタはごめんだよ。」

メイビーさんは、今まで目を通していた本を脇に置いて、横にあった古い本を開けながら独り言を言っている。

メイビー 「何が"この前のようなドタバタはごめんだよ"だ。現場の苦労を知らないで。どこでもこんなものだよ。いつも企画部門がざるのような仕様を出してきて、開発の最後の方になったら、仕様を誤解しているじゃないかと難癖付けて仕様変更を入れるから、いつも最後は苦労するんだ。ったく、ソフト開発は難しいんだ!」

「そうだよな、難しいよなあ」
と急に後ろから声がしたのでメイビーさんが振り向くと、社内では仙人とかセサミアンとか呼ばれている人が立っていた。彼はソフトウェアに関しては非常に詳しいらしいが、どうもみんなから煙たがられていて、そのせいか特定の開発部門には属していない。彼は気が向くと開発現場に現れて意見を言うが、課長レベルが相手にしないらしい。メイビーさんは、何だ人が困っているのに、のんきな顔で現れて思っていると、
セサミアン 「ほう、懐かしい本を読んどるな。Hatleyの『リアルタイム・システムの構造化分析』か。わしも読んだな。関心、関心」
メイビー 「いや無意識に手に取っただけで。昔から埃を被った、誰も読んでいないような本を見ると何となく読んでみたくなるんですよ。でも、構造化設計なら知ってますよ。もちろん実践もしてますよ。最近はC言語でプログラムを開発してますからね。」
セサミアン 「ほう、C言語でプログラム開発すれば構造化設計になるのかね。」
メイビー 「もちろん。GOTO文は使っちゃ駄目というコーディングルールを作ってますから。まあ、一部アセンブラで書いているところは、ご存じのように、しようがないですが。」
セサミアン 「アセンブリ言語を使うと構造化設計は無理かね。」
メイビー 「ブランチとジャンプを使わないとしようがないけど、ブランチとジャンプはGOTO文と本質的に同じですからね。最近はGUI部の開発ではC++を使い出していて、構造化設計だけではなく、オブジェクト指向設計も採用しつつあるんですよ。」
セサミアン 「君はもっと優秀かと思っていたが、他のやつらと変わらんなあ。会社の部長連中はしょうがないとして、会社の担い手がこんな連中ばかりじゃ、この会社も長くないなあ。まあ、わしがやめるまでもってくれればいいか。ホッホッホ!ほかはどんな本を読んどるのかな。どれどれ、UMLやCMMに関係する本か。君じゃ役不足だなあ。」

メイビーさんは、やはり噂通りの嫌なやつだと思ったが、昨日の企画部長の話でむしゃくしゃしていたのと、図書室には他に誰もいないので、いっちょ、がつんと言ってやろうと議論をふっかけることにした。
メイビー 「UMLを使ったオブジェクト指向設計やCMMは最近の考え方で、ご存じないかもしれませんが、我が社もこういった新しい手法を取り入れていかないことには、ソフトウェア開発の競争力をなくなっていくんですよ。」
セサミアン 「ほうほう、その心意気は結構だが、もうちょっと勉強せにゃあ。例えばオブジェクト指向設計は構造化設計よりも古い考え方というのはしっとるかな?」
メイビー 「えっ?」
セサミアン 「まあ、1970年代のファッションがまた大流行するようなものじゃな。服や口紅の今年の流行色と同じで、設計手法に纏わるツールを売る方の都合もあることじゃから。それに、GOTO文を使わずにC言語でプログラムを書けば構造化設計だと思っておるようじゃが、アセンブリ言語を使っても構造化設計はできんことはないわ。」
メイビー 「・・・」
セサミアン 「構造化分析と設計の違いもわかっとらんようだし。」
メイビー 「分析と設計の違い?」

「あっ、ここだったんですか。」
そこにシャル君とウィルさんがやって来た。

シャル 「課長から電子ポット試作の話を聞いたので、面白そうだったのでウィルさんを誘ってさっそくやって来たんですよ。今までとは違う開発手法での開発に取り組むんですって?楽しみだなあ。今までやって来たようなことしか知らないので、いろいろ教えて下さいね。」
ウィル 「私は組込みソフトウェア開発の経験零ですから、よろしくお願いします。でも、徹夜だけは・・・」
セサミアン 「ほう、新しい開発手法での開発をやるのか。それで勉強しとったのか。浅漬け手法か?」
メイビー 「違います。UMLを使ったオブジェクト指向設計を基本として、...」
シャル 「えっと、あなたは?」
メイビー 「あ、セサミアンでなくって、お名前は、...」
セサミアン 「仙人とか、シーラカンスとか、恐竜とか、いろいろと呼ばれておるようじゃが、セサミアンがいいのお。あんまり会社は好きじゃないが。」
ウィル 「へえ、面白い方ですね。私はウィルです。よろしくお願いします。」
セサミアン 「おお、なかなかしっかりしているな。」
シャル 「私はシャルです。よろしくお願いします。」
セサミアン 「頑張ろうな。」
メイビー 「ちょっと待って下さいよ。プロジェクトのメンバーは私とシャル君とウィルさんの3人ですよ。」
セサミアン 「まあ、そんなにわしに気をつかわなくてもよいぞ。」
メイビー 「そういう問題じゃないでしょ。」
ウィル 「なんだつまらない。」
セサミアン 「ホッホッホ!」
メイビー 「シャル君とウィルさん、いいですか、プロジェクトはこの3人でやる。今回のプロジェクトでは、UMLを使ったオブジェクト指向設計を使って試みることにする。同時にCMMの考え方を取り込み組織的に品質の向上を目指す。だから、さっそくこれらの本を読むように。」
セサミアン 「何か特別な電子ポットか?そんな簡単なものにUMLを使ってオブジェクト指向設計でやるのかい?まるで、少ししかない高価なトロをチェーンソーで切り分けるようなもんじゃな。しかも、改善するプロセスさえもまだ影も形もないのにCMMとはなあ。」
メイビー 「はいはい、セサミアンさんは関係ないんだから、引っ込んで・・・」
ウィル 「私はよく知らないので教えて下さい、セサミアンさん。では電子ポットの設計ならどんな手法がお薦めなんですか?」
メイビー 「ウィルさん!」
セサミアン 「そうじゃな、いろいろといい手法はあるのだが、おおそうじゃ、今メイビー君が前に広げている構造化分析、それと構造化設計がよいな。10人くらいまででやる小規模開発で、我が社のような扱う組込み機器が決まっているリアルタイム性のあるものにはピッタリじゃな。」
メイビー 「余計なことは言わないでください。第一、そんな埃を被ったような手法を誰が使うものか。」
セサミアン 「我が社のメンバーは見る目がないから埃を被っておるだけで、世間では使われている。第一、今はやっておるオブジェクト指向設計も構造化分析・設計で足らないところを何とかしようというアプローチと考えて良い。つまり、オブジェクト指向設計も構造化分析・設計を土台としてできているわけじゃ。

だから上手く使い分けてやるのが賢い使い方なのじゃ。お前さんのように、構造化分析・設計をきちんと勉強もせんで、流行だけ追っかけていては、基礎工事をちゃんとしとらん家みたいなもので、そのうち傾くぞ。その点、欧米の企業は偉い。ちゃんと過去の技術を吸収し積み上げてきとる。まあ、確かに構造化分析・設計といっても、それらの教科書は絶版だし、ツールもなくて使いにくいという問題もある。

市場原理からすると、組込みソフトウェアの世界は小さなものだから、組込みソフトウェアに役立つといっても世間の流れに押し流されていくのお。今の流行もどうなることやら。かつ消えかつ結びてじゃな。」
ウィル 「鴨の仙人なんだ。」
シャル 「別名、つれづれ仙人!」
セサミアン
・ウィル
「・・・」
シャル 「冗談ですよ。セサミアンさん、先ほどから構造化分析と設計という言葉がでてきていますが、よくわかってないので教えてください。構造化はなんとなくわかるのですが、分析と設計はどう違うのですか?」
セサミアン 「違いか?メイビーさん、教えてやったらどうだね。」
メイビー 「全く・・・。プロジェクトはオブジェクト指向設計なんだから。分析は、与えられた仕様からどのように作成すれば実現可能かを検討することですよ。

例えば、外部からの入力は割り込みにするのかポートで受けるのか、I/Oは何本必要か、タイマやAD/DA等必要な周辺機能はあるかとか、細かいところではクリティカルな部分のタイミング仕様、大きなところでは製品仕様に規定のある処理性能が出せるか、RAMやROMはどんなものがどのくらい必要かを検討する。

そのために、与えられた仕様を実現するために必要な機能を洗い出し、実現するために特別な機能が必要でないか、入出力のタイミングで実現できそうにないものがないかを考える。また、処理速度や必要なRAMサイズで問題になりそうなところはないか、OSを使うかどうかなどを検討するために、大まかなモジュール構成やそのモジュールをどういう場面で使うかを決めて、速度や必要RAM/ROMサイズを検討するんだよ。

分析で大体の目処が立ったら設計に入って、分析で大まかに分割したモジュールを実際どうやって実現するかを考えるんだ。つまり、データ構造やアルゴリズムの詳細をどうするかを決めていくんだ。ウィルさんには難しいかもしれないが、経験を積んでいけばわかるようになるよ。」
ウィル 「本当に難しそうですね。でも、それだけいろいろと細かなことまで分析していても、この前みたいに最後まで大変なんですね、ソフト開発って。」
メイビー 「それは、後の方になってから、これはこういう意味なんだとか、ここをこう変えてくれとかいうやつがあるからなんだ。」
ウィル 「でも、もうちょっと何とかならないのかなあ。最後の方、みんなひどい顔してましたよ。」
セサミアン 「ひどい顔が目に浮かぶようじゃ。でも、ちゃんと分析と設計の意味するところを理解しとったら、ちとはましだろうに。」
メイビー 「何をいうですか、セサミアンさん。」
セサミアン 「だから君は分析と設計の区別もついていないと言ってるじゃろ。さかりのついた猫じゃあるまいし、仕様が与えられたら飛びついてこれはこういう手順でこうやればいいなあと考えるからいかんのじゃ。分析は対象とするシステムが何をするものであるかを明確にすることが目的じゃ。

具体的にどう実現していくかは後の話じゃ。第一、何がやりたいのかがはっきりしていない時に、本当に必要かどうかがわからんものをどうやって実現しようか考えても無駄じゃろ。それよりも、仕様を決めた者とプログラムを開発する者との間、あるいはプログラムを開発する者たちとの間で、本当に実現したいものを共有する、つまり同じシステムを頭に描けるようにするのが分析の目的じゃ。誰かのように、仕様書のここはこういう意味じゃないんだと後になってから言い合わんようにな。

構造化分析はそのための手法だな。分析でシステムが何をやりたいか、仕様に矛盾がないか、冗長なところがないかと吟味してから、設計で具体的にどのように実現するかを考えるんじゃ。何をやりたいかは分析で明確にして、実現するさいのH/Wによって変わる実装に関係する部分を設計で考える、これにより小さな仕様変更やマイコンの変更などは設計で吸収できるのが理想じゃな。」
ウィル 「分析と設計の違いはなんとなくわかりました。大学で構造化プログラミングという言葉を勉強しました。どれも"構造化"なんですね。シャルさんは構造化という意味はわかっておられるようですが、私はよくわからないので、教えてください。」
セサミアン 富士山「面白い質問じゃな。"構造化"は言わば当時の流行語、接頭詞じゃな。例えば、食品についている"手作り"とか"有機"のようなものじゃ。

"構造化"という言葉が出てくる前は、構造化されていない、つまり余り系統立てて考えられていないプログラムが多かったんじゃ。いわゆる、スパゲッティじゃな。当時の開発言語の問題もあったし、プログラム規模も小さかったのでひとりでやってしまって、他の人がそのプログラムをわかる必要もなかったこともあるし、フローチャートしかプログラム開発の道具もなかったという背景もあるんじゃが。

そんな中で出てきた潮流が、プログラムの流れを見やすく、わかりやすくするために系統的な制御の流れで書くようにしようという考え方が提唱されたんじゃ。その考え方の1つの具体的な技法が、構造化プログラミングかな。

ただ、ひとつだけ注意して欲しいのは、C言語はif文やwhile文といった制御構造を持っているため、C言語を使って書いたプログラムはGOTO文さえ使わなければ構造化プログラムだと言う人がいるけど、もう一度議論の本質に立ち戻って考える必要があるというところだな。構造化プログラミングの重要な点は、プログラムの構造とプログラムを作る過程とを密接に関連させるという立場から、いわゆるトップダウン的なプログラム開発を推し進めることだとわしゃ理解しておる。

つまり、プログラムの持つべき機能を定式化したあと、果たすべき機能に従って大きくいくつかに分解する。そして、分解された各部に対しても、果たすべき機能に従って大きくいくつかに分解するという手順を繰り返して、最後はいわゆるコードに落ちていく。

この分解過程(プログラムを作る過程)がそのままプログラムの構造となって現れるというわけだが、その際の人間の頭で行う分解過程がif文やwhile文で代表される制御構造を用いて考えている(考えるとやりやすい)というところがポイントかな。だから、格好だけをまねても本物の構造化プログラミングとは言えんな。C++を使えばオブジェクト指向設計だというのもしかりじゃ。
どうも日本人は表面しか見とらん。」
メイビー 「ご高説は十分承りましたが、構造化分析の設計はUMLを使ったオブジェクト指向設計よりいいんですか?聞いていると特に差がなく、UMLを使うほうがいろいろと道具があって良いように思いますが。」
セサミアン 「確かに、目指すところは一緒じゃな。
UMLを使ったオブジェクト指向設計は、大規模で開発した経験のあまりないようなシステムを試行錯誤しながら開発するのには向いておるかな。いろいろな分析をするための道具も豊富だし。また、オブジェクト指向という面から一部のサブシステムに以前に開発したものを使おうとする際も便利じゃ。自分たちのドメインで必要となるパーツを上手く部品化できるのなら合っとるな。

しかし、いろいろと道具が多いということは使いこなすのに時間もかかるし、オブジェクトの切り出し方もなかなか難しい。それにリアルタイムシステムへの適用という面でまだまだじゃ。一方、構造化分析と設計は、組込み機器が扱うリアルタイムシステムへの適用の仕方もかなり確立されているし、また組込み機器の設計にも相性が良い。

例えるなら、宇宙船の設計には量子力学は必要だが、家庭で使う踏み台を作るのには古典力学で十分だろ。そんなもんじゃな。どちらも重要だが、適材適所じゃ。UMLを使ったオブジェクト指向設計でシステムを分析して、あるレベルのサブシステムまで機能分割できれば、その先は構造化分析・設計に切り替えた方が良いかもしれない。まあ、その辺りは経験じゃな。」
ウィル 「私には構造化分析・設計が向いてそうですね。勉強して損にならないし。」
シャル 「そうだな、善し悪しは自分で判断出来なきゃ。それに先生が適していると言ってるんだから、やってみるか」
メイビー 「おいおい、誰がセサミアンに教えてもらうと言った。プロジェクトは3人で、...」
セサミアン 「いつも企画部門がざるのような仕様を出してきて、最後に、設計が仕様を誤解していると難癖付けてると言っていたと企画部長に言ってやるぞ。シャル君とウィルさん、時間あるかな、さっそく勉強を始めようじゃないか。メイビー君も時間は取れるだろ。」

本編へ続く