Developers Summit 2020 2日目の感想

この記事の後編です。

参加したセッション

２日目に参加したセッションはこんな感じでした。

10:00～10:45　「ともにつくる」を実践するドメイン駆動設計

11:05～11:50　守りのモニタリングから攻めのモニタリングへ

12:10～12:40　A retro on agile ー アジャイルをふりかえる

13:05～13:50　問題から目を背けず取り組んでいく ･･･ 一休のこれまで

14:10～14:55　クラウド・ネイティブ時代に最適なJavaベースのマイクロサービス・フレームワーク ～ Helidonの実力を見極めろ！

15:15～16:00　オープンソースのこれまでとこれから

16:20～17:05　月間約10億件のクラッシュデータから見えたアプリ品質の実態！ エンジニアが仕掛ける、『ONE TEAMで挑む、賢いアプリの品質管理』とは？

17:25～18:25　雲の中心で愛を叫ぶ！ クラウド横断パネルディスカッション

２日目も盛り沢山な内容ですね。さっそく感想を書いていきます。

「ともにつくる」を実践するドメイン駆動設計

ドメイン駆動設計については、元となったEvans本も読みましたし、自分でも気になっていろいろ試しています。

そんなドメイン駆動設計を、ドメインって何？ユビキタス言語って何？という基本的な部分からグラフィカルにわかりやすく解説していただきました。

ドメイン駆動設計は対話が大事だなと改めて思いました。ドメインエキスパートと会話して、使う言葉の定義だったり意味だったりを共通認識しっかり持ってやっていかないと、なんちゃってドメイン駆動になりかねないなと。

私の前職はSIerだったんですが、SIをやっていると自分に業務知識が無い分野の開発をやるというのはよくあるので、そういうときはその分野のプロであるお客様を巻き込んで設計していく必要がありますね。

守りのモニタリングから攻めのモニタリングへ

New Relicは初めて知ったんですが、ここまでモニタリングできるのか、と驚きの連続でしたね。

例えばパフォーマンスは最近の自分の悩みのタネで、テストで性能が出ないとどこにボトルネックがあるのか探すのに非常に苦労しています。また、テストで問題なかったのに、本番で（データの頻度や属性など考慮しきれなかった部分の差異により）性能劣化することもよくあって、そのときもどこが問題なのかいろいろログを仕込んだり調べるのにかなり手間がかかります。

NewRelicでは（例えばJavaであれば）JVM内部と外部通信の時間を分けて確認できたり、どのメソッドが何回呼ばれてどれだけ時間がかかっているかも確認できていました。また、１回のトランザクションで、あるメソッドが何回呼ばれているかも見ることができるので、n+1問題のような呼び出し回数が過多になることによる性能劣化も発見しやすくなっています。

普段からこれだけいろいろなメトリクスを計測できていれば、わずかな異常についても事故として顕在化する前にいち早く気づいて対策を打てたり、いろいろ夢が広がりますね。

A retro on agile ー アジャイルをふりかえる

様々なプロジェクトにおいてアジャイルの開発をふりかえってみて得られた知見を共有していただきました。

面白かったのはクネビンのフレームワークという考え方ですね。

問題を単純、煩雑、複雑、カオスの４つの領域に分けてそれぞれの状況に応じたアプローチを取りましょうという考え方です。例えば単純でやることがわかりきっている問題についてはウォーターフォール的な開発がフィットしますし、複雑な問題については仮説検証を繰り返していくアジャイル的な開発が合いそうです。

問題の性質を取り違えると混乱の谷に落ちてしまうということで、しっかり性質をとらえてアプローチしていきたいです。

チームヘルスモニターも面白い試みだと思いました。プロジェクトで必要な様々な要素（知識が共有されている、役割分担がしっかりできているなど）に対して、各自がどのように感じているか３段階で評価していきます。そして評価が悪かったところや、メンバーどうしの評価が割れたところなどを中心に改善策を話していくという試みです。

問題から目を背けず取り組んでいく ･･･ 一休のこれまで

厄介な問題に目を背けてはいけない、ということを痛感させられる内容でした。

冒頭、エンジニアが働きやすくなれば会社の問題は本当に解決するのか、という問題提起から始まりました。チームの状態がよくなれば、物事がうまくいくというのは悪魔の誘惑で、プロダクトの問題、事業の問題、技術の問題などより難易度の高い問題から目を背ける言い訳になってしまうと。

このプレゼンでは一休において実施した問題解決などを振り返って、目を背けず問題に取り組むことや、問題に合った対応をしていくことの重要さを教えていただきました。

最初は難易度が低いものから順番にやっていたそうです。そして、どんどん改善が進んで良くなっていくので、いつか大きな問題もこんな感じで解決できるんじゃないか、と思ってしまいがちになるんですが、実際にはそんなことはないという現実に気づいたことがよかったと振り返っています。

興味深かったのが、以前に一休でうまくいかなかったシステム更改の事例でしたね。一度にシステムを全刷新するというやり方で取り組んだ結果、リニューアルに対する期待が高まりすぎて大小あらゆる案件がきてしまい、規模が大きくなって収束にとても苦労したそうです。

私も似たような経験があり、親近感を持って聞くことができました。

このような問題に対してはなんの問題を解決したいのかフォーカスをしっかりして、スコープを絞り込むことが重要ということでした。

複雑な問題に対して一般解は無いので、現状をしっかり理解し、それをどうしていきたいかをしっかり分析して、それによって問題に適したアーキテクチャ・戦略を作り込んでいくという作業が大事だということでした。

チームビルディングによって問題を解決するのではなく、問題を解決する過程でそうしたほうがよかったからそうした、結果問題は解決されたという流れであれば誰も文句は言わないという意見はなるほどなと深く関心しました。

クラウド・ネイティブ時代に最適なJavaベースのマイクロサービス・フレームワーク ～ Helidonの実力を見極めろ！

JavaにおいてもGraal VMの登場などによって、マイクロサービス・クラウドネイティブという言葉が盛り上がっている印象を受けています。

Helidonはマイクロサービスを開発するためのJavaライブラリで、Docker/Kubernatesでデプロイが可能です。SEバージョンとMPバージョンという２種類のバージョンがあり、SEバージョンはGraalVMのネイティブイメージに対応しています。MP版はEclipse Microprofile準拠という特徴があり、将来的にはGraalVMのネイティブイメージにも対応する計画があるそうです。

MP版はKubernetesのヘルスチェックや、トレーシングなどがアノテーションベースで記述できて良さそうに見えましたね。一方でSE版についてもNetty上にリアクティブAPIを使って構築できるということで、どちらを使うのかは検討が必要そうな感じです。

いろいろ機能を紹介していただきましたが、使ってみなければわからない部分も多いので近いうちに触ってみたいですね。

オープンソースのこれまでとこれから

オープンソースの歴史を振り返りながら、オープンソースが今後繁栄していくためにはどうしたら良いかいろいろ考えを披露していただきました。

昔はベンダ主体で進めていましたが、今はユーザー企業（技術じゃなくて別のものをメインで売っている。Amazon, Facebook, Netflix, etc)主体で進んでいるというのは改めて言われると興味深いですね。ユーザー企業の方が面白い問題に直面しているので、その解決に使った技術をオープンソースにする流れがきているそうです。

オープンソースを進めるにあたって、決して慈善事業では無く、メリットを主張することが大事と述べていました。業務としてオープンソースに関わる場合は当然、何かしら利益につながるメリットが必要になるのでこの視点は重要だと思います。

メリットとして、コストの圧縮、開発者のリクルーティング、従業員満足などが挙げられていました。戦略の大事さを強調されていて、いかに新しいビジネスチャンスを見つけて周囲を巻き込んでいくかがポイントになりそうです。

ただ待っていてもプルリクが来るわけでは無いので同業他社と仲良くするプロセスが必要だったり、他部署も含めて全社的にバックアップする体制が必要だったり、いろいろ泥臭い活動が必要なんだなと思いました。

月間約10億件のクラッシュデータから見えたアプリ品質の実態！ エンジニアが仕掛ける、『ONE TEAMで挑む、賢いアプリの品質管理』とは？

モバイルアプリは作ったことがないので、そもそもどうしてクラッシュが発生するかという部分から興味を持って聞けました。確かにOSも端末も無数に存在する状況で、全てをテストするのは無理ですよね……

NewRelicさんの話にも通じますが、普段からいかにいろいろな情報をモニタリングして、異常にすぐ気づける・改善できる体制になっているかというのは改善を高速に進めていくには不可欠だと感じましたね。

Froskさんのツールでもクラッシュのリアルタイム検知、クラッシュしたときの画面のスクリーンショットや端末情報、エラーのスタックトレースなど様々な情報が確認できたり、フィルターを用いて絞り込みができるそうです。

クラッシュがあると明確に継続率が低下するということで、クラッシュ率のモニタリングというのはモバイルアプリ開発には不可欠だなと思いました。

雲の中心で愛を叫ぶ！ クラウド横断パネルディスカッション

AWS, Azure, GCPそれぞれをこよなく愛するエンジニアが本音でディスカッションするなかなか面白いイベントでした。いろいろぶっちゃけ話が聞けて、こういう企画は良いですね。

AWSはやっぱりコンポーネント多すぎるよね、とか、いやだからこそどんなニーズにも応えられるみたいな話とか面白いですね。AWSはやっぱり使っている人が多いという部分が最大のメリットな気はしています。

それぞれのクラウドの勉強法については、資格試験がいろいろ網羅されていて効果的という話はしていました。全てを勉強し尽くすのは無理なので、自分の守備範囲を認識して勉強することが大事というところはみなさん共通していました。

また、クラウドにおいてもネットワークやインフラまわりの低レイヤの知識は重要ということで、基礎をおろそかにしないことだ大事だなと思いました。

私はHerokuを個人開発で使っているんですが、これらのメジャーなパブリッククラウドにもそろそろ手を出してみたいですね。なかなか、料金がいくらぐらいかかるか見えてこないので及び腰にはなっていますが……