実績・事例
お客様の社名・地域・数量など、事業者が特定できる情報は伏せています。 困っていたこと、どう決めたか、作ったもの、期間と体制、そして変わったことを書きました。 測っていないものは、測っていないと書いています。
出庫と在庫が紙と口頭で回っており、締めのたびに数が合わない。現場は手が濡れていて入力どころではない。
先に『何を減らすか』を決めた。記録の正確さより、現場が止まらないことを優先した。
現場で動画を撮ると、そこから出庫と在庫の記録が起きる社内システム。入力画面を増やさず、いつもの作業の順番のままにした。
変わったこと現場の入力作業を増やさずに記録が残る形まで到達。
紙をなくすのではなく、入力そのものを無くす方向で設計した例。
★削減時間は未測定。
会員向けの申請書類の下書き確認に時間がかかり、担当者ごとに指摘の粒度が違う。
AI に判断させず、観点の一覧を先に決めた。判断は人が持つ。
申請書の下書きを貼ると、観点ごとに指摘が返る添削の仕組み。担当者が違っても同じ観点で見られるようにした。
変わったこと複数の団体で運用中。
既にある道具の上に載せると、運用も引き継ぎも軽くなる。
★実機での通し確認まで完了。削減時間は未測定。
受注データを配送システム用に作り直す作業が毎日発生し、変換ミスが出ると再送になる。
『どこで間違えると事故になるか』を先に洗い、そこにだけ関所を置いた。
受注データを配送用に変換する仕組み。代金引換の扱いなど、間違えると事故になる条件を変換の手前で止める形にした。
変わったこと本番で運用中。
自動化の価値は速さより『事故を止める場所』にある。
★変換が丸ごと壊れる不具合（特定の漢字が原因）を実データから特定して修正済み。
サイトはあるが検索から見つからず、扱っている商品の幅も伝わっていない。
見た目より先に『何を探している人に、どのページで応えるか』を決めた。
扱いの幅が伝わる構成へ作り直し。ページを機械で生成し、内容と構造の食い違いを検査で落とす形にした。
作った後に崩れないよう、検査を先に用意した。
★公開ページ数が 2 から 27 へ（実測）。検索順位は継続観測中。
スマホでの表示が重く、写真が多いページほど離脱していた。
『重い原因』を推測せず、実データで測ってから直した。
画像の持ち方を見直して転送量を削減。よくある質問を構造化して検索側にも伝わる形にした。
速さは設計の結果であって、後から足す機能ではない。
★HTML の転送量を大幅に削減（実測）。表示の体感も改善。順位への影響は継続観測中。
小口の現金と起案の紙が回覧で滞り、誰がどこまで見たか分からない。
役割を 1 つ足して初めて見える穴があった。権限は後付けではなく設計に入れる。
小口現金と起案を画面で回す仕組み。誰がいつ何をしたかが残り、訂正できる人を役割で分けた。
電子化の失敗は機能不足より『誰が何をしてよいか』の曖昧さで起きる。
★実利用を開始。役割の追加で『読むだけの画面に関所が無い』経路を発見し塞いだ（設計時の実測）。
記事の外部配信が属人的で、どこへ何が出ているのか把握できていない。
作る前に『いま何が起きているか』を測った。結果、作らずに済んだ部分がある。
配信の経路を洗い出し、配信元と配信先の関係を可視化。運用の手順書に落とした。
実測すると『作らない』が答えになることがある。
★1 本の配信が 3 社へ同時に入っていた事実を実測で特定（把握できていなかった）。
予約と連絡が電話中心で、繁忙期に取りこぼしが出る。
使える上限を先に測り、上限に当たったときにどうするかまで決めてから配った。
メッセージアプリを入口にした受付と案内。運用できる範囲に機能を絞った。
止まったときの手当てまで設計に含める。
★運用中。★月あたりの配信通数に上限があることを運用中に実測し、上限に達した際の手当てを設計へ反映。
業務スクリプトの実行が遅く、待たされる時間が業務のリズムを崩していた。
『遅い気がする』を数字にしてから、移すかどうかを決めた。
実行環境を移す前に、どこで時間を使っているかを実測。移行先での構成を設計した。
移行の是非は、感覚ではなく計測で決める。
★遅さの原因が実行環境そのものであることを実測（数秒規模の待ち）。移行の判断材料になった。
DX の必要性は理解されても、投資の判断が自分ごとにならない。
『説明して分かる』ではなく『やって困る』を作ることにした。
経営の意思決定を体験する研修用のゲーム。投資と回収、人の動き、外部環境の変化を扱う。
腹落ちは説明ではなく体験から起きる。
★設計・検証の段階。★数値バランスは検証中で、完成品としての受入は未測定。
店の存在がインターネット上でほとんど見えず、問い合わせの入口も電話しかなかった。
サイトの見た目より先に、問い合わせが「どこから来るか」を決めた。
新しいサイトを制作し、相談の入口をメッセージアプリにも広げた。後に自前のドメインへ移し、旧の置き場所は残さず畳んだ。
引っ越しは、移した後に全部踏んで確かめるまでが作業。
★移行後に、入口・転送・画像・存在しないページの扱いまで通しで実測して確認（全項目が期待どおり）。問い合わせ件数への影響は未測定。
紙のスタンプラリーは集計に手間がかかり、参加店舗の負担も大きい。ただし店員に新しい操作を覚えてもらうのは難しい。
できることを足すのではなく、★現場に負担をかけない条件を先に置いた（店員の操作なし・位置情報なし）。
メッセージアプリで参加する回遊イベントの仕組み。★店舗は掲示物を貼るだけ、店員の操作は不要。位置情報も取らない設計にした。
防ぎきれない不正は「起きない」と書かず、見つけて止める運用まで含めて提案する。
★提案・要件定義の段階。実装も運用も行っていないため、効果は未測定。
通販システムの既製デザインのままで、スマホでの見え方が整わず、伝えたい特長も埋もれていた。
全部を作り替えず、★いちばん見られる 1 枚だけを先に直した。
入口となるページだけを作り直し、スマホでの読みやすさと、商品の特長が伝わる並びに変えた。
既製の仕組みの上でも、入口の 1 枚は作り替えられる。
★作り直したページを公開。売上や問い合わせへの影響は未測定。
POLICY
お客様の業務の中身は、その会社の競争力そのものです。「どこの会社が何に困っていたか」が 分かる形で出すことは、こちらの都合であって、お客様の利益にはなりません。 そのため、社名・地域・数量・時期など、事業者が特定できる情報は伏せています。
掲載しているのは、どんな困りごとに、どう手を付けたかです。 同じ業種でなくても、進め方はご覧いただけると思います。
削減時間や金額を書いていない事例があります。測っていないからです。 作った前後で時間を計測していない案件で、それらしい数字を出すことはしません。 計測を行った案件については、その旨と数字を記載します。
ご検討にあたって、より詳しい内容が必要な場合はご相談ください。 お客様の許諾が得られる範囲で、個別にご説明します。
「この case-01 に近い」といったご相談でも大丈夫です。 いまの業務のどこに時間が消えているかを一緒に洗い出し、進め方の見立てをお伝えします。