← エピソード一覧に戻る Episode 190 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― モバイルは小さなデスクトップではない
タカシ
今日は SaaS デザインのモバイルワークフローです。スマホ対応というと、PC画面を小さくした話に見えますが、実務ではまったく違います。外出先でも仕事を止めないために、何を優先し、何を捨てるかを決める設計なんです。
ミカ
ありますよね。スマホでも開けるけど、結局見づらくて何も終わらない SaaS。対応はしているのに使われない。あれって機能不足というより、モバイルでやる仕事の想定がずれているってことなんでしょうか。現場ではそこが痛いです。
タカシ
その通りです。Slack はモバイル通知を、デスクトップをロックして1分後、あるいは操作停止から10分後に送るのを既定にしています。つまりスマホでは、全部読むより先に、今すぐ反応すべきことだけを拾う前提で設計しているわけです。
ミカ
なるほど。通知の設計だけでも、モバイルは情報量勝負じゃなくて優先順位勝負なんですね。机にいない時間のほうが多い人ほど、その数分の遅れが承認待ちや返信待ちとして積み上がっていきそうです。かなり怖いです。
Chapter 2 原則 ― どこでも全部ではなく、止めてはいけない仕事を終わらせる
タカシ
モバイルワークフローで優先すべきなのは、承認、確認、担当変更、メモ追記、証拠の取り込みのような短時間で価値が出る仕事です。片手操作、割り込み、通信不安定を前提に、画面数と入力文字数を減らしきることが経営判断になります。
ミカ
全部できることが正義じゃないんですね。むしろ、何をスマホで終わらせて、何をPCに戻すかを明確にするほうが親切そうです。ユーザーも、移動中に重たい設定変更までやりたいわけじゃないですもんね。その線引きが大事です。
タカシ
ええ。今回見た Shopify、Jira、Salesforce、HubSpot、ServiceNow は、どれもフル機能より優先タスクの圧縮に寄っています。モバイルは制約が多いぶん、どの業務が止まると事業インパクトが大きいかを、逆に鮮明にしてくれるんです。
ミカ
モバイル設計って、UI の話に見えて、実は業務優先順位の話なんですね。誰が、どんな場面で、何秒なら耐えられるのか。そこを雑にすると、現場では『後でやる』が増えて、そのまま仕事が止まりそうです。本当にありそうです。
Chapter 3 通知と承認 ― Slack、Jira、ServiceNowは滞留をどう減らすか
タカシ
Slack の Catch up は、未読の最新プレビューと件数を見せて、反応すべき会話から処理させます。長いチャンネルを全部たどらせるのではなく、一次判断を先に終わらせる。モバイルで重要なのは、閲覧時間より意思決定時間の短縮なんです。
ミカ
たしかにスマホで過去ログを全部追うのはつらいです。まず火事が起きているかだけ知りたい。そのあと必要なら PC で深掘りする。モバイルって、フル閲覧よりトリアージに振り切ったほうが現実的なんですね。この割り切りは大事です。
タカシ
Atlassian も近い発想です。Jira Mobile は指標確認、依頼受付、承認を前面に出し、Jira Service Management では SLA 違反をプッシュで知らせ、課題の担当変更や遷移を single swipe で済ませます。詰まりを解く操作だけを極端に速くしているんです。
ミカ
一回のスワイプでキュー処理できるのは大きいですね。現場のマネージャーって、移動中に細かい設定はしなくても、止まっている案件だけは動かしたい。そこに絞ると、モバイルの価値が急にはっきり見えてきます。納得感があります。
Chapter 4 現場入力とオフライン ― Salesforce、HubSpot、Shopifyの割り切り
タカシ
Salesforce はモバイルで CRM データへリアルタイムにアクセスでき、音声でアカウント要約や値引き承認まで進められます。さらにオフライン向けホーム画面も作れる。営業や現場担当が、机に戻る前に次の一手を打てるようにしているわけです。
ミカ
音声で承認まで進められるのは、かなり現場寄りですね。車移動や訪問の合間って、キーボード前提の操作は厳しいですし。モバイル最適化って画面の見た目より、入力手段の再設計まで含むんだなと分かります。これは大きいです。
タカシ
一方で HubSpot は、モバイルで取引先や商談を扱え、保存済みビューは最大5件まで表示できますが、ネット接続なしではレコードの作成や編集や閲覧はできないと明記しています。この割り切りは重要で、できないことを隠さないほうが運用事故は減ります。
ミカ
それは大事ですね。何でもできますと言われて、圏外で入力が消えたら一気に信用を失います。モバイルで本当に怖いのは機能不足より、境界が見えないことかもしれません。現場は曖昧さに弱いですからね。ここは重要です。
Chapter 5 まとめ ― モバイルは完結性より、滞留しない設計を持て
ミカ
今日の失敗パターンをまとめると、PC の構造をそのまま縮小する、通知を増やしすぎる、オフライン境界を曖昧にする、重い入力を強いる、必要な承認文脈を見せない、このあたりですね。全部、現場での後回しを増やす方向です。
タカシ
まずは役割ごとに、外出先で最優先の5タスクを書き出してください。そのうえで、承認、返信、担当変更、記録追加、状況確認の導線を見直す。モバイルの評価は DAU ではなく、持ち越し率や承認完了率で見るべきです。
ミカ
通知も全部オンではなく、即対応、まとめ確認、オフに分けて役割ごとに既定値を変えるべきですね。スマホで使われるかどうかは、派手な機能より、いま反応すべきことがちゃんと浮いて見えるかにかかっていそうです。
タカシ
その通りです。モバイルワークフローは、どこでも全部できることではなく、机から離れても仕事が滞留しないことを目指す設計です。皆さんの SaaS でも、まずは外出先で止めてはいけない仕事から見直してみてください。