アプリケーションの見直し
ここでは、業務での利用を前提として、画面遷移やアクセス方法が適切かどうかを確認します。また、検証時の都合で簡略化された構成が残っていないか、ケース別に見直します。
ユーザ利用を想定した動作確認
検証用として作成したルーティングは、基本的な画面遷移の骨格のみを示しており、操作手順の理解を前提とした設計や、想定外の操作・再実行への対応が含まれていない場合があります。公開にあたっては、ルーティングの骨格は維持しつつ、異常系の処理、戻り先、再操作時の挙動などが業務ルールに適合しているかを改めて確認してください。
| 観点 | 検証時によくある状態 | 公開時に確認すべき点 |
|---|---|---|
| (1) 開始画面・入口の安全性 |
|
|
| (2) 異常系や戻り先の扱い |
|
|
| (3) 検証都合の画面遷移 |
|
|
| (4) 複数パターンの業務への対応 |
|
|
ケース別のチェックポイント
確認すべき点があれば、該当するページを参照し、必要に応じて修正してください。
(1) 開始画面・入口の安全性
ユーザ環境では、ポータルの業務メニューなどの導線からアプリケーションを起動することを前提とします。そのため、ユーザがURLを直接指定してアクセスした場合でも、業務上、想定していない画面や処理が実行されないよう、開始画面や遷移条件が適切に制御されているかを確認します。
運用時、ブックマークや履歴、メールで共有されたURLなどから、画面が直接開かれるケースが必ず発生します。そのため、想定外のURLアクセスを前提とした制御が必要となります。これにより、業務事故の防止、問い合わせの削減、セキュリティ向上につなげることができます。
直接URLアクセスを想定した動作確認
実際の環境では、ユーザが正しい業務フローを通らず、ブラウザのアドレスバーにURLを直接入力して画面へアクセスする可能性が考えられます。そのため、想定外の画面遷移や不整合な状態に入らないよう、事前に確認と制御を行っておく必要があります。
確認ポイント：
- (1) URLを直接指定して、ユーザがアクセスできてしまわないか
- (2) 業務上、必要な前提条件が満たされているか
- (3) 想定外のアクセスが発生した場合でも適切な画面に遷移できるか
操作手順
- Webブラウザのアドレスバーに、対象画面のURLを直接貼り付けて、アクセスを確認します。
- 入力画面：登録・編集画面
- 確認ダイアログ：登録・編集後に確認ダイアログが表示
- 完了画面：登録・編集後に、一覧画面に戻る
→業務上、画面の表示や遷移が問題ないかを検証してください。
- 画面表示時やロジック開始時に、以下の前提条件を満たしているかを確認します。
- ユーザがログイン済みであるか
- 必要なパラメータがすべて揃っているか
- 正しい業務フローを経由して遷移しているか
- セッション値
- ステータス情報
参考正しい業務フローを経由して画面に遷移しているかどうかは、デバッグ機能のログを確認することで、間接的に検証できます。詳細は「アプリケーションのデバッグ」を参照してください。ただし、URLの直接指定か、画面操作による遷移かをデバッグ機能だけでは判別できません。業務フローを通過した証跡となるセッション値やステータスを保持し、画面初期表示時のロジックで判定してください。
コラムintra-mart Accel Platformでは、原則として、ユーザはログイン済みの状態で画面にアクセスします。ただし、以下のケースでは、業務フロー上の前提条件が満たされていない状態で画面が表示される可能性があります。
- セッション切れ
- 長時間放置後の再アクセス
- 別タブ・別ウィンドウからの直接URLアクセス
- 認可設定の変更直後
そのため、ログイン済みであることを前提としつつ、セッションの有効性や業務フロー上の前提条件が満たされているかを確認してください。
- 前提条件を満たしていない場合、業務上、適切な画面に遷移させるように修正します。
- 未ログインの場合：ログイン画面に遷移
- 必要なパラメータが不足している場合：一覧画面
- 不正な業務フロー：業務アプリのトップ画面
→想定外のアクセスが発生した場合でも、ユーザが業務を継続できる画面遷移となるように設計してください。
参考ルーティングを変更する必要がある場合は、「公開URLの確認と修正」を参照してください。
判断基準
上記の操作確認を行った上で、次の点を満たしているかを確認してください。
- ✓確認画面や完了画面を、直接URLで指定しても表示されないこと
- ✓正しい業務手順を経由しない場合、次の画面へ遷移できないこと
- ✓想定外の操作やアクセスが発生した場合でも、必ず業務的に安全な画面へ遷移すること
ここまで問題がなければ、次の確認ポイントに進んでください。
ポータルのメニューを起点とした画面遷移
業務用アプリをポータルのメニュー一覧に登録し、ユーザが迷わずアクセスできるように設定します。メニューに登録することで、直接URLを知らなくても、日常業務の導線からアプリを利用できるようになります。ここでは、メニューからアクセスした際に、想定通りの画面が表示されるかを確認します。
確認ポイント：
- (1) メニューに設定された内容が正しいか
- (2) メニューから起動した初期画面が業務ルールに沿っているか
- (3) ユーザのロールによって、表示される画面や遷移先が適切に制御されているか
操作手順
- アプリケーションをポータルのメニュー一覧に登録し、認可設定を行います。
参考
- ポータルのメニュー一覧にアプリケーションを追加する方法については、「ポータルのメニュー設定」を参照してください。
- アプリケーションをユーザが利用できるようにするため、認可設定を変更する必要があります。詳細は「アプリケーションの認可設定」を参照してください。
- ポータルのメニュー一覧からアプリケーションを起動し、以下の項目を確認します。
- リンク先のURLが正しく設定されているか
- 起動時に必要なパラメータが設定されているか
- 起動対象のロールが業務要件通りになっているか
→検証時に使用していた検証用URLや一時的なパラメータが残っていないかに注意してください。
- 起動後の初期画面が、業務ルールに沿っているかを確認します。
- 一覧画面から開始すべきか
- 新規入力画面（登録）から開始すべきか
- 業務の流れとして不自然な画面遷移になっていないか
→業務手順の通りに操作を開始できるかどうかを検証してください。
- ロール別に切り替えて、表示される画面や遷移先が適切に制御されているかを確認します。
- 一般ユーザ
- 管理者
→権限によってアクセス可能な画面が異なる場合は、特に注意してください。
参考intra-martの一般ユーザとは､ システムの設定やカスタマイズに関する権限を持たない通常のユーザを指します。また、intra-martの運用を担う管理者は､ 大きく分けてシステム管理者とテナント管理者の2つに分類されます。詳細は「intra-martの歩き方 - 管理者が最初に設定すること」を参照してください。
判断基準
上記の操作確認を行った上で、次の点を満たしているかを確認してください。
- ✓ポータルのメニュー一覧から、想定通りに業務を開始できること
- ✓URLを直接入力しなくても、業務が完結できること
- ✓権限別にアクセスした場合でも、適切な画面に誘導されること
ここまで問題がなければ、次の確認ポイントに進んでください。
(2) 異常系や戻り先の扱い
エラーや処理中断が発生した場合でも業務が混乱しないよう、業務ルールに基づいて遷移先を明確に定義し、二重登録や中途半端な状態を防止することが重要です。想定外の操作や再実行が行われても、常に正しい画面・正しい状態に誘導される設計になっているかを確認します。
検証時に問題がなかった挙動についても、運用を想定して異常系や戻り先の扱いまで含めて見直すことが大切です。そのためにも、「とりあえず動く」「戻れればよい」という考え方ではなく、業務ルールに基づいて戻り先や処理継続の可否を明確に定義しておきましょう。
業務ルールに基づく画面遷移先の定義
実際の運用環境では、エラーや処理の中断が発生した際に、単に「直前の画面へ戻す」だけでは、業務上、不適切な操作につながる場合があります。そのため、エラーの内容や発生箇所に応じて、業務ルールに沿った適切な画面へ遷移させ、そこから操作を再開できるように設計することが大切です。
あらかじめ「どのエラーが発生した場合に、どの画面から業務をやり直すのが正しいか」を明確に定義しておくことで、ユーザにとってわかりやすく、一貫性のある画面遷移を実現できます。
確認ポイント：
- (1) 想定されるエラー（入力エラー、登録エラー、システムエラー）を洗い出しているか
- (2) エラー種別ごとに、戻り先となる画面（入力画面や任意画面など）を明確に定義しているか
- (3) 「前の画面に戻る」といった曖昧な遷移に依存せず、遷移先を明示的に制御しているか
操作手順
- 想定されるエラーの発生パターンを書き出します。
- 入力チェックエラー
- 登録処理エラー（データベース・APIの連携失敗など）
- 画面遷移中の想定外エラー
- エラーの種別ごとに戻り先を定義します。
エラー種別 戻り先画面 業務上の理由 入力チェックエラー 入力画面 入力内容を修正すれば、処理を継続できるため 登録処理エラー 入力画面＋エラーメッセージ 再実行の可否を判断させるため 致命的なエラー 任意画面＋エラーメッセージ 処理を中断し、最初からやり直させるため
- 遷移先を明示的に制御します。
- 「前の画面に戻る」動作に依存しない
- エラー時の遷移先を、条件分岐やルーティングで明示的に設定する
参考
- IM-LogicDesignerによるロジックフローのエラーハンドリングでは、エラー発生時の処理継続可否と、エラー発生後の後続処理をどのように制御するかを設定できます。詳細は「IM-LogicDesigner チュートリアルガイド - 5.7. ロジックフローのエラーハンドリング」を参照してください。
- IM-LogicDesignerでロジックフローのエラーハンドリングを設定した後、IM-BloomMakerでアクションのエラーハンドリングを設定することで、ロジックフローのエラーメッセージを表示します。詳細は「Low-Code HANDBOOK - アクションのエラーハンドリング - IM-BloomMaker」を参照してください。
- ルーティングを変更する必要がある場合は、「公開URLの確認と修正」を参照してください。
判断基準
上記の操作確認を行った上で、次の点を満たしているかを確認してください。
- ✓画面遷移の理由を業務的に説明できること
- ✓業務担当者が見ても違和感のない画面遷移になっていること
- ✓同一のエラーに対して、常に同じ画面へ遷移すること
ここまで問題がなければ、次の確認ポイントに進んでください。
二重登録や中途半端な状態の防止
実際の運用環境では、登録処理において「登録が成功したかどうかが分からない状態」を発生させないことが重要です。失敗しているのに成功したように見えたり、成功しているのに再実行できてしまったりする状態を避けるため、登録処理の結果を明確に判別できるようにし、成功・失敗に応じて適切な画面遷移やメッセージを表示する設計にします。
確認ポイント：
- (1) 業務上、どこまで処理が完了すれば登録成功と判断できるか
- (2) 登録処理の結果に応じて、処理フローが分岐しているか
- (3) 登録状態と画面遷移が一致しているか
操作手順
- 登録処理における判定基準を明確にします。
- データベースへの登録が完了していること
- ステータス更新が完了していること
- 関連データの登録がすべて完了していること
→業務上、どこまで処理が完了すれば登録成功と判断できるかを事前に定義してください。
- 登録処理の結果に応じて、処理フローが分岐しているかを確認します。
- 成功時の処理フロー
- 失敗時の処理フロー
→同一の画面遷移や処理にしないように注意してください。
参考ロジックフローを確認・修正する場合は、「ロジックフローの修正」を参照してください。
- 同じ登録処理を再度実行し、挙動を確認します。
- 既存データが上書きされるか
- エラーとなり処理が中断されるか
- 何も処理されないか
→業務ルールに沿った正しい動作が実行されているかを確認してください。
- 登録状態と画面遷移が一致しているかを確認します。
登録状態 表示画面 操作可否 登録前 入力画面＋確認ダイアログ 登録操作が可能かどうか 登録成功後 完了画面（一覧）＋完了メッセージ 再登録が不可能な状態であるか 登録失敗後 入力画面＋エラーメッセージ 再登録操作が可能な状態であるか 参考画面遷移に関する基本的な方針については、「intra-mart Design System - 画面遷移」を参照してください。
判断基準
上記の操作確認を行った上で、次の点を満たしているかを確認してください。
- ✓同一の操作を複数回実行しても、データの不整合や破損が発生しないこと
- ✓登録済みのデータに対して、再登録処理を実行できないよう制御すること
- ✓現在の処理状態（未登録／登録済み／登録失敗など）を、画面表示だけで判別できること
ここまで問題がなければ、次の確認ポイントに進んでください。
(3) 検証都合の画面遷移
検証アプリでは、動作確認を優先するため、業務上の判断を伴う確認ステップを省略した画面遷移になっていることがあります。しかし業務用アプリでは、処理の確定や外部連携など、一度実行すると取り消しが難しい操作が含まれるケースも多く、ユーザが内容を確認し、判断した上で処理を進められる設計が必要です。
検証アプリは操作手順を理解しているユーザが使用することを前提としていますが、実際の環境では初めて利用するユーザも想定する必要があります。そのため、画面遷移や次に行うべき操作を明確にしておくことで、操作ミスや問い合わせの増加、業務上の事故を未然に防ぐことができます。
業務判断を伴う確認ステップの設計
実際の運用環境では、「そのまま処理を進めて問題ないか」をユーザ自身が判断できる確認ステップを設けることが重要です。検証用アプリの作成時では省略されてしまう確認・承認・最終判断の工程も、運用時には必要となるケースが考えられます。ここでは、誤操作や業務上の事故につながらないように、確認ステップを設計します。
確認ポイント：
- (1) 業務上、後戻りできない処理を洗い出しているか
- (2) 確認ダイアログにより、ユーザが操作内容を判断できるようになっているか
- (3) 確認ダイアログで、登録またはキャンセルを明確に選択できるようになっているか
操作手順
- 業務上、後戻りできない処理を洗い出します。
- 登録後に内容を修正できない処理
- 他システムへデータ連携される処理
→上記のような処理については、実行前に必ず確認ダイアログを設定してください。
- 確認ダイアログで可能な操作と意味を確認します。
操作 意味 登録・更新 入力内容を確定し、登録・更新処理を実行する 削除 表示内容をもとに削除処理を実行する キャンセル 入力画面に戻り、内容を修正する 参考トランザクションが発生する処理を行う場合は、確認ダイアログを利用してユーザに確認を促します。詳細は「intra-mart Design System - 画面遷移」を参照してください。
- コンテンツ種別を確認し、確認ダイアログを設定します。
- Bulma／Bulma Theme Coloredの場合：標準仕様の確認ダイアログがあらかじめ設定されています。
- imui／imdsの場合：アクションアイテム「メッセージ○をダイアログで表示する」を設定してください。
参考コンテンツ種別がimuiまたはimdsの場合は、アクションアイテムを設定し、メッセージの表示方法（アラート・確認・エラー）を指定します。詳細は「IM-BloomMakerのアクション > アクションアイテム - メッセージ表示」を参照してください。
コラム
- コンテンツ種別の詳細は、「画面コンテンツの作成 > コンテンツ種別について」を参照してください。
- コンテンツ種別を確認する方法は、「画面コンテンツの編集 > 画面コンテンツの基本情報を変更する」を参照してください。
判断基準
上記の操作確認を行った上で、次の点を満たしているかを確認してください。
- ✓ユーザが、どの内容を確認すべきかを画面上で理解できること
- ✓入力内容に誤りがある場合、必ず修正のために前の画面へ戻れること
- ✓確認ステップを経ずに、処理を確定できない設計になっていること
ここまで問題がなければ、次の確認ポイントに進んでください。
次に取るべき行動を示す画面遷移
画面遷移後に、ユーザが「次に何をすればよいか」を迷わず判断できるようにするため、各画面の役割と操作内容を明確にします。単に画面が遷移すること自体ではなく、遷移後の画面が果たす役割を意識して設計・確認することが重要です。
確認ポイント：
- (1) 各画面について、業務上の役割を明確にしているか
- (2) 完了画面では、処理が完了した事実だけではなく、次に取るべき操作を明示しているか
- (3) ボタンやリンクの文言から、実行される内容が想像できるか
操作手順
- 各画面における業務上の役割を明確に定義します。
画面 役割 入力画面（登録・編集） 業務情報を入力する 確認ダイアログ 入力内容を確認し、処理を進めるか判断する 完了画面（一覧） 処理結果を通知し、次の行動へ誘導する →役割が不明確な画面があると、ユーザが操作に迷う可能性があるため注意してください。
参考画面遷移に関する基本的な方針については、「intra-mart Design System - 画面遷移」を参照してください。
- 確認ダイアログに表示されるボタンやリンクが操作内容に合っているかを確認します。
画面 ボタン名 クリック後の画面遷移例 入力画面（登録） ［登録］ボタン
［戻る］ボタン→登録用の確認ダイアログを表示
→登録したデータを残した状態の入力画面に戻る入力画面（編集） ［更新］ボタン
［削除］ボタン
［戻る］ボタン→更新用の確認ダイアログを表示
→削除用の確認ダイアログを表示
→編集したデータを残した状態の入力画面に戻る確認ダイアログ ［登録］ボタン
［更新］ボタン
［削除］ボタン
［キャンセル］ボタン→登録した結果が反映された一覧画面を表示
→編集した結果が反映された一覧画面を表示
→削除した結果が反映された一覧画面を表示
→一覧画面に戻る
- 完了画面に「処理結果」と「次の行動」が表示されていることを確認します。
（例）登録完了後
- 続けて新規登録したい場合：一覧画面の［新規作成］ボタンをクリック
- 登録内容を確認したい場合：一覧画面のリンクをクリック
判断基準
上記の操作確認を行った上で、次の点を満たしているかを確認してください。
- ✓画面の表示内容や操作項目から、次に行うべき操作が直感的に理解できること
- ✓操作を誤った場合でも、業務に影響する致命的な処理が実行されないこと
- ✓業務フローの詳細を知らない利用者でも、画面の案内に従って操作を進められること
ここまで問題がなければ、次の確認ポイントに進んでください。
(4) 複数パターンの業務への対応
ユーザ環境では、入力ミスによるやり直しや処理の再実行、将来的な業務ルールの追加など、複数の業務パターンが発生します。こうした変化に対応できるよう、やり直しを考慮した分岐処理や、後から拡張しやすい構成になっているかを確認します。
やり直しを考慮した分岐処理の設計
実際の業務では、入力ミスや業務判断の変更、エラー発生などにより、ユーザ操作や業務状況に応じた「やり直し」が必ず発生します。そのため、想定される取り消し・再入力・再処理といった操作を事前に洗い出し、どの状態でどの操作を許可するのかを業務ルールとして明確に定義しておく必要があります。
確認ポイント：
- (1) 業務上、発生する可能性のある「やり直し」操作を洗い出しているか
- (2) やり直しが発生した場合に、許可する操作（取り消し・再入力・再処理・閲覧のみなど）を明確に定義しているか
- (3) 状態（ステータス）に応じて分岐処理を制御できる設計になっているか
操作手順
- 業務上、発生する可能性があるやり直し操作を整理します。
- 登録後の取り消し操作
- 入力内容の誤りによる再入力
- エラー発生後の再実行
- 処理途中での業務中断
- やり直しが発生した場合に、どの操作を許可するかを定義します。
状況 許可する操作 画面上の動作 登録前
（確認ダイアログが表示）再入力 確認ダイアログで［キャンセル］ボタンをクリックして、入力画面に戻る 登録中断
（確認ダイアログで取り消した後）取り消し 入力画面の［戻る］ボタンをクリックして、さらに破棄確認ダイアログで［OK］をクリックする。クリック後は、一覧画面を表示 登録後
（確認ダイアログで確定した後）再入力・再処理 結果を反映した一覧画面を表示。編集リンクをクリックして、編集画面から再入力する 入力ミス
（確認ダイアログが表示）再入力 確認ダイアログで［キャンセル］ボタンをクリックして、入力画面に戻る 入力ミス
（確認ダイアログで確定した後）再入力・再処理 結果を反映した一覧画面を表示。編集リンクをクリックして、編集画面から再入力する
- 状態（ステータス）に基づいた分岐条件をそれぞれ設定します。
- ロジックフローによる「分岐」制御要素の設定
- 画面のアクションアイテムによる条件の追加
参考
- IM-LogicDesignerによるロジックフローの条件分岐の設定については、処理フローに合わせて「【参考】ロジックフローの基本設計」を参照してください。
- IM-BloomMakerによるアクションアイテムの設定については、画面の種類に合わせて「【参考】画面コンテンツの基本設計」を参照してください。
判断基準
上記の操作確認を行った上で、次の点を満たしているかを確認してください。
- ✓想定されるやり直し操作が、画面遷移やロジックフロー上に明示的に存在していること
- ✓単純な「戻る」操作に依存せず、業務上意味のある分岐として設計されていること
- ✓現在の状態に応じて、どの操作が可能かを説明できること
ここまで問題がなければ、次の確認ポイントに進んでください。
将来的な業務拡張を妨げない構成
実際の運用を見据え、将来的に分岐条件や画面が追加された場合でも、既存の処理を大きく修正せずに対応できる構成になっているかを確認します。検証段階では問題なく動作していても、実際には業務変更や運用ルールの追加により、想定以上にロジックフローや画面が拡張されるケースが多く発生します。そのため、将来的な拡張を妨げない構成になっているかを、この段階で確認しておくことが重要です。
確認ポイント：
- (1) ロジックフローの分岐条件が拡張可能な形で定義されているか
- (2) ロジックフローに分岐条件を追加できる余地があるか
- (3) 処理の役割ごとにロジックが整理されているか
操作手順
- 分岐条件のEL式が、特定の値に固定されていないかを確認します。
- 分岐に必要な値は、事前に変数として用意すること
- 複雑な業務判断はEL式に書かないこと
- ステータスや区分値で分岐できる構造にすること
→結果文字列などの固定値だけで判定している場合、条件追加時に修正範囲が広がりやすくなります。
参考EL式の詳細と利用例については、「IM-LogicDesigner仕様書 - 5.4. EL式」を参照してください。
- フローのルートが直線的になりすぎていないかを確認します。
- 処理の途中に条件分岐や割り込みを追加できる余地があること
- 既存の遷移を壊さずにルートを増やせる構成になっていること
- 役割ごとの処理が適切に分離されていることを確認します。
（例）以下の処理が混在していないかを確認します。
- 入力チェック
- 登録・更新処理
- 結果表示・画面遷移
→役割ごとに処理を分離しておくことで、将来の仕様変更や機能追加時の影響範囲を最小限に抑えることができます。
判断基準
上記の操作確認を行った上で、次の点を満たしているかを確認してください。
- ✓条件や画面が追加されても、既存のロジックを壊さずに拡張できること
- ✓業務変更時に「どこを直せばよいか」が説明できる構成であること
- ✓検証時だけでなく、運用や将来拡張を前提とした設計であること
次のステップへ：公開URLの確認と修正
ユーザに公開する前に、公開URL（ルーティング定義）を確認していきましょう。「公開URLの確認と修正」では、公開URL（ルーティング定義）の確認と修正（編集・再作成）方法について説明しています。