失敗の波に乗れ

プロジェクトをやってると今でも急に不安になることがある。

とりあえず今はなんとか上手くいっている。でも次のリリースはどうだろうか。間に合うだろうか。ギリギリになって大きなバグが見つかるかもしれないぞ。先日もバグ報告が来た。テストが足りてないのだろうか。・・・

そう、失敗が怖いのだ。失敗が怖い、失敗しちゃいけない、そんな強迫観念に囚われそうになる。そんな恐怖を感じるのは僕だけじゃないと思う。そんな恐怖をどうやって上手く「受け流して」、失敗を恐れず成功に立ち向かっていくか。

プロジェクトの成功は簡単

こう考えよう。プロジェクトを成功させるのは、実はものすごく簡単なことなのだ。次の2つのプロジェクトを考えてみればそれが分かる。

  • そのプロジェクトは成功の連続だったが、最後に終わってみると結局失敗だった
  • そのプロジェクトは失敗の連続だったが、最後には見事成功した

もちろん、成功プロジェクトは後者だ。つまりこういうことだ。

どんなに失敗したっていい。最後にたった一回だけ成功すればいいのだ。

な?簡単なことだろ?

完璧主義は危険

それでも完璧主義者は、次のようなプロジェクトを目指そうとするかもしれない。

  • そのプロジェクトは最初から成功の連続で、最後までずっと成功だった

おい、夢見てんじゃねぇ。お前のプロジェクトはそんなに簡単じゃない。お前の相手は、もっと魅力的で、挑戦のし甲斐があって、失敗を恐れず全力でぶつからなきゃ倒せない強敵だろ?そんな一度も失敗しないで簡単に片付けられるようなつまんねーヤツじゃないんだろ?

それに、「完璧主義」心理に陥ると失敗したときがヤバい。必要以上に慌てるし、必要以上に動揺してしまう。しかも、「完璧主義」心理は失敗を隠そうとする方向に働く。臭いものにはフタをして見なかったことにしようとしてしまう。それじゃダメだ。

「成功ばっかりじゃつまんねーな。そろそろ失敗しねーかなー。」

それぐらいの余裕が必要だ。

計画的に失敗する

そうはいっても、予想外の失敗はダメだ。マジで手痛いダメージを受ける。場合によっては一撃で死んでしまう。

「おお ゆうしゃよ しんでしまうとはなさけない・・・検収ムリポ

そんなヤバイ失敗パターンを例示しよう。そのプロジェクトでは要件定義書や仕様書をきっちりと記述した。仕様書を元にテスト仕様も作成し、すべての機能をしっかりとテストした。意気揚々と客先に持っていくと、「欲しいものと全然違う」。

こうならないためには、失敗を「想定の範囲内」に追い込まないといけない。そう、物事には順序があるのだ。順を追って失敗しなくちゃダメなのだ。

そこで失敗目標を立てる。成功目標じゃない、失敗目標だ。それは例えば「バグが多いと客先から苦情をもらう」という目標。プロジェクト最終段階でなければ、この目標は「あり」だと思う。なぜなら、
お客さんの目が細かいバグに向くということは、そもそも作ったものと欲しいものがズレているという大失敗はなさそう

だから。ただし、当然だけれど、正常系の処理までどこもかしこもバグだらけではお客さんが全く出来具合を確認できないので意味を成さない。お客さんが仕様の妥当性を検証できる程度の品質は達成できている必要がある。逆に言えば、
この段階では仕様の妥当性を検証できる程度の品質までテストすれば十分
といえる。

失敗計画は心理的に楽

客先から「バグが多いんだけど?(怒」って電話が来ると、たいていは結構ビビる。プレッシャを感じ、ストレスになってしまう。
でも、それが自分が立てた「失敗目標」どおりの苦情だったらどうだろう?電話で「申し訳ございません。」と対応しつつ、心の中では

「フッ、やはり来たな。狙い通り。(ニヤリ」

と余裕を保てるのではないだろうか。

これは見方によってはお客さんにメチャクチャ失礼な話だけれど、でもストレスをためて鬱になっても問題は解決しないのだ。これぐらいの心理的余裕を保って不敵に失敗を克服していくタフさが必要なのだ。そのためならば、このくらいの失礼は許容されるんじゃないかと思う。

敢えてバランスを崩す

プロジェクトと一口にいっても、色んな切り口がある。パッと思いつくだけでも

などなど。これらすべての項目でバランス良く点を取ろうというのは間違いだ。そんなことをしたら、失敗のリスクが全項目にわたって均等に分散してしまい、どこが失敗するか全く予想が立たなくなる。つまり、「失敗計画」が立てられなくなる。

狙い通りに失敗するには、敢えてバランスを崩さないとダメだ。敢えてボトルネックを作らないとダメだ。敢えて弱いところ、敢えて失敗する「隙」を仕込んでおかないと管理できないのだ。例えば「要件定義」では満点を狙う代わりに「品質」ではものすごく手を抜く、というエキセントリックさが必要なのだ。

かの森博嗣氏もこう書いている。

すべての箇所を合理的に作り、つまり全体として最適な強さのバランスにデザインすることは、必ずしも正しくない。むしろ、通常はわざとバランスを崩し、弱い部分を設定しておくものだ。
 いろいろなレベルのものがある。少々方向性が違うが、たとえば、ヒューズは大電流が流れた場合に、その弱い部分で断線するようになっている。

http://blog.mf-davinci.com/mori_log/archives/2008/01/post_1664.php

これについては以前もこのブログで言及している。

例えば、開発は大抵計画通りには行かない。たぶん、何が何でも計画通りにやれるようにしよう、という発想はナンセンスなのだ。そうではなく、「計画というのは必ず崩れる」という前提に立ったとき、僕たちは計画をどのようにデザインすべきなのか。

計画の「壊れ方」をデザインするという発想はどうだろうか。

つまり、あえて計画に弱い箇所を仕込んでおく。ここから計画が壊れるはず、という箇所を用意しておく。そして、そこを集中的に監視することで計画からのズレを管理できる、かもしれない。

破壊をデザインする、という発想 - カタチづくり

ふむふむ、我ながらいいこと言ってるじゃないか。

プログラミングファースト開発

ひがやすを氏がプログラミングファースト開発というものを提案している。

プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。

プログラミングファースト開発 - yvsu pron. yas

これも「狙い通りに失敗する」手法といえる。

通常の「ドキュメントを書いてからソースコードを書く」という手順は、「要件定義と実際の動作が食い違う」という失敗を軽減するための手段だ。だけれど、そもそも要件定義が間違っているという失敗を軽減する手段にはなっていない。これは失敗の順序が間違っているわけだ。

そうではなく、いきなりコードを書いてできるだけ早くユーザーに触ってもらう。そうすることで、まず最初に「作ったコードを欲しいものが違う」という失敗を済ませておく。この手法はドキュメントもテストも甘い状態で開発を進めるわけだから、当然後半は品質が問題になるだろう。でもその失敗は「狙い通り」なのだ。

品質が問題になり始めたら、それが仕様が固まったサイン

なのだ。

失敗の波に乗れ

成功の波じゃない、失敗の波に乗るんだ。

そう思って、もう一度プロジェクトマネジメントの本を開いてみるといい。そこには成功の仕方は書いてない。失敗の仕方が書いてあるんだ。

XPの「変化を抱擁せよ」という標語は、言い換えれば「失敗を抱擁せよ」だ。だから、こまかくイテレーションを回して積極的に早く失敗しにいく。

リファクタリングの極意はコードをキレイにするところにあるんじゃない。まず「動くコード」を優先することで意図的に「コードが汚い」という失敗に追い込むところに極意がある。

テストファーストとかTDDなんてもっと典型的だ。なんてったって、最初にワザと失敗するテストコードを書くんだから。そうやって上手く失敗を導いていくわけだ。

もう分かってくれたと思う。

あなたが今考えるべきは、どうやって成功するかじゃない。どうやって失敗するかだ。