元同僚への相談が断られた時点で、問題の本質が見えた。
個別指導塾の時間割作成と振替対応を自動化するという構想は、言葉にできていなかった。
既存の管理ツールでは「配置を考える判断」を担えない理由。
全体生成・再生成・自動振替が一体でなければならない理由。
確定済みの配置を崩さずに影響範囲だけを再計算するという処理が、なぜ制御構造の問題なのか。
これらを構造として説明する言葉が、この時点ではまだ整っていなかった。
言語化するためには、問いを投げ返してくれる相手が必要だった。
I氏との付き合いは10年以上になる。
ワイン会を共にする間柄であり、仕事上の利害関係はない。
大手企業向けにCRMシステムを構築・提供してきたY社の元代表取締役として、ITシステムの開発と事業化の両方を経験してきた人物だ。
技術的な問題として評価できると同時に、事業としての問題としても評価できる。
そして10年以上の付き合いは、相手の感情を慮って本音を避けるという関係ではない。
構想が既存のものと変わらなければそう言う。
新しいものがあれば新しいと言う。
言語化が不十分であればそれを指摘する。
この対話の中で、スケジューリング自動化の構想が初めて 外部から問い直されることになる。
その問い直しが、shiftect.の設計思想の核心を言語化する起点になった。