社内向けツールのUIを Google Stitch で作るのは、外向けサービスより難しかった

2026.04.12

「社内ツールのUIなんて、誰も文句言わないから適当でいい」——そんな空気が職場にあった。ユーザーは選択肢のない社員だから、使いにくくても使い続ける。外部サービスのように離脱される心配がない。だから後回しにされる。

でも、Google Stitch で社内ツールのUI改善に取り組んでみて、社内向けUIには外向けサービスにはない特有の難しさがあることが分かった。「誰も文句を言わない」ことが、むしろ一番の問題だったかもしれない。

結論から言うと

社内ツールのUIを Google Stitch で作る場合、外向けサービスとの最大の違いは「ユーザーの要求を引き出すこと自体が難しい」点だ。外向けサービスなら離脱・不満・レビューという形でフィードバックが来る。社内ツールは「使いにくいけど慣れた」「文句を言っても変わらない」という諦めが蔓延しており、真の要求が見えにくい。Stitch でビジュアルプロトタイプを作ることで、この「言語化できていなかった不満」を引き出す効果があった。

今回改善した社内ツールの概要

対象は、製造業の中規模企業で使われている社内の経費申請・承認システムだ。10年以上前に導入されたシステムで、UIは一切更新されていなかった。使っているのは全社員約200名で、月に1〜2回経費精算をする場面で使う。

システム自体を入れ替えるほどの予算はなく、「画面のUI部分だけを改善する」プロジェクトとして関わることになった。Stitch を使って改善案のビジュアルを作り、社内の合意形成と実装指示をすることが私の役割だった。

社内UIが抱えていた典型的な問題

既存システムのUIを分析すると、典型的な問題が複数あった。画面に詰め込まれた情報量、意味が分かりにくいボタンラベル（「F5で更新」「ESCでキャンセル」など）、モバイル非対応、エラーメッセージが英語のみ——これらは10年前のシステムとしては普通だが、今の感覚では確実に使いにくい。

ただし問題は「どこが使いにくいか」を社員から聞き出すことだった。「使いにくいですか？」と聞くと「まあ、慣れているので」という回答が返ってくる。不満を言語化する機会もなく、言っても変わらないという体験を繰り返してきたため、「不満を言う」という習慣自体がなかった。

Stitch を「不満の引き出しツール」として使う

Stitch で改善UIのモックを作り、現在のUIと並べて見せたとき、初めて社員から具体的な反応が出てきた。「あ、こっちの方が分かりやすい」「日本語でエラーが出るんですね、それだけで随分違う」「スマホで申請できると出張中に助かる」——比較対象が目の前にあることで、言語化できていなかった要求が出てきた。

Stitch の「素早く比較対象を作れる力」が、社内UIの改善プロセスで特に効いた。これは外向けサービスの設計では気づかなかった使い方だった。

社内ツールUIを Stitch で作る難しさ

社内ツールのUI設計で、Stitch を使いながら感じた特有の難しさを整理する。

「レガシーシステムとの制約」をプロンプトに入れることの難しさ

外向けサービスなら「こういうUIにしたい」というゴールを自由に設定できる。社内ツールの場合、既存システムの技術的な制約（データベースの構造・APIの仕様・画面の入力項目の固定）が存在する。「フルリデザインはできない、この項目はこの場所に必須、入力フォームのフィールドはここを変えられない」という制約の中でUIを改善するプロンプトを書くことは、自由なゼロイチ設計より難しかった。

対処法として、「制約を先にリスト化してからプロンプトに組み込む」方法が有効だった。「変えられる要素（色・フォント・余白・ラベルの言葉）」と「変えられない要素（入力項目の種類・順序・必須項目）」を明確に分けて、変えられる部分だけを Stitch で最適化するプロンプトを書いた。

「使う人が選べない」ことへの設計責任

外向けサービスのユーザーは、使いにくければ別のサービスに移れる。社内ツールのユーザーは逃げ場がない。毎日使わざるを得ない。この「選択肢がない」という状況は、設計側に大きな責任を生む。

「まあ、慣れるでしょ」では済まない。経費申請を毎月繰り返す社員にとって、1分の時間短縮が年間12分以上の節約になる。200人の社員なら、1分の改善が年間200分、3分の改善なら年間600分——全社の生産性への影響は軽視できない。この責任を持ってUIを設計することが、社内ツールの設計では特に重要だと感じた。

「承認者・申請者・管理者」の3役割同時設計

経費申請システムには3つのユーザー役割があった。申請する社員、承認するマネージャー、集計・管理する経理担当者。それぞれの使い方が全く違い、同じシステムの中で3種類のUIニーズが存在する。Stitch でこれらを一つずつ設計するのは可能だが、「同じ画面の中で3役割がどう機能するか」を整合させる設計は、人間の判断が必要だった。

社内ツールUIのプロンプトで有効だった表現

社内ツール特有の要件をプロンプトに落とし込む際に効果的だった表現をまとめる。

「デジタルツールに不慣れな社員でも説明なしで操作できるUI、専門知識不要」
「月に数回しか使わないユーザーが毎回ゼロから操作を思い出せる構造、記憶に頼らないナビゲーション」
「操作ミスのリスクが高い項目（金額・日付）には確認ステップを設ける」
「完了・エラー・処理中の3状態を明確に区別し、ユーザーが処理の進行状況を常に把握できる」
「PCとスマートフォンの両方で使えるレスポンシブデザイン、出張中のモバイル入力を想定」

UI改善後の変化

Stitch で作った改善案を実装した後の変化を、3ヶ月後のアンケートで確認した。「以前より使いやすい」という回答が回答者の82%から得られた。具体的な変化として最も多かった声は「日本語でエラーが分かるようになった」「スマホで申請できる」「どこを見ればいいかが分かりやすくなった」の3点だった。

定量的には、経費申請1件にかかる平均時間が約4分から約2.5分に短縮した（自己申告ベース）。200名の社員が月1〜2回使うとすると、月間で400〜500件の申請が発生しており、1件あたり1.5分の短縮は月間約700〜750分の節約になる計算だ。

よくある質問（FAQ）

Q1. 社内ツールの改善に予算や承認が必要で進められない場合はどうすれば？

A. まず「現状の非効率コスト」を計算することをすすめます。社員の作業時間×人件費×月次発生回数という形で、現在の非効率による損失を金額で示すことで、改善の投資対効果が説明できます。Stitch で改善案のビジュアルを作り「見える改善」を示すことも、承認を得るための有力な材料になります。

Q2. 社内ユーザーからフィードバックを得る方法はありますか？

A. 「現在のUIと改善UIを並べて見せる比較法」が最も効果的でした。「使いにくいですか？」という抽象的な問いより、「こちらとこちら、どちらが分かりやすいですか？」という具体的な比較の方が、明確な反応を引き出せます。Stitch でたたき台を作り、比較対象を用意してから聞くことが社内UIフィードバック収集のコツです。

Q3. 社内ツールのUIに Google Stitch を使う際の最初のステップは？

A. 「最も使われる頻度が高い画面を1つ特定する」ことから始めることをすすめます。経費申請なら「申請入力フォーム」、勤怠管理なら「打刻・確認画面」など、日常的に触れる画面の改善が最もインパクトが大きく、社員に変化を実感してもらいやすいです。

Q4. レガシーシステムの制約がある場合、Stitch でどこまで改善できますか？

A. 「見た目とUXの改善」は大きくできます。入力項目の数や種類が固定されていても、色・フォント・余白・ラベルの言葉・エラーメッセージの表現・操作の流れの説明——これらは技術的な制約に縛られにくい部分です。Stitch で「変えられる部分の改善案」を作ることで、制約の中でも体感的な使いやすさを大幅に向上できます。

Q5. 社内UIの改善は誰が主導すべきですか？

A. 「最もそのツールを使う人」が最も強い動機を持っているため、実際の使用者側から声を上げることが理想です。ただし決定権は多くの場合ITや管理部門にあるため、使用者の声を可視化して管理部門に届ける橋渡し役が必要です。Stitch で作ったビジュアルは、この「使用者の声を形にする」ための強力なツールになります。

Q6. 社内ツールのUIを Stitch で作る場合、セキュリティ面で注意することはありますか？

A. プロンプトに実際の社内データ（顧客情報・社員情報・機密業務情報）を含めないことが原則です。UIのプロトタイプを作る段階では、ダミーデータや匿名化したデータを使い、実際のデータをStitchに入力することは避けるべきです。社内のセキュリティポリシーでAIツールの使用制限がある場合は、事前に確認することを推奨します。