まずは UX から考える
自分の工夫を相手に伝えるためには
Section titled “自分の工夫を相手に伝えるためには”高度なアルゴリズムやモデルを作ると、つい 内部ロジックの説明 から始めたくなります。
- 最適解 / 準最適解 / 制約付き最適解 が出せます
- 多目的最適化ができます
- モデルの性質はこうです
しかし、これだけだとユーザーにはこう見えます：
- 何がユーザーの入力で、何がシステムの計算結果か分からない
- システムが「勝手に3つの解を吐いているだけ」に見える
- 結局どう触れば良いのかがイメージできない
そこで大事になるのが、次のような 工夫の見せ方・説明 です。
意識したいポイント
Section titled “意識したいポイント”1. 機能ではなく、「ユーザー視点の操作イメージ」を最後まで言語化する
Section titled “1. 機能ではなく、「ユーザー視点の操作イメージ」を最後まで言語化する”- ❌️ 「パラメータを設定した後に、コスト関数の最適化では100回のサンプリングを行い、最適解とそれに近いものを3つ出力できます」
たとえばコストが小さい順に3種類の異なる解を出力する機能がアプリ上の工夫だとしましょう。その場合、
画面で設定した制約や優先順位を元にして計算されるコストを最も小さくする組み合わせが3種類表示されます。 出力結果を見ながら、どのような配送ルートを選択するかの意思決定が可能となっています。
のような表現を取ることで、「意思決定のために使える便利なツールなんだな」という印象を与えられ、アプリの工夫自体も相手に伝わりやすくなる。
2. 「入力（ユーザーが決める）」と、「出力（システムが計算する）」を明確に分ける
Section titled “2. 「入力（ユーザーが決める）」と、「出力（システムが計算する）」を明確に分ける”- ユーザーが決めるもの（例）
- 制約の上限・下限 （トラック台数 < 3, 労働時間 = 8h など）
- 目的関数の重み（コスト重視か、納期重視か）
- 使用する工場・原料の候補
- システムが返すもの（例）
- 条件に対する最適スケジュール
- コスト・時間などの評価値
- 代替シナリオ
3. システムが“勝手に決めている”ように見せない
Section titled “3. システムが“勝手に決めている”ように見せない”- ❌️ 「システムがベストなスケジュールを自動生成します」
- ⭕️ 「ユーザーが設定した条件に基づき、最適なスケジュールを計算します。条件を少し変えた比較シナリオも簡単に作成できます。」
4. シナリオ比較ができることを UX として見せる
Section titled “4. シナリオ比較ができることを UX として見せる”数理最適化の強みは、条件を変えてシナリオ比較できることです。
例：
- シナリオA：コスト < 200 かつ トラック台数 < 3
- シナリオB：コスト < 1000 かつ 3 < トラック台数 < 10
- シナリオB：トラック台数 < 4 かつ 作業時間 ≤ 7h
これらを比較し、何がどのように嬉しいかがわかれば使いやすいアプリになります。
5. 結果だけではなく、「なぜその結果になったのか」の説明までセットにする
Section titled “5. 結果だけではなく、「なぜその結果になったのか」の説明までセットにする”- ❌️ 「このスケジュールが最適となりました」
- ⭕️「この結果は、労働時間が8時間以下、配送コストの削減重視で、作業Aは必須という条件に基づいて計算しています。これらの条件を変えると、結果がどう変わるかも確認できます。」