SAP GUIのユーザメニューを作り慣れたコンサルタントが、SAP Fiori ラウンチパッドを設計するとき、最初に戸惑うのは「どのアプリを、どこまで画面に並べるか」ではないだろうか？
権限を付与したアプリを
全部タイルに並べておけばいいんじゃないの？
何を隠そう、筆者はそう考えていた。
しかし、SAPはFioriラウンチパッドのデザインガイドを公表しており、この考えは間違いのようだ。
SAPが目指すのは、利用可能なアプリの一覧をホーム画面に再現することではない。
仕事に必要な入口を、業務の文脈と作業の流れに沿って見せることである。
先に数値を示そう。SAPのデザインガイドが示す目安は以下だ。
- 1ページ： 2～5セクション
- 1セクション： 3～7アプリ
- 1ページ全体： 最大25アプリ程度
これらは画面の設計指針であり、システム上の上限ではない。
デザインガイドの一部には「1セクション2～7アプリ」という表記もあるため、数値を絶対視せず、対象製品・版の資料と実際の利用者を確認する必要がある。
SAP Fiori ラウンチパッドの基本構造：スペース、ページ、セクション、タイル
スペースは業務領域への入口
現在のスペース方式では、上部ナビゲーションの入口がスペースである。
スペースの中に一つ以上のページがあり、ページの中にセクション、その中にアプリを起動するタイルやリンクを置く。
SAPの説明を単純化すれば、次の四層だ。
| 階層 | 利用者から見た役割 | 売掛金業務を例にした名称 |
|---|---|---|
| スペース | どの業務領域で働くか | 売掛金 |
| ページ | その領域で何の仕事をするか | 入金確認と消込 |
| セクション | 関連する作業をどうまとめるか | 本日の確認、未消込の処理 |
| タイル／リンク | どのアプリを起動するか | 入金・未消込明細などの対象アプリ |
- 右列は説明用の設計例であり、SAPが指定する日本語の標準名称ではない。
SAPは、スペース名をビジネスロール名のコピーにせず、利用者に分かる業務領域名にするよう勧めている。
つまり、「会計」のような広すぎる名前より、「売掛金」のような具体的な仕事の言葉にせよということだ。
ページ名も「FI」「SD」といったSAPモジュール名・機能名ではなく、そこで行うタスクを要約する名前にする。
スペース名をページ名で繰り返すことも避けたい。
ページは「仕事のまとまり」
同じ売掛金担当者でも、朝の状況確認、入金処理、滞留債権のフォローでは、見る情報と使うアプリが異なる。
SAPは、複数の独立した作業文脈があるときにページを分ける考え方を示している。
ページを「入金確認と消込」「延滞債権の確認」のように分けておけば、ユーザは業務から機能名へ翻訳しなくても、自分が行う仕事から入口を選べる。
複数ページを横断する業務が必要なら、先頭に概要ページを設ける選択肢もある。
ただし、概要ページを全アプリの置き場にしては本末転倒だ。頻繁に確認する情報と主要な入口に絞り、各ページにはその作業文脈で必要なものを置く。SAPは各ページを、その文脈における「お気に入り」のような入口として説明している。
セクションは意味で束ねる
セクションは、ページ内のアプリを意味でまとめる単位だ。
SAPは、主要アプリをまとめる「Quick Access」、分析アプリをまとめる「Insights」を、ページ間の一貫性を高める名称として勧めている。
それ以外のセクションも、「照会系」「その他」のような雑多な分類より、そこで行う仕事が伝わる見出しにしたい。
セクション名自体は必須ではないが、見出しがないと内容を推測しにくい場合は付けた方がよい。
タイルはアプリの起動点
タイルは、アプリへの視覚的な入口であり、リンクも起動点として使える。
なお、タイルの枚数とアプリの数は常に同義ではない。SAPが定量ガイドで数えているのは「apps per section/page」である。
設計レビューでは、見た目のタイル数だけではなく、ページに並ぶアプリの数と、利用者が区別すべき選択肢の数を確認するのが安全だ。
セクション数・タイル数の目安は？
SAPのガイドラインにある数値
SAPのデザインガイドは、簡潔なページを目指すため、目安として以下の数値を推奨している。
- 1ページ： 2～5セクション
- 1セクション： 3～7アプリ
- 1ページ全体： 最大25アプリ程度
したがって、初期案を作るときは「ページを仕事のまとまりで分け、各ページは2～5セクション、各セクションは3～7アプリ程度」を作業仮説にするとよい。
ここで注意したいのは、各目安を独立した上限として足し算しないことだ。
5セクションそれぞれに7アプリを並べれば、ページ全体は35アプリになる。セクション単位では目安内に入っていても、ページ全体の「25アプリ程度」から外れる。
そんなときは、似た仕事をまとめ直す、独立した作業を別ページへ分ける、低頻度のアプリを初期表示から外す、という順で見直す。
一方、セクションにアプリが2つしかないからといって、必要のない3つ目を無理に補充する必要はない。
業務上まとまりが明確で、利用者が迷わないなら、目安から外れる理由を記録して採用すればよい。
なお、同じv1-148のデザインガイドでも、本文は「3～7」、後半のGuideline欄は「2～7」と表記が異なる。ここではSAP Helpとガイド本文が一致する「3～7」を中心的な目安として扱う。
「使える全アプリ」をページに置かない理由
SAP Helpは、ページにはロールとカタログに基づいてアクセス可能なすべてのアプリが表示されるわけではなく、管理者が利用可能にした一部が表示されると説明する。
SAPのデザインガイドも、日常業務で重要かつよく使うアプリに絞り、除外したアプリはApp Finderから探して直接起動、またはページに追加できるという設計を示す。
ただし、App Finderや個人化の提供・有効化は製品や設定に依存する。対象システムで使える経路を事前に確かめる必要がある。
ここには二つの異なる設計判断がある。
- 権限・カタログ： 「何を利用できるか」
- スペース・ページ： 「最初に何を見せるか」
スペース・ページを権限・カタログに準じた全件表示にしてしまうと、頻繁に使う仕事と年に数回しか使わない仕事が同じ優先度で並んでしまう。これでは、ページの目的である「今日の仕事を始める入口」がぼやけることになる。
実際の起動可否や業務データへのアクセスには、ターゲットマッピング、サービス、業務権限なども関わるため、ロールとページだけで権限制御を完結したと考えてはならない。
UI Content and Authorization Concept（SAP Help Portal）
少ないほどよいのか―― リーンページの意味
SAPはセクションもタイルも、「リーンページを目指す」としている。
ここでいう「リーンページ」とは、UX設計上の「絞り込まれた、簡潔なページ」という考え方である。
つまり、権限で付与されているすべてのアプリを1ページに詰め込むのではなく、ユーザにとって重要かつ利用頻度の高いアプリを選んで配置することを推奨している。
「リーンページ」は、単にアプリ数を減らす競争ではない。利用者にとって必要な入口が、適切な文脈に過不足なくまとまったページである。
たとえば日次で照会し、例外を判断し、処理へ進むなら、「状況を見る」「判断する」「処理する」という流れが画面から読み取れる配置が有効だ。
SAP Helpは、先に状況を把握してから必要なアクションへ進むInsight-to-Actionと、利用者の作業順を反映したページ構成を勧める。
性能面でも、動的なKPIタイルは最新値の取得に追加の呼び出しを伴うため、SAPは必要なものに絞るよう助言している。
ただし「25アプリを超えると何秒遅くなる」といった一律の閾値は存在しない。
表示速度はタイルの種類やシステム構成でも変わる。数値目安はレビューの基準として使い、実際の表示と操作を測って判断すればよい。
SAP GUIのユーザメニューとFioriラウンチパッドの違い
SAP GUIはメニューツリーから、Fioriは業務文脈から
SAP GUIのSAP Easy Accessでは、ユーザメニューが展開可能なツリーで表示される。
トランザクションやレポートなどをメニュー階層から探し、よく使うものはFavoritesに登録できる。トランザクションコード（T-CODE）を知っていれば、コマンドフィールドから直接起動する手段もある。
SAP公式はユーザメニューについて、日常業務に必要な項目を含むと説明している。したがって「SAP GUIは必ず全機能を表示し、Fioriだけが選抜する」という対比は正しくない。
設計上の違いは、何を主な手がかりにするかだ。
GUIのメニューツリーは機能を階層で保持しやすく、既知のT-CODEへ素早く到達できる。
一方、Fioriのスペースとページは、「売掛金の中で、いま入金を確認する」という業務文脈を先に示す。分析から処理までの入口を近くに置くこともできる。
以下は、SAPの機能説明をもとにした実務上の比較である。
| 観点 | SAP GUIのユーザメニュー | SAP Fiori ラウンチパッド |
|---|---|---|
| 主な入口 | 階層ツリー、Favorites、Tコード | スペース、ページ、セクション、タイル／リンク |
| 得意なこと | 広い機能群を階層で整理する。既知のコードに素早く到達する | 主要業務を最初の画面に示す。状況確認から処理までをつなぐ |
| 利用者の負担 | 階層やコードを知らないと、目的の項目を探しにくい場合がある | 重要なアプリが初期ページにないと、別の探索経路を理解する必要がある |
| 設計・保守上の負担 | 階層やロールメニューを維持する必要がある | 業務文脈、表示順、選抜基準、個人化を継続的に見直す必要がある |
| 端末・画面 | 既存GUI画面の使い方に依存する | ラウンチパッド自体はレスポンシブ。ただし起動先アプリの対応は別に確認する |
- 両方式の操作時間を測定したSAP公式の優劣判定ではない。
SAPのベテランコンサルタントにとって、T-CODEによる直接起動は強力だ。その習熟を無視してFioriのタイルだけを唯一の経路にすれば、かえって仕事が遅くなる可能性がある。
一方、新しい担当者にとっては、T-CODEやメニュー階層を覚える前に、自分の業務名から入口を見つけられることに価値がある。
旧来のSAP ERPからS/4HANAへの移行設計では、どちらの利用者が、どの業務で、何を手がかりに探しているかを観察する必要がある。
なお、以下の記事で紹介しているブラウザ拡張機能「Prodegic Quick Launcher」を導入すると、Fioriラウンチパッド上で、SAP GUI のコマンドフィールドからT-CODEを指定してアプリを起動する操作を再現できる。
既存のSAP GUIトランザクションもFioriに置ける
Fioriに移行するからといって、対象業務のすべてが最初からネイティブなFioriアプリになるとは限らない。
SAPは、SAP Easy Access側のアプリをFioriラウンチパッドへ統合する方法を提供している。
ただし、古い画面をタイルから起動できることと、その画面自体がFioriの操作性やモバイル対応を得ることは別だ。
対象トランザクション、起動方式、端末、認証、ナビゲーションを実機で検証する必要がある。
この点は、SAP GUI 経験者を巻き込む際の重要な説明材料になる。Fioriのメニュー設計は、SAP GUI を否定する作業ではない。利用者の業務に合った入口を再設計し、必要な既存画面を含めて一貫したナビゲーションをつくる作業だ。
スペースとページを業務から設計する実践手順
1．「その人の一日」からアプリ候補を集める
SAPのデザインガイドは”Day in a life of…（ある一日の業務）”というアプローチを示している。
”Day in a life of…（ある一日の業務）”アプローチ
「どのアプリが重要か」だけでなく、「どの頻度で使うか」「最初に何を見て、次に何をするか」「前後の作業に依存関係があるか」「日々確認する指標は何か」「独立した作業文脈はあるか」を確認する方法。
これを、画面共有を伴う業務観察や担当者への聞き取りに落とし込む。
実務では、アプリ一覧に「業務」「利用頻度」「使う順番」「代替経路」「利用者ロール」「端末」「例外時のみか」を付けると議論しやすい。
たとえば月末だけ使うアプリが重要でも、毎朝開くページの中央に常設すべきとは限らない。重要度と頻度は分けて記録する。どのアプリを初期表示にするかは、ユーザの実際の仕事で決める。
要件定義フェーズで 業務プロセスフロー を作成していれば、そこに 業務を遂行する利用者・利用する機能・利用する順序・利用頻度 などが書かれているはずなので、それを基準に設計する方法も有効だ。
2．スペースは業務領域、ページは独立した仕事で区切る
まず対象ロールに対応する業務領域を置き、その中の独立した作業文脈をページとして切る。
SAP Helpは導入初期の考え方として原則1ビジネスロールに1スペースを勧める一方、ロールの作り方に合わなければ、複数ロールでスペースを共有したり、1ロールに複数スペースを割り当てたりすることも認める。
また、関連するアプリ数に応じて1スペース当たり1～5ページを検討するとしている。
設計の出発点であり、一律の制限ではない。
名称を決める際は、PFCGロール名やFI/SDといった内部分類をそのまま表示名にしない。
ユーザに「ここで何をするか」を尋ね、その答えに近い語を選ぶ。同じ作業を複数部門が行うなら、ページの名称や配置を揃えることも重要だ。
SAPはロールをまたいだタイトルとレイアウトの一貫性、再利用できるページを勧めている。
Best Practices for Managing Spaces and Pages（SAP Help Portal）
3．セクションを作業順に並べ、タイル数を絞る
セクションは単なるアプリの箱ではない。仕事の順序や判断の流れを表す。
売掛金担当者向けのページであれば、たとえば「本日の状況確認」から「要対応の明細」「入金・消込処理」へ進む配置が考えられる。
これはSAPが示すInsight-to-Actionを応用した仮の設計例だ。実際のアプリ名と並び順は、対象システムと担当者の業務に合わせて決める。
| ページ案 | セクション案 | 選抜基準 |
|---|---|---|
| 入金確認と消込 | 本日の状況確認 | 朝に見て判断する指標・一覧 |
| 入金確認と消込 | 要対応の明細 | 例外を見つけるための主要アプリ |
| 入金確認と消込 | 入金・消込処理 | 判断後に高頻度で起動するアプリ |
| 延滞債権の確認 | 滞留状況、顧客フォロー | 独立した業務文脈に必要な入口 |
この例では1ページに3セクションを置いた。各セクションに機械的に7個ずつ並べる必要はない。
逆に、頻度の低いアプリまで入れてページ全体が25を超えるなら、配置の理由を問い直す。
例外業務でしか使わないアプリを初期表示から外す場合は、利用者がどこから起動できるかも同時に確認する。
4．カタログ・ロールと画面表示を別々に確認する
メニューの絵ができても、権限と起動先の確認は残る。実装では、必要なアプリがビジネスカタログに含まれるか、ロールに割り当てられるか、ページのタイルがその利用者に実際に現れるか、起動後に必要なデータが見えるかを別々に検証する。
ページにタイルを配置しても、対応するアプリの利用資格がない場合や端末条件に合わない場合には、利用者に表示されないことがある。
SAP提供のスペース／ページは、まず標準の出発点として評価する。自社業務に合わせて内容を変えるなら、SAP Helpは提供コンテンツをコピーしてから調整するよう案内している。
実際の管理ツールは導入形態で異なる。
- S/4HANA Cloud Public Edition
-
Manage Launchpad Spaces、Manage Launchpad Pages、Maintain Business Rolesなどを用いる。
- オンプレミス
-
Launchpad App Manager、Launchpad Content Manager、PFCGなども関わる。
具体的な操作手順は対象リリースのSAP Helpで照合する。
5．代表ユーザ＋実機で検証する
設計レビューは、管理者権限を持つテストユーザだけでは不十分だ。SAP Helpも、実際に近い条件でテストし、1ユーザへ過剰なロールを付けないよう助言している。
ロールを割り当てた代表ユーザでログインし、以下を確かめる。
- スペースとページがどう見えるか
- 非表示になるタイルはないか
- 必要なアプリを初期ページまたは別経路から見つけられるか
Best Practices for Managing Spaces and Pages（SAP Help Portal）
確認するときは、
- 「この画面を見て、最初に何を押すか」
- 「月末に使うアプリはどう探すか」
- 「分析から処理へ迷わず移れるか」
を業務シナリオで試す。
起動できないタイルがあれば権限・設定を調べ、見つけられないアプリがあれば名称と配置を直す。
ページが増えすぎたら、仕事の文脈の切り方を見直す。数字を満たしたことだけを合格条件にしない。
SAP Fiori ラウンチパッド設計で避けたい三つの誤解
誤解1：タイルを置けば、ユーザに権限が付く
タイルは起動の入口である。タイルの配置だけで、アプリや業務データへの権限が与えられるわけではない。
逆に、アクセス権を持つアプリをすべてページへ表示する必要もない。利用資格と初期表示を分けて設計・検証することが重要だ。
誤解2：推奨の25アプリはシステムの上限である
「25」は、SAPが簡潔なページを目指して示す設計上の目安だ。超えた瞬間にエラーになる技術的な上限という意味ではない。
また、25以内なら必ず使いやすいとも言えない。利用者が必要な入口を見つけられるか、セクションの意味が通るか、作業順に合うかを検証する必要がある。
誤解3：SAPUI5 1.75から数値ガイドは変わっていない
SAPのデザインガイドは、スペース方式がSAPUI5 1.75で従来のラウンチパッドホームページと並行して導入されたと説明する。しかし、それはセクション数やアプリ数の表記が1.75以来変化していないという証拠ではない。
実際、デザインガイド内にも3～7と2～7の表記差がある。SAP GUIのユーザメニューが廃止されたことを意味するものでもない。記事や設計書には、参照した製品・版と資料のURLを明記したい。
まとめ：SAP Fiori ラウンチパッドは業務から組み立てる
SAP Fiori ラウンチパッドのメニュー設計では、スペースを業務領域、ページを仕事のまとまり、セクションを関連する作業、タイル／リンクをアプリの入口として扱う。
SAP公式の数値は、1ページ2～5セクション、1セクション3～7アプリ、ページ全体25アプリ程度が実務上の出発点だ。
これらは権限の総量を制限する数字ではなく、利用者が最初に見る画面を簡潔にするための目安である。
SAP GUIのユーザメニューにも必要な項目を選ぶ考え方はある。Fioriで加わる重要な設計判断は、階層やT-CODEをそのままタイルへ置き換えることではなく、利用者の「最初に何を確認し、次に何をするか」という導線を、画面の構造に反映することだ。
権限でできる仕事と、ページで見せる仕事を分けて考え、代表ユーザの実際の業務で検証する。その繰り返しが、利用時に迷わないメニューにつながる。
コメント