詳細な設計書なんて捨ててしまおう

ども、@kimihom です。

一部のスタートアップ(?)では、未だに細かな設計書を書いて満足してしまうチームがあるようだ。先日、久々にスプレッドシートに大量に機能設計書(しかも Phase 2まで書かれた)を見て、おぞましさを感じたので記事にしてみる。

私が言いたいのは、「そんな設計書を作るのは時間の無駄で、もっと他にやるべきことがある」である。

何のために開発するのか？

詳細な設計書を作る意図としては、最終的に “誰かに全部作らせる” だとか “お金をもらうため"という考え方だからだろうか。そんな考え方をしてる時点でサービスが成功する確率は限りなく0に近い。

サービス開発ってのは常に試行錯誤が必要だ。どっかに納品して終わりみたいなそんな世界ではない。使う人が機械じゃないんだから、人の感情や時代の流れによって使い勝手ってのは大きく変わってくる。だからこそサービスに関わる全ての人が常に改善していくという姿勢と協力体制が不可欠である。言い換えれば、作り続けられる体制ってのがサービス開発には大変重要だ。

よくある酷い開発チームの例としては、チームのメンバーがコロコロ替わるというのがある。初期の思い描いていた構想を知る人が誰もいないようなチームで、とうの昔に離れたエンジニアの書いたコードを仕方なく読ませられるエンジニアたち。。それがどんな良いアイディアのサービスでも、当人たちは気持ちを切り替えて “ただお金のため” に働くだろう。当初の熱い思いなんてどこかへ消えてしまうのである。このようなチームメンバーの"異動"を考慮した結果、きっと後から入った人でも作れるように詳細な設計書などが必要だと感じてしまうのかもしれない。でも本当にやらなきゃいけないのは、優秀なエンジニアがずっとそのシステムに携わり続けられるようにするための仕組みづくりではないのだろうか。

じゃあどんな組織っていうのは、書くまでもないけどまずはエンジニアが当事者意識を持てないといけない。エンジニアでも、「このサービスは一緒に作って、世の中の人に貢献できると思うから頑張りたい」って思えば、自ら進んで開発してくれるし、そのチームに長く居続けてくれる。ところが、以下のようなパターンで一気にモチベーションが消え去り、すぐに他に行こうという衝動に駆られる。

他の優秀なメンバーが去ってしまった。代わりにスキルのないエンジニアが入ってきた
プロダクトマネージャなど、他の主要メンバーがコロコロ変わる
当初のサービス思想と異なる開発をさせられた
設計書を渡されて、ただ単に作らされているという感覚しか出てこない
自分が大切だと思うこと(コードの整備など)を言っても聞く耳を持ってくれない、もしくは言いづらい環境

上記を言い換えると、当事者意識、これに尽きる。

サービスを成功させたい

設計書通りに作ってサービスは成功するのだろうか。丁寧に細かく作り上げた設計書で、事前にどれくらいの調査をしたのだろう。ビジネスが世の中に必要とされているのかを調査したり、実際にプロトタイプを作ってユーザーに見せたりしたのだろうか。使い勝手の部分で何か工夫できることはないか、技術的な部分で特徴を出せないか。スプレッドシートにまとめられた設計書には成功確率を高めるための努力が一切見えてこなかった。ただ黙々と資料を作り上げて、あとは丸投げする。そんな意図しか感じられない。

サービスを成功させるためには、最初に思い描いたプランを柔軟に変えていく必要がある。今回の詳細な設計書を作ってしまうことの最大のデメリットはここにある。最初から大正解を生むことなんて不可能だ。大抵はその人の思い込みだけだったり、極一部の人にしかウケないか、多くが “使いたいとは思わないけどいいかな” レベルのアイディアで終わってしまう。しかし、注意深くサービス内容を意図的に変えていくことで、最終的には提供者と受給者のベストマッチってのが見つけられる。そこに行き着くには多くの時間と試行錯誤が必要だ。

ここでよくある間違いを書いておこう。最初のサービスを作った後に、"あれもこれも"と言ってあらゆるターゲットに刺さるような多角化をしてしまうことだ。一見すると、多くのユーザーに刺さるような目的を満たせると思ってしまうかもしれない。しかし、ユーザーはサービス名を聞いた途端に、そのサービスの全体像をパッとイメージする。Yahoo!ならポータルサイト、LINEならチャット、楽天なら買い物、と言ったように。当然、それらサービスには他の大量のサービスが用意されているけど、最終的にイメージするのはその主要な機能のみである。だからこそ、あなたのサービスも、サービス名を聞いた途端に “それ” と言えるような主要な何かを持たなければならない。"あれもこれも"戦略がうまくいかないのは、最終的にユーザーがサービスに対してどう思って欲しいかを与えることができないのだ。

前回の記事で “プロダクトの全体的な思想を理解しよう"と書いてたのに、コロコロとサービスのプランを変えちゃダメじゃないかと思う方がいるかもしれない。しかし、思想ってのは Why であり、機能ってのは What なのだ。つまり Why を変えずに What を柔軟に変えていくってのが大事ということを理解していただけると幸いだ。

設計書を渡された身にもなってみよう

詳細な設計書を渡されたエンジニアはどう思うだろうか。あとは機械のように言われたことを黙々と作り上げるだけ・・。そんな仕事のどこに魅力を感じるのだろう。心を無にして作ったところで、メンテ不能な、引き継ぎが困難なシステムが出来上がるだけだ。作るエンジニアも不幸だし、ひどいものが出来上がってしまった発注側も不幸になる。誰にとっても何の成果も生まない。

お金のためじゃない。自分の作ったものが本当に世の中に貢献できる！と確信できるような、素敵なモチベーションをエンジニアに提供すれば、最高のプロダクトを作り上げてくれることだろう。