見出し画像

計画業務を支える技術 Vol.2 — “賢い表”をさらに柔軟にするために

計画最適化のことならアルゴアーティス

はじめに

こんにちは。ALGO ARTIS のプロダクトチームで開発を担当している細野です。
先日公開された「計画業務を支える技術 Vol.1 計画業務の裏で動く“賢い表”の仕組み」では、ソフトウェアエンジニアの古屋さんが、計画業務における表形式のデータを扱う上での基本的なデータ構造と、その選択理由について詳しく説明してくれました。
とくに、「行」を単方向リストのような構造で管理し、挿入・削除を効率化するという設計は、計画業務で頻繁に起きる要素の追加・削除への対応として興味深いものでした。

一方で、Excel ライクな表をより汎用的に扱おうとすると、「UI で扱いやすい構造」と「共通基盤側で保持したい構造」を必ずしも同一にする必要がないケースが出てきます。本記事では、前回記事の記事の内容を補完しつつ、UI と共通基盤側のデータモデルを分離するというアプローチや、それを支える社内プロダクト AAGridSheet(社内呼称：エーエー・グリッド・シート) を例に挙げながら、「よりExcelらしさ」を実現する設計の可能性についてご紹介したいと思います。

前回記事のアプローチのおさらい

まずは簡単に、前回記事のアプローチをおさらいしましょう。

  1. 列：ソート番号を用いて並び順を管理

    1. 列の総数は行の総数に比べて少なく、また列の追加・削除頻度も低い。

    2. したがって、列はシンプルにソート番号を保持して並び順を再現するだけでも十分。

  2. 行：単方向リストで管理

    1. 計画業務では行の追加・削除を頻繁に行う。

    2. そこで、「行ごとに next_id（直後の行）」だけを持たせることで、行の順番を再現できるようにしている。

    3. 配列に比べて、途中挿入・削除が比較的効率的なのがメリット。

上記設計は、計画業務にありがちな「大量の行データを試行錯誤しながら組み替える」というユースケースにフォーカスしていて、とても合理的です。
実際、本記事が主に想定している「行を頻繁に操作する計画立案」のシーンでは、このような構造により業務が大幅に効率化されるでしょう。

さらなる柔軟性が必要になるケース

ところが、「Excel からの移行」 を強く意識したり、より“汎用的な表UI”を実装しようとすると、もう少し柔軟な機能を提供したいケースが出てきます。たとえば、

  • 列も行と同じくらい頻繁に変わるケース

    1. 業務内容によっては、列にあたる属性自体を「試しに増やしては削除する」ということを繰り返すシナリオもあります。

    2. この場合、列に対しても高速な挿入・削除機能が必要になり、単なるソート番号管理では煩雑になることも。

  • 列の並び方・行の並び方をサクサク変えたい

    1. Excel 上ではドラッグ＆ドロップで列・行を簡単に移動できます。

    2. こうした「見た目の操作」に対するユーザーの期待度が高い場合、共通基盤側の構造をそのままUIに持ち込むと複雑さが増すことがあります。

  • 特定列でソート、フィルタリングするなど「Excelらしい」操作が頻繁

    1. Excel のように柔軟なフィルタリングやソートを何度も切り替えるケースでは、共通基盤側の構造を頻繁に組み替えるより、UI 側がサッと配列（あるいは DataFrame 的）に読み込んで、オンメモリ上で並び替えやフィルタを行うほうが圧倒的に高速です。

これらのニーズが高まってくると、UI画面側と共通基盤側のデータ構造を同一視するアーキテクチャでは、設計や拡張が難しくなることがあるのです。

UI と共通基盤データモデルを分離するアプローチ

こうした要望に応えるには、UI で必要な操作性と、共通基盤側での永続化・統合的なデータ管理を分けて考え、それぞれ最適化するアプローチが効果的です。
たとえば、共通基盤層と、それを利用する描画、UI層の間でレイヤーを分離します。

  • UI側のレイヤー

    • 画面上で扱うデータは、必要なタイミングで共通基盤側から受け取り、オンメモリ上では2次元配列やDataFrameライクな構造に変換しておく。

    • 行や列のドラッグ＆ドロップやソート、フィルタリングなど “Excelライク” な操作を軽快に行うために表示の仮想化を取り入れる。

    • UI上でユーザーが操作した内容（挿入・削除・変更など）を、必要に応じて共通基盤側の永続化モデルに反映していく。

  • 共通基盤側のレイヤー

    • データベースや永続化層では、計画業務にフォーカスした双方向リストや単方向リスト、あるいはスキーマ付き／スキーマレスのDBを使って最適化する。

    • 計画業務特有の要件（在庫数や工程順序の計算ルールなど）を考慮したユースケースロジックを保持して、ビジネスルールを安全に運用する。

こうした分離を行うことで、

  • UI実装をシンプルかつ高速化できる

    • 多くのユーザーが親しんでいる「Excelライクな見た目・操作性」の再現を、UI専用の最適なデータ構造（2次元配列など）で実装しやすくなる。

  • アルゴリズム・サーバー側の変更に柔軟に対応できる

    • 単方向リストを採用するのか、双方向リストにするのか、列も同じデータ構造にするのか、などの変更があっても、UI 層に大きな影響を与えない（＝技術的負債の拡大を最小化できる）。

    • アルゴリズムやデータモデルの変更も、二次元配列やUIが規定する型へのマッピングを変更することで、UIに大きく影響しない。

  • 大規模データにも耐えやすい

    • フロントエンド側で必要な部分だけを読み込み・仮想化表示することで、数万・数十万行に及ぶデータでもスムーズな表示が可能。

といった柔軟性をもたらすことができます。

AAGridSheetでの取り組み

ALGO ARTIS の社内では、こうした「UI と共通基盤構造の分離」に基づいた汎用的な表UIコンポーネントとして、AAGridSheetを開発・運用しています。
AAGridSheetでは、以下のような機能を備え、幅広い業務ユースケースに対応できるようにしています。

  • 基本はオンメモリで2次元配列を管理

    • Webクライアント側で一時的にデータを受け取り、2次元配列あるいはもっと複雑なマッピングを扱いやすい形に変換する。

    • 列の入れ替え、行のドラッグ＆ドロップ、フィルタリングなどの操作を即時かつ滑らかに実現。

  • 必要な変更のみをサーバーへ反映

    • CRUD（作成・読み込み・更新・削除）操作時に、差分だけをAPIでサーバーに送ることで通信コストを削減し、サーバー側のデータ構造とも整合を保つ。

  • 大規模データへの仮想スクロール

    • 全てを一括ロードしなくても、一部分を順次読み込み・表示できる仕組み（いわゆる仮想スクロール）をサポート。

    • 数万行以上のデータを取り扱うような計画業務でも、Excelライクな操作感を損なわずにスムーズな表示が可能。

もちろん、サーバー側では計画業務に特化した処理（ソルバーやロジック）や、前回記事で説明されていたような行の単方向リスト管理を活かして挿入・削除を効率化することもできます。
「表の見た目や操作は UI 側で対応し、サーバー側は計画業務としての最適化ロジックや永続化に専念する」ことで、それぞれのレイヤーがよりシンプルかつ高いパフォーマンスを発揮できるようになるわけです。

前回記事との接続点

前回記事のデータ構造は、行が多い計画業務を強く意識したアプローチであり、Accessやデータベースを活用するような運用に近い思想とも言えます。
この設計が「すでに明確なスキーマを持つ計画業務」にとって必要十分なのは間違いありません。実際、ある程度列が固定されるケースでは非常に有効でしょう。
しかし実際の Excel ユースケースは多種多様です。

  • 行と列の両方がどんどん増減する

  • 行も列も直感的にドラッグ＆ドロップで並べ替えたい

  • そもそも定型的なスキーマがないスプレッドシート運用を代替したいといった場合は、UI とサーバーで構造を分離し、UI 側を“見やすさ・操作しやすさ”に特化させることが、より柔軟なアプリケーション開発につながります。

まとめ

  • 前回の記事

    • 行の頻繁な追加・削除がある計画業務を想定した、単方向リストをベースとした賢い表の仕組みを紹介。

    • 配列によるコスト増大を抑えるために、行の構造を工夫するアプローチが非常に参考になる。

  • 本記事での補足：汎用的なUIへの視点

    • Excelライクな操作を実現するには、UI 側で2次元配列やデータフレーム的な構造を使い、サーバー側とは切り離して管理するのがおすすめ。

    • 大量データや複雑な並び替え・フィルタリングにも対応しやすく、拡張性が高い。

    • サーバー側では、計画業務特有の処理ロジックを維持しつつ、行（あるいは列）の管理構造を選択できる。単方向リストから双方向リストへ変更する場合も、UIに大きな影響を与えずに済む。

おわりに

古屋さんの「計画業務を支える技術」は、実際の業務要件に合わせたシンプルでパフォーマンス重視の設計が光る内容でした。一方で、「Excel 業務全般をもっと汎用的に置き換えたい」「UI 側の利便性をさらに高めたい」と考える場合は、本記事のように UI とサーバーデータモデルを分離する アプローチも有力な選択肢になります。

私たちALGO ARTIS では、データ管理基盤だけでなく、フロントエンドからも、AAGridSheet をはじめとする表UIコンポーネントの開発を通じて、計画業務だけでなく幅広い業務シーンで「Excel からの移行」を支援できるように、日々試行錯誤を重ねています。
もし興味をお持ちいただけたら、ぜひALGO ARTISの採用ページもご覧いただければ幸いです。お互いの知見を持ち寄って、一緒に「賢い表」を育てていきましょう！

それでは、本記事をお読みいただきありがとうございました。今後も「表」をめぐる技術的・運用的なトピックを掘り下げていきますので、どうぞよろしくお願いいたします。

良かったら、SNSやHPをチェックしてみてください。最新情報をご覧いただけます。また、フォローやスキ♡もお待ちしています！（スキはnoteのアカウントがなくても可能です！）

ALGO ARTIS について：https://www.algo-artis.com/

最適化ソリューション『Optium』：https://www.algo-artis.com/service
化学業界DXソリューション『Planium』：https://planium.jp/
X : https://x.com/algo_artis
Linkedin : https://www.linkedin.com/company/algo-artis/