#概要
2021/10/27に行われたAWS Innovate- Modern Applications Editionのモダナイゼーションに関するセッションを視聴した際の、個人的に印象に残ったことを書きます。

###ステップバイステップで始めるモダナイゼーション

モダナイズはお客さんのビジネスを達成する手段
→「モダンアプリケーション作りたい！だってかっこいいから！」と思っていたが、お客さんが実験を短いサイクルで繰り返してイノベーションを起こすことで他社との差別化を図り、ビジネスの成功を納める手段だということをすっかり失念していた。Amazonは口酸っぱく言ってるけど、顧客目線で考えないと本当に道を誤りそう。でも、技術のことを勉強しつつお客さんのことも勉強するのは大変そうだ。

モダナイズは移行戦略の一部
→古いアーキテクチャは悪！絶対モダナイズすべき！というイメージを勝手に持っていたがあくまで移行戦略の一つでありリホストなども選択肢に入るという話を聞き、結局はお客さんや環境との相談になるのかぁ‥と思った。結局、顧客目線で提案することが大事？

モダナイズの手段としてコンテナを採用する
→資格勉強の時からコンテナに苦手意識があり避けてきたが、こんなに大切だと思わなかった。
モダンアプリケーションがどんどん採用されるなら、コンテナも理解してないとやばいと思った。コンテナのメリットは頭では理解できてるけど実感できていない。
例えば、「仮想マシンと違って軽量」、「ホストとコンテナのOSが一致していればどの環境でも実行できる」などは本当に腑に落ちた感じがしない。何か良いハンズオンはないだろうか‥。

###マイクロサービスとストラングラーフィグパターンを活用してモダナイズを進めよう

モダナイズをする時の手法としてメトリクス、ログ、トレースなど現在のシステムの情報を集める
→集めた情報がアプリを改修する際の目標値になる‥という話が印象に残った。
先日受けた問題解決の研修でも、数値化した目標がなければ問題解決の効果を測定出来ないという話があり、似たような物を感じた。(モダナイズもやっていることは顧客の問題解決だから当たり前か)
でも具体的にどんな数値を目標値にすれば良いのかイマイチ分からなかった。パッと思いつくのは応答速度とかだけど‥。

説明スライドで、rdsのスキーマをdynamodbに変換する役割としてAmazon DMSが使われていたこと
→オンプレからAWSへのDB移行に使用されるイメージが強かったため、アーキテクチャの一部として使えることが新鮮だった。確かに継続的レプリケーションはできるから使えそう。

マイクロサービス化するサービスの選び方について
→切り出しやすく、切り出して価値が高まるサービスを選ぶ‥という説明だった。
この考え方も問題解決でやった重要度と緊急度のマトリクスに似てる。マトリクスの考え方は身につけた方が良さそう。例えば昼食を選ぶ時も値段×ヘルシーさ‥などで選ぶ癖をつけると練習になるかも。

切り出して価値が高まるサービスは、具体的にどんな定義なんだろう。
「今、利用者が多数いる」
「将来、利用者が増加する」
くらいしか思いつかない‥。

###特別公演

社会問題と、それに対するお客さん会社の姿勢
→話の中ではアメリカ社会の変化に対して金融機関がどのように変化していくか、それに伴いシステムはどう変化するのかを解説していた。話がアメリカのコロナや人種差別から始まった時は「話のスケール大きすぎだろ‥」と思ったけど、金融機関は社会問題に対して立ち向かわなければならなかった。今ある社会問題は把握しておき、お客さん会社に関係ありそうな問題は特に注目する必要があると感じた。今まで技術さえ習得出来れば良いと思っていたが、視野を広げないと後々大変そう‥。

クレジットカードの機能
クレカ使ったらSMSで「クレカ使った？」とメッセージ飛んできて、yesと答えたら決済完了する仕組みがあるらしい。不正利用を防ぐのに便利とのこと。確かに非常に便利そうだけど、急いでる時にもその手順踏まなきゃいけないのはしんどいな‥と思ったり。セキュリティと便利さはトレードオフの関係って話が思い出された。

ウェザーニュースのクラウド化事例で出てきた「EC2はクラウドではない」という言葉について
ギクリとした。会社で保守・運用しているシステムはEC2ばかりでコンテナやサーバレスに関する知見が圧倒的に少ない。自分の会社はAWSを取り入れ始めたばかりで、自分は結構AWSに触っている側の人間だと思っていたが社内と比較するのはやめようと思った。広い視野大事。

###エンタープライズにおけるモダナイゼーションプロジェクトの進め方
変化することにはリスクを感じる
→分かる。失敗するのは怖い。でも早めに失敗して成長することが大事だという話も出てきて「確かに‥」となった。自分は失敗することを恐れすぎているのかもしれない。

モダナイゼーションしたい人は多いけど方法が分からない‥という人が多い
→同じ気持ちを持っている人がいっぱいいて良かった。何も分からない状態からAWSのサポートを受けつつどうやってモダナイズに成功したのか事例を読んでみたい。

Experience Based Accelerlation
→モダナイズをする上でAWSが関係者に行うトレーニング。アジャイルの考え方を使い、モダナイゼーションの考え方を身につけることが目的。3日ほどかけてその会社実在するアプリケーションを実際にモダナイズしてみる。関係者が一同に介して行うためモダナイズする際の問題が解決しやすい。
EBAのように、モダナイゼーションのステップには関係者の知識習得も含まれている。

###モダンアプリケーションへの近道～ AWS App Runner のご紹介～

モダンアプリケーションに必要な知識、習得が難しい問題について
→分かる。現状CI/CDもコンテナも分からず何から手をつければ良いのか途方に暮れている。

App Runnerはユーザの要望を聞いて機能追加していく‥という話について
「自動リリース機能、コンテナなど全部セットアップしてくれるのは便利だが、システムをApp Runnerに合うように変える必要がある(RDBをDynamodbに変える‥など)のはちょっとなあ‥」と思っていたが要望を出して機能追加してもらえるなら心強いと思った。

###クロージングセッション

DXに伴う課題について
→企業をサポートすべきシステムが複雑化しすぎて変更が容易ではないことで逆に企業の足を引っ張っているという話が印象的だった。

マイクロサービスのチーム人数について
→two pizza teamという考え方が有ったが、そこまでの人数を雇う余裕がない企業はどうすれば良いのだろうか。複数のサービスを兼業で担当することになり、手が回らず結局サービスに対する責任を果たせない・ということになるのではないかと感じた。

バイモーダル組織について
→モード1とモード2は文化が違って仲悪くなりやすいから仲介役のガーディアンが必要‥という話があった。開発チームと保守チーム、アプリチームとインフラチームみたいに、やっていることや価値観が違うと衝突しやすいのは何でも一緒なんだと思った。

ドメイン駆動設計について
→前から単語だけは聞いたこと有ったが、業務モデルをそのままシステムに落とし込む開発方法だと聞いて驚いた。要件定義など難しそう、お客さんの業務モデルが変わったらシステムも変える必要があるのか？という感想を持った。