定義よりも対話・合意を大切にする

システムは定義通りにつくることが困難

一般的にシステム開発においては、仕様書という納品物が存在します。これは「何をつくるか」を定義した書類で、この仕様書を元にシステムをプログラミングしていきます。ところが、仕様書に記載されていることと寸分違わずプログラミングをすることなんて実は不可能なのです。

どれだけ仕様書を詳細に記そうと努力しても、どのように作るかは実装者により解釈が異なってしまいます。例えば「ログイン機能が欲しい」というオーダーがあったとして、どのように作るかの解釈は何通りも存在します。ユーザーIDには自由な文字列を入力させるのか?それともEメールアドレスだけを許容するのか?文字桁数は何桁までにするのか?パスワードに記号を必須にするのか?ほんの少し考えただけでも、考慮しなければならないことが次々と溢れ出てきます。

この程度であれば、仕様書に定義することは可能かもしれません。しかし、実際にはもっと膨大な量のバリエーションが存在します。それら全てを仕様書に明記し、解釈とのブレをゼロにすることはほとんど不可能なことだと言えます。

システムは変化させ続けるもの

定義を重要視する主張は「システムは定義した通りに作って完成させれば価値を生む」という前提を元に成り立っています。しかしこれは誤りで、本来システムというものは、仮説をもとに構築したシステムを実際に見て、触って、必要なら仮説を修正しながら、少しずつ価値を生む形に近づけていくものです。たった一度定義したものを軌道修正なしで成功させることなんてあまりに難し過ぎます。

作るべきものは、様々な要因によって刻一刻と変化していきます。例えば市場のトレンドが変わったり、作っている最中に競合製品が登場してしまうこともあります。現代の目まぐるしく変わり続ける社会に追従していくには、定義を正として、決められた通り作り続けるのではなく、都度対話と合意を繰り返して、あるべきシステムの形へと変化させ続け、価値を生む形を模索していく必要があるのです。

ミーティング中の対話

対話・合意とは何か

対話・合意とは、

をコミュニケーションして決めることです。

特に重要なのはなぜ作るか?(Why)の部分です。「◯◯機能が欲しい」と表現された機能要望があるとして、その機能には必ず「なぜそれが必要か」という目的が存在します。定義を重視する手法では、設計する工程と開発する工程が分断されていることが多く「なぜそれが必要か」置き去りに開発してしまいがちです。

例えば、ユーザーの手間を減らしたいのか、ユーザーの離脱を減らしたいのか、ユーザーを迷わせないようにしたいのか、多様な目的が存在していて、まずは目的有りきで、それ達成するために「何を」「どうやって」作るかを決めるべきです。目的を実現する方法は、実は要望された機能とは異なる形で作ったほうがより効率的に実現出来ることがあります。

mofmof inc.では「こういう機能が欲しいからつくる」ではなく「どんな目的があってその機能を作るのか?」にフォーカスして「このような形で作りましょう」というように一つ一つ対話・合意して作っていきます。ときには今は作らない方が良いという提案をすることもあります。そのようにしてムダな作り込みを減らして価値のあるもの優先して効率的に作り込んでいくことが出来ます。