こんにちは。ヘル太郎です。
続きです。
前回記事で仕事の押し付け合いが蔓延して本来は設計能力のないSIer 担当者が設計せざるを得ない状況に陥っていたことを紹介しました。自分達で出来ないから子会社に発注しているハズなのにブーメランのように戻ってくるお仕事。一体全体なんでこんなことに？Ｆ社の仕切りが悪いのか？いやいやそうとも限りません（今までの記事は管理人はＦ社に恨みがあるかの如く書いてた？全くの気のせいです）。顧客側にも問題がありました。それも特大級の。今回はそんなお話。
◆前回記事はこちら↓
SIer 体験記その０： SIer 絶滅作戦開始
SIer 体験記その１： ５ヵ月連続過労死ライン超え
SIer 体験記その２： 僕たちは奴隷じゃない
SIer 体験記その３： 30分でできるわけねーだろがっ！
SIer 体験記その４： それ、うちの仕事じゃありませんから
★諸注意★
責任押し付け、当事者意識＆能力欠如
まずこちらの記事をちょっとお読みください。
建機の世界シェア２位、日本が誇る小松製作所が防衛産業から一部撤退するというニュースです。記事の一部を抜粋。
採算がとれないから装甲車の開発から撤退する、というものですがこの記事の著者は陸幕＝発注側の受注側への責任押し付け、当事者意識＆能力の欠如 を指摘しています。
これは陸上自衛隊とコマツの例です。が、管理人の気持ちを代弁するかのようなナイスな記事であります。
世界の中心で叫びたい
発注側である顧客の当事者意識＆能力欠如は呆れるほど相当なものだった
それどころか管理人側（Ｆ社側）へ責任を押し付けられた
信じ難いことにＦ社は押し付けられた責任を回避しようとしなかった(「顧客に寄り添う」絶対的価値観)
こんな頭のイカれた連中人達には付き合ってられない
それぞれの主張の根拠となる管理人の体験をご紹介していきます。
顧客の当事者意識＆能力欠如
管理人は3月からプロジェクトに参加しました。この時、システム設計の大半を担っていたＦ子社Ａ の実働部隊、すなわち実際の設計担当者達とほとんど顔を合わせていません。実働部隊はＦ子社Ａの下請け会社、Ｆ孫社Ａ（分かりにくい！これだからＩＴゼネコン構造は！）だったんですが、実はこの時は一時的にプロジェクトアウトしていたことが判明します。理由は顧客の際限ない要求に付き合いきれなくなったから。５月後半にプロジェクト復帰しますが後にＦ孫社Ａの人に聞いてみました。なぜ離脱してたんですか？と。その時の回答がこちら。
簡単に言うと、
現場に入ったら当初聞いてた話と違う、作業進めたくても顧客の聞き取りが一向に終わらないからもうムリだと思って逃げた
ということになります。
システム要件書とはなんぞや？これはシステムの仕様、つまり顧客の「こんなこといいな、できたらいいな (゜▽゜)♪」を設計可能なレベルまで落とし込んだもの。車でいえば 何キロまでスピード出せて、何人まで乗れて、これくらいの燃費で～、とかいったものです。ＳＥはこのシステム要件書に基づいて具体的な実現方法を考えていくわけです。が、それがないと言ってる・・・・・。
はて？ 目標達成すべきスピードがわからなければ車のエンジンは作れません。100㌔まででいいのか、200㌔まで出したいのか、さらにスピードに応じてタイヤやボディの作り方も変わってくるでしょう。それはシステム設計も同じ。目指すべき完成形が分からないのにどうやってシステムを作るのん (° ＿ ° )ﾎﾜｰｲ？※1
※1 「目指すべき完成形が分からないのにどうやって作るのか？」このセリフはプロジェクトアウトどころか退職するまでの間、100万回ほどＦ社と自社上司に吐き捨てました。
そこで後半部の ”ひたすら顧客の要件確認のための資料作りに追われている” です。ははーん、なるほど、やりたいことの確認作業をさせられていたと・・・。
つまりこうかな(゜▽゜)？
自分たちが欲しいと言っているのにどんなものが欲しいか分からない？
自分たちが欲しいものなのに他人に確認させる？
しかも確認させる時間と労力は他人持ち？
・
・
・
・
・
・
・
・
・
頭にムシでも湧いてるんですかね(⌒▽⌒)？
タクシーに乗り込んできた客が明確な目的地を告げずにとりあえずの方向で発進させ、再三尋ねる運転手に対して明確な目的地を回答せず、あげく料金を請求したら「なんでこんな余計な道を走ったんだ！何？俺が目的地を告げなかったからだと？それはお前の聞き方が悪かったせいだ！金はここまでしか払わんからな！」とイチャモンつけて本来支払うべき料金を踏み倒そうとする客とえらく変わらんわけです。うーむ。てっきりここは日本だと思ったんですが。いつの間にかお隣の国にいたのでしょうか？
システムは設計書に従って作られなければなりません。これは管理人の価値観からすれば至極当たり前のお話。というか、まともなエンジニアとってはもはや口にする必要がないくらい常識中の常識中の常識、もはや空気のような存在です（あって当たり前）。その設計書の元ネタとなるシステム要件書が存在しなかった。
材料がなければ料理は出来ないように、システム要件書がなければ設計書は作れない。実働部隊であるＦ孫社Ａは契約納品物である設計書を作成するため、本来予定のなかった要件確認作業を行ってシステム要件を確認せざるを得ない状況だったわけです。
これはひどい話です。上記の通りＦ孫社Ａは要件定義が終わっているという前提でプロジェクトに参加したハズで、要件定義の確認などという余計な作業の人員も時間も計画に入れていたとは思えず、事実この確認作業の負担に耐え切れずにプロジェクトから一時撤退しています（後にこのせいで管理人は悲惨な状況に陥ります）。
さらに顧客の当事者意識＆能力欠如という問題が追い打ちをかけます。このプロジェクトは管理人が参加した３月より4か月前の11月から開始されていますが、システム規模に比してプロジェクト期間が短すぎます。これは顧客（とＦ社営業）のＩＴリテラシーの欠如が原因です。ただでさえ複雑なクラウドシステム化、相当な知見が必要ですがカウンターパートである顧客情報部にもクラウド化の経験者0。ヒアリングしてもまとも回答が返ってきません。決める能力がないのです。これではまともな要件定義など出来ようハズもありません。これは３月時（顧客お偉方への設計結果説明）の段階で システム要件書がかけらも存在しかなったことから明らかです。間に合わなかったのではありません。全くなし、作りかけすら存在しませでした。
体験記1,2 で管理人が3月に120時間超の一発過労死ラインオーバー残業に苦しみ、原因がパワポ地獄だったことを書きました。顧客に発表前日のギリギリまで何度も修正させられたわけですが、何度修正しようが顧客の納得のいくものになるわけがなかったのです。なぜか？
システム要件書がないので顧客の求める完成形が記載された資料は存在しません。設計書は一応ありました。が、説明会の期日が迫って追い詰められたＦ社が孫社Ａにやっつけで作らせたもの（つまりパチモノ）。顧客要望を具体化したシステム要件書を元に作られた設計書（つまりホンモノ）は存在しなかったわけです。ただでさえ設計能力のないSIer はそのパチモノの設計書で説明資料を作らざるをえません。だってそれしか拠り所ありませんから。当然そんなパチモノを顧客が許容するハズもなし。顧客情報部は（システム要件書を作れなかった自分達の責任を棚にあげて）資料の出来が悪いと延々と修正作業をやらせていたわけです。
至極まともな運転手である管理人はそんなトンデモない輩お客様の乗車は是非ご遠慮願いたいところ。ですがそれは許されません。なぜなら我が社は「顧客に寄り添う」絶対的タクシー会社、もといSIer 。お客様の言うことは絶対なのです。
んなわけあるか
が、こちらも人間。ロボットではありません。ついに運転手の怒りが限界突破することになります。
つづく。
