こんにちは、サービスチームの日下です。

9月6日〜9月8日にかけて開催された『builderscon tokyo 2018』に参加してきました！
buildersconは技術的な制約のない、様々なテーマのトークを聞けるとても濃密な内容のカンファレンスです。

buildersconではトークに関して技術的な制約はありません。特定のプログラミング言語や技術スタックによるくくりも設けません。必要なのは技術者達に刺激を与えワクワクさせてくれるアイデアのみです。
builderscon.io

この記事では、私が聞いた発表の中でも今興味を持っている「サービス開発」に関わるものを御紹介します。

パスワードレスなユーザー認証時代を迎えるためにサービス開発者がしなければならないこと

パスワードを使用しないユーザー認証方法、「パスワードレス」の現状・課題についての発表です。

そもそもパスワードを使用した認証は何が問題でしょうか？パスワードは特定デバイスに依存しない最強の認証方式ではないのでしょうか？
しかし、ユーザーはパスワードに簡単な文字列を設定し、使い回してしまう事があります。さらにはパスワードを要求するサービス側が、文字数を制限する等の制約をかけてしまう事もあります。
これらの問題は、パスワードがユーザーへ負担をかけているという事であり解決すべきものです。そんな状況だからこそ「パスワードレス」は来たるべき未来となっています。

実際のパスワードレスの現状を見てみると、実現するためにFIDO 2.0という仕様が策定されています。また、Web仕様としてWebAuthn APIが存在します。
このWebAuthn APIを実装したデモサイトwebauthn.orgを使用した解説も発表の中で行われました。

ただ、パスワードレスを実現しても我々サービス開発者が考えなければならない事はあります。それは既にパスワードを使用している既存サービスへの対応であったり、パスワードを使用しない事によるユーザー体験への変化にどう対応するか等様々です。

弊社のサービスにもパスワードレスの波がやってきた時に、どういう対応が求められるのか考えさせられる発表でした。

Webサービスにて200週連続で新機能をリリースする舞台裏

builderscon.io
speakerdeck.com

200週連続リリースという偉業を成し遂げられた訳、これからどうするのかという内容でした。

対象サービスMackerelはとても小さなサービスとしてスタートし、顧客獲得の大きな武器として連続リリースがあったそうです。
実際、1つのサービスに200週連続で「新機能」をリリースするのは驚異的だと思いますし、とても強みだと感じます。

実現できた理由として、連続リリースをチームの最重要事項にするのはもちろん、エンジニアに余力を持たせる（自主的な活動ができる余地を残す）、チームのスキルバランスを常に把握するなどの様々な工夫が施されていたのが印象的でした。
また、個人的にはプロダクトオーナーが3年の長期ロードマップ、四半期ごとの中期ロードマップを作成している事が凄い重要な事だと思いました。200週の連続リリースを達成してもサービスの方向性がブレないのは、そのような導きがあってこそだと思います。

200週連続リリースを機に連続リリースは終了するそうですが、より価値に集中するためらしく、サービスの成長への熱意がとても感じられる発表でした。

ボクが考える i18n の未来

builderscon.io
speakerdeck.com

i18nの現状・問題について解説後、次世代のi18n対応について考察する内容です。

i18n対応は面倒ですが、ハードコーディングをしていると後に大変な事になったり、考えていないUIデザインをしていると再設計が必要になったりしてしまいます。

i18nは現状プログラミング、フレームワーク、文字コード、ライブラリ、フォント、絵文字に至るまで幅広くサポートされるようになってきています。
しかし、発表中にも言及された以下の記事のように「完璧」なi18n対応はとてもとても難しいものです。 qiita.com また、プロジェクト固有のエッジケースがある場合は開発者が頑張るしかなく、i18n対応自体が開発者を疲弊させてしまう問題があります。

そこで、開発にフォーカスした次世代のi18nのソリューションについての考察が発表されていました。
次世代のi18n対応にはUsability、Maintainability、Testability、Extendability、Integrityの5つの要素が不可欠としています。
その要素を満たす解決策として、提案されていた内容は以下の2つです。

i18nのSaaS
i18nフレームワーク

特に具体的に説明されていたのがi18nフレームワークでした。
i18nフレームワークは、要求に応じて解決手段が異なるプログレッシブフレームワークであるべきで、問題に応じて公式のライブラリが用意されているべきとしています。また、アーキテクチャもプラグインシステムとして機能を自由に拡張できるものが良いとしていました。
確かに多種多様な対応が要求されるi18n対応では、ビジネスの段階や問題に応じて柔軟な対応ができるべきだと私も思います。まだ考察の段階ではありますが、とても実現が望まれるアイデアなのではないかと感じました。

弊社もFoodJobJapan等の多言語対応のサービスを開発しており、開発が進んでも辛くならないi18n対応について考える必要がありそうです。 foodjobjapan.com