前の話→“好き”と“関心”を巡る冒険 第一章 vol.4 - Sato’s Diary
全話リストはコチラ
私が見つけた”好き”と、
私が抱いている”関心”の実現は、
もしかして、この場所で、両立することはできないのでは？
そんな想いを抱える社会人3年目の冬、
プロジェクトは結合テスト工程へと入っていった。
大勢でひとつのシステムを作る時、
最初はバラバラに担当の部品を作っていき、
結合テスト工程で、それらの部品を繋ぎ合わせて、
システム全体が想定通りの動作をするか、確かめる。
この時になって、私は初めて気づく。
自社、親会社、関係会社を含めたプロジェクトメンバーのほとんど誰もが、
お客さんの要求していたことを理解していなかったのだということを。
私たちが開発していたのは、
とある専門文書を自動生成したり解析したりするシステムだった。
文章のパターンは複雑で多岐に渡り、単純なルールを決めることは難しかった。
お客さんは初期の打合せで言っていた。
「実際に動かしてみて、生成された文書を確認しながら、
調整していくような形でやっていきたい。
アジャイル開発のような形でお願いしたい」
システムの開発形態には大きく、
ウォーターフォール開発とアジャイル開発がある。
ウォーターフォール開発は、設計、実装、テストの各工程をがっちりと
石橋を叩くような感じで一つ一つ進めていって完成させる。
品質の高さを保証する代わりに、後からの変更に弱い。
それに対してアジャイル開発は、小さく作るところから始めて、
そこから柔軟に変更を加えながら育てていく開発スタイルだ。
趣味でやる開発はアジャイル開発に近かった。
だから、最初にお客さんの話を聞いた時も、
「あぁ、なるほど、アジャイル開発ね」
私は普通に納得して頷いていた。
だけど実際に開発が始まると、どうにもウォーターフォール型の開発形態だった。
少し「あれ？」と思いはしたが、
開発関係者が50人規模のプロジェクト。
趣味でやる開発とはやり方が違うのかもしれないし、
お客さんとの契約内容とかも何か変わったのかもしれない。
大きなシステム開発に初めて携わる社会人3年目の私は、
大して疑問を抱かなかった。
だけど、そうではなかった。
そうではなく、プロジェクトメンバーのほとんどが、
アジャイル開発とはどういうものなのか、理解していなかったのだ。
最近ではアジャイル開発もそれなりにメジャーになってきたが、
2005年当時、大手のシステム開発会社の開発形態は、
ほとんどがウォーターフォール開発で、
ほとんどの人は、アジャイル開発という言葉は、
資格試験の出題キーワードとして知っているくらいだった。
開発の途中で一度、簡単な動くデモを見せたことがあった。
それで、アジャイル開発なのだと、
ほとんどの人間が思い込んでいたのだ。
実装担当者が開発を追い上げている中、
並行して結合テスト工程が始まり、
まず、テスト項目の作成担当者たちが
「何のテストが通ったら、テストOKってことなんだ？」
ということで、さざめき始めた。
想定される入力項目・出力項目を単純にリストアップできるタイプの
システム開発しか経験してこなかった彼らは、
文章の組み合わせによって、
あらゆる形の文章が生成されうるという今回のシステムにおいて、
どういったテストを行えばいいのか、わからなかった。
それでもやがて、104項目のテスト項目が用意され、
親会社のＥ課長とＭさんが、私の元へやってきて、
「これでいいかな？」
と私に尋ねた。
その頃の私は、
周りからのあらゆる依頼事項を突っぱねるチームリーダーと、
「君はもう自分の開発に集中していいよ」と周囲が言ってくれ始めたおかげで、
ようやく自担当機能の開発に集中できる状態となっていた。
Ｅ課長の持ってきたテスト項目書を見て、
「書いていることは間違ってはいないですけど…でも、これ…
ただの基本ケースですよ？」
一抹の不安を感じながら、私は答えた。
このテストをクリアしたところで、スタートラインを切った、
というくらいの話だ。
これだけをクリアしたからといって、
システムは使い物になど、全くならない。
でもまず最初は、これでいいのか…？
ここから、システムを育てていくっていうことで、いいんだろうか…。
私の答えを聞いて、
「これでいいみたいだ」
と言いながら、Ｅ課長とＭさんは他のメンバーたちの元に戻っていった。
彼らがシステムの要求事項も、アジャイル開発のことも
まったく理解していないことに、この時まだ気づいていなかった私は
一抹の不安を感じつつも、そのまま二人を見送った。
だけれども、そこから、プロジェクトが大きくざわつき始めた。
自社や親会社は、このテストをクリアできれば要求仕様を満たせると主張し、
お客さんたちは、もちろん、
「いやいや、これだけ出来ても使い物にならない！」と言い、
それに対し、
「じゃあ、何が出来たらOKなのか、全部出してくれ。追加費用請求するから」
という要求を返し、
「そんな馬鹿な！」とお客さんが叫び…、
「じゃあ、ここで開発を打ち切ります」と返し…。
泥沼と化していった。
社会人3年目の私は、守られていたからというのか、何というのか、
この泥沼でやり合っている現場を、幸か不幸か、直接には見ていない。
だけど、直接見ていなかったはずなのに、その様がありありと目に浮かぶのは、
親会社のE課長や、自社の部長、プロジェクトリーダーの先輩、お客さんたちが、
打合せの合間、合間に、入れ替わり立ち代わりに
私に色々と確認しに来たからだ。
彼らの問い合わせに、私は私の考え――
この104パターンは基本ケースであって、これだけでは使い物にならない――
ということだけを伝えて、
あとはただひたすらに、自分の機能の開発に集中していた。
私は、怒っていた。
まったく使い物にならないシステムで、
「これで仕様通りです。これ以上は追加費用です。
納得してもらえないなら、ここで打ち切ります」
と、のたまう自社や親会社に。
私が所属していた大手企業グループにとっては、
そこまで大きなプロジェクトではなかった。
こじれたまま、ずるずると行くよりも、
さくっと打ち切った方が良かったのかもしれない。
だけど、お客さんたちにとっては、
社運を懸けた一大プロジェクトだった。
「これじゃ全然ダメなこと、君はわかっているよね。
君から、俺たちの要求が追加要望なんかじゃないことを言ってくれないか」
そこまではっきり言われたかどうかは、よく覚えていない。
私が何の力も持たない、ただの若手に過ぎないことなど
充分わかっていたお客さんたちが、
私に無理な要求をしたことなど一度だってなかったから。
だけど、彼らの縋るような、悲鳴のような、
切実な、その声を、
私は確かにどこかで聞いた気がするのだ。
だけど。
お金のことも、
契約のことも、一般的なシステム開発のことも、
まだ何もわかっていない3年目のペーペーの私には、何もできなかった。
何も知らない自分が、
この会社からお金をもらって生活している自分が、
ただの正論を振りかざしたところで、そんなのは、ただの子供の正義漢だから。
私にできることは、ただ、自分の担当機能をいち早く仕上げること。
そして、せめて自分が何とかできる担当機能部分についてだけは、
少しでもお客さんの要望に応えられるようにすること。
それだけが私にできることだろうと
内心に怒りと悔しさを抱えながら、ただひたすらに開発に専念していた。
（つづく）
次の話→"好き"と"関心"を巡る冒険 第一章 vol.6 - Sato’s Diary
全話リストはコチラ
