デザインと設計

ユーザー導線、画面、デジタル製品の設計。OTOKO®は貴社の要件を、わかりやすく一貫した操作性へとつなげます。

顧客は手続きを完了させたいと考え、外勤チームは現場での情報を必要とし、業務部門は信頼できる全体像を求めています。

開発前に行う、クリック可能なプロトタイプと、業務部門または顧客によるユーザーテスト React、Next.js、VueによるWebフロントエンド、WCAG 2.2に基づくアクセシビリティ React Native、またはKotlinとSwiftによるネイティブ開発のモバイルアプリ（ストアへの公開を含む） OpenID Connectによるログイン、OWASP MASVSに基づくセッション保護と証明書ピンニング オフライン対応、プッシュ通知、GDPRに基づく同意を得たテレメトリ

ソースコード付きの公開済みアプリとWebアプリケーション デザインシステムとアクセシビリティレポート OWASP MASVSに基づくセキュリティ検証レポート

利用者グループと主要業務 既存のログインとロールモデル 必要な端末とオフライン利用シーン

パートナーポータルはメールでの問い合わせに代わるものです。パートナーは自分の案件のみを閲覧し、資料をアップロードし、処理の過程で問い合わせを受け取ります。社内処理では同じデータを使用しますが、ロールと承認権限が異なります。

React Next.js Vue React Native Kotlin Swift

ポータルが役立つのは、利用者が回り道をせずに目的を達成できる場合です。ログイン、データ入力、アップロード、問い合わせ、状況確認までの一連のフローを設計します。エラー発生時の対応も設計に含めます。セッションの期限切れ、不備のある書類、接続の中断が原因で、すでに入力した作業内容が失われることがあってはなりません。 クリック可能なプロトタイプによって、実装前にこれらのフローを検証できます。業務部門と利用者グループからのフィードバックは、ナビゲーション、フォーム、分かりやすいメッセージに反映します。共通のコンポーネントシステムにより、新しい機能にも同じ操作ロジックが適用されます。

選択は用途に応じて決まります。ブラウザベースのポータルは、インストール不要で手軽にアクセスできます。プログレッシブウェブアプリは、特定のモバイル用途には十分な場合があります。デバイスのインターフェース、バックグラウンド処理、オフライン要件が必要とする場合には、ネイティブアプリやクロスプラットフォームアプリが選択肢になります。必要な機能については、実機で検証します。 オフラインデータには、ローカル保存、同期、競合に関するルールが必要です。例えば外勤アプリでは、2人が同じ案件を処理した場合にどちらの変更を優先するかを明確にしておく必要があります。これらの点はユーザーインターフェースだけでなく、バックエンドや権限にも影響します。

キーボード操作、識別しやすいフォーカス状態、分かりやすいエラーメッセージ、拡大可能なフォントは、ユーザーインターフェース設計の一部です。アクセシビリティに必要な検証範囲は貴社とすり合わせます。ビジュアルデザインや自動スキャンだけでは、アクセシビリティの完全な証跡にはなりません。 アクセスは、すべてのロールと操作についてサーバー側で検証します。ファイルアップロード、セッション、データ共有にはそれぞれ専用の保護対策を設けます。展開に向けては、テスト端末、必要に応じたアプリストアの承認、サポート経路、貴社の利用者への導入を計画します。

顧客アカウントはログインだけで完結するものではありません。招待、所属組織の変更、ログイン情報の紛失、代理設定、従業員の退職といった状況が権限モデルに組み込まれている必要があります。新規利用者を誰が承認できるか、どのステップで再確認が必要かを明確にします。一元管理されたIDを連携させることもできますが、個々の案件に関する業務上の判断はポータル側の役割として残ります。 申請プロセスとアップロードについては、社内処理に至るまでの一連の流れ全体を検討します。ファイルサイズ、許可するコンテンツ、隔離処理、承認は、分かりやすいステータス表示と併せて計画します。アップロードが成功したからといって、書類が確認済み、または受理されたことにはなりません。下書き、自動保存、別端末での再開には、表示範囲に関する明確なルールが必要です。機密性の高い情報は、通知やURL、診断メッセージに誤って表示されないようにします。

倉庫や外勤で使うモバイルアプリケーションは、常に安定した通信環境を前提にはできません。閲覧用のオフラインデータとローカルで入力した変更内容を区別し、それぞれの有効期間を定めます。大量のデータを無差別にすべての端末へコピーすることはしません。利用者の権限、端末のストレージ容量、端末紛失時の対応もこの設計に組み込みます。 再接続した時点で、同じデータがサーバー側ですでに変更されている場合があります。「最後の変更を優先する」という一律のルールは、多くの業務プロセスには適していません。どの項目を自動的に統合できるか、どの競合に判断が必要かを定義します。送信待ちのデータは利用者から見える状態を保ちます。テストでは、送信中の通信切断、複数回の再送、セッションの期限切れ、入力から同期までの間の権限変更を確認します。

ポータルは開発用の大きなモニターだけで使われるわけではありません。長い名前、翻訳文、拡大されたフォント、画面キーボード、動作の遅い端末は、いずれもレイアウトに影響します。そのため、実際に使用する端末上で、さまざまな入力方法により一連の作業全体を検証します。エラーメッセージは修正すべき内容を説明し、該当箇所へ誘導します。再ログインが必要になっただけで、フォームの入力内容が失われてはなりません。 導入にあたっては、対象利用者を限定し、すぐに問い合わせられるサポート体制と、実際の業務フローからのフィードバックを計画します。モバイルアプリでは旧バージョンが残ったまま使われることがあるため、バックエンド側は合意した移行期間を考慮する必要があります。利用状況の計測は、どの時点で案件が中断されるかなど、具体的な改善課題に答えられるものであるべきです。どの計測を実施してよいか、そのためにどの情報が必要かは、実装前に明確にします。

アプリケーション環境、要件、リスク 業務部門、IT、情報セキュリティ、OTOKO®ソフトウェアアーキテクト 評価済みの案件、棚卸し、セキュリティ・運用要件

アーキテクチャ、テクノロジー、運用モデル 業務部門、アーキテクチャ、データ保護、情報セキュリティ 目標アーキテクチャ、脅威モデル、テスト戦略、運用モデル、マイルストーン