【契約書管理SaaSを、クライアントと共にゼロから立ち上げる 】
雛形化・差分管理・複数人運用を実装して、構想段階からサービス立ち上げ・継続開発まで伴走支援したゼロイチ開発の支援事例

1. 本事例の背景（相談の入口）

本プロジェクトは、補助金を活用したゼロイチの新規サービス開発としてスタートしました。クライアント側には、開発において契約書管理における明確な課題意識がありました。契約書は同じような文面が多いにもかかわらず、相手ごとの名前や条件、時期などの差分によって、作成・送付・管理の負荷が大きくなってしまいます。ここをもっと効率化できないか、という発想がサービスの出発点でした。

たとえば、電子契約サービスの多くは「会社と会社」「担当者と相手方」のような1対1のやり取りを前提にした手軽で便利な体験が中心です。一方で、同じような契約書を多数の相手に送る場合や、契約本文はほぼ同じで一部の条件だけが異なる場合には、個別作成・個別送信・個別管理の手間が積み重なります。

そこで目指したのが、契約書の共通部分を雛形として持ち、相手ごとに異なる情報だけを差分として扱える仕組みです。同じ文面を何度も作り直すのではなく、共通化できるものは共通化し、個別に変えるべき部分だけを管理する。そうすることで、作成する側も確認する側も、より少ない負荷で契約業務を進められるようになります。

ただし、クライアント側はビジネスサイドが強く、課題の定義や「こういう問題を解決したい」という構想は持っていたものの、実際にそれをどう開発し、どうサービスとして成立させるかを担える体制が社内にありませんでした。

そこでKSRが開発パートナーとして参画し、西谷さんが開発PMとしてプロジェクト推進を担うことになりました。ゼロイチ開発である以上、最初からすべてが見えていたわけではありません。何が起きるか分からない、どこまで機能が広がるかも分からない、だからこそビジネスサイドの構想をそのまま受け取るだけではなく、画面・操作・データ・開発工数へ一つずつ変換し、クライアントと共にサービスとして立ち上げていく役割が必要でした。

2. 課題（支援先で起きていたこと）

プロジェクトを進めるうえでの難しさは、大きく2つありました。

1つ目は、ゼロイチ開発だからこそ、将来の拡張性を見越した設計が必要だったことです。本プロジェクトは、最初から完成された仕様がある状態ではなく、ゼロから契約書管理SaaSを立ち上げていくプロジェクトでした。初期リリースで必要な機能を作るだけであれば、短期的に実装しやすい構成を選ぶこともできますが、サービスとして立ち上げる以上、リリース後に機能追加が続くことも想定されます。契約書の種類が増える可能性もありますし、運用の中で新しいビジネスロジックが追加される可能性もあります。そのため、最初の段階から「後で機能が増えても崩れにくい構成」にしておく必要がありました。単に早く作るのではなく、今後どこまで広がるか分からないサービスを受け止められる土台を作ることが、重要な論点でした。

2つ目は、要件を決めるたびに、サービス全体への影響を見なければならなかったことです。ビジネスサイドとの会話では、「こういう機能を作りたい」「こういう画面にしたい」という実現したいことに意識が向きやすくなります。もちろん、それ自体はプロダクトづくりにおいて大切な出発点です。一方で、ゼロから作るサービスでは、ひとつの機能追加が、画面の導線、データの持ち方、ステータス管理、周辺機能の動きに影響します。

つまり本事例の課題は、単に「サービスを作ること」ではありません。ゼロイチの不確実性がある中で、将来の拡張に耐えられる設計を選びながら、目の前の要件をサービス全体として自然に成立する形へ落とし込むことでした。

3. ゴール（何を"できる状態"にするか）

今回のゴールは、契約書管理SaaSをクライアントと共にゼロから立ち上げることでした。開発体制を持たないクライアントに代わり、KSRが開発パートナーとして中に入り、ビジネスサイドが描いていた構想を、実際にユーザーが操作できるサービスへ落とし込むこと。そして、初期リリース後も機能追加を重ねながら、継続的に広げていける土台をつくることが求められていました。

ゼロイチ開発では、最初に作るものが最終形とは限りません。むしろ、初期リリース後に機能を追加し、運用の中で改善しながら、サービスとして育てていく前提があります。だからこそ本プロジェクトでは、まずサービスとして形にすることと、その後も広げられる土台を作ることの両方が重要でした。短期的な実装だけに寄せるのではなく、将来の機能追加や運用変化にも耐えられる設計にする。そこまで含めて、サービスをゼロから立ち上げることが今回のゴールでした。

4. 進め方（実行してきたこと）

4-1. 契約書管理のドメインを理解し、不明点を確認する

まず必要だったのは、契約書という領域への理解です。西谷さん自身、過去に業務委託契約に触れた経験があり、「契約は重要だ」という感覚は持っていたと語っています。ただ、契約書管理サービスとして成立させるには、それだけでは足りません。

• 契約書のこの部分はどう扱うのか。
• この条件で契約は成立するのか。
• 相手ごとに違う情報は、どこまで差分として持つべきなのか。
• 雛形として共通化してよい部分と、個別に変更すべき部分はどこなのか。

など、多角的な視点でみる必要があります。分からないことがあれば、都度確認しながらキャッチアップしていきました。ゼロイチのプロジェクトでは、最初から正解が用意されているわけではありません。だからこそ、分からないまま作らず、聞いて、確認して、理解を積み上げていくことが重要になります。

4-2. シンプルな構想から、画面モックへ落とし込む

クライアント側から出てくる最初の情報は、必ずしも詳細な仕様書ではありません。「こういうことを実現したい」という構想が、スライド上のシンプルな図や比較のような形で示されることもあります。そこに対して、逐一、細かな問いを重ねていきました。「これはどういう意味ですか？」「このケースではどう動きますか？」「この操作の次は、どの画面に進みますか？」「この情報は、契約書のどこに反映されますか？」といったように、こうした会話を通じて、やりたいことを少しずつ具体化していきます。

そのうえで、デザイナーと連携し、画面モックとして整理しました。文章だけでは曖昧だったものを、実際の画面と操作に落とすことで、「こういう操作をすれば、こういうことが実現できます」という状態をクライアントと一緒に確認できるようになります。ゼロイチ開発では、画面にして初めて見える論点が多くあります。だからこそ、モックは単なるデザイン確認ではなく、要件を具体化し、サービスとして成立させるための重要な材料になります。

4-3. 機能を細かく切り、リリース単位を設計する

プロジェクトにはフェーズごとのスケジュールがありました。初期リリースでどこまで出すのか、その後に機能追加をするならどれくらいかかるのか、3ヶ月後なのか半年後なのか。こうしたリリース単位を決めるために、機能を細かく切っていきました。この切り方こそ、要件定義の重要なポイントです。

やりたいことをすべて一度に作ろうとすると、スケジュールもコストも膨らみます。一方で、切りすぎると初期リリースとしての価値が弱くなります。そのため、画面モックと実現内容をすり合わせたうえで、実際に作った場合どれくらいかかるのかを見積もり、現実的な開発スケジュールへ落とし込みました。「やりたいこと」を「いつ、どこまで作るか」に変換することで、構想がサービス開発として進む状態になっていきます。

4-4. プロジェクトオーナー／BizPMと解釈を揃え、詳細を詰める

意思決定の体制としては、クライアント側にプロジェクトオーナーがいて、その下にプロダクトオーナー兼BizPMに近い担当者がいるというような構造でした。西谷さんは、その2名と話した内容を受けて、「こういう解釈で、こう進めましょう」という形に落とし込みながら、詳細を詰めていきました。

ここで重要なのは、外部から一方的に「こうした方がよい」と提案するような関わり方ではなかったことです。クライアントの頭の中にあるものを理解し、それを開発できる形に翻訳する。完全に100％一致することは難しくても、少なくとも見ている像が重なる状態を作り、そのうえで「自分の中でも納得できる形」へ落としていく。

この"解釈のすり合わせ"が、今回の要件定義の中心にありました。構想を持つ人と、実装を担う人の間で見ているものがずれると、プロジェクトは進むほど手戻りが大きくなります。だからこそ、早い段階で画面や機能単位に落とし、同じ像を見ながら判断できる状態を作りました。

4-5. 拡張性を意識し、後から崩れにくい技術設計にする

課題の1つである拡張性に対しては、初期段階から技術設計で備えていきました。本プロジェクトでは、フロントエンドをReact、バックエンドをGoで構成しました。西谷さんはバックエンド側を主な専門領域として、DBの拡張性や、後からビジネスロジックを追加しても崩れにくい設計を意識しました。短期間で素早く作るだけであれば、もっとシンプルな構成を選ぶこともできます。

しかし今回は、今後どこまで機能が広がるか分からないゼロイチのサービスです。契約書の種類や運用パターンが増える可能性もあります。だからこそ、ビジネスロジックを後から追加しても破綻しにくい構成を、初期段階から意識していました。

いま作りたいものだけでなく、この先どのように育っていくか分からないものを受け止められるようにする。そこに、開発PMとして技術側の責任を持つ西谷さんの視点が反映されています。

4-6. 要件追加時に、周辺機能への影響まで見立てる

2つ目の課題に対して、西谷さんが価値を発揮したのが、要件追加時の影響範囲をその場で見立てる動きです。本プロジェクトはゼロから作っていたため、西谷さんの頭の中には、サービス内のどの機能がどこに関連しているかが入っていました。だからこそ、打ち合わせの中で新しい要件や機能案が出たときにも、「この機能を追加すると、こちらの動きはどうなりますか」「この導線だと、ユーザーが少し迷うかもしれません」といった論点をすぐに出すことができました。これは、単に技術的な実装可否を見るだけではありません。画面上の操作、既存機能とのつながり、データやステータスの扱い、ユーザーが迷わず進められるかまで含めて、サービス全体として自然に成立するかを確認していく動きです。

ビジネス側の「こうしたい」という意図を受け取りながら、実装した後にどこへ影響が出るのかを先回りして考える。その場で技術面・体験面の両方から論点を出せたことが、後から大きな手戻りを生みにくい進め方につながっていました。

4-7. 開発PMに留まらず、UI・導線・必要性まで議論に入る

西谷さんの役割は開発PMでした。技術側の責任を持ち、何を作るかを開発へ落とすことはもちろん重要です。ただ、それだけに留まらず、周囲へ"染み出す"ように動いていたことが、このプロジェクトの特徴です。

たとえば、ある画面について、「この動きだとユーザーが迷わないですか？」「このUIの方が自然に進められるのではないですか？」といった会話に入ります。あるいは、機能の配置について、「この機能はここではなく、この導線にした方が違和感なく使えるのではないですか？」と議論します。決められたものをそのまま作るのではなく、「この機能は本当に必要ですか？」「本当にこの形でよいですか？」というところから一緒に考えます。

そこに、西谷さんの開発PMとしてのバリューがありました。開発PMという役割に閉じるのではなく、ユーザー体験や導線、機能の必要性まで含めて議論に入り、サービス全体がより自然に成立する形を探っていきました。

5. 成果

本事例の成果は、契約書管理SaaSの構想を、クライアントと共にゼロからサービスとして立ち上げたことです。ビジネスサイドが持っていた「契約書の共通部分を雛形化し、個別に違う情報だけを扱えるようにしたい」という構想に対して、画面・機能・リリース単位・技術設計を一つずつ具体化。契約書の多くが共通文面であり、一部だけが相手ごとに変わるという業務特性を、雛形化・差分管理というサービスの核へ落とし込みました。

また、初期リリースと追加開発を分け、必要な機能を細かく切り出したことで、現実的な開発スケジュールに変換できた点も大きな成果です。ゼロイチ開発では、最初にどこまで作るかの判断が重要になります。大きく作りすぎればリリースが遠のき、小さくしすぎれば価値が伝わりにくくなる。そのバランスを、画面モックと見積もりを行き来しながら整理していきました。

さらに、リリース後の機能追加を見据え、拡張性を意識した技術設計を初期段階から組み込んだことも、本事例ならではのポイントです。後からビジネスロジックが追加されても崩れにくい構成にすることで、サービスを継続的に育てていける土台をつくりました。

KSRは単なる外部ベンダーではなく、クライアントの中に入り込む開発パートナーとして伴走しました。初期リリースまでは請負、その後は準委任という形で関わり方を変えながら、フェーズに応じてサービス開発を支えています。構想を理解し、画面にし、技術的な影響を見立て、リリース単位へ切り分ける。その一連の動きによって、まだ形のなかったアイデアが、契約書管理SaaSという実際のサービスへと変わっていきました。

6. インタビュイーのこだわり

西谷さんが最後に語っていたのは、自分が納得できるものを作りたいというシンプルで強い姿勢です。既にあるサービスであれば、その上に積み重ねていくしかない場面もあります。しかし今回はゼロイチで、一番最初の一歩を作るプロジェクトでした。だからこそ、「自分が使わないシステムを作っても仕方ない」という感覚があったと語られています。これは、単なるこだわりではありません。開発PMとして、技術側の責任を持つだけではなく、ユーザーが迷わないか、導線に違和感がないか、その機能は本当に必要かという議論にも踏み込む。自分自身が「これは自信を持って出せる」と思える状態まで考え抜くからこそ、ビジネスの構想と技術の実装の間にあるズレを埋められます。

要件定義において大事なのは、依頼された内容をそのまま仕様にすることだけではありません。相手の頭の中を理解し、同じ像を見られる状態を作り、そのうえで「自分ならこれが正解だと思える形」へ落とし込むことです。その姿勢が、今回のプロジェクト全体に通底していました。

7. 最後に（総括）

ゼロイチのサービス開発では、最初から完成図がはっきりしているとは限りません。解きたい課題はある。届けたい価値もある。けれど、それを実際の画面・機能・導線・データ構造に落とし込み、サービスとして提供できる状態まで持っていくには、いくつもの判断が必要になります。

今回の支援が示しているのは、サービス立ち上げにおける開発PMの役割です。構想を整理するだけではなく、ユーザーが操作できる形にし、初期リリースに必要な範囲を見極め、将来の拡張にも耐えられる設計にする。さらに、要件が増えたときにも周辺機能への影響を見ながら、サービス全体として自然に成立する形を保つ。そこまで踏み込んで初めて、ゼロイチのアイデアは実際に動くサービスになります。

特に印象的なのは、西谷さんが「決められたものをそのまま作る」のではなく、UIや導線、機能の必要性にまで自然に踏み込んでいた点です。それは役割を越境しているというより、サービスを最初の一歩からきちんと立ち上げるために必要な動きだったのだと思います。

ビジネス側の構想を受け取り、画面に変え、開発単位に切り分け、技術的な土台まで整える。そして、初期リリースだけで終わらせず、その後も広げられる形にしていく。契約書管理SaaSを、クライアントと共にゼロから立ち上げる過程には、要件定義・開発PM・技術設計が一体となって価値を出す、KSRらしい支援の形が表れていました。