罪と罰（15） ラストチャンス
「忙しいんですがね」武田さんは腕を組んで、五十嵐さんに非友好的な視線を向けた。「どんなご用でしょうか？」
「シノハラさんの件だ。俺は君に言ったはずだな。仕様書作成は必要最小限度にとどめて、実装の方を進めろと」
「ああ、そんなこともあったかもしれませんね。何しろ忙しいもんで。それが何か？」
「箕輪さん」五十嵐さんは私の方を見た。「こいつに、さっきの電話について話してやれ」
何もこんな対決の構図を作った上で、私に話させなくてもいいのに。そう恨みがましく思ったものの、いずれ話さなければならないことには違いない。私は小さく咳払いすると、川原田さんからの電話について、できるだけオブラートに包んだ表現を使って武田さんに説明した。
「......というわけです」
「そうか」武田さんは大したことではない、とでも言いたげに肩をすくめた。「そりゃ迷惑かけて済まなかったな」
「君が謝るべき相手は、箕輪さんじゃない」五十嵐さんが切り込んだ。「シノハラの担当者にきちんと謝罪しておけ」
「副部長に言われなくてもそうしますよ」武田さんは反抗的な口調で返した。「まあ、あの人はよくわかってないんだと思いますがね。客は客ですから」
「どういう意味だ？」
「素人、ってことですよ。システム部門にいたって、システムの作り方なんかわかってないんです。仕様書の重要性とかね。所詮ユーザ企業の人間ですからね」
「いや、ちょっと待ってください」私は思わず反論した。「川原田さんはソフト部門にいた人なんですから、システム開発について素人ってことはないですよ」
引き継ぎのとき説明したはずですよね、とも付け加えたかったが、やめておいた。
五十嵐さんは冷ややかな視線を武田さんに向けた。
「俺も君に言ったよな。こっちの都合や自己満足を顧客に押しつけるなってな。顧客は時間をかけて仕様書を作るより、動作するソフトウェアを早めにリリースしてくれる方が嬉しいんじゃないか？」
「それは保守ということを考えていないからですよ。きちんとした仕様書が残っていれば、今回みたいに担当者が変わっても、機能追加なんかに対応するのが簡単じゃないですか」
「きちんとしたソースが残っていても、それは同じだろう」
武田さんは乾いた笑いを洩らした。
「他人の書いたソースなんか読めませんよ」
「ああ、そうか。つまり、こういうことか」五十嵐さんは、ほとんど友好的と言ってもいいぐらいの笑顔を返した。「君はソースを読む能力が著しく不足しているんだな」
武田さんの頭に血が昇る、と私は覚悟した。ところが案に相違して、武田さんは歯をむき出してニヤリと笑った。
「その手には乗りませんよ。副部長のやり方については、私だって経験値を上げてるんですから」
どうやら似たような状況は、五十嵐さんが年長組の対応にあたっている間に何度も起きていたようだ。
「とにかく、私は私なりに顧客のために最善と思われる方式で開発をやってるんです」
「本当にそうか？」
「どういう意味です？」
「君は自分が技術面では、もう箕輪さんはもちろん、Aチームの誰にも及ばないってことをわかってる」五十嵐さんは淡々と告げた。「わかってることを、彼らもわかってる。一方、君は副課長という職位にいる。つまり彼らを管理する立場だな。なのに実装スキルでは管理するだけの能力がない。それもみんなわかってる。遠慮して言わないだけのことで、公然たる事実だな」
武田さんの顔に浮かんでいた余裕の表情がきれいに消え失せ、代わりに落ち着きのない焦りに変わりつつあった。
「なあ、箕輪さん」五十嵐さんは不意に私を見た。「君もそう思うだろう？」
なんでいきなり、そんな厄介なボールを投げるかな、この人は。私は軽いパニックに陥りながら、当たり障りのない答えを必死で探した。
「えーと、いや、別にそのようなことは......」
「ありがとう」最初から、私が明確な答えを返すことは期待していなかったらしく、五十嵐さんはあっさり私を解放した。「な、わかるだろ？今のが遠慮ってもんだよ」
武田さんに凄い目で睨みつけられ、私は思わず顔を背けた。
「そこでだ」何事もなかったかのように、五十嵐さんは続けた。「そうなると君が管理職としてのメンツを維持する方法はひとつしかない。君が得意な唯一のこと、仕様書作成を全員に押しつけることだ。それならJavaやPHPの知識が中学生以下でも、君が主導権を握れるんだからな」
「ちょっと......」
「これが君が今までこの部でやってきたことだ」五十嵐さんは武田さんが上げかけた反論の声をあっさり無視した。「顧客のために最善と思われる方式なんかじゃない。君が、リーダーシップもどきを維持するために最善の方式ってことだ」
そうか、そういう考えもあるのか。
私の知る限り、武田さんはシステム開発において、要件定義と詳細設計が必要欠くべからざるものだと、本気で信じているようだった。信じているからこそ、要件定義や詳細設計に大きく時間を割いている。
CS開発部や公事開発部では、今でも仕様書重視の考えがメインストリームだ。UIといえば80x25のCUI画面でしかなかった時代からシステム開発をやっていたような人たちだ。彼らは、Webシステム開発部のやっている仕事を、うさんくさそうな目で見ることが多い。彼らにはこれまで多くの実績を残してきたという自負があるから、設計と実装が一体となっている今どきの開発プロセスは、異次元の言語で書かれた書物のように見えるのだろう。「あんなふうにまともなドキュメントも残さないでメンテできるんかいな」そんな呟きを、私は何度も耳にしている。五十嵐さん登場以前に、武田さんの指示で私たちが作成していたドキュメントの数は、私などからすると過剰に思えたのだが、それでもCS開発部や公事開発部の水準からすると少ないらしい。もし彼らが、今のAチームのドキュメント量を知ったら卒倒するかもしれない。
たぶん、武田さんも同様の思考で動いているんだろう、と私は常々考えていた。だが、ひょっとすると、五十嵐さんの言うように、それは自分がお山の大将でいたいがための方便だったのかもしれない。
ひょっとすると、武田さんはその職歴のいずれかの時点で、自分のプログラミングスキルが、達人レベルに到達することは決してない、と悟ったのではないだろうか。私ならそれに気付いたところで、まあ、なるようにしかならんわ、と、そのままの自分を受け入れたことだろうが、元来、負けず嫌いでオレ様気性の武田さんは、誰かの後塵を拝することが我慢できなかったに違いない。だから、自分の得意分野を仕様書作成にすることにした。
あくまでも想像でしかない。考えすぎだろうか？私は武田さんの表情を窺ったが、そこに見い出せたのは、怒りだけだった。
「何と非難されようと勝手ですがね」武田さんは低い声で唸るように言った。「私は私のやり方を変えるつもりはありませんよ。これまでだって、それでそれなりにうまくやってこれたんですからね」
「......」
「仕様書を作るな、実装を進めろ、と命令されるのであれば従いますよ。とりあえず今のところはね」武田さんは勝ち誇ったように続けた。「副部長は来年にはこの会社からいなくなる。そうなれば元通り、私がこいつらを指導していきますよ」
五十嵐さんは少しの間、何かを決めかねているような表情で沈黙していた。それから小さく頷いた。
「うん、わかった」五十嵐さんは口元だけで笑った。「じゃあこっちもそれなりの対応を取らせてもらうよ」
その口調と表情に、私はなぜかぞっとした。五十嵐さんが怒りを露わにしたシーンは何度も見てきたが、恐怖を感じたのは今回が初めてだった。
「対応？」武田さんは半ば嘲笑するように訊いた。「何のことですか？」
五十嵐さんはそれには答えず、こう言っただけだった。
「時間を取らせてすまなかった。シノハラの担当者には連絡をしておいてくれよ」
「ああ、わかりましたよ。じゃ、忙しいんで」
そう言うと、武田さんは乱暴に席を立って、さっさとミーティングルームから出て行ってしまった。
ドアが閉まると、五十嵐さんは大きなため息をついた。
「困るのは、あれがレアケースではないってことなんだよな」
「は？」
「この業界の抱えてる問題の典型的なケースだ。特に会社の規模が大きくなればなるほど、保守的になる。気にするのは、どんな技術を身につけるか、なんてことより、客から責任を追及されないように、やたらにドキュメントやら承認フローなんかを複雑にすることばかりだ」
「......」
「まあ、いい。＜ハーモニー＞の方で忙しいのに、余計なことで手間をかけさせてしまって悪かった」
「いえ、いいんですが」私は躊躇ったが、気になったことを訊いてみた。「さっき仰ってた"それなりの対応"って何ですか？」
「気になるか？」
「そりゃあまあ......」
「いろいろ考えていることがある。本当はもうちょっと後になってからにするつもりだったが、なかなかそうは言っていられなくなったみたいだからな。予定を早めるつもりだよ」
具体的な事への言及はなかった。私はそれ以上訊くことを諦めた。五十嵐さんは、こういうときは何も言ってくれない人だとわかっていた。
もっとも、何を考えているにせよ、それは武田さんにとって、あまり愉快なできごとではないだろう。そのことだけは、五十嵐さんの何かを決意したような厳しい表情から、何となく察せられた。
武田さんがシノハラの川原田さんに電話をかけたのは、翌日の朝のことだった。話の内容まではわからないが、川原田さんから、かなりきつい口調で責められたらしい。いつもの武田さんは、相手の言葉を遮るように自分の主張を押し通すオレオレトークを得意としているのだが、このときばかりは神妙に頷いている時間の方が多かった。
それでも仕様書作成を重視する方針については、最後まで自分の意志を貫き通したらしく、受話器を置いたときには満足そうな勝利感を顔一杯に浮かべていた。
「納得してもらいましたよ」武田さんは意気揚々と五十嵐さんに報告した。「これまで通りってことで。まあ、実装の方は少しスピードアップすることにしましたけどね」
対する五十嵐さんの反応は素っ気なかった。
「そうか。よろしく頼む」
もっと何か反論されると思っていたらしく、武田さんは拍子抜けしたような顔で「どうも」とつぶやくと自席に戻っていった。
「身体の具合でも悪いのかしらね」カスミさんが囁いた。「それとも少しは武田さんの顔を立てることにしたとか？」
たぶん、そのどちらでもない。五十嵐さんは何かを考えている。それは確かだ。でも、それは何なのだろう。
その答えの一端は、翌週の月曜日、定例ミーティングの席で明らかになった。
いつも通りに各自の報告が終わり、中村課長が連絡事項を伝達した後、五十嵐さんはこう告げた。
「シノハラさんの件は、もうみんな知っていると思う」感情を抑制した声だった。「その件で武田副課長と話をしたんだが、武田副課長は考えを変えるつもりはないと言った。つまり、あくまでも仕様書作成を優先とする方針を貫くとのことだ。このことについて、私はこれ以上、口を挟まないことにした」
武田副課長が得意げにニヤリと笑ったのが、周辺視野に入った。勝った、とでも言いたそうな顔だ。
「さらに私は、Aチームの指揮に戻ることに決めた。武田副課長が、私が去った後は、元の体制に戻すと公言したからだ。そうだな、武田副課長？」
武田さんは、フンと鼻を鳴らすと小さく頷いた。
「要するに私は、君たちをどうにかするのはもう止めることにしたってことだ」五十嵐さんは武田さんたちを見つめた。「自ら変わろうとしない人間に何を言ってもムダというものだからな」
武田さんと久保さんが何かを言おうとしたが、五十嵐さんは手の平を向けて押しとどめるような仕草をした。
「その代わり、私はプロジェクトAの成功に全力を尽くす。私がいなくなった後でも、Aチームが継続して利益を出せるような体制を作るつもりだ」
「じゃあそういうことですね」武田さんが声を上げた。「そっちはそっち、こっちはこっちで、それぞれやってくってことで」
まるで、何かの真剣勝負に勝利したようなドヤ顔だった。私は年長組が並んで座っているテーブルをそっと見た。久保さんは武田さんに同調して笑っていたが、村瀬さんは複雑な顔だった。カスミさんはあまり関心がなさそうだ。
反対にAチームの面々は、一様に少しがっかりしたような顔だった。事情は詳しくわからないものの、五十嵐さんが武田さんにポイントを取られたようなので悔しいのだろう。こいつらにとって、五十嵐さんはヒーローみたいなものになっていたから。
これが五十嵐さんの言う「それなりの対応」なんだろうか。単に、年長組の指導を「止める」と宣言することが。五十嵐さんが再びAチームの指揮を執ってくれるのは嬉しいのだが。五十嵐さんの落ち着き払った横顔は、何となくまだ考えていることがあるように見えた。
後から考えると、私が同席させられた五十嵐－武田会談は、五十嵐さんが提示した最後のチャンスだったのだとわかるが、私はもちろん、当の武田さんでさえ、それに気付いてはいなかった。
（続く）
この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術・製品の優位性などを主張するものではありません。
コメント
あ
昔居た会社で実際にあったことをこのストーリーに当てはめてると、
シノハラのリリースを何度も延期してこれ以上は延期できないという日の朝に、
武田グループ全員が辞職というのがありましたな。
使えないドキュメントと、新品の(でも旧型の)開発用PCや
封を開けてないVisualStudio等が残されてました。
wildcat
月曜の朝から来週の展開がひじょーに待ち遠しい内容でした。
武田『大先生』の運命や如何に。
しかしながら毎度この国では武田『大先生』みたいのがどんな分野でも延々と蔓延って久しいと思いますが、中々駆逐できませんね・・・。
分野は違えどこういう大先生を駆逐するために頑張っておりますが、中々大変です。
n
初回は五十嵐さんがやらかす系のお話かと思ったけど、組織内の旧体制との戦いを描く物語なのね。
bottom
武田さんたちは、… おっと余計な推測はやめておきましょう。
一話を見直してきた
「私には、1年という期限付きではありますが、Webシステム開発部に対して人事権以外のほぼ全ての権限が与えられることになります。一定の金額を越える購入は、瀬川部長の決裁が必要となりますが、それ以外、つまりシステム開発の実務については、私に全ての決定権があると考えてください。もちろん、瀬川部長は私の決定を覆すことができますが、それは相当な根拠がある場合に限ってのことになります」
blue
“他人の書いたソースなんて読めませんよ”
って言葉を恥ずかしげもなく言えるってすごいなぁ…。
通りすがり
”他人の書いた（糞な）ソースなんて読め（るもんじゃ）ないですよ”という
カッコを補完して解釈したらダメですか？ｗ
そういうのは、コードを捨てて、一から書き直す方がよいかもしれない。
もちろん、お呪いのような各種回避コードも一緒に消えてしまって、
過去の障害が復活というケースもあるんでしょうね。
多くはそのコードで過去に費やしたテスト工数も一緒に捨てられるか？が
問題なんでしょうけど、過去の負債はさっくり捨ててしまいたいなぁ。。
n
担当が変わる度に1から作り直されたらたまらないなぁｗ
当然そんな開発費なんて出ないし。
（書き直したくなるソースも読みたくないソースもあるのは知ってます。）
通りすがりのPM
いつもながらどっちも両極端。
自分たちの会社組織を含めてクライアントを本当の意味で見る気がない五十嵐さんの方が、ビジネス観点からするとダメっぽいかな。武田さんが本当にクライアントを見ているかはわからないけどね。
顧客予算、開発規模、保守期間、要員体制（保守期間中の退職者、新人、中途採用者のスキルレベル傾向まで想定）等、さまざまな条件を考慮して決めるのが適切なPMであり、マネージャーの仕事。
マネージャーとして権限を振りかざすなら、「ソースが読めればいい」というだけでなく、「ソースを呼んで、顧客要件、仕様を把握できる要員を継続して確保できる施策を実施していてその成果も上がっているから、今回の成果物を作成するソースを読めればよい」といわなきゃダメ。
とはいえ、そこまでリアルにしちゃうと、想定している読者層(経営者、PM、マネージャー層が含まれない人たち)の枠から外れちゃうかr、わざとやっているだろうけどね。
新米IT屋
PMとか仕様だけ書いてるSEとか大手SIerとかの人の意見をもっと聞きたいです。
前のふっちーマンセーな人とか、大手SIerとか言ってた人とか。
五十嵐さんの言ってることが正しいんだと私のまわりは自分も含めて全部だめな
人だらけです。。。
elseorand
武田のような人間は技術者では無いので､
｢PMなんだから､どうにかしろ｣
なんて言われても､｢こういうバカをどうにか教育するのが､経営企画や人事だろ｡そして経営の仕事だろ｡企業は人なら､経営が責任を持て｣とやんわり返したことがございますが､
経営層が自身のやるべきことから逃げている問題への喚起のケーススタディーになっていくとありがたいですね｡
DumbObj
シノハラの案件は、武田さんが担当PMでは？
開発者も兼任していても、顧客予算、開発規模、保守期間、要員体制等を決めるのは武田さんの仕事だと思う。
顧客が求める開発スタイルに開発者が対応できないのであれば、PMとして対策を講じる必要があるけれど、
それができる気配が全くないから担当を変えてくれという話になってるんでは？
武田さんが自分のスキルの無い部分を認めて、周りや上司に支援を求めることができれば、
流れが変わったと思うけど、五十嵐さんの侮辱口調がそのキッカケを完全に塞いだ気がする。
技術に疎いPMとか、コードの書けないSEとか、そういう人たちがいてもいいと思うけど、
プログラマーよりSEのほうが高度な仕事をしてるだとか、PMのほうが偉いだとか、そういう勘違いをしてる人たちはマジ有害。
HTMLコーダーをバカにしてるプログラマーも要自戒。
通りすがりの…
五十嵐さんは旧人を攻撃ではなく、しっかり意図を説明して理解を得ようとしたか？
どうも反発を誘ってアンチパターン側に配置したようにしか見えないなぁ。
ドキュメント必要派に、必要以上に無能(に見える)人間を配置してドキュメント不要派がまさに正しい！という流れに持ってこうとしているようにように見えるのは、自分がドキュメント必要派だからか。(コードからWhyを読み解くのは想像以上に困難だと思っている。最適な設計と実装がなされているシステムばかりじゃない。)
uFitnA
武田さんが鈍感すぎて笑えない。
BEL
自動車がない時代では、顧客の要望は「速い馬を頼むよ」だろう。
顧客の要望だけ聞いていても、未来永劫自動車は開発されない。
＞「きちんとしたソースが残っていても、それは同じだろう」
これはさすがに、どうだろうか。
ソースから難なく読み取れるのはせいぜいその設計までだろう。
複雑な正規表現やSQLから仕様を復元できるだろうか。
それにそもそもバグがあったらどうするのか。
(設計がされてないとバグなのかバグじゃないのかも判断できないことがある)
ソースから「どう動くべきか」を正確に読み取るのは困難だ。
逆に、「バグも含めてどう動くか」は100%保証してくれる。
(特にWEB開発などでは)ガチガチのドキュメントが費用対効果が薄いということは、
開発業界が経験則的に学んできたことだろうが、
ソースに細かくコメントをつけて、設計書に近づけることはできる。
テスト仕様書を「現状どう動くかを保証するドキュメント」とすることもできる。
実際、引き継ぎやシステム移管で、ソースだけ送りつけられても困る。
逆にドキュメントだけあってソースがない場合もそれなりに困る。
もっとも、ドキュメントや仕様そのものにも間違いが往々にしてあるし
プログラマにとってソースより各段に有用なドキュメントって、殆ど見たことないけど。
この描写だと、武田さんの一番の問題点は人間性でしょうね。
(じゃ五十嵐さんの人間性はどうなんだ、ってのもあるけど)
私も、ソースがまともに読めない管理職がいること自体は、ただちに問題とは思わない。
役割が違うというだけで、DumbObjさんがおっしゃるように
高度だとか偉いとか勘違いしてればそれは問題だ。
じゃあどうやって部下を評価するのかという問題は残るが、それはアウトプットで評価すればいいわけで。
営業職だって「客と話してる現場全部見てないのにどうやって評価するんだ」って
問題があるのと似たようなことでしょう。
なにも、開発の何たるかに関して、ちんぷんかんぷんてわけじゃないんだから。
あべＣ
責任逃れのためのドキュメント(エビデンス含む)って大事ですけどね。
特に大手はそういう逃げ口上だけはやたらと達者なので、防具がないとあっという間に責任転嫁されて損害賠償背負わされますよ。
a
>通りすがりのPM
そりゃPM・マネージャーの役割でしょう、五十嵐さんの役割ではないんですけどそこらへんどうなんです？ｗ
p
ああ、またいいところで終わってる…
焦らさないでええええ
来週も期待
DumbObj
確かに、顧客の要望を実現することが常に良い選択肢だとは限らないですけど、顧客の要望と違うことをやるのであれば、その事について後からクレームされないよう事前に対策を講じておくのが、PMとしてやっておくべき重要な仕事かなと思います。
五十嵐さんや箕輪さんもドキュメントが全く必要ないと言っているわけではないので、ドキュメント不要派というわけではないのでは？
全体像や背景などコードで表現しにくい情報はありますが、コードもドキュメントとして捉えて意図が伝わるような書き方をしたり、テストコードを動く仕様として書いておくことで、詳細な仕様書を別途作る必要性はかなり小さくなると思います。
BELさんが書いてるように正規表現は意図を表現するような書きにくいですが、パターンをマジックナンバー的にそのまま使うのではなく、分割して意図がわかる名前をつけて、例を用いたテストコードとセットにしておけば、仕様書がなくても保守可能なレベルにはできると思いますよ。SQLは、ActiveRecordのnamed_scopeのように分割して名前が付けられるORMが使えれば、正規表現よりは楽かもしれません。
個人投資家
会社 VS 会社の 取引では、ドキュメントは大事ですよ。
言った言わないの水掛け論で済む可愛いものじゃなくて、システム不具合が発生したせいで、逸失利益ＸＸ億円の賠償をするかしないかという企業責任の話になりますから。
それで半期の利益の2/3が吹き飛びましたなんて日には、開発効率やプログラムスキルがどうのこうのという話なんて、誰も聞く耳持ちはしません。
一読者
武田さんは、反五十嵐みたいに思ってるみたいだけど、五十嵐さん（のコンサルタント会社）に依頼したのは自分とこの会社なわけで、変革するためにコンサルを入れたのに、いなくなったら元通り好きなようにやると公言してしまったら、もはや会社に対する造反といえるんじゃないですかね。
そもそもいまのままでは、部署の廃止が既定路線だったわけですし。
変わる気がない奴に何か言っても無駄っていう五十嵐さんの評価は、そのまま会社からの評価になりうるのでは？（武田さんに限らず）
局面局面で、五十嵐さんのやり方が常にベストではないかもしれませんけど
匿名
というか、顧客側が早く動くもの見せてよって言ってるのに
ドキュメント作成の、しかも打ち合わせでごり押ししてる時点でアレでしょ。
客側だって元システム屋みたいだし、ドキュメントの大事さはわかったうえで
動く物が早くみたいって言ってるのにこれではないよ。
サンプルとかプロトでいいから持っていったうえでドキュメントの話しないとさ。
まぁ武田にそんなスキルは無さそうだから無理なんだろうけど。
やじうま
>a
五十嵐さんの役割（副部長の役割）って具体的になんでしょうか？
この規模の会社、プロジェクトだとPM, SE, プログラマ, テスター, ...
といった区別がないように思います。
五十嵐さんの活動は発注するユーザ企業側もかなりかわってくれないと
難しいから、そっちにも人を送り込んでいるって話でしたがほんとに
気の長い話です。
シノハラっていうお客様はバグが出てもある程度情シスで許容してくれてる
ってことですが、どこの客もそうじゃないでしょうし。
大きな案件になればなるほどあべCさんのいうようにきっちりドキュメントで
守っていくしかないですよね。スルガ銀行みたいいなことがあるとみんな
そりゃ守りに入るのはしょうがないように思います。
やじうま
>aさん
敬称略になってしまってたいへん失礼しました…
あやまりついでに。
私もソースだけでも設計書だけでもだめだと思っています。
適度にっていうのがなかなか難しいですよね。
設計といっても外部設計とか基本設計っていうレベルは重要ですけど
内部設計とか詳細設計までいくとユーザが見てもわからないとこも多いし
ソースで代替できるとこも多いだろうと思うのです。
DumbObj
損害賠償請求をされるような事態を防ぐ目的で、「コーディング開始前に、詳細な仕様書を完成させる」という手段を意識的に選んでるんですかね？
詳細な仕様書がないと「保守できないじゃないですか！」とか「訴えられたら困るじゃないですか！」という場合に、仕様書がなくても保守できたり、訴訟問題を避けられたりするような他の方法も検討した上で、仕様書を作成するのが一番良い手段だと主張しているのか、それとも、従来からのやり方を変えないための理由付けをしているだけなのか、そこが重要ですよね。
通りすがり
＞「自ら変わろうとしない人間に何を言ってもムダというものだからな」
重要なのはこれだわな。
コードで言えばVBerとか、仕様書系で言えばこれに出てくる武田とかな。
VBerが他の言語もろくに知らん癖に何でもVBを選択して実行効率も生産性も
メンテナンス性も悪いゴミ資産の山を築いたように、何でも仕様書（の形式）
に拘る奴は時代後れの仕様書フォーマット＝時代後れの開発プロセスに拘って
生産性と信頼性を著しく低下させプロジェクトのデスマ化を連発している。
仕様書は開発プロセスの紙への投影。
過去の仕様書フォーマットにしがみつくって事は実は開発プロセスを改善してない証拠。
OOの時代にワードエクセルのみの仕様書とかドコゾの似非SIerじゃねぇんだから、
そりゃ、死ねって話になるわな。
（文中にはないけど武田のスタイル間違いなくこれのはず）
武田に一分でも理があると唱えている人は何のための仕様書なのかを一度考
えてみるといいさね。
アラファイブ
個人投資家さん。
＞会社 VS 会社の 取引では、ドキュメントは大事ですよ。
＞言った言わないの水掛け論で済む可愛いものじゃなくて、システム不具合が発生し
ドキュメントさえなんとかすれば、システム不具合が起きないなら、いくらでも何とかします。しかしそれは無理です。それだけで無く、不具合の起きた時の責任分担だって、法廷に出て結果は丁半ばくちのギャンブルなみでドキュメントなんてお札の役目にもならないじゃないですが。
だからといってどうすればシステム不具合が無くなるか、自分も知りませんけどね。（笑）
レモンＴ
五十嵐さんはＩＴ業界のサン＝ジュストにでもなるつもりなのかと思ってましたが、考えたらタイトルからして五十嵐さん：ラスコーリニコフ、武田さん：アリョーナ（金貸しの老婆）とするべきですよね。
……何か「武田さん自殺」→「『ＩＴ業界全体の為には彼の犠牲は不可避だ』と自己正当化しつつも狂気に追い詰められていく五十嵐さん」という展開しか思い浮かばないんですが、果たして箕輪さんは五十嵐さんのソーニャになれるのか？！（無理っぽいような……）。
匿名
順当に行けばおそらく解雇か降格って流れなんでしょうけど、
果たしてそれが普通の会社でそう簡単にできるのだろうか・・・。
通りすがり
そうそう、損害賠償とかエビデンスとか言っている人いるけど、
形式に拘りすぎてプロジェクト破綻させて納期間に合わなくなっても
同じ結果になるのは無視か？
匿名
プロジェクト破綻しなくても会社として赤字大量に出すとか、訴えられて賠償金
たっぷりとられるじゃ困るでしょ。
システムを動かすことが目的じゃなくて利益を出す、損失を最小限にすることが
目的じゃないかと。
確かに形式にこだわりすぎるのもまずいけど、リスクを考えるとそれなりのものは
つくらないと後で困るんじゃないの？
システム動かすの優先ってかっこいいけどきれいごとな気もする。
匿名
今回の場合、きれいごとではなく、相手から動くの優先という要求がある。
訴えられたら困るというなら、事前にその事(納品物やそのレベル感、責任分解点)を詰めるのがPMやあるいは経営陣の役割。
特に今回の場合、長い付き合いみたいだし、ドキュメントより実装重視という慣例が通っていたなら、
どこかのタイミングでその事をこそ先に明文化すべきだったわけで、個々の修正のドキュメントのレベル感はその後の話。
物語の中で出てきてないだけで、実装重視のための文書が仮にあったのなら、勝手にドキュメント重視に切り替えるのは約束違反だし、
その合意も無いのに慣例を破って仕様書だけ作っても、作る側の保身にすらならない、本当にただの自己満足だけ。
武田さんがここまでしてねじ込もうとした事が、(今やるべきかは別として)責任分解点の明確化のための文書作りならともかく、そういうわけではなさそう。
通りすがり
＞確かに形式にこだわりすぎるのもまずいけど、リスクを考えるとそれなりの
＞ものはつくらないと後で困るんじゃないの？
＞システム動かすの優先ってかっこいいけどきれいごとな気もする。
それこそ奇麗事ですよ。
ドキュメントが契約上のガードになるのは合意文書だから。
顧客が了承すれば覚書のテキスト一つでもいいし、了承しなければそんなもんは
幾ら時間をかけても何の意味もないのです。
この場合は顧客は過去実績から速度優先ではしょれる部分ははしょる事を
良しとして、工数もその前提で見積もっている筈です。
それを武田は顧客の望まない形のドキュメントを作成して余分な工数と時間を
かけてしまっている。結果、あら不思議、工数オーバーで「赤字にもなるし」
納期遅れで「損害賠償も発生する」かもしれません。
適切なバランスを取らないと同じ結果が待っているんですよ。
もう一度読み返してみてください、武田を否定している人は「ドキュメントを
作るな」とは主張していません。
武田を擁護している人が勝手にそういう極論に振っているだけなのです。
個人投資家
＞アラファイブ
不具合がなくなるかどうかではなく、
不具合が顕在化した場合に、「それはどこの守備範囲か」を示すためです。
「ここまでは打ちで保証します。それ以外のところで起きたことは責任持ちません」ってことです。
サービス水準合意 (Service Level Agreement, SLA) もそういう為の仕組みです。 無制限の保証というものは、ビジネスとしてはできません。
通りすがり
＞個人投資家さん
製造工程におけるドキュメンテーションはシステムの設計図面であって
契約文章ではありません。
匿名
俺が3か月前にかいたはずのコードがクソ過ぎて読めない（26歳・プログラマ）