LayerX・榎本氏が語る“いいプロダクト開発の条件”　開発のループを速く回し、プロダクトのキメラ化を防ぐには

開発のループを速く回すためにフルスタックになりましょう

榎本悠介氏：最速でループを回すためには、もう簡単な話なんですが、フルスタックになりましょう。先ほど、画面仕様を作る、バックエンド設計する、実装する、みたいなポイントがいくつかあったんですけど、それらを全部カバーできるようになれば自分1人でループを回せるので、それが一番速いんですよね。

フロントとかバックエンドとか、もちろん得意領域はあっていいんですが、それらをまたいで一気通貫にできるようになろうぜというのが、基本的な考え方になります。

慣れてくると、脳内でループが回せます。脳内ですぐ「やっぱりこっちだったわ」というのができるようになると、めちゃくちゃ開発は早くなるし、いいものができるサイクルが回ってきます。

フロントエンドエンジニア、バックエンドエンジニア、プロダクトマネージャー、デザイナーみたいな感じでこれが全部分業されていると、お互いの専門性が発揮できていいっちゃいいんですけれども、やはりどうしてもコストがかかります。

前提を揃えたり、前提を共有するために、画面仕様を起こしてみましたとか、資料作成したりとか、インターフェイス仕様書作ってみましたみたいなコミュニケーションコストがかかったり。

それをもとに実際に実装してみて、みんなで確認して、「なんか違うね」ってなって、「じゃあ、ここから戻ろう」みたいになるコストとか、最終的に、「これはいいね」って合意形成したりだとか、そういうコストがかかっちゃうので。

これを1人とか、オーバーラップするかたちで2人とかで完結すると、めちゃくちゃループが速く回るので、いいプロダクトが作れるようになると思っています。

複雑になった時点で罠にはまっている

なので、第1にドメイン知識が絶対あります。必要です。ドメイン知識をベースに、もちろんコードレビューとかはあるかもしれませんが、この機能は自分が主役だと、自分が絶対責任を持って作りきるんだという、あくまで自分が主役で、みんなで背中を預け合って開発しましょうみたいなチームが結果的に一番いいプロダクトを作るチームになるかなと思っています。

なので、とにかく覚悟が大事ですね。「この機能は俺が主役で、なにかあったら俺の責任だ」くらいに思うのが、いいプロダクトを作れるチームかなと思います。

あとは、デザインもそうですし、いろいろな技能があると、さらに高速に回すことができます。要は、全部できるといいねという、ちょっとマッチョな結論になっちゃうんですけど、そういうチームでありたいなと思っています。

あとは、大事な考え方になるんですけど、仕様ですね。プロダクトの仕様は、とにかくシンプルにしましょう。複雑になった時点で、もうなにか罠にはまっていますね。ユーザーに伝わらないし使われないし、よくわからない。作るのも大変だし、作るのが大変ということは、負債も大きくなるし、品質も低くなるのでだいたいバグも出まくるんですよね。

複雑な仕様って、たぶん誰も得していない。なにかが間違ってそうなっちゃっているという嗅覚を持ちましょう。それを工夫して、どうシンプルに落とし込むかが腕の見せどころだと思っています。

なので、エンジニアってそこがすごくいいところかなと思っています。エンジニアだと見積もりができるじゃないですか。概算で問題ないので、これがやばいかやばくないかみたいなところが肌感でわかるのがすごくいいなと思っています。

あとは、「短期では、なんとかなるけど長期だとやばくなるな、これ」みたいな嗅覚もあると思います。既存のシステム仕様もわかっているので、「ここをつぎはぎするとやばいぞ」みたいなのもわかる。

プラス、先ほどのドメイン知識と、どれだけユーザーにメリットがあるか、という両面を掛け合わせると、シンプルなコスパのいい落としどころがわかるので、そこを目指していけると長期的に使われるプロダクトになっていくかなと思います。

「ここまでは許していいけど、ここまではあかん」みたいなポイント、落としどころをさっと作れるような人になると、いいプロダクトになっていくかなと思います。

ユーザーに言われたとおりに作らないことが大事

あとは、ユーザーに言われたとおりに作らないのもすごく大事です。

ヒアリングで、「こういう機能欲しい、こういう機能欲しい」と言われるんですけど、それをそのまま額面どおり受け取るんじゃなくて、「こういう要望が来るということは、そもそも想定していない使い方をしているぞ」とか、「そもそも、もともとの業務をこう変えるべきなんじゃないか？」とか、逆に提案をしたり「僕らのそもそも考える、あるべきのフローって何だっけ？」みたいなところに立ち返って、言われたまま作るんじゃなくて、あるべきをより抽象化して作るのがいいかなと思います。

Howは僕らが考える仕事なので、あくまでWhyを突き詰めて考えるというかたちです。お客さまが言っている。その上でなるべく個別機能じゃなくて、ラベル機能とかタグ機能とか、抽象化していける分には抽象化して作る、みたいなのをすると、複数の要望が一気に打ち取れてキメラにならないプロダクトになるかなと思います。

（次回へつづく）