「駅すぱあと」を支える技術とDSLの話

「駅すぱあと」を支える開発 〜９２６２の可能性を繋げ！〜(DevLOVE関西Ver) というイベントが開催された。

ぼくも会場係としてスタッフ参加。

「駅すぱあと」の歴史から技術、開発のマネジメント手法に至るまで、幅広い話が聞ける良いイベントだった。

いろいろな話が聞けたのだけれど、僕は特に佐藤さんの「『駅すぱあと』新しい開発基盤の研究」がおもしろかった。

まだ開発途中で、実際の駅すぱあとには組み込まれていないそうなのだけれど、佐藤さんは「駅すぱあと」の運賃計算のDSLを研究・開発しているという。

曰く、鉄道の運賃計算は泥沼である。単純に距離や、目的地までの駅数などで運賃が算出できればよいが、鉄道の運賃計算には無数の特例がある。

下記リンク先に、JRの運賃の特例計算が列挙されているので、ちょっと見ていただきたい。

……お分かりいただけただろうか。現在の「駅すぱあと」では、これらの特例がすべてif文の分岐で実装されているのだという......。

ここまで複雑になると、ドメインエキスパートと運賃計算について会話する際、実装済みのコードや仕様書を読んだところで正直普通の人間には理解しづらすぎるだろう。そこでDSLが威力を発揮する。

こういったDSLは、特定領域に特化していればよく、言語設計としてチューリング完全である必要はない。また、鉄道の運賃計算のような専門領域は、一般人にわかりやすい言葉などで無理やり言い換えるより、むしろ専門用語をそのまま使ったほうが、ドメインエキスパートと理解の齟齬が無くコミュニケーションができる。このあたりはDDDのユビキタス言語を考えるとわかりやすい。

これらのドメインモデルを定義することで、運賃計算のアルゴリズムを専門用語そのままに表現することができ、極端な話ではあるが、運賃の計算式に対して鉄道ファンのレビューを受ける、ということも不可能ではなくなっていくだろう。

佐藤さんの目標は、「駅すぱあと」の初期から実装され、複雑化しているコア部分をDSLとして抽出し、再定義することでメンテナンス性を高めることだという。

DSLは一歩間違えるとそれ自体がブラックボックス化し、メンテナンス不能に陥る危険性をはらんでいる。しかし、アルゴリズムとして極度に複雑なものをシンプルに保つために定義するDSLは、複雑さの分離という観点で効果が高そうな気がする。

これらの研究が実を結び、実際に「駅すぱあと」に適用された頃に、佐藤さんのお話をもう一度伺ってみたいと思った。

実践プログラミングDSL ドメイン特化言語の設計と実装のノウハウ (Programmer’s SELECTION)

ドメイン特化言語 パターンで学ぶDSLのベストプラクティス46項目