1. TOP
  2. サービス
  3. Webアプリ開発

開発・その他

Webアプリ開発

業務で使う Web アプリは、既製の SaaS で足りるのか、作るべきなのかの判断から始まります。タイプの切り分けからモックでの合意、開発、社内で直せる状態にしての引き渡しまで、一括で引き受ける humbulls にご相談ください。

解決できる課題

humbulls にご依頼いただくことで、次のような課題を解決できます。

  • 業務アプリを作りたいが、どこに依頼すればいいのかが分からない
  • 入力・転記・確認・報告の工程を、いまも人の手で回していて時間が取られている
  • 既製の SaaS で足りるのか、作るべきなのかの判断がつかない
  • 何を作ればいいのかが社内でまだ言葉になっておらず、要件として書き出せない
  • 過去に作ったアプリが使われなくなり、手作業に戻ってしまった
  • 作って終わりで、使い始めたあとの改善には対応してもらえなかった
  • コードやアカウントの名義が発注先のままで、あとから移せない

humbulls の特徴

01

すでに使っているツールを作り直さずに済む、着手前の工程の棚卸し

ご相談を受けて最初に行うのは、いま手でやっている工程を1行ずつ書き出す作業です。書き出した工程は、既製の SaaS で足りる範囲、いまあるツールの設定と連携で足りる範囲、作るしかない範囲の3つに分けます。この棚卸しは、無料相談の60分で扱う範囲です(進め方のステップ1)。

切り分けをせずに作り始めると、すでに契約しているツールの機能を作り直すことになります。作らずに済むと判断した場合は、そのようにお伝えします。

02

文字の要件書ではなく、触れるモックで合意する進め方

要件書の読み合わせだけでは合意しません。先に触れるモックを作り、実際にその業務をやっている方に使っていただいてから、作る範囲と作らない範囲を決めます。画面を見るまでは要件が言葉になりにくいためです。

方向の違う案を仮公開 URL で見比べながら決める進め方は、支援先の LP 案件で実際に回しています(2026年・支援先案件)。モックは捨てる前提で作るので、この段階では作り込みません。

03

担当が分かれない、設計から実装まで一貫した体制

画面を設計するのも、モックを作るのも、実装するのも、humbulls の代表自身の実務範囲です(UI/UX の画面設計、kintone を使った業務アプリ、iOS アプリの開発)。設計した人がそのまま画面を作るので、要件を書き起こして別の担当者に渡す工程が入りません。

窓口が分かれないぶん、途中で意図が薄まる場面も少なくなります。一方で、同時に進められる案件数には上限があります。

04

引き渡したあとに社内で直せる、運用ごと納品

動くものと一緒に、リポジトリ、環境構築とデプロイの手順、繰り返し作業を再現する AI スキル(.md)をお渡しします。humbulls ではこれを「運用ごと納品」と呼んでいます。

支援先の案件では、Claude / Codex のスキルを受け渡す形で納品し、ページの更新とバナー制作を社内でできる状態にしました(2026年・支援先案件)。これは LP 制作での実績で、アプリでの納品実績ではありません。お渡しするものの構成は、アプリでも同じにしています。

Webアプリ開発の3つのタイプ

Web アプリと一口に言っても、既製の SaaS を導入するのか、いまあるツールの設定と連携で済ませるのか、ゼロから開発するのかで、費用も運用の負担も大きく変わります。humbulls では、業務の性質と運用体制の組み合わせで、Web アプリ開発を3つのタイプに分けて考えています。最初の打ち合わせでは、これから作るものがどのタイプに当たるかを決めるところから始めます。

タイプ1 SaaS導入型

すでにある SaaS を導入し、設定と運用ルールで業務に合わせるタイプです。他社にも同じ形で存在する業務が対象になり、勤怠・経費・問い合わせ管理・アンケートの集計などが当たります。既製品では合わないと言われる理由が、画面の並び、項目の呼び方、承認の順番であることも少なくありません。その場合は、運用ルールを変えるほうが安く済みます。

humbulls では、その業務を自社の商品名や部署名を使わずに3行で説明できるかを最初に確かめます。書けたものは、同じことをやっている会社が他にもあるので、既製 SaaS の検討から始めます。合わない点は、機能・データ構造・運用ルールの3つに分けて書き出します。

タイプ2 既存ツール連携型

すでに契約しているツールの設定と、ツールとツールのあいだをつなぐ処理で済ませるタイプです。手作業が残っている場所は、ツールが足りないところではなく、ツールとツールのあいだであることが多くあります。CSV を書き出して別のシートに貼り付ける、通知メールを見て別の画面に入力し直す。この2つは、どちらのツールを入れ替えても残り、あいだをつないだときに消えます。

humbulls では工程を1行ずつ書き出し、人がやっている理由が「つながっていないから」の行だけを対象にします。判断が要る行、例外が多い行は人の手に残します。対象になった行は、既存ツールの設定(ワークフロー・自動送信・権限)と、あいだをつなぐ処理で片づくことが多く、新しい画面を作らずに済みます。画面が増えないので、操作を教える工程も、使われなくなったあとの後片づけも発生しません。

タイプ3 スクラッチ開発型

業務に合わせてゼロから開発するタイプです。作れば業務に完全に合ったものが手に入りますが、合うのは作った時点の業務です。業務のほうは変わっていきます。変わったときに誰も直せない状態だと、半年後には手作業の回避策が復活し、アプリと手作業が二重に残ることになります。

humbulls では、作ると決める条件を3つ置いています。①その工程が業務の中心にあり、なくならない ②データが自社にたまり続け、他の用途にも使う ③直す人か、直す手順が社内に残る。抜けやすいのは③です。humbulls は自社の月次 SEO レポートを、レポート系の SaaS を契約せずに内製しました。着手から1週間で再現できる状態になり、いまは毎月スキルの実行1回で作り直しています。直しているのも humbulls 自身です。

タイプを見分ける4つの問い

タイプは好みで選ぶものではないので、判定に使う材料を先に置きます。工程の棚卸しが終わった時点で、この4つに答えられる状態になります。

問い タイプ1 SaaS導入型 タイプ2 既存ツール連携型 タイプ3 スクラッチ開発型
その業務は、他社にも同じ形であるか ある ある 自社固有の形をしている
画面を毎日触る人は何人か 複数部署にまたがる 0人でも成立する 日常的に使う担当者がいる
データはどこにたまり続けるか ベンダー側にたまる いまのツールの中にたまる 自社にたまり、他の用途にも使う
半年後、誰が直すか ベンダーが直す 手順書があれば社内で直せる 直す人か手順が社内に残る必要がある

4つのうち3つ以上が同じ列に並んだら、それがそのタイプです。列がばらける場合は、まだ決める段階ではありません。進め方のステップ3(モック)で決めます。

humbulls が主に支援するタイプ

humbulls が開発まで引き受けているのは、タイプ2(既存ツール連携型)とタイプ3(スクラッチ開発型)です。タイプ1(SaaS導入型)と判定した場合は、そのようにお伝えして、開発は引き受けません。見る順番もタイプ1・2・3 の順で、タイプ3 から検討を始めることはしません。作らない提案をすれば humbulls の売上は減りますが、使われなくなったアプリを引き継ぐ仕事のほうが、双方にとって高くつきます。

4つの問いで列がばらけるご相談は珍しくありません。その場合は、言葉で議論を続けずにモックを作ります(進め方のステップ3)。触れるものを1つ出すと、「この画面は要らない」「ここは既存のツールでやっている」という判断が現場から出てきます。

プロジェクトの進め方

実際の進め方は、いま使っているツールと工程の状態を踏まえて決めていきますが、基本的には次の6ステップで進めています。ステップ1〜2 でタイプを判定し、決まらない場合はステップ3 のモックを使います。ステップ4以降は、タイプ3(スクラッチ開発型)を選んだ場合の工程です。

Webアプリ開発の基本進行プロセス
Webアプリ開発の基本進行プロセス
01

プロジェクト設計

最初に、進行の計画とやり取りの場を整えます。あわせて、いま何を手でやっているか、どの数字がどこに残るかを、工程ごとに1行ずつ書き出します。ここでは「アプリで何をしたいか」は伺いません。「いま何をしているか」だけを伺います。やりたいことから聞くと、すでにあるツールで足りる部分が話に出てこないためです。

主な成果物業務フロー図/手作業の工程リスト/自動化候補の一覧
所要無料相談60分
02

要求理解

4つの問いに答え、行き先をタイプ1・2・3 のどれかに決めます。タイプ3 になった場合も、作る範囲は工程の一部だけ、という結論になることがあります。判定を書面にしてお渡しするところまでが、この工程です。口頭で済ませると、あとから範囲が動いたときに、何をもとに決めたのかが残らないためです。

主な成果物タイプ判定シート(4つの問いと回答、行き先、根拠)
03

プロトタイピング

タイプが決まらない場合、または作る範囲の輪郭が定まらない場合に、触れるモックを作ります。実際にその業務をやっている方に使っていただき、要らない画面を削ります。モックは捨てる前提で作るので、この段階では作り込みません。

主な成果物動くモック(仮公開 URL)/触ったあとの指摘一覧
04

要件定義

モックと判定シートをもとに、作る範囲、作らない範囲、お渡しするもの、お渡ししないものを文書にして合意します。あわせて見積もりを出します。認証・決済・既存システムとの接続・想定同時利用者数をどこまで引き受けるかも、ここで範囲に書き込みます。作らない範囲を明記しないまま進めると、後半で追加の依頼が積み上がり、公開日が動きます。

主な成果物要件メモ(作る範囲と作らない範囲)/見積もり
05

開発とテスト

確定した範囲を実装し、実際の業務データに近い状態で動かして確認します。設計した人がそのまま実装まで担当するので、途中の引き継ぎで意図が薄まりません。テストの記録は残し、引き渡しのときに一緒にお渡しします。

主な成果物稼働するアプリ/リポジトリ/テストの記録
06

納品

環境構築とデプロイの手順、運用手順(誰が何をいつ実行するか)、繰り返し作業を再現する AI スキル(.md)をお渡しします。担当の方に手順どおり1回やっていただき、詰まったところを手順書に書き足してから終わります。手順書を渡すだけでは、社内で直せる状態になりません。

主な成果物手順書/運用手順/AI スキル(.md)/アカウントとリポジトリの移管

成果物

アプリ本体と一緒に、次のものをお渡しします。修正のたびに開発した会社へ発注する状態にしないための一式です。humbulls ではこれを「運用ごと納品」と呼んでいます。

実物

# 実物 内容
1 自社の月次 SEO レポート画面 レポート系の SaaS を契約せずに内製したレポートの一例
2 AI スキル(.md)と運用手順書の実物 引き渡しに含まれる手順書の一例(一部マスクしています)

納品物リスト

  • 手作業の工程リストと、タイプ判定シート
  • 動くモック(仮公開 URL)
  • 要件メモ(作る範囲と、作らない範囲)
  • 稼働するアプリとリポジトリ
  • 環境構築・デプロイの手順書と、運用手順
  • 繰り返し作業を再現する AI スキル(.md)

お問い合わせ

いま何を手で回しているかを工程ごとに伺い、3つのタイプのどれに当たるかをその場で切り分けます。作らずに済むと判断した場合は、そのようにお伝えします。相談は60分です。

相談内容は AI でその場で整理し、まとめた PDF をお渡しします。フォームからのご連絡には3営業日以内に返信します。

無料相談を予約する

関連ナレッジ

実績

このページに載せられる事例は、いまのところありません。

humbulls の代表には、kintone を使った業務アプリの開発、iOS アプリの開発、UI/UX の画面設計の実務経験があります。ただし社名・時期・規模・成果が記録として残っておらず、事例として出せる形になっていません。数字のない事例を並べるより、材料が揃ってからこのセクションを起こします。判断の材料になるよう、進め方と成果物はこのページで先に公開しています。

よくある質問

みなさまからよくいただく質問をまとめています。

費用はどのくらいかかりますか。

作る範囲によって大きく変わるため、金額を先に1つ出すことはしていません。代わりに、費用の決まり方をお伝えします。確定した見積もりを出すのは、モックを見て範囲が決まったあと(進め方のステップ4)です。タイプ1・タイプ2 に落ち着いた場合は、開発費そのものが発生しないこともあります。SaaS の利用料とインフラの実費は見積もりに含めないので、金額をお伝えする前に内訳を共有します。

制作期間はどのくらいになりますか。

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

どのくらい前までに依頼する必要がありますか。

作るかどうかを決める前にご相談いただくのが、いちばん効きます。作ると決めたあとのご相談は見積もりを取る段階なので、タイプ1 と タイプ2 が検討対象から外れています。着手できる時期については、同時に進める案件数に上限を置いているため、問い合わせのタイミングによります。埋まっている場合は、着手できる時期をその場でお伝えします。

要件が固まっていない状態でも相談できますか。

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

設計と開発の切り分けはどのように行いますか。

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

タイプの判定だけをお願いすることもできますか。

できます。タイプの判定までは無料相談60分の範囲で、判定シート(4つの問いと回答、行き先、根拠)をお渡しします。そのまま社内で検討していただいても、別の開発会社にご依頼いただいてもかまいません。

すでにある社内システムの改修や、引き継ぎもお願いできますか。

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

納品後の保守はどうなりますか。

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

引き渡しのあとに、月額の費用はかかりますか。

このメニューの範囲は引き渡しまでで、必須の月額費用はありません。引き渡しが終わった時点でプロジェクトを閉じ、手順書と AI スキルで社内で運用していただく形が基本です。担当の方が自分で直せる状態を作るところまで伴走する場合は、AI Mastery · 1on1(月30万円 × 3ヶ月)に接続できます。アプリで取得したデータをマーケティングに使う段階に入る場合は、伴走プランの Growth Partner(月額30万円〜 / 最低3ヶ月)に接続できます。用途が限定されるため、汎用の接続先にはしていません。

コードやアカウントは自社のものになりますか。

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

提案コンペに参加していただくことはできますか。

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

代理店や親会社が窓口になる案件でも進められますか。

進められます。条件は、発注元の企業と直接やりとりできることの1点です。伝言を経由する体制では、工程の棚卸しに必要な情報が届かず、タイプの判定を代理店側に預けることになります。

無料オンライン相談会

オンラインで60分。売り込みはしません。現状をその場で AI と一緒に整理し、解決の道筋をまとめた PDF を当日お渡しします。開発をともなうご相談は、1週間以内に動くモックを無料でお見せする「モック相談会」もご用意しています(月5社まで)。

相談を予約する

お問い合わせ

お見積り・お仕事のご相談はフォームからどうぞ。担当より3営業日以内に返信します。判断に必要な情報はその場でお伝えします。よくある質問もあわせてご用意しています。

お問い合わせする

資料請求

サービス内容・実績・料金の目安をまとめた資料をご用意しています。社内での検討や上申にお使いいただけます。フォーム入力後、その場でダウンロードできます。

資料をダウンロード