« 2006年2月5日 - 2006年2月11日 | トップページ | 2006年2月19日 - 2006年2月25日 »

ウォーターフォールはこう使え(まとめ)

 この連載を始めたのは、Waterfall 2006を見たから。ついカッとなって書いてしまった。今は反省している。この連載は体系的じゃないし、blog よりむしろ出版物の形で問うべき。何よりも、今週の睡眠時間を大幅に犠牲にしてきたので、眠くてたまらん。

 …というわけで、ここでは総括+補足して締める。

* * *

 ウォーターフォール・モデルとは、プロジェクト構造化モデルと言い換えられる。その特徴として、以下のことが挙げられる。(その1)


  1. プロジェクトを構造化し、段階を踏んで要素成果物を構築する
  2. 次に、必要な要素成果物を適切なタイミングで持ち寄り、組み上げる
  3. 要素成果物を構築する工程はスパイラル・モデルを適用できる。しかし、組み上げる工程は逐次的であることが求められる

 プロジェクトを構造化することにより、プロジェクトを「見える化」できる。全体と部分、出来てるところと空白のところが分かる。未確定事項がオープンになり、ベースが明らかになるのでそこへの変更が「変更」として管理できる。(その2)

 クリティカルパスによく乗っかりがちな「仕様の確定」は、日付を決めることで現実的なものにする。契約前はペラペラだろうし、プロジェクト終盤では遅すぎる。だから、契約直後になんとしてでも形にする。そのためには、プロジェクト序盤で、「仕様が明確化されていない」事実を顧客自身の口から言ってもらう。(その3)(その4)

 責任問題となったとき、最終的にプログラマを「守って」くれるのはドキュメント。プロジェクトが傾いたとき、その建て直しの土台となるのがドキュメント。ソースから自動生成できるが、全部読んで理解することを顧客に求めるのは無謀というもの。ドキュメントとは契約書だと意識すること。(その5)

* * *

 変更、特に仕様の変更について。ウォーターフォール・モデルで「変更」は別ライン、すなわち未来日の peak で受け渡しを約束する別チームが対処する。

 そのためには、リソースを新たに割り当てなければならない。これを嫌がるPMは現在のチームでその作業をさせようとする(←これが間違い)。その結果、現行チームの能率が大幅に低下し、クリティカル・パス上の神輿のスピードが落ちる→未来日の peak に間に合わなくなる… という悪循環がある。

 一方、きちんとリソースを割り当て、別チームが出発できれば、これほど理想的に働く方法はないといえる。なぜなら、未来日の peak で現行チーム・別チームが合流するようコミットできるからだ。ウォーターフォールでマイルストーンの「日付」にやかましいのは、その日をプロジェクト全体として保証するため。「次」はもうないのだ。

* * *

 ウォーターフォールとスパイラルの役割分担について。プロジェクト全体を俯瞰し、マスタースケジュールを粛々と実行するのはウォーターフォール、個々の「すべきこと」を割り当てられたチーム内で実行するのはスパイラルが適している。

 つまり、マイルストーン+成果物のマネジメントはウォーターフォールで、「方式」や「業務」で、peak とチームが割り当てられた中ではスパイラルで回すほうが良い結果を出している。契約のコミットが求められ、後戻りができないものはウォーターフォール、ある程度分解された目標をクリアするにはスパイラルが良い(と経験的に知った)。特に「方式」のネットワークやデータベースアクセス、部品の開発にはスパイラルが最適。

* * *

 わたしはウォーターフォール信者ではなく、アンチ・アジャイルというわけでもない。ウォーターフォール・モデルでのプロジェクト経験が多かったというだけ。良いウォーターフォール悪いウォーターフォールの双方ともに、沢山の knowledge を積んできている。だから、危機に陥ったときどうすればよいか適切に判断できるし、そもそも酷い目に遭わないようにするには何を準備しておくべきなのかも身をもって知っている。

 フシギなことが一つある。スパイラルであれアジャイルであれ、RUPでもいい。世に問われてから随分と時間が経っているが、knowledge は積まれているだろうか? 偉大なるグルの著作物のことではない。ありゃ"教科書"だ。そうではなく、実践において結果を積んでいるだろうか? 単なる「プログラミング+アルファ」のレベルを超えて、プロジェクト全体を任せられるものとして育っているのだろうか?

 プロジェクト全体を任せた事例があるなら、紹介してほしい。断っておくが、「実験的なプロジェクト」や「どっかの研究室が主催したやつ」ではない。また、一度きりではなく、繰り返し(=spiral)実践で培った事例だ。10年以上前、まだ「オブジェクト指向」が手垢にまみれてないときから、ずっと探してきたが、いまだに見当たらない。

* * *

 また稿を改め、ウォーターフォールならでの事例を紹介してみたい。あるいはもっと体系的に書き直すべきかも。いずれにせよ、次回からは「スゴ本」の紹介に戻るとしよう。

| | コメント (2) | トラックバック (3)

ウォーターフォールはこう使え(その5)

 ウォーターフォールの怨嗟の的になっているのは「ドキュメント」だろう。使うかどうかも分からぬような大量のドキュメントを書かされる。しかも顧客の一言で大幅に書き直しを命ぜられる。さもありなん。だが、ここでは、ウォーターフォール・モデルにおけるドキュメントの必要性を強調する。

* * *

ドキュメント=契約書

 なぜドキュメント化が嫌われるのか?

 SEの立場から言うと、ちゃんと検討していないまま、「とりあえず」ドキュメント化をさせられるから(結果、後から手直しが多発する)だろう。PGの立場からすると、理解してコードに落とすだけの内容を、なぜ語弊の出る日本語に書き直さなければならないか、疑問に思うだろう。

 本当の問題はSE/PGがドキュメントを書いていること。あるいは、片手間にドキュメントを書いていることをなんとかすべき。本来なら専門部隊を準備するか、リソースを明示的に割り当て、執筆期間を設ける必要がある。

 これを理解しないまま、ドキュメント排斥を追求すると、思わぬところで足をすくわれる。例えばトラブル。巨大システムもjob sequenceひとつ間違えただけで全面停止になることがある。アナタのアウトプットが起因でトラブルが発生した場合、誰が守ってくれるのか?

 じっさいそういう場面に出くわせば分かるが、誰もアナタの仕事の正当性を保証してくれない…ていうかできない。イザとなったら自分の身は自分で守らないと。そのときの命綱がドキュメントだといえば、少しは怖がってもらえるだろうか。

 「ドキュメント要りませ~ん、開発現場に顧客が同席しているから」

 「動くプログラムから仕様書を自動的に作るから問題ありません」

なんて、どこの研究室の話ですか? あるいはどこの実験「だけの」プロジェクト? とツッコミたくなる。

 顧客はごく少人数で、サービス開始後も同じ開発者が傍らですぐ控えております、なら分かるが、そんなわけない。"顧客"の背後に控えているおおぜいのオペレータの視線を感じたことがないか。目の前の"顧客"を口頭と目視で納得させればOKだなんて、ムシがよすぎやしないか。

 あるいは、ソースから生成した日本語として体を成していないクソ資料を全部読んで理解して、かつ「承認」してくれる顧客がいるならともかく、そんな人間すらいない…ってか「ソースコードが仕様書です」と本気でいう奴はソースから生成したドキュメントを読んだことがあるのか? と問いたい。自分が書いたやつだけでなく、"全部"だ。あれは開発や保守で大づかみに理解したりするために使うんだよおぉぉ。

 ドキュメントを軽視した結果、土壇場になって「オレはそんなこと言ってない、証拠を見せてみろ」と手のひらを返されたことが一度でもあるならば、おいそれと↑のようなセリフは吐けない。ドキュメントとは契約書なのだから。

* * *

ドキュメント=チーム間の橋渡し

 顧客とベンダとの契約書になるだけではない。チーム内、チーム間の橋渡しの役割もある。アナタが書いたドキュメントは、ひょっとして一度も日の目を見ることがないかもしれないが、必要なときは是が非でも必要となる。

 デスマの火消しに投入されたことはあるだろうか。ウォーターフォールを採用したプロジェクトが燃えている場合、最初に渡されるのが莫大な仕様書(あるいはその残骸)だ。古文書を読み解くが如く、そいつに喰らいつくのが最初の仕事。んで、プログラム動作との Fit/Gap を見つけるのが次の仕事。

 このドキュメント(のあるべき姿)と、目の前で燃えているコード(もしくはテストシステム)の差に対し、3つの切り口がある。


  • コードをなんとかして、仕様書どおりに動かす
  • 仕様書を書き換えて、コードの振る舞いどおりに直す
  • 動かないところの仕様書を切り離す(段階的にリリースする)

 んで、優先度が高い順に財布とカレンダーをにらめっこしながら、コードを書くのかドキュメントを直すのか、あるいは仕切りなおしさせてもらうのか、を選び取るわけだ。

 一方、ドキュメントをちゃんと作っていないプロジェクトが燃えた場合、最悪のことが起こる。

 即ち、「何が本当か分かりません」だ。ソースなのか仕様なのか、誰が本当のことを知っていて(決断できて)、誰がそれを知るべきなのかがぐちゃぐちゃになる。どのチームに影響が出るか分からないから、ミーティングは全員参加、全員周知になる。ソースの修正による影響も特定できないため、全員周知となる。ペアプロじゃなくって全員で同じコードをプログラミングしているようなもんだ。

 いまだに「ソースコードが仕様書です」を胸張って言うプログラマを見かけるたびに、マイクロソフト・ジョーク「それは仕様です」を思い出してこっそり笑わせてもらっている。

| | コメント (0) | トラックバック (0)

ウォーターフォールはこう使え(その4)

決めるべき2つの日どり

 二つ目の戦略。それは「日どり」だ。「あいまいな仕様」が"今は"決まってないことを顧客自身の口から言ってもらった後は、何月何日までに仕様凍結するかプロジェクト全体のスケジュールの中で顧客と決める。「仕様の再確認」ができていない以上、そいつができる日はいつなのかを決める。

 こいつを最初に決める。ここを過ぎると挽回が不可能とうい点「ポイント・オブ・ノーリターン」を"今"決める。ここまでギッチリ動機づけしておけば、仕様凍結の最大の脅威「先送り」を回避できる。

 あるいは、こっちの方がもっと重要なのだが、「仕様凍結を先送りしている事実」を共有できる。極端な話、仕様が凍結されていないのが問題なのではない。仕様が凍結されていないことが公になっていないまま、先へ進んでいるほうが深刻なり。

 表向きは仕様は固まっているはずなので、顧客からは口頭や電話だけで「指示」がくる。当然、仕様書は書き直さないので、仕様変更ではないと判断される。あいまい仕様に対し、顧客へ問い合わせする度に「固まっているはずの仕様」がずんずん膨らんでくるので、いつしか訊かなくなる。んで、代わりに「自分で考えて」実装するわけだ。

 問い合わせる度に「口頭での」仕様が膨らむ
 →確認する代わりにSE/PGが自分で明確化・実装する
 →"こんなの作れって言ってない"と罵倒される

 この悪循環をモトから絶つわけだ。つまり、「現在仕様は凍結されておらず、○月○日に確定する」と顧客を巻き込んで宣言する。(その1)で書いた「peak に到達する日」を顧客にもコミットしてもらう。スパイラルでもOK、「その日」までに何回くり返すかだけの話。

 その一方で、もう一つの日どりを密かに決めておく。もう一つの日を知っているのはPMとシニアマネージャだけで良いが、必ず決めておく。

 その日とは、「最悪の事態に陥った場合、納期延期を申し入れる日」のこと。プロジェクトにとって重要な日は納期ではない。納期に間に合うように努力と工夫を重ねるのだから、間に合って当然。大事なのは、そうならないことが分かったとき、いつまでがギリギリといえるのか? ということ。

 プロジェクトが燃えさかってくると、「その日」のことが脳裏にちらつき始める。納期より手前であることは分かっているのだが、それが1週間前なのか、1ヶ月前なのかが見当がつかない。だから火事場で顧客とハラの探りあいなんて阿呆なことをしだす奴が出てくる。

 こいつを回避するために、最初に決めておく→「ダメなときお客さんにゴメンナサイを言う日」。そうすることで肝も据わるだろうし、火事場になったとき、「その日」に向かって、今度は回避・低減・転嫁するためにすべきことに準備できる。

 顧客だってそうだ。なんだかヤバそうだぞと見ていると、ギリギリになって「結局できそうもありません、どうしたらよいですか?」と来られても困る。ダメになったことに言いたいことは沢山あるだろうが、ダメならどうする? を考えて来いと。「ゴメンで済んだら警察いらない」はガキの使いやあらへんで。

 だから、いざとなったら、「その日」に向かって準備ができるよう、「その日」を決めておくんだ。ダメになりそうな要素は見えているもの、見えないものと沢山あり、プロジェクトの最初から準備しておくことは難しい。しかし、「すべきこと」が洗い出され、プロジェクト・ベースラインがあれば、「その日」を決めることは比較的たやすい。

twoday

* * *

決戦は月曜日

 戦略は2つある。「仕様の再確認」と「2つの日どり」だ。どちらにも共通するのは、ゴールまでの作業スケジュールを逆算した"日"、すなわち時間を味方にしているところだ。

 ほとんどのSE/PG/PMにとって、時間は脅威以外のなにものでもない。なぜなら、プロジェクト終盤になると、カレンダーを片手に顧客やシニアマネージャーが迫ってくるから。窮すれば鈍す。「時間」や「スケジュール」とは、"追い詰められるもの"というイメージが強いんじゃなかろうか。

 ところが、開始直後では、むしろ「時間」は味方になる。「今、決めておかないとゴールできません」と最初に宣言しておくことで、時間の刃を顧客のシリに突きつける。もちろん"現時点で決まっていない"ことは顧客自身の口から言わせておく。

 この戦略が可能たらしめているのは、「すべきこと」が洗い出されており、かつ、その行程と peak (=マイルストーン)が見えているから。「何故、いま決めておかないとできないのか」と顧客は必ず切り返す。そのときこそ、「すべきことの結果」(=成果物)とマイルストーン一覧を示すとき。「成果物」と「マイルストーン」はこうやってオープンにして、顧客を巻き込む。最初にだ。

 おわかりいただけたと思うが、決戦地はプロジェクト開始直後なり。"決戦は金曜日"ではない。夢を真実にしたいんなら、最初に全力を尽くすべし。にもかかわらず、序盤を部下に任せっきりで、終わりのほうになって火事場になると大声と体力勝負で、いかにもリーダーシップしてまっせというPMがなんと多いことか。

| | コメント (0) | トラックバック (0)

ウォーターフォールはこう使え(その3)

 ちょっと思い出して欲しい。次の弾丸が飛んでくるのはいつだろうか?

  「すでに決まったはずではないか」
  「そう読み取れるではないか」
  「いまさら言われても困る」

 よい子のみんなはもちろん分かってる。納品が間近に迫ってきたときだね。品質がアレなのか、そもそもマトモにできていないことが明らかになったか、トリガーは様々だけど、たいていはプロジェクトも終盤になってそんな弾丸が飛んでくる。

 これは「仕様のあいまい性」を先送りしてきたツケだ。実はこの弾丸、プロジェクトを通じて3度発射する機会があるという。


  • 1回目:顧客との契約時、仕様の確認をするとき
  • 2回目:ベンダーと請負会社の契約直前に、請負会社から仕様の確認を求められ、顧客に問い合わせるとき
  • 3回目:火ダルマになっていることが知れ渡り、顧客が乗り込んできて「こんなのを作れなんて言ってない」と言い放つとき

.…にもかかわらず、3回目がほとんどだろ。この弾丸を発射するときがチャンスで、口を尖らせて「そもそもかくあるべき」論がくりひろげられる。そんなんなら最初から言えやボケェ!と叫びたくなるのをグッとこらえるのに苦労しただろう。

 だから、この弾丸は最初に撃ってもらおう。1回目こそが決戦地。ここでは、仕様をきちんと落とし込むためのテクニックは書かない。テクニックはUMLでもマジカでも好きな武器を手にすればよい。ここでは、決戦地で闘うための戦略を書く。戦略は2つある。

* * *

「仕様の再確認」によるあいまい性の排除

 一つ目の戦略。決戦地は「受注確定直後」。ここで決めなければいつまでたってもあいまいなまま。極端な話、動いたものが仕様ですなんてシャレにならん冗談もある。確定直後、「システム仕様の再確認」をやる。ミーティング形式だろうが、題名は " 仕 様 の 再 確 認 " であること

 そもそも受注時にまともな仕様が決まっているハズがない。顧客も営業も社内手続きや次案件に忙殺されてて、内部ネゴが通れば後は済んだ事にしたがる。だから、契約書に添付されている「仕様書もどき」を見ても、ペラペラのスカスカだ。

 だから受注確定時、「分析・検討フェーズ」と称して「仕様の御用聞き」をやってるわけだ。顧客にとってはベンリだよな。契約でスケジュールをしばって、仕様は後付けで決められる。都合の悪いところは「そう読めるじゃねーかよ」と切り返す。どうとでも読み取れるような書き方をしているからだ。

 そこが問題なり。仕様は決まっていないのに、あたかも決まった上での契約として扱われ、フリーハンドの余地をたっぷりと残している。しかも決めにくいところは先送りできる。そうしたしわ寄せは後の人に押し付けられる。

 こいつを回避するためにすることは「仕様の再確認」。仕様は既に凍結しており、今やってることはその再確認に過ぎない、という姿勢で臨む。そこにはペラペラの「仕様もどき」から全力で肉付けしたドキュメントを準備しておく。

 すると顧客は「そうじゃない」とくる。あたりまえだ。顧客自身、真剣に深堀りして考え抜いたわけじゃないからだ。けれども、ペーパープロトタイピングでも何でもいいから、形になったものをとにかく突きつける。顧客はそこで初めて考え始める。仕様を考えるベースラインがあれば、そいつに朱入れしてもらうなり、顧客自身に書き直してもらうことができる。何も土台がないまま空中戦を続けても何も残らない。

 それでも「仕様の再確認」という姿勢はくずさない。なぜか? 「すべきこと」は決まっているから。(その2)で出てきた「空欄込みのすべきこと」が効いてくる。プロジェクトのゴールが決まっていて、そこから逆算してすべきことが洗い出されていて、順序性と未決定事項がオープンになっているから。仕様は今決まっていないと、順序が崩れるから。「そうじゃない」と"今"言われても困るから。"今"(=契約直後)に決まっていないと、ゴールは望めないということを、"今"たっぷりと自覚してもらう。

 これができるのは、空欄が入っててもいいから「すべきこと」が全部マナ板の上に乗っているから。「走りながら考える」「とりあえず動いてから決める」姿勢でいる限り、いつまでたっても決まらない。

 プロトタイプ開発方式での仕様決めに参加したことがあるだろうか。プロトタイピングのだんだん肉付けするやり方は、作るのには適しているが、決めるのには最悪なり。これを理解していないと、いつまでたっても決まらない画面をいじりまわしているうちに時間切れになる。顧客が決めたいのは文字の色やボタンの配置なのではなく、そこでやりたいこと、即ち仕様なり。「大学で情報工学を専攻してました!」という連中が最も陥りやすい罠。むしろ、そういう研究室上がりこそ、「色やボタンの配置こそが"仕様"じゃありませんかッ」と詰め寄ってくるので「画面仕様書を「作らない」リスク」あたりを読んで理解してもらおう。

 何が欲しいのか、顧客が説明できないのであれば、何を作っても満足させることはできない。プロトタイピングが根本的に誤解しているのは、ここだ。顧客を巻き込むまでは正しい。しかし、顧客の言うとおりにスパイラルをくり返したところで、顧客が満足するアウトプットは出ない。だから最初にアウトプットを出して「そうじゃない」と顧客自身に言わせる。顧客にとっての"銀の弾丸"は、最初に撃ち尽くしてもらおう。


| | コメント (0) | トラックバック (0)

ウォーターフォールはこう使え(その2)

 ウォーターフォール・モデルとは一言で説明するなら、「プロジェクトの構造化」だ。逐次実行や先手管理、進捗の予実管理なんざ、特徴的だが本質ではない。それらはキチンと構造化された後に実現できる。プロジェクトの構造化をしないまま先手管理しようとするからおかしくなる。

* * *

プロジェクトの構造化はこうやる

 ウォーターフォールは逐次的な開発技法であり、ウォーターフォール全体として「分析>設計>製造>試験」とはならない。顧客受けしやすいようそんな絵を書くこともあるが、実質は異なる。

 「すべきこと」単位に分解して、「すべきこと」同士の順序性を決めた後、「すべきこと」同士では逐次的な関係を守らせるようにすることが本当

 「すべきこと」の分け方は「分析」「設計」「製造」「試験」ではない。これらは分断するものではない。「なんちゃってウォーターフォール」をダメにしているのは、工程(=フェーズ)ごとにチームを割り、それぞれの工程を1回でカンペキにこなせるという期待なり。運を点(≠天)に任せているとしかいいようのない希望的観測のおかげで、どれだけの呪詛が生まれたことか…
usoppachi

 学び取るなり盗むなりしてきちんと身に着けていない連中が見よう見まねでマネジメントしていることが、元凶。しかもその部下で実績を積んだ人が、今度はPMとして「なんちゃってウォーターフォール」を任される …悪夢の再生産やね。

 では、どのように分けるのか? プロジェクトにより異なるが、


  • 方式
  • 業務
  • データ
  • 環境
  • 品質

に割れる。そして、アサインされたチームがそれぞれの役割を果たす。役割はこんなカンジ。

  • 方式 → ネットワーク、データベース、通信制御、他のシステムとのインタフェースを決定・実装・試験
  • 業務 → ビジネスプロセスを分析・実装・試験
  • データ → 方式・業務で必要なテーブルセットを準備し、予め用意するべき内容を入れる
  • 環境  → 方式・業務・データの開発・試験に必要な環境(ネットワーク・クライアント・サーバなど)を準備
  • 品質 → 要求されたものと提供するものが合致するためのあらゆる努力(具体的には品質保証/品質管理/品質基準)を実施[参考]

 デカいプロジェクトになると、「方式」や「業務」もさらに割れる。ポイントは、役割をアサインされたチームの中で「分析>設計>製造>試験」を回すことと、チーム間での成果物渡しは逐次的なこと。フェーズの名前が気に入らない。なら「検討>執筆>レビュー>」(仕様決め・契約の場合)だろうと、「方針検討>環境構築>実施>検証」(テストの場合)だろうと、お好きな名前をどうぞ。
PDCA

 仮にウォーターフォールが「逐次的な開発手法」というならば、ココのことを指す。相手チームに渡したら、原則として手戻りは許されない。品質的にアレな場合や、相手チームからのフィードバックがあって初めて手戻りをすることができる。

 「すべきこと」を週単位まで割ることができるならWBSが定義できるが、プロジェクトの最初の段階では全部WBSまで割るのは難しい。だから「すべきこと」はデカいカタマリ単位でOK。このとき大切なのは網羅性。「後で足せばいいや」「やり直しがきくから」なんて甘いことは許されない。なぜなら、「チーム」が別会社にある場合、「契約」が発生してくるから。「あいまいだから分からない」は逃げ。そんなセリフ吐くPMは、いつまでたってもWBS定義をやるはずがない。

 そして、「すべきこと」とWBSが混ざっててもよいから、ネットワークダイアグラムの形にする。つまり、順番を決め、作業量を見込み、矢印で結んでゆき、クリティカルパスを見つける。たいていの場合は、「仕様のあいまい性」がボトルネックとなる作業がクリティカルパス上に乗ってくる。

* * *

構造化すれば、プロジェクトが「見える」

 プロジェクト全体を俯瞰し、プロジェクトを構成する部分を見極め、作業順番を決定し、チームに役割を振ること。これがプロジェクトの構造化。「あいまいなこと」は極力排除するが、残ったところは「あいまいなところ」として「見える化」する(つまり、顧客との共有情報に"空欄"を作っておく)。

 「このプロジェクトの全て」を可視化して、「全体>部分」の構造をオープンにする。まだ決まっていないところや、あいまいな部分は「未決定項」や「未確定事項」として、空欄で定義しておく(←これ重要。これをやっておかないと、変更や追加の要求を受ける際、「変更・追加するモトとなるもの」があやふやになる)。プロジェクトのベースラインを決めることで、そこからのブレを管理することができる。

 しかし、「あやふやなもの」を放置しておけば破綻する。いったんは空欄としてベースにしたとしても、いずれ明確化する必要はある。この連載では、「あやふやなもの」の真っ先のターゲットとして挙げられる「仕様のあいまい性」に着目する。

  「すでに決まったはずではないか」
  「そう読み取れるではないか」
  「いまさら言われても困る」

 「あいまい仕様」に対し、顧客の使う三大文句はこれだ。顧客にとっては銀の弾丸だが、先送りしているにすぎず、いずれ破綻する。破綻のケツはPM/SE/PGに持ってこられる場合が多い。では、ウォーターフォールを使って、誰がどう動けば「仕様のあいまい性」を排除もしくは低減することができるのか?

| | コメント (2) | トラックバック (0)

ウォーターフォールはこう使え(その1)

 ウォーターフォール・モデル悪玉論が幅を利かせている。一方でスパイラル・モデルやアジャイル・モデルがもてはやされている、銀の弾丸のごとく。
 曰く、


  • この無駄な成果物を作らされているのはウォーターフォールだから
  • あいまいな仕様と理不尽な要求に振り回されているのはウォーターフォールだから
  • スケジュール後半になって追い立てられるのはウォーターフォールだから
  • いつまでたっても品質が向上しないのはウォーターフォールだから
  • 赤字プロジェクトが垂れ流されているのはウォーターフォールだから
  • このプロジェクトがデスマってるのはウォーターフォールだから

 偉大な(?)グルの尻馬に乗って叩く。まるでウォーターフォールという軛がボクの創造性と可能性をことごとくダメにしていると言わんばかりに。何かに責任転嫁して考えを止めるのは楽だけど、その「何か」が真の原因で無い限り、解決にはならない。

 仕事ができないのは道具が悪いと騒ぐ前に、その道具ちゃんと使ってる? 知らないままコトバだけを振り回すことはとても危険なことは、OO談義で語り尽くされてるでしょ? 10年前のトドメ文句「オブジェクト指向ですから」は、それなりに効力をもっていた。わたしはよく分かっていなかったから…が、今はそうではない。試行錯誤を繰り返す中で、その両刃の剣に何度も傷ついたから。

 今ではウォーターフォールとスパイラルを併用している。M.Fowler氏のようなスゴいことは言えないけれど、それでも蔓延する誤解というか怨念というか思い込みについて、提案めいたものは出せる。

* * *

ウォーターフォールモデルとは

 はてなの定義によると、ウォーターフォールモデルでは逐次開発モデルであり、フィードバックがないらしい

 滝が上から下へ流れ落ちる如く、手戻りは認められない。「上流」で決定されることは碑(いしぶみ)と同じ、絶対命令かつ誤りが一切無いことが前提。その一方で、拡大解釈可能かつあいまいに書かれてあることも事実。「下流」に至り顧客の目に見える段階になって要求が具体的になり、しかもそれは碑に書いてある(=解釈可能)と言い張り、無償で直せ、これは仕様どおりでないと言い放つ…

 この例は、今の状況なのかもしれない。安請合した営業やダメPM、あいまいな仕様や無謀な計画がプロジェクトを破綻させているにすぎない。"ウォーターフォールだから"なのではない。理論武装のヘリクツと、開発方式とは別物。

 これをふまえた上で定義する。ウォーターフォールモデルとは、まずマイルストーンまでの成果物を厳密に決め、次にそこに向かって収束させることを段階的に進めるやりかた。

 成果物とはドキュメントやコードに限らない。他システムの接続確認ができる試験環境だったり、○○業務を行うためのデータセット一式だったり。

* * *

"河下り"よりもむしろ"山登り"

 "ウォーターフォール"という名前に違和感がある。上から下へ、"河下り"のイメージじゃない。現実はむしろ、順番に段階を踏んで上を目指す"山登り"の方が近い。

 ただし、頂上がゴールなのではなく、一つの peak であって、peak から peak をリレー式に縦走する感じ。一人で黙々と登るのではない。皆で登る。それも全員がいっせいに始めるのではなく、チームごとにバラバラ。ある人は途中の peak で下山し、別の人は途中から peak を目指す。また、登山口から登る人もいれば、市販ソフトを使って五合目からの人もいる。
_

 最初から最後まで縦走する人はいない。リレー式に渡されるバトンというより、むしろ神輿のようなものを担ぎながら次の peak を目指す。途中で合流する人から部品を組み込んで、神輿はだんだん大きくなる。担ぎ手もどんどん増えてくる。

 ポイントは、peak に到着する日を予めコミットしておくところ。つまり、マイルストーン毎に必要な成果物は厳密に提示させるところ。「次でがんばるからいいや」「○○のせいで遅れます」なんてセリフは言わせないところ。

 「○月○日に peak-1 に到達し、次のチームへの引継を行う」のであれば、何が何でも神輿はその日に着いてなければならない。できなければ peak-1 で待っている人のお金と、そこへ向かっているチームのお金がどんどん使われることになる。

 神輿は一つに限らない。むしろ2つ3つあるのが普通。どんな神輿かはプロジェクトの性格による。1回こっきり、失敗が許されないならば、試験環境やテストツールがデカい神輿になるだろう。あるいは、レガシーシステムの更改ならば古い神輿が引っ張り出される。

 その中で、最も遅れてはならない神輿のルート、すなわち一番時間がかかる神輿のルートがクリティカルパス。こいつを見極め、こいつだけはゼッタイに遅れないようにする。計画との Fit/Gap に目を光らせる。この神輿が遅れるということは、プロジェクト全体のケツを割ることになるから。

 仮に「間に合わない」「成果物がそろわない(貧弱ゥ)」な場合は、挽回策とセットで peak-1 に臨む。peak-1 には皆が待っているのだ。PMがマイルストーンと成果物に喧しいのは、自分の責任で他人(他社・他チーム)のお金を会社に使わせることがイヤだから。
_

* * *

ウォーターフォール・モデルの真髄

 ウォーターフォール・モデルの真髄はこうだ。プロジェクトを構造化し、段階を踏んで要素成果物を構築する。次に、必要な要素成果物を必要なタイミングで持ち寄り、組み上げる。これを複数のルート・複数のチームで行う。だからこそ「マイルストーンの厳守」「成果物の厳守」が求められる。"ウォーターフォール・モデル"を言い換え、「プロジェクト構造化モデル」と呼ぶほうがしっくりする。

 幸か不幸か、「あじゃいる」だの「らっぷ」といったカッコイイ呼び名が付けられず、"ウォーターフォール"という語感から様々な誤解・曲解が生まれては一人歩きしたのが真相だとふんでいる。

| | コメント (2) | トラックバック (0)

« 2006年2月5日 - 2006年2月11日 | トップページ | 2006年2月19日 - 2006年2月25日 »