スケジューラUIライブラリ比較：dhtmlx-schedulerとSyncfusion Kanban

概要

業務システムで「予定・タスクをどう見せるか」を実装するとき、候補になるUIライブラリに dhtmlx-scheduler と Syncfusion 系コンポーネント（ここでは Kanban）がある。

名前だけ見ると近い領域に思えるが、両者は 設計思想が根本的に違う。dhtmlx-scheduler は「時間軸に予定を置く」カレンダー/タイムライン型、Syncfusion Kanban は「状態（列）にカードを並べる」ワークフロー型だ。この記事では公開情報をもとに、両者の向き・不向きと選定基準を整理する。特定の案件・顧客情報は含まない一般論として書く。

前提：この2つは「同じカテゴリ」ではない

観点	dhtmlx-scheduler	Syncfusion Kanban
中心概念	時間（日/週/月/タイムライン）	状態（列＝ステータス）
データの主キー情報	開始・終了時刻	所属する列・優先度
典型的な問い	いつ・誰が・何をするか	今どの段階にあるか
ユースケース	予約・シフト・会議室・設備割当	進捗管理・タスクボード・課題管理

「予約枠を時間で押さえたい」なら scheduler、「To Do → Doing → Done の流れを見たい」なら Kanban。同じ画面要件でこの2つを迷うケースは本来少なく、迷うとしたら「要件の解像度がまだ低い」サインのことが多い。

比較軸1：描画パラダイム

dhtmlx-scheduler（時間軸型）

• Day / Week / Month に加え Timeline / Units ビューを持つ。
• Timeline ビューは「縦軸＝リソース（人・部屋・設備）、横軸＝時間」を取れるため、リソース割当型のスケジューリングに向く。
• 繰り返し予定、ドラッグによる移動・リサイズ、時間帯ブロックを標準サポート。

Syncfusion Kanban（状態型）

• 列（カラム）＝ステータス。カードを動かす＝ステータス遷移。
• スイムレーンで担当者別・優先度別にグルーピング。
• WIP制限（列ごとの最大カード数）などかんばん方式の概念をサポート。

最大の分岐点は 「時間の概念を強く持つか」。Kanban に締切を持たせることはできても、時間軸上の衝突（ダブルブッキング）検知には向かない。

比較軸2：フレームワーク対応とデータの持ち方

どちらもバニラJSに加え主要フレームワーク（React / Angular / Vue）のラッパーを提供する。Syncfusion は Blazor など .NET 系も手厚い。

// Syncfusion Kanban（Reactの概念例・プロパティ名は公式ドキュメント参照）
import { KanbanComponent, ColumnsDirective, ColumnDirective } from "@syncfusion/ej2-react-kanban";

function TaskBoard({ cards }: { cards: Card[] }) {
  return (
    <KanbanComponent
      keyField="Status"
      dataSource={cards}
      cardSettings={{ contentField: "Summary", headerField: "Id" }}
    >
      <ColumnsDirective>
        <ColumnDirective headerText="To Do" keyField="Open" />
        <ColumnDirective headerText="Doing" keyField="InProgress" />
        <ColumnDirective headerText="Done" keyField="Close" />
      </ColumnsDirective>
    </KanbanComponent>
  );
}

// dhtmlx-scheduler（タイムライン初期化の概念例・APIは公式ドキュメント参照）
scheduler.createTimelineView({
  name: "timeline",
  x_unit: "minute",
  y_unit: resources,   // 縦軸＝リソース
  y_property: "resource_id",
});
scheduler.init("scheduler_here", new Date(), "timeline");
scheduler.parse(events); // 開始・終了時刻を持つイベント配列

> 上記は概念を示す擬似コードであり、正確なAPI・プロパティ名・初期化手順は各公式ドキュメントで確認してほしい。

ポイントはデータモデルだ。scheduler は「時刻」を持つイベント配列、Kanban は「所属列」を持つカード配列を素直に渡せる。自分のバックエンドのデータモデルがどちらに近いかで、実装の素直さが変わる。

比較軸3：ライセンス

選定で見落とされやすい重要ポイント。

• dhtmlx：GPL版と商用ライセンスの2系統を持つ製品がある。プロプライエタリな製品に組み込むなら商用ライセンスの検討が必要。
• Syncfusion：商用製品だが、一定条件（小規模事業者・個人など）を満たすと無償のコミュニティライセンスが使える枠組みを提供してきた。

いずれもライセンス条件は改定されうる。採用時点の公式ライセンスページで必ず最新条件を確認すること。「無償で使えると思っていたら条件を外れていた」は後から効く地雷になる。

選定フロー（実務の判断軸）

1. 時刻が一級市民か？ 時間帯の衝突検知が要件にあるなら → dhtmlx-scheduler（特に Timeline）。
2. 状態遷移が主役か？ 進捗可視化が主なら → Syncfusion Kanban。
3. 両方欲しい？ 1画面に詰めず2つのビューに分ける。1コンポーネントで両立させると両方の長所が死ぬ。
4. ライセンス・配布形態は？ ここで候補が絞られることもある。

確認方法

• 公式デモを自分のデータ件数（例：数百〜数千件）で触り、スクロール・描画のパフォーマンスを体感で確認する。
• ドラッグ操作後の永続化イベントの発火タイミング（楽観更新か、サーバ確定後か）を確認する。
• scheduler ならタイムゾーン・繰り返し、Kanban ならスイムレーン・WIP制限と、実際に使う機能だけを優先検証する。

注意点

• 名前が似ていても解く問題が違う。ラベルに引っ張られて誤選択すると実装後半で苦しむ。
• ライセンスは採用時点で必ず再確認。本記事の記述は一般的傾向の説明であり、最新の正確な条件は公式が正。
• 本記事のコードは概念提示であり、実装前に公式ドキュメントで裏取りすること。

まとめ

• dhtmlx-scheduler は時間軸にイベントを置く世界（予約・シフト・リソース割当、Timeline が武器）。
• Syncfusion Kanban は状態にカードを置く世界（進捗・ワークフロー、スイムレーン・WIP制限）。
• 第一問は「時刻が一級市民か、状態遷移が主役か」。ここを言語化できれば2つで迷うことはほぼなくなる。
• 最後はライセンスと実データでのパフォーマンス検証で確定させる。