|
武蔵流プログラマ
山崎敏 YAMAZAKI Satoshi
vol.12 |
|
|
この話はフィクションです．フィクションと言うからには，「ですます調」より「である調」のほうが似合うと思うので，前回（前編）に引き続き今回（後編）もそのようにします． |
|
|
【前回のあらすじ】私はあるシステム開発でデスマーチに陥っていた．期限はあと1ヵ月．身も心もボロボロ．コードも書けていない．後輩の上田君は辞めると言っている．そんな中，女性プログラマの山田さんが投入される．彼女はいったい…．
|
|
|
●●V字モデルの登場 |
|
|
●手戻りを減らす
山田さんはホワイトボードに「V（ブイ）」の文字を大きく書き始めた．
「いいですか．私たちの仕事はシステムを完成させることです．」
と言いながらホワイトボードの右上に「完成」と書いた．
「顧客から要求があり，設計をして，コードを書く．
そしてテストをして，バグが出たら戻る」
そう説明しながら「要求」「設計」「実装」「テスト」
の文字を書き加えた．この図なら見たことがある．
ウォーターフォールモデルの変形で，「V字モデル（図1）」とか呼ばれていた気がする．
そう思ったことを上田君がそのまま発言した．
「V字モデルですね．」
「そうです．問題なのは，テストでバグが出た場合の手戻りなんです．」
と山田さんは手戻りの矢印を強調した．
私の知っているV字モデルには「手戻り」という矢印はなかった．もともとは，「設計した人がテストをする」という階層を表しているモデルだったはず．ここは山田さんの独自の解釈なのだろう．
「バグが出ると，テスト待ちの多くのコードに影響を与えます．場合によっては，テスト待ちのコードをすべて修正する必要も出てきます．」
と山田さん．
「我々は，バグのないプログラムを書かなければいけないということですか？」
と上田君．
「いや，そうではなくて．そもそもバグのないコードを書ける人はこの世の中には存在しないんです．私にも無理です．」
と山田さんは否定した．
●コードを減らす
「では，どうしろと？」
私は具体的な方法を聞いた．
「簡単です．書くコードの量を減らせばいいんです．」
と山田さんはあっさりと答えた．
「は？」
またしても全員が山田さんの言っていることが理解できていない．
「たとえば，100行のコードからバグを探すのと，1,000行のコードからバグを探すのでは，100行から探したほうが圧倒的に楽です．1度にテストするコード量を減らすのです．3本の矢を1度に折るのではなく，1本ずつ折るということなんです．」
なるほど，言いたいことはわかってきた．
●TOCのDBRを適用
「では，具体的にはどうするのですか？」
私はさらに細かい方法を山田さんに聞いた．
「まず，ボトルネックと考えられるテストを通過するコード量を測り，全体作業の速度をテストの作業速度に合わせます．要求から設計に投入する量を制限するのです．
このとき，必要以上の要求を投入しないように注意します．すべての要求を一度に投げるのではなく，細かく分割して少しずつ投入するのです．
そして，すみやかにテストを実施するために，設計の段階でテストコードを書くのです．
テストでバグが出たら設計に戻ります．この手戻りを少なくし，このサイクルをできるかぎり小さく高速に回します．ボトルネックの効率を優先するためです．
投入量を細かくコントロールし，さらにテストコードをあらかじめ用意することで，ボトルネックに効率良く動いてもらうわけです．」
と，ここまで話を黙って聞いていた上田君が言った．
「これはTOC（Theory of Constraints）ですか？」
「そうです．TOCのDBR（Drum Buffer Rope）の考え方です．そのDBRの考え方をシステム開発にあてはめているわけです．」
と山田さん．
「なるほど，これはすごい．」
と上田君．
たしかに，こんな考え方（図2）はいままで誰もしていなかった．TOCの考えは『ザ・ゴール―企業の究極の目的とは何か』（Eliyahu M.Goldratt著／三本木亮訳／ダイヤモンド社／ISBN：4478420408）などの本を読んで，私も知ってはいたのだが．それは工場などの生産的な作業現場での話であって，システム開発のような知的作業には直接適用できるとは思っていなかったからだ．
システム開発の場合は，原材料があるわけでもないし，加工があるわけでもない．さらには生産能力を数値で測ることも難しい．しかし，この方法ならどうだろうか？
●V字モデルミクロ／マクロ
顧客からの要求を細かく分けて原材料に位置付ける．その原材料を加工するのがコーディングだ．
そしてテストを通ったコードが製品になる．しかし，細かい部品（単体テスト）レベルのコードが完成しても，全体が完成したことになるわけではない…．ということは，その部品の結合テストがいるわけだ．まてよ，それは別にシステム開発だけが特別な作業ではなく，どんな工場でもやっている．結合テストをして，うまく動かない部品を特定して，その部品を再度作り直せばいいわけだ．
そうか，V字モデルがフラクタル構造になっているわけだ．「実装」の部分もV字になっていて，「詳細設計→コーディング→単体テスト」と小さなループになっている．さらには，マクロに見れば「開発／創る→生産／作る→販売／売る」という大きなループもある．V字モデルはマクロでもありミクロでもあるということか（図3）．
●あとは実践
なるほど，理論としてはいい．あとは，本当にそれが実践で通用するかどうかだ．いや，うまくいくかもしれない．論理的な破綻はないし，やってみる価値はありそうだ．
|
|
|
●●高速 |
|
|
早い，とにかく早い．1日という時間がとても短く感じられた．
出社すると，まず，現状を確認するためにプログラマ6人，全員立ったままミーティングをする．
現状はどうなっているのか，問題はないか，フィードバックすべきことはないのか，今日は何をすべきか，このミーティングは3分もかからない．朝は必ずすることになっているが，何か問題があれば，すぐに作業を中断してその場でミーティングが行えるため，朝のミーティングの時間は短い．
この速度は快感だ．プロの仕事をしている気がしてくる．
そのあとやるべきことをこなすとすぐに昼になり，15時になり，退社時間になる．あっという間だ．そして帰宅するのだが，そのころには酷使された脳は軽い悲鳴をあげている．これ以上続ければ，やはり効率は落ちる．そのことが強く感じ取れる．しかし，これほどの質のコードをこれほどの効率で書き上げたことが，いまだかつてあっただろうか．かなりの達成感がある．
考えてみると，十分な睡眠は確実に必要だ．プログラマという仕事はとにかく頭を回転させないとならない．とにかく頭を使う．自分の考えていることを正確に表現することがどれほど難しいか…．しかも間違えは許されないし，曖昧な表現はできない．必ず「Yes」か「No」か，はっきりとした表現にする必要がある．そこは適当に…ということができない世界なのだ．
これだけ集中して頭を使うと，割り込みによるロスは大きなものになる．以前のように電話がじゃんじゃんかかってくる部屋での開発は，今では考えられない．はっきり言えば，それは開発ではなくただ時間をつぶしているだけだ．とにかく，この開発室に電話がないのはいい．ネットに繋がずにメールの受信による割り込みをなくしたのも正解だ．開発以外の作業は，残りの4人がつねにバックアップしてくれている．これほど頼もしいことはない．
|
|
|
●●仕様は生もの |
|
|
「仕様は生（なま）もの」とはよく言ったものだ…．私は感心していた．壁一面に貼られた付箋紙は，毎日のように姿を変える．まるで成長していく生き物のようだ．開発当初は数枚の付箋紙であったが，現在では壁一面を埋め尽くしている．今日も数枚の付箋紙が増え，そして移動している．1枚1枚の付箋紙が生き物であり，それぞれがゴールを目指して歩んでいる気がしてくる．
あらためて我々の作ったシステムの形が見えてくると，なんとも不思議な感じがしてくる．開発当初に書いた仕様書の内容とはまったく違うモノが現れたのだ．たしかに概要というかおもな機能は変わらないのだが，当初の仕様書に書いていた内容とはまったく違っていた．
こうして全機能が見えてくると，バグなど存在しないと言える気持ちになってくる．もしバグが出たとしても，この状態なら1時間，いや10分あれば解決できると自信が持てる．そもそも，このようなクリアな状態でバグが出るとは思えないというのが正直な気持ちなのだ．
このように1つの壁を毎日全員が眺め，議論し，フィードバックし，改善し，加え，除き，変化しつづける最新の情報を共有する．顧客代表の矢部氏にも笑顔が多くなったのを感じる．この壁を見ていると安心するのだろう．なにしろ，形として見えないソフトウェアがこうして目の前に見えるのだから．そして，そのソフトウェアは完成していない現時点でも正しく動作するだから．
|
|
|
●●コミュニケーションとモチベーション |
|
|
考えてみれば，電子メールや電子掲示板そして電話などのハイテク装置は必要ないと思いはじめた．なぜなら連絡をとる必要のある人間は数メートル以内にいるからだ．これは意外な盲点だった．
たしかに電子メールや電子掲示板などのハイテクシステムは便利である．とくに，直接会うことの難しい人たちと連絡を取り合うには強い味方になってくれる．
しかし，我々はいつのまにかその便利な機能に頼ることで，行くべきところに行かなくてもいいとか，集まるべきところに集まらなくてもいいと勘違いをしてしまっていたようだ．いくら電子メールや電子掲示板が高機能で使いやすくなったとしても，コミュニケーションの手段として「直接会って話す」という行為にはかなわないのだ．
システム開発とは考えてみれば，伝言ゲームのようなモノで，いかにして高速にそして正確に情報を伝えるかが勝負であり，そのほかの知識やテクニックに関してはそれほど重要ではないのだ．
たしかに，最終的にモノを完成させるには多くの知識やテクニックが役に立つだろう．だが，その知識やテクニックを発揮するための前提として，正確な情報が素早く伝わることが重要なのだ．
おそらく，山田さんはこのコミュニケーションの重要さを知っていたのだろう．いや知っていたというよりも，長年の経験の中から自然に感じ取ったに違いない．
・全体を見渡すマクロな視点
・素早く的確な判断
・コミュニケーションによる高速なフィードバック
この3つがシステムの開発効率を高めている．これらは山田さんの「顧客のメリットを考える姿勢」から感じられる．そして，システムそのものの価値も高め，開発チームのモチベーションも高めているのだ．私は山田さんからこれらのとても大事なことを学んだ．
|
|
|
●●最適化 |
|
|
●最適化は○，×？
「上田さん！コードの最適化なんかしなくていいんです．テストしないコードも書いたらダメです．」
と山田さんは朝からテンションが高い．
「山田さんこそ，仕様をコロコロと変えないでくださいよ．動いているコードを修正するのはリスクが高いじゃないですか．」
上田君も黙っていない．
「いいえ，仕様を変えないほうがリスクが高いんです．変わらないという選択そのものがリスクなんです．環境の変化に追従できない生物は絶滅するしかないでしょ．とにかく，変化に追従できる状態を維持することが大事なんです．」
と山田さんも反論．上田君は黙っている．
たしかにそうかもしれない．しかし，彼には彼なりのやり方があり，それが正しいと信じてこれまでやってきたのだ．少しでもプログラムが早く動くようにコードを最適化し，少しでもコードに汎用性を持たせようとオブジェクト指向を強化してきたのだ．ただ，山田さんに言われるまで「テストを中心としたコード」というのを考えたことがなかったのだ．
●最適化は一点突破で
山田さんは，「部分を最適化しても意味がないの．全体を見て．
我々のすべきことは，顧客の要件を速やかに実現すること．そのためには要件を洗い出し，テストコードにし，テストを通す，それが最優先なんです．」
と言う．我々も，山田さんの考え方を受け入れようとそれなりに努力している．ただ私や上田君は，最適化に関する経験が長く，かつそのことが評価されてきただけに戸惑いも大きい．
車のハンドルに「遊び」があるように，システム開発にも作業を最適化すべきでないところがあるのだ．ボトルネックであるテストは最適化すべきだが，テスト以外の非ボトルネックの作業はもうこれ以上最適化すべきではないのだ．
「あれもこれもできないでしょ．できるだけシンプルに一点突破でいくの．」
と山田さん．
そんな言葉を聞きながら，私は思っていた．
我々日本人は，手先が器用で，最適化が得意だと言われてきた．だから，どうしても簡単に成果の出せる最適化に走り，それに頼る傾向があった．
あれもこれもと最適化しすぎなんだと．
●万能ツールとは
そして「こうすれば必ず成功する」という万能な方法論は，この世には存在しないのだと．いや，万能な方法論ではなく万能なツールなら世界に1つある．それは，耳と耳の間にある頭だ．頭脳こそが万能なツールなんだ．
その頭を使うには，現場で感じて考えて，実際やってみて失敗して，そしてフィードバックする．
V字モデルで言うのなら「考える→やってみる→失敗から学ぶ」というループ（図4）．たったそれだけのことなんだと…．
|
|
|
●●天国 |
|
|
●季節はずれの嵐
もうすぐ春とはいえ，3月の朝の空気はまだまだ冷たかった．しかし，今日の天気はいったいなんなんだ．季節はずれの嵐．バケツをひっくり返したような雨とはよく言ったもんだ．多くの社員は電車通勤である．駅から会社までは，この嵐の中に放り出される．
しかも都会の嵐は尋常ではない．前後左右そして下からも襲いかかる．傘はまったく役に立たない．全身ずぶ濡れである．朝からこんな状態では仕事にならない．バブルな時代には，雨に濡れるのがいやで駅からタクシーを使って通勤したツワモノもいたが，それも最近は見かけなくなった．
そんな嵐にあっても，私の気持ちは春を先取りしていた．おおげさに言えば天国だった．久しぶりに，「余裕」という感触を味わっていた．なぜかと言えば，納期まで1週間以上の余裕を残して，予定していた入力部分のテストが終わったのだ．この状態ならいつでも顧客に渡せる．いや，顧客の矢部氏もすでにこのことは知っている．
昨日の出来事なのだが，ようやく単体テストが終わり，結合テストが始まった．通例であれば，ここからが正念場である．結合テストでは単体テストよりも困難なバグが出るからだ．しかし，あと1週間あるのでなんとかなるという気持ちはあった．少なくともコードは納期前に書きあがった．
これだけでも，当初からすれば奇跡に思えた．
●結合テストの開始
事態は予想外の方向に転んだのだ．昨日，結合テストを始めた上田君が言った．
「バグがありません．」
そんな言葉は，過去十数年間聞いたことがなかった．私は上田君言葉の意味がよく理解できずに聞き返した．
「え？」
「何度もテストをしたのですが，バグが見つからないのです．」
上田君も困惑した表情だった．
「どういうこと？」
と聞き返す私．
●バグ数ゼロ？
「状況を説明すると，結合テストは一度でパスしました．何の問題も発見されなかったということです．バグ数ゼロです．」
上田君の言葉に私は「そんなバカな」と思った．
しかし，この状況ならばありえない話でもないと思い直した．単体テストの精度が高いのか，あるいは…と思い念を押して聞いてみた．
「結合テストのテストプログラムは正しく動いてるの？」
「はい．その可能性も考えて調べてみたのですが，エラーケースもちゃんとエラーを返しますし，正常に動いています．」
上田君の経験からいって，プログラムに関して間違った判断をするとは思えない．となると残る答えは1つ．あっけなく入力部分が完成したのだ．
しかもバグ数ゼロで…．信じられなかったが，どうやらこれが事実のようだ．これもすべて山田さんのおかげだ．
そんな我々のやりとりを聞いていたのか，山田さんは言った．
「言ったでしょ『納期どおりに完成できる』って．」
|
|
|
●●崩壊 |
|
|
●事態の急変
そういえば，今朝は山田さんの姿を見ていない．
この嵐に捕まったのか．とくに仕事に関しては厳格な彼女がまだ来ていないなんて…．
そのとき，プログラマの1人が何か叫んでいた．
「たいへんです！来てください！」
嵐の中，上田君が時間に遅れながらも息を切らせて入ってきた．
「すみませんっ，電車が止まってしまって，遅れました…はぁはぁ…．」
上田君は普段とは違うピリピリした周りの雰囲気を感じ取り言った．
「何かあったんですか？」
「上田くんは昨日，何時ごろ帰った？」
「定時15分すぎくらいですけど…」
「そのとき，山田さんはいたかな？」
「ええ，いつも彼女が最後にチェックして，部屋を閉めて帰りますから．そのことは皆さん知ってますよね．山田さん，今日はまだ来てないのですか？」
「来てないんだ．それより，たいへんなんだ．PCが壊れているんだ．OSから何からすべて壊れている…」
「ええっ？！何もかもですか？3台とも？」
「ああ，3台ともだ！」
「マジですか！ウィルスですか？」
「いや，この3台はほかのネットからは完全に独立しているし，ウィルスに感染するような環境じゃない．それにウィルスがここまで破壊することはできないはず」
「じゃぁ，なぜ？誰かの仕業ですか？」
「この部屋は鍵がかかるから，簡単には入れないはず…．あとは，最後に部屋を出た山田さんに聞いてみないとなんとも言えないが…．」
●いったい誰が…
いったい誰が…．山田さんがわざわざこんなことをするとは考えられない．となると昨日会社に残っていた誰か…，一軍のチーム？まさか．いくらなんでもそれは強引すぎる．ありえない．
以前の開発環境であればCD-RもMOも揃っていて，バックアップを別の媒体に残すことは容易だった．しかし，ここにある急ごしらえの開発環境には，ノートPC3台以外には何もなかった．HDD内にはバックアップを取っていたので，3台あれば同時に紛失することは考えられないと思っていた．
しかし，今となると外部の媒体にバックアップしていなかったことが悔やまれる．
あと少しだったのに，何もかも失った．上層部にはなんと説明したらいいのか…，いや，それよりも，我々の努力の結晶が，金に変えることのできない失われた時間が大きかった．それは取り返すことのできない時間．そして，そのことを考えると悲しみや怒りよりも強い脱力感を覚えた．真っ白に燃え尽きた…という言葉が私の頭の中を支配していた．
●雷！
そのとき突然，物凄い衝撃がやってきた．爆発音とも言える物凄い破壊音とともに地震のように足元からビリビリと響く地響き．そして閃光！ドッッカーーン！！ビリビリビリビリ…ゴゴゴゴ…．
雷だ！しかも近い！すぐ近くに落ちたらしい．
開発室は停電．あたりは騒然となる．女性の悲鳴や動揺の声が聞こえる．
「これだ！雷だ！」
と誰かが言った．
ノートPCはバッテリがあるので停電でも動く．
しかし，雷のときの異常な電圧は電源コンセントやLANケーブルを通してPC本体にダメージを与える．PCの作りにも関係するようだが，雷に弱い機種も存在する．その異常な電圧にノートPCのHDDが耐え切れず，データがすべて消えてしまったようだ．すぐさまノートPCの電源を抜いた．これ以上雷が落ちたら，ハードまでも壊れてしまうかもしれないからだ．
●バックアップがあった
そんな騒然とした空気の中，上田君が何やらカバンの中からゴソゴソと取り出し，
「ジャジャーン！ピーシーカード！」
と何かのモノマネのように言ったが誰もニコリともしなかった．
「バックアップはここにあります．結合テスト直前のバックアップです」
「おおー！」
と一同唸る．さすが上田君．やることが違う．
「結合テストの前まで戻ってしまいますが，結合テストではバグも出なかったので，すぐに元に戻せるでしょう．」
いやぁありがたい．助かった．これで立ち直ることができる．その日は1日，ゼロから開発環境を構築し直した．これで仕事が再開できる．危なかったが，なんとかなった．
その日，山田さんはとうとう姿を現さなかった．
彼女の身に何もなければいいのだが…．
|
|
|
●●春 |
|
|
●納品
「さーて，飲みますかぁ」
日本酒に目のない上田君が言った．あたりはすっかり暗くなっていた．顧客の会社，矢部氏の会社は郊外にあった．自然が多いと言えば聞こえがいいが，素直に言えば山の中だった．昼間に来たときは感じなかったが，帰りが夜になるとひっそりとして妙に静かだった．
今日，無事に納品が終わった．システムが完成したというわけだ．納品といっても形だけの作業で，実際にはシステムは何度も顧客に渡されていて，矢部氏も事前に「問題はないです」と言ってくれていた．私と上田君は顧客先の会社で矢部氏とともに納品作業を終わらせ，3人でささやかな打ち上げしようと顧客の会社の玄関を出た．
我々二軍チームは予定どおり入力部分のシステムを収め，その3週間後には全体のシステムが完成していた．
●そういえば…
そういえば，一軍チームのシステムは完成したのだろうか？今となっては，一軍，二軍，どちらのシステムが顧客に採用されるかといった勝ち負けは，もうどうでもいいことに思えていた．デスマーチは終わったのだ．
それでも少し気になるので，それとなく聞いてみた．
「矢部さん，一軍のシステムはどんな感じですか？」
「あれ，知らなかったのですか？一軍チームは別のシステムを開発していたのですよ．」
「え，そうなの？」
「池田本部長に最後まで騙されましたね．」
「上田ぁ！おまえは知ってたのかぁ？」
「えぇ…こっそり山田さんに教えてもらいました．」
「くそー！あのタヌキオヤジめ！許さぁん！」
●山田さん
結局，あの雷の日以来，山田さんは我々の前に姿を現さなかった．もう一度ちゃんと挨拶をしたかったのだが…．風の便りでは，携帯電話の組み込みプログラムのデスマーチの救済に向かったとのことだった．彼女はこうやって，あっちこっちの火を消しに走り回る消防士なのだろうか．もう1つの別の噂では「山田さんはあの池田本部長の娘だ」とのことだった．
今回の仕事で，山田さんには大切なことをいろいろ教わった．こうして無事に納品できたのも山田さんのおかげだ．この気持ちを彼女に伝えたいと心から思った．いや，それ以外の想いも伝えたいと強く思った．
●上田君
そして上田君はこれからどうするのだろうか？田舎に帰ってしまうのか？少なくとも今の上田君の顔からはそのことは感じとれなかった．それもこれも，このあとの酒の席で明らかにされるだろう．
「きれいですねぇ，矢部さんがうらやましい」
と上田君の声に，あたりを見回してみると，そこには夜の闇の中，街頭に照らされたたくさんの桜の木が満開に花を咲かせていた．我々は桜の花を眺めながら黙ってしばらく歩いた．
|
|
V字モデル【後編】