プログラムはどうやって作るものか

もしあなたが「ソフトウェアってのはプログラマがパソコンに向かってカタカ タとキーボードを叩いてプログラムを打つもんなんだろ？それ以外に何がある？」 という認識でしたら、この作業は「コーディング」と呼ばれる作業で、全体の 開発の中では2割〜3割程度の作業量でしかない事を申し上げておきます。

上のような認識しか持っていない人はソフトウェア開発の場ではトラブルのタ ネになります。そんな人がもしマネージャだったら「おいお前ら、プログラム はいったい何行書いたんだ！？そんな所でしゃべってないでパソコンに向かえ！」 と言って設計に関する議論をダメにします。逆にもしプログラマだったら、自 分のパソコンにこもりっきりで毎日何やらキーボードをカチャカチャ叩いてい て、納期間際になって全く見当違いのものを意気揚々と持ってきます。こんな トラブルメーカーにならないために、まず「ソフトウェア開発はコーディング だけでできるものではない」ということを頭に入れておいてほしいのです。ど ちらかというとコーディングはおまけみたいなものなのです。

ではソフトウェアは本当はどうやって作るべきかというお話をしましょう。

要求分析

ソフトウェア開発の出発点はどこでしょう？それはプログラムファイル を作って一文字目を書き始めた時ではなく、「こんなソフトを作りたい」ある いは「こんな事がソフトでできればいいな」と思った時点からです。この時点 からソフト開発の第一フェイズである「要求分析」に入ります。要求分析では、 まさにこのソフトでどんな事をしたいかという「要求」をはっきりさせます。 自動車で言えば、「街乗りに便利なスモールカーを作ろう」というようなコン セプトデザインの段階です。

これはソフトウェア会社ではなく顧客がやるものだというイメージがある かもしれません。例えば「ウチの店の品物の在庫管理をやるソフトを作ってく れんか」とソフトウェア会社へ注文が来た場合です。ここで「顧客の要求ははっ きりした。さあさっそくソフトを作ろう」となってしまいがちです。しかしこ れは間違いです。顧客の要求をもっとはっきりさせなくてはならないのです。

顧客の要求は「こうこうこういう物に対して私は○百万円払います」というい わば契約のようなものです。これをはっきりさせないままうやむやのうちに契 約をすませてしまっていいのでしょうか？例えば「在庫管理ができるソフト」 とだけしか言っていなければ、極端な話メモ帳でもできないことはないわけで す。メモ帳をはいっと渡されて○百万払わなくてはならないのでしょうか？

ただこういったいい加減な契約で得をするのは顧客ではなくソフト会社側なの で、ソフト会社側での危機感というのはまったくありません。可哀想な素人は だまされて泣き寝入りするのが常です。ソフト会社側もこうした悪徳商売 をやめてまっとうな商売をすべきです。

ソフトを作る場合には、まず要求分析をして「要求仕様書」を作成します。こ れは「ここに書いてある項目だけを実現すればいいですね」という顧客とソフ ト会社双方の取り決めみたいなものです。これがすべての出発点になります。

仕様分析

どんな事ができるソフトが作りたいのか、その要求がはっきりしたら、次にそ のためにどういうソフトを作らなければならないのかを考えます。これが「仕 様分析」です。例えば「店の在庫を管理したい」という要求だったら、在庫と してどういうデータを持っていなければならないか、そしてそれをどんな画面 に表示すればいいか、といった事です。

仕様分析フェーズでは、最終的にソフトウェアの仕様ができます。 仕様というのは、ソフトを起動するとどんな画面が出てどこのボタンを押 すとどういう動作をして……という、ソフトウェアの動作を規定したものです。 この仕様通りに作りさえすれば、誰に作らせても同じ物ができてくるはずのも のです。

請負開発の場合には、要求仕様書をもらったら仕様書を客先に出して「これで いいですか？」と確認します。仕様書は要求に対する解答であるからです。そ して仕様書が納得のいくものだったら、あとは顧客はソフトの完成をただ待っ ていればいいのです。仕様書の通りに動くソフトができてこれば何の不満もな いわけですから。出来てきた物にヘンな動作があったら「ここはこの仕様書の 通りに動くはずだっただろう！これはおかしい！契約違反だ！」と文句を言う ことができるわけですし、逆に顧客側が仕様書通りの動作に不満だったら「そ れでは追加契約といたしまして○万円……」とやればいいわけです。

仕様分析を甘く見てはいけません。これは大ざっぱに言って全工程の3割を費 す非常に手間のかかる工程です。そしてその成果物は残念ながら単なる書類で す。だから多くの場合これをすっ飛ばしてすぐプログラミングにかかってしま うのです。少しでもプログラムが動いた方がうれしいし見栄えがするからです。 しかしその誘惑に負けてはいけません。

設計

仕様が決まってしまえば、あとはソフトを作るだけです。そのためにまずは 「構造設計」を始めます。構造設計ではソフトをどう分割して、それぞれにど ういう機能を持たせたらよいかを設計します。ソフトウェアをいくつかの部品 に分割し、さらにそれを分割し……というように再帰的に全体を部分に分割し ていきます。それが終わったら次は詳細設計です。それぞれの部品について実 現方法を考えます。

構造設計は、自動車の設計に例えるとエンジンやブレーキといった部品を組合 せて車体を設計する事にあたります。そしてエンジンそのものを開発するのが 詳細設計です。これらの成果は最終的には「設計仕様書」となります。

コーディングとテスト

ここまできて、やっとコーディングに入ります。プログラマが設計仕様書を見 てそれをCやJavaなどのプログラミング言語で書き下すのです。そしてそれぞ れのソフトウェア部品ができたらまずは単体でテストします。関数にいろいろ なテストデータを入れて呼び出してみて、ちゃんと規定通り動くかをテストす るのです。自動車で言えばエンジンテストやブレーキテストにあたります。

それぞれの部品ができたら、次はそれらを組合せていよいよ完成です。しかし 完成だからといって大喜びで帰ってしまってはいけません。完成したソフトウェ アがちゃんと動作するかどうかテストしなくてはいけないのです。完成した自 動車をサーキットや公道でテストするように。これを「結合テスト」あるいは 「全体テスト」と呼びます。

テストが済んだソフトウェアはようやく出荷となります。出荷時にはパッケー ジングをするとかマニュアルを作るといった付随の作業が必要になることも あります。