V字モデルが割と良かった話

on


今朝、タイムラインを眺めていて目に入ったのが、いや、違うな。本当は週末にすでにタイムラインで見かけていたんだけど、すっごくに気になっていたんだけどスライドを読んだのは今朝だった、と言う話です。


JJUG 2014 fall 「私がTDD出来ないのはどう考えてもお前らが悪い！」


タイトルからネタっぽいので「どうなかー」とは思いつつ、緑色のスライドデザインに惹かれた……違う、気になっていたから今朝はスルー出来なかったというか。


ワタシ的に「テストを先に書く。」という行為は良いと思うんですが、TDDだけひっぱり出してきてチームに「やってみて。」と言うかと考えると「それだけじゃ上手くいくわけないだろう？」とも思ってしまう。案の定、スライドの中でもそればっかりじゃダメなのよ、いろいろな仕組みの中でやるのよ、とありましたけど。


V字モデルが思っていたより良かった話
とある開発で、本番系をリリースした後に災対サイトを立ち上げるプロジェクトがあったんです。で、本番をリリースした後、災対サイトをどうやって安全に立ち上げるかという検討する必要がありまして。如何せん、利用者が多くて止めたらそれはそれで大騒ぎには成るし、多分、開発責任者が顧客に呼び出されて叱責されるのは想像に難くなかったのは、ポカをした方はそのフォローというか始末でものすごいワークになってしまうのを他チームが事故を起こしていたので知っていたからです。


その上、担当するシステムはパッケージでナレッジはマニュアルベースしかないというこれまたリスクがコンボになりそうな気配もあります。沢山の利用者がいるということは、業務規制を掛けるにしてものんびりとはやってられない可能性が高いです。あーこのあたりは当時はまだ検討の遡上に上げられる物的確証がなかったのですけど。まぁ、もろもろの制約が多そうだ、のレベルでしか手元に情報がない。


じゃあ、どうしたかと言うと、先ずは「机上で方式の確立」です。当たり前ですけど災対サイトを作るという目標があるのですからソレをどう作れば作れるのか、っていう理屈がないといけない。そして、その理屈をするにはどんな仕様があるのか、どんな前提があるのか、どんな制約があるのかを明示的にする必要があります。


その次にすることは、その「机上での方式の確からしさ」を如何に担保するか、ということです。


これ、コレをやったあとに実感したことなんですが、これをやっておかなかったら幾ら机上で頭をひねって考えても抜け漏れは発見できなかったかもしれない、ということです。それって、先の開発責任者が顧客に呼び出されて……のパターンになる可能性を秘めている、と言うことです。そればかりか、ポカの程度によっては利用者の業務に支障が出るかもしれない、ということの業務への影響は大きくてそれはそれで現実になったらとんでもないことです。


結局何をしたかと言うと、素直に「テスト仕様を書いた」、たったそれだけです。総合テストの中項目レベルででしたがテスト仕様を書くことで机上の方式の確からしさを担保しよう、と。


なんかとっても王道な感じですね。でも、とても効果があったんです。何にか。それは、システム環境、ネットワーク、テスト端末、災対サイトを構築する際の依存関係などなどが「曖昧なままだった」り、「暗黙の裡に前提にしていた条件」がボロボロ出てきたんです。


このときのメンバの、特に技術リーダの驚いた顔は今でも思い出せます。「こりゃスゲー」って。


成果
このやり方の成果です。

  • 災対サイトの構築手順の検証テーマが決まった。
  • 構築に必要な手順書の目録ができた。
  • 検証の際の作業時間を計測しておくことが決まった。
  • 構築、テストで必要なお助けツールの開発リストができた。
  • 設計書に何を書けばいいかが決まった。


つまり、「やることリスト(to do)がはっきりした。」ということです。これって、単なるV字モデルをやっているだけなんですけどね。でも、プロジェクトマネジメントの観点で考えれば、あとあとの設計やら、構築やら、テストの軸がぶれなくて良いと思いました。


多分、みなさんは普通にやっていることなんだろうと思います。だからその先のテストの実際のところのTDDの話をしているんだろう、と。でも、もっと前に戻って、プロジェクトを俯瞰する視点で見直すことがあとあとの作業品質やらテストの正当性やらを助けることが出来るということも知っておいてください。