第４８２話　黒幕の役員が表に出た事件

私が取引先の会社の情報システム部長に頼み込んで派遣社員として勤務を始めた時、私が以前に勤務していた会社の役員が、わざわざ私が派遣されている取引先の会社の役員に私に非があるかのような誹謗中傷を耳打ちして、私の自宅のパソコンのデータを調べるというようなことをしたのは前回説明した通りです。
この役員は顧客からシステム開発を受託したシステム開発のプロジェクトマネジャーの後ろで糸を引いていたのはプロジェクト開始の頃に露見していました。その後、基本計画終了では本当に作業が終了したのかどうか不明なままに基本設計になだれ込んで、その基本設計は計画より実質倍以上の工期がかかったのを偽装して報告していたという事実がありました。
そういういい加減な作業を批判的に見ていた私が、システム開発を受託した事業部やの裏にいた役員には私が邪魔に見えていたのだと想像していました。嘱託社員の契約終了後、システム開発の契約先企業に派遣されるというので、システム開発を受託した事業部のプロジェクトマネージャーがプロジェクトの邪魔をされるのではないかと危機感を感じて、私をプロジェクトに関わらないよう亡き者にしようと画策して、基本設計の延伸に次ぐ延伸のごたごたの時には知らん顔をしたのはさっさと棚の上に上げて、システム開発の発注先の役員に面会を申し込んだのでした。この行動は、この役員がシステム開発を受託している事業部の裏で糸を引いていたことを自ら露見させるものでした。
 
システム開発の開始からごたごたしているのに、顧客の情報システム部員は何の文句も垂れずにシステム開発を受託している事業部の事業部長やプロジェクトマネージャーの言いなりになっていたのは大いに問題があったのですが、波風をたてるのが嫌な体質の会社というので何事も耐えているようにしか思えませんでした。そういう体質が逆にシステム開発を受託した事業部のやりたい放題を助長したともいえると思っています。
基本計画では何で終了したといえるのかを、きちんとシステム開発を受託した事業部やプロジェクトマネージャーに求めなくてはいけなかったのですが、発注者たる情報システム部員の誰からも声が上がりませんでした。情報システム部員が心配なのはシステムが出来上がる事だけにしか目が行っていないので、そんなことはどうでもいいと大いなる勘違いをしていたのですが、システム開発という仕事に対する知識や経験がないので気づかなかったのだろうと思っています。
その後、情報システム部長が危機感を感じてシステム開発を受託した事業部に乗り込むも一人だけでの行動に限界もあり、最後には基本設計の半年延伸や本番の半年延伸という負の遺産を、システム開発を受託した事業部やプロジェクトマネージャーから押し付けられて費用も全額負担するという事態に陥ってしまいました。

私がシステム開発を発注した会社に派遣された時は、既にシステム本番時期も半年ずれて行う事が決まった後で、当時はプログラム製作を中国でしていて顧客は出来上がるのを待っているような時期でした。週次の会議でも何も議論もなく一見平静にみえるような時期でした。そういう状況を見て、システム開発を受託した事業部の裏で糸を引いていた役員は私の行動阻止を狙ったものだと思いました。
元々、この顧客は全てが受け身なので、昨年にあれほどもめた基本設計の延伸の時には何の説明にも来なかった役員をなじることもなく素直に受けいれたのだろうと思っています。情報システム部長から見れば派遣社員の私が悪事でもしたのかと思ったのかも知れませんでした。それでも私は派遣社員として何の咎めも無く情報システム部に勤務できたのは、既に１年半の契約ができてしまった後に起きた事件なのでどうしようも無いということになったのだろうと思います。
派遣先の情報システム部の派遣作業指示者である課長からは私に対して「週次のプロジェクト会議では発言を控えてください」と言ったのがこの事件の結末だったかも知れません。それはシステム開発を受託した事業部をますます増長させるだけの行為だなと感じていました。

私の勤務していた会社が私の自宅パソコンのハードディスクを調査した後、調べたシステムエンジニアが私の派遣先の企業までそのハードディスクを返却して終わりでした。他人の個人情報を全て見た役員や会社からは何の連絡もありませんでした。離職した社員の個人情報を何か問題があるかのように騒ぎ立て調べた結果何もなかったとしても、自分の会社内では個人情報管理をうるさく言っているにも関わらず、関係の無い他人の個人情報を見た事に対して何の説明や謝罪もないのは、自ら個人情報管理が出来ない会社というのを証明ことになったものと思っています。同時に、この会社の個人情報保護を声高いに言う人は口先だけで信用できない人間であるという評価もできるかとも思います。

第４８１話　役員の能力差を思い知らされた事件

私が４０歳で転職して１年後位の時期で、今から３０年程の前の話です。転職先の会社で新規事業の売上増のために色々な施策を自ら考えて実行していました。その中で貧弱な営業体制では売れないと思い、代理店による販売を切り開いていた時に、たまたま某大手情報処理会社の関連会社との縁が出来て、その情報処理会社の丸の内本社１階のショールームで展示会を開催しました。私の勤務していた会社の製品を売り込むだけでなく、同時にその情報処理会社の製品も売れるというので両社にメリットがあるというので実現したものでした。
この時、私は営業担当として若い２０代の人に交じって自ら製品説明をしていました。その本社１展示会場に、新しい販売協力というのが出来たというので喜び勇んで大手情報処理会社の課長が挨拶に会場に現れました。課長からは色々な新しい事にチャレンジしていますという様な話を聞きました。展示会の最終日にはビル最上階にあった役員用のラウンジで、展示会関係者全員に懇親会を開催してくれたという事で記憶にとどめることになったのですが、その当時の課長さんが昨年に社長に就任したというのを新聞で見て驚きました。当時初めて面会したにも関わらず、実績も無い一代理店のために慰労会を開催してくれたという気遣いは、社長になるという素質があったのだということかと理解が出来ました。
 
私が嘱託契約を継続しないと契約終了の４カ月前に上司である営業部長から宣告されて、急いで就職先を見つけないといけないと思い当時の取引である会社の情報システム部長に頼み込んで派遣社員として採用をすることに決まったのは、嘱託社員の契約終了を言い渡されてから１カ月後くらいだったので営業部長には嫌な話に聞こえたと思います。そして、私が４月に派遣社員として情報システム部で勤務を始めた頃に事件が発生しました。
私の勤務していた会社の役員がわざわざ取引先である私の勤務する会社の役員に面談して、私が会社の情報を持ち出しているとして私個人を調べてほしいという事を要求したのでした。
この顧客のシステム開発で、１年前の基本設計フェーズの終了時期の延伸に次ぐ延伸をしていた時に知らん顔をして一度も取引先である役員に言い訳にも来なかったのが豹変したのでした。この役員はシステム開発を開始するにあたり顧客役員と会議をした時には顔をだして責任者として出席していました。
当日、情報システム部長と私が役員に呼び出されると、別室で私の勤務していた会社の上司と人事部長が待っていました。情報システム部長は「こういう話は役員ではなく、まず私に話を通すのが筋でしょう」と息巻いていましたが、相手は蛙の面に小便とばかりに無表情で反応はありませんでした。
当日人事部長と一緒に自宅まで行って私の私用パソコンからハードディスクを取り出して調査をするということをしました。当然ながら会社の情報などはありませんでした、逆に私の個人情報を会社に開示されて非常な迷惑を被ったということになったのですが、当の人事部長や上司からは何の釈明もなく現在に至るということになっています。
私が会社を辞する前に転職先の会社に送ったのは、既に転職先の会社に提出した資料で、それらは全て私が作成したり関わったりしたものなので、そういう情報を消したい時は私を殺すしかなかったということです。そういう状況判断が全く出来ないという役員が揃っているという事が明らかになった時だと思いました、
大手情報処理会社の社長になる社員と弱小システム会社の役員との差がこれほど明瞭に出た時は無いとも感じたのでした。出来る人材というのは弱体企業ほど集まらないので逆に学校名とかに依存せざるを得ず採用するので、ますます弱体化は止められず、笛吹けど社員は踊らずという企業環境を役員自ら作っていることにさえ気づかないのではないかと思っています。

第４８０話　プログラム製造報告に疑惑あり

システム開発を請負った事業部からの報告内容は、基本設計での出鱈目な報告ぶりから想像できるように、顧客に提示される資料がシステム開発をしている実態に対して正確なものではなく、自らに都合のいいような内容にねつ造されているというのが何となく分かってきたような気がしていました。其の証拠は、私が嘱託を解任されてこの顧客に派遣社員として仕事をしていた時に私自身がシステム開発を請負った事業部から提出される資料を解析して改ざんの証拠を見つけました。その内容は後ほどに書く事にして、基本設計は９月末に終了して１０月から半年も掛けてプログラムの製造が中国で行われたのでした。その中国でのプログラム製造についての仕事振りについては一切開示もされず説明もされなかったので、毎週プロジェクト会議で報告されるプログラムの製作本数が唯一のものでした。
 
先回お話ししたように、１０月以降はプログラムの製造フェーズなので顧客との会話はない筈でしたが、毎週のプロジェクト会議では基本設計書の間違い・訂正が毎週のように行われて、基本設計書の訂正が殆どなくなったのは年を明けてのことだったと思います。
何が不思議化と言えば、毎週のように設計書の修正が入るのに、それがプログラムの製造変更にどのような影響があるとか、製造の遅延に影響するかが全く説明がされないことでした。システム開発を受託した事業部では顧客の情報システム部担当者から基本設計書の間違いや訂正の指摘があると「はいはい」と生返事をして、後日設計書を修正して顧客の担当者に送り返すという作業が繰り返されるだけでした。顧客の担当者も基本設計書が修正・訂正されてやれやれと思っているだけで、その先の事には全く思いも及ばないと見えました。
基本設計書の変更があるならば、当然ながらプログラム仕様書も変更されるはずであり、そのプログラムに関わるデータも修正するかどうか検討をしなくてはいけないはずなので、基本設計書の少しの修正でもプログラム製造には大きな影響を与える大きな要素です。それ故に、システム開発ではフェーズを切って、仕様を確定してから次のフェーズに入るということを原則をとしているのです。
金魚の糞よろしくぷちぷちと基本設計書の修正が１０月以降も発生しているにも関わらず、同時に重要なサブシステムの基本設計書は１２月末に何とか完成にたどり着いていたので、プログラム製造は全く問題なく進んでいるという報告に違和感があったのは当然でした。当然ながら、違和感を持ったのはプロジェクト関係者では多分私だけで、顧客はそんな疑問を微塵ももたず報告通りに順調なのだろうと理解をしていたと思います。プログラム開発の手法を理解している人には、上記のような状態であれば、プログラムの製造が順調なはずであるわけがない事は自明の理だと思いますが、素人集団の顧客には全くそういう意識はなかったと思います。

このシステム開発で新規に開発するシステムの範囲が小さくて割合に平易なものだと分かって、システム開発を受託した事業部では顧客に報告をしても理解出来ないからと、自らに都合の良い理屈をつけて適当な報告をこのプログラム製造の時期に行っていたのではないかというのが結論です。基本設計のけじめもつけられないで、プログラム製造を開始すること自身がシステム開発を理解していなかった証と理解しています。そういう連中を陰で支えて放置していた役員も同様の技術レベルで、顧客から受託した仕事に責務を果たしていなかった罪は重いのではないかと思っています。

第４７９話　基本設計のごたごたが起こした出来事

スケジュール上、１０月から開始されたシステム開発の制作フェーズは６カ月もあって、その期間は顧客の情報システム部員は一休みのような状態となり、毎週開催されるプロジェクト会議も本当かどうか全く分からないままにプログラムの製造は順調に進んでいますという報告が、システム開発を受託した事業部から行われたのでした。
システム開発の基本設計フェーズでの色々な面倒な事件があって、営業部長は逃げの一手だけなのを冷ややかに見ていた私は自然と距離が出来て、１２月の某顧客の忘年会会場で嘱託契約の延長をしないとの宣告をされたのでした。翌日、私は顧客の情報システム部長を訪問して派遣での社員採用をお願いして１年半という期間の勤務をすることになったのは以前のブログで紹介した通りですが、その他にも社内では出来事が起きていました。　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　それは、私の部下の新入社員が転職するという事件でした。職場というよりも営業という職種に不満があったようで、自ら外資系コンサル会社への移転を決めたという事を告げられたのでした。
私の営業の片腕というよりも事務処理を一手に任せていたので、一人前になるずっと手前で会社を辞するのは如何なものかというようなアドバイスをするにとどめました。本人は会社を９月末に退社して、１０・１１月はカナダでホームステイして語学研修をするというのですっかり自らの道を決めていたので何も言うべきことはありませんでした。色々な人生があるのだなという風に思えると同時に、私は会社という砦の中でしか生活を出来なかったので、会社を辞めて語学研修をホームステイでするという発想には若者らしいという驚きだけが残った事件でした。
この時、結構なかわいがりを見せていた営業部長は怒り心頭で、自らの評価が下がるような事をしやがってという様な態度をあからさまにしていたので、外目から見ると気の小さい人間だというのが分かってしまうような気がしました。それは、このシステム開発の基本設計での顧客対応にも表れて、社内のろくでもない情報を信用して顧客の情報システム部長への対応を全くしなかったとか、偽装された作業の見積書や決裁書に内容を確認する事無くめくらばんを押していたとかも、そういう人間性が現れていたというのを、この新人の退社騒ぎで再確認したということになりました。

この年に、顧客ではシステムの災害対策としてシステムの一部移転が行われて、これも１月から別プロジェクトで走っていたのですが、こちらは特段に大きな問題も無く進んで、年末にはサーバーや関連機器の自社ビルからデータセンターへの移転も終了しました。移転の際に、忘れ物があるといけないといので、運搬する要員や車に予備を準備していたことが当たって、２度目の予備配送で忘れ物をデータセンターに届けるという事も経験して、物事には予備ということが重要だと思い知らされたのでした。
システム開発の基本設計でのごたごた中にも、何度か他ベンダーとは言わないまでも、社内の他の事業部で引き受けてくれないかなと考えたこともあります。システム開発を受託した事業部では自らの能力はさておき、自らしている仕事がまっとうなものであるという固定概念しかないような連中の集まりなので、自らの仕事がおかしいとは思わないし、反省とか客観評価が出来ない程の能力レベルの集団なので最後まで実現は出来ませんでした。データセンターの移転のような単純な作業でも忘れ物をするようなことが起きるくらいなので、ましてもっと困難なシステム開発においては受け皿としての他者が必要ではないという事を、深夜の移転作業確認中に思った時でした。
顧客の情報システム部長は、システム開発を受託した事業部の基本設計での余りの酷い対応に「稟議がお宅の会社で通っているので今更会社を変えてとは言えないが、せめてまともな人にお願いは出来ないかね」というような話題が私との会話に登ったこともありました。顧客が「お前は首だ」というのをはっきりと言えなかったのは、会社の風土からすれば仕方なかったと思いますが、システム開発等の難しい仕事に対してはそういう事が言えるくらいの判断力や行動が求められるのかとも感じました。

第４７８話　基本設計を終われない理由

システム開発の基本設計は顧客の情報システム部長の英断で、とにもかくにも１月開始から計画の５月末を大きく超えて９月末には、形の上では完了ということになりました。この時、システム開発を受託した事業部では自らの失態を隠すために、基本設計の８・９月を次フェーズの詳細設計を２ケ月間実施したことにするという偽装を行い、それに加えて次フェーズの準備をしていたという名目の費用を請求するという、顧客の見識の無さをかさにかけて、前代未聞の犯罪的行為を堂々と実行したのでした。こういう行動は金さえもらえば何の問題も無いという、営業窓口のこれも見識の無い営業部長によって問題視されることなく社内で決済がされていったのでした、そういう意味ではシステム開発を受託した事業部だけでなく、企業としては営業窓口の責任も大きかったのではないかと考えられます。まともな仕事もせずに金だけ請求するというという行為を正当化していたという意味の重みをどれほど理解しているかという、今どきのガバナンスの意識がどれほど無かったのかという証左にもなっていたと思われます。
 
形の上では9月末までに基本設計書は耳をそろえて完成していなくてはならなかったのですが、これも以前紹介したように1つの重要なサブシステムはシステム開発を受託した事業部のプロジェクトマネージャーが判断を誤り2度も外注エンジニアを交代しても対応できず、仕方なく社員のエンジニアに交代して漸く情報システム部員との会話が成り立っいたという経緯があり、このサブシステムの基本設計書が出来上がったのは12月末、正確には翌年の1月中旬だったので、都合1年もかけて何とか設計書ができたという事になりました。延伸した費用は全て顧客持ちだったので、システム開発を受託した事業部はいたくもかゆくもなかったという風にしか理解していたのではないかと思います。
それでは、その他の業務は9月末で全部が完成していかと思いきや、毎週のプロジェクト会議で情報システム部員からぽろぽろと訂正や改変の要求が出ては基本設計書の修正がされていて、一体全体この基本設計という作業の監督は誰がしているのかという怒りが私はこみ上げてきました。
一方、顧客の情報システム部員にはそういう感情はわかないようで自分の担当の業務部分だけが出来ていればそれでよしとするようなプロジェクト感覚が絶無だというのかわかるような態度でした。それがシステム開発を受託した事業部では好都合で、時間を忘れて対応さえすれば何も文句は言われないという理解をしているとあからさまな態度を示していました。いやはや、もう言葉さえないという文言をこのブログでは何度も使っていましたが、この時もその言葉が出た時でした。顧客は自らがこけにされていることも知らずに、システム開発を受託した事業部のシステムエンジニアと丁々発止会話をしていることにだけ満足感を示しているのに違和感を持たざるを得ませんでした。

10月からはプログラムの製作フェーズというので顧客は何もすることがなく、毎週のプロジェクト会議ではプログラム製作の一方的な進捗状況を聞いているだけで終わりでした。しかし、形の上では基本設計が5月から9月に延伸したので、以後のフェーズも自然と遅れさせざるを得なくなり、本番開始を翌年１２月末から翌年の5月連休にせざるをえないとシステム開発を受託した事業部からは提示があり、システム開発については素人の顧客は言いなりになるしかありませんでした。システム開発を受託した事業部では費用は当然すべて顧客持ちという風に考え、顧客は費用よりもシステムが出来上がることしか頭にないので、費用は全て顧客が支払うということで問題には上がりませんでした。
客観的観点とかプロジェクト視点からは、延伸の理由がシステム開発を受託した事業部の不手際にあり、その延伸費用についての議論がされないことが問題と思われました。ここがシステム開発を受託した企業としての見識が試される時でしたが、金さえもらえばという風潮が上から下まで染みわたっている風土では無理というものでした。顧客が費用増加になっていると気づいた時は、既にプロジェクトも終了してすべての費用を支払い終えた後というのは、如何にも遅きに過ぎたという事だと思いました。

第４７７話　基本設計の最後まで続く無責任

システム開発の基本設計が１月中旬から開始され、予定の５月末が毎月の様に延伸されて、最後には顧客の情報システム部長が「ええ加減にせんかい」と怒って９月末に止めたという状況でした。８月末には基本設計作業中止指示が顧客の情報システム部長からあり、９月中旬には始末をつけろという顧客の情報システム部長の指示は、システム開発を請負った事業部では対応が出来ずに結局９月末になって漸く終われたというような状況でした。システム開発を外注に丸投げしているので急には止まれないというのが目に見えた時でもありましたが、そもそも計画よりは相当に遅れているという事に関しては鈍感なように思えて、このシステム開発を受託した事業部はまともなシステムを開発した経験がどれほどあるのか甚だ疑問に思えたのでした。
基本設計は元々５月が９月末に延伸したのですが、プロジェクト管理上は基本設計を７月で終了として、８月から９月は詳細設計とするという風にシステム開発を受託した事業部から提示されたのでした。提案では７月から１０カ月間で実施する「詳細設計・製造・試験」というフェーズを分解して、「詳細設計」と「製造・試験」に分けて体裁繕いをしたのでした。システム開発を受託した事業部が行った歪曲行為という事実だけがのこりました。
そして元々の提案にはなかった詳細設計準備とか称した新たな費用も請求するという事があり、顧客は不満気ながらもシステムを作るのが最優先とばかりに、システム開発を受託した事業部の要望を全てのみ込んでしまったのでした。
同時に、詳細設計というのは基本設計フェーズで実施しているので、これを認めると費用の二重取りになりますと情報システム部長に解説をしたものの、情報システム部長はシステム開発を受託した事業部の説明を鵜呑みにして了解したのでした。

システム開発を受託した事業部の基本設計書は、業務仕様書にプログラム仕様書もついていて、その内容は世間一般でいうところの基本設計書と詳細設計書を同時に作成するというものでした。基本設計フェーズに入る時、システム開発を受託した事業部のプロジェクトマネージャーは「これが当社の標準の仕様書です」とだけ説明して、その設計書というものはプログラム仕様書も含んでいますとは説明しませんでした。顧客に基本設計書をチェックしてもらう段になり、顧客の担当者がプログラム仕様書は細かすぎてチェックできませんという事があったのは以前のブログで紹介した通りです。
システム開発を受託した事業部が基本設計書にはプログラム仕様書がついているというのを説明しなかったというのは、自らの仕事のやり方を顧客に説明したくないという理由があって説明をしなかったものと推測されます。この時、プログラムを製作するのは中国の会社なのですが、その発注経路が社内の取引利害があって二手に分かれていたということもあったのかもしれないと思います。最後まで顧客に対してそういう事実は説明されることはありませんでした。
そこには物さえできればいいという安易な考えがあるとしか思えませんでした。品質を考えていないという事の裏返しにもなると思われるものです。
プログラムの製作にあたり標準・試験とかはルールにのっとり行われるものですが、システム開発を受託した事業部では試験することも含めてすべて外注丸投げにしていたので、品質も２つの発注ルートに分かれたので、微妙に違うのではないかと考えるのが普通と思います。一つのシステムに２つの違う品質のプログラムが存在しているとも推測され、そういう製作ルートが分かれたのも障害発生の遠因と考えられます。
システム開発を受託した事業部では、基本設計フェーズの遅れの原因を全て顧客にあるとするのに対して、顧客では情報システム部長一人がシステム開発を受託した事業部の御託の反論を孤軍奮闘して作成するばかりで、情報システム部員は仕様書のチェックに忙しいというばかりで誰も部長を支援する人はいませんでした。情報システム部長は疑問をメールで窓口の営業部長に送付をするものの、営業部長は対応するのが嫌でメールをシステム開発を受託した事業部の関係者に転送するだけに終始したので、基本設計延伸問題はシステム開発を受託した企業としての対応は絶無のまま終わるということになったのでした。

第４７６話　根っこは東京都の豊洲問題と同じ？

システム開発プロジェクトの基本設計フェーズの終了時期が毎月の様にどんどん延伸された背景は、現在マスコミをにぎわしていると豊洲の新市場問題と根っこは同じではないかと思います。小池知事から発言の有った東京都の「無責任」「弛緩」とかいう言葉が、システム開発を請負った事業部にそのままあてはまるのではないかと思っています。
当時、システム開発を受託した事業部は、社内にプロジェクトの進捗を審査する会議で基本設計終了時期が毎月延伸する理由を説明していたと思います。ここでは社長以下役員と幹部社員が出席して報告を聞いたはずなので、基本設計が延伸したことや延伸費用について役員は説明を聞いたと思います。
説明者であるシステム開発を受託した事業部のプロジェクトマネージャーや事業部長は終了時期延伸原因は顧客にあり且つ延伸費用は全額回収できますという説明をしたと思われます。

今までに記述したように延伸した理由は素人集団の顧客ばかりでなく、何重もの失態を重ねたシステム開発を受託した事業部に過半以上の責任はあると考えられます。そういう実態を社内の審査会議では説明せず、一方的に顧客を悪者に仕立てて報告し、プロジェクトとしては何の問題もありません、出来の悪い外注は入れ替えます位の事で終わっていたと思います。社内の審査会議では、そういう偽作の報告を受け身で聞くだけで、審査とは名ばかりの会議であったというのがこの時に裏付けられたようなものかと思います。審査会議でプロジェクトは順調ですと報告する側と、碌な意見も言えない程度の大勢の役員が揃って、決められた会議の時間を過ごしていただけの事と思われます。ここが、東京都の豊洲新市場建設問題と同じと思われる所以です。
形ばかりの審査会議で承認されれば、プロジェクトの内容がどうであれ前に進むという事で、そこには会議という体裁があるだけで、実態は誰も本当の事を告げない解明できないという無責任体制が存在したということでした。無責任ではなかったと反論したいのならば、このプロジェクトの収支が大幅黒字になつた原因を自ら解明する必要があると思います。

そういう形ばかりを大切にするのは良しとしても、民間会社でありながら自分の仕事の実態が分かっていないというのであれば、会社として存続の価値があるのかどうかという所まで行きついてしまいます。社内には仕事やプロジェクトを監察する法務部とか監査部という組織もあるのですが、こういう事件が発生しても自分の都合を主張するのが主眼で、取引先の不都合や損失には何もしないという身勝手な組織というのが明らかになるのでした。
本件の場合は全てが現場の事業部や裏方の役員で仕組まれたことだと推測されますが、そうなると社内のガバナンスが全くなかったという事になります。会社という組織が役所同然の形ばかりで実態は現場任せというのは、東京都の豊洲新市場問題と相通ずるものがあると感じた次第です。
システム開発の基本設計終了時期が延伸に次ぐ延伸という状況でも、システム開発を受託した事業部の事業部長や役員は顧客の役員に一度も説明もすることもなく、プロジェクトマネージャーが１カ月数千万円という費用を「終わりませんので延伸します」という一言で済ませていたというのは驚くべき不作為ではなかったかと思います。法務部では契約がありますからという言い訳が聞こえそうですが、契約内容そのものに問題があるにも関わらず承認していたとすれば、それこそ不作為ではなかったのでしょうか？
民間会社なので豊洲新市場問題のように糾弾されるようなこともなく、時間とともに忘れ去られるような事件だとは思いますが、会社の無責任体質が明らかになっただけで誰も責任を負わないという事も同時に明らかになったと思います。
この事件の背景には顧客の軟弱な体質というものがあるのですが、それを逆手に取っての悪質極まりない行為が行われたものともいうことができると感じています。 

第４７５話　情報システム部長の英断の評価

システム開発の基本設計フェーズの事件はサラリーマンという職業の裏側をも浮かび上がらせたのでした。システム開発を受託した事業部の事業部長やプロジェクトマネージャーは、相手の立場や事情を鑑みるというような器量は全く無く、ひたすら自分が損をしない、儲けをいかに増やすかだけを考える単純な連中であったかを自らの行動で如実に示したのでした。勿論、システム開発の出来栄えなどは眼中になく、物さえできれば万々歳というレベルの持ち主であったと思います、それが本番後の障害につながっている根本原因とは誰も気づいていないのではないかと思います。
システム開発を受託した事業部の事業部長とプロジェクトマネージャーが４月中旬に顧客の情報システム部長に基本設計の延伸をほのめかし、原因は顧客にありと一方的な通告をされた情報システム部長は苦境に立たされたのでした。４月には丁度役員が昇格する時期に当たり、全社挙げてのシステムリニューアルの計画が延伸するなどという報告は役員会では出来ない状況でした。情報システム部長は仕方なく計画は資料では予定通り進んでいると報告をせざるを得ないという、苦しい胸の内を私は聞かされたのでした。
この後、当然ながら顧客の役員会が終了して役員の昇格も決まった後に、基本設計の終了を当初契約の５月から６月末への延期を、システム開発を受託した事業部から一方的に押し付けられたのでした。これが７月、８月、９月へとどんどん延伸した状況は以前のブログで紹介した通りですが、延伸の原因はプロジェクトを仕切れないシステム開発を受託した事業部の責任であることは明らかでした。
システム開発を受託した事業部では基本設計終了時期が延伸しても費用は貰えると、気の弱い顧客のプロジェクトマネージャーや顧客の体質を見抜いていたので、大船に乗ったような気分で「仕方ないでしょう」というような余裕の高慢な態度でどぎまぎする顧客に費用を請求し、当初計画より売り上げや利益が自然にどんどんと増えて笑いが止まらないという状態になっていったのでした。
 
基本設計開始後、週次のプロジェクト会議で毎月月末に「終わりませんので期間を延伸します」とシステム開発を受託した事業部のプロジェクトマネージャーから顧客に一方的に報告されるばかりの状況に、当然ながら顧客の情報システム部長は怒り心頭でした。自分の部下であるプロジェクトマネージャーが呆然とするばかりで何の折衝もしないし対応もできない事に対しても少々怒ってはいるものの、自社都合の人事異動で決まったプロジェクトマネージャーなので変えるわけにいかずジレンマがあったようでした。
８月にはシステム開発を受託した事業部の基本設計の仕事量が減ったと見えて報告量が少なくなっているものの、システム開発を受託した事業部のプロジェクトマネージャーはさらに延長しそうな状態であることに顧客の情報システム部長が気づいてかなり焦っていました。この勢いでは基本設計は９月どころか年末までかかってしまうのではないかと想像される状況でした。

プロジェクトの延伸は自らの責任ではないとシステム開発を受託した事業部の事業部長やプロジェクトマネージャーが宣言したにも関わらず、毎月延伸されている状況に対して作業が遅れているという説明だけで一方的な期間延伸を宣言されている状況は、誰から見てもおかしな状態でした。顧客の情報システム部員たちも週次の会議の終了後「又、延長になりました」という感想を述べるだけで反論とかは殆どなく、システム開発を受託した事業部の報告する内容が事実と異なっていることに対してのみ反発するだけなので、システム開発を受託した事業部のプロジェクトマネージャーが「次回から改めます」と口先でその場をやり過ごして終わりになるのでした。信じられないような光景とはこういう事なのかというのを毎週目にしていたということでした。
８月末も近づくと、顧客の情報システム部長も危機感を強めて「こうなったら期限を切って基本設計を終わらせないと何時までも終わらない」と言って、基本設計の９月末終了をシステム開発を受託した事業部に宣告したのでした。これは、このプロジェクトでの唯一のまともな決断がされた時だと感じました。システム開発を受託した事業部の言いなりに基本設計を延伸し続ければ、多分１２月末が基本設計終了と言いかねないと想像されました。基本設計の１月から５月の５カ月間の計画が、何と１２月終了となれば計画に対して２倍以上の期間になり、とんでもない基本設計期間延長となるおそれがあったという事です。システム開発を受託した事業部では良い金づるが出来たとでも思ってどんどんと延伸して費用を貰う事を思いついたのかもしれません。

システム開発を発注したした側にとってみれば、大きな基本機能が１システム無くなった上に基本設計期間が倍以上になるとは思いもつかず唯々絶句すべき状況があったという状態でした。そういう状況でも、顧客の情報システム部員は、システム開発を受託した事業部のシステムエンジニアに対して怒りもせず、自ら淡々と余裕で残業にいそしんでいたという、何とも理解不能な状況を眼にしていました。
顧客の情報システム部長の英断が、自身の会社でこうむる損害を減らしたというのは大きな功績だと思いましたが、残念ながら社内ではあまり評価されないようでした。社内が役所体質で仕事の出来には差別がなく、論客であり行動力のある人は敬遠されたのではないかと思います。
システム開発を請負った事業部の言いなりになって基本設計を延伸してプロジェクト進めていれば、本番予定は翌年の１２月末がこの基本設計遅れで半年延期されて５月になったのですが、更に半年伸びて当初計画から１年延期され、数億円も費用を請求されることになったと推測しています。

第４７４話　混乱に乗じて費用をむしりとる事件

システム開発の基本設計が２月に開始され、基本計画のごたごたで終了が１カ月延期された６月末の１ケ月半も前に、システム開発を受託した事業部のプロジェクトマネージャーと事業部長が打ちそろって顧客に基本設計の延伸の理由は顧客にありと顧客の情報システム部長や課長に説明していたのは以前に紹介していた通りです。
この時期に私が情報システム部長と会話をしていて感じたのは、顧客の情報システム部長は基本計画での終了のごたごたがあって「基本設計は本当に６月に終わるかな」と一抹の不安を抱いたのでした。システム開発の内容は理解出来ないにしても、週次の会議での情報システム部員とシステム開発を受託した事業部のシステムエンジニアと称する面々とのやりとりを聞いていて一抹の不安を抱いていたのが見事に的中したということになりました。そういう不安を抱いている時に、基本設計が延伸しそうなのは顧客責任というのをシステム開発を受託した事業部の事業部長とプロジェクトマネージャーが説明をしたというので、情報システム部長は社内で苦境に立たされたという事になりました。
 
先回紹介した１つのサブシステムでは基本設計はまるまる１１カ月以上もかかったという事実を紹介しました。サブシステムと言っても顧客業務としては重要なもので、情報システム部でも担当者が１名専属でついている位に内容は複雑な内容でした。業務内容を通り一遍に聞いても直ぐには理解が難しいと思われるような業務システムでした。基本計画のフェーズで、システム開発を受託した事業部のシステムエンジニアが理解をしていなくてはならない筈のものでしたが誰一人としできていませんでした。その証拠は、基本設計フェーズでの設計書作成では新しい外注がアサインされたものの内容が理解できないのか設計書が間違いだらけで週次の会議の都度修正を要請されているものでした。４月の段階では、設計書が出来ないので、外注のシステムエンジニアが２人目に交代をする時期であったと思います。
レベルの低い外注の作成する設計書の出来栄えとか間違いとかの修正や確認は、本来システム開発を受託した事業部で行うべき仕事でしたが、システム開発を受託した事業部では週次の会議の席上で顧客に対して「次週は管理します」と口先では会議での失態を挽回するような事を言うのですが、これが毎週毎週繰り返されるのだけでした。システム開発を受託した事業部の、無責任なプロジェクトマネージャー、口先だけ達者で実は何も対応しない統括プロジェクトマネージャー、何時も無言で何をしているのか不明な副事業部長が毎週の会議に漫然と出席して、技術レベル低い外注会社や社員の出来の悪いシステムエンジニアのやりたい放題が説明される会議が延々と続くのでした。
会議に同席している私でさえ恥ずかしくなるような内容のやりとりがされたのですが、そんな状態でも顧客の管理者は怒りを露わにしないし、担当者もほんの時々しか怒らないのが不思議で仕方ありませんでした。それはプロジェクトの内容が十分に把握できていないという事と、対応の仕方が分からないと言う事に起因しているのかなと感じていました。
こんな状態でまともなシステム等出来る筈はないというのが感想でした。私には最早制御不能なプロジェクトになっていて、システム開発を受託した事業部のレベルでしかシステムは出来ないのだろうと想像するばかりでした。

こういう混乱している状況が毎週続いている時に、システム開発を受託した事業部の事業部長とプロジェクトマネージャーが基本設計の延伸をほのめかして、その原因は顧客にありと言ったので、週次の混乱した状況を見聞している情報システム部長は青天霹靂という事件だったと思います。挙句の果てに実際に基本設計期間は無期限に延長されるような事態になり、その全て費用用を顧客が負担すると言う前代未聞の事実が残ることになりました。
当時のシステム開発を受託した事業部では、週次の会議で揉め事が続いているので基本設計書は予定通り出来そうにないのを薄々感じていて先手で大人しい相手に責任を押し付けて金を取ろうと考えたのだろうと推測されても仕方のない状況であったと思います。挙句の果てに、プロジェクトの採算が良かったとして会社から表彰なんかされているとしたら、この事件が会社として正しい行為であったのを認めたことになります。
当時の議事録とかを読み込んでいけば上記の事実が明明白白の事件として明かされると思います。裁判沙汰でも起こさない限りそういう事はないと思いますが。
当時の状況を振り返ると、全くもって酷い事件があったものだと思いますが、顧客はシステム開発完了後はこういう事件は総括もされることもなく、日々の障害対応が仕事のように感じて淡々と行動しているのでないかと思いますが、その遠因はすべてこの時期に生み出された遺産であると思っています。

第４７３話　聞けば聞くほど変な話がまかり通る会社

このシステム開発プロジェクトで基本設計期間の終了がほぼ無期限で延期された原因は、システム開発を受託した事業部では事業部長自身が原因は顧客にありと大きく出たのですが、実際は殆どの原因はシステム開発を受託した事業部の社員や外注会社のシステムエンジニアのレベルの低さにあったと思います。
基本設計は当初計画から遅れる事、１月から開始して６月には終わるところ、７月、８月とずるずると「終わりません」と週次のプロジェクト会議でシステム開発を受託した事業部のプロジェクトマネージャーが発言して延期されたのは以前のブログで紹介した通りです。
この時、私は控室でシステム開発を受託した事業部の社員に「今までにこういうシステム開発のプロジェクトは経験があるんですか」と質問すると「これだけの規模のものはありませんでした」という答えが返ってききて、やっぱりシステム開発というのがプログラム開発と勘違いしている位のレベルと分かりました。
 
このシステム開発では当初５つの機能の開発で受注したものの、費用が予算よりオーバーするという理由で機能を４つに落として基本設計に取り掛かっていました。この４つの機能のうち、既にオープン系で稼働しているシステムが３つあるので実質的に新規に開発するのは基幹業務の１つだけでした。それに加えて、経理とか人事とかは別にシステムがあって開発対象外なので、言い換えれば基幹業務の一部のシステム開発と言えるものでした。機能を落としに落として、既存の３システムの焼き直しに新規の１システム開発というものなので極めてハードルの低いシステム開発と考えられるものでした。
それくらいに簡素なシステム開発の基本設計期間が何故遅れたのかと考えると、原因はシステム開発を受託した事業部がシステム開発の基本設計を経験したことが無いとしか思いつきません。
簡単なシステム開発である事はその中身を見れば分かるので、基本設計期間延長の原因を全て顧客のせいにするのも如何なものかと思われるは私だけでは無く常識ある人ならば誰でも考えられると思います。それをあたかも顧客に問題があるように説明した、システム開発を受託した事業部のプロジェクトマネージャーや事業部長の行動は「傲慢・強欲」のなせる業かもしれませんでした。
基本設計フェーズの期間は６ケ月を計画していましたが、週次のプロジェクト会議の報告を聞いていて実質的に殆どのが終わりと感じたのは９ケ月後で、一つの詳細機能は１１ケ月かかりました。
基本設計の作業期間は計画よりも１．５倍から２倍かかった計算ですが、顧客にはそういう感覚は全く無くひたすら早く終わってくれればという事だけに終始して、延長費用問題は情報システム部長が少しは抵抗したものの、最終的には顧客は延長した費用を全額支払ったというのは以前のブログでも紹介した通りです。延長費用支払を要求したのはベンダーとしての社内ガバナンスが全く無い事を露呈させた、極めて理不尽な請求と言わざるを得ないものであったと思います。

更に、詳細機能のうちの一つは１１ケ月もかかったのは、最初の５カ月の間に担当する外注のシステムエンジニアが能力が追いつかず２度も担当を交代させて実質的に遅れの原因となったのでした。これは明らかにシステム開発を受託した事業部のプロジェクト管理ミスでした。
外注のシステムエンジニアで対応出来ない事が分かり、最後に費用の高い社員のシステムエンジニアに対応させて何とか６カ月かけて完成したのでした。この件は明らかにシステム開発を受託した事業部のミスでした。
この事例のように明らかに判明したミスの他に、小さなおかしなミスが毎週起きてそのたびにプロジェクトマネージャーが「次週には改善します」と言うものの同じミスが繰り返されたのでした。顧客も厳しくは追及しないのでそれが延々と続いたという時期であったと思います。そういう意味では顧客は毅然とした態度が取れなかったのも問題と思いますが、顧客の社内が厳しくない環境なので対応が出来ず、最初から最後までシステム開発を受託した事業部のシステムエンジニアと称する連中に押し倒されぱなっしという状況であったと感じています。
この時期に、システム開発を受託した事業部のプロジェクトマネージャーがシステム開発内容を何も把握していない事が明確になったのですが、この時に気づいても手遅れという状況だったと思います。
基本設計が延伸延伸という状況になっても、費用が発生するので全て顧客に請求するという発想しか頭になかったというのが実態であったと思うと、最早言うべき言葉を持てないというのが感想です。