開発に４年の歳月が掛りました。
４年間・・・とても長い時間です。失敗と挑戦を繰り返し挫折を覚えた時もありました。情熱と信念、努力で乗り越えた時間です。ローズマスターは当社の技術力と愛情の結晶です。きっかけは一件の開発依頼でした。リラクゼーション業界向けのシステム開発依頼で、適度なボリュームはあるが、特に問題のある開発には見えませんでした。機能数に基づき見積もり、『これをベースに業界向けのパッケージを作らせて欲しい』と申し出て、見積額の半額近くで受託した案件でした。
ところが、大きな落とし穴がありました。とても大きく、底が見えないくらい深い落とし穴でした。それは、ＮＰ困難と言われる問題です。つまり、要望を満たすソフトウェアを構築するには、『完全には解決出来ない、現実的な処理時間内に的確な答えを見つける処理が出来ない』と言う要素が含まれていたのです。
どういう事かと申しますと―
開発依頼のあったリラクゼーション店舗の基本的な運用ルールは以下の通りです。
・出来る技術の種類が異なるトレーナーが複数人出勤している。施設は出来るコースが決まっている。
・施術時間が重なる予約は、施設の数とトレーナーの持つ技術の数のいずれも超えてはいけない。
・トレーナーは、優先順位が決まっていてお客様が施術に来られたら、優先順位に従って施術に入る。
・但し、優先度一位でも後の予約消化が困難になる場合は施術に入れず、次に優先度の高い者が入る。
ルールはたったこれだけです。
10件程度の予約数であれば正攻法に組んだプログラムで容易に処理が行えます。
しかし、予約件数が40件ともなると、その予約割当（予約をトレーナーに振り分ける事を言います）の組合せ数は
予約数40の階乗（40×39×38×37×36×35×34×33×・・・・8×7×6×5×4×3×2×1）で
815,915,283,247,989,000,000,000,000,000,000,000,000,000,000,000通り以上の組合わせになります。
これだけの数の組合せの中から的確な答え＝『取れる or 取れない』を導くためにコンピュータで処理をさせようとすると膨大な時間が掛ってしまうと言う問題です（決して大袈裟ではなく、予約件数40件で二日や三日、予約件数100件にもなれば一ヶ月待っても答えが返ってこない場合もあります）。
巨大な落とし穴
組合せ数の肥大化による解決困難な問題である事が当初気付けなかった落とし穴だったのです。我々がこの問題に気付いたのは最初に開発したシステムの結合テストに入ってからです。ＮＰ困難なので当然なのですが根本的に解決出来る術は見当たりませんでした。我々に残された手段は限定的な処理にして組合せ数の肥大化から逃れるシステムを作り上げ、取り合えず動くモノに仕上げて納品する事でした。
当初の納期を遅らせてもらい、なんとか人の手を借りて予約受付と施術開始処理が動くモノに仕上げリリースしました。限定的にしか処理しないので、人のサポートが無くてはまともに動かない「取れるのに取れないと判断する事が起こってしまう」代物です。パッケージどころか、納入出来る製品とはとても言い難い品質でした。
長き戦いの始まり
我々の戦いはここから始まりました。敵は『組合せ数の肥大化』と言う名の怪獣です。低品質な製品を使い続けて頂き、戦う時間を許容して下さったユーザー様には感謝の言葉が尽きません。我々としても、データを登録するのに、人の手を借りなくてはいけないようなシステムのままでは、製造者としての責任が果たせません。
そこで、再構築しパッケージ化の実現に向けたプロジェクトを立ち上げました。この肥大化怪獣と戦う機能を『予約エンジン』と名付け、それ以外の機能とは区別して担当者をアサインしてプロジェクトを推進しました。根本的な改善を求め開発ロジックの見方・考え方を変える為に、開発担当者を何度も変え、設計と製造を繰り返し、処理速度を極限まで上げるようなプログラム的施策も施しましたが、それでも思うように動くモノが出来ません。処理時間10秒以内に割当出来る予約数はせいぜい20件程度にしかなりません。これでは、怪獣に向かって水鉄砲を武器に戦いを挑むようなものです。運用状況を考えると実用的な製品とは言えません。せめて150件の予約が入っても全件組み替えして正確な『取れる or 取れない』の判断が出来るシステムでなければ納品出来ませんし、パッケージとして売り出せる製品としての基準を考えれば200件がボーダーラインです。
窮地と試練
戦い始めてから二年を過ぎた頃、社内からも「無理でしょう」と言う声が上がった事もありました。
しかし、無理でしょうと言う言葉を発したエンジニアも、言葉とは裏腹にローズマスターの完成に向け予約エンジン以外でとても高い品質の機能をいくつも創り上げ完成に向け尽力していました。『困難に立ち向かいやり遂げる』ローズマスターの開発はいつしか当社全体の夢・目標になっていました。『自分達が納得できる妥協の無いモノ創り』は当社の掲げた理念です。ローズマスターの開発が理念に基いた仕事を遂行する事の喜びを浸透させてくれたような気がします。
こうして予約エンジン以外の機能の開発は目標期限までの完成に目処が立ち、後は「予約エンジンのみ！」というところまでプロジェクトは進んでいました。
しかし、予約エンジンの決定的な打開策は相変わらず見つけられず、プロトタイプを作っては、テストを行い、10秒以内に処理できる予約件数が目標ラインに達しておらず設計からやり直し、と言う失敗の繰り返しで時間が過ぎて行きました。
差し込んだ一筋の光
暗中模索のある日、ある技術に辿り着きました。もちろん、ＮＰ困難を根本的に解決出来る訳ではありません。現代科学で解決する事が出来ないからＮＰ困難なのです。しかし、我々が辿り着いた技術は、実運用上で充分な予約件数を処理出来る技術です。怪獣を倒しきる事は出来なくても、怪獣が戦場に現れた時に負けない武器にはなりました。具体的には、250件までなら全件組み替えを行い正確な予約の受付可否判断を10秒以内に行える技術です。詳しく述べれば、99％の確率で5秒以内に可否判断処理が出来、99.9％以上の確率で10秒以内に処理が出来ます。0.1％以下の確立で10秒以上の時間を要するケースがあり得ますが、タイムアウト処理で受付不可と判断させています。この数は１予約の平均時間を50分、トレーナーが30人とした場合、約7時間インターバル無しで全トレーナーに予約が割当てられ、空き時間が全くないと言う状況です。250件の予約受付を正確に可否判断出来れば、実用に充分な性能と言って差し支えないレベルであると考えています。
実際には予約間にインターバルが必要となりますし、お客様の希望時間もあり多少の空き時間が発生します。また、３～４時間以内の予約が大半を占めていると言うのが温浴施設内での予約受付実体である事を考慮すると、実際には150～200件の予約を全件検索して正しい答えを見つけられれば要望を満たす事の出来る品質です。当社の開発した予約エンジンは更に40％以上の余裕をもった性能です。
ローズマスターの完成
ローズマスターは、この予約エンジンの完成度を上げる事ばかりでなく、再構築を機にユーザー様の視点に立って『画面を見るだけで分かり易く、簡単操作で使い易いＰＯＳシステム』の実現に全力を投じた製品です。ボタンの大きさや配置をピクセル単位で設計すると言った細部にも、プログラムのソースコードと言うような見えない部分にも拘り、一切の妥協なしに自分達が納得できる製品に創り上げました。機能、操作性、デザインの全てにおいて当社の技術を結集し考えられる限りの工夫を凝らしました。 4年の歳月が掛りましたが、『特別な技能を持たない方でも、高効率で理想的な業界の運用ルールに基づいて安定したオペレーションを実現出来る武器』としてローズマスターが完成しました。
