今日学んだこと

分かっていることは書かない。分かっていないから書いて学ぶ。だから「今日学んだこと」なのです。

早めに失敗する文化

(写真:秋のたそがれ その2)
f:id:FairWinder:20150227004413j:plain
コンピューター業界でいうところの、ウォーターフォールとアジャイルの二つの開発手法。

ウォーターフォールは、NASAがロケットのプログラムを開発するため、何千人月の巨大プロジェクトを動かす用途で生み出した手法です。
それは、まさに滝のイメージで、一つ一つの工程をしっかり完成してから次の工程に進みます。
ですから、手戻りがないことが前提です。逆に言えば、手戻りを何より嫌います。
ちょうど、一度滝から下に落ちた水は二度と元に戻らないようなものです。

そのため、川上の工程担当者の重責はたいへんなものです。たとえば、お客様から機能の要望を聞き取るシステムエンジニアは、もしそこで聞き誤りがあれば、間違った機能のまま川下へと流れてしまいます。そして、その間莫大な人件費が発生します。
それに気がついて、やり直しを依頼しようものなら、川下のメンバーからたいへんな突き上げがありますし、費用が嵩むので上からも怒られます。
しかたないので、お客様になんとか合わせていただくようお願いにいくのですが、まず受け入れられることはありません。
そもそも住んでもいない家のイメージを思い描くことができないように、業務効率を上げるため、使ってもいないソフトの仕様をお客様に確定してもらうのは無理があるでしょう。

そのため、ウォーターフォールは、お客様にも腹を括ってもらう必要があります。
大手の開発案件で、お客様とベンダーの責任の有無がよく訴訟にまで発展しています。
曰く「お客様は理解して製作にGOを出されたんですよね」「いや、これくらいの仕様の漏れは業者として気がついて当然だ」と。

このコンピューター業界は、過去散々この問題に悩まされて来ました。そこで、最近のWEBアプリを中心に採用されているのがアジャイル開発方式です。
コンピューター業界では、アジャイルと言えば、誰でも「ああ」とわかる馴染みのある言葉です。
それは、一言で言えば試作を繰り返しすことです。
当然、試作ですから、一号評価版は、基本的な動作はするもののエラーがいっぱいの緩いバージョンです。
ウォーターフォールの場合は、これを紙ベースで、「こう作りますけど良いですか」と確認をするのですが、アジャイルはここでいきなりお客様に実際に動くものを提供して評価を依頼します。
確かに、紙ベースで見せられるより、実際に使ってみた方がお客様は「自分は何をしたいのか」という本質には近づきやすいですよね。

かくして、アジャイルは、一週間という短い工期で試作版を改良して、お客様に評価してもらいながら、完成版に近づけます。
一言で言えば、ウォーターフォールは失敗できない方式、アジャイルは早めに失敗する方式と言うことができます。

もちろん、ウォーターフォールとアジャイルのいずれを適用するかは、プロジェクトの性格によるので、一概に優劣を論じられませんが、アジャイルと言う考え方は、ビジネスのいろんな場面で使用できます。

ともすれば、私たちは失敗が怖くて、もう大丈夫となるまで動けなくて機会損失をしています。
アジャイルが早めの失敗を許容する文化だとすれば、完璧なロードマップを引いてから実行するより、稚拙でも仮定と修正を繰り返して完成に近づける方が、手数はかかるように見えても、時間的にははるかに早くなります。
スピード重視の今の時代は、アクションを早めに起こすことが何よりも求められます。
要はそれを失敗と見るか、学習と見るか。
そこで、早めに失敗すれば学習、終盤に失敗すれば、本当の失敗です。

とかく後輩社員は、先輩社員の成功体験の範囲で動きたがるもの。
しかし、時代は変わっていますし、先輩の成功体験がいつも適用できる訳ではありません。
先輩自身も散々失敗して成功をしているのですから、後輩に対して「早めに失敗する文化」を示すのは先輩社員の務めでありましょう。