こんにちは、GAOGAOにてスタートアップスタジオのエンジニアをしております @mass-min と申します。GAOGAOでは秀吉と呼ばれています。どうぞよろしくお願いいたします。

今回はモノ作りをする上で欠かせない工程「仕様決め」についてのお話です。

GAOGAOは0->1開発を強みとしており、それゆえお客様とのミーティングやヒアリングを通してプロダクト全体の仕様決めを行う機会も多々あります。お客様があらかた仕様を固めた状態でプロジェクトをスタートすることもあれば、そもそもの構想段階から我々がお客様と二人三脚で進めていくこともあります。

いずれのケースにおいても重要なのは、 お客様が本当に欲しているものは何か、お客様の利益が最大になるにはどうすればよいかを考え提案すること です。これを達成するために仕様決めのフェーズで我々が何を考え、どう行動しているかを今回の記事でお伝えできればと思います。

0->1フェーズで確認すべきポイント

どんな技術を使って開発するのか

言語やフレームワーク、インフラ構成など、スタートアップスタジオとして、またチームのメンバーとして得意な技術分野はあるはずです。ですから、0->1フェーズにおいては自分たちの強みを最大限活かせる技術選定が最良手です。たとえ多少尖った技術が得意分野だったとしても、運用もずっと自分たちが行うならその選択で全く問題ありません。

しかしお客様が自社でエンジニアさんを雇って運用するイメージを描いていたり、お客様の他プロジェクトで既に専属の運用ベンダーさんがいたりすると、また状況が違ってきます。自分たちだけでなく今後運用を担ってくれるエンジニアさんたちも触りやすいよう、ドキュメントも揃っていないような尖った技術というよりは普遍的に使われている技術に寄せて選択をする必要があります。
どんなベンダーさんでもキャッチアップが容易というメリットがありますし、お客様がもし自社でエンジニアさんを雇うことになっても人口が多く採用の幅が広がるというメリットもあります。実際GAOGAOでも、大手企業のお客様で専属の運用ベンダーさんがRailsが得意ということで、我々が当初提案していた PHP × Laravel ではなく運用実績のある Ruby × Rails での開発になった事例もあります。

もちろん技術は日進月歩であり、次の3年、5年を耐えうる技術選定であるかどうかも非常に重要です。このように、技術選定に関しては観点がいくつも存在します。今最大限の開発速度が出る手法を取るのがいいのか、それとも今作ったプロダクトを今後も改修し続けていくことを考慮すべきなのか、それはお客様のニーズ次第です。お客様の思い描く未来に寄り添えるよう、しっかりとヒアリングを重ねた上で技術選定をする必要があります。

あれもこれもと機能を盛り込みすぎていないか

プロダクトにおいて一番の悪手は「ユーザーに使われないものを作ること」です。分かってはいるけれど、そんなの作ってみないと実際に使われるかどうか分からない…というのが大方の世論です。ですが、よくよく聞いてみるとこれは要らないだろうと分かることもありますよね。

例えば、旧システムやプロトタイプフェーズで管理していたデータの移行機能。一度移行したらもう使われない機能ですが、ファイルのやりとりを実装する必要があり、ファイルが正しいフォーマットで渡ってくるか保証されていない場合テストケースが多くなるため、結果として作業工数が膨れ上がってしまうことが多いです。
作り終わって運用に乗せたときのことを考えると、「多少手間でも手作業でデータを登録し直した方が時間も費用も掛からなかった…」となってしまう未来が見えます。

こういった悲劇を防ぐためには、最初に必要そうだと思った機能を考えなしに全部載せしないことが重要です。GAOGAOスタートアップスタジオの方針では、 もしお客様の方で仕様をあらかた決め終わっていたとしても、機能を盛り込みすぎているなと感じたらその旨はすぐにお客様に伝えます。 「盛り込みすぎていると感じる」というのは、機能を実装した場合と実装せずその他の方法で実現した場合とでコストとユーザーの満足度を想定し、機能実装した場合のコストパフォーマンスが低いと結論づけた状態を指します。
最終判断はもちろんお客様がしますが、ユーザーに使われないものを高値で作ってしまうという、お客様にとって最大のリスクを回避するため、判断材料は常に提供し続ける必要があります。

GAOGAOのVALUE に「Practical」というものがあります。スタートアップスタジオのメンバーはただ言われた通りに実装するだけのいち技術リソースではなく、お客様と一緒にプロダクトを考え抜く存在です。ときには「作らない」という選択肢を取ってでも、お客様が見たい未来への最短ルートを考えます。

お客様はワクワクしているか

お客様が定めた仕様にそのまま沿って開発して、そこそこユーザーが付けばそれでよいでしょうか。

もちろんお客様はその事業ドメインにおけるプロフェッショナルですから、お客様が定めた仕様に沿った開発をするのが良いケースは多々あります。しかし、よく考えてみてください。そのプロダクトを使うユーザーはお客様自身ではないかもしれません。我々と同じ、その事業ドメインでの素人が使うとしたらどうでしょう。
分かりづらいと感じたところ、ちょっと仕様を変えればよりユーザーが使いやすくなりそうなところ、こういった観点は常にプロフェッショナルとして立ち向かうお客様からすると意外に出てきにくいものです。
仕様を決めていく上で、よりよいものが思い浮かんだらそれを具体的に提案します。よりユーザーフレンドリーなプロダクトを生み出すことに対してほぼすべてのお客様は圧倒的にワクワクするはずですし、そのワクワクはユーザーにも間違いなく伝わります。お客様あってのプロダクトです。お客様がプロダクトに全力で愛情を注ぎ続けられるように、スタジオメンバーも全力でユーザーフレンドリーな開発を貫きます。

前項と相対するようにも思えますが、機能追加だけがユーザーフレンドリーなプロダクトの作り方ではありません。細部にこだわったり、逆に無駄なフローからステップを取り除いたりするのも手法の1つです。スタジオメンバーとして徹底的にプロダクトのイメージを描き、そこから出てきた意見でお客様が圧倒的にワクワクしてくれると最高です。

むすび

0->1開発と言うと誤解されがちですが、プロダクトは決して「作って終わり」ではなく、長きに渡ってお客様のニーズに応え続けなければいけません。しかしながら、プロダクトの開発や運用のしやすさは最初の仕様決めがうまく進められるかどうかに大きく依存します。そしてエンジニアとしてのスキルレベルがはっきりと現れるのもこの仕様決めのフェーズです。皆様もモノ作りをする際は、ぜひ今回挙げたようなポイントに気を配りながら素晴らしいモノを生み出していってください。

GAOGAOでは、この非常に難解ながらも非常にわくわくするフェーズを一緒に楽しめるエンジニアの皆さんを心からお待ちしています！興味が湧いた方は、ぜひお気軽にご連絡いただければと思います！

なんだか終始エモめの話でまとまりがあったのかなかったのかよく分からなくなってしまいましたが、お読みいただきありがとうございました！では、また次回👋