開発プロセス

事業のアイデア段階や創業前のご相談でも構いません。検証したい仮説、想定しているユーザー、おおよそのご予算感と時期が分かるとスムーズですが、決まっていなくても問題ありません。ご相談とお見積りは無料です。秘密保持契約が必要な場合は、この段階でお知らせください。

お問い合わせの前に社内で頭を整理しておきたい場合は、要件を1枚にまとめるシートの7つの欄を埋めてみてください。埋まらない欄があっても構いません。埋まらなかった箇所こそ、最初のお打ち合わせで一緒に考える論点になります。

オンラインのお打ち合わせで、事業の目的から逆算して「何を検証したいのか」「最初のユーザーは誰か」を整理します。既存のプロダクトがある場合は、コードや環境を拝見して現状を把握します。この段階で、技術的に難しい点、費用がかさみそうな点、システム化しないほうがよい部分を率直にお伝えします。

初回に作る範囲をどこで切るかを社内で議論する際は、MVPの範囲を決めるチェックシートが役立ちます。「誰が何を決めるか」がはっきりしないまま議論が止まる場合は関係者と決裁の地図を、範囲・期日・費用のどれを固定するかで意見が割れる場合は範囲・期日・費用の優先順位シートをお使いください。

課題整理の結果をもとに、初回に作る範囲と後回しにする範囲を分けた提案書と、作業項目ごとの内訳を記した見積書をお出しします。ご予算の上限があれば、その範囲で効果の大きい構成をご提案します。契約形態（準委任・請負）の使い分けも、この段階でご相談します。詳しくは料金の考え方をご覧ください。ここまでは費用をいただきません。

弊社の見積りを他社の見積りと並べてご検討いただく場合は、相見積もりの比較シートの手順で前提条件を揃えてからお比べください。総額の差は値段の差ではなく範囲の差であることが多く、揃えずに並べると安く見えた見積りが後から追加費用で並ぶことがあります。各社に同じ質問をするための質問集として開発パートナー選定で確認する15の質問もご用意しています。弊社にも同じ質問をぶつけてくださって構いません。

二つの契約形態は、対価が何に対して支払われるかが違います。準委任契約は業務を行うこと、つまり稼働が対価の対象です。完成の義務はなく、専門家として適切に業務を進める義務を負います。請負契約は完成した成果物が対価の対象で、検収を通ることが支払いの条件になります。

この違いは、仕様が変わったときの手続きに表れます。準委任では優先順位を入れ替えて次の稼働分に回せますが、請負では範囲の変更ごとに金額と納期を合意し直す必要があります。要件が変わりやすいMVP段階に準委任が向くのは、この手続きの差が理由です。逆に範囲と検収条件を確定できる開発では、請負のほうが総額を先に決められます。

契約書には作業範囲、期間、検収の方法、支払条件、著作権の扱いを明記し、後から認識のずれが起きないようにします。

ソースコードの権利については、納品物の著作権をお客様に譲渡する形を基本としています。汎用的な部品や弊社の開発基盤など譲渡の対象外にするものがある場合は、契約前にその範囲をお伝えします。リポジトリをどこに置くか、いつ移すか、弊社が離れたあとに何が残るかも、この段階で決めておきます。ご締結の前に契約形態の選び方シートで自社の状況を整理し、ソースコードの権利の確認事項で権利の条項とリポジトリの移転時期を確かめておくと、条文を読む目的がはっきりします。一般的な情報であり、個別の事案は専門家・所管官庁にご確認ください。

主要な画面の流れを先に固め、ユーザーが迷わない導線を設計します。あわせてデータ構造、権限、外部サービスとの連携方法を決めます。作り直しの費用が最も小さい段階で問題を見つけるため、プロトタイプでの確認をおすすめしています。設計書は検収の基準と、将来の引き継ぎ資料になります。

この段階では機能の話に集中しがちですが、性能・可用性・セキュリティ・運用の要件は聞かれないまま決まらずに進むことがあります。非機能要件の確認シートの6分野を発注側から確認していただくと、公開後に効いてくる論点を先に決められます。着手前に揃えておくものはキックオフ前の確認事項にまとめています。

すべてが完成してからお見せするのではなく、短い周期で動くものをご確認いただきます。実際に触ると設計時には気づかなかった点が見えてくるため、軽微な調整はその場で反映します。生成AIによるコード生成・レビュー・テスト作成を活用し、同じ期間でより多くを実装します。作業範囲を超える変更が必要になった場合は、影響と費用をご説明したうえでご判断いただきます。

毎週の確認でどこを見ればよいか迷う場合は、週次デモの確認シートの9つの観点をお使いください。進捗率の報告ではなく動くものを見る形にすると、ずれに早く気づけます。

クラウド上の本番環境、自動デプロイ、監視、バックアップを整えて公開します。既存プロダクトからの移行がある場合は、停止時間を抑えた手順で切り替えます。コードの構成、環境情報、運用手順をまとめたドキュメントと、各種アカウント情報をお渡しし、管理情報がお客様の手元に残る状態にします。

納品を受け入れる前にお客様ご自身で確かめていただく観点は検収テストの項目シートに、公開当日の段取りと切り戻しの判断はリリース前チェックリストに整理しています。公開後に何を見て異常に気づくかは監視設定の確認シート、止まったときに誰が何をするかは障害対応の手順シートで、公開前に決めておくことをおすすめします。

リリース時に組み込んだ計測をもとに、ユーザーの行動と事業の指標を確認します。定着率や転換率など、事業の判断に必要な数字を見ながら、次に改善すべき点を決めます。改善は月ごとの稼働時間を決めた準委任契約で継続するのが基本です。使われていない機能を削る判断も、この段階で行います。

見る指標が増えすぎると判断が鈍ります。何を中心に見るかを一つ決めるところから始める場合はKPI設計のはじめの一歩を、保守として何がどこまで含まれ、どこから追加費用になるのかを線引きする場合は保守範囲の確認シートをお使いください。

事業が成長し、社内で開発を続ける段階になったら、開発チーム体制構築・内製化支援として移行を進めます。最初のエンジニアの採用要件づくりや技術面接への同席、入社後の環境整備、コードレビューや設計相談による伴走を通じて、チームが自走できるまでを支えます。すべてを内製化しない選択も含めてご相談ください。

引き継ぎで足りなくなるのは、多くの場合ソースコード以外のものです。受け取るものの一覧は引き継ぎ資料の確認リストに、担当が替わっても回る記録の形は運用手順書のひな形にまとめています。弊社から引き継ぐ場合だけでなく、他社から引き継ぐ場合にもお使いいただけます。