Webアプリ開発

作る範囲によって大きく変わるため、一律の金額はお答えできません。このメニューは特に振れ幅が大きく、3分岐が A や B に落ち着けば、開発費そのものが発生しないこともあります。見積もりを出すのは、モックを見て範囲が決まったあと（進め方のステップ4）です。それより前の段階で金額を出すと、あとから動きます。

範囲が決まるまでの工程は、相談と工程の棚卸し（無料相談60分）、3分岐の判定、モックの提示までです。実装以降の期間は、範囲が決まってから見積もりと一緒にお伝えします。開発工程の日数が記録として残っていないため、現時点で全体の期間は書けません。根拠のない期間を先に出さない、というのが humbulls の方針です。

「アプリを作るかどうか」を決める前に相談してもらうのが、いちばん効きます。作ると決めたあとの相談は、見積もりを取る段階なので、分岐A と B が検討対象から外れています。決める前であれば、作らずに済ませる選択肢が残ります。

固まっていない前提で始めます。相談ではまず、いま手でやっている工程を確認し、作るべき範囲と、既存ツールの設定で足りる範囲を分けます（進め方のステップ1〜2）。要件が固まっているという状態は、たいてい「作る」と決めた後の状態なので、そこから相談が始まると分岐A と B を見ないまま進むことになります。

モックの作成と、作る範囲・作らない範囲の確定は引き受けます。実装も、画面設計から humbulls の代表自身の実務範囲です（UI/UX の画面設計、kintone を使った業務アプリ、iOS アプリの開発）。認証・決済・既存システムとの接続・想定利用者数の上限をどこまで引き受けるかは、モックを見たあとの「範囲と要件の確定」で1件ずつ決めます。

方針としては、リポジトリ・アカウント・データは発注側の名義で持つ形にします。乗り換えられる状態を保つのが前提です。

24時間の稼働監視や、復旧時間を保証する保守契約は結んでいません。humbulls は少人数の体制で、止まったら即座に駆けつける約束ができないためです。その代わりに、社内で直せる状態にして渡します（進め方のステップ6）。業務が止まると即座に損失が出るシステムで、復旧時間の保証が要件に入っている場合は、その要件を満たせる開発会社に依頼してください。判断に必要であれば、要件の整理と選定の観点までは相談に乗ります。

既存システムを引き継いで保守する形は受けていません。書いた人がいない状態のコードを引き取ると、直すたびに影響範囲の調査から始まることになり、humbulls の速度が出ないためです。既存システムに触れずに、あいだをつなぐ処理を足す形（分岐B）であれば引き受けられます。

相見積もりのための見積書だけの依頼は受けていません。3分岐を判定しないまま金額を出すと、作る前提の金額しか出せず、その数字が判断材料として使われてしまうためです。営業の段階でお渡しできるのは、進め方の資料、概算のスケジュール、範囲を決めたあとの見積もりまでです。

同時に進める案件数に上限を置いています。モックを先に出す進め方をとる以上、受注量より着手時期の確実性を優先するためです。埋まっている場合は、着手できる時期をその場でお伝えします。