SE年収1000万までの道のり

パソコン初心者の僕が年収1000万を超えるまでにしたこと。仕事、転職、独立、副業、投資など。

*

開発プロジェクトの失敗例、今思う反省点

      2016/03/20

SOFTHOUSE_VOL010

結合テストが終わり、いよいよ客先での受入テスト(顧客検収)が始まりました。

 

この受入テストをクリアして、顧客から検収印を頂くことが出来れば、この辛かったプロジェクトもやっと終わりになります。

 

このプロジェクトにアサインされてからというもの、連日の残業と休日出勤で僕はかなり消耗してましたので、

僕(この検収さえ貰えればこの地獄から解放されるぞ・・・。)

僕(人間らしい生活を取り戻すんだ・・・。)

なんてことをマジで考えていました。

スポンサーリンク

受入テスト(顧客検収)の概要

このテストは顧客企業(機械部品メーカー)が主体となって進めるもので、顧客側は予め実業務に沿ったテストシナリオを作成しておきます。

 

実際のテストは、コンサル会社、情報システム部門、実際に使うユーザーの3者が行うというものです。

【物欲とモチベーション】年収3000万のITコンサルタントの自慢話

 

テストシナリオはマスタ登録から始まり、トランザクションの入力、日次バッチ実行、月次バッチ実行、年次バッチ実行と、仮想日付を変えながら1年間の運用を模して行っていきます。

 

僕らベンダー側の役割分担は、リーダーと、ベテランSEの2人は顧客のテストサポートを行い、障害対応は僕と先輩の2人が担当することになりました。

 

プログラムは外部ベンダーに請負で作ってもらったので、本来であれば仕様変更ではない純粋なバグは瑕疵担保責任の範囲で修正させることも出来たのですが、その進め方をすると仕様変更かバグかを切り分けた上で、仕様変更もその外部ベンダーに修正させる必要が出てきます。

(別会社が触ったソースは瑕疵担保責任の対象外になる為。)

 

そうなると見積依頼して発注して検収して・・・と、障害の解決に多くの時間がかかってしまい、1ヶ月の期間内で検収を貰えなくなってしまいます。

なので、仕様変更やバグに関わらず、テスト中に発生した障害は全てその場で僕らが直すというスタイルになったのです。

受入テスト(顧客検収)開始

さて、僕たちはテストが始まる前に顧客中心となって作成したテストスケジュールを見せてもらいました。

 

スケジュールはかなり緻密で、所々に予備日まで設けられていた為、僕は

「あまり残業しなくても平気かな?」

と甘い期待を持ってしまいました。

 

しかし、実際にテストが始まってみると僕の甘い期待は一瞬で崩れ去り、そのテスト部屋は阿鼻叫喚の地獄絵図になりましたw

 

コンサルA「例外発生っていうメッセージが出たよ!」

リーダー「障害表に記載して対応致します。」

 

コンサルB「IMEの制御おかしくない?入力し辛いんだけど。」

ベテランSE「障害表に記載して対応致します。」

 

情報システム部門A「このデータって一度入れたら直せないの?間違えたらどうすんの?」

リーダー「そうですね・・・、障害表に記載して・・・。」

 

ユーザー部門A「例えば、xxxっていう業務もあるんだけどその場合はどうすれば良いの?」

リーダー「えーと、それは・・・。」

ユーザー部門A「それ出来ないと困るよ!業務回らないもん!」

リーダー「はい、障害表に・・・orz」

 

と、僕達のシステムはフルボッコにされましたw

 

そして、修正が難しい障害は先輩が担当し、修正が簡単なのは僕が担当しました。

それでも障害表の件数は留まるところ知らず、日々増加し続けました。

当然稼働時間は最高潮に達しました。

 

そんなある日、僕は別会社のベテランSEが何かの錠剤を飲んでいるところを見てしまったのです。

秘密兵器投入

カプセル

僕「何飲んでるんですか?」

ベテランSE「眠いからモカジョウ飲んでたんだよー。」

 

僕「何すか?それ。」

ベテランSE「SEなのにモカジョウ知らんのかー。」

ベテランSE「エスタロンモカっていうカフェインの錠剤よー。」

ベテランSE「眠い時これ飲むと一気に眠気飛ぶんよー。」

 

僕(マジ?!)

僕(そんな素晴らしい薬があるのか?!)

 

連日の残業で寝不足だった僕にとって、眠気が吹っ飛ぶ薬というのは非常に魅力的に映りました。

 

ベテランSE「タカ君も食うかい?」

僕「はい!是非下さい!」

ベテランSE「そかそかー、沢山あるから1箱全部あげるよー。」

僕「ありがとうございます!」

 

この効き目は抜群でした。

一瞬で眠気が吹っ飛ぶ上に、やたらと頭が冴えてくるのですw

そして僕は、この薬の虜になり、少しでも眠くなるとまるでラムネでも食べるかのようにパクパク食べながら障害対応をしていました。

 

※注意

これは飲みすぎると中毒症状が出るので、もし飲むなら(必ず用量を守った上で)人生ここが正念場というところで悪魔と取引するつもりで飲みましょうw

【第3類医薬品】 エスタロンモカ12 20錠

価格:236円
(2015/8/24 00:16時点)
感想(0件)

受入テスト終了

そんなこんなで1ヶ月が経過しました。

頑張った甲斐あって、全てのバグは先輩と僕で潰し終わっていました。

しかし、機能の欠落など明らかな仕様変更で、見積もりからやらなければならないような課題は大量に残っていました。(そもそも業務分析から間違いだらけだったってことです)

 

これらの残課題は直ぐには対応出来ないので、一旦リリースを見合わせて、今後少しづつ対応することになりました。

 

これでは出来損ないのシステムなのですが、僕は既に次のプロジェクトにアサインされることが決まっていたのでこのタイミングで抜けることになったのです。

今思うこと

青空

残念ながら、このシステムは運用に耐えられる代物ではありませんでした。

 

エンドユーザーがテストの時に言った言葉が忘れられません。

「このシステム使わなくても良いんだよね?」

「使いたくないんだけど・・・。」

 

さて、結局リリース出来なかったこのシステム開発プロジェクトですが、進め方などに沢山の問題点がありました。

細かい所は置いといて、大きな点に絞ると次の3つだと思います。

 

  1. エンドユーザーの参加がシステムが完成後。
  2. 上流工程を担当したSEの業務知識が少ない。
  3. 受注金額(見積工数)が少ない。

1.エンドユーザーが参加がシステムが完成後

要件定義や基本設計といった上流工程のフェーズで、ユーザー部門は殆どノータッチでした。

では誰と仕様を決めたのか?というとになりますが、コンサル会社と情報システム部門が主導で決めたのです。

もちろんユーザー部門に対するヒアリングはしていたと思いますが、いざ納品してユーザーが使ってみたら全然使い物にならないシステムだったのです。

 

ただでさえ現場のエンドユーザーは変化を嫌がるものです。

今まで使っていたシステムの方が使い慣れていますし、それで日々の業務は回っています。何故わざわざ新しいシステムの使い方を覚えなければならないのかと思うのは当然ですね。

 

本当は上流工程のフェーズから、仕様に対する責任をもつ専任の担当者(ユーザー部門)をアサインして貰うのが良かったんだと思います。

そして、その担当者からユーザー部門全体に対して新しいシステムを導入するメリットを納品前に浸透させておけば割とスムーズにリリースから移行まで出来たのではないかと思います。

まあ、納品後の検収で初めて見て、障害だらけじゃ拒絶反応が出るのは確実ですね。

 

後はコンサル会社と情報システム部門の言いなりになって、現場の声を聞こうとしていなかった僕らベンダーのスタンスにも問題がありました。

まあ、金だけくれれば何でもいいって考えなら別に問題ないのでしょうが・・・。

(このSIerの営業はそんな考え方してましたね。)

2.上流工程を担当したSEの業務知識が少ない

これも今になって思うことですが、リーダーやメンバーの業務知識が少なかったのも問題だった思います。

 

僕自身は勿論のこと、リーダーや他のメンバーも製造業は初めての業種でした。

いくら経験豊富なベテランSEでも、知らないジャンルのシステムを設計することは出来ませんから、必然的にコンサル会社や情報システム部門の言いなりになるしかなかったのです。

もちろん、こちらからの提案なんて絶対出来ません。

 

じゃあどうすれば良いのか?

 

契約前のコンペの際、営業はきっとこう言った筈です。

営業「弊社は製造業の顧客を多く抱えており、システムの導入実績はxx社にも上ります!」

営業「また、会社やグループ全体でのサポート体制もあり、全社一丸となって御社の課題を解決します!」

とかw

 

しかし、会社の導入実績とかサポート体制とか、そんな事よりも実際にアサインされるPMやPLの業務知識の方が遥かに重要です。

何故かというと、会社とかグループ全体のサポート云々はセールストークで、実際は皆んな別プロジェクトにアサインされていて誰も助けてくれません。

 

なのでコンペの際は必ずPMやPLといった技術者にインタビューしましょう。

形式だけのものではなく、相手が自社(その業種)の業務をどの程度把握しているかを意地悪な質問をしてでも計った方が良いと思います。

 

その際、営業が何か上手いこと言うかも知れませんが、そんな営業トークはシカトして下さい。

3.受注金額(見積工数)が少ない

このプロジェクトは作業量に対してお金がなさ過ぎました。

 

営業がコンペで何としても受注する為に、ろくな見積りもせずに出した金額だったのです。

ユーザが言ってました。

「お宅の会社だけ他社と比べて見積金額がかなり安かったです。逆にそんなんで作れるのか心配になりましたよw」

と。

(残念ながら予感的中です・・・。)

 

安くて良いシステムは作れない。と僕は全く思いません。

 

しかし、何故安いのか?

その理由を理解してないと必ず発注側も痛い目にあいます。

 

例えば、家を建てる時に他社よりも安い工務店があったとして、その理由が、

「うちは人件費の安い未熟な大工が建てます。」

とか、

「うちは材料費を抑える為に強度の劣る細い柱を使います。」

とかだったら絶対発注しませんよねw?

 

逆に、

「うちは工場でパーツを大量生産することで材料費と組立工数を抑えてます。」

とか、

「口コミだけで顧客から直接受注してるので中間マージンや宣伝費がありません。」

とかなら安くても安心して発注出来ますよね。

 

それと同じように、システムも安いのは安い理由が必ずあるものなのです。

その理由が見積もりの甘さや、安い人件費だとしたら、必ず品質にはね返ってきて痛い目にあいます。

 

このプロジェクトの場合はそこが見抜けなかったんだと思います。

もしくは見抜けてても経営者が値段だけで選んでしまったとか・・・。

でも、それなら自業自得ですかね。

 

あとは、事業会社の情報システム部門(社内SE)は、新卒を取らずにベンダー上がりの中途を採用するのが良いと思います。

大工が家を買うようなもんですから騙されたり失敗するリスクは減ると思います。

 

僕が1人で勝手に思うこのプロジェクトの反省点はこんな感じですね。

レベルアップ

  • バグ対応をする中で少しコーディングに慣れた。
  • イチ作業者として一つのプロジェクトを経験した。

 

次の話⇒基本設計が出来ないSE

 - 中小ソフトハウス時代 ,