本文へスキップ

業務の可視化と現場の知恵を共有する「仕事のプラットフォーム」

TEL025-531-1151

〒942-0036 新潟県上越市東中島1943-91

可能性をデザインせよ!

こんな体験から 炎上プロジェクトに参加して作り直しを提案!

システム開発での設計の重要性を感じた体験


独立して2年目の頃だったと思います。

独立して、フリーのSEをやっていた時のことです。
システムの大切さを実感した体験でした。
この体験で、仕事の仕組みや人とのコミュニケーションの
大切さ、難しさを実感しました。

こんなことから始まりました..
COBOLのシステム開発の次の仕事まで1週間空いていて、
コタツに寝転んでテレビを見ながらミカンを食べていると..
東京のソフト会社の社長から電話がありました。
(新潟に帰る前に、その会社でCOBOLのプログラマーをしていました。)

プロジェクトが大変に事になっている「すぐに来てくれ!」
そこで、急いで支度をして東京に向かいました。
浜松町の駅の構内で待ち合わせをして打合せに参加しました。

まさに炎上プロジェクト..
大勢の人が、打合せをしています。
初参加で状況がつかめないので、様子を見ていました。
バグ(プログラムの問題)が、現在何個あって、修正何個で
残りをどのくらいの期間で改善するかを打ち合わせています。

バグの個数なんて数えても意味ないのに..
システムの問題はどうなの?
などと、初参加なので第三者的に見ていました。

翌日から、炎上プロジェクトに本格的に入りました。

分厚いコクヨのファイルを手渡されました。
綴じ込んである仕様書をどんどん読みこんで行きました。

でも、どれだけ読んでもシステムの構造が見えてきません。
プログラムの一本づつの仕様書はしっかりあるのですが、
それが、どう繋がっているのかが見えません。

このシステムは..
私が、東京でプログラマーをやっていた頃の先輩がかかわったはずです。
しっかり設計する人でした。
システムを体系化するべき資料の内容が薄く、中身がありません。
信頼できそうな資料は、プログラムの仕様書しかありません

彼なら、もっとしっかり資料を作りながら設計するはず???
どうしたんだろうと聞いてみました。

すると、先輩は途中で病気になって設計ができなかったとのことです。
そこで、結構いい加減な方の先輩がPG会社に丸投げしたとのことです。
だからか..納得です。

私の方は、直接プログラムの修正にはかかわらず、
たくさん集まって深夜まで作業をしているプログラマーとの調整役を
やりながらシステムの全体像を理解する作業をしていました。

でも..
どれだけ仕様書を読みこんでもシステムの構造が見えてきません。
システムとして機能しているのか、疑問です???

当時33歳、まだまだ若かったです。
提案はストレートです。
今のプログラムの集合体を、修正してもシステムにならない。
「捨ててゼロから作り直しましょう」と提案しました。

私の所属する会社の上に、2社ありました。
上も偉かったです。
すぐにOKとなりました。

受注の構造は
 A社:顧客から受注した会社
 B社:丸投げした会社
 C社:私の所属する、システム設計をした会社
 D社:プログラムを開発した会社

ただ、新規にシステムの開発をするとなると時間がかかります。
ただ、まったく何も動かさないというわけにはいかないようです。
そこで、現行システムの改修を続けるふりをしながら、
時間稼ぎをしてもらい別の部隊を編成して新規開発をすることになりました。

時間稼ぎの部隊は、
モグラたたきのようにバグが減って増えての、不毛な作業の繰り返しです。
システム設計がしっかりしていないとこうなるのです。
彼らも、うすうす勘づいていたようですが..
文句も言わずに不毛な作業を続けてくれました。
頭が下がります。



この体験で、システム設計の大切さを実感しました。

プログラマーは指示通りに一生懸命に頑張って開発します。
でも、使えないシステム、役に立たないシステムと言われます。
役に立たないと言われます。
プログラマーの努力は、同じなのです。

全て、システムの設計が原因です。
その設計のもととなるのが、「要求定義」です。
経験の浅いSEは、これをしっかりつかむことができません。

エンドユーザーが口で言ったことをまとめて、
それを「要求定義」としまいます。
本当は、口で言っていることと望んでいることが違うのです。

  口で言っているコト ≠ 望んでいるコト

システム設計をするSEには、これを理解して欲しいと思います。


新規開発のシステムは、とても大変でした。
1月中旬に、新規開発のGOがかかりました。
そこからシステム設計をはじめて..
2月の初旬には、順次プログラムの仕様書を完成させ、
プログラムを開発してくれるG社に渡さなければなりません。

そして、3月末には
日次・週次のプログラムを完成させテストもして
4月に本稼働させます。

その上、
4月中には月次のテストを行い
末には月次のプログラムの本番稼動が待っています。

厳しいけれど力が付く体験でした。

新潟にいて設計していたのですが..
一番困ったのがあります。

受注構造の上の、A社・B社への状況説明です。
各担当者に毎朝電話で状況説明をしなければなりません、
その上、その担当者が自分の上司に報告できる
明るい話題を提供しなければなりません。
それがないと担当者は電話から解放してくれません。

その上..
時々、彼らの上司にも電話連絡が必要です。
ほぼ毎日、午前中が電話でつぶれます。

こんな短納期のシステム開発をしているのだから、
設計に専念させて欲しいと思っても放してくれません。
「できるのか、大丈夫なのか?」を常に求められます。
まあ、仕方がないことです..
彼らにも、彼らの立場も責任もあります。

隠れ蓑にしている炎上プロジェクトの方は..

COBOLのSEやプログラマーを入れられないので、
自動販売機やエアコンなどの制御システムを開発している
人当たりの良いSEにリーダーになってもらいました。

モグラたたきのようなブログラムの改修を続け、
バグの数を数え工程表を作り、
何も知らないB社のF担当部長に報告してもらいます。

彼は、制御システムを開発しているSEなのでCOBOLや
事務処理はまったく分かりません。
報告を受けているB社のF担当部長も開発のことは分かりません。

何も分からない2人が、一生懸命に話をしています。
はたから見ると、笑い話で漫才のようなやりとりです。

でも、組織運営には大切な事でした。
彼は、一生懸命に防波堤の役目を果たしてくれました。
ありがたいです。
厳しい役割を担当してくれた彼には、
終わった後に、たくさん飲んでもらいました。


こちらも綱渡りのような日々が続きました。
予定通り仕様書を作成して渡し..
まさに超特急でプログラムを作ってもらわないと
3月にテスト、納品、4月の本稼働はできなくなります。

プログラマーの男の子たちも辛くなると言い逃れします....
言い訳、責任転嫁、上司が..こんな無茶な..
でも、仕方がありません。

無茶苦茶な工程で、プログラムを作れと要求しているのです。
お酒を飲ませながら、文句を聞いて..
大忙しの毎日でしたが、とても刺激的でした。



この体験が頭に入っていて、この図解になりました。

なぜ...
 ・システム開発が失敗するのか?
 ・仕様変更が多いのか?
 ・言った聞いてないのトラブルなのか?
 ・システムが使えないのか?

実は..
事業運用をオペレーションレベルに展開しないままに、
システム開発をしてしまうことにあります。

入力画面や出力を決めても..
それを使って、いかに日々の仕事をこなすのか?

オペレーションレベルまで突き詰めた創りこみをしないで、
専門家だから、プロだからと...
コンピュータの専門家に、業務運用の仕組みまで
丸投げにしてしまうことが問題なのです。

この体験で、鍛えられシステムの設計の大切さを実感しました。
今の仕事の仕方にも大きくかかわってきました。

余談ですが..
一番上の顧客から受注しているA社の担当者と
深夜にシステムのテストをしていた時のことです。

深夜に、こそっと缶ビールを手渡してくれて、
誕生日を祝ってくれました。
3月26日が誕生日だったんです。

嬉しかった.. (*^_^*)



こんな体験から 一覧へ 

バナースペース

有限会社 テオリア

〒942-0036
新潟県上越市東中島1943-91

TEL 025-531-1151
FAX 025-531-1152
info@teoria.co.jp