システム開発とは

creation date：2002/12/28
last update date：2003/1/8

はじめに

まず、ここでいっているシステムとは、販売システムとか生産システムとか経理システムなどの、企業活動において利用する業務アプリケーションのことです。セブンイレブンのPOS端末（商品のバーコードにあててピッと音を出して買物金額を合計する-->それだけではありませんが....）や、銀行のATM、インターネットのオークションサイトなども利用する人が違うだけで同じようなものです。ですから、どんな人にとっても身近なものですね。

一から作る場合もありますし、できあいの物を使うという場合もあります。こんな流れになります。

「企画」→「設計」→「コーディング」（できあいの物を使う場合は「設定」）→「テスト」→「移行」→「利用（運用）」

これの繰り返しです。

システム開発というと、多くの場合、「設計」→「コーディング」→「テスト」の部分にあたることになります。「企画」から参画する場合もありますし、「移行」にも深く関わることが多いですね。また、作ったシステムの「運用」を受託してお金をもらうことも、ソフトハウスにとっては大切な業務分野です。

筆者の勤めていた企業

僕が勤めていたのは、某大手メーカーの子会社でした。親会社は大手なので、事業部毎に工場を持ち、それぞれに情報システム部（IS）を持ち、子会社も持っていました。本社にもISがあり、そのISの子会社が僕の勤め先でした。そんなわけで、顧客は、親会社事業部の場合と、子会社（親会社の）の場合の二つしかありませんでした。僕は、子会社を相手にする部門にいました。

子会社もいろいろなので、しっかりしたISを持っているところもあれば、数人で賄っているところもあります。大きな違いは、自分で企画できるかどうか、自分で運用できるかどうかです。数人で担当している会社の場合、ISはほとんど何もしていないというのが実感です。むしろ何もできないから、親会社から追い出されたという印象を僕は持っています。そういうところでは、上司は、煙草をぶかぶかふかしながら、ペチャクチャ勝手なことを喋り、部下が細々と雑用(データをFDに吸い上げるとか、帳票を部門毎に仕分けするとか)をこなすだけで、本来の業務を行っていません。

そのような、ISの力の差があるとしても、先の「設計」→「コーディング」→「テスト」の手順においては、「設計」と「テスト」の関わり具合が違ってくるだけで、手順そのものは同じです。

システム開発の作業

さて、3つの段階のうち、「コーディング」だけは受託したソフトハウスの中だけでできます。そこが駄目となると、ソフトハウスでいる資格がありません。決められた仕様通りにプログラミングするだけだからです。プログラミング言語は違えど、そこはプロとしてしっかりしなければなりません。むしろ、難しいのは、「設計」、「テスト」の部分なんですね。

設計

設計の段階では、ユーザと顔を突き合わせて話をします。ユーザは、あーしたいこーしたいと思っているわけです。それも、人それぞれです。その話を聞いて、情報システムに落とし込む作業をするのです。

PJ会議の参加者は、それぞれが自部門を代表してきているので、自部門の利益を考えたシステム化を主張します。ISがしっかりしている企業なら、それを自分でまとめてからソフトハウスに発注しますが、しっかりしていない零細ISであれば、まとまらないうちからソフトハウスを呼び出します。そうなったら、とにかく時間がかかってかかって大変です。ソフトハウスには決定権がないので、「そんなことをすると処理に時間がかかります」とか「その場合、工数が嵩んで費用が増えますけど」とか「それによってどれぐらい省力できますか？それはシステム化費用に見合いますか？」とか、そういった話しかできないのです。そういうやり取りをしながら、どうにかこうにか仕様を作るのです。

テスト

テストですが、仕様通りにできたかどうかという意味合いでのテストはソフトハウス内で完結します。そうはいっても、なかなかきちんとできないこともあったりしますが、それは完全にソフトハウスの責任です。問題は、ユーザと話し合って決定したはずの仕様がよろしくないことが多々あることです。仕様通りかどうかのテストを繰り返し、ユーザにテストをしてもらった途端、不具合が発生することがあります。それはそれは、恐ろしいものです。「動かないんですけど、どうなってるんですか？」などという電話がかかってきます。調べてみると、接続されないはずの内容のデータが接続されていたり、ボタンを続け様にクリックしたり、画面が止まってしまったから（遅くなると警告していたのに....）といってリブートしたり、マスターデータの登録が不備だったりといったことよりも、仕様がきちんとしていないという問題が大きいのです。仕様にないことはできないのがコンピュータシステムなのです。急に「こういう場合は、こうならないと困ります」と言われても、設計段階では、そんな話はなかったのですから。