「駅すぱあと」を支える開発 〜9262の可能性を繋げ!〜(DevLOVE関西Ver) #DevKan

「駅すぱあと」を支える開発 〜9262の可能性を繋げ!〜(DevLOVE関西Ver) - DevLOVE関西 | Doorkeeperに参加してきました。

今は全く関わりないのですが、前職で券売機系のお仕事を2・3年やっていてこともあり、非常に興味深く聞かせていただきました。

以下簡単なメモを掲載。自分が聞いた内容を書いていますが、勘違いしている場合もあるのでそういうときはご指摘お願いします。

「『駅すぱあと』を解剖します。基本的な経路案内の仕組みの紹介」宮本 雅臣氏

  • 駅すぱあとに携わって四半世紀
  • 駅すぱあとのはじめ1988年(首都圏版)
    • 他のソフトがあんまり売れない
    • 大学の研究室で経路検索の研究していた人がいた => 売れるんじゃないか?
  • 営業の人があとから検索してというニーズがあった
    • けど実はあんまり売れなかった
  • 1993年 全国版
    • 日本で一番出たのが早かった
    • 当時首都圏版でメモリフルに使っていたが、JTB時刻表を見ていけそうと思った
  • 全国版が出たら企業に売れ始めた
  • 欲が出てきて、路線バスを対象に
    • 路線バスルート案内を見て、できそうと判断
    • 東京、京都、大阪、名古屋やればいい => 現在大変なことに
  • 路線図見て、運賃計算が同じと思ってにっこりする程度のサラリーマン
  • フルダイヤ対応
    • 路線バスやるころはフルダイヤ売ってなかった
    • フルダイヤを売るように仕向けたところがあった
    • このとき初めて経路案内ができるようになった
  • 運賃誤表記問題
  • マルスと勝負して勝ったことがある
    • マルスは操作する人によって変わる
  • ソフトの可能性に気づく必要がある
    • 環境省からCO2排出量を入れてくれと言われた
  • ICカード対応
    • カードの種類によって運賃計算が変わるようになる?
      • テスト項目が怖い
    • 路線でどこまでカード使えるかも見られる
  • ムダを省く、捨てる技術、根こそぎではない
    • 代替案は出さないとだめ、比較できないとだめ
    • ICカードの視点、終点はわかるが途中のルートはわからない => 運賃計算は泥沼
    • 一部上場会社ほどクレームがうるさいww
    • JRだけなら、その会社が最適解を出せばいい。こっちは精度悪くてもいくつもの代替案が出せる。
  • 知らないことは駅すぱあとにとってプラスになった
    • 知らないから踏み出せた
  • お褒めの言葉はあまりない
  • 私鉄のダイヤは買ってない
    • 分単位のダイヤは売っている
    • 必要なダイヤは秒単位
    • 時刻表はあくまで人のための分単位で書かれている
  • コアエンジンはC言語
  • データの鮮度を保つのが大変
    • バスが大変

「『駅すぱあと』新しい開発基盤の研究」佐藤 昭彦氏

  • Javaエンジニアから駅すぱあと部門、改善プロジェクト
  • まだ研究中のもので、導入はされてない
  • C/C++開発環境カイゼン
  • 運賃計算とDSL
    • 泥沼の話
    • 基本乗った距離で決まる && 同じ所は2回通ってはダメ
    • 関西の路線を例に(京都→USJ
    • 大阪→京都→奈良
      • 1490円? No
      • 大都市近郊区間内 → 常に一番安くなる経路でOK 840円? No
      • 電車特定区間 800円
    • 特例が多い
      • プログラムで頑張ってる
      • 特例ごとにif文があるかんじ
    • DSL!
      • 開発者の生産性向上
      • ドメインエキスパートとのコミュニケーション改善
        • 鉄道用語をそのまま使えるようならチェックができる
      • コストに見合うか?
        • 覚える言語が増える
        • DSL自体のメンテナンスコスト
          • そもそも大きくしてはいけない
    • DSLの導入
      • セマンティックモデルを作成する(問題解決方法をモデル化する)
      • 今回はプロダクションルールモデル
    • DSL作成の注意点
      • DSL使う人は専門家
        • 積極的に専門用語を使う
        • DDDとも似た感じ

AWS,DevOps絡みの話(仮)」見川 孝太氏

  • DevOpsツールとか成功事例の話ではない
  • 協力する文化
  • Webサービス周辺
    • 開発:必要な環境ができない、運用の増大 => フラストレーションがたまる
    • インフラ:監視増大、よくわかってない要望、開発の理想押し付け => フラストレーションがたまる
    • 開発とインフラで相互に不満がたまる
  • セグメント主義的な話も……
  • AWS
    • 運用負荷、環境も限界 => 導入
    • 文化もついてくる
    • CDP
    • Amazon自体の企業文化も
  • 開発がインフラに踏み込める!
  • インフラは環境をより良くすることに集中できる
  • いい感じになる => めでたしめでたし?
  • Bizが抜けている
    • 営業さん
    • ビジネスの成功には3者の協力が必要
    • 仕事の違いで食い違い
      • インシデント 営業はユーザの報告優先、開発・インフラは復旧優先
    • 共通言語がない
    • チリツモ不満が、最近表面化
  • 改善
    • 決め事の見直し
    • 意識合わせ
    • コミュニケーション改善
      • 壁を超えるためのスタンプカード
    • 部・チームではなくプロダクトのゴール
  • 目指すのは協力する文化

「エナジャイズ!アジャイルの取組みや活性化の紹介」新井 剛氏

  • ちょっとエモい話
  • 緊急地震速報駅すぱあとミドルウェアの開発
  • 会社の背景
    • 設立39年
    • 成熟している
    • ドラッカーさん => 捨て去る勇気
    • 小さな風穴を開ける仕事
  • アジャイル
  • 夕会
    • 帰る宣言ができる
  • カンバン
    • どんどん自分たちでカイゼン
    • 会社が続くと形骸化する
    • すくらむでも同じ => 自分たちでルールを棚卸しできる
  • 上司評価
    • 部下に上司(この場合は新井氏)を評価してもらう
  • 焼き肉メソッド
    • メンバーが多くなって毎月開催できなくなった
  • 部署間で人材交換・交流
    • 2wだけメンバー交換
    • スキル・文化の相乗効果
  • try 100
    • 100件の大小な様々な問題解決で社内貢献
    • 半期で300超え
  • TechLounch
  • カイゼン ビアバッシュ
  • 経営的なところにアジャイルなあれこれをやってみた
  • 在宅勤務
    • すくらむでチケットベース開発
    • ちょうどいい仕事加減
  • 毎月LT
  • 管理部の朝会&KPT
  • これらの話は3年前までやってなかった
  • 他人は変えられない => 自分は変えられる
  • ぼっちはどうするか => 社外にHELP!
  • 変化を起こす最高のカード => 著名人を招く
  • コミュニティに感謝!
  • 続けることの大事さ
    • 会社のミッションとビジョン
    • 仮想的にCEOとなって会社のミッションを煮詰めていった
    • キー・コンセプト
      • ゼロアクション
      • ワンクリックの先へ
  • 言いたいことは => 学びつつける、そのために動いていく
  • メンバーがイキイキしている顔はかっこいい
  • 人間は保守的になる => それをぶちやぶっていく

「Product/Market Fitに至る道での悩ましい話(仮)」篠原 徳隆氏

  • 基幹システムから駅すぱあとへ。そこから営業に。
  • 今は新規事業立案的なところに。
  • JAWS-UG MATCHIMAKER
  • Chrono
    • グルメキュレーションアプリ
    • 検索をせずに合ったお店で食事ができるように
    • 好きな料理を学習させて、そこからレコメンド
  • Product Market fit
    • 顧客実証から顧客開拓
    • 最適なプロダクトを最適な市場に出せるか
  • ユーザのニーズにあっていて、かつ市場にあっているものはなにか?
  • 指標の選び方 => フェーズで選ぶ
    • AARRR(海賊指標)
    • Retentionが大事と思っている
    • Lean analytics ビジネスモデルとステージで決める
    • point
  • KPIの悩ましい話
    • Chronoは継続に課題がある
    • いくつかやったが大きくドライブするようなKPIがない
    • MVP Canvas
  • KPIがみつからない理由
    • いくつか要素はある
    • 検証環境が成立していない、スコープが大きすぎる
  • KPI見つけたら最大の成果
  • 対会社の新規事業評価が難しい
    • 平均値に合わせて、下限・上限の一定範囲内で評価
    • どこかで結果評価を出さなければならない
      • リテンションカーブ
  • 実践あるのみ
    • 計測を重視するようになって、考え方が変わった
    • エビデンスが示せないものはどこか破綻している
    • KPIはきっちり決める必要あり

雑感

駅すぱあとと言えば、ずいぶんと長い間稼働している印象があるわけですが消費税3%の対応とかを経てここまで稼働しているというところがまず驚きでしたねぇ。コアの部分は完全に秘伝のタレ状態らしくそれを打開するためにも……というDSL導入に向けての話があったり、運賃計算はやはり泥沼であるという言葉は多少なりとも業界に関わった身としては涙なしには聴けない話でした。

一方でAWS導入の中でインフラ部門との関係を改善していったり、アジャイルやるための試みなど長く続く会社の停滞感をなくしていこうというその熱い気持ちはかなり勉強になりました。

後はICカード周りの話はテストがおそろしいことになってそうで……すでにICカードでの運賃と切符での運賃が異なってますが(駅すぱあとはそれも対応)、カードの種類で割引とか入り出すとちょっとぞっとする事態になりそうですなぁ。

というところで非常に面白い話が聞けたので、この場を提供していただいたDevLove関西とヴァル研究所のかたがたに御礼を申し上げつつ筆を置きたいと思います。