デザインと開発を同じ人に任せると、何が変わるのか

ソフトウェアの案件には、どの見積書にも載らないコストがあります。設計されたものと、実際に出来上がったものの差です。

全員が存在を知っています。ほとんど誰も測りません。測ると、その大きさを認めることになるからです。

損失が発生する場所

劇的な失敗として起きることは、まずありません。積み重なります。

丁寧に決めた余白のスケールが、フレームワークの初期値に丸められます。意味を持たせたアニメーションが、ただのフェードになります。意味のあるほうは実装に三日かかると分かり、その三日は誰も見積もっていなかったからです。設計した空状態が「データがありません」の一行に置き換わります。インライン検証を持たせたフォームが、画面上部にまとめてエラーを出す形で出ます。コンポーネントライブラリに既にあったのがそれだったからです。

どれ一つとして、単体では揉めるほどの話ではありません。合計すると、「考え抜かれている」と感じるプロダクトと「とりあえず組み上げた」と感じるプロダクトの差になります。

問題は引き継ぎ資料ではなく、翻訳です

引き継ぎ資料の精度の問題だと言われがちです。資料を厚くしても直りません。私は極めて詳細な資料を書いた上で、同じ劣化が起きるのを見てきました。

本当の原因は、デザイナーが約束をして、その約束をエンジニアが守る構造になっていることです。しかもお互いに情報が足りていません。デザイナーは、そのリストが仮想スクロールで実装されていてアニメーションが高くつくことを知りません。エンジニアは、そのアニメーションこそがリストを成立させていた理由だと知りません。

そして両者は、決定を変えるのがまだ無料だった時点から三週間遅れて、コメント欄で、下手な交渉をします。

一人になると消えるもの

自分でデザインして自分で実装すると、その交渉は頭の中で、思いついた瞬間に、四秒で終わります。

高くつくものを設計してから費用に気づくのではなく、描いている最中にすでに費用を知っています。制約に聞こえますし、実際に制約です。ただし役に立つ種類の制約です。作れないものは設計されず、設計が静かに落とされることもありません。落とす相手がいないからです。

もう一つ消えるのはレビューの往復です。チケットも、確認依頼も、「二倍解像度で書き出してもらえますか」もありません。変更があり、その変更が本番に出ます。

この体制が向かない場合

限界も正直に書きます。答えは「常に一人に頼め」ではありません。

一定規模を超えると成立しません。一人でプロダクト一つ、コーポレートサイト一つ、アプリ一つは背負えます。エンジニア四十人のプラットフォームは背負えません。無理に背負えば、ボトルネックが一人分できるだけです。

専門性も手放します。iOS 専任のエンジニアのほうが、私より良い iOS を書きます。専任のリサーチャーのほうが、良い調査を回します。プロジェクトが本当に一分野の深さを必要としているなら、深さが勝ちます。

そしてリスクが一点に集まります。その一人が動けなくなれば全部止まります。この点を質問してこない発注者は、まだ検討しきれていないと思いますし、私はむしろ聞いてほしいと思っています。

日本での現実的な使いどころ

日本の会社では、デザイン会社と開発会社を別に発注する形が今も標準です。理由は品質ではなく、契約と責任範囲が切り分けやすいからです。

その切り分けは、揉めたときには機能します。揉めていないときは、上に書いた劣化を毎日少しずつ生みます。

私の見方はこうです。要件が固まっていて規模が大きいなら、分けて発注してください。まだ何を作るべきか探している段階なら、決定の数が多く、人数は少ないほうが速い。ゼロイチ、社内の新規事業、コーポレートサイト、そして「代理店に頼んだら、打ち合わせで話した内容と全然違うものが返ってきた」と言われる類の案件です。

節約できるのは費用ではありません。だいたい費用も安くなりますが、本当に守られるのは、デザインの中には存在していて、実装の途中で少しずつ存在しなくなったほうのプロダクトです。