ベンダーSE時代に味わった最凶の炎上プロジェクト②

外部設計を終え、お次は内部設計。

ここで、H社独自フレームワークとプログラム自動生成ツールが登場。
これがあるから、短納期で開発できますよ・・・という売り込み方だったらしい。

で、内部設計に先立ち、私がこれを使ってサンプルプログラムを開発してみることに。

使い勝手にクセありすぎ。(汗)

色んなSIerが、自分達独自のフレームワークを生み出したせいで、プロジェクトごとにいちいちフレームワークの使い方を覚えなければならないというのは、本当に非効率です。
しかも、当然ネット等には情報が一切無いので、自分で調べようにもその手段がありませんし。

おまけに、自動生成ツールも制約が非常に多く、生成するまでにエラー出まくり。
で、やっとこできたソースコードのうちUOCが許された部分にコーディングしていくのですが、その後一項目増えただけで自動生成し直し。
このとき、UOCが消えてしまわないように自動生成ツールにフィードバックしてUOC部分を記憶させておくのですが、これをうっかり忘れると、次回自動生成したときにUOCが全て消えた状態のソースコードが出来上がります。

何コレ、自分で作った方が早いんだけど。(泣)

そんなこんなで、まともに動くものを1画面も作成できずに、内部設計スタート。

内部設計~結合テストは、下請け協力会社に発注。
その入力となるドキュメントとして外部設計書を一式提供したのですが、遅々として内部設計書の作成が進みません。

それもそのはず。
前回書いたように、外部設計のスケジュールを優先するあまり、外部設計書には殆ど何も書いてない状態でしたから。(笑)

例えば、とあるバッチ機能の外部設計書はこんな感じ。

「〇〇システムに、××データを送信する。」

以上。(苦笑)

外部設計書の設計内容がたった1行。。。
あの頃は何も疑問に思わなかったんですが、よくこんな設計書でレビュー通ったな。
ユーザーの情シスも、H社の社員も、ザルとしか思えん。
恐らく、私と同様に、外部設計工程で何を決めなければならないかということが、分かってなかったんでしょうね。

スポンサーリンク


一番可哀そうなのは、設計書とは到底言えないものを渡された協力会社のSEの人たち。

案の定、こちらには質問の嵐。
でも、質問されたところで、外部設計書がこのレベルだからこっちだってまともに仕様を回答できません。

しょうがないので、逐一リーダーに確認するハメになるのですが、リーダーの口からは聞く度に違う仕様が返ってくる有様。
こういうことが起こらないようにするための外部設計書なんだと、このとき理解しました。

外注しておきながら、結局我々も残業しまくり状態。
でも、きっと協力会社さんの方が、それに輪をかけて過重労働を強いられてたんだろうなぁ。。。

内部設計が(日程上は)終盤にさしかかり、設計書のレビューを行うことになりました。
が、ここでもまともにレビューなぞできるはずもなく・・・

ここで、協力会社側のPLが、「御社との仕事の際は、いつも内部設計書のレビュー後にハンコを頂いています。今回もレビュー後の設計書にハンコをお願いできますか?」と言ってきました。

不審に思ったうちのリーダーは、すぐさま上司の取締役に確認。
すると、そんな前例は無いとのこと。

つまり、レビュー後に仕様をひっくり返されることを恐れた協力会社のPLが、いつもやってる風を装って設計書の承認印をもらおうとしたことになります。
そうすれば、後で堂々と仕様変更を主張でき、開発期間とお金を確保できるのでリスク回避になる・・・という思惑だったのでしょう。

これを察知した取締役からうちのリーダーへの指示。
「ハンコなんか絶対押すなよ。」

仕様をコロコロ変える気満々やん。
外注先に対して、一方的にリスクを押し付ける、、、
ふだん、協力会社・パートナーなどと言っていても、本音はただの下請けに過ぎないのです。

かくして、内部設計書にはハンコは押されないまま、内部設計工程が終了。
製造工程ぐらいはすんなり進んでほしいなぁ。。。

次回へ続く


還元率の高いポイントサイトで、ハイペースでポイントが貯まります ポイントサイトのポイントインカム

獲得ポイントの高いアンケートサイトで、効率的にポイントが貯められます infoQ新規会員登録

ベンダーSE時代に味わった最凶の炎上プロジェクト③

製造工程は、それは悲惨なものでした。

なんせ、ちゃんと最後まで動くサンプルプログラムが無いんですから。
(まぁ、私の責任でもあるわけですが)

大方の予想通り、協力会社の人達も、H社のクセの強いフレームワーク&自動生成ツールに悪戦苦闘。
進捗は芳しくなく、協力会社のエンジニアは、全員が休日出勤も厭わず働いていました。
で、それに引きずられるように、発注側である我々も休日出勤するハメに。。。
(質問に迅速に回答して、少しでも進捗を取り戻すために)

この頃は、毎日帰宅は22時過ぎで、週1回しか休みが無かったなぁ。。。
まだ若かったから耐えられたけど。

とりあえず、成果物だけは一式揃い、製造工程も何とかスケジュール通り終了。
もはや、品質なぞ二の次です。(笑)

それを東京に持って帰って、我々だけで結合テスト開始。
あれもこれも、まともに動きやしねぇ。(泣)

画面もバッチも、ちょっと動かしただけで落ちまくる有様。
そりゃそうか。
単体テストをキッチリやる時間も精神的余裕も無かったでしょうし。

とりあえず、致命的なバグだけを優先的に改修し、何とかシナリオの最初から最後まで一通りの機能が流れました。
・・・が、100件程度のテストデータを入力し、そのうち数十件が最後の機能まで連携されるはずが、、、

ゴールまで到達したデータ、その数たったの2件。(汗)
精子じゃないんだから。。。

一体、途中の機能のどこでどれだけ除外されてしまったのやら。
調査は非常に難航しました。

なんせ、外部設計書に何も書かれてないから、正解が誰も分からないんだもん。
機能と機能がどのようにつながっていくか、一度もウォークスルーしてませんし。

結局、結合テストもほぼやっつけ。(苦笑)
まともに動いてないのに、結合テスト結果報告書には、なぜか順調に完了日が入力されていきました。
そうまでしても、しょっちゅう徹夜&休日出勤を駆使しなければならず、スケジュール通りに結合テストは見かけ上完了したものの、全員が瀕死の状態でした。

スポンサーリンク


結合テストまで終わったということは・・・いよいよ総合テスト。
そう、ユーザーにお披露目です。

もう皆祈るしかありませんでした。
とにかく、ユーザーがバグに気付かないことを。
もう、低レベルな恥ずかしいバグだらけの状態でしたから。

固唾を飲んで、ユーザーの打鍵を見守る。。。
記念すべき、1画面目。
よし、何とか持ちこたえた。
登録されたデータはおかしいかもしれんが、とにかく落ちないことが重要なので。(笑)
その後も、画面系はそこそこ動きました。
まぁ、どノーマルな操作しかしてないからね。

さて、いよいよバッチ処理の実行。
実行されるのは、卸売業では超重要機能の「受注締め&在庫引当」。
ストレスに押しつぶされそうになりながら、実行されている様子を見守る我々。
何とか落ちずに最後まで流れ切りました。

その後、しばらくの間は、バッチから出力された各種帳票をユーザー側で検証するということで、我々はプロジェクトルーム内の自席に戻りました。
すると、ユーザーの情シス部長が、ものすごい剣幕でこちらに詰め寄ってきました。

何でも、帳票に出力されている在庫引当数が、明らかにおかしいとのこと。
どれどれ・・・
在庫引当数0.002ケース。

そりゃ怒るわな。
惜しいどころか、整数ですらないんだもん。
一体、どんな計算式で、こんな数が弾き出されたのやら。

卸売業において、在庫引当は生命線です。
当然、その最重要機能でこのレベルのバグが発覚したので、他の全ての機能の品質にも疑いを持たれたというわけです。
怒りの矛先は、一次請けであるH社のPMにも向けられ、私達はH社からもこっぴどくお叱りを受けました。

結合テストでは、処理が落ちずに最後までデータが流れることだけで精一杯で、各機能での値検証には一切手が回りませんでしたから、この結果は必然です。

結局、ユーザー&H社のお怒りを鎮めるために、無償で品質向上テストを行うことになりました。
もちろん、その分納期が延期されることになってしまったわけですが・・・

さすがに、今度はミスが許されないため、品質向上テストでは値検証も行われました。(当たり前ですが)
そして、2ヶ月に及ぶ品質向上テストが終了し、再度ユーザーにお披露目することになりました。。。

次回へ続く

還元率の高いポイントサイトで、ハイペースでポイントが貯まります ポイントサイトのポイントインカム

獲得ポイントの高いアンケートサイトで、効率的にポイントが貯められます infoQ新規会員登録

ベンダーSE時代に味わった最凶の炎上プロジェクト④

品質向上テストを経て、総合テストリベンジ。

不具合は色々見つかったものの、とりあえず最後まで流れ切り、見かけ上はそれなりの品質っぽい。

それもそのはず。
総合テストのシナリオは、全て当社側が作成したものですから。
なので、結合テストと全く同じシナリオで、同じテストデータを流してるわけですから、不具合なんぞそうそう出るわけがない。
本来は、開発者側と発注者側とで、視点が異なるテストを行うことがこの工程の主旨なはずなんですが・・・

ただ、この工程で待ち受けていた本当の地獄は、仕様変更の嵐でした。

・これだと運用が回らない
・画面が使いにくい
・帳票が見づらい
 等々・・・

そして、これらを全て不具合だと主張して、無償でリリースまでに改修するように要求してきたのです。
外部設計書に何も処理内容が記述されていないのを良いことに、「こんなつもりじゃなかった」の一点張り。

いやいやいや、、、ちょっと待ってみようか。(汗)
確かに処理内容の記述は無かったが、UIはちゃんと提示していただろう。
なのに、「使いにくいから」という理由だけで、画面レイアウトや帳票レイアウトまで不具合だと主張するのは、さすがに厚顔無恥というもの。

が、品質が悪すぎて納期を延期してしまった当社側、及びH社のPMも強硬な態度に出ることはできず。。。
結局、この要求を受け入れることになりました。

これに味をしめた情シス部門の担当者たち。
これを契機に、不具合改修という名目の仕様変更を、とめどなく要求し続けてくることになるのです。
酷い話ではあるのですが、そもそもの根本原因は、外部設計を手抜きしたことにあるのですから、どっちもどっちかな。。。

そんなわけで、総合テストに入ってからも昼夜問わずプログラム改修に明け暮れるメンバーたち。
私はサブリーダーという立場だったので、昼間は総合テストに立ち会ってユーザーに嫌味を言われ、夜は遅くまで改修作業を行うという状態でした。

スポンサーリンク


悪夢のような総合テストが終わり、お次は運用テストです。

しかし、ユーザー側の準備が全く整っておらず、本番までに外部システム連携テストは一度も実施できないという、まさかの事態に。
(ちなみに、総合テストでもやってません)

しかも、総合テストで色んなプログラムを変更しまくったわけですが、その改修確認は全て単機能止まり。
つまり、通しで一度も流してないので、正直後続の機能や、H社子会社が担当するサブシステムにうまくつながるのか、確証が無い状態です。

運用テストは、結局外部システムとの疎通テストと、移行リハーサルぐらいしか行われず。。。
そんな酷い状態であるにも関わらず、なぜか稼働判定はGOサインが出たため、そのまま本番リリースされることになりました。
いや、無謀すぎるだろ。。。(汗)

稼働スケジュールは、いきなり全面稼働するのではなく、一番取引件数が少ない地方支店から段階的に稼働していく計画でした。
なので、一支店目で失敗しても業績には大きな影響は無いと判断したのかもしれません。
でも、取引先にも多大な迷惑をかけちゃうからねぇ・・・

メンバー全員が不安感に押しつぶされるのを尻目に、ついに稼働日当日を迎えるのでした。。。

次回へ続く


還元率の高いポイントサイトで、ハイペースでポイントが貯まります ポイントサイトのポイントインカム

獲得ポイントの高いアンケートサイトで、効率的にポイントが貯められます infoQ新規会員登録
プロフィール

Author:たみおと
36歳にして社内SEに転職しました。
ベンダーSE・社内SEどちらの方が記事を読んでも、ご参考になる体験談をUPしていきたいと思っていますので、宜しくお願い致します。

検索フォーム
ブログランキング
よろしければ、ポチっと一押しお願いします。m(__)m

ブログランキング・にほんブログ村へ
カテゴリ
よく読まれている記事
最新記事
おすすめ書籍
[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

なぜ、システム開発は必ずモメるのか? [ 細川義洋 ]
価格:2160円(税込、送料無料) (2016/11/7時点)



[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

絵で見てわかる RPAの仕組み (絵で見てわかる) [ 西村 泰洋 ]
価格:2786円(税込、送料無料) (2018/7/30時点)



月別アーカイブ
リンク