仕様が固まらないまま始めたシステム開発をプロトタイプで乗り越えた話

はじめに

「まず仕様を決めてきてください」

システム開発を検討してWeb制作会社や開発会社に相談したとき、こう言われて止まってしまった経験はないでしょうか。あるいは、何度打ち合わせを重ねても話がまとまらず、気づいたらプロジェクトが宙に浮いていた、という方もいるかもしれません。

私はWebエンジニアとして独立する前、大手化学メーカーで7年間、研究開発に携わっていました。その後Web業界に転身し、今は製造業や中小企業のシステム開発・Web制作を手がけています。その経験の中で、ある案件を通じて「仕様が固まらない問題」の本質と、その解決策に気づきました。今回はその話をそのまま書こうと思います。

なぜ仕様は固まらないのか

最初に断言しておきたいのは、「仕様が固まらない」のは発注する側の能力の問題ではないということです。

自社の業務フローを言語化することに慣れている人は、ほとんどいません。毎日当たり前のようにやっている作業だからこそ、それを言葉にするのは意外と難しい。「こういう感じで」「なんとなくこういう流れで」という表現になってしまうのは、むしろ自然なことです。

加えて、言葉で説明できたとしても、受け取る側との認識がズレることは頻繁に起きます。「管理する」という言葉一つとっても、Aさんが想像するシステムとBさんが想像するシステムは全然違う。言葉は思っている以上に曖昧で、それがそのままシステムの仕様に持ち込まれると、後になって「こういうつもりじゃなかった」という事態が起きます。

つまり「仕様が固まらない」という問題は、発注側の準備不足ではなく、言葉だけで仕様を確認しようとする進め方そのものに無理があるのです。

ミーティングのたびに話が変わった、あの案件のこと

少し前の話になりますが、中国からアパレル商品を輸入して日本国内で販売したい人たちを支援する、輸入代行業者の方からシステム開発のご依頼をいただきました。

その方のビジネスは複雑な構造をしていました。中国現地のスタッフ、日本国内で輸入販売をしたいクライアント、そして加工・検品・梱包を担当する作業者。この三者の間に入って、商品ごとに異なる指示を出したり、タグの付け替えや値札の変更を管理したりしていたのです。それをExcelで管理していたのですが、クライアントが増えるにつれて煩雑さが限界に達していた。

初回の打ち合わせでは「こういうシステムが欲しい」というイメージを丁寧に話してくれました。ところが次の打ち合わせでは、別の機能が追加されていたり、前回と違う前提で話が進んでいたりする。

正直に言うと、最初は戸惑いました。「なぜ話がまとまらないのか」と。でも打ち合わせを重ねるうちに気づいたのです。この方は悪意があって話を変えているわけじゃない。自分のビジネスの全体像を言葉にしながら、頭の中を整理しているんだ、と。

化学メーカーで叩き込まれた「仮説検証」の思考

行き詰まったとき、私は化学メーカー時代の感覚を思い出しました。

研究開発では、最初から正解を出そうとしません。まず仮説を立てて、実験して、結果を見て、仮説を修正する。この繰り返しです。重要なのは「言葉で考える」より「手を動かして確かめる」こと。どんなに精緻な計画を立てても、実際に実験してみると想定外のことが起きる。それが当たり前で、そこから学んでいくのが研究のプロセスでした。

「これはWebの仕事でも同じじゃないか」と思ったのです。言葉でいくら仕様を確認しようとしても限界がある。だったら、動くものを先に見せてしまえばいい。

「これです！これで勝てます！」

仕様がある程度見えてきた段階で、私はまだ完全には固まっていない状態のまま、簡単なプロトタイプを作りました。完成品ではなく、あくまでも「こういう認識で合っていますか？」を確認するためのものです。

それを見せたとき、クライアントの反応は今でも鮮明に覚えています。

「これです！これで勝てます！」

それまで言葉でうまく伝えられなかったものが、画面の前で一気につながった瞬間でした。「ここはこうしたい」「この部分はもう少しこう変えてほしい」という具体的なフィードバックも、プロトタイプがあることで初めてスムーズに出てきました。

言葉での説明が難しかったのではなく、見るべきものがなかっただけだったのです。

この経験が変えた、私のヒアリングへの向き合い方

この案件以来、私はシステム開発の打ち合わせにおいて、「仕様を言葉で固めてから動く」という順番にこだわらなくなりました。むしろ、ある程度の認識が揃ったら早めに手を動かして、動くものを見ながら一緒に考えるというプロセスを意識しています。

もちろん、プロトタイプを作るにはそれなりの時間と手間がかかります。でも、言葉だけで何度も打ち合わせを繰り返して後から大幅な修正が入るよりも、結果的にずっと効率がいい。何より、クライアントにとって「自分のビジネスがちゃんと形になっていく」実感を早い段階で持ってもらえることが、信頼関係の構築につながると感じています。

ただ、こうした打ち合わせには発注する側にも相応の負荷がかかります。その覚悟についてはシステム開発を依頼する前に知っておきたい「打ち合わせの覚悟」に書きました。

化学メーカー時代に染み込んだ「仮説→検証→修正」の思考は、研究室を離れた今も、私の仕事の核にあります。

複雑な業務課題を抱えている方へ

既製品のシステムやツールでは解決できない、自社独自の業務フローがある。でも、それをどう言語化して開発会社に伝えればいいか分からない。そういう悩みを持つ方は、思っている以上に多いです。

開発会社に相談する前に何を整理しておくとよいかは、システム開発を依頼する前に整理しておくと、話がスムーズに進むことにまとめました。

仕様が固まっていなくても大丈夫です。むしろ、固まっていない段階から一緒に考えることが、私の仕事だと思っています。

まずは現状をそのままお話しください。「こういう感じで」「なんとなくこういう流れで」という言葉で十分です。そこから一緒に整理していきましょう。