第４９２話　本番直前になってデータが移行できないとは？

このシステム開発は完成度や安定性という問題をはらみながらも、予定の３年を経過したので時間になりました、終わりですというような本質論は置き忘れたまま本番が開始されたように思います。そういうプロジェクト運営を表すような典型的な事件が本番直前に発生しました。
本番を眼に前にして確認の為に新しいシステムに旧システムからデータを移行しようとしたら、新しく開発したシステムのデータベースに抜けがあってデータが移行できないという事件が発生したのでした。
この話を聞いた時には、案の定やってくれたんだねという感想でしたが、同時に以前にも紹介した通りデータ移行は新しいシステムの形が出来た後で検討すれば良い筈なのに、システム開発を受託した事業部のプロジェクトマネージャーが、プロジェクト開始早々にデータ移行の別プロジェクトが必要と言い出して、顧客は当初提案にはなかった追加の費用を３年も払い続けたのでした。情報システム部員も意味が分からずに、最初はシステム開発を受託した事業部のプロジェクトマネ＾ジャーを信じていたこともあり、明確な理由もなく追加費用を認めたのではないかと推測しています。
システム開発を受託した事業部が主導した３年間ものデータ移行作業で何をしていたかは、私はデータ移行には全く関わっていなかったので内容を知る由もありませんが、本番前に移行できないという障害が発生じた時点では、３年間の費用は無駄であったという事は明白になったのではないかと思います。
システム開発の本番開始前に、私はプロジェクトの工期について評価をしていたのですが、データ移行は長くて１年、経験のあるシステムエンジニアが効率的に仕事を進めれば半年もあれば終わる作業と考えていましたので、システム開発を受託した事業部がデータ移行に費やした期間は私の試算の約３倍にもなり、普通にはにわかには信じられないような期間と費用を費やしていたという事かと思えました。
それに加えて、プログラム製造後に何度もテストをしたという報告をシステム開発を受託した事業部はプロジェクト会議でしていましたが、データベースの項目抜けの状態で、色々なテストをして検査結果良好という内容も疑問に思えるのは当然でした。システム開発を受託した事業部ではデータベースの改修に２・３日も掛けたので不信感を持ちましたが、作業が完了して旧システムから新システムへのデータ移行ができるという事になりました。
 
情報システム部員はこれほどの重大な障害が発生しても、システム開発を受託した事業部に対して怒りが爆発するというような事も無かったのが不思議で、こういう事態を役員に報告するとかえって自分たちが怒られると思ったのかどうかは不明ですが、以後は何もなかったかのような事になったのには違和感を持ちました。普通なら「責任者を呼べ」から始まり「その原因は何か」とか「落とし前はどうする」というような話になると思ったので不思議で仕方なかったという感想を持ったのでした。
同時に、情報システム部員は障害内容や障害レベルなんかよりも、とにかく本番開始に間に合わせるという観点でしか物事を見ていないので、深く障害検証するとい行為をしなかったとも思っています。
データ移行障害でシステム開発を受託した事業部がどういう作業をしたのかは全く知りませんが、臨時に作業したのは事実なので、本番以降の障害でその不備が現れる可能性は大きいのではないかとは容易に想像出来ると思っています。

第４９１話　機能しないソフトウエアが存在する理由

システム開発も終盤になるとおかしな事が見えてきました。その一つがシステムで利用している或るソフトウエアが何故導入されているのか甚だ不明であるという事がありました。
このソフトウエアは私がシステム開発を受託した会社に在籍中に見積もりをしていたので記憶が鮮明でした。ライセンス体系が分かりにくくて、システム開発を受託した事業部のシステム基盤担当のシステムエンジニアに何度も確認していた記憶があったからでした。
このソフトウエアは多数の外部サイトとの通信を簡単に変換できるというものでしたが、提案時から顧客の要件にはそんな事はなく、導入する必要はないのではないかと不思議に思いながらも、システム開発を受託した事業部から必要だと言われれば反論も出来ないのでも見積もりをしたという代物でした。
本番テスト（受入テスト）が始まると色々な障害が発生していて情報システム部員はそういう障害の対応に日々追われることになったのですが、その時に私はシステム内のデータがどういう具合に流れているのかを調べてみました。
そうすると、この外部サイトとのデータをやり取りするソフトウエアは何も役目をはたしていないのではないかと思い情報システム部員に質問をしました。情報システム部員からシステム開発を受託した事業部のシステムエンジニアに問い合わせると「何でもかんでも通過だけはしている」という答えがあったと聞きました。業務上の理由は無くてもソフトウエアはあるので通過点として利用しているというようなことが判りました。しかし、本来の機能である変換機能は何も利用していないのでは無いかという疑問もでました。
 
これはシステム開発を受託した事業部が提案時に直ぐにシステム構成図が出てきたので不思議に思っていた事と合点が行きました。顧客の業務要件を理解する前にシステム構成は決まっていたという事だと思いました。その理由は、以前に納入した顧客のシステム構成をそのままコピーして提示したという事に他ならないのでした。それで、使わないソフトウエアもそのまま導入してデータだけ通過させるということになっていたのではないかと推測しています。
プログラムを動かすハードウエアに基盤ソフトウエア等で構成させるシステム基盤と呼ばれる構成も、システム開発を受託した事業部では顧客の要件を検討する事も無く、納入した実績があるので安心という決め打ちのものを納入したという事でした。３年もかかって検討するようなシステム開発というプロジェクトは必要なかったのではないかという事につながる事と思います。同時にそういうシステム基盤を検討する能力も無いので、安易に過去の納入実績のある構成をコピーして提示したということの裏返しでもあると思われます。

このような背景があったので、ハードウエアや基盤ソフトウエアを納入後にシステム基盤テストをしたと言ってはみたものの、テスト仕様書や検査結果がずっぽりと抜け落ちていたのも、過去に納入した経験があるのでテストをしなくても良いと自分勝手な理由でテストをしないで放置していたのを、私が不備を指摘すると慌ててテスト仕様書や検査結果を提出をしていた理由も分かるように思えました。
レストランでオーダーメイドの食事を頼んだつもりが、レトルト商品が出てきてしまったという事なので、羊頭狗肉という看板に偽りありといういような事が行われていたのではないかと推測しています。

第４９０話　プロジェクトの最後まで空論を振り回す？

このシステム開発を受託した事業部が本当はシステム開発について無知であることが最後になって判明したのは保守体制についての話が出た時に明らかになったと思いました。同時に、この事業部はシステム開発業務を全て外注業者に丸投げするような仕事しかしてこなかったのではないかという事も浮かび上がったものと思いました。１０月に本番テスト（受入テスト）が始まっても障害だらけで計画した２ヵ月で終わる気配もなく、とうとう５月まで継続して受入テストが行われたのは以前に述べた通りですが、その時に話題になったのが本番以降の保守費用問題でした。
システム開発を受託した事業部のプロジェクトマネージャーは開発費用の何パーセントとか言うのを盾にして最初は８人必要ですとか、最後でも５人は必要という様な体制と費用を主張していました。この話を情報システム部員から聞いた時、このプロジェクトマネージャーは顧客の業務やシステム内容を全く理解していないのではないかと思いました。システム開発後のシステム維持や保守体制というのは、基本となる顧客の情報システム部員支援に、システム開発をしたベンダーからどの程度の負荷が必要であるかを考えるのが基本です。システム開発を受託した事業部では、そういう観点ではなく単に開発費用のパーセンテージで提示してきたのでした。年間数億円という数字を提示されて情報システム部員も驚かされました。私は元々開発費用が市場よりも倍もする開発費用であると試算していたので、この保守体制検討についても当然ながら反発を感じたのでした。
 
システム開発のプログラム製作が終わるあたりの時期から、私はシステムの本番後の運用分担について整理が必要と思いついて、顧客である情報システム部とシステム開発をした事業部とで行う運用業務の分担表を作業ごとに整理するサンプル表を作成しました。保守体制の話が出てきた時期には、この分担表も毎週の情報システム部とシステム開発を受託した事業部との打ち合わせでほぼ出来上がっていました。その分担検討途上で、アプリケーションプログラム運用業務も追加されたのは前回お話した通りです。
過大な保守工数を要求するシステム開発を受託した事業部に対抗する措置として、私は情報システム部員に対して、この表に工数を入れて合計すれば必要な工数が出ることを説明しました。その後、システム開発を受託した事業部と情報システム部員で数字を入れていくという作業を行いました。その結果を情報システム部員から聞くと１人月以下でしたという結果を聞いて、私の予測よりは小さいものだったので少しは驚きました。又、この時に情報システム部の課長が提案書には保守費用は数億円どころかもっと小さな数字が書いてあることも発見してシステム開発を受託した事業部に示すという事もありました。
私は保守契約については全く関わっていないので、実際の契約工数については知りませんが、システム開発を受託した事業部のプロジェクトマネージャーが主張していた人数よりは少なくできたと思います。
 
業務に複雑性は少なく、データ量も極端に少ないシステムで、システム開発を受託した事業部のプロジェクトマネージャーが大人数の保守要員が必要という発想をしていたのは、プロジェクトの最後の最後まで業務実態を理解していなかったと言われても仕方のないような主張をしていた事だったと思いました。この時、システム開発を受託した事業部では、プロジェクトマネージャーに加えて、統括プロジェクトマネージャーに副事業部長という幹部も揃って会議に出席していましたので、プロジェクトマネージャー自身というよりも事業部としての主張であったと思います。

第４８９話　金の切れ目で全ての作業は終了？

このシステム開発プロジェクトが如何に中途半端なものであったかを象徴するような事はシステム開発を受託した事業部がテストをしていなかったシステムテストから本番テスト（受入れ）から本番開始までの８カ月以上にわたって行われていた運用に関するマニュアル整備が不十分なままに時間切れで終了した事でした。
事の発端は、この時期にシステムを運用するための設計書や関連するマニュアルが必要というので情報システム部のシステム基盤整備担当者がシステム開発を受託した事業部や関連するメンバーと作成の打ち合わせをしていましたが、そういう会議の様子を見て情報システム部のシステム開発の担当者がアプリケーションの運用書も必要という事に気づいて作製の検討を始めたものでした。何をとぼけた話をしているのかと聞いていましたが、システム開発を受託した事業部からは何も説明もなかったので、黙っていたらアプリケーションの運用に関する資料は何も作成しないままにシステム開発プロジェクトは終わったかもしれないと思っています。
この時、システム開発を受託した事業部の後ろで糸を引いていた役員が派遣をした公称月額２００万円以上という常駐しているシステムエンジニアを称する男が主導したのですが、本番が開始されるまでに整備されるべき資料が出来たかどうかという確認もあいまいな儘尻切れトンボ終わり、その男も常駐が終了していなくなってしまいました。本番開始当初は重大な障害が続いて、仕様書やマニュアルなどの運用資料どころの話ではなくなっていました。
この運用関連資料整備の会議には私もシステム基盤側のアドバイザーみたいな形で参加していましたが、インフラ側の資料も多岐にわたり整備に時間がかかりましたがとうとう完成しないまま本番を迎えて完成しまいままに終わったのは確認しました。私は「これじゃあ出来ていないでしょう」と情報システム部員からは「できないので・・・」という曖昧な返事しかありませんでした。
 
システム開発後はアプリケーションの維持運用はシステム開発を受託した事業部に任せるというので、開発したプログラム一式とその仕様書はシステム開発を受託した会社のクラウドサービス上で管理されるということでした。こうなると、顧客は命を取られたも同然で、会社の社風から情報システム部員に管理するという概念が希薄なので、自らがプログラムの現状を確認することは出来なくなっていると推測されます。システム開発を受託した事業部のやり放題が維持されることになっていると思われます。トラブルがあっても、システム開発した事業部に責があるようなものは知らない間にプログラムが修正されてしまっていることが考えられるからです。仕様書も最後まで完成しているのかも確認できないままに本番に入っているので、未完成の仕様書もあると推測されます。

金の切れ目が縁に切れ目みたいに、プロジェクトが終了して本番が開始されると、残作業はありませんと言われてシステム開発プロジェクトのメンバーは大半がいなくなってしましいましたが、プロジェクトの終了を確認すべき大量の仕様書やマニュアルが未完のまま終了したように思えました。情報システム部としても部としての責任があるので公にはそういう事も言えないので、とりあえず終わりましたという事になっていると思いますが、最後までシステム開発を受託した事業部と裏で支えた役員に一杯食わされてしまった結果になったのかと思います。その惨憺たる遺骸は、システム変更や障害時には必要となる未完の仕様書やマニュアル類に見て取れると思います。

第４８８話　怖い程に淡々と進む本番テストで起きていた事

システム開発を受託した事業部ではプログラムを作成したものの、プログラム製作後にテストを十分にしていなかった事が本番テスト（受入れテスト）を始めた以降に障害という形で現れたのでした。
一番分かりやすい例はプリンタで紙の出力が出来なかった事でした。事前に、システム開発を受託した事業部には顧客から新システムで使用するプリンタをテスト用に貸し出していました。本番テストが始まる前には当然ながら紙が出てくるのを確認していると、顧客である情報システム部員全員がそう思っていたのは当然であった。
しかし本番テストを開始してから色々試してもプリンタから紙が出力されないので、プリンタのベンダーも含めて対策会議を開催する羽目になったのでした。
この事件は前任の情報システム部次長が心配していて、プロジェクト開始前に関係するベンダーと問題洗い出しの会議をするようにと別に予算を組んでいたのを、システム開発を受託した事業部では基本計画が延伸した時にその予算を食ってしまったのでした。理由は不明ですが、システム開発を受託したプロジェクトマネージャーははなからベンダーとは打ち合わせをする必要がないとして、私からのアドバイスを無視したつけがこの時に現れたと思いました。

この時はプリンタのベンダーも未だ顧客との契約があるのでという理由で無償でシステムエンジニアを派遣してくれたのですが、システム開発を受託した事業部からは何の礼の言葉もありませんでした。普通の簡単なシステム開発もできないばかりか、人への礼も失するような会社の体質が垣間見えたと思いました。
この時の対策はプリンタを通常使用の設定から変えれば出力が可能になるという事がベンダーの調査で判明して解決したのですが、同時にシステム開発を受託した事業部ではシステムテストと称するフェーズではテストをしていなかったことが判明したのでした。
これだけのことを起こしても波風を立てたくない社風なのか、文句を言うのが嫌なのか不明でしたが、情報システム部員は怒りを露わにすることはありませんでした。ここでも心中ただならぬ気持ちで怒りがこみ上げていたのは私だけだったかもしれません。

週次のプロジェクト会議では、本番テストで発生する様々な障害に対してシステム開発を受託した事業部のプロジェクトマネージャーからは「やります」とか「対応します」とかいう生返事ばかりが出たのですが、障害があっても解決すれば良しとする情報システム部員の態度もあって、システム開発を受託した事業部を追及するという雰囲気はありませんでした。
情報システム部員はシステム開発の知識はないので仕方が無いと言えばそれまでですが、元々理屈をこねて考える習慣が無いので、システム開発を受託した事業部の障害対応がその場限りの一時的な対応かも知れないという疑問を持たなかったのが、将来の障害発生の種を作らなければよいのだがと心配をしていたのは私だけだったと思います。表面的には収まっても根の部分に対して処置がされていないと、再び何かのきっかけで障害は発生するという心配の種が沢山あったという風に感じました。
本番テストで沢山の障害が出るというのは、プログラムを製造してから半年も色々なテストをしていますと説明していたシステム開発を受託した事業部のプロジェクトマネージャーが説明していたことが本当かどうかという疑念が出てきても普通だと思いますが、情報システム部のプロジェクトマネージャーの他、情報システム部員からもそういう疑問を提示されることはありませんでした。
情報システム部としては役員会で説明したシステムの本番が来るのを只待っているとしか思えないほどにのんびりしたものだったと思います。障害の中身よりも、本番のカットーバーをどう演出するのかという事に気が回っているので、ますますシステム障害の本質論などは置き去りにされて、当時は重大な障害が残されている事には誰も気づかぬまま本番の日を迎えたのだと思います。

第４８７話　本番テストをしたらプログラムが無くて使えない？

このシステム開発プロジェクトではテストフェーズに入ると、システム開発を請負った事業部が行ってきた仕事の質が如何にひどい状態であるかを思い知らされることになるのでした。
先回はサーバー基盤と言われるOSとかミドルウエアのソフトウエア導入はされたものの果たしてどこまできちんとテストされたか不明であるという事を紹介しました。この時、関連することで非常に重要な事を思い出したので少し順序は違いますが書くことにしました。

プログラムが４月には出来上がって、内結・外結テストとかシステムテストとか６カ月もテストした後には、いよいよ受入テストという本番データでテストをするという事になりました。
その受入テストでは情報システム部員が機能ごとに担当者が数字を入力しては計算結果に間違いないかということや、画面の遷移が仕様通りにできているかを確認して、本番に入れるかどうかを確認するものでした。計画では２か月程度で終わる予定でしたが、多数の障害が発生して本番移行・教育という後の３か月もこの受入テストが並行して行われることになったのでした。
アプリケーションの受入テストは業務ごとに情報システム部の担当者に分担分けされていました。見ていた限りでは担当者によってテストの密度が違うように思えました。
この受入テストをしていた時、ある業務で処理が出来ないということがあって、情報システム部の担当者からシステム開発を受託した事業部のシステムエンジニアに問い合わせると「プログラムに計算式が組み込まれていません」と正直な答えが返ってきたのでした。多分、情報システム部の担当者から直接問い合わせをしたので何の考えも無く返事をしたのだろうと思いました。
当然ながら情報システム部の担当者は「直ぐに修正してください」と言ったと思いますが、この件がそれ以上に炎上することはありませんでした。発注者たる情報システム部は理由の如何を問わず本番に向けてシステムが動くことにしか目が行っていないので、それがどういう意味を持つものか等とは考えもしなかったと思いました。
 
私はこの件を聞いた時に、これがプロジェクトの象徴すべき事件だなと思うと同時に、忙しそうにしている情報システム部員の中で一人だけ怒り心頭の状態にあったのでした。
プロジェクトを開始してはや２年も経過して、いよいよ本番かと思って実際の業務用データを入力したらプログラムが出来ていなくて処理が出来なかったという、事態というか事件と言った方がいいかも知れないと思いました。
本番前の実データテストで機能が出来ていないという事が発覚したのは、仕様書には書いてあったのにプログラムを製造する時に忘れていたとしか思えないもので、半年以上も何とかテストをしたという報告を散々にしていたのを、システム開発を受託した事業部のプロジェクトマネージャーから毎週聞いていたのですが、その報告の信頼性を瓦解させるよう事だった思いました。
こういう事件が起きても情報システム部員は怒るわけでもなく淡々と仕事をしていたのは、自分の担当した仕事が完成できればよしとする思考しかなかったのかとも見えました。情報システム部員のシステム開発の不慣れや知識のないのをいいことに、システム開発を受託した事業部はシステム開発プロジェクトを適当にあしらい、最後のテストも手抜きだらけで、顧客から金だけ巻き上げたというような一断面が見えた時とも思えました。
週次のプロジェクト会議では、システム開発を受託した事業部のプロジェクトマネージャーは「修正しときました」の一言で終わり、情報システム部のプロジェクトマネージャーからも何の異議も出ませんでした。

第４８６話　テストをしていたかどうか疑わしい仕事を発見

システム開発のプロジェクト会議は週次で行われていて、色々な資料が提出されたので、そういう資料とプロジェクトの進捗との関連もチェックするのが、私が派遣社員として仕事を始めた時から終わるまで継続的にしていた仕事の一つでした。
私は４月から派遣社員として情報システム部に在籍していたのですが、６月から中国で製造したプログラムを６０００ものパターンでテストをするというスケジュールになっていました。情報システム部員は６０００という数字を聞いてたくさんテストをするので安心感があるというような印象を持っていたらしく深く質問をすることはありませんでした。同時に何を質問したらよいかもわからなかったかも知れませんでした。このテストもテストの仕様書はあったのか無かったのか分かりませんが、毎週数字で説明されるだけで、一体全体何がテストされて何が問題だったのかというのは何も報告されなかったので、報告を聞く受け身の情報システム部員は沈黙しているしかなかったのでした。

そんな時、実際にプログラムを動かすためのハードウエアのサーバーが導入されていて、色々な準備がされていました。当然ながらコンピュータという機会の性格上、サーバーというハードウエアだけではなく、システム開発したプログラムを動かすための諸々のミドルウエアと呼ばれる基盤ソフトウエア製品の導入も行われていました。
プログラムを動かすためのハードウエアの導入や関連する基盤と呼ばれるソフトウエア群の導入からテストまでは、毎度の報告通りに順調に進んでいますという報告が、システム開発を受託した事業部のプロジェクトマネージャーからされたのでした。
そういう製品群のテストも終わりいよいよ検収という段階になって、私がそういう基盤ソフトウエアと呼ばれる製品群のテスト仕様書や報告書が無い事に気づいて情報システム部員に報告しました。週次の会議で事実を指摘されると、システム開発を受託した事業部のプロジェクトマネージャーは「ええ、それじゃ準備させます」と言って終わりでした。余りに簡単に受け流されてびっくりしたのでした。

基盤ソフトウエア群にはアプリケーションソフトと密接に連携しているものもあり、それらはシステム開発を受託した事業部のシステムエンジニアの担当でした。この基盤ソフトウエアを担当していたシステムエンジニアが提示したテスト仕様書や結果を私がいちいち査読すると、仕様書の間違いとか、テストの方法がおかしいのではないかという事に気づいて質問状を作成して提示したら、修正した仕様書とテスト結果を再提示してきたというようなことがありました。えらく急いで資料を作成したのが分かる程に完成度が低いものもありました。
そういう状況を見ると、元々テスト仕様書や結果報告書を出すつもりはなくて、私が指摘してから製作にとりかかったとしか思えないような状況でした。こんなことをしなければ、工数がかからずに儲かっいたのに変な事に気づいて大迷惑だわと、システム開発を受託した事業部の連中はそう思っていたに違いないと思いました。
そういう状況でも人の好い発注者の情報システム部のプロジェクトマネージャーは何のクレームを言うわけでもないので、システム開発を受託した事業部のプロジェクトマネージャーはまるで大船に乗っているような余裕綽々とした感じでした。
 
こういう事態を見ていると、そもそも基盤ソフトウエアと呼ばれるソフトウエアのテストを本当にしていたのかと疑問に思えて、基盤ソフトのテストをした担当者に質問すると「ええ、データセンターには行っていました」という答えが返ってきただけでした。製品の導入とテスト作業は外注のシステムエンジニアとしていたらしいとは分かったものの、きちちんとしたテストが行われたかどうかは甚だ疑わしいという印象を持ちました。
基盤系のシステムやソフトウエアのテストする前に仕様書を確認し、基盤ソフトのテストも情報システム部員が同席して確認するようなことが必要だったのではないかと思いました。当然ながら、情報システム部員にはそういう発想法は出るわけもなく、作業は全てお願いしますということなので報告を受け身で聞くしかなかったのでした。何もかもお願いするのはいいとしても、相手がどういう風に仕事をしているのかさえも理解していなかったのが問題で、波風を立てたくないという雰囲気の中でいちゃもんを付け始めた私の存在は情報システム部のプロジェクトマネ＾ジャーから見ると煙たく思えたのではないかと感じていました。
しかし、時すでに遅く、プログラムは出来てしまっているし、あとはちゃんと動かくどうかの確認というテストの段階だったので、私一人がわめいても限界があると思いました。
 
このフェーズに到達する前には、プログラムの製造についてばかりに気が行っていましたが、そういう製品を動かす基盤システムと呼ばれる部分について少し注意をするという事が不足していたと思いました。しかし、それはシステム開発を受託した事業部が発注者たる顧客の情報システム部員に情報を出さずに、作業だけはしていたらしいというような状況になっていたからでした。プログラム開発同様にプログラムを動かす基盤ソフトウエアの導入やテストについてもプログラム開発同様に、自分たちに都合の良い情報しか出さないという姿勢であったと思いました。
こういう仕事の進め方が本番以降のシステムの障害とどう関連しているかは不明ですが、何か起きた時にはシステム開発途上で行われた、知らない間に行われたり行われなかった作業が原因という事もあるのだろうとは想定がつくと思います。

第４８５話　世の中より倍の費用をかけたシステム開発

私がシステム開発を発注した会社の情報システム部に派遣されても特別な仕事は無く、自らやるべきことを探すというような状態でした。通常はシステム開発の週次プロジェクト会議で配布される資料の整理とプロジェクトで必要とされそうな資料作成をしていました。
プログラムの製造が終わって外結テストというフェーズに入ると、システム開発を受託した事業部のプロジェクトマネージャーからプログラムの総ステップ数が公表されました。プロジェクトマネージャーはもったいぶってその数字が大きいというような言い方をしていました。
この時、私はシステム開発の内容の妥当性を調べられないかと調査を始めた頃だったので、このプログラムの総ステップ数の公表は非常に役立ちました。同時に、この後にプログラムが顧客も知らない間に、システム開発を受託した事業部の独断で製作し５０本も増えてしまったのですが、総ステップ数について何のコメントなく最終的な数字は分からずじまいでした。
又、当初提案は５機能のシステム開発でしたが、基本設計を始める時に５機能の開発は当初提案費用を超えてしまうので、一つ減らして４つの機能だけにして当初提案費用でできますという目論見がシステム開発を受託した事業部から提示されていました。実際には、その後の基本設計延伸で相当額が増額されたという経緯がありました。機能は減らすわ、費用は増やすわとやりたい放題でしたので、当然のことながら費用は世間離れしたものになったということもあると思います。

システム開発の費用試算をする場合には、プログラムのステップ数・画面数・帳票数・バッチ数等の色々な要素で試算する方式が多多あり、偏りのない数字を求めたいので３種類ほどの方式で試算をしました。しかしながら、いずれの方式で計算しても、システム開発を受託した事業部の提示した費用の半分程度の数字しか出てきませんでした。少しは余裕度を見ても精々６割程度の費用試算となったので、システム開発を受託した事業部の見積金額が如何に高額なものであったかが証明されることになりました。言い方を変えれば、利益がそれだけ高額であっただろうという想像もできるということでした。
同時期に、工期と品質についても計算をしてみると当然ながら工期は長すぎる、品質は悪いという結果がでました。工期は以前から説明をしている通り、目的の無かった基本計画の半年と基本設計の延伸半年がまるまる世の中標準のシステム開発工程からは長すぎたという評価になりました。システム開発を受託した事業部には顧客の業務内容を学ぶという姿勢が無かったので、基本計画などは無しで最初からプログラム開発の準備をするのが、システム開発を受託した事業部の仕事の仕方としてまっとうなものであったのだろうと思いました。システム開発を受託した事業部ではシステムという概念は持てなくて、プログラム開発しかできないという一段低い能力しかない集団なので、設計等ということはそもそも無理であったという事が、この時のシステム開発の費用・工期・品質を評価して明らかになったと思いました。
プログラムの品質は先回も述べた通り自ら立てた合格数字を自ら低く変えて合格にするくらいの程度なので、私がレビュー数とかバグ数で評価した世の中のシステム開発の標準からは落ちるものであったというのは当然の帰結だったと思います。
 
情報システム部に在籍すると漸くこの会社の仕事の内容が理解できるようになりました。この顧客の業務は少し複雑な手続きのものもありますが、一般の会社の業務内容と比較すれば極めて簡素な業務という印象を受けました。それに加えて、データ量が極めて少量なので、普通にシステム開発すれば障害などは発生することは考えられないというのが感想です。この新しいシステム開発をする前に、オープン系で開発した一部の情報系システムは障害は殆ど発生しなかった事で証明されているようなものでした。ところが、新しいシステムでは色々な障害が度々発生するというので、品質に問題があるというのが判明しています。
この新システム開発以前はホスト計算機を導入して、素人の情報システム部員がプログラムを自分で作成し、業務上色々な障害を発生させていました。そういう以前の障害発生状況を考えると、新しく金をかけて開発したシステムは、素人同然のエンジニアと呼ばれる人たちが開発したシステムとも言えると思いました。システム開発の評価を定量的に行うと、システム開発を受託した事業部の能力が低いという評価になりました。
顧客はシステム開発費用の半分を返して貰っても、出来の悪い１０００本のプログラムだけが残るという結果となり、不満の残るシステム開発プロジェクトを経験することになったという事だと思いました。
以降のブログでは、そういう能力の低さとはなんであったかという事例を思い出しながら書き綴りたいと思います。
 
 
 

第４８４話　システム開発の不正の証拠を発見

私はシステム開発を発注した会社の情報システム部に派遣社員として１年半という期間を在籍しました。前職の会社からは役員が私を悪者にしたてて、役員とその関係者の不正行為の露見を防ごうとしましたが、図らずして私はシステム開発を受託した事業部の数々の不正を暴く様な役目をしていました。
システム開発を発注した会社の情報システム部員は普通の事務職で採用された人ばかりで理科系ならば少しは素養があるという程度で殆どの部員は素人同然で、情報システム部員という名前だけが一人歩きしているような印象を持っていました。
４月からはシステム開発を発注する側の立場になったので、システム開発を受託した事業部から提示される資料の分析を徹底して行い、そこから不正を見抜くことが出来ました。
システム開発は半年もかけてプログラムの製造を行っていた時期であり、毎週の週次の会議でもその進捗を聞いて終わりという事が続いていて、システム開発を受託した事業部からは問題ありませんという話しかされないので、何で問題がないのかさえも分からない状況でした。
 
この時の不正は２つあって、一つはプログラムがいつの間にか５０個程増加していた事でした。私が６月位に情報システム部員経由で入手した、システム開発を受託した事業部が作成した、１０００個程プログラムが表になっていたプログラム一覧と９月に新たに提示されたプログラム一覧とを比較して数が異なっていたのを発見しました。
システム開発を受託した事業部は、プログラム追加開発を発注先の情報システム部員には一切知らせずに内緒で開発をしていたのでした。ある日突然プログラム数が増えたので、私が情報システム部員に報告をしました。
週次のプロジェクト会議で情報システム部員から「プログラムの数が増えていますが・・・」とシステム開発を受託した事業部のプロジェクトマネージャーに質問すると「えっ」と驚いて「調べてみます」と言って終わりでした。以後、このプログラムが増えた件については何の説明もありませんでした。情報システム部員も必要なら増えるだろうという位の意識だったのだろうと思いました。システム開発を受託した事業部のプロジェクトマネージャーは素人の情報システム部員にはプログラムの数が少しくらい増えたって発見できやしないと思い込んでいたと推測しています。
そもそも、システム開発を受託した事業部のプログラム仕様書は業務仕様書と一体になっているので、仕様追加がある時は顧客の承認が原則です。推測ではテストが始まると不足するプログラムがあることが分かり、顧客には隠れて開発していたということです。基本設計書を作成している時は気づかず、テストを始めて初めて業務の仕組みが分かり慌てて追加したものと推測しています。それで顧客には内緒で作成したものと考えられるものです。システム開発の能力程度が明らかになったとも言えます。
この不正は「仕様追加について顧客承認を得なかったこと」と「システムテストという契約内容とは異なる業務をしていたこと」が当たると思います。追加されたプログラムの作成時期が不明ですが、プログラム製造が終わりシステムテストが始まるまでの間の期間と考えられるので、この時期に基本設計の残りの作業を行っていたことになります。１年前の１月から開始した基本設計は半年で終了する筈の計画が実質半年延長され、それが更に半年以上隠れて行われていたという事が露見したということでした。
システム開発でフェーズ分けをしている意味が全くないという仕事振りで、明らかな契約違反なので、基本設計の延伸１年分の数億円は裁判所で係争しても十分に勝ち取れる証拠が出てきたと言う意味があるかと思います。
 
二つ目の不正も顧客の素人なのを逆手に取ったようなもので非常に気分の悪いものでした。
シナリオテストという実データを利用したテストが８月から１０月にかけて実施されて、毎週テストの数とバグ数が週次の会議で報告されました。私はその数字を別表に写して数字の推移を見ていて、９月になって不正を発見することになりました。
バグ数がシステム開発を受託した事業部で自ら立てた数字が超えそうになった時、知らん顔して表のバグ数を２割ほど水増ししてハードルを下げて報告したのでした。この時も私は情報システム部長に報告をしましたが、システム開発を受託した事業部のとの管理者会議でも、システム開発を受託した事業部から何の回答もなかったようでした。情報システム部長も５月の定期異動で新しい部長でしたが、情報システムは全くの素人で何のことか全くわからないようだったのが残念でした。
このケースでは、品質問題と直結しており本番以降の障害発生と大きく関係していると考えられます。
こういう不正を、システム開発を受託した会社では見抜けずに放置していたことになると思います。ガバナンスを言うどころではなく、まっとうな仕事も出来ないことが白日の下に明らかになった事件と思います。

システム開発を受託した事業部のやらかした不正は以上に留まらず、次回以降にご披露に及ぶつもりです。本当にひどいものでした。

第４８３話　役員が行った失敗プロジェクトに屋上屋を架した事

４月になって私の派遣先の会社の役員に私を誹謗中傷した前勤務先の役員は、その少し前３月にもシステム開発の発注先である会社の役員に面会して、このシステム開発の失敗の屋上屋を架すような事をしていました。
既に本番時期も半年ずれることも決まっており、顧客の情報システム部員は、文句を垂れるわけでもなく半年延期が会社の役員会で承認されたというのでほっとしていて、何事もなかったかのように毎日を過ごしていた時期でもありました。
そういう時に、このシステム開発を受託した会社で某顧客に派遣されていた社員が問題を起こして会社に戻ってくるという事態があり、この男を役員がこの顧客に押し込んだという事がありました。システム開発の発注者である顧客の役員はシステム開発で何が行われているかというのは全く分かっていない素人なので、システム開発を受託した事業部の裏で糸を引いていた役員には赤子の手を引けるような感じで「プロジェクトがいよいよ終わりに近づいたのでシステムを完成させるために要員を強化するたに必要です」と言って発注会社の役員にお為ごかして、この男の派遣を押し付けたのでした。このシステムエンジニアの追加費用が無償であれば、少しは顧客思いなのかとも感じて感謝の念もでるところでしたが、それが以前よりも輪をかけた悪質なものだったので私も驚きました。
この男は会社に帰っても仕事がないので何処かに良い派遣先はないかと考えたら、文句も言わない顧客がいるというので役員が目を付けたと思います。当時、プロジェクトのごたごたについては、顧客はシステム開発完了という希望の光ですっかり目が見えない状態で、システム開発を受託した事業部に対して何の文句をつける気も起きないような状態だったので、唐突に現れた役員に対しても警戒感がなかったのだと思います。普通の顧客なら「こんなに当初計画から遅れてどう責任を取るんですか」とか「延伸費用を全部客持ちにするというのはどういう了見か」という様なことで食ってかかられると思いますが、何もシステム開発の事情が分からぬ顧客の役員は「お久しぶりで」とにこやかに出迎えたものと思います。
 
この男の派遣単価が２百万円も超えるという金額が提示されたのでした。そして、両者で費用を負担するというので半額の百数十万円の単価で契約したいということで、顧客の折衝力のなさとお為ごかして単価を倍以上に水増していたと推測しています。情報システム部員も役員が決めたことなので金には執着がなかったものとみえてさっさと合意したのでした。
結果として、延伸費用も全て顧客負担した上に、全く無意味な男の費用までも負担することになったことになったのでした。

この時、派遣される男が程度の能力を持ったシステムエンジニアなのか全く知りませんでしたが、その実世の中の派遣エンジニアの相場としてはとても１００万円なんてものは出せないレベルで高くても５・６０万円どまりのエンジニアであると思いました。
私が経験している長年のIT業界の常識では、２００万円を超えるシステムエンジニアというのは、与えられた端末でIDやパスワードを与えられればどんなシステムでも入り込んでアプリケーションどころかシステムのソフトの不具合を見つけることが出来る能力があるエンジニアと思いますし、そういうエンジニアとも付き合いがあり単価の意味については身をもって知っているつもりです。
ところが、この新たに派遣される男は口先だけはやたら物知り顔に言うだけで、端末操作さえもろくにできないと言うのを１年にも及ぶ駐在で自ら証明したのでした。自分がどう評価されるか、何をしたら評価されるのかさえも分からないような男で、他人のすることにケチをつけるような行動をしていました。
又、システム開発の会議の席上では居並ぶ情報システム部員や私を威嚇するような大きな声を出すので、大人しい顧客は何も言えないような状態でした。当然ながら、この男が劣悪な状態のプロジェクトに対して何の貢献もしなかったのは言うまでもありません。プロジェクトの最後を飾るのに、こういう変人のエンジニアまがいの男を派遣させたのは、システム開発を受託した事業部の出鱈目ぶりを総括する意味ではふさわしい人材と言えるのかも知れないと思います。
この常識が無く使えない男を堂々と推薦しますと派遣を要請したのが、システム開発を受託した事業部やプロジェクトマネージャーの裏で糸を引いていた役員でした。プロジェクトの管理の出鱈目や、システム開発の失策を全て素人の顧客に押し付けて、当然のように費用は全額負担させ、プロジェクト計画は偽装する等、本当に普通ではありえない状況を裏で支えていた役員でした。