こんな課題ありませんか
- 現場から「使いにくい」と言われているが、どこをどう直せばいいのかが分からない
- システムに入力したあと、同じ数字をスプレッドシートにもう一度転記している
- 入力欄は増えたのに、半分は空欄のまま運用されている
- 操作方法を把握しているのが1人だけで、その人が休むと入力が止まる
- 見たい数字を出すのに、毎月手作業で集計している
- 作り直しの見積もりを受け取ったが、その金額が妥当かどうかを社内で判断できない
humbulls の特徴
受けない形を、先に伝えます
humbulls が進められるのは、いまその業務を回している担当者が確認の場に出られる案件です。システムの知識は要りませんが、手順を話せる人が誰も出られない場合は進みません。設計の見直しを含まず、画面のデザインと実装だけを引き受ける形も断っています。原因が画面の外にあるまま作り直すと、同じ問い合わせが残るからです。条件を先に出すのは、着手してから範囲を削り合う時間を減らすためです。
途中の版と、見積の内訳を見せます
humbulls は完成品だけを出す進め方をしません。見積は工程ごとに分けて出し、どの工程を落とすと何が手元に残らなくなるかまで書きます。設計中のモックは仮公開の URL に置き、直す前の版も消さずに残します。途中の判断が見えるので、着手したあとでも範囲を狭める相談ができます。
humbulls が手を動かし、AI を併走させます
工程を分業しません。業務フローを聞いた人が、画面のラベルを書き、モックをつくり、手順書まで書きます。画面設計もアプリ開発も代表が自分で手を動かしてきた領域なので、設計から実装までの間に引き継ぎが入りません。AI は調査の整理、モックの複数案出し、繰り返し作業のスクリプト化に使います。データの扱い方は要件に合わせて選べます（具体的な構成は、よくある質問に書いています）。
画面より先に決める5つのこと
業務システムの使いにくさは、画面の中だけで起きているわけではありません。humbulls が改善の相談を受けたときに、画面の話へ入る前に決めている5つを公開します。
その1 直さずに済む道を、先に3つ潰す
改善の相談は「この画面を直したい」という要望から始まります。要望のとおりに見積もると、改修の範囲は画面の数で決まります。ところが着手してから、その画面が使いにくい本当の理由は運用ルールにあった、という結論になることがあります。
使いにくさとして報告される作業の中には、画面を1ピクセルも触らずに消えるものが混ざっています。承認の順番を入れ替えれば無くなる差し戻し、既に持っている道具（スプレッドシート・グループウェア・HubSpot など）に寄せれば要らなくなる画面、そして誰も見ていないので入力をやめられる項目です。
最初の切り分けで、次の3つを順に潰します。①運用ルールの変更で消えるか ②既に契約している道具に寄せられるか ③そもそも入力・出力をやめられるか。3つを潰して残ったものだけを、画面の設計対象にします。この切り分けの結果は書面で渡すので、humbulls に発注しない判断もできます。
その2 入力の起点を、1か所に決める
転記作業が多いとき、対策は「転記しやすい画面にする」「CSV の書き出しを増やす」に向かいがちです。書き出しを増やすと、コピー元が増えるので、突き合わせの作業も増えます。
同じ数字が2か所で生まれている状態では、画面をどれだけ直しても照合の手間は残ります。転記は画面の問題ではありません。データの起点が2つある問題です。
業務フローを書き出して、数字ごとに「最初に生まれる場所」を1つに決めます。決めた起点以外の場所には、人が入力せず、自動で受け取ります。既存の道具を止めずに、並行運用へ寄せる進め方も取ります。
その3 入力項目は、出口の集計から逆算して決める
要件定義では「あったほうがいい項目」を現場からヒアリングして積み上げます。丁寧な進め方に見えますが、入力欄は増え続け、埋まらない欄が生まれます。欄が埋まらないレポートは信用されなくなり、現場は手元の Excel に戻ります。
入力項目の数と、業務の解像度は比例しません。決まるのは、その数字を毎月誰が見て、何を判断するかです。出口が決まっていない項目は、入力されないか、入力されても使われません。
設計の最初に「毎週・毎月、誰がどの数字を見て、何を決めるのか」を1枚に書きます。そこに登場しない項目は、入力欄から落とします。出口の側から先に組む方法は自社で実行していて、humbulls が自社サイトの Google アナリティクスと Search Console を統合して月次レポートを内製化したとき、同じ手順を別サイトで再現するのにかかったのは1週間でした。
その4 例外の逃がし先を、画面の状態として持たせる
設計はまず正常系から始めます。イレギュラーは「備考欄に書いてください」で運用に逃がします。運用でカバーする前提の設計は、短期的には作りやすく、合意も早く取れます。
現場が「この件は Excel で管理しています」と言うとき、対象はたいてい例外処理です。備考欄に書かれた情報は検索も集計もできないので、いずれ別の台帳が生まれます。二重帳簿は、正常系の画面をどれだけ磨いても消えません。
設計の段階で例外を先に洗い出し、テキストの備考ではなく、画面が扱える状態として持たせます。保留・差し戻し・特例承認のように、後から件数を数えられる形にします。例外が何件あるかを数えられると、次に自動化すべき場所が決まります。
その5 誰が直せる状態で終わるかを、着手前に決める
納品の議論は、機能とスケジュールに集中します。納品後の修正体制は「保守契約で対応します」で片付きます。
業務システムが使われなくなる理由は、作ったときの品質より、直せない体制にあることが多いです。選択肢を1つ足すだけで外注に戻り、返ってくるまで待つことになれば、現場は元のやり方に戻ります。
着手の時点で、担当者が自分で直せる範囲（ラベル・選択肢・レポートの並び・通知の文面）と、humbulls に戻す範囲を線で分けて書き出します。引き渡しでは手順書に加えて、繰り返し作業を再実行できる AI スキル（.md ファイル）を渡します。同じ作業を、担当者が自分で再実行できる状態にして終わります。
進め方
実際の進め方は前提を確認したうえで相談して決めますが、基本の形は次の6ステップです。
切り分け
相談で聞いた「使いにくい」を、原因の所在で分けます。運用ルールで消えるもの、既に契約している道具に寄せられるもの、画面の作り直しが要るものの3つに仕分けし、書面で渡します。ここで作り直しが不要という結論になることもあります。切り分けをせずに見積もると、消せたはずの作業まで作り直しの対象に入ります。
- 主な成果物: 切り分けメモ（対象と対象外の一覧）
業務の棚卸し
誰がいつ何を入力し、その数字を誰が見ているかを書き出します。担当者への確認と、実際の画面・シート・帳票の現物確認を並行します。数字ごとに最初に生まれる場所を特定し、二重に生まれている箇所に印を付けます。ここを飛ばすと、画面の並びが業務の順番と食い違ったまま設計が進みます。
- 主な成果物: 業務フロー図（現状）／数字の起点の一覧
設計
入力の起点、数字の出口、用語、例外の扱い、権限の5つを決めてから、画面の構成を決めます。用語はシステム上の名前と現場の呼び名を突き合わせ、1つに寄せて一覧にします。例外は洗い出して、画面が扱う状態として定義します。この順で決めないと、画面ができたあとに用語の議論が始まり、作り直しになります。
- 主な成果物: 画面構成／用語表／出口レポートの定義1枚
モックで合意
仕様書だけで合意せず、触れるモックを出します。モックは仮公開の URL で渡すので、現場の担当者が自分の端末で操作できます。実際に使ってもらったうえで直し、直した版も URL に残します。作成には AI を使うので、捨てる前提で複数案を出せます。
- 主な成果物: 動くモック（仮公開 URL・工程ごとの版）
実装 または 引き渡し
実装を humbulls が担当するのか、設計とモックを渡して顧客側の開発会社・情シスに引き継ぐのかは、契約の時点で決めます。引き継ぐ場合は、開発側が読める粒度の指示書を作ります。
- 主な成果物: 稼働するシステム／または開発指示書
定着と引き渡し
操作手順書と運用ルールを渡し、担当者が自分で直せる範囲を線引きして共有します。繰り返し発生する作業は AI スキル（.md）にして渡し、その場で一度実行してもらいます。引き渡し後にどこまで humbulls に戻すかも、同じ紙に書きます。
- 主な成果物: 操作手順書／運用ルール／AI スキル（.md）／直せる範囲の線引き表
成果物
進め方の各ステップで、次のものが手元に残ります。
| # | 成果物 | 中身 |
|---|---|---|
| 1 | 切り分けメモ | 運用で消せるもの／道具に寄せられるもの／作り直しが要るものの仕分け |
| 2 | 業務フロー図 | 誰がいつ何を入力し、どの数字が二重に生まれているか |
| 3 | 用語表 | システム上の名前と現場の呼び名の対応。画面より先に固定する |
| 4 | 出口レポート1枚 | 毎週・毎月、誰がどの数字を見て何を決めるかの定義 |
| 5 | 動くモック | 触れる仮公開 URL。工程ごとの版が残る |
| 6 | 操作手順書と AI スキル（.md） | 担当者が同じ作業を自分で再実行できる状態 |
無料相談
まず、いまの画面を見せてください 相談は60分。直すべきなのが画面なのか、運用ルールなのか、そもそも別の道具に寄せる話なのかを、その場で切り分けます。売り込みはしません。フォームからのご連絡には3営業日以内に返信します。
関連ナレッジ
業務システムまわりで humbulls が実際に使っている手順は、記事で公開しています。
FAQ・価格・完了後の道
費用の目安
範囲によって大きく変わるので一言では答えられませんが、考え方は先に出します。
予算が決まっている場合は、その範囲でできることを切り出して提案します。
工程ごとの内訳
| 工程 | 内容 |
|---|---|
| 切り分け・棚卸し | 業務フローの整理、直さずに済む道の仕分け |
| 設計・モック | 画面構成、用語表、出口レポート定義、動くモック |
| 実装 または 引き渡し | 実装、または開発指示書の作成と引き継ぎ |
工程を切り出しての依頼も受けます。切り分けだけ、設計とモックだけ、という形でも構いません。
よくある質問
費用はいくらくらいになりますか。
範囲で変わるため一言では答えられません。工程ごとの内訳は上の「費用の目安」に出しています。切り分けだけ、設計とモックだけ、といった形での依頼も受けるので、予算が決まっている場合は先に伝えてください。その範囲でできることを切り出して提案します。
着手から引き渡しまで、どのくらいかかりますか。
期間が決まる条件は、実装まで humbulls が担当するかどうかです。
いつごろ相談すればよいですか。
相談そのものはいつでも受け付けます。ただし同時に進める案件数には上限を置いているので、着手時期は相談のタイミングで前後します。忙しいから待ってもらうのではなく、1件あたりの手数を落とさないために上限を決めています。
実装まで頼めますか。それとも設計だけですか。
設計とモックまでを humbulls が担当し、実装は顧客側の開発会社または情報システム部門に引き継ぐ形にも対応します。引き継ぐ場合は、開発側が読める粒度の指示書を作ります。
いまのシステムを入れ替えずに、使い勝手だけ直せますか。
入れ替えを前提にしません。最初の切り分けで、運用ルールの変更で消えるか、既に契約している道具に寄せられるか、画面の作り直しが要るかを分けます。既存のシステムを止めずに、主となる道具はそのまま使い、別の道具に差分だけを流す進め方も取ります。
情報システム部門がなくても進められますか。
進められます。棚卸しで必要になるのは、いまの業務の手順です。システムの知識は要りません。実際にその業務を回している担当者に、確認の場へ入ってもらえれば足ります。逆に、業務を回している人が誰も出られない場合は進みません。
AI をどこまで使いますか。データは学習に使われませんか。
調査の整理、設計案の作成、モックの生成、繰り返し作業のスクリプト化に AI を使います。データの扱いは要件に合わせて選べます。機密度が高い場合は、顧客の生データを AI に渡さず、AI にはコードを書かせ、データの処理はそのコードが実行する構成にします。アカウントや保存先を顧客名義にする運用にも対応します。
設計は社内で終わっています。画面のデザインと実装だけを頼めますか。
この形では受けていません。使いにくさの原因が画面の外にあるまま作り直すと、同じ問い合わせがそのまま残ります。設計の見直しを含む形であれば受けます。
相見積もりのために提案書だけ作ってもらえますか。
提案書の作成のみの依頼は受けていません。humbulls が契約前に出せるのは、60分の相談と、着手できる時期の見通しと、見積書です。切り分けの結果を書面で渡すところからは、有償になります。
開発会社や代理店を経由しての依頼は可能ですか。
可能です。条件は1つで、業務を実際に回している発注企業の担当者と、humbulls が直接やりとりできることです。業務の手順を伝聞で受け取ると、切り分けの精度が落ちます。
完了後の道
引き渡しの時点で、担当者が自分で直せる範囲と、humbulls に戻す範囲を線で分けて書き出します。直せる範囲を広く取れるほど、運用は続きます。
担当者が AI を使って自分で手順や画面を直せる状態まで持っていきたい場合は、AI Mastery · 1on1（月30万円×3ヶ月）に接続できます。