ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。

人形つかい(13) 契約書が存在する理由

»

 翌日の朝、エースシステムで進捗表を開いたぼくは、首を傾げた。昨日の帰りに確認したときは「未実装機能数:10」だった。だが、高杉さんが宣言した通りであれば、この数字は5になっていなければならない。

 単にまだ反映されていないだけか、とも思ったが、エースシステムは進捗に関するこの手の数字に関しては異常なぐらい正確で、これまで反映が30分以上遅れたことはなかった。不思議に思いながら数字をクリックしてみると、10件の機能が表示された。

 01. A01F011 [修正]
 02. A01F012 [修正]
 03. A02F002 [修正]
 04. A02F003 [修正]
 05. A02F004 [修正]
 06. A04F008 [未]
 07. A04F009 [未]
 08. A04F010 [未]
 09. A04F011 [未]
 10. A04F012 [未]

 後半の5つは、昨日までの未実装機能一覧に含まれていた機能だから問題はない。問題なのは前半の5つだ。ステータスが [修正] となっているということは……。

 「前に完了したやつだ」思わず声に出してしまった。

 前半の5つは、どれも10月下旬から11月中旬までに実装し、ユニットテストを終え、橋本さんから[完了]をもらった機能だった。[完了]をもらうまでは、いろいろ修正が入るなど簡単には進まなかったが、一度ステータスが[完了]になった機能に修正が入ることは、少なくともこれまではなかった。

 少し遅れて東海林さんが現れたので、画面を見せて事情を説明したが、予想に反して怒りの言葉は聞けなかった。

 「そんなことだろうと思ったよ」東海林さんは自分の開発PCを起動しながら言った。「いままで、ろくに確認もしないでステータスを完了にしてきたってことだな」

 「で、総合テストで不足がボロボロが出てきたってことですか?」ぼくは何日か前に東海林さんが言った言葉を真似した。

 「そういうこと。まあ高杉さんが何て言うか楽しみだよ」

 しかしぼくたちの非難の矢面に立ったのは、高杉さんではなく、疲れ切った表情の橋本さんだった。

 「申しわけありませんが、これらの修正ができていないと、総合テストが進まないんですよ」橋本さんはぼくたちと目を合わせなかった。「とにかくお願いします」

 「すでに新規での機能追加が増えているうえに、この調子で完了分の修正が発生するようなら、完全に対応できるとは保証できませんよ」

 東海林さんは警告したが、それほど強い口調ではなかった。

 後でわかったことだが、エースシステムと交わした業務委託契約書に、次のような文言があったのだ。

  • 甲(エースシステム)が完了とした機能について、甲が必要と判断すれば、乙(うち)は修正に対応する義務を負うものとする。
  • .前項は、総合テスト完了(1月26日)を期限とする。

ぼくは契約書などに興味はなかったのだが、東海林さんは黒野さんに要求して一読していたようだ。だから総合テスト完了までは、エースシステム側が無節操に投げてくるパイをよけることはできないとわかっていたのだ。ただ、これまでステータスが[完了]になった機能が戻ってきたことがなかったので、さすがの東海林さんも油断していたのかもしれない。

 「とにかくやるしかないか」橋本さんが戻っていった後、東海林さんは諦めたように言った。「よし、個人別の担当は忘れて、おれたち2人で片付けていこう。まず修正分からいくぞ。作成日の若い方から手をつけるか。最初はどれだ?」

 「A01F011ですね。承認ルート分岐ロジックです」

 「ああ、あれか」東海林さんはバージョン管理システムから、最新のソースをチェックアウトした。「修正内容は?」

 「これです」

 ぼくは変更仕様書を自分のPCに呼び出して、画面を東海林さんに向けた。仕様書といっても、修正箇所として5項目が箇条書きになっているだけだ。

 東海林さんは目を細めて画面を睨んだ後、口の中で何かつぶやいていた。

 「ふん、なるほど。よし、項目3と4はおれが追加する。お前は残りを頼む。1と5は請求金額の範囲で決裁ルートを変更するロジックに似てるから、お前が作ったルート変更画面の中のロジックからコピペすると早いかな。A02F008だったか?」

 「たぶん、それです。見てみます」

 「それができたら、ユニットテスト用のデータを確認しておいてくれ。かなり前だからなくなってるかもしれん。なくなってたら、橋本さんに言ってバックアップから……」

 ぼくたちの開発は、いきなり猛烈な激務に突入していった。

◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇

 その日のうちに、東海林さんとぼくはステータスが[修正]になっている9つの機能の6つまでのユニットテストを終えて、橋本さんに報告することができた。

 修正内容の多くはいくつかのメソッドの引数を増やすとか、追加されたテーブルの項目に対応して、if~else を増やすといった簡単な単純作業ですんだ。なかには設計自体が大きく変わっているものもあったが、東海林さんの的確な指示によって、最小限の修正ですますことができた。

 まずまずの成果だ。そう思いながら開発室に戻ると、東海林さんが険しい顔で画面を睨んでいた。

 「どうしたんですか?顔が怖いですよ」

 「見ろよ」

 東海林さんが見ていたのは、例の進捗表ページで、ぼくの担当分だった。

 「未実装機能数:12」

 ぼくは自分の目を疑った。

 「なんか増えてませんか?」

 「増えてるよ」東海林さんは乾いた声で肯定した。「ちなみのおれのも2つ増えてる。修正分だよ」

 急激に襲ってきた脱力感に、ぼくは崩れるように座りこみ、パイプ椅子に悲鳴を上げさせた。

 「6件片付けたと思ったら、4件増えたわけですか」

 「きっとまだ増えるな」

 「……増えそうですね」

 「土日の休日出勤届け、出しとけよ」

 「うーん……ディズニーシーに行く予定だったんですけど」

 東海林さんは鼻で笑った。

 「やめとけ。どうせ今の時期は、豚汁の具みたいに混んでる。疲れにいくようなもんだ。そんなことより、少し休憩してこい。今日中にあと2件ぐらいは片付けたいからな」

 そう言うと、東海林さんは自分の肩をもみながら、喫煙ルームへ向かった。

◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇

 結局、ぼくは日曜日だけ休むことができた。金曜日と土曜日の2日間で、40時間以上も働き続けていて、脳が働かなくなったため、東海林さんに休養を命じられたのだ。

 休みといっても、人やそれ以外の生物で賑わう週末のテーマパークに突入する体力も気力もなく、自宅でぶっ倒れていただけだった。昼過ぎにフライドチキンとケーキを持ってきてくれた彼女は不機嫌そうだったが、明日からの果てしない実装作業を考えると気分が暗くなり、彼女に気を遣うどころではなかった。

 必死の努力の甲斐あって、土曜日の深夜時点で上がっている修正分については、全てユニットテストを完了することができた。総合テストチームは、土日は出勤してきていないので、少なくとも月曜日の昼ぐらいまでは、新たに修正分が増えることはない。絶対数を減らすチャンスだった。

 数を減らすことができたのは、東海林さんが2つの変更仕様書の内容に不備を見つけ、橋本さんがそれを認めたことも大きかった。橋本さんに説明したのは、ぼくの役目だったが。

 ぼくの説明を橋本さんは黙って聞いていた。「実装担当は設計に口を出すな」と言われることを半ば予想していたが、案に相違して橋本さんは頷いて了承した。

 「わかりました。高杉に確認しておきます。この2つに関しては、次の指示があるまで保留ということで」

 拍子抜けして開発室に戻ったぼくは、東海林さんに結果を伝えた。東海林さんは「そうか」とうなずいただけだった。

 「でも、よく設計のミスなんかわかりましたね」

 「ああ、まあな。とりあえずは2つ減ったわけだ。たった2つだけどな」

 それでも、その2つが減ったのは大きかった。それが残っていたら、日曜日も出勤せざるを得なかったかもしれない。

 「それっていわゆるデスマってやつ?」

 ぼくの話を聞いた彼女が心配そうに聞いた。彼女は都内の大手SIerで働いているが、総務部門なので、開発とは無縁だ。月末月初以外は、ほとんど定時で退社しているし、土日出勤などしたことがないらしい。残業代を稼げない分、ぼくよりも手取りは少ないが、ぼくよりも数倍ましな、人間らしい生活を送っている。

 「デスマというか、なりかけかな」

 「ふうん。ま、過労死だけは勘弁してね」彼女はコートを着た。「じゃあ、今日は帰るからゆっくり寝なよ?」

 「ありがと。ごめんな」

 彼女が帰った後、ぼくは考え直した。現在の状況は、ある意味では立派なデスマーチと言えるかもしれない。

 とにかく人的リソースにも、スケジュールにも余裕がなさすぎる上に、毎日のように追加される修正が拍車をかけている。その多くは、エースシステムがその気になってテストしていれば、こんな間際になる前に対応できたはずの修正だ。どうせ「まだ時間はあるから」とか言って後回しにしていたんだろうが、なんでそのツケをうちが払わなければならないのか不思議なところだ。

 「いかんいかん」

 ぼくはつぶやいた。こんなことを考えていても、負のループに陥るだけでいいことは何もない。彼女の忠告を素直に受け入れ、ぼくは目を閉じた。

(続く)

 この物語はフィクションです。実在する団体名、個人とは一切関係ありません。似たような行動や言動があったとすれば偶然の一致でしかありません。また、特定の技術・製品の優位性などを主張するものではありません。

Comment(15)

コメント

ハムレット

いつも、楽しく拝見させてもらっています。

しかし、受託開発での業務委託契約書にしては日米修好通商条約なみの不平等な契約ですね。

やはり法務の担当部署なり、相談できる弁護士がいないとこうなってしまうのかな。履行すべき業務要件は技術的な要因だけでは決まらないし、下手すると技術の叩き売り状態に持ち込まれるしな。

本気で弁護士に相談したら、商法とかを盾にして、戦えない事も無いとは思いますが。まあコストがべら棒にかかってしまうか。

くらにさん

まあ、プライムと二次請以降の間の契約なんて、多かれ少なかれこういうものでしょう。

こういう不平等を甘受する代償に、仕事を回してもらってる、という構図ですな。

実際のところ、契約条項で決まってなかったとしても、プライムに無償で「やれ」と言われれば、二次請以降に拒否権はないのは現実なわけで。

というのも、真っ向からやりあったら以後そのプライムから仕事を干される訳で、だから経営や営業は絶対に現場の犠牲を前提に尻尾を振り続けるしかない。

それが嫌なら、会社としてはプライム受注できるほどの力をつけるしかないし、エンジニアとしてはプライムやユーザ企業に転職するしかない、というのが現実でしょうね。

pep

今度、契約書、読んでみよう、と思いました。

ベイビー

まぁ、ベンダなんて甘くしたらサボる一方だしね。
生かさず殺さずに使うのがベストでしょ。
その結果、精神的に病んでも自分の会社の人間じゃないので
被害ゼロだしね。

特名

>ベイビー
あんたエースシステムの人?w

自分の会社じゃない人が病んでも被害ゼロって言い切れるとは
あんたも結構病んでるねwww

ハムレット

その後調べてみたのですが、今回の契約書の内容だと、下請法の不当な買い叩きに該当する可能性大ですね。おまけに契約書として形に残ってしまっているので、エース側からすれば、言い訳すらできない。(ここの法務の目はザルかよと云いたい)

まあ、サードアイの営業さん、多分善人すぎるよ。これがもっと百戦錬磨の営業になってくると、エースシステムの法令順守(コンプライアンス)違反をネタに、自社に有利になるように仕掛けるんですがね。

妥当な落とし所としては、高杉さんを担当から外すって感じかな。(その程度なら、昔悪質な客先担当者につかまって、デスマにはまった際に、部長や専務が客先の担当部署の部長に根回しして、実現したことはあるけど。・・・)
エースシステムのk自動車って発注元があるし、自動車会社って一般消費者向けの製品を扱っている関係上、(コンプライアンス)違反は非常に忌み嫌うしね。弱みならいくらでも炙り出せると思うんだがな。
あとk自動車からの受注を狙う、エースシステムの競合に働きかけるとか。・・

ベイビー

味方の兵隊に多少出るがもう少しで敵陣を撃破できる状況で、
「味方に死者は出したくない」と言って退散する将軍が
果たして良い将軍だろうか?

目的は敵陣を撃破することであって、
兵隊に「あの将軍優しいなぁ」と思われることではない。

>特名
兵隊乙。

プレ

牟田口乙

ベイビー

>プレ
兵隊その2乙

加納

>味方の兵隊に多少出るがもう少しで敵陣を撃破できる状況で、

経済の大本は「経世済民」だから、戦争状態を前提にすること自体
間違ってる気がするんですがね。。

そもそも今の日本で死にそうになるまで働く理由は、まったくないと思う。。

福島原発で働いている人なら、わからんでもないが、
この「エースシステム」の業務内容だと、仕事が増えてる理由は、
「上流工程ミス」なわけだし。命かける理由にならんでしょ。

本来なら、労働基準法で守られているはずなのだが、36協定みたいな
「ザル」だからな。。

kurihara

人としてどうなの?というのを問われてるのにPJだけが、PJの元請けだけが良ければそれでいい、ってそりゃ牟田口と言われても仕方ないわな。
そういう考えの人って、いざ契約の縛り外で困った事が起こっても誰も手を差し伸べてくれないよ。あるいは下請けのちょっとした気遣いで回避できたはずのトラブルだってあえて見て見ぬふりされかねない。
大好きな軍隊用語で言うなら後ろ弾。

ベンダに甘くするのと人として誠実な対応するのは別問題だよ。
デスマになっても、全作業員一丸となって燃えるPJの大和建造と、ひたすら後ろ向きなエースのPJ、同じ負荷でも前者では精神を病む奴は出ないよ。(PMはまた別だけど)

2daime

>kurihara 氏
>ベンダに甘くするのと人として誠実な対応するのは別問題
>デスマになっても、全作業員一丸となって燃えるPJの大和建造

そこを絶妙なバランスで保っていたのが日本式すり合わせ文化の強みだと思っていたのですが…。
この例に限らずソフトウェア業界ではできてませんね。

この不景気ですから営業が強く出れないのはわからなくも無いし
下請け、協力会社を絞って利益を出すのも短期的には正しい選択かもしれない。

でもそれだとお互い技術やノウハウがたまらず、また同じデスマの繰り返し。
このストーリーのオチはわかりませんが、
おそらく高杉さんはまた同じ過ちを繰り返すでしょう
(社内工作で橋本さんあたりに罪を擦りつけるんでしょうけど)

それでもk自動車からみればその都度、問題を起こす業者として記録されるわけで…
下請けいじめて短期的に利益を出しても、中長期的にはエースシステム的に損になるんですよね。

そういう意味で日本のソフトウェア業界って中長期的な視点で考えられる
人材が不足してるんだなぁと思います。
だから他国に比べて弱い弱いっていわれるんだろうなぁ・・・

ヤミ

楽しく読ませてもらってます。
前作に引き続き、読みやすくていいですね^^
今回の内容は、自分も似たような事をされたことがあり、他人事には思えない内容でした。
主人公が体を壊して入院しない事を祈ってます。。

もうたこさん

こんな経験は開発を請け負うシステム屋ならみんなあるんでしょうね・・・
「うんうん」って周りの人も言ってます。

実際のところ、自分の権限の範囲でコントロールするのが精いっぱいですね。

ドラマ化しても面白いと思うんだけどな~
システム屋のドラマ見たことないし。

のこのこ

いやぁベンダー時代を思い出しますね。
いまは発注側やってますが、発注側のメイン担当者としては無茶振りは断ってくれって思ってます。

システムのシの字も知らん、上役に常軌を逸した追加機能や仕様変更だされて相手の営業が戦おうともせず、OK出してくると・・・こりゃ終わったなと内心では思ってますよ。

自分としてはベンダーいじめが容認されるのは、使い捨て案件のみ。
それ以外でやると、あとはもう知れてますからね。
継続案件でコレくらうと、現場としてはベンダー調整、うまく握るところと誤魔化すところ、ついでに次回開発での見積もりを甘くして、前回は申し訳ないってな形でまとめて素通しに近くして・・・
ってやったりしてますが、まずベンダー会社の営業は、もっとしっかり現場を見ろ。と言いたいです。
それで相手が会社の誰が敵で誰が味方か見極めろ。糞案件に悩まされているのは、受けて側にいる人間だけじゃないんだぞとね。

断っても問題ない、いやむしろ断れ!!って案件があるんだよ。
こちらに必要なのはちょっと前にでたが「調べてみたが駄目でした」という報告で、なんも調べてないのにOK出した上、いざやろうとしてできません。というバカな回答じゃない。
バカが出した要求を突っぱねる根拠として、開発ベンダーに断られる必要がある。ってだけだ。


開発経験を持ってるちゃんとしたシステム屋は、そういう案件はそれとなく匂わせてるんだけどね。
意味深なメールや話しを振ったりして、この発注は危険だ、断れ、詳細をちゃんと質問しろ、無能な営業に任せでOKを出すなって・・・。
それに気づかず見積もり貰って、中身みると内心バカヤローと叫びたくなるものが多々あって、こんなもの上に出したら、OKでちまうだろ。
OKでた後、お前らこれじゃできねぇんだろ。あれもコレもソレも見積もりに入ってねぇじゃんか。気づけ!!こっちはワザと隠してるんだよ。
そして打ち合わせするなら、ちゃんと技術者同士の場を作れ、発言権が限られてるのはなにもお前らだけじゃねぇんだ。
営業としては余計なことを言われたくないかもしれねぇが、実際指揮とるのが誰か?ってのがわかんねぇわけじゃねぇだろ。
上の連中は、額面での金額を見るが、現場は総合的コストを見てるだよ。
無茶な案件を無茶なまま実装したら、額面上はコストが低く見えても
稼動とか利便性とか保守とか含めたら、お互い損する結果にしかなんねぇってわかってるだろ、少なくとも技術者ならよ。
無茶な案件を適切に断るベンダーは評価は上がりこそすれ下がらないんだよ。
営業力がねぇベンダーはこの点しっかり勉強しろ。
なんでもOKして、結果適当になる会社は、あそこは安かろう悪かろうだから、この案件に関わらすことはちょっとできませんねって、形にしかならねぇからさ。

っと、この辺でまとめますが、発注側に技術がわかる奴がいるなら
そいつを味方につける努力をしろ。
気づいていないかもしれないが、そこが一番の防波堤にも障害にもなるからよ。

コメントを投稿する