開発会社に発注するとき、「途中で何をやっているかわからない」という不安を持つ方は多い。
その不安は正当だと思う。数百万、場合によっては数千万を預けて、進捗がブラックボックスになっている状態は、発注側にとってリスクでしかない。
だからうちは、フローを全部公開している。どの段階で何をやっているか、発注側に何をお願いするか、すべて事前に知っておいてほしいからだ。
1. はじめての相談
要件が固まっていない段階でも相談を受け付けている。「こういうものを作りたいが、何から始めればいいかわからない」という状態で来てもらって構わない。
最初に確認するのは、何を作るかよりなぜ作るかだ。目的が明確になると、必要な機能と不要な機能が整理できる。この段階で目的を共有しておくことが、後のすれ違いを防ぐ一番の方法だと考えている。
2. AIでモックアップを作りながら、要件と金額をすり合わせる
ヒアリングをもとに見積もりを出す前に、まずAIでモックアップやデモを作る。
この段階で用意するものは、ワイヤーフレームのような簡易的なものではない。実際に操作できる、かなり完成度の高い状態で準備する。
初めて見た方から「え、これってもう完成しているように見えるんですけど」と言われることがある。それくらいの状態で、要件の確認に入る。
動くものを見ながら「これじゃない」「これに近い」を確認することで、言葉だけのやり取りでは気づけない認識のズレを早い段階で解消できる。「なんとなくこんな感じ」という曖昧さが、この段階でかなり具体化される。
見積もりもこの段階で提示する。モックアップがあることで、発注側も「何に対してこの金額が発生しているか」を確認しながら話し合うことができる。根拠のない金額を提示することは、うちはしない。
3. 何を作って、何を作らないかを明文化する
方向性が固まったら、スコープを書面で明確にする。
「この機能は作る」「これは作らない」「これは次のフェーズで検討する」——ここを曖昧にしたまま進めると、後で認識のズレが生まれる。それが「言った言わない」につながる。このタイミングで必ず双方が合意した内容を文書化する。
予算と要件のバランスで迷う場合は、この段階で一緒に整理する。何を優先すべきかの判断基準については開発会社が「正直、これをやめてくれると安くできる」に詳しく書いたので、事前に読んでおいてもらえると話がスムーズになる。
4. 実装・確認・バッファ
4-1. 実装
やること（チケット）を起票すると、AIが自動でコードを書いてPR（プルリクエスト）を出す。人間のエンジニアはそのPRをレビューし、設計の意図に沿っているか、保守できる構造になっているか、後から誰でも触れるコードになっているかを確認した上で取り込む。
コードを書くのはAI、判断するのは人間。
この分業によって実装速度は大幅に上がっている。ただし、速さを優先してレビューを省くことはしない。AIが出したコードは、動いているように見えても設計上の問題を抱えていることがある。そこを見落とすと、半年後・1年後に誰も触れないシステムになる。それを防ぐために、レビューの工程は絶対に省かない。
4-2. 毎週の定例MTG
実装期間中は、毎週定例MTGを設けている。
その場で実際に動いているものを一緒に確認してもらいながら進める。「途中で何をやっているかわからない」という状態にならないよう、完成に向けて少しずつ積み上げていくイメージだ。気になる点があれば、その場で都度確認してほしい。
4-3. バッファ対応期間
実装が一通り完了したら、一定期間のバッファ対応期間を設ける。
開発を進める中で、当初の要件からは外れるが「ここだけ少し変えたい」「この部分を追加したい」という軽微な要望が出てくることは珍しくない。このバッファ期間を設けることで、そういった変更にもスムーズに対応できる。大きな仕様変更には対応できないが、軽微な調整であればこの期間内で吸収する。これによってリリースを早め、余計な工数や費用が発生しないようにしている。
5. テスト
機能が仕様通りに動くか、意図しない挙動が発生していないかを確認する。AIが生成したコードは、特定の条件下で想定外の動作をするケースがある。そのため、テストは以前より丁寧に、時間をかけて実施している。
6. リリース
テストが完了したらリリースを行う。
なお、うちは過剰なインフラ構成を作らない方針をとっている。必要十分な構成を選ぶことで、ランニングコストを大幅に抑えることができる。他社と比べてインフラコストが80〜90%削減できるケースもある。初期開発費だけでなく、リリース後のランニングコストまで含めて考えることが、長期的なコスト管理において重要だと思っている。
7. リリース後——ここからが本番だと思っている
リリースはゴールではない。うちはリリース後をスタートラインだと考えている。
どれだけ丁寧に作っても、使われなければ意味がない。使われてわかることがある。数字を見てわかることがある。作ったシステムで事業を伸ばすことが本来の目的のはずだ。そのためには、リリース後にPDCAを速く回せる体制を作ることが重要だと思っている。
うちでは運用契約を強く勧めている。数字を見ながら「次に何を作るか」「何を改善するか」を一緒に考え、定例MTGで進捗を確認しながら改修や機能追加を積み重ねていく。「試してみてダメだったら戻す」「ユーザーの反応を見て次を決める」——そういうサイクルを速く回すことが、事業が伸びるかどうかに直結する。実装はAIが担うため、小さな改修であれば比較的速く動ける。リリースして終わりではなく、一緒に走り続けることがうちの仕事だと思っている。
よく「保守と運用って何が違うんですか」と聞かれる。
保守は、システムを正常に動き続けさせるためのケアだ。サーバーやアプリケーションの死活監視、パフォーマンスの監視、セキュリティのためのバージョンアップ対応——いわば、作ったものを守る契約だ。運用は、そこに「事業を伸ばすための改修・機能追加・意思決定の伴走」が加わる。
保守契約なしという選択肢もある。自社にエンジニアを抱えていて、監視や運用を自分たちで回せる場合はそれで十分だ。その場合でも、納品から1年間は不具合を無償で対応する。品質には自信を持って納品しているので、安心してほしい。※詳細は契約による。
読んでいただいた方へ
このフローが、発注前の判断材料になれば幸いだ。
透明性を持って仕事をすることが、長く信頼される開発会社の条件だと思っている。だからこそ、良いことも悪いことも含めて、全部見せることにしている。
