読者です 読者をやめる 読者になる 読者になる

Chonaso's Commentary

InternetやIT技術などについて知ったこと、試したこと、考えたことを書いていきます。

#DevLOVE 「駅すぱあと」を支える開発 〜9262の可能性を繋げ!〜に行ってきました

勉強会

Dev:Ops:Biz=2:7:1くらいな今日この頃、DevLOVE勉強会に参加してきました。

駅すぱあと」を支える開発 〜9262の可能性を繋げ!〜 http://devlove.doorkeeper.jp/events/10713

1988年に首都圏版が生まれて四半世紀突破、形態を変えつつも未だ第一線、もはやインフラの一部と化している「駅すぱあと」。 私の世代だとメーカーPCのバンドルというイメージが強いですが、20代以下の方にとってはWebサービスやアプリのイメージが強いのではないでしょうか。


「『駅すぱあと』を解剖します」

(取締役兼開発本部長 宮本氏)

基調講演に近い雰囲気でしたが、「駅すぱあと」の歴史や裏話など。

この分野の草分けだった故の悩みというのはあるもので、やはりお手本がないというのは想像しただけで(想像しづらいけど)怖いものです。

とはいえ、「案ずるより産むが易し」な部分も多かったらしく、 「首都圏版作っただけで640KB*1めいっぱい使ったのに全国版なんてムリ!」と思ったけど全国の特急路線図みたら案外少ない(からやれそう)だと感じた、というところなど、結果だけ見れば些細な引っかかり方をするんだなぁという感想です。

この分野ならでは、と思ったのが以下の部分。(意訳してます)

「要らないを判断する」サイエンスがない。 経路探索はメモリがあればいくらでも検索できるし結果は無数に出てくる。 無駄を省く、最適ではないものを捨てる技術が求められる。

明確な答えには言及がありませんでしたが、技術的なところでいえばその時々の最適なラインがあるのだと思います。

ちなみに経路探索のアルゴリズムは基本的な部分は当初にほぼ固まっているようで、進化と共にコード量は増えていても、今でも昔のコードがいくらか残っているとのこと。


「『駅すぱあと』新しい開発基盤の研究」

(R&D Centre ソフトウェアエンジニア プロダクトチーフ 佐藤氏)

GitHub+Jenkinsでの自動テストでずいぶん楽になりましたよー、ってな話はそこそこにDSLな話。

運賃計算は「基本ルール+大量の特例」で構成されています。

これに対し、今はそれぞれの特例をプログラムでがんばっているが関数設計を工夫しても保守性に限界があり、生産性の向上のためにDSLを用いようとしているとのことです。

DSLのメリット

  • ビジネスロジックより抽象度の高い言語で表現
  • ドメインエキスパートとのコミュニケーション改善
  • 特化言語なら開発者以外でも理解しやすい

DSLを使わないケース

  • エンジニアの習得コストが高い
  • メンテナンスコストがかかる

例として「Ruleを基底としたConditionとActionのコンポジション」が紹介されました。

DSLで大事なポイントや注意点

  • 問題と解決方法のモデル化(抽象化)
  • 表現力を限定する(なんでもできるようにしない)
  • 一般的な作法(文法/記法)に倣いつつも、専門用語は積極的に使う

この話を聞いていて、8年くらい前にとあるパッケージの機能追加でパターンロジックの追加を柔軟に行うためにXMLとロジックのインタフェースを規定したことを思い出して、「ああ、あれがDSLだったか」と追憶しました。


「開発者が導入するAWS -ヴァル研究所の場合(仮)」

(開発部 Webサービスチーム リーダー 見川氏)

インフラ担当部署はコンサバでイマイチ頼れない。よろしい、ならばAWSだ的な流れでAWS導入をすすめていった、という話。

AWSを社内への導入推進ために

  • 社内勉強会などで支持者を増やした
  • 自分たちで使って実績を作る

得られたもの

  • 運用に割かれる時間の削減
  • 構成の自由度
  • テスト環境の調達が早い
  • 安定稼動
  • 今まで試せなかったことも試せるようになった
  • 新サービス、プロダクトの投入速度も向上

一方、コストも(上がった?)...というところでしたが、コスト削減が主目的ではない、と。 コストに踏み込むのであれば現状のデータセンタやVPSなど(ある意味)二重化になっている部分をどうするか、というところがポイント。


「手探りで始めた企業内スタートアップで嵌まったことベスト54」

(Business DevelopmentDepartment 部長 篠原氏)

リーンスタートアップについてのハマったことについてですが… すみません、全くの門外漢なので特に言及しません。

メモは取ったので、「RUNNING LEAN」「スタートアップマニュアル」を読んでから見直します… やっぱり企画にはエンジニア混ざってないとだめだよね…と思った次第。


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

(R&D Centre 部長 新井氏)

社内に小さな風穴を開ける取り組みについて。

気になったものをピックアップ。

  • 夕会(「これやったら教は帰ります」が明確にできる)
  • 個人目標の公開(メンバーの承諾のもと張り出し)
  • カンバン(タスクが増えると形骸化していくね…)
  • 在宅勤務(半分在宅・半分出社、チケットベースでタスクを消化)
  • TechLunch
  • 著名人を招く(コミュニティなどを通じてお願いした)

社内、というか部署内にこういう盛り上げ役というか熱い人がいるといいですね…、とかいうと「自分がそうなれよ!」って怒られそう。 正に「他人は変えられない、自分が変わる」ですね。


肩書き的に偉い方が多かったのですが、こういう場できちんと話せる人が多い会社っていいなぁ、と感じました。

「駅すぱあと」風雲録

「駅すぱあと」風雲録

駅すぱあと(Windows)年間サポート付2014-2015

駅すぱあと(Windows)年間サポート付2014-2015

ヴァル研究所 駅すぱあと(Windows)2014年4月

ヴァル研究所 駅すぱあと(Windows)2014年4月

*1:当時のプラットフォームであるPC-9801ではメインメモリが640KB(MBじゃないよ!)で、「640KBの壁」などとも呼ばれていました。