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