builderscon tokyo 2019 で「時を正しく扱うシステム設計」を発表しました
8月29日から31日にかけて東京電機大学 東京千住キャンパスで開催されたbuilderscon tokyo 2019に登壇し「時を正しく扱うシステム設計」というタイトルで発表しました。
時を正しく扱うためのシステム設計
私はアルプ株式会社でサブスクリプションビジネスのSaaSをドメイン駆動設計の手法を取り入れながら開発しているのですが、業務でドメインモデリングをしていく中で、知識としては小学生でも知っているような時間というドメインにも、サブスクリプションという観点で見たときに新しい気付きがあったり、その観点で検索しても欲しい情報が見つからないという経験がありました。
この学びはこれから同じ課題と向き合う未来の誰かの役に立つかもしれないし、すでに同じ課題と向き合った先駆者がいれば知恵を借りて一緒に考えたい。そう考えて応募しました。
発表後のQAは核心を突いた質問ばかりが飛んできて、伝えたいことが伝わったようで安心しました。
「日付でもUNIXTIMEで保存するべきだ」という主張をいただけるかと思っていたのですが、いい意味で期待を裏切られました。
自分が気付いていなかった視点も得ることができて、質問者の皆様にはとても感謝しています。
例えば、発表では考慮が漏れていた前提があって、それは今回題材としたサービスがSaaSであることです。
「1ヶ月後を計算するとき1日〜28日始まりであれば月末を考慮する必要はないのでは？」という質問で回答しましたが、利用期限や請求日の仕様を自社で決定できるような性質のサービスである場合は、そのような仕様の制限によって発表で紹介したような月末の複雑さを回避することができます。
しかしSaaSにおいてシステムの都合で仕様を制限することは、月末で処理したいユーザを切り捨てることになってしまいます。
つまり、発表で紹介したような月末のロジックはSaaSという領域においては特に問題になるということです。
サブスクリプションサービスによっては「第X週目のX曜日」というロジックで月単位の周期を決定しているサービスもありますし、毎月1度だけ提供される行政サービスでも「第X週目のY曜日」が多いですね。
そういった事例や回避策を紹介できればよかったのですが、SaaSである前提をすっかり失念していて、資料に盛り込むことができませんでした。
改めて、ご質問ありがとうございました。
もう一つ伝えたかったテーマが、身近な常識の中のDiscover Something Newでした。
今年はちょうど改元という大きなイベントもあり、時間によって生じるシステムの対応が話題になりました。
元号をデータとして保存するべきではないことをシステムエンジニアは直感的に理解できる常識かもしれませんが、その理由を言語化しようとしたとき、これは意外に難しいと思ったのです。
私が言語化した元号をデータとして保存するべきではない理由は、発表資料にありますのでご覧ください。
アルプ株式会社ではScalaを使いオブジェクト指向を取り入れた設計をしているのですが、私たちはよく「これは状態を持っているから複雑になる」「複数のステータスを持つならオブジェクトは分けた方がよいのでは？」といった議論をします。
ではなぜ状態を持つのかというと、時間の経過が対象を変化させるからなんですね。
そんなことは当たり前だと思われるかもしれないんですが、私はこのことを最近になって認識しました。私はこれまで状態やステータスを時間軸と分断して論じていたわけです。
思えば、ニュートンが重力を発見したとき、当時から誰の身の回りにも重力は存在したわけですが、誰も重力を認識できていなかったわけですし、だからこそ大きな発見だったわけです。重量の発見を例にするのは恐縮の極みなのですが、身近にある対象への気付きは実は大きなDiscover Something Newかもしれません。
システムで時間を取り扱うときによく語られるタイムゾーンやサマータイムといったメジャーな問題だけでなく、サブスクリプションという領域での問題を紹介することで、身近な時間というドメインについて考えるキッカケになったり、何かのヒントになれば嬉しいです。
プログラミング言語プロレス
ライトニングトークでは「プログラミング言語プロレス」も発表させてもらいました。今年のScalaMatsuri 2019のアンカンファレンスで行ったパネルディスカッション「Simple VS Easy」を紹介しました。
伝えたかったことは発表資料の通りなのですが、付け加えるならば、インターネットで議論するよりも会って議論する方が伝わることもあるということです。
インターネットでの対立や炎上への意見を読んでいると、言いたいことは本当に伝わっているのだろうか、問題意識は共有しているのだろうかと思うことがあります。
コミュニケーションは本当に難しいです。
技術カンファレンスのような人が集まる場を活用して、技術的な対立をテーマにディスカッション、つまりプロレスすることは相互理解を深める手法として有効なのではないかと思っています。
ファシリテーターやレフェリーが必要になったらいつでも呼んでください！
エンジニア募集中
アルプ株式会社ではエンジニアを募集しています。
おわりに
ブログを書くまでがbuildersconということで、このエントリをもって私のbuilderscon tokyo 2019をクロージングとさせていただきます。
参加者、発表者、スタッフのみなさん、おつかれさまでした！
楽しいカンファレンスをありがとうございました！
この記事が気に入ったらサポートをしてみませんか？