簡単にシステム開発の流れとはどういうものなのかを説明しておきます。
- 1)お客さんの要件を聞きます。
- …なにをシステム化したいか、どういう機能にしたいか
- 2)見積もりを出します。
- …いくらかかるのか、どういう機器やソフトウェアが必要か、 それを開発し運用が始まったあとのサポートまで、考えて金額を出します。
- 3)それで受注ということになれば概要設計に移ります。
- …処理をおおまかにわけて図などに書きます。
- 4)詳細設計をします。
- …概要設計でわけたのをさらに細かくし、プログラムで作る処理に近付けます。
- 5)開発します。
- …開発ツールを使う、手でコードを打つ、などでプログラムを作ります。
- 6)テスト
- …細かい部分からテストしていき、最後にシステム全部を統合してテスト。
テスト仕様書などに基づいて厳しくチェックします。
- 7)仮納品、客先でのテスト
- …お客さんに使ってもらって、テストしてもらいます。
- 8)本稼動、サポート
- …無事正式に使ってもらいます。
なお、当時の話なので今はどうかわかりませんよ。
さて、4課でサポートしていたあるお客さんで、開発の要件が出てきました。
私が担当していたところなので開発も私が担当に。ただし開発は初めてなので
設計などはすべて先輩の森川さんがやることになり、森川さんと二人のプロジェクトです。森川さんに、
「○○さんなら大丈夫だよ。俺より頭いいもの」とか適当なことを言われて、
開発することになったわけですが。
システムの要件は、こうです。
(この当時よりさらに)大昔のコンピュータで動いている、ある
業務システムを、Windowsで動作するように移植してほしい。 いくつか動かない機能があるので、それを直すのと同時に、機能追加して
CUIからGUIベースにしたいとのこと。 (CUIとGUIの説明はこちら)
この要件を聞いて、森川さんは、
- 昔の言語からVisualBasic(以下VB)に移行する業者があるので、そこに外注し、現状のままコンバートしてもらう。
- CUIベースのままWindowsでの動作を確認する
- 動かないところの原因をさぐり、修正する
- GUIベースにするなど機能追加する
という手順で開発し、開発期間は8ヶ月くらいだろう、と設定し、 見積もりを出し、受注しました。
ところが、このプロジェクト、結果的に1年半ぐらいかかったでしょうか。落ち着いたのは
2年ぐらいしてからです。
まず、aの段階で、つまづきます。 このシステム、お客さんのところの社員が、趣味でコンピュータの勉強の
かたわら作ったものだったのが間違いの始まり。(しかもその社員はもういない)
外注した専門の業者の、コンバートツールすら通らない超汚いソースプログラム。
(多少プログラムの分かる人には、go toの嵐だといえば解っていただけるでしょうか)
外注さんから聞かれてもとのソースを私が辿る日々。お客さんに 「この○××△登録というのは、どういうことをするんですか」と聞いても
「使ってないからわからない」との返事。 ソースを追って機能を知るしかないんです。お陰でソースを読む能力がつきましたが、
誰も使っていない昔の言語なので、スキルがついても別にうれしくない。
やっとbの段階に辿りついて、今度はVBのソースを読むことに。これが、また大変でした。
コンバートツールの吐き出したソースが汚いのなんの。 もともと汚いソースを、
無理矢理コンバートしたものだから、さらに酷いことになってました。 さらにそれにコンバートツールのバグまで大量
に襲ってきます。元のソースは正しい、なのにコンバートしたのは間違っている、と。いちいち外注業者に修正を頼むと遅くなるので、報告だけして自分で直します。
間に合わないので、バグの修正と同時に機能追加もすることになりました。cとdは同時進行です。ぐちゃぐちゃのプログラムにむりやりねじ込まなければいけません。しかも、CUIベースの線形な処理と違って、GUIはイベントごとに
処理が発生するわけで、プログラムのつくりが全然違う。 大変でした。いくら開発経験のない私でも、
最初から作り直したほうがよかったんじゃないかと思いはじめました。
このへんから、お客さんから機能追加の注文が増えます。
「○○に削除機能をつけてほしい。削除機能がないと意味がない」
「○×もできるようにしてほしい」
当初の追加機能が倍くらいにふくれあがりました。 もとのシステムは素人が趣味で作ったものですから、矛盾していたり、これがないと
おかしい、というようなものがたくさんあったのです。(例えば追加があるのに削除がないとか)
「そういうのは当初なかったと言って断るか、お金をもらうんでしょう?」とお思いでしょう。
ですが、森川さんは「わかりました」と言って受けるのです。そういうものらしいです。
「お客さんは多少納期が遅れてもいいっていってるから」といわれました。
ところがその森川さんの設計ミスもいろいろ出てきて、出戻り作業が 何度もありました。こういうののしわ寄せは、全部私一人にきます。
帳表印刷系がこのシステムの主な機能なのに、それをVBでやろうとしたのも余計な困難の一つです。当時VBは出たばかりで帳表系の実績やツールもありません。帳表系は不得意だと言われていました。(今はどうなのでしょうか?)やっとツールを見つけてそれを使うと、そのソフトも出たばかりでバグだらけ…。
すでに半年すぎてました。もうヤバいとやっとわかったのか、森川さんはチーフに相談し、機能追加の
一部を外注することが認められました。
開発のピークでは、私の帰宅は毎日日付けが変わってからでした。土日も出ました。
疲れて、疲れて、 なんで、こんなぐちゃぐちゃなソースと毎日格闘しなければならないんだろう。なんで、自分が悪くないことにこんなにふりまわされなきゃいけないんだろう。
もうやってられない気分でした。
このとき何度も「もういや!」とトイレで叫んでたのを思い出します。
こんな赤字プロジェクトをやって、社内で問題にならないのか?とお思いでしょう。
ならないんです。なぜかって?私はお金上は別の仕事をしていることになってたからです。
毎月どんな仕事をやったかを表に書きますが、その表の上では、お金の余っている
他のプロジェクトをやってることになってました。 これはT社全体でごく普通
にやっていたことです。親会社のT社に出向していた 人は目を丸くしていました。「そんなこと、やっちゃいけないことでしょ?!」
こうして、問題はちっとも表面化せず、ただの成功した一例となってしまう。失敗の経験は
担当者以外に生かされません。
これが、大企業SE会社の実態です。 ま、別に珍しいことじゃないでしょうけど。
|