前回、完成度が50%の状態でサービスを公開するという話を書きましたが、「半分の完成度でサービスを出すなんて無茶苦茶だ」といった感想をもたれる方もいるのではないかと思います。

そうした意見の大半は、不具合などによる被害を想定してのことだと思います。確かに「ログインパスワードを誰でも盗めるような仕組みになっていたけれどろくに検証もせずに公開してしまった」みたいな事は許されない事です。

しかし、「パスワードを盗まれて他人が自分に成りすましポイントを換金されてしまう」といった被害と、例えば「一部のブラウザで表示が崩れて見えてしまう」被害とを比べたときに被害の規模が違うことも確かです。

ウェブページの表示が崩れて見えてしまうことを防がなくてはいけないのは確かなのですが、様々な被害を客観的に評価し、例えば表示が崩れるといった被害に対しては「これまでに表示を確認したブラウザは○○と△△ですが、もし他のブラウザで表示がおかしい場合はすぐに直しますので教えてください」とお願いする方法もありえるのではないかと思います。

さらに、「○○という意図で□□な仕組みを作ってみましたが、多人数で使うとどう発展するかが予測できません。利用動向を見ながら発展させますので、ぜひ色々と使ってみてください」といった不確定な可能性をプラスの方向に切り拓いていくような場合には、この50%手法がとても有効に働くでしょう。

こう考えると、どんなものでも50%の完成度で出してしまえばよい、というものではないことが分かります。問題を前回とは違った被害規模という観点で分けてみると、

1. 確実に安全を保たなければならない問題
2. 安全性とスピードのトレードオフがきく問題
3. 不確定な可能性を切り拓く問題

といった風に分けられ、それぞれが段階的に繋がっているのだと思います。

例えばこれを建築に例えるならば、1.は「人が乗っても床が落ちないようにする」といったことでしょうし、2.は「壁の材質をガラスにするか木にするか」みたいな問題で、3.は「家具の配置をどうすれば効率的に仕事ができるか」といった問題だと言えるでしょう。

こういった評価を行いながら、最も効果的な方法を選択できれば理想なのだと思います。しかしこうしたことを実践する時に一番の抵抗になるのが、「不具合があってはいけない」という意見でしょう。こういう意見は基本的に正論ですし、どうしても力が強くなります。

オープンなプロセスに対する検討を行う際は、「おいおい、そんなことして大丈夫か」と言う前に、自分がどんな危険性について心配しているのかを考え、ありきたりな正論が「不確定な可能性」を削いでいないかを一度考えてみることが大事だと思います。