ここだけの話
開発依頼ってしんどくないですか？
WEBシステムの開発会社を選ぶのって、正直かなり難しくないですか。
なぜなら、見積もり前の段階ではどの会社も良いことを言えるからです。
「なんでもできますよ！」
「似た案件の実績あります！」
そう言われると、安心してしまいますよね。
ただ私は、いわゆる“開発だけをしてきた人”ではありません。
これまで何度も、発注側（ディレクション側）の立場で開発会社とやり取りし、進行・調整・検修まで経験してきました。
その中で、依頼側としての「本当にしんどい瞬間」を何度も味わってきました。
依頼側として経験した苦い現実
打ち合わせの段階では順調でも、進み始めると想定外が積み重なることがあります。
できると言っていたのに、途中から「それは難しい」「想定外です」が増えていく
デザインが古く、いまのユーザーが安心して使える見た目にならない
仕様がズレたまま実装が進み、「思っていたのと違う」が後半で噴き出す
連絡や判断が遅れ、こちらの業務も止まっていく
そして、特に厳しかったのがここからです。
いちばん辛いのは、バグだらけの検修作業
これは本当に消耗します。
パッと触っただけでも不具合が何十個も出て、依頼側がスプレッドシート等にまとめて報告する。
ですが、こちらの意図や状況が開発側にうまく伝わらず、修正→確認→再発→説明…のループに入る。
その間、依頼側は疲弊していく。
「開発会社さんは、デバッグやチェックを本当にしているの？」と言いたくなるほど、つらい時はつらいです。
ただ、すでに開発を進めているので、引くに引けず良くなる気配のないシステムのバグ取りを進めないといけない。これは地獄です。
追加依頼の段階でつまずく
開発が難しい理由のひとつに、「担当者が変わることによる断絶」があります。
開発会社では人の入れ替わりが起こりやすく、担当が変わるたびに前提の共有が途切れ、追加依頼のたびに話が１から振り出しになってしまう。
連続で依頼を続けていれば大丈夫ですが、開発してもらったシステムで運用していて、半年〜１年後に追加機能が必要になり追加依頼を行うと、「今は開発担当者がいないので・・・」という返事が来たりします。
依頼には応じてもらえても、簡単な開発(内容の差し替え程度)でさえも高額な見積もりが来ることも。
そうなると追加依頼もしづらく、せっかく開発したシステムもアップデートを行えないオワコンシステムになるんです。
もちろんちゃんとした開発会社ではあり得ないことですが、実際の現場ではけっこうあるあるなんです・・・
だから私は、最初から
“ 依頼側が困らない作り方 ”
で進めます
こうした経験を踏まえて、私は「作れます」と言うだけの開発はしたくありません。
目指しているのは、「事業の課題を確実に解決でき、運用の現場がラクになる仕組み」です。もちろん追加開発も含めて長期的な目線で。
そのために、次のことを大切にしています。
1) できる・できないを、最初に線引きします
開発側が曖昧に「できます」と言って進めると、どちらも後から痛い目を見ます。
実現性・制約・代替案まで含めて、最初に現実的な設計へ落とし込みます。
できない場合は、できないと伝えたうえで別の手段を提案します。
要望・要件
実現性・制約の判定
現実的設計
代替案の提案
2) “仕様がズレない”ように、途中で何度も確認します
一発で完璧な仕様書を作るより、途中で小さく形にしてズレを早期に潰す方が確実です。
画面イメージ・導線・入力項目・権限・通知などを途中段階で確認し、「思っていたのと違う」を後半で起こさない進め方をします。
「ズレない」開発フロー
早期確認で手戻りをゼロにイメージを共有
早期に潰す
仕様を確定
3) 見た目も“今の基準”で整えます
システムは機能だけでなく、操作する画面の使いやすさ・安心感・信頼感が成果に直結します。
管理画面や入力フォーム、ユーザー画面まで「実務でストレスが出ない」設計を前提に、古さを感じさせないUIに仕上げます。
4) バグが出にくい運用を、最初から組み込みます
複雑なシステムになればなるほどバグはどうしても発生することがあります。
だからこそ重要なのは、バグ自体を減らし、出た時にすぐ潰せる形にしておくことです。
最低限のテスト観点を共有し、確認の抜け漏れを減らす。
不具合は「何が起きるか」だけでなく「再現手順」まで揃えて管理し、修正の精度を上げる。
修正・確認のやり取りがぐちゃぐちゃにならないよう、管理方法を統一する。
こうした“依頼側が疲弊しない進行”を、プロジェクトの中に組み込みます。
5) 中村が最初から最後まで責任を持って進めます
開発会社では担当者の入れ替わりによって、追加の開発依頼のたびに前提共有がやり直しになったり、「以前の話が通じない」ことでスピードや精度が落ちることがあります。
manmaruでは中村が窓口から要件整理、設計、実装、検修、運用改善まで一気貫通で担当します。
たとえ、開発から10年経っても中村が担当し続けます。
前提が途切れず、意思決定が速く、細かなニュアンスも継続して汲み取れるため、追加機能や改修もスムーズに進みます。