罪と罰(19) ワルツは踊らない
かなり以前のことになるが、この会社に入社して間もない頃、武田さんと開発プロセスについて話し合いをしたことがある。話し合いといっても、真剣に議論をしたわけではなく、「前の会社ではどんなことやってた?」という雑談の延長レベルだったのだが、今にして思えば、そのときにもう少し自分の思うところを主張しておけば、Webシステム開発部も違う方向に進んでいたかもしれない。。
武田さんの前職では、何種類もの定義書、設計書の類をしっかり作成することが義務づけられていたようで、武田さん本人もそれを疑問に思うこともなく、それを身体の芯まで染みこませた状態で転職してきた。そのことを知った私は、特に深い考えもなく、前の会社でのやり方を話したのだ。
私の前職での開発プロセスは、今の第2開発課と似ている。すなわち、最初に最低限の設計だけを行い、後は実装と設計を並行して行う手法だった。ただし別に積極的にアジャイルを実践していたというわけではなく、単に悠長に設計書などを書いている時間的余裕を持てなかっただけだったのだが。
それを聞いた武田さんは、新種のゾウリムシか何かを見つけたような目で私を見た後、やれやれとばかりに肩をすくめた。
「よくそんなリスクばっかりの方法でやってこられたもんだな」
「リスクですか?」私は訊き返した。
「そうだよ。仕様書書かないなんて、リスクそのものじゃないか。オレはとてもとても、そんな危ない方法でやる気になれんなあ」
このとき、武田さんにデマルコの熊の本でも薦めておくべきだったのだ。だが、私は曖昧にうなずいて沈黙するという方法を選んでしまった。入社したてで波風を立てるのもはばかられたし、私と違って管理職待遇で入社した武田さんに正面から異を唱えるのも躊躇いがあったためだ。
やがて武田さんはドキュメント駆動型の開発プロセスで、開発を行うようになり、私も何となく追随してしまっていた。それは五十嵐さんの登場まで続いたのだった。
私の予想通り、武田さんは慣れ親しんだウォーターフォール型の開発プロセスを選択することにしたようで、ヘルプに出した3バカトリオは、早速、仕様書作成に駆り出された。<ハーモニー>の開発では、ER図だけは作ったが、詳細仕様書などは全く作成しないで、実装優先で進めてきた。元Aチームのメンバーは、そのやり方にすっかり慣れてしまっているので、武田さん方式には、相当な拒否反応を示したらしい。しかもプロジェクトAでの成功体験がまだ生々しく残っているからなおさらだろう。
五十嵐さんがやってくる以前から、若手組は仕様書作成という苦行に、進んで身を投じていたわけではなかった。だが、武田さんはWebシステム開発部のナンバーツーとして、技術的な方針については決定権があったから、渋々従っていたようなものだ。
守屋と足立、足立と木下、木下と守屋、のローテーションで回したヘルプが一巡した日の夕方、武田さんが喫煙室に消えた途端、3バカトリオが、ほとんど引きずるように私を廊下に連れ出した。
「かんべんしてくださいよ、もう」守屋は泣き出す寸前のような顔で訴えた。「HTMLのフィールド1つ1つに対して、文字数やらスタイルやら、いちいち書けって言うんですよ。しかも、ドット単位で領域の定義も付けろとかいうし」
「前から仕様書には細かい人でしたけど」木下もうんざりしたような顔で付け足した。「今回のはちょっと細かすぎですよ。細かく書くこと自体が目的みたいになってます」
「正直あれでは」足立も暗い顔で言った。「実装に入るのは当分先になりそうです」
「......わかった。後で、武田さんに言っておくから」
「お願いしますよ」守屋が露骨に安堵の表情を浮かべた。「今は、同じ副課長なんですから、遠慮もいらないんでしょう?」
私は思わずため息をついた。こいつの言葉ぐらい世の中が単純だったなら、もっとずっと気楽な人生が送れるだろう。
3人を追い払うと、私はその足で武田さんを探しに行った。さっき喫煙室の方へ行ったのなら、そろそろ戻ってくる頃かもしれない。できれば、他の人の耳目がない場所で話したい話題だ。
武田さんは自動販売機の前にいた。24種類のドリンクを左上から右下へと順に見つめている。私は近づいて声をかけた。
「武田さん」
「おお」言いながら武田さんは、ようやくキリマンジャロ・ブレンドのボタンを押した。「休憩か?」
「いえ......ええ、まあ」
「おごるよ」武田さんは回収したおつりの中から500円玉を自販機に投入した。「どれがいい?」
「すいません。そんなつもりじゃなかったんですが。じゃあ、いただきます」
私は無糖ストレートティーを選ぶと、武田さんに礼を言って、一口飲んだ。
「あの、うちの3人ですが......」
「おお、助かってるよ。ありがとうな」武田さんは明るい笑顔で言った。「まだ仕様書の段階だから、つまらないとは思うけどな。実装になったら活躍してもらうからさ」
私は少し居心地の悪さを感じ、冷たい紅茶を喉に流し込んだ。ついこの前まで、武田さんは朝から晩までイライラしているようで、事務的な伝達事項でさえ、話しかけるのが躊躇われたのだ。それなのに今は、ドーナッツの山を目の前にした子供のように、ニコニコしている。
――よっぽど、新規案件が嬉しかったのかなあ
「その仕様書なんですけど」私は慎重に言葉を探した。「その、少し丁寧に作りすぎらしいですが......」
「うん、わかってるよ」武田さんは意外にもあっさり肯定した。「ちょっと今回はいつも以上に細かくやってる」
わざと細かくやっているということか。なぜだ?まさか嫌がらせというわけではないだろうが。
「でも、納期にもそんなに余裕があるわけじゃないですし、長く残るシステムでもないので、もう少しおおざっぱでもいいんじゃないですか?」
「最初はそのつもりだったんだがなあ。考えを変えたんだ」
「なんでまた」
「そっちの3人のためだよ」
「は?」あまりにも意外な言葉に、私は紅茶を噴き出しそうになった。「ど、どういうことですか?」
「今は、アジャイルだの何だので、ドキュメントを書かずに、いきなり実装を回すやり方が流行ってるだろ?まあ、それもいいさ。そういう時代の流れなんだろうし、素早いリリースが何度も必要なサイト構築なんかは、それでもいいんだろう」
武田さんは甘そうなコーヒーをぐびりと飲んだ。
「だがなあ、そういうやり方って、バグも多いんだよな。そりゃあ、昔みたいにバグ票起こして、修正前と後のエビデンス残して、なんてことをやらない分、バグの修正も簡単なんだろうけど、やっぱりバグはないに越したことはないだろう」
「......」
「俺はあいつらにもう一度教えてやりたいんだよな。きちんと仕様書を書いて、それからコーディングに入れば、どんだけきっちりしたシステムができるかってことをさ。行き当たりばったりにコーディングやテストを繰り返すより、ずっと楽にできるはずだろ」
私は肯定も否定もしなくてすむように、ペットボトルを口に運んだ。
武田さんが言っていることは、理論的には間違ってはいない。確かにきちんとした仕様書を先に作ってから実装に入れば、コーディングは楽だし、バグも少なくなるだろう。ただしそれには、「ほとんどソースと同じぐらい」細部まで考え抜かれた仕様書が作成できれば、という前提が必要だ。さらに仕様書作成に、無限の時間を費やすことが許される、という大前提も必要になる。達人でも天才でもなく、予算や納期を決める権限のない普通のエンジニアに、そんな前提は与えられない。
バグは根絶できない。そのことに気付いた先人たちは、バグを出さない方法を模索することに時間を費やすのをやめ、出しても迅速に対応できる仕組みを築き上げることに方向転換した。それが、武田さんから見ると「行き当たりばったり」に見えるとは。
ただ、私は、完全に武田さんを否定することができなかった。技術的にではなく、心情的にだ。
武田さんにとって、自分とは正反対のやり方で一応の成功を収めたプロジェクトAは非常に目障りな存在であるに違いない。これまで長い年月をかけて築いてきた方法が、突然現れた五十嵐さんと愉快でない仲間たち――Aチームのことだ――によって、あっけなく否定されたからだ。過去の業績を否定されるだけならともかく、これからは自分のやり方では通用しない、と認めるのは業腹だし、それ以上に恐怖でもあるだろう。
だから武田さんは、仕様書にこだわる。何が何でも、KSR電機さんの案件を成功裏に終わらせて、自分のやり方でも成果を出すことができる、ということを内外に示したいのだろう。
「じゃあ、先に戻るな」
「あ、はい」私は慌てて一礼した。「ごちそうさまでした」
武田さんの後ろ姿を見送りながら、私は、この案件が何事もなく終わるとは思えなくなっていた。
次の日の第2開発課の定例ミーティングでは、予想通り、3バカトリオが不満をぶちまけた。私が「仕様書は今の通りで進めることになった」と告げたからだ。武田さんの「3人のために、あえて細かすぎる仕様書を作っている」発言については伏せた。それを話していたら、3人がぶちまけるのは不満では済まなかったかもしれない。
「悪かったってば」私は3人をなだめた。「いや、ホントに。でも、いろいろ大人の事情ってのがあってね......」
「大人ってのは、30過ぎた人のことですか?」と守屋。
「守屋てめえ」私は守屋を睨んだ。「あたしにケンカ売ってんのか」
「武田さんに何か言われたんですか?」木下が訊いた。
「何かって?」
「何か弱みを握られてるとか」
「あるか、そんなもん」
「じゃあ、買収されたんじゃないですか?」と足立。
自販機で100円の紅茶をおごってもらったことも、買収に該当するんだろうか。
「とにかく」私は不毛な議論を断ち切った。「そういうことだから。これも何かの勉強だと思って、何とか切り抜けて」
「そうですよ、先輩方。人生、勉強です。がんばってくださいね」クミが少しも心がこもっていないエールを送った。
「お前、自分が担当じゃないと思って気楽なことを......」
「はい、今日はここまで」私はさっさと解散を宣言した。「今日の当番は足立と木下だね。さっさと行って、さっさと戻ってきて」
「はいはい」
「お前は幼稚園児か。ハイは1回って習ったでしょ」
「はーい」
私たちがオフィスルームに戻ると、ホワイトボードに貼られたスケジュール表の前で、五十嵐さんと中村課長、そして武田さんが何やら深刻そうな顔で話をしていた。久保さんも自分の席から、その様子を心配そうに注視している。
「なんですか?」
私はカスミさんに訊いたが、答えが返ってくる前に、私たちが戻ってくるのに気付いた五十嵐さんに手招きされた。
「箕輪さん、ちょっと来て」
「はい」私は急ぎ足でホワイトボードの前まで歩いた。「なんでしょう?」
「これ」五十嵐さんはスケジュール表の方に顎をしゃくった。「どう思う?」
私は状況が呑み込めないまま、スケジュール表を眺めた。武田さんは苦い顔でそっぽを向いている。
武田さんがホワイトボードに貼り付けたスケジュール表は、予定を表すラインの下に、実績を表すグリーンのラインを書いていく、という昔ながらのガントチャートだった。一番最初の大項目は「要件定義」で、これは予定と同じ長さのグリーンのラインが引かれていた。担当は武田さん、久保さんだ。
次の大項目は詳細設計で、3週間分の予定が確保してあった。中項目として機能単位のラインも引いてあり、武田さん、久保さんの他、守屋、木下、足立の名前が均等に割り振られている。
最後の中項目は「設計書検収」となっていて、1日分のラインが引かれている。今日がその日だ。
「えーと、遅れているようですが」
「そうだな」五十嵐さんはうなずいた。「まともに完成している仕様書は1つもない。武田、理由はなんだ?」
「理由なんてないですよ」五十嵐さんと目を合わせないまま、武田さんはボソボソと答えた。「こういう遅れはよくあることです」
「昨日、クライアントから電話があったらしいな。今日が設計書の検収日だけど何時に来られるかって」
「ありました。仕様書が完成していないので、延ばしてもらうようにお願いしました」
「どうして報告しない?」
「それぐらいは、担当者間で解決すべき問題でしょう。わざわざ副部長のお耳に入れるようなことではないと判断しました。こんな風に箕輪さんまで呼ばなくても......」
「お前が事態を収拾できると思っていれば、こんなとこに突っ立ってやせんよ」
「......」武田さんは沈黙した。
「それでいつになったら実装に入るつもりなんだ?」
「たぶん今週中には、何とかがんばれば......ある程度は」
「何とか?がんばる?」五十嵐さんは呆れたように冷笑した。「お前、それでもシステム屋か。何とかっていうのは、どういうメソッドなんだ?がんばるっていうインターフェースに対する実装はなんなんだ?ある程度って単位はなんだ?KかMかGか?」
何も、そんなに詳しく怒らなくても、とは思ったが、この件に関しては武田さんの方針に全く共感できないのも確かだ。「がんばる」ことで「何とか」しようとするのは、結果的に何ともならないことが多い。
「わかりました」武田さんはようやく五十嵐さんの顔を見た。「木曜日中には全部の仕様書を完成させます」
背後で、3バカトリオがまとめて息を呑むのが聞こえた。今は火曜日の15:30だから、あと2日強。スケジュール表での遅延は、その4倍以上だ。
五十嵐さんはやや厳しい顔で武田さんを見ていたが、やがて小さくうなずいた。
「いいだろう。では、金曜日の朝一番で、仕様書を一式見せてもらうからな」
「わかりました。朝一番で机の上に置いておきますよ」
どちらも、達成できなかった場合については言及しなかった。そのときは、武田さんにとって愉快ではない事態が到来することは、この場にいる全員がわかっている。
「それで箕輪さん」五十嵐さんが私を見た。「もう1人、ヘルプを出せるか?」
私は答える前に武田さんの表情をチェックした。こういう場合、武田さんなら「必要ない。今の人数で必要十分条件を満たしてる」とか言い放つだろうと思い、それを期待していたのだ。だが、案に相違して武田さんは五十嵐さんの言葉に反対しようとはしなかった。さすがに時間が足りないことは認識しているらしい。
「わかりました」私は渋々了承した。「じゃあ、守屋、今日はあんたもKSR案件のヘルプに回って。金曜日までは3人ともね」
守屋も、後の2人も心底げんなりした顔になったが、空気を読んだのか、文句を言うこともなく揃ってうなずいた。
「じゃあ、仕事に戻りますので」武田さんは自分の席に戻ると、3人のヘルプを呼んだ。「おい、守屋、木下、足立、ちょっと来い」
呼ばれた3人は、出荷直前のブロイラーみたいな顔で、のろのろと武田さんの席まで歩いていった。
「箕輪さん」五十嵐さんが近寄ってきた。「申しわけないが、少し多めにヘルプの時間を取ってやってくれ。若い連中には苦労をかけることになるが」
「仕方ないですね。でも、間に合うんですか?」
「武田はそう言ってる」五十嵐さんは突き放したように言った。「とりあえず金曜日までは静観する」
私は武田さんから説明を受けている3バカトリオを見た。わずかでも救いがあるとすれば、これで武田さんも細かすぎる仕様書の作成を考え直すだろうということだ。
席に戻ると、マサルが近寄ってきた。何か言いたそうな顔をしている。
「どした?」
「ぼくら全員で手伝った方がいいんじゃないでしょうか」マサルは真剣な表情で提案した。「その方が早く終わると思います」
実のところ、私もそのことは何度か考えた。これは、武田さんのためだけではなく、第2開発課にとってもメリットがある。細切れで人員に抜けられると、ちょっとした打ち合わせなどもできないし、コミット待ちのソースを先に進められない。情けは人のためならずだ。だが、おそらく、そこまで全面的に第2開発課が介入することは、武田さんが拒否するだろう。
「うん。ありがとう。でも、とりあえず金曜日までは様子を見よう」
私は先ほどの五十嵐さんと同じ内容の言葉を返した。マサルは、納得した様子ではなかったが、それ以上主張することもなく自席に戻っていった。
カスミさんが私の方に身体を寄せると、微笑みながら囁いた。
「あの子も、ちゃんと自分の考えを言えるようになったねえ」
私は小さくうなずいて同意した。五十嵐さんが来たことで、この部の人間は全員が何らかの影響を受けているが、一番、変化したのはマサルかもしれない。
(続く)
この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術・製品の優位性などを主張するものではありません。
コメント
yamada
武田さんみたいな人は社内の情シスにいたほうがいいんじゃないかなぁ・・・
リソースかなり余裕がある環境じゃないと無理でしょ・・・
見込みが甘い上に検収日から期限を逆算して木曜日までとか自殺行為ですよ…
elseorand
仕様書にどうしても欲しいのは、業務観点でのフローと画面・機能の対応表
「この画面のこの機能は、お客さんのこういう要望があって、その要望のこの部分を満たすために、これこれしている」
これがあれば、ソース以外のドキュメントは不要に感じる。
そのソースもクラス・関数呼び出しが、3階層程度に収まっていればなおよし。
gems
スタイルや文字数の指定などのみためを仕様書に書くなんてー!! お客さんの確認時にあれこれどうせ言われるので、自分の感性を大事に実装してるw
こういう手法もありなんだけど、それはオフショアで大活躍します。ドット単位色のRGBも事細かくしないとフィールド整列されていないは、なぜか文字色はバラバラとか泣かされたw
DumbObj
設計書と仕様書の使い分けがいまいち理解できなかった。
"仕様書"を含むいくつかのドキュメントを合わせて設計書と呼び、それを検収予定ということなんでしょうか?
検収日当日まで手を打たず、武田さんを挑発する五十嵐さん、腹黒い。
スタイルはともかく、文字数は見た目ではないかも
"emailテキストボックスは60文字まで入力でき..."
http://japanese.joelonsoftware.com/PainlessSpecs/WhatTimeIsIt_Jp.html
http://japanese.joelonsoftware.com/PainlessSpecs/2.html
ふっちーlove
>バグを出さない方法を模索することに時間を費やすのをやめ、出しても迅速に対応できる仕組みを築き上げることに方向転換した。
ココは違いますよね?
バグを出さない努力を惜しむのがアジャイル的開発手法なら
ユーザー企業の立場ではウォーターフォールの方がマシ。
ピンポイントに反応してたちの悪いレビューアのようで申し訳ないですが、
利用者をデバッガ代わりにするなと思ってしまいます。
うっちー
↑ふっちーを愛するだけあってたちの悪いレビュアーですね…
さかた
>利用者をデバッガ代わりにするなと思ってしまいます。
立ってる者は親でも使えというし。
それはともかく、一番真剣にテストしてくれるのは、やはりエンドユーザだと思うぞ。
Perl命
バグを「出しても迅速に対応」するのはリリース前がメインでしょ。もちろん取りきれないのはあるわけだけど、ウォーターフォールよりかならずバグが多いわけではなく、「利用者をデバッガ代わりにする」とは言ってないでしょう?
J
ユーザテストまででバグを出しても迅速に対応できるようにって意味じゃないんですかね。
それより気になったのは要件定義の次が詳細設計というのはどうなんだろうかと。
基本設計はないの?という点でした。
お客さんって詳細設計のすみずみまでレビューするもんでしょうか?
通りすがり
>Jさん
そんな大規模でもないし、既存リプレイスのうえ捨てシステムなんだから、
要件の中にUI、I/Oの概要設計まで含んでいるんじゃないかな?
それに、今回の窓口は顧客の社内開発部隊ってのもあるでしょう。
>ふっちーloveさん
ネタだと思うけどナイナイ(笑)
テストがそのレイヤのフェーズに上がってくまで上流工程のバグ(結合、システム
設計、運用設計、画面構成等の欠陥)が判明しないウォーターフォールモデル、
特に下流工程からのフィードバックを否定した日本式ウォーターフォールモデルの方こそ
ユーザーにバグ押しつけてるって。
日本の大手SIerの開発が、その手戻りでどんだけ酷いことになっているのか
わかってんのかね?
個人投資家
AS/400の既存の在庫管理システムの、オープン移行案件なんでしょ?
AS/400ならRPGとCOBOLで作られていて、データベースはISAMファイルでしょう。
だとしたら、画面はWEB化するにしても、ターミナルのエミュレータをActiveXで組み込んだWEBと、プログラムはRPGかCOBOLのツールによる変換でしょう。
多分、オープンシステム用のCOBOLに変換する。
データはISAMファイルからRDBに移行しても、プログラムにはISAMファイルとしてみせるプラグインか、COBOLの拡張機能を使う。
数ヶ月で移行を行うのなら、これがが一番工数が少なくてリスクがない。
プログラムの中に仕組まれているビジネスロジックを抽出しなくて済む。
Javaで書き直す核なんて工数的にあり得ないなあ。
新規開発部分のテスト工数かんがえると、数ヶ月でリリースは無理だ。
eno
> 一番最初の大項目は「要件定義」で、これは予定と同じ長さのグリーンのラインが引かれていた。担当や武田さん、久保さんだ。
ここ『担当【は】武田さん、久保さんだ』でしょうか。誤字指摘のみで失礼します。
J
なるほど現行があるから基本設計はなくて、内製する会社だから詳細設計書見るってことですか。
あとはマサルが急に行って手伝えるような内容なのかなあと思ったり。
マサルはすげーヤツだかできるのかな。
こんな短期間だと追いついたと思った頃には終わってるんじゃないでかと。
DumbObj
>バグを出さない方法を模索することに時間を費やすのをやめ、出しても迅速に対応できる仕組みを築き上げることに方向転換した。
この箕輪さんの独り言が、アジャイルに言及してるのだとしたら、確かにちょっと違うと思う。
アジャイルは、ドキュメントより動くソフトウェアにより価値をおくけど、それは、バグを出しても迅速に対応できる仕組みを築きあげようとしたわけではないし、ましてやバグをなくす努力を惜しむものでもないと思う。
TDDやCIをイメージしてると考えられなくもないけど、武田さん式の仕様書を書いたほうがバグが減ると考えてることから、それもなさそう。
3~4人がみっちり3週間かけて作った詳細設計書を、1回のレビューで検収しろってのは普通無理。
しかも、ドット単位の領域定義とか不要な詳細が多いと、レビューの精度が落ちて、バグを量産したり。。。
がんばれ武田さん!
のこのこ
ここまで楽しく読ませていただきました。
在庫管理システムをWEBシステムに移行、発注が11月中旬で12月末納期
期間1.5ヶ月で要件定義に2~3週間、全体規模は6~8人月程度ってな感じで、
相手会社の社内リソースが足りないからこぼれてきた案件って状況ですかね。
こういう案件は、請負会社が主導をもぎ取って、要件定義なんてものは名ばかりの制限事項を記載した資料作成のみを行い、開発にコストを割かなければこけるだけだと思いますよ。
クライアント側が門外漢でなければある程度の制限がかかるのは承知の上だから、それを押さえて「動くもの」ができれば社内の言い訳が立つので、それに全員が向くことですな。まぁ要求者が高いレベルのものを求めてるのではなく、自分達の上や周りに「言い訳」が立つものを求めているって点を抑えていれば問題ないのだが・・・門外漢がやると言い訳資料だけは立派な「動かない」ものができあがる。。。という。
受ける前から結果見えてるけど、一番の被害者はそんな開発会社に掴まされたクライアントですかね
にしか立たないので