第４７２話　会社幹部の心の裏が見える

このシステム開発の基本設計でのごたごたについては誰一人として解決をできた人はいなかった事が一番の不幸であったと思います。問題に対する解決策として、プロジェクトマネージャーや管理者を１人追加するとかを思いついた人の能力も疑われるものでした。そもそも企業としてシステム開発という類の仕事はできないという事を証明しただけの事にもなったのだと思います。
現場では仕事の出来ないシステムエンジニアがその場の対応だけで手一杯でうろうろしているだけで時間だけがどんどん経過し、システムに対する知識の無く何もいう言を持たない顧客は、不満をぶつける訳でも無く仕方がないので自分のペースで与えられた仕事を淡々として行うというような摩訶不思議な光景が続いたのでした。
システム開発を受託した事業部に一任しているような仕事に終始していたにも関わらず、顧客のプロジェクトマネージャーや役員はその一任している仕事の全貌が全く理解できていないままに時間が経過して最後まで行ってしまったというプロジェクトの結果になりました。
もともと規模の小さなデータしか扱わないのでデータ量で問題が発生する筈は無いので、後は業務処理ロジックや関連業務との連携さえきちんとできてしまえば何の問題も発生しないシステムでしたが、現実には本番後色々な障害が発生しているという事は基本設計のみならずプログラム製作でも問題を起こしていたという事を証明しています。その根本原因となる事が基本設計の時には発生していたのですが、ごたごたさえ乗り越えればシステムは出来るとシステム開発を受託した事業部では勘違いしていたのではないかと思うと、口先ばかりで実は何も役に立たないシステムを作る仕事をしているといわれても仕方のない実態が浮かび上がりました。
 
基本設計でのごたごたが発生すると真っ先に白旗を上げたのが顧客との窓口となっていた部署の営業部長でした。自ら「本件には関わりたく無い」といって顧客の情報システムシステム部長からの苦情メールに対しても、自ら出向く事も無く受け取ったメールをシステム開発を受託した事業部の関係者に転送をしているだけでした。そういう実態を知った顧客の情報システム部長は、名だけの営業窓口ではなくシステム開発を受託した事業部長と直接折衝するという変な図式ができていました。同時に、システム開発を受託した事業部の後ろ盾となっていた常務は話を聞いても多分顧客に落ち度があるのではないかと勘違いをしていたのではないかと思います。
この時、システム開発を受託した事業部の責任者や役員は顧客に真摯に向かい合うというような対応では無く、基本設計の期間延長は顧客に問題ありと一撃を加えてみたものの、その実基本設計の終了はずるずると延期されるので問題をすり替えるためにプロジェクトの管理者やプロジェクトマネージャーを増員するという手段に出たのだと思われます。その増員した管理者費用も顧客に堂々と請求したので正に自分に否は無いと言うのを言っていたようなもので、そういう要求を呑んだ顧客もこけにされているという意識が無かったと思います、第三者の目から見ると全くもって不幸な事件であったと思わざるを得ませんでした。
本日１８日の日経新聞の読書欄に「悪い奴ほど出世する」という米スタンフォード大ビジネススクールの著名教授が書いたという本が紹介されていました。この本では「氾濫する優れたリーダー像の「通説」がいかに実態とかけ離れているかを徹底的に論じた」と書かれていて「謙虚・誠実で思いやりを忘れずに」といった理想とは裏腹に「傲慢（ごうまん）、強欲で冷徹な経営者がいかに多いかを名だたる企業のトップ名挙げつつ論証する」と紹介されていました。
この基本設計フェーズの無期限になりかけた期間延長問題が発生した時、システム開発を受託した事業部や役員のとった行動はこの本で紹介されていたような実態ではなかったのかと感じています。人の心の裏側はこういう事件が起きて明らかになるものだとも思えて一つ勉強をさせてもらった様な気分です。

第４７１話　金が全てのプロジェクトの行く末

このプロジェクトの成否は基本設計の時に決したようなもので、その時の様子は何回にも渡って紹介しました。基本設計を開始する時の状況は、提案時に決めた基本計画の契約期間が終わったので次フェーズの基本設計に入るという事で、システム開発を受託した事業部が外注の維持管理に困ってごり押ししたものでした。当然ながら、基本計画は正確に終わったのか終わらなかったのか分からなくて、顧客から書類をそろえて提出しろと言われて体裁だけは整えて数十冊ものバインダーを納品して終わりという事になりました。
 基本設計では期間終了が延伸延伸となる中、問題解決のためとお為ごかして途中から参画した、システム開発を受託した事業部の副事業部長の説明では、この基本計画終了時点で画面仕様も決まっていなくてはならなかった筈でしたが、提出されたのはサンプル画面のみで実際には利用できないものでした。そういう意味では、基本計画の実質的な作業は未完成で作業は終わっていないという状況でした。

システム開発を受託した事業部の連中が契約が無いとばかり大騒ぎしているごたごたの中、一旦中止ではなく進めると決めた顧客の意向が出て、早々に基本設計を始めなくてはいけないというので、最初に基本設計で使う仕様書の説明がありました。
システム開発を受託した事業部では基本設計で使う仕様書が標準だと言い張っていましたが、それは自分たちの仕事の標準であって世の中の基本設計の標準ではありませんでした。
顧客側でもそういう説明を鵜呑みにするだけで、確認したり調べたりするという意識が全くないので疑義は全く出ませんでした。プロジェクトマネージャーは顧客が烏合の衆で当然何も質問は出ないと言うのを十分に分かった上で、これでよろしうございますねと言って顧客の承認を取り付けたとして、何かあっても顧客との合意済みという錦の御旗を持つ事になったのでした。
この基本設計の仕様書は業務仕様とプログラム仕様がセットになっていたもので、最初は全て顧客にチェックしてくださいと要求していたものの、顧客からプログラム仕様は細かくてチェックできないと言われて業務仕様のみのチェックにすると言う合意が週次のプロジェクト会議で合意されていたのは耳にしていました。
そもそも素人の顧客に基本設計書で作成するプログラム仕様についてチェックする事自体が無理なのを知った上でそういう要求をした事自体が何か裏があると想像をさせるような行為だと思いました。当然ながらプログラム仕様のチェックは出来る筈は無いと知っていたのは、システム開発を受託した事業部のメンバーは全員だと思います。盲目の人に道を聞く様なものであろうと思いました
この基本設計書の一件はプロジェクトが終了まで当然ながら素人の顧客から何の疑義も提示されなかったのですが、システム開発を受託した事業部の受託内容と費用内容には乖離があったという疑いを持っていたのは私一人くらいのものでした。
金さえもらえば適当に自分たちの手の内で仕事をするというシステム開発を受託した事業部と、金さえ払えば何とかなると思っていた顧客とのミスマッチが起こっていたと思います。ある意味では教訓的な事例ともいえるかとも感じました。
以後、私は度々顧客の情報システム部長に「費用の二重取りになっていませんか」という疑問を投げましたが何れも「別作業があるという説明でした」と納得させられていました。
この基本設計で作成したプログラム仕様書を作ることがシステム開発を受託した事業部では始めて実質的な仕事になったのですが、下敷きになる筈の基本計画での業務習得ができていないので一からの仕切り直しになるものが多多あるのだというのを週次の会議の席で聞くことになりました。
 
基本設計のフェーズで４月には事業部長が顧客に乗り込んで「期間延伸の原因は顧客に責任があると」と悦明があったというのは以前に紹介した通りです。これは当初の提案内容を会社として変更するという意味であったと思いますが、顧客は変な言いがかりを付けられた位に思って、情報システム部長が反発するのが精々でした。
実際はこういう説明があった時点で「それでは当初の提案と異なるので、契約破棄となります。全額費用を返却して下さい」というのが筋論でした。顧客側では何としても新システムを作らなくてはならんという意識ばかりがあって、そういう発想は全く起きなかったと思います。この時点で契約を終了して新たにベンダー選定しても期間的には問題ないと思いましたが、この時も顧客には当初通りにという頭しか無いようでした。度々のベンダー変更のチャンスを逃したのも顧客の体質からすれば仕方のない事だったと思いますが、そういう事さえ思いつかなかったというのが現実だと思います。
 
基本設計の終了期間が延伸延伸となっていくうちに、対策と称して新たに２名の管理職がプロジェクトに送り込まれたのですが、この２人の男は最後まで何の役にも立たず費用だけ取られて焼け太りしただけのことに終わりました。システム開発を受託した事業部から見れば、仕事のない社員に漸く金がつけられると喜んでいたと思います。
基本設計は何時までも終わらないので、業を煮やした顧客の情報システム部長が９月１５日終了号令で、システム開発を受託した事業部では漸く終わる支度を始めたのでした。そして延伸費用や次フェーズ準備費用、データ移行費用追加等々を請求したのでした。
本当に全ての基本設計が終了したのは１２月中旬だったので、この基本設計というのがプロジェクトの肝で、この時の品質が本番後の障害となって発生することになるのでした。
この期間延伸中に、顧客の情報システム部長も呆れて「先の見えないプロジェクトマネージャーにはうんざり」と私に向かって小言を言うのが常になっていました。後に、このプロジェクトマネージャーが会社では非常に儲かったプロジェクト管理をしたとして表彰されたと聴いたら顧客はどんな風に思うのでしょうか？

第４７０話　トラブル解決にも金をとるんですか？

システム開発の基本設計でのシステム開発を請負った事業部の体たらくは目に余るものがあり、顧客の情報システム部長が直々にシステム開発を受託した事業部に乗り込んだものの大した成果がなかったのはご紹介した通りです。こういうトラブルが発生すると人の本質が現れて、システム開発を受託した事業部の連中は顧客から余程普段からひどい目にあわされているかどうか不明でしたが、あたかもそういう事が日常起きていたと想像される土壌があったと推測される如く、他人の事情を全く斟酌しない体質をあらわにしたのでした。しかしながら、顧客の中でも論客筋の情報システム部長のクレームが少しは効いてプロジェクトにはシステム開発を受託した事業部から仕事の無い新たに２名が加わりました。
 
一人はプロジェクトマネージャーの上にプロジェクトマネージャーを置くというので統括マネージャーと命名していました。プロジェクトにあたかも何人ものプロジェクトマネージャーがいるように思えるような名称でしたが苦肉の策でそういう名称にしたものだと思いましたが、プロジェクト管理の常識からすれば、問題を起こしたプロジェクトマネージャーを首にして新たなプロジェクトマネージャーを据えると言うのが普通の対応だと思いましたが、そういう２名のプロジェクトマネージャーを据える事を思いつく連中の発想にはついていけないとも感じました。
一方、顧客の担当者の顔を見ていると、提案からずっとプロジェクトを仕切っていたプロジェクトマネージャーがいなくなると不安に思えたらしいと思えました。毎日がトラブルの連続でも苦にも思わないとのはよしとしても、そういう原因を断ち切るという勇気は全くないと言うのを感じていました。そういう顧客体質を分かっていたプロジェクトマネージャーにしてやられたプロジェクトとも言えると思いました。このプロジェクトマネージャーは、当初から「画面なんかは過去に作ったもので流用しておけばいい」というような発言をして顧客の意向を考えると言う思考は全く持ちえない男でした。そういう事情を知っていたので、この好機にプロジェクトマネージャーを首すれば少しは変わるかもしれないと思いましたが実際はそういう方向には向かず、プロジェクトマネージャーを途中で首に出来なかったのもプロジェクトが失敗した遠因とも感じています。
肝心の新しい統括プロジェクトマネージャーというのは関西弁まるだしでシステムエンジニアとは思えない風貌でした。休日には真っ赤なバッグを持って会社に出社している姿は大阪のおっさんが東京におるなというものでした。当初からプロジェクトマネージャーをしていた男に比べれば物腰も柔らかで口先は滑らかなので対応はよさそうでしたが、実態は何も変えられませんでした。この統括プロジェクトマネージャーも失格という風に思えました。
もう一人は副事業部長という肩書だけはえらくがんばったものでしたが、風貌と肩書が似つかわしくない田舎者風情の男でした。この男もプロジェクトの終わりまでプロジェクトの週次の全体会議と、全体会議の後の管理者ミーティングに出席していました。
情報システム部長から「副事業部長から、画面の設計は以前の基本計画で決めるもので、基本設計で決めているのが間違いです」と言われたと聞かされて驚きました。システム開発を受託した自分の事業部の仕事の進め方が間違っていたと堂々と公言して、その誤りがあたかも顧客にあるような言い方だと聞いて空いた口がふさがりませんでした。当然ながら、怒る情報システム部長はメールで檄文を営業部長に送付しても明確な答えはありませんでした。社内ではメールはたらいまわしにされて終わりというだけでした。
基本計画では、プロジェクトマネージャーが過去に作成したサンプル画面を顧客に提示したものの全て拒否されたので、現在利用中のシステムの画面には著作権があって同じものは作れないという理屈で押し切ろうとした経緯がありました。基本設計の段階になってから、最初の基本計画では画面サンプルの検討ではなく、画面仕様を決めておくべきだと言われると、このシステム開発を受託した事業部の開発方式というのは人によってまちまちであるというのが露見して、企業としての開発標準など無く、個人の嗜好でやり方は勝手に決めているというのが明らかになりました。
システム開発を受託した事業部からは言いたい放題やりたい放題されても、兎にも角にも新しいシステムを作るという一念だけで黙ってみている顧客との間には、相当な思いの開きがあると感じさせられた時でした。
顧客は新しくプロジェクトに参画した２人の男の追加費用もちゃんと支払っていたのには驚きを通り過ごして唖然とするしかないという感想でした。問題を起こした当事者が問題開発のために投入した人の費用を支払ったというのを始めて経験した時でもありましたが、金さえ払えば何とかなるという発想は違うとも思いました。理屈が通らないというよりもシステムが出来ないという不安の方が勝っていたのではないかと理解しています。
過去のシステム開発を経験した私には、会議で顧客とシステム開発を受託した顧客で連日口角泡を飛ばすというような光景を目にしてだけに、システム開発を受託した事業部の進め方が異常に思えのは私だけだったかもしれないと思いました。

第４６９話　開発遅延の責任所在は何処に？

このシステム開発プロジェクトの基本設計の期間延長問題を取り上げるのは３回目になります。責任論について整理をしてみたいと思います。
システム開発を受託した事業部では自らプロジェクト管任を放棄してプロジェクトは双方の業務分担であると、提案書にも書いてない事を基本設計が始まってから言い出したのは以前に紹介した通りです。事業部長直々に顧客を訪問しているので、これは会社としての方針変更であると理解できると思います。その時に顧客側の情報システム部長一人が反論を展開したのですが何の成果も得られませんでした。
約束違反でプロジェクト中止をするというのは顧客側の社内論理として考えられない事なので、結局システム開発をする業者の言いなりにしか出来ないと言う事だったと思います。システム開発を受託した事業部では、提案時のシステム機能が１箇少なくなった上に、期間遅延費用発生とか、提案書にも書いていない次フェーズ準備費用発生とかやりたい放題でした。それに加えて、私が疑念を持っていたデータ変換の外注も、基本設計の延長期間延長もそのまま費用を払い続けたので、システム開発を受託した事業部では満額を回収したので相当に潤ったものと思われます。
期間が延長した原因が作業能力の低い外注を起用して延長していたのも原因と思いますが、顧客側で毅然とした対応を取らなかったのも問題と思います。しかし、システム開発を開始する当初から顧客側では「素人なので」というような発言があり、プロジェクトの主導権はシステム開発をする事業部に任せると言うのは暗黙の了解が双方にあったものだと思います。それを逆手にとって、システム開発を受託した事業部では能力の低い外注を起用していたとしたら、未必の故意があったと思われても仕方がないと思います。裁判所での訴訟となれば、裁判官の判断は多分そういう判断を下すと思われるいような作業内容であったと思いました。

基本設計の期間延長の責任は全部システム開発を受託した事業部にあったとは思いませんが、それでも７・８割のプロジェクト遂行責任はあったと感じています。システム開発を受託した事業部では当時はうはうは状態ではプロジェクトマネージャーは表彰でもされていたのではないかと思われるほどの貢献度であったと思いますが、それは顧客側の犠牲の上に成り立っているとは私を除いて誰も考えついていなかったと思います。それくらいにプロジェクト管理が出来ない事業部の体質なのか個人の能力なのか、それとも両方なのか分かりませんが、悪い事例を残したのは事実なので、会社として最悪の事例として残ることになったと思います。
期間延長費用の８割はシステム開発を受託した事業部あるとすれば、そういう費用折衝をすべきだろうと当時は思っていましたが、そういう話し合いは無いままに終わったようでした。
この事実は８割の責任を取ると言う明確な指導とか評価が社内でもなされなかったことを意味しています。プロジェクトを管理する体制はシステム開発を受託した事業部や会社には無いと言う実態が、この時に明らかになったとも言えます。
これは最悪の事態だけなら良いのですが、その内容が通常取引の範囲を逸脱していれば犯罪行為と言うことになると思いますが、顧客側は相手を訴えるというような風土はないので仕方なく泣き寝入りということになったのだと思います。泣くどころか、とにかくシステム開発が完了してよかったと思っている面々も多いと思います。システムというのは利用できて動けばいいというものではなく、毎日の仕事で障害が無いという事も重要です。極めて少量のデータ量を処理しているにも関わらず障害が発生する事自体に疑念も持たず、障害も直れば終わりという様な安直さがあるように思います。家に板が一枚無くて風が入ったので、とりあえず近くに落ちている板切れでふさいで安心するものの、家全体がどうなっいているか分かっていないというような状況だろうと推測しています。

第４６８話　システム開発の成否を想像出来ない

このプロジェクトの問題が基本設計の期間延長に凝縮されているとは先回のブログで述べた通りです。丁度５月から８月末までの夏の厚い盛りに、プロジェクトで一番重要な時期を単なる作業の遅れと称して過ごしましたが、社員として最後の暑い夏を苦々しい思いで過ごしたのは、サラリーマンとして残念としかいいようの無い事でした。
プロジェクトとしては一見多忙に見える時期でしたが、システム開発を請負った事業部のシステムエンジニアは全く自らの非を感じない集団なので夏休みを取った人間もいましたが、一方真面目な顧客の担当者達は夏休みどころではないと毎日残業している姿が何とも変だなと感じていました。

問題の本質はシステム開発を請負った事業部は顧客をリードするという能力や姿勢が欠けていて、そもそもプロジェクトで仕事をするという事自身が出来ないのだというのが如実に現象として出ていると感じました。そういう雰囲気を毎週開催されるプロジェクト会議での議論で感じて、未だ社員でもあった私だけが肩身の狭い思いをしていたと思っていました。
そんな状況下、顧客の情報システム部長がシステム開発を請負った事業部に単身乗り込んでも、暖簾に腕押しとか糠に釘のような状態で何の成果も得られなかったのは、システム開発を請負った事業部の意識が相手の立場よりも自身の保身や利益ばかりを考える立場でしか考えない集団であったからだと思いました。これは先回のブログでも紹介した通り、システム開発を請負った事業部の事業部長以下社員はそもそも倫理感が欠如しているのが原因ではないかと指摘しました。８月も末になると、基本設計の延長費用や次フェーズの準備費用問題だけが粛々と語られたのはシステム開発を請負った事業部の事業部長以下のメンバーの頭の中では、それ以外に考えつかないので至極当然のように思われたと思います。
 
システム開発を請負った事業部ではシステム開発を身内同然の外注先に丸投げしていて、自身は管理をするだけというような体制でしたが、顧客との問題は全て外注先の問題であるような発言をしてここでも責任逃れをするような事が行われていました。顧客からの仕様修正をまともに作業出来なくて、間違いどころか同じミスを何度も繰り返すというのは、外注管理をしているシステム開発を請負った事業部に責任があると思ったのですが、これも全て外注が悪いと発言していると聞きました。一体誰がこのプロジェクトを責任を持って進めているのか甚だ疑問にも思えて、プロジェクトの悪い結論が見えてしまったように感じられる日々を過ごしてしました。
一方、正直だけが頼りの顧客の情報システム部社員の面々は、毎日の面倒な仕事が終了したあかつきにはシステムは完成すると思い込んでいたので、システムの成否というような事は全く眼中にないと言う様に見えました。こういう危険な状況を把握していた私が、退職後にこの情報システム部に派遣されて在籍した時に、そういう状況を陰ながら伝えようとしても全く反応がなかったので、ますます事の問題の根深さを感じさせられることになったのでした。
私が３０歳もはじめの頃、某社の全システム入れ替えという事も経験して、当時はえらく顧客から感謝されたことも記憶していました。当時は顧客とベンダーのシステムエンジニアが一体化していたと覚えています。しかし、このプロジェクトは、システム開発を請負った事業部自ら顧客との間に壁を作って相手が入り来めないようにして自らの利益を守り通そうとして、目的がシステムを開発すると言う事よりも金儲けをするチャンスとしか考えていないのではないかと思えたのでした。他の顧客での損失をこの善良な顧客から埋め合わせようと考えていたとも勘ぐられても仕方のない程の無責任さがあったと思います。
そういうシステム開発を請負った事業部の行動や態度について、最初から最後まで少しばかりは相手を非難はすれど、断ち切るという態度に出れなかった顧客も不幸であったというべきかも知れないとも感じていました。

第４６７話　自分だけが損をしないという理屈は倫理観の欠如から

このシステム開発では基本設計期間の延長につぐ延長という出来事がこのプロジェクトの本質を物語っていたと感じています。４月にシステム開発を請負った事業部の事業部長がわざわざ顧客を電撃訪問して基本設計の遅れは全て顧客側にあると一方的に宣言していたものの、そういう危惧を請けたベンダーが本当に理解しているならば、普通なら何とか対策を考えて出して改善をするのだろうと思ったのですが、システム開発を請負った事業部の事業部長やプロジェクトマネージャーひいては後ろ盾となっていた常務などからからは何の対策が出なかったものと見えて、プロジェクトはだらしのない自然体でだらだらと毎週会議で仕様書の修正が遅れていると報告がされるだけでした。

基本計画フェーズで、元請の事業部のシステムエンジニアがきちんと業務を理解して大筋の流れを理解していれば、基本設計の個別の仕様書の中身もそれほど時間をかけることなく決めることが出来たと思いますが、システム開発を請負ったシステムエンジニアは口先がえらく滑らかで自身の仕事の出来栄えは棚の上に上げてシステムが開発出来なくなるぞとばかりに、少し強く出ると顧客の担当者は矛を収めてしまうように見えていました。
顧客にはとにかく何とかシステムを作りたいという雰囲気だけがあり、システム開発を請負った事業部の連中とは喧嘩をしたくないし、そういう気概もないという状態だったので、何かと問題があっても結局は押されぱっなしという事だったと思います。
共同作業というのはお互いの信頼関係と同時に作業負荷もお互いの合意を得て進めるのが鉄則なのですが、この時はシステム開発を請負った事業部の無能分を全て顧客側に寄せて仕事がされていて、横から見ていた私自身も呆れると当時に自身の勤務する会社といいながら、この事業部の仕事の仕方の無責任さに怒りが起きていました。社内会議でもシステム開発を請負った事業部のプロジェクトマネージャーの余りの身勝手さに怒って社内会議にも出ないと言う状態でした。私の上司である営業部長は事の本質が全く理解が出来なくて、単に顧客の対応が悪いだけとか、プロジェクトマネージャーの無能を関係者と意見が食い違っているとか思っていたらしく、私とは全く見解が相違していました。
プロジェクトマネージャー自身が「我々は忙しくて業務を覚える暇も時間も無い」と言い切っていたのが根本的な問題を象徴していたと思いますが、そこまでシステム開発を請負ったプロジェクトマネージャーに言い切られても、顧客側では誰一人として反論する人もいなかったのも何とも言えず残念だと思っていたのは私一人だったかもしれません。普通なら「ふざけるな」という反論が出てシステム開発は中断するというような状況であったと思って聞いていました。

システム開発の延長は前回も記述した通り、５月末、６月末、７月末と月の終わりの週になると週次の会議でプロジェクトマネージャーが「終わりませんので延長します」と一方的に宣言され、顧客側のプロジェクトマネージャーからは何の反論のないので、システム開発を請負った事業部の連中は承認されたと理解して意気揚々と引きあげていきました。顧客側にはプロジェクトマネージャーの他にも大勢の部員が出席をしていましたが、個別の問題点の指摘をするのが精々というのは最初から最後まで変わりませんでした。大局観を持つと言う仕事をしていないせいもあるのかなと感じていました。
延長したのは顧客事由なので費用発生は全て顧客負担という発想は、システム開発を受託した事業部では至極当然な思考だと思いますが、事の本質を理解していないという事が問題というのを誰一人として考えつかなかったというのが、企業の持つ管理能力とかガバナンス統治能力のレベルを表していたのかと感じています。
これは管理能力という問題ということもありますが、もう一つ踏み込んだ倫理観も問題ともいえると思います。企業人としてどういう倫理観を持つかという問題です。問題を全て顧客側に押し付けて、そういう事態に対して役員も知らん顔をしているようでは倫理観は極めて低いと言わざるを得ません。倫理とは「人として守り行うべき道。善悪・正邪の判断において普遍的な規準となるもの」で企業人と言う前に社会人として備えていなかえればならない最低限の事かと思います。そういう倫理観が無い人たちが社員だけでなく役員にも大勢いる会社と判断されかねない事件と思いました。目前の利益に惑わされて自分だけが損をしないようとする行動が如実に現れ、基本設計の期間延長事件という現象を引き起こしたのだと感じています。

第４６６話　顧客から終了命令が出て作業が終わり？

システム開発を受託した事業部の事業部長とプロジェクトマネージャーが揃って顧客を電撃訪問して一方的に顧客に責任を擦り付けられた情報システム部長は怒り心頭の境地だったと思います。しかし、肝心の顧客側のプロジェクトマネージャーはそういう事態に対しても淡々として何も感じていないらしいのが不思議でした。理不尽な説明に対して反論するどころか、システム開発を受託した業者にすっかりお任せなので仕方ないという様にも見えたのでした。
こうなると情報システム部長は孤軍奮闘するしかないというのを見ていられなくて、私自身はシステム開発を受注した側の社員という立場もありあからさまな言動は出来ないので、問題の無い範囲で助言をしました。情報システム部長がシステム開発を受託した事業部の事業部長に反論したいので乗り込むというので、アレンジの段取りを指南したというような事です。
システム開発を請負った事業部のプロジェクトマネージャーが４月の電撃訪問で説明した通り、この基本設計の期間延長問題は深刻な状態に陥っていくのでした。当初は５月末には終わるでしょうと言って、当初計画よりも１カ月長く再設定して間違いなく終われますと言うような話をして２月から施業を開始したのですが、５月が来ても終わる気配はなく週次のプロジェクト会議で「もう１カ月延長せざるをえません」というような事を５月も終わりの週に発言したので驚きました。
しかし、顧客はそういう延長も仕事が終わらないので仕方が無いと言うような受け止めしかされなかったのか、大した反論もせず延長戦になるのが私にはもどかしく感じられたのでした。この時点で私は必ず費用の話になるので、延長費用に対して対抗策を考える必要がありますと情報システム部長には何度もアドバイスをしたのですが、責任者である情報システム部長の立場としては費用を支払わないことで問題が出た時のことを想像すると支払わざるを得ないと考えたようでした。
この基本設計はもともと基本計画であらかた業務の整理はできている前提なのに再び仕様書をチェックするという同じ仕事していたので、私は仕事の内容が重複している部分は費用を支払う必要はないと思っていたので何度も情報システム部長には説明しましたが、前回も書いた通りシステム開発を受託した事業部の費用をそのまま受けいれてしまったのでした。

週次のプロジェクト会議では、基本設計が遅れているのは仕様書のチェックが遅いからだというような説明がシステム開発を受託したプロジェクトマネージャーからされたのですが、顧客側のプロジェクトマネージャーは確たる反論もしないし、出席している顧客の社員も「理解を間違っていた仕様書を修正していますよ」というような個別の反論に留まるので、最終的にはシステム開発を請負った事業部に押し切られてしまうというような状態であったと思います。相手が悪すぎたというような事もありますが、発注する側も理論を立てて戦うというような対応をしないので、最後には相手の言うがままにしかならないという風に感じました。
この基本設計は５月が６月に延長し、６月も終わらず７月に入るというようなずるずるべったりというような状態でした。システム開発を受託した事業部のレベルが低くて仕様書を一度で書ききれない事が原因だと思って見ていましたが、顧客からはそういう作業の根本原因を追究する発言はなく、個別の「仕様書の内容が不備だらけで」と担当者が憤慨したりするだけで会議は終始していました。
基本設計は７月も終わらず８月に突入すると、流石に情報システム部長も顔色が変わって一体どういう事になっているのかと紛糾しそうになりました。そして、８月の終わりには情報システム部長から基本設計は９月中に終わるようにとの指示を出して、残課題を残して漸く基本設計を終わると言う事になりました。この決断は遅きに失したと思いましたが、それでも終われたのは情報システム部長の決断がなければできなかったと思いました。

この様なていたらくを招いたシステム開発を受託した事業部の事業部長や役員からは一切の謝罪とかお詫びの説明はなく、それどころか逆に営業担当者から延長費用の見積書が提示されただけでした。この時、情報システム部長は即答はしなかったのですが、半年も遅れて漸く費用を支払ったのがささやかな抵抗だったのかと思えたのでした。
システム開発を遅れたのは相手が悪いと責任を押し付けるばかりか、実務で自らの無能で計画が延長すると費用は相手持ちだと言うのは、甚だ非常識の至りかなと感じました。それでも、そういう自らの責任を感じることもなく堂々と費用を請求していた案件があったという事実だけが残ったことだと思いました。 

第４６５話　自分の責任を顧客に擦り付けた行為

システム開発の基本設計が実質２月から開始されると、事実上はもうこの先もシステム開発を請負った事業部で最後までやってもらうしかないのかなと考えると随分と落胆した気持ちになりました。私の私の上司に当たる営業部長は、システム開発というものにも経験もなく単なる物売り経験しかないので、システム開発も金さえもらえばそれでよしと思っていたと思います。私はシステム開発をホスト計算機の時代から何度も経験してきたので、今回のシステム開発の進め方の異常さに憤りをかんじていましたが、そういう非常識なシステム開発を何の抵抗も無く進めていた会社の体質の問題というのは何度も記述した通りです。
基本設計が２月に開始され６月には終わるという終了時期は、発注した顧客の情報システム部長は甚だ心配をしていたのは、毎週この部長と会話をしていて感じていました。
当初の提案からシステムの１システムが無くなって、システム開発を請負った事業部はの負荷は随分と軽くなったはずだと思ったのですが、システム開発を請負った事業部では、相変わらずミスを連発して何の改善も無いという状態が続き、顧客の担当者は怒るどころか大人しいので毎日残業をして作業するのが癖になってしまいました。元々、午後８時位に帰宅するのが習わしみたな職場でしたが、それが夜１２時くらいになりタクシーで帰るのが続くようになったと聞いています。会社としてもタクシー代は大変な費用だと思いましたが、真面目な担当者は努力をしていたのだと思います。

４月の中旬になって、システム開発を請負った事業部の事業部長とプロジェクトマネージャーが突然顧客の情報システム部長を訪問すると言う事件が起きました。事件と表現されるのは、普通の日本の商慣習では役員クラスの人間が顧客を訪問する時には、事前に「ｘｘの件でご報告があります」とか「ｘｘの件では相談に応じて貰いたい事が発生しまして」とかいう風に事前に訪問目的を相手に伝えると言うのが常識だと思います。その時には、何の件で訪問するかも伝えないで突然訪問したので事件という表現になるのでした。もっとも、システム開発を請負った事業部では常識の無いのが常識というくらいの意識レベルだったので、自分たちの常識の規範では普通と思って何も相手に告げないで役員が訪問するという行動になったのかも知れません。
この時に説明されたのは「お宅の仕様決めが遅れたので基本設計も時期が延びます」という我田引水の資料を提示して説明したのでした。顧客は部長以下プロジェクトマネージャーや管理職が同席していましたが、驚いて部長は無言だったそうですが、課長の一人が「この資料って始めて見ますが、事前に相談はしないものですかね」という普通の常識的な問いかけをしても、システム開発を請負った事業部の事業部長とプロジェクトマネージャーは蛙の顔に何とやらという表情で知らん顔をしていました、という話を後ほど情報システム部長から聞きました。顧客側のプロジェクトマネージャーも何時も通りの無言で何の役にも立たなかったのは言うまでも無い、と言うのも付け加えられたのでした。
情報システム部長は「いや、実によく作られた資料だ」と感心するので私が「それじゃあ駄目でしょう」とたしなめて、どちらが顧客が分からないなあとも感じました。

この件では、情報システム部長は筆が立つ才能を遺憾なく発揮して、以後契約の窓口である私の上司である営業部長宛にメールで抗議とか説明を求めたのですが、肝心の営業部長は自分の問題ではないのでシステム開発を請負った事業部の問題だとして、メールを転送するのが当然のように発言をするようになりました。所謂責任逃れである、そういう事も自己保身のために行われたのですが、相変わらず社内では顧客がおかしいんじゃあないのという位にしか理解をしていないのもおかしいと感じていました。これは、システム開発が開始されてから社内ではずっとそういう雰囲気であるのは以前から書いていたとおりです。
この時に明らかになったのは、毎週システム開発の報告会議に出席していた常識ある人間であれば、システム開発の遅れはシステム開発を請負った事業部に問題があり発生しているのは、明明白白の事実だったと思います。それを、自分達の責任にしたくない事業部長とプロジェクトマネージャーが仕組んで相手を悪者に仕上げたということだったと思います。こういう事をやってのけるのは犯罪にはならないのでしょうか？という疑問が私にはありました。
同時に、この事実は社内ではコンプライアンスとか社内統制に引っかからないのが不思議で、自分たちさえよければよしという企業風土とか、顧客を顧客とも思わない単なる金稼ぎをする相手にしか見ない体質があったのだろうと思います。金を貰えればよしと言うのであれば、消費者金融でも始めた方がよかろうにとも思ったのでした。

第４６４話　トライアングルの人生模様

このプロジェクトが開始されて以来、顧客のプロジェクトマネージャーとは別に情報システム部には威勢の良い次長がいて独特の存在感を示していました。このシステム開発を手掛けるきっかけを作った人で、私とも長年の付き合いがあり双方信頼を持ってお付き合いをさせて頂いていたと思います。それは通常の商取引での出入り業者というよりはもう一つ深い信頼感もあったと思います、そういう意味では色々な困りごとにも迷いなく相談に乗っていたという事もあったのだろうと思っていました。
この次長は非常に主張が鮮明なので分かりやすくてよかったのですが、システム開発を請負った事業部にとっては目の上のたんこぶみたいな存在だっただろうと思いました。私の感覚からすれば、この次長を何でプロジェクトマネージャーにしなかったのかというのが不思議でした。会社の中では順送り人事のようなものが普通なので、当時の幹部もそういう感覚で、２０年以上前にプログラムを作った年配者の担当部長をプロジェクトマネージャーに据えたのだろうと思います。
次長は威勢はいいのですが、社内での年功序列を意識していてプロジェクトマネージャーには意見をすることはなかったようでした。基本計画の終わりでごたごたが発生して顧客側のプロジェクトマネージャーがシステム開発を請負った事業部の連中に飲み会に誘われて結局のところ費用を脅し取られたのを私に報告するだけでした。
基本計画から基本設計への移行期間中や基本設計が始まった後も色々なプロジェクトでは色々な不祥事が発生していたのですが、システム開発を請負った事業部は全て顧客側に責任ありとして自分たちには責任なしという態度で週次の会議に臨んでいました。
基本設計が開始された後、週単位の会議ではシステム開発を請負った事業部のシステムエンジニアは基本計画の時と同じように仕様書のミス・間違い訂正が追い付かず、それを指摘されたプロジェクトマネージャーは「次週はチェックしてから送付します」と口ではいうものの、次週も同じことが繰り返されるというような事が続きました。
基本計画で業務を習得していればそんな事は分かっているだろうにさ、と横で聞いている私でも恥ずかしくなるような内容でも、堂々と始めて聞いた話だと主張するシステムエンジニアの発言には呆然とするという言葉しか思いつかないというのが当時の気持ちでした。
情報システム部の非常に大人しい社員ばかりが殆ど出席している会議にしても、静かすぎるのが気になりました。私が顧客の立場ならば相当の程度怒り狂うような場面だなと思いながら、恐縮して聞き入るばかりでした。
そういう状態を何とか打開したいと思っていた威勢の良い次長は、毎日朝早くから出社しては私に電話をするのが習わしになってしまいました。当時、私は毎朝７時位には事務所に出社していましたが、午前７時１５分位になるとこの次長から毎日電話が掛かり、あれこれと御叱りやらご意見を貰い私は全く同感ですという会話が、この次長が異動になる３月末まで続きました。
この次長としては私に社内で動いて貰いたいという気持ちがあったのは理解していましたが、主管部門ではないので私の判断ではどうしようも無いと説明するのが精々でした。
それよりも顧客としてきちんとシステム開発を請負った事業部に対して主張すべきでしょうと説明するのですが、顧客側のプロジェクトマネージャーと年齢とか立場とかいう確執もあるのか、動けないようでした。情報システム部長にもこういう状態を説明すると「私はプロジェクトマネージャーだからとか、次長だとかいう意識はしなくてもいいので、主張すべきは主張しなさい、と言っていますよ」と説明されるのでした。
私とこの威勢の良い次長、次長とプロジェクトマネージャーというのは丁度三角形のような関係で、これが形はあるものの全く心が通じていない虚構のように思われました。形はあるがお互いに思う事は異なっていたということかと思っていました。一つの事を成しえようとするには心が一つになることの重要性を思い知られるようなことでもあるのかと思いました。
この次長とは対策として今のシステム開発を請負っている連中を首にしないと良いシステムは出来ませんという会話をしたのですが、批判はしても行動に移せないので結局のところ最後までシステム開発を請負った事業部のペースで終わらざるを得ないということになりました。
そういう顧客の気持ちを思い図るどころか、システム開発を請負った事業部は顧客を大食いに掛かかったのが信じられないのですが、社内の幹部や役員は責任を感じているどことか、契約を取るとか支払いをしてもらう事にだけ執着して、全く平然としてしたのは信じられないような光景でした。当然ながら、このシステム開発が散々な結果に終わったいまでも、当時の事業部長はそのまま役員に名前を並べているので多分会社としても何の問題もなかったという風に理解しているのだろうと憶測されても仕方がないのかなと思います。

第４６３話　不幸が不幸を呼び込む

このプロジェクトでは基本計画から基本設計にフェーズが変わる時が山場だったと思いました。山場というのは、このまま続けてシステム開発はうまく終わるのかどうかという見極める最後のチャンスだと思いました。しかしなすすべを思いつかない顧客のプロジェクトマネージャーは当初の計画を進める道が普通だと感じていて、そのまま続ける道を選択したのでした。一時中断して、再度ベンダーを選択しなおせるチャンスだとも思いましたが、全くそういう風には感じていなかったのが不思議でした。
システム開発を請負った事業部のプロジェクトマネージャーの力不足で見積もりは遅れる、毎日の仕事はミスだらけで顧客担当者からは不信が出るというような状態でした。こういう状態を見れば、この先本当に大丈夫かというような確認が必要であったと感じていました。
しかしシステム開発を続けたい仕事の無い事業部の連中はごり押しして早く注文をよこせと、顧客の案山子同然のプロジェクトマネージャーに迫って脅したのでした。顧客側のプロジェクトマネージャーは外見は真面目そうに見えるのですが全く何も分かっていないので、プロジェクトを計画通り進めて終わればよしとしか思っていなかったようでした。この御仁、自分ではプログラムを書いていたと言っていましたが、システムについては何も理解をしていないと思いました。システム云々よりもシステム開発を計画通り進めることが自分の仕事だと思っていたのが大きな間違いであるというのを最後まで気づかなかったようでした。
相手が善意の人間ならばそういう選択も間違っていないと言えるかもしれませんが、金のためには何でもやってしまうとう集団であるというのを半年の間に気づかなかった事にも大きな問題があったのだと思います。

ごたごたしながら基本設計というフェーズを始める頃には、顧客の担当者からは「次のシステム開発ではお宅は選択しません」という様な事も語り始められました。担当者は基本計画での資料レビューで散々な目にあわされたので、これ以上はごめんだと感じていたのかも知れませんでした。しかし、その後の基本設計では同じことが繰り返され、もっと大変なレビューをすることになったのでした。
そういう部内の雰囲気を全く意にも介さなかったプロジェクトマネージャーへの反感もあったのかも知れませんでした。
この基本設計見積もりのごたごた以来、順調に進んでいたとしか報告を受けていなかった情報システム部長は自身もプロジェクトの中身を監視しなくてはいけないと感じたのか、週次のプロジェクト会議にも顔を出すようになりました。しかし部長もシステム開発の経験があるわけでもなく、会議の中身よりもきちんと事が運んでいるかどうかというような事しか理解ができないと思いました。
これから以降は私が情報システム部長に会議での論点を解説するようになり、毎週のように起きる様々な事についての解説をしたのでした。しかし問題の本質は殆どがシステム開発を請負った事業部の問題に帰結してしまうので、未だ社員であった私も少しはオブラートに包んで言わざるを得ないような事もありました。
この基本設計でシステム開発を請負った事業部が示した設計こそが始めてシステム開発というか、プログラム開発仕様書とでもいうべき代物でした。業務仕様書とプログラム仕様書が一体になったもので、中国での開発もできるような体裁になっていました。
ここで私は、情報システム部長に業務仕様は基本計画で書いた筈なので作業費用の二重取りですと解説したのですが、システム部長は相手から「少しは意味合いが違います」とシステム開発を請負ったプロジェクトマネージャーから説明されたと言って納得していましたが、私は全く納得のできない事だと思っていました。
費用の二重取りなので減額すべきだと思いましたが、システム開発を請負った事業部は外注丸投げなので当然そういう話には乗れないという事情もあって、適当に顧客に屁理屈を言って後は知らん顔をしていたという事だと思いました。こういう風に理解が不十分なままに仕事がどんどんと技術レベルの低いシステム開発を請負った事業部のペースで進んで行くのに不安は誰も持っていなかったというのも、このシステムがまともにできなかったという事の証だったかもしれないと感じています。