超久々のITイベントへのオフライン参加ということで、いつも技術記事でお世話になっているクラスメソッドさんのイベント「DevelopersIO DayOne」に行ってきました。
ということで、そこで取ったメモなんかからこのイベントの私的備忘を書いてみたいと思います。

DevelopersIO DayOneって？

AWSに関する色々や今回だとchatGPTに関するセッション盛りだくさんの聴講型イベントです。
クラスメソッドさんのオフィス「日比谷フォートタワー」内で行われました。日比谷フォートタワー26階、オフィスキレイ！！夜景きれい！！クラスメソッドさんオサレすぎる。
イベントはお酒やフードもあり、和やかな雰囲気で開催されました。

聞いたセッション

複数会場で複数セッションが同時実行されていた中、私が聞いたセッションは以下
★事例で学ぶ!! 東急様のLINE施策と技術課題へのアプローチ
・ChatGPT元年 〜ChatGPTで変わるエンジニアリング〜
・prismatixでのTerraform運用で活用している＆しようとしているツールの紹介
・Introducing DevSecOps in CI/CD
★モノリスかマイクロサービスか、その選択に迷っている人へ届けたい話

以下に参加した各セッションを聞いて思ったことを書いてます。セッション内容自体の記載はありません。↑で★がついているもののみです。
他は気力がわいたら追記します・・・。

各セッションのメモ

【事例で学ぶ!! 東急様のLINE施策と技術課題へのアプローチ】

東急がクラスメソッドさんと組んで実施したLINEを使ったユーザ施策に関するセッション。
東急で持っているデータ（ファイル含む）とLINEからユーザが登録したデータをマージして、LINEアプリを使った施策に活かす、それに対するビジネス的な観点、技術的な観点に関して話されてました。

以下、聞いてて印象的だったポイント。
東急さんって大企業だし、大企業のシステム部門ってガチガチに固められてて腰が重いイメージで、同じかなって思っていたのが印象がらりと変わったセッションでした。

・達したい結果が実現できる、その時できることからやっていく
　データがファイルで手動出力でシステム化は時間がかかるのでS3にアップロードするPowerShellを組んで実行していた、とか。思想にあったシステム化が終わってからローンチじゃなく、結果に対して最速で出来ることを実装してローンチしてそこから育てる。

・LINEでポイントカードアプリ作り、TOKYUポイントと楽天ポイント統合してユーザも店舗スタッフも時短
　TOKYUポイントと楽天ポイント紐づけてアプリ一回のスキャンで両方にポイントが付与。ユーザはアプリ出すだけでOK、店舗スタッフもPOSで一回スキャンするだけでOK、両方の時間削減が実現。
店舗スタッフのスキャンが一回減ると3～5秒の時短ができる⇒積み上多羅年間時間が33万時間(って言ってた気がする)削減になったとのこと。
動作ステップ数を以下に減らすかはユーザビリティに大きな要因になるとは思っていたけど、業務側スタッフについても同じ、というのは「なるほど」と納得。これがDXだなぁ、と。

・フィーチャーフラグによる機能ON/OFFで本番環境のみ構成でテスト実現
　関連する外部システムの制限で本番環境以外でやりたいテストが難しい、でも本番一発勝負は・・・という問題をフィーチャーフラグで乗り越えた、という話。あとはこれで「限定ユーザだけでテスト」というのも実施したとのこと。
フラグをDynamoDBで管理している、というのが「なるほど」でした。コストやレイテンシーの問題も込みでDynamoDBにした、ってことですが外部にフラグを持っていれば切り替え容易だし、事故も少なそう。
選択肢は「App Config」「CLoudWatch Evidently」「DynamoDB」だったそうです。
あとフィーチャーフラグは検証が終わったり、動作の安定の確証が取れれば都度削除していく、とのこと。不要なフィーチャーフラグが残ると技術負債になるので、重要なステップだなと思いました。

・その他LINEアプリの機能
これは私がLINEの機能を分かってないので聞いて「ほー」っとなったもの。
　・セグメント配信
　・プロバイダ機能（複数の公式アカウントのグループ化）
　　⇒複数アカウントで同時に共同キャンペーンができたり。

【モノリスかマイクロサービスか、その選択に迷っている人へ届けたい話】

セッション時の資料が公開されてます。

・モノリスは悪くない。
「モノリス＝悪」ではない。「モノリス＝レガシー」じゃない。
悪いのは「大きな泥だんご」であること。自社のシステムが「マイクロサービスがいいんじゃないか」と考える前に、自社のシステムが「大きな泥だんごかどうか」を確認するほうがいい。
大きな泥団子要素は一言で言うと「スパゲッティ」
　・アーキテクチャが明確に存在しない
　・コード内の機能に境界線がない
　・場当たりな構造化が無秩序に広がる
　・冗長で無差別な共有
　・度重なる急場しのぎの修繕
最後の「急場しのぎ」はシステムが運用されていく中で絶対に出てくる、それはどうしようもない。からせめてその影響を最小限にする、とかリファクタリングするとか「やって終わり」にならないようにするべき。
他は防ぐ（最低限その努力と意識をする）べき。

・本当にマイクロサービスである必要があるか？
エンジニアはマイクロサービスやりたいって思う。けど、本当に「マイクロサービスである必要があるか？」は自社のシステムが
　・マイクロサービスの特性（メリットもデメリットも）を飲み込めるか
　・ユーザから見て必要なのか
　・他の方法は無かったのか
を冷静に見極めるべき。
あとKPIも設定するといいよ。モチベーションの問題と経営層への説明と色々あるよね。
「モジュラーモノリス」という選択肢

・マイクロサービス＝分散システムで罠があるよ
以下は罠の代表例（これは全部ちがうよってやつ）。これを頭から除外しないと爆死するよというもの。
　・ネットワークは信頼できる
　・レイテンシはゼロである
　・帯域幅は無限である
　・ネットワークは安全である
　・トポロジは変化しない
　・管理者は一人である
　・転送コストはゼロである
　・ネットワークは均質である

・マイクロサービス導入は＝組織作り
The twelve factor appをチーム全員がそらで言えるくらいじゃないと実現は無理。
[ネガティブな原因]
・コンウェイの法則のやつ
　　有名ワード：組織が設計するシステムはその組織自体のコミュニケーション構造を反映する。
　　法則の続き：大規模システム崩壊の3ステップ。組織の圧力、経営陣の
　　　　　　　　型にはまる
・ルースさんのやつ
　　システムのアーキテクチャと組織のアーキテクチャが対立する場合、
　　組織のアーキテクチャが勝つ
[対抗策]
・逆コンウェイ戦略

[The twelve factor app]

さいごに

とてもいいイベントでした。
技術的なことには必ずビジネス的なこと、組織的なこともセットになりますが、そういったことも今回色々聞いて考えることが出来る場だったと思います。

2023/7/7、7/8にDevelopersIO 2023が2Day開催で確定だって！
参加必須だな。