第５８１話　サラリーマン生活４８年の振り返り　転職した会社（３９）　企業の暗黒面２

役所体質の顧客の基幹システム刷新について、システム開発を受託した事業部の問題の底に潜む問題は何なのかというものを考えています。先日、麻生大臣がセクハラという罪は無いという発言をして物議をかもしていましたが、麻生大臣の発言は責任回避をしているだけの事なのは明白です。
役所体質の顧客の基幹システムのシステム開発で引き起こしされた問題を見ていると、システム開発を受託した事業部は麻生大臣と同様の意見を持っているかもしれないと思いました。役所体質の顧客の基幹システム刷新プロジェクトで顧客の意向とは全く正反対の実務が粛々とあたりまえの如くに実行されて、システム開発を受託した事業部はプロジェクト契約が終わったので金の切れ目は縁に切り目ですと言ってさっさと終了してしまいました。
実行した作業に対して顧客が未完を指摘しても責任を感じている姿勢がなかったのは、自身の行った仕事に対しての責任回避をしていたと疑われても仕方が無いという風に思います。別の表現を借りれば、責任回避というよりも自分がプロジェクトで行った仕事の内容が正確に理解出来ていないので、顧客から色々な不具合を指摘されても何のことでしょうかと訝しがり、プロジェクトの不具合は顧客に責任があるのではないかとさえ考えていたのでないかと想像されて、受託責任という一般常識という見地から考えると信じられないとしか言いようが無いと思います。これもある意味、企業の暗黒面が表出したというべきことかも知れないと思います。

こういう事態を起こしても社内で社員や組織を守るべく波風が立たないようにする企業風土は何処でもある話と思います。しかしながら、役所体質の顧客の基幹システム刷新というプロジェクトについて、契約ばかりを重視してプロジェクト実態を把握できなかったというのは企業のプロジェクト管理や実行能力が無いというだけでなく、そもそも情報処理業者としてシステム開発を生業と出来る程の能力があるのか無いのか甚だ疑問であるということも浮かび上がったと思われるのですが、そういう事実にさえ気づいていないというのは正に企業に暗黒面があるということではないかと思えます。
本件プロジェクトについての遂行にあたって契約書上の文言に留まらず契約内容の遂行事実について、法務部からは何の問題提起がされなかったというのも、情報処理を看板とする業者としては如何なものかという疑問が浮かび上がりました。法務部の社員は契約書の細かい文面ばかりしか確認出来なくて、契約内容の業務実態が把握出来る知識や経験が無い事務系ばかりなので、自分の会社の社員がやらかした契約書に記載してある業務の不履行や能力不足による不手際も指摘できず問題提起出来ないと推測されます。そうなると、情報処理業者としての自覚が役員や管理職にないという実態をも浮かび上がり、会社の看板と遂行している実務との差異があるという疑問が呈されることになると思われます。これも、会社の暗黒面と言えば言えることかも知れません。
こういう企業体質に気づいているのは極めて少数派と推測されますが、前のブログで書いた通りに自身で考えるという思考能力問題に加えて、業績の目先だけを追うのか追わざるを得ないような管理があって、問題があっても何事も無かったことにしたい企業風土という組織として機能が不全であることも、役所体質の顧客の基幹システム開発で引きこされた数々の事件の根底にあったものではないかと推測しています。

第５８０話　サラリーマン生活４８年の振り返り　転職した会社（３８）　企業の暗黒面

役所体質の顧客の基幹システム刷新プロジェクトで発生した事象については過去のブログで時系列的に紹介をしましたが、この段に及んではプロジェクトがほぼ事件と言ってよい程の衝撃的な出来事に終始した背景を感想として書いています。現状は、顧客の立場からは発注した責任という立場があり技術面でも素人という事から、刷新した基幹システムで色々な変な事象が発生しても、その事象が基幹システム刷新プロジェクト作業の原因で発生したものかどうかの判別は顧客で行うのは困難と思われる場合が多々あると想像され、基幹システム刷新を受託した事業部の真意の程は定かでないと想定される報告書を鵜呑みにせざるを得ないという状況ではないかと想像をしています。
そもそも、この基幹システム刷新プロジェクトが情報処理業者によって普通に行われた仕事であったのか、それは事件ではなかったのかというのは、発注した顧客や受託した情報処理業者の各々の担当者、管理者、役員という立場によって見方が変わると思いますが、ここでは第三者という見地から見たら、どう考えても事件であるという風にしか思われないので色々な考えが巡って縷々綴っているようなことです。その原因や背景を色々と考えだすときりがないという風にも感じていて、以前のブログでは企業の暗黒面が現れたシステム刷新プロジェクトであったと感想を述べましたが、その暗黒面を突き詰めると何が出てくるのかという事を探っているという事でもあると思います。それは突き詰めるという事は企業の哲学的意味を考える機会にもなると思います。

私の勤務していた会社では管理者による早朝読書会なるものがあったように記憶していますが、その読書会で読まれる本が街の本屋の棚に入れ代わりたり変わり並べられる実用本ばかりで、思考を鍛えるという観点ではなく、他社の成功事例を滔々と読んでいたのは役員の能力レベルが知れて呆れていた過去を思い出しました。考え方によっては、こういう場面が企業の暗黒面の一部が表象していた事実であるとも言えるかも知れないと思います。
サラリーマンにとって仕事をするうえで求められる能力は多々ありますが、一番の本質的なものは自身で思考するということではないかと思います。入社年次によって思考内容や程度は変わりますが、普通にルーチンワークをしていても普段から思考するという態度が身についていれば、ルーチンワークから何かを学び取り改善の要求が出てくると思い、そこに進化が生まれると思います。そういう仕事の姿勢が企業の実力というものにつながると思いますが、昨今は素人経済記者が新聞紙上の記事を埋めるために書いているとしか思われないような、目の前のことをうまくやればよしとする所謂ベンチャー風土をもてはやされているのは何とも本質的なものを置き去りにする風潮が現れていると感じています。
何度もここで書きましたが、私の勤務していた会社では役員の思考程度が本質から離れて即席の業績ばかりを考えるので、如何にも一見役立ちそうに見えるものの思考能力に疑問があると見える、外資系コンピュータ会社からの弁舌爽やかな口先転職社員が社内を闊歩していたのも思い出します。
役所体質の基幹システム刷新のプロジェクトで現れた色々な事象というか殆ど事件と思いますが、そういう事態を招いたのはシステム開発を受託した事業部だけでなく関連した管理者や役員の基本的思考能力の程度問題が根底にあったのではないかとも推察できると思っています。

第５７９話　サラリーマン生活４８年の振り返り　転職した会社（３７）　覚悟を持つとは

システム開発に限らず、情報システムに関する多種多様な億円クラス以上の規模以上の仕事をこなすうえで何が必要なのかというのをつらつら考えるに、色々なご意見がある中で一つには覚悟というものが必要であると感じています。
役所体質の顧客の情報システム刷新のシステム開発では受託した事業部の技術スキルが低い事が致命的ではありましたが、同時に受託したシステム開発という仕事に対する覚悟が無くて安易に受託したという事もプロジェクトがまともに終われなかった理由では無かったのかと思います。どんな困難が待ち受けようとも当初の計画通りやり遂げるという強い意志があれば、途中で計画を変更することもなかったと思います。
自身の技術レベルを正確に認識もしないで、受託した仕事の大半を外注に丸投げし、外注のスキルが低いので計画通り出来ませんというような言い訳が社内ではまかり通っていたのではないかと思います。
システム開発の出来栄えについては受託した事業部が技術担保すべき問題であり、外注に仕事を分担させるのは補助手段に過ぎないという、仕事をする上での基本的常識が無い事も露見してしまっていたと思います。
システム開発を受託した事業部ではシステム開発の中身を十分理解も出来ないところに、受託したシステムの業務を外注任せにしていたのは、外注会社の業績貢献のために仕事をしているような事ではなかったかと想像をすると何とも不思議に思えてなりません、会社ぐるみで裏で何かがあったのかという妄想も働きました。これに関連して思い出す出来事が何度もありました。システム開発を受託した事業部は何か外注業者に弱みでも握られているのかも知れないと思ったのは、プロジェクト進行中に外注会社のシステムエンジニアと称する外注会社の担当者が相当にひどいへまをやらかした時、顧客から事実を指摘されてもシステム開発を受託した事業部のプロジェクトマネージャーは悪びれもせず平然と対応していた事も何度もあったからでした。
システム開発プロジェクトではシステム開発範囲変更され工期が延期されるなど、提案書で述べたシステム開発とはまるで異なるプロジェクトが実行された理由の一つに、最初に述べた覚悟が無かったという事が大きいのではないかと思います。システム開発の色々な段階で進捗状況に覚悟を持って臨んでいれば、何故計画通り成果が出ないのかというのは工期の終了前に分かる筈であったと思えます。覚悟は同時に責任感をも管理者や役員が持つものだと思いますが、システム開発を受託した事業部の管理者や役員には金勘定ばかりに目が行って、システムの開発内容や実態に責任を持つという事には興味さえなく他人事で、全て担当者任せにして社内で変な噂でも立たなければ良しとするというご都合主義の姿勢では無かったと想像しています。
覚悟があればシステム開発は提案書の通りに誠実に完工させるという意思が現れて懸命に頑張ると思いますが、システム開発を受託した事業部は覚悟も無く普通のルーチンワークでもやるように安易に考えていたらしく、過去の自身の仕事の前例通りに外注会社に丸投げしてやり過ごそうとしたのが、この役所体質の顧客の基幹システム開発プロジェクトの結果になって表れたのではないかとも思えます。

第５７８話　サラリーマン生活４８年の振り返り　転職した会社（３６）　責任の所在

私は転職後２７年間の間、会社の役員や幹部の顔を思い出してみると、情報処理を生業となる会社としては随分と違和感があったという印象を持たざるを得ないと思っています。そもそも会社の仕事はとは何ぞやという事ですが、毎日社内事務処理しかしないルーティンワークの部署や苦情処理を扱う社内管理部門があり、一方では労働集約の典型とされるソフトウエアを生産する部署があり、対外的に顧客と接する部署もあります。
世の中の企業は多種多様で色々な業態があり、私が社会人として会社に入社した頃に知った大手商社の横流し商売には仰天して、何の苦も無く大儲け出来る会社があるというのを知って自分の視野の狭さを感じさせられたということもありました。しかし、時代は流れてそういう楽な商売はどんどんと淘汰されて企業自身も新しい事を始めないと生き残れないという時代に入りました。
丁度、私が転職した会社もバブルの波に乗って新規事業を始めようという時期に当たり、私は営業マンとして新規事業の一部を担当しました。この新規事業は１０年程続けて、投資した莫大な費用を回収も出来なくて全てを失い、残ったのは社員という人だけという事態となり、情報新処理業として残されたのがシステム開発という労働集約分野のみになりました。この当時の役員の顔を思い出して見ても、その役員は特段自分が悪いという風に思っていたらしいとは思えない程に淡々としていて、サラリーマンとして役員にたまたま抜擢されて運が悪かったのだというように思っていると推察されて、事業に対する責任というものをどう感じているのか甚だ不思議だと思っていました。
転職後の会社名は色々と変わりましたが、内実は何の変化も無く、実態は何か仕事があればやりますという受け身の対応しか出来ないので、当然ながら業績は世の中の景気の風次第というような形となり、右肩上がりを標榜すれど結局は出来ないということが連綿として続いていたと思います。一つには会社を変革しようという意思がないので、尤も役員もどう変えたらいいのかさえも分からないらしいと思えたのですが、結局素人の役員が始めた事業もそのまま残して、又別の事業を始めるという単に組織は肥大化させるばかりの実態があると思いました。特に人事も役員や幹部の個人的嗜好で選択されているので、素人が素人を呼ぶような形が連綿として続いていると思いました。
そうなると自然とソフトウエアを生産する部署の費用は、身の丈に合わない程の大勢の社員を養う為の費用を稼がなくてはならんという事になり、ソフトウエアの質には関係なく費用だけは世の中で一番高い水準となるのは当然のことだろうと思います。顧客には能力が比例していますと説明するものの、実態との乖離は非常に大きいと思いました。又、そういう風土は費用意識を希薄にして、自分の非はさておき、全部顧客に請求すればよいと言う安易な考え方が社内常識になっていたと思います。
顧客は紹介案件ばかりで、必然的に他の情報処理業者が手を出さないような胡散臭い顧客を相手にせざるを得ないので、金さえもらえればという思考しかできない結果、名前は通っていても内実は怪しげなる顧客がずらりと並んでいたと思いました。
 
このような社内の実態が、役所体質の顧客の基幹システム開発で遺憾なく発揮されて、提案書とはまるで違うシステム開発が実行されてしまったという事につながったと考えています。誠実ではないのさえ気づく事も無く、自分の会社としては当たり前の事として、役所体質の顧客がシステム開発を受託した事業部にまんまと餌食にされてしまった背景には、会社が歩んできた道があったということだろうと思います。同時に、そういう社員を指導すべき素人役員が低能力の社員をかばうので益々おかしくなってしまったり、事態を認識できなくて無責任にプロジェクトを放置して認めていた役員や管理職も大きな責任があったと思っています。

第５７７話　サラリーマン生活４８年の振り返り　転職した会社（３５）　サラリーマンのくびきとは

役所体質の顧客の新基幹システム開発に関わった者としての感想は大体書き終えたのかなと思いますが、こうした事件の構図というものを考えると、サラリーマンとしての基本的な態度・能力（くびき）に問題があるのではないかと思いました。たまたま私は２社のサラリーマン勤務を経験して会社の体質の違いというものは大きいというのを感じていましたが、私が勤務した２社とも保守的という環境は同じでしたが社員を育てるという環境は大きく違いました。
基本は自ら学ぶという意思がない人には、どこの会社でも同じ環境であるかのようにしか感じられないと想像は出来ますが、私が転職した会社は特に自ら学ぶという意思の薄弱な人が多くて、何かあればお助けを頼めばよいという風に考えている社員や役員が多いように思いました。そういう風土なので、会社の業績を伸ばすにも経験者を安易に中途採用すればよいという思想が芽生えてくるのだと思います。そのような背景があり、口先だけが上手い外資系の会社から社員が多数転職しているのが分かりましたが、私の見立てでは殆どが並以下の能力の持ち主で口八丁手八丁で如何にも仕事をしている素振りをしているとしか思えませんでした。そうなると、会社の中は自然と事なかれ主義とか場当たり的な対応が多くなり、会社として顧客向けの情報システム構築をすることを生業としていると標榜しながらも、その実は社内事情優先の態度で仕事をするような姿勢になるのはごく当然の成り行きだったと思います。外資系会社からの転職者だけでなく、元々能力がある筈と想像されて入社した筈のプロパー社員も学習意欲が低いので、知識が貧弱だけでなく社内の事なかれ主義にすっかり染まって金太郎飴のような社員がうろうろしているばかりの職場と感じていました。
 
普通の社会常識が通りにくい社内環境なのを理解した上で、私は社内のマイナスイメージを覆い隠すために自らが全てを仕切って顧客に対応する方針で臨み、出来るだけ社内の幹部を顧客の前には行かせないようにして顧客に対してマイナスイメージを与えないようにという努力をしていました。
しかしながら、この役所体質の顧客の情報システム開発プロジェクトは、会社の普通常識が通用しない体質の中に取り込まれて実行されたということが色々な事件や問題を引き起こし、私の個人的な力ではどうしようなく対応が出来なかったという結果であったと思っています。
システムの提案から受注に至る段階でも、すでにシステム開発を受託した事業部の連中の対応は変だと感じていましたが、一旦動き出したら流れに乗るしかないのかと思いつつ諦めざるを得ないのかとも思っていました。そういう少々変な状態でも、曲がりなりにしても何とか計画通りに情報システム開発が出来ることを想像していましたが、以前のブログで紹介した通りのこのシステム開発プロジェクトは非常に残念な結末に至り、私のサラリーマン最後の仕事としては非常に不満足な結末で失望をするという事になったわけです。

このプロジェクトの問題は基本的にはシステム開発を受託した事業部の考えられない程の低能力にあったのですが、プロジェクト進行中に色々な問題（システム範囲の縮小、工期の延長等々）があったにも関わらず、役員以下管理職が誰一人として問題を指摘・改善・指導ができなかったのは、役員や管理職が単にシステム開発の経験が少ないというレベルの問題ではなく、そもそも役員とかの管理職の役職に対応できるだけの能力が無いというのを露呈した事であったとも思います。
何か問題が発生した時に、契約先である顧客から指摘される前に自ら問題を感知して対応策を練るなどというのは、何もシステム開発プロジェクトに限らず、サラリーマンが仕事をするうえで基本中の基本であり、このプロジェクトでは最後の最後までそういう事が行われなかったのは、会社としての暗黒面が露出したという事であったとも思えました。
問題は、そういう非常に根深い問題を含んだシステム開発プロジェクトというのを認識できずにプロジェクトメンバーを大きな利益が上がったというので表彰した後に、顧客から「騙された」という評が出ても、顧客に対して真摯に向き合おうともせず、何事も無かったかのようにふるまうシステム開発を受託した事業部や関係する役員や管理職の姿勢には大きな疑問を持たざるを得ないという感想を持ちました。

第５７６話　サラリーマン生活４８年の振り返り　転職した会社（３４）

役所体質の顧客の新システム開発で象徴的だったのは、基本計画の作業が終了した頃、システム開発を受託した事業部から当初提案の機能数では見積金額が増額となるので５システムのうち１システムの開発を除外してほしいという提示があった事でした。後に顧客役員から「騙された」という言葉の出る一因にもなったと思われる事件だと思いました。
このシステム範囲縮小の話があった時、もし開発範囲が変更になるのならば提案書から仕切り直しになるというのが普通だと思いましたが、発注者である顧客は社内で既にシステム開発プロジェクト進行中を宣言しているという面子もあり不承不承了解をせざるをえないという状況であっいたと思います。顧客側のプロジェクトマネージャーも会議で座っているだけで何もできないという状況の中、システムを受託したやくざまがいの事業部からみれば赤子の手をねじるようなものだったとも感じていました。
この時の状況を考えてみると、提案時と開発範囲を変えるということならば、システム開発を受託した事業部の元々提案時の社内決済が無効になるということなので、再度稟議を上げて審議をしなくてはならないという事態と思いましたが、社内では費用的に損にならない話ならば問題なしとされたようでした。会社の看板であるシステム開発という業務に対して、役員の意識や能力レベルが図らずしも知れてしまったという事だったと思います。
 
元々の見積もりが何故変わるのかというのは、システム開発を受託した事業部では見積もりが出鱈目であったという事になるし、そうでなければ基本計画を終えてシステム開発の難易度が漸く理解出来てシステム開発を受託した事業部にとっては勘違いをしていたことが証明されたということだと思いました。この件は続きがあって、一旦は顧客もシステム内容の縮小に合意したものの、その縮小した筈の基本設計が半年近くも遅れたという事になり、この時も費用は全て顧客に請求していました。
早い話が、受託したシステム開発は提案時から８割規模に縮小されて、半年もの作業延長で費用は増加したものの満額請求出来たので、結果としてシステム開発を受託した事業部にとっては利益が大幅に増加するのは当然であったと思いました。
契約上プロジェクト終了後、会社としては利益が大きいとしてシステム開発を受託した事業部のメンバーが表彰されたということでしたが、実務上は提案時から自ら開発範囲を縮小し、自らの能力不足で延長された費用を無抵抗な顧客から満額得た事が高額な利益につながったのであったと思うと、会社の表彰という行為は社員の金策に対するものであって、顧客が満足するシステムを提供したものではないという事であったという事を証明するようなことであったと感じています。こういう場面で会社としての力量というものが知れてしまうということではなかったのかと感じています。同時に、顧客の立場に立って仕事をするという思想は絶無で、会社利益優先の思想が極めて鮮明に出ていたシステム開発プロジェクトではないかともいえると思いました。
このシステム開発の仕事は、契約が完了してから３年程も経過して段々と忘却のかなたに行くような出来事でしたが、未だにシステムに障害が発生してるならば契約は終了してしていても、システム開発は完了していなかったということの証だと思いますが、そうではない事を祈るばかりの気持ちです。

第５７５話　サラリーマン生活４８年の振り返り　転職した会社（３３）

役所体質の会社の基幹システム開発実行には、受託した会社の社員として２年、退職した後に第三者として１年半関わり、序章から考えれば５年位は関わったことになると思います。華々しいテープカット本番以降の障害発生頻度から想像されるのは、システム開発終了時点でのシステム状態は、多分システムとして未だに完結していないのではないかと想像されるというのが個人的感想です。
最初に情報システム部の次長が次期システム開発の端緒を見出そうと色々思考錯誤している時に、現状システムは素人の情報システム部員がプログラム開発を勉強しながら作成したもので、２０年以上経ても何かの障害が時々は出ているので、次期システムは情報システム部員に手が掛からないようなシステムを開発したいものだ、という願望を語っていました。しかし、システム開発した後に出来上がったものは、その当時の次長の思いとは真逆なもので、本当に１０年も安定して利用できるかどうか非常に不安を感じさせるものであると思っています。本番開始後の半年間は派遣社員として在籍して、情報システム部員の負荷を見ていましたが、以前のシステムと比べて情報システム部員の仕事が楽になったような印象は受けませんでした。
 
おぼろげなるシステム開発の談話を情報システム部の次長としている当時は、私の勤務していた会社のシステム開発をする部隊は稼げないという理由で、社長の素人発想によるシステムエンジニア部隊の解体作業みたいなことが行われた後で、はた目からは弱いものが益々脆弱性が増したという風にしか思えない状況でもありました。
そういうひ弱なシステム開発の体制しかない社内で、たまたま既存の顧客から提案却下された部署がこの役所体質の顧客のシステム開発を受託して担当することになったのが不幸の始まりと思えました。役所体質の顧客のシステム開発を受託した事業部のメンバーが、既存の顧客で情報も十分ある筈なのに提案が却下されて注文が貰えなかったので仕事も無く暇なので担当しますと言われた時は少々不安を感じました。実際にシステム開発のプロジェクトを始めてから社内会議に参加すると、メンバーの顔を見て何となく技術レベル感が低いとうかがえるし、外注業者が素人中国人エンジニアを沢山連れてきて人ばかり増やしているという実態から、何となく駄目なプロジェクトの匂いを感ずることが出来ました。
当時のシステム開発を受託した事業部の事業部長以下、関係者の面々の面を思い出すと、日本の普通の会社ではこういう人達は管理職にはならないよなと思える人達ばかりであったという印象を持っています。それに加えて私の上司であった、システム開発どころかプログラム開発さえも経験の無い営業部長が少々値の張る案件と言うので介入して、システム開発プロジェクトでトラブルが発生しているのに深刻さも理解しないばかりか、自ら顧客の情報システム部長に面会する事も無く、これは自分の知らない事ですと言って顧客からのメールを他人に転送するだけの行動をしていたのもプロジェクトが混乱した大きな一因であったと思います。

私は過去に多数のシステム開発という仕事をシステムエンジニアと一緒になって実行したという経歴があり、門前の小僧習わぬ経を読むというような事から、この役所体質の顧客のシステム開発を考えてみると、システム開発は未完になっていると想像されます。その要因は、システム開発を受託した事業部のシステム開発能力が普通では無い程に低い事に加えて、契約期間をプロジェクト期間と誤解していて、受託した仕事が完工されていなくても終了してしまうという態度に現れていたという事ではないかと推測されます。
それに加えて、システム開発を受託した事業部を応援していた役員が悪乗りして、自ら顧客役員を説得して追加費用を出してステムエンジニアと称する人間を常駐させたのにも関わらず、本番後多発した障害については顧客役員とは自ら音信不通とした態度にもあったと推測しています。

第５７４話　サラリーマン生活４８年の振り返り　転職した会社（３２）

役所体質の会社の基幹システム開発がテープカットという華々しい行事で本番が開始された後に普通には発生しえない障害が多発して、特に顕著なものについて３例ほどの記憶があるのですが、顧客の情報システム部員は毎日障害対応という仕事が出来たというので、システム開発を受託した事業部の担当者に早く障害復旧を促すという事くらいしか出来ていなかったように思います。
本番開始後に障害が発生して発覚したシステム開発を受託した事業部の作業忘れにしても、情報システム部員は作業をして回復したのでそれでよしとしていた事に私は違和感を覚えていました。普通の感覚であれば、本番開始後にプロジェクトの作業忘れが発生したならば、金を返せとか責任者を呼んで来いとか言う風に怒り心頭の状態になるのが自然だと思うのですが、一切騒ぎだてもしないという姿勢を見ていると責任感も希薄なのかなという風に思わざるを得ないと思っていました。
システム開発のプロジェクト期間中に、たまたま情報システム部に在籍していたので運が悪かったという風に考えているのかなと思った時もありました。いずれにしても、システム開発を受託した事業部はこういう顧客の無抵抗な体質に助けられて訴えられる事も無く、欲しい額の金だけせしめてさっさと手じまい出来た事は幸運だったと思い、ほくそ笑んでいるに違いないと想像をしています。
私が派遣社員として契約期間が切れる頃にはシステムで必要な台帳データが無いというので情報システム部長を悩ましていました。この話は、システム開発を受託した事業部がデータ移行というサブプロジェクトを完遂していなかっただけなので、私が情報システム部長の立場なら早よ仕事をせんかいとシステム開発を受託した事業部に怒鳴り込むだけの事だと思っていましたが、この台帳データ作成忘れ作業も顧客の対応力の悪さにつけこまれて、システム開発を受託した事業部とは話がつかない状態の時に、私は派遣社員としてこの顧客との契約を終了しました。最終的にどういう結論に至ったかは知りませんが、再びやくざまがいのシステム開発を受託した事業部から金をせびられていない事を祈っておりました。
 
はた目から見ているだけでも心配を通り越して不安が増すばかりのシステムの障害発生には驚きを隠せませんでしたが、プロジェクト会議の内容を振り返るとさもありなんと思い当たることが多々ありました。
例えば、システムの構成問題についてシンプルなシステムなので定石通りに構成するのかと思っていたら、わざわざややこしい方式を採用しているので不思議に思っていたのですが、実はシステム開発を受託した事業部の他の顧客事例をコピーしていらしいと推測されました。世の中の常識よりも、自分が経験した常識外の変則的なものが正しいと信じているという断面が見えたとも思いました。
システム開発言語もゼロクリア問題が発覚して、随分と古びたバージョンでこれから何か機能追加する等というのはとても考えられない状態と思えるし、システム構成は何かあった時に正常に動作するのか不安を残しているのではないかと推測しています。唯一救われているのは、この顧客特有の常識外にデータ量が僅少という事が、プログラムやシステムが少々おかしくても作業は出来そうだという事と理解しています。
プロジェクトの途中でプロジェクトを完遂するためには追加のシステムエンジニアが必要と、直々にこの顧客の役員に訴えて法外な費用でシステムエンジニアを常駐させた、システム開発を受託した会社の役員は本番開始後に重大な障害が発生しても、見事に手のひらを返したかの如く何の音沙汰も無くなってしまいました。本番後の不始末について自ら謝罪などをするつもりはつゆほども無いと見えて、この役員も金を貰ったのでさっさと縁を切ったというように理解出来ました。この役員もシステム開発を受託した事業部と一蓮托生で金にしか目がなくて、システムの出来栄えなんか何も気にもしていないというのを証拠立てる行動であったと思います。この役員が常々口にしていた、親会社の伝統を受けついだという会社の仕事振りなのかと驚くばかりでした。

第５７３話　サラリーマン生活４８年の振り返り　転職した会社（３１）

役所体質の会社の基幹システム開発がテープカットという華々しい行事で本番が開始された後には、先回も紹介した通りこのプロジェクトの性格が一挙に露呈するという現象が起きました。システム開発を受託した事業部は「もうプロジェクトは終了してフォロー期間に入っています」と自らの都合を述べるばかり、障害内容の事の重大性とかには無関心で、顧客から障害連絡があったから仕方なく対応するという様な態度で淡々としていたと思います。それに反して、システム開発を発注した顧客の情報システム部員は、何か障害が発生すれば利用部門の責任者からクレームがくることもあり、担当者は自らの責任みたいな風に感じていたらしく、あたふたとしてシステム開発を受託した事業部に「障害対策を早くしてくれ」というような事を伝えていたというのが本番開始後の毎日ではなかったかと思います。
鮮烈な記憶としては先回紹介した通り、自ら作業をしていなかったことによる本番開始後の障害には言葉を失うというのを通り越して、呆然として立ち尽くすしかないというような事態だったと思います。常識ある会社ならば、システム開発を受託した事業部の責任者から謝罪があって、同様の事がないか確認して報告するという対応になると思いますが、そういう事もなかったようでした。要するに、もう仕事は終わって金も貰ったのでさっさと撤退したいという事に終始していたと思いました。
プロジェクト開始後から、システム開発を受託した事業部と顧客とは毎週プロジェクト会議が開催され、システム開発を受託した事業部から進捗報告がされていたのですが、作業がされていなかったことがシステム本番開始以降に発覚したという事は、裏返すと毎週報告されていたプロジェクト進捗報告が虚偽であったことをも証明することになったと思いました。顧客は何事も表ざたにしないという社風なので、それに助けられて大事にならなかっただけとも思いました。
 
同様の障害話が本番開始後にあって、これも余りに驚愕の事実という事で記憶に鮮明に焼き付けられています。あるプログラムでデータを入力するとゼロになってしまうという現象を、情報システム部員が本番開始後に発見して、当然ながらシステム開発を受託した事業部に障害対策を依頼しました。しかし情報システム部から障害連絡をした以降、システム開発を受託した事業部からはしばらくの間うんともすんとも連絡もなく、１カ月以上も経過したある日に突然原因が分かりましたという報告がありました。
プログラムを制作した張本人が直ぐには解明できないという事実にも驚きがありましたが、驚かされたのは原因がプログラム開発をした開発言語のバグであったという事実でした。システム開発を受託した事業部では受託範囲にプログラムテストという項目もあり、毎週プロジェクト会議で品質と進捗について問題なしとの報告があったのですが、そもそもプログラムを開発した言語に問題があったという事ならばプログラム開発の前提が崩れてしまっていると感じました。この時は、大人しい情報システム部員も少々怒って「何でプログラムテストの時に確認できなかったか」と質問したら、システム開発を受託した事業部からは「桁数の多いデータではテストしなかったし、そんな桁数の多いデータがあるとは思わなかった」という言い訳がありました。システム開発を受託した事業部の言い訳に矛盾があったのを私は気づいていましたが、情報システム部員は事を荒立てるのをしたくなかったのか気づいていなかったのかどうかは不明でしたが、それ以上の追及はありませんでした。
プロジェクトの開始直後にシステム開発をするために現状のデータを全て調べる必要があると言い出したのはシステム開発を受託した事業部で、顧客は追加費用を計上して仕方なく依頼をしたという経緯がありました。詳細は以前に書いたプログに譲りますが、自らが提案したデータを確認するという仕事をした筈なのに、障害が発生したらデータ内容は知りませんでしたと回答したという事実が残りました。
一時的にプログラムを修正したとしても、問題のある開発言語でシステムが開発されたというのは、将来的に見てシステムの不安要因になったと感じました。

第５７２話　サラリーマン生活４８年の振り返り　転職した会社（３０）

役所体質の会社のシステム開発が、顧客主催のテープカット行事で新しいシステムが完成している筈であると思いこんでいたのはシステム開発経験が浅い発注者である顧客だけでなく、システム開発を受託した事業部は契約が終了したという契約期限を持って終わりであると考えていたらしいと思われたのは、通常の感覚では到底理解が出来ないと思いました。発注者と受託業者とのものすごく大きな意識差というものが、このシステム開発というプロジェクトの性格を象徴していると感じました。性善説を信じてやまない発注者と、利益のみを考える受託者という構図は真逆な意識差となって表れたのだと思いました。
システム開発の発注者である顧客は、自身が素人であるのを薄々は認識していたものの、何とかして自力で業務テストをこなそうとしている事に、私は限界があるなと感じていました。そうであるならば、システム開発を受託した事業部は３年もかけたシステム開発で得た業務知識で、顧客の行うべき業務テストに対してアドバイスをするのは当然だと思いましたが、システム開発を受託した事業部の態度は、顧客が行う類のテストはあくまでも顧客でご自由におやり下さいという冷たいものでした。
システム開発を受託した事業部は、発注者と受託者の仕事を完全に分離して、自らは自分の仕事だけしかしないという態度であったのが、このシステム開発が未完ではないかと想像をされる所以です。一体だれがシステム開発の全貌を把握できているのか不明であったというは、システムの完成度が低いという事実につながる原因であったと思っています。
顧客の業務は社会一般の生産販売業務に比べれば割合とシンプルなもので特に難しそうなものは無く、それだけにシステムは障害発生も少ないのは当然と思われると理解をしていました。
しかし、テープカット行事の本番開始以降に発生した障害は数知れず、その障害そのものも普通には考えられないものが連続して起きていたと思います。私は派遣社員として、新システム本番後に半年の経過を見ていましたが、テープカットから半年経過しても障害が発生していたのには俄かには信じがたいような気持ちになったのでした。
 
システム開発の本番後の障害と言えば、画面文字が一文字違っていたとか、処理時間が予想よりも遅いとかという、実務は問題なく処理できているものの、子細なところで障害が発生するということが一般的には考えられます。
この役所体質の会社のシステム開発では、テープカット本番後に発生した障害は多数ありますが、一番ひどいと感じられたのは、システム開発を受託した事業部で行うべき作業が全くされていなくて障害が発生した事でした。システム開発を受託した事業部は、作業が完了していないのに顧客には終わりましたと報告していたのでした。システム開発を受託した事業部は契約が終了したので終わりですと言っていたのですが、事実は契約に基づいた作業さえ出来ていなのに、契約期限が来て完了したと顧客に報告したという事だったと思います。
同時に、そういう類の障害が発生した時、障害内容を社内に知られると顧客自らの監督責任を問われるように想像したらしく、出来るだけ内々にして済ませてしまおうという姿勢であったのが、かえってシステムの完成度を低くすることに陰ながら協力をすることなったという事実には気づいていないように見えました。
このような姿勢でシステム開発を受託した事業部が社内で表彰されたという事実は、この会社が契約上すべき事をしなくても良いという事案を社員に認識させただけでなく、同時に承認をしたとも言えるので、そのような社風は一般社会に通じるのかと不思議に思えました。