真面目な人を本気にさせる方法

先日、他社の開発の方々が、アジャイルに関する相談ということで、弊社にいるアジャイルに詳しい髪の長いおじさんに訪ねてきた。その中で、実感駆動開発の話になって、久しぶりに「本気（マジ）と真面目（マジメ）」の話を聞いた。

この話を聞いてから、人がプロダクトの価値について考えられるようになるにはどうしたらいいのか考えてみた。

TL;TR

ありきたりな回答だけれど、さっさとリリースして、さっさと使ってもらう。それをできるためのことを、もちろんリスクを下げつつ、できるようにするためのことを頑張ろう。

本気と真面目

人はドキュメントを前にして真面目な態度を取るが、動くソフトウェアを前にして本気になる。

端的に言うと、人は仕様書などドキュメントを前にするとそれを徹底的に重箱の隅を突くようなレビュー（真面目）をしてしまうが、本当に欲しかったことに対して考え始める（本気）は実際のプロダクトを前にしてからという話だ。こういう話は、ソフトウェア開発に携わった事ある人なら誰しもが経験があると思う。仕様書通りに作ったはずなのに、開発の終わり頃にデモを見せた時やリリースの時に「欲しかったのは○○で…」と言われたことはあるのではないだろうか。

どうやったら予め本気になれたのだろう。ドキュメントをもっと徹底すれば良いのだろうか？開発経験のある人だと、薄っぺらいドキュメントでも、それがユーザーにとって価値がありそうかどうかや、クリティカルな部分が事前にわかったりする。必要なのはソフトウェア開発の経験なのだろうか？動くソフトウェアでなければ本気になれないのだろうか？ペーパープロトタイピングで事前にわかることもある。会議室で実際のプロダクトをデモしても本気にならないことだってある。

では何が人を本気にさせるのだろうか。個人的な考えではあるば、徹底されたドキュメントでも無ければ、開発経験があることでも、プロダクトであるかプロトタイプであるかでさえも関係無いのだろうと思う。大切なのは、現実的（リアリスティック）であるかどうかではないだろうか。

現実的＝ユーザーストーリーに埋め込められるかどうか

数年前、弊社の新卒研修にコーチとして来ていただいていたアトラクタ社CEO原田さんにユーザーストーリーについて紙に書いて教えてもらったことがあった。その時書いてもらったものをPDFにして、たまに見返したりして反芻している。当時話題になっていたある事件からインスパイアされて、そのPDFを勝手にハラダ文書と読んでいる。ハラダ文書はここから見れる。

上の図は、ユーザーストーリーを描いた図だ。棒人間として書かれたユーザーがある状態（上）から違う状態（下）に変わっている。そこに至る過程がユーザーストーリー。この時点では一切システムなど関係無い。しかし、その過程の中でペイン（不便や辛さを感じること）やゲイン（楽しかったり便利だったり、とにかく良いこと）がある。システムはペインを減らし、ゲインを増やさなければ価値は無いだろう。

システムはユーザーストーリーにあるペインを失くし、ゲインを増やさなければ無価値！

この右側に書かれたUC（確かその時はUse Caseと言ってたように記憶している）がシステムが提供する機能を表している。例えば、「何か思いついたことを多くの人に知ってもらうために周知する」というようなユーザーストーリーに対して、ブログのようなシステムであれば、上から「ログインして」、「思いついた内容を書いて」、「SNSで拡散する」といったことでシステムが価値を提供できるだろう。

動くソフトウェアであろうとなかろうと、このユーザーストーリーとその中のどこに対してどういった価値（ペインを減らすのか、ゲインを増やすのか）を提供するものなのかを想像できる時に、人は本気になるのではないかと思った。逆に本気にさせないことは容易だろう。

自分が以前に情シスに在籍していたころ、社内コミュニケーション用のメーリングリスト管理ツールをリプレイスした時、購読の申請を1件ずつ1クリックで管理者が承認できるようにしたことがある。元のシステムが1つの承認処理が煩雑だったので、これだけでも価値があるもの（ペインを減らす）ものだと思っていた。スプリント終わりのレビューでもステークホルダーからは好評だったのは覚えている。しかし、小規模に先行リリースしたところ、ある人から「これでは使えないので、部下に使わないように連絡しました」という連絡を貰った。その人の場合、部署の人数が多いため、一度に複数できないと意味がないということだった。このケースは、リプレイスの期待値の問題でもあったが、開発している僕らは本気になれていなかったのだ。元のシステムの仕様書を見て、真面目になっていただけだった。

作ったらリリースすれば良い。と言うのは簡単ではあるし、実際に実在するユーザーストーリーに変化が起きれば、ユーザーは本気にならざるを得ない。しかし、相当な自信が無ければ、混乱を起こすだけになるだろう。そういうリスクを減らす方法として、フィーチャーフラグなど色々なプラクティスは有効だろう。リリースするまでもなく、ペーパープロトタイプで気づけるものも勿論あるだろう。慣れてくれば、一切実装することなく口頭で話をするだけでも、ユーザーへのインパクトを測れるかもしれない。もしかしたら、リリースのリスクを少なくすむくらいにシンプルなソフトウェアを作るという手もあるかもしれない。それぞれ難易度は違うけれど、どういった価値を得られそうなのか想像を働かせやすくすることが、人を本気にさせる方法なのではないだろうか。