はじめに
こんにちは。データプラットフォーム部（DP部）の石井です。
マーケティング部門から異動し、社内データ活用プラットフォーム「Pochi」のアプリ開発に携わっています。
本記事では、「利用者から開発者へ歩みを変えたことで初めて見えた“使いやすさの構造」” その課題を、組織としてどう“仕組み化”し改善していったのか、という、利用者視点 × 開発者視点 × 組織改善 の3軸を一気通貫でお伝えします。
社内データ活用プラットフォームPochi※1とは
私たちDP部は社内のデータ民主化を目指し、StreamlitとGoogle Cloudで圧倒的に使いやすいデータ活用プラットフォームPochi※1を開発・推進しています。 このプラットフォームは24年度に30万時間もの業務効率化を実現し、直近では5,000人以上の社員に利用が拡大しています。
ASCII.jp：NTTドコモ、Streamlit利用の“ポチポチ分析アプリ”開発で社内データ活用を促進 (1/3)
※1: Pochiは社内の開発コードネームです
こんな人に読んでほしい
- アプリ／システム開発にこれから携わる方
- 利用者から開発サイドに異動（兼任）する方
- UI/UX改善に課題を感じている現場リーダーや企画担当者
利用者視点 × 開発者視点の両軸で、伝わりづらい“使いにくさ”の背景や改善の糸口を整理しています。
この記事の要約
前半では、利用者としての「不思議」と、開発者の「当たり前」について改めて言語化を試みます。
その結果、UIのばらつきは“人・技術・開発体制”の構造的な問題があると考えました。
使いにくさは言語化されにくいので、利用者と開発者の視点の差があるのでズレが生まれていきます。
そのため、業務上重要な機能に比べて優先度が低くなり、反映されないことが多くなっていました。
後半では、その課題を解決するため、使いやすさを統一するためのガイドの作成に挑戦した内容を書きました。
しかし、いくつか失敗をしています。
“標準を押し付ける”のではなく“選びたくなる標準”が重要。それを考慮して最終的なアウトプットを作りました。
それにより、開発者の迷いが減り、ばらつきが抑制され、vibecodingにより標準の再利用を容易にすることができました。
第一部：利用者 → 開発者で見えた、“使いにくさ”が生まれる構造
業務現場の“あるある”使いにくさ
まず、現場でよくある、細かなストレスの例です。
- 初心者向けヘルプが常に表示されて邪魔
- 条件入力が毎回ゼロから
- ボタンの配置が近くて押し間違える
- 「保存」「登録」「実行」などの意味が不統一
- 使わない機能がロードを重くする
- 慣れによって改善意識が失われる
上記のような経験は私が利用者だったころ、よく感じていた事例です。 みなさんも普段使われているアプリなどでも似たような経験はないでしょうか。
一つ一つは小さい課題で、自分で開発しない立場。 私の場合、時間とともにそのままにしていきました。
開発者になって見えてきた“構造”
そして、開発する側に異動してきました。 最初に気になった点は、
「なぜUIがアプリごとに揃わないのか？」
「なぜ使いやすさの統一が難しいのか？」
という疑問です。 そこには、“構造的な問題”がありました。
● 主な構造要因
1. 各アプリで依頼者・開発者が異なる
例：依頼の流れ
- 依頼者A → 開発者B → データ抽出アプリ
- 依頼者C → 開発者D → データ抽出アプリ
→ 同じ「データ抽出アプリ」であっても、要件・優先順位・コンセプトが一致することはありません。
開発者同士は連携をとっても、依頼者同士は横のつながりがないことが多く、似た機能でもUI差分が生まれる構造になります。
2. MVP優先のアジャイル構造
例：開発の順番
1. 要件定義
2. 開発着手
3. 必要最小限の機能
4. 最短アプリリリース
→ “必要最小限の機能を最速で”が優先され、UI統一は後回しになりやすいです。
当然ですが、早くリリースしたほうが早く業務が改善されるからです。
3. 局所最適が積み上がる構造
例：アプリＡ
1. 要件定義
2. 開発着手
3. 必要最小限の機能
4. 最短アプリリリース
5. よく使う部分のUIを「繰り返し改修」
例：アプリＢ 1. 要件定義 1. 開発着手 1. 必要最小限の機能 1. 最短アプリリリース以降「そのまま」
→アプリ単位での最適化の積み重ねが、プラットフォーム全体の不統一につながるケースもありました。
4. Streamlitの技術特性
例：特性 * CSSを横断的に適用しない運用 * 見た目や挙動が異なるライブラリの自由度が高い * 各開発者の過去実績の“デフォルトUI”に依存する
→ 技術特性として、表現の選択肢はあるが、選択しなくてもよく、どちらも正解で決め難い。
そんな特性のため、同じUIに縛ることが難しいこともわかりました。
利用者・開発者の双方で重要なこと
構造的に問題があるので、利用者の「使いにくい」は届かない。 どうすれば届くのか考えました。
開発側は、特に「リピーター」といえるほど使っている方の意見は、 その数をKPIとしているにとって非常に重要でした。
しかしながら、届かない理由は、
小さな違和感を共有する情報が単純に足りていなかったことが問題でした。
● 小さな違和感のメモをとる
フォーマット例： * どこで不便を感じたか * 業務への影響 * 理想状態 * 優先度 * 共感の声
→作るつもりで見ると、このような情報がないと作れないことがわかります。
特に以下の点は重要です。
● 代案がなくても“不便”を率直に伝える
例：
NG「分かりづらいです」
良い例「保存と登録が同じ位置に並び、用途が判断しづらい」
→ただ、不便であることを聞いても、開発者は改善案を複数持っているので困ります。 作り手になった側は、利用者に対して、先に記入例を示すなどして、質問のラリーを減らすことができました。
● 開発側の“実装コスト”や制約を理解する
- 簡単に見えて実は重い対応もある
- 逆に「無理そう」に見えることが軽い工数で可能な場合もある
→ 開発側しかわからない情報は、利用者はイメージできません。
「複雑な修正」については、伝わる言葉に変換して、ご説明を心がけるようになりました。
また、開発者が「可能」と回答すると、利用者は「実装する」に聞こえるので、必ず、工数とセットで要否確認するように気を付けています。
こうした小さな積み重ねが、継続的なUI改善サイクルを生み出す土台になればと考えています。
第二部：構造的課題をどう解決したか──UI標準化の仕組み化
第一部で紹介した「UIが揃わない構造」を踏まえ、ここからは DP部が組織としてどう改善に取り組んだのかを紹介します。
開発者側になったことで、いくつか改善を試みました。
失敗も含め、事例をご紹介します。
解決アプローチの試行錯誤
◆ ① デザインガイドライン案（NG）
Pochiアプリのために「独自」のUIコンポーネントの用意し、開発者へ周知を検討しました。
- 全パターンを網羅できない
- 運用・浸透が難しい
- 現場の負担増で採用されない
→学習のポイントは、コンポーネントのメンテナンスと開発者への負担です。
この時点では、vibecodingは使われておらず、手動実装、手動反映を想定していたので、NGとなりました。
◆ ② Skillによる一括変更案（NG）
vibecodingのSkillという機能によって、開発者が作ったコンポーネントを強制的に統一する仕組みを検討しました。
- 適用後の見た目が予測困難
- 自動変更のBefore/After比較ができない
- Skill更新のメンテが重すぎる
→学習のポイントは、開発者の理解を得ないと浸透しないという点です。
また、HTML/CSS構造の前提が異なるUIを横断的に扱うには、運用面で限界がありました。
◆ 方針転換：「自然と使いやすいUIを選ぶ」仕組みへ
押し付けの標準化ではなく、
“選びたくなる標準”を整備することが最も現実的
という結論に至りました。
UIリファレンス集（比較ガイド）の構築
学習のポイントを加味して、vibecodingによりUIリファレンス集を作成することにしました。
以下の観点で、UIコンポーネントを体系的に整理・比較するコンテンツを用意しました。
● 比較軸（5段階の星取表）
- UIコンポーネントの網羅性
- デザイン性
- カスタマイズ性
- インタラクティブ性
- 導入のしやすさ
- 安定性
- Streamlit互換性
→どんな時にどのUI・グラフを使うべきか、そもそもどんなUI、グラフがあるのか、可能な限りの表現を網羅しました。
これにより、まず開発者に実用性を理解いただくよう説明をすることにしました。
● 実行結果の横並び比較
- グラフ・表などの描画例
- 操作感
- 実装コード例
→これにより、StreamlitのプレーンなUIと、ライブラリを利用したリッチな表現の比較ができるようにしました。
この画面は、開発者の表現のパターンを増やしたり、利用者との打ち合わせで使ったりすることを想定して作りました。
● vibecoding との連携
- “UI”の参照元として蓄積
- 実装難易度が下がり、プロンプトに迷わず実装できる環境を実現
→このUIコンポーネントをvibecodingに学習させて、自身の担当アプリに反映することで、かんたんに同じ表現を実装することができます。
おわりに
現場からは以下のような声を頂きました。
- 「ゼロからのUI設計が不要になった」
- 「依頼者との認識合わせが圧倒的に早くなった」
- 「迷ったらここを見ればOK、という共通言語ができた」
ばらつき防止と工数削減を実感することができました。
UIのパターンは50種類以上を実装していますが、まだ足りないと考えています。
今後の展望として、“人気UI・使いやすいUI”の特性を定量化し、コンテンツの拡充やおすすめ機能など継続的にアップデートしたいと考えています。
「使いやすい」は感覚的な話に見えますが、実際には “構造”と“仕組み” の影響が非常に大きいことがわかりました。
利用者が気づく小さな違和感、開発者が理解している技術的制約、組織として整える標準と仕組み。
それらが揃えて、もっと“みんなが使いやすい”状態が実現できるよう努めてまいります
本記事の内容が、同じ課題に向き合うチームのヒントになれば幸いです。
最後まで記事を読んでいただき、ありがとうございました。
