ツー

日常の記録

AWS Summit Tokyo 2023に行ってきた

プログラミング

業務で。

報告書を会社に提出するけれど、どうせまとめるなら社会性フィルターを通す前のメモを残しておく。

以下はすべて敬称を省略する。

受付

混むと聞いていたので9時くらいに現地着。そんなに混んでいなかったので受講票と名刺を提示して受付はすんなり終了。受講票とサイレントセッション用のイヤホンを受け取る

基調講演の会場へ移動する途中で弁当の引換券もらった。

ノベルティに会場案内のQRをつけるのはテクノロジー企業っぽい。けど中に物を入れるとQRが歪んで読み取りにくくなるんだよなこれが。

各セッション

DJタイム

基調講演は1030からなので0900に行くとかなり時間の余裕があったが、DJがムーディーな音楽を流して場をつないでいた。

よくよく名前を見てみたらFantastic Plastic Machineの人だった。 こんなところで再び目にすることになるとは。

DJというと、ライブ行くオタクとしてはアッパーでテンションどーーん！という感じではあるが、会場の雰囲気に合わせたしっとりとしたチョイスで飽きなく落ち着いて基調講演までを待つことができた。仕事を感じる。

KEY-01 基調講演

アマゾン ウェブ サービス ジャパン合同会社 代表執行役員社長 長崎 忠雄

  • 4年ぶりの物理開催
  • アメリカ以外でリージョンが二つあるのは日本だけ
  • AWSは機械学習の民主化に注力
    • AWS bedrock 自社用にカスタマイズできるAI
    • AWS Titan Text, Titan Embedding
    • AI学習用のEC2インスタンス Trn1n、Inf2
    • AWS Clean Rooms 機密データを社外関係者のみに簡単に安全に提供
  • データドリブンの会社は30%以上成長率が多い

KDDI株式会社 代表取締役社長CEO 髙橋 誠

  • データドリブン経営
  • αu（アルファユー）でweb3をがんばっていく
  • 社員は真面目なのでデータドリブンにちゃんと取り組んでくれる。けれど縦割りが障害。従来の会社と変わらない。

初代デジタル大臣 自民党デジタル社会推進本部長 平井卓也

  • デジタル田園都市国家構想
  • デジタル庁の組織づくりの要
  • 既存の縦割りに対抗する組織
  • Goverment as a Serviceを目指す
  • 国全体のアーキテクチャの作り直し、クラウド普及の今やるしかない
  • テクノロジーを使っていくことに国民が慣れていかないといけない
  • 経営の判断にエンジニアがもっと関わっていくべきだし、それを応援していきたい

神戸市長 久元 喜造

  • EBPM データに基づく政策立案
    • いままでバラバラに存在していたデータを一か所にまとめる
    • Kobe Data RoungeというダッシュボードをAWS上に作り、様々な視点からデータを自由に可視化できるようにする。
    • 住民の年齢情報と建築予定の住宅戸数を合わせて表示することで、保育園を新規に設立するかなどの判断ができるようになる。
  • 審査自動化による業務改善
    • 定型業務に関してはオンライン申し込みから自動審査を行うようにし、5分*2万件？の時間を削減
  • ガバメントクラウド先行事業参画
    • 現状は独自仕様としているが、徐々に標準化できるところは標準化していく。
    • 独自の処理がある場合はガバメントクラウドを利用する。
    • 過渡期を経たうえで最終的にはガバメントクラウド上にある標準化されたシステムをみんなが使うことを目指す。

浜松市長 鈴木 康友

  • 国土縮図型の政令指定都市
    • 道路総延長全国一位
    • 市の面積が全国二位
    • 橋梁数が中部地整管内一位
    • 過疎地を内包
    • これらの要素が日本を凝縮した要素である
    • この浜松でデジタル活用し、持続可能な都市モデルを確立できれば日本全体のモデルとなる。
  • 2019年10月 デジタルファースト宣言
    • 下記三つを推進していく
    • 都市づくり
    • 市民サービス
    • 自治体運営
  • 浜松市データ基盤活用モデル事例創出事業
    • Hamamatsu ORI Project(ORI=Open Regional Innovation)
  • ガバメントクラウドを活用した、書かない窓口の推進
    • 行政手続きのオンライン化
    • コンビニ交付
    • 書かない窓口
  • デジタル田園都市国家思想のリファレンスシティに
    • 国土縮図型で多様な対象への多彩なサービス
    • ユースケース駆動＆Make our city
    • 官民共創型 みんなが活躍
    • やらまいかの精神（遠州弁でやろうじゃないかという意味の遠州人の気質を表す言葉）

CUS-09 サンドラッグ小売業における顧客データ活用の最前線、CXを最大化するデータ活用戦略

  • グローバルスタンダードなものを使っていくことを目指す
  • オムニチャンネル（すべての販路を統合すること）
  • O2OからOMOへ(Online merge with offline)
  • ECに閉じないシステムづくり
  • ECサイト自体を別部署で構築するとECに閉じてしまう
  • お客様の接点全てに対してデジタル化をしていく
  • ECの仕組みはリアルに転用できる仕組みを採用する
  • 65周年となる企業なのでソースコードが複雑化
  • ユニファイドコマースを目指す（チャネルとデータソースを分離して、データソースから必要な機能をマイクロサービスで作っていく）
  • グローバルスタンダートなものをを使っていく
    • Shopify
    • Salesforce
    • MuleSoft
    • S3
    • Redshift Serverless
    • Braze
    • Tableau
    • 海外の小売では常識となっているものを取り入れていく
    • 上記構成は8ヶ月くらいで作成した。機能追加も差し込む形で素早くできる。
  • 従来のシステム制作だと機能実装に1〜2年かかるが、作っている間に時代遅れになっている場合がある。
  • そのためにはグローバルスタンダートな物を使い、素早くシステムを作っていく。
  • プロジェクト推進して行く上での壁
    • 知らないものには協力できない。変革に対する抵抗感の払拭
    • 自分の事業にメリットがないものは協力できない
    • リアルがメインである
    • コストが掛かるのではないか
  • 上記に対して以下を行った
    • EC、デジタルではこんなことができます、を少しずつ共有
    • 日本ではなく海外の事例を紹介する
    • 危機意識をつける
  • データ基盤にAWSを採用した理由
    • 顧客が改善案を言わなくとも、AWSが年間3000回の機能改善してくれる
  • まとめ
    • SaaSモデルでGlobal仕様に
    • OMOはOnlineをベースに考えること
    • 経営陣の理解や社内啓蒙が必要
    • ECに閉じない。横串で動く。

AP-10 NEC 官公庁・自治体が取り組むべきスマートモダナイゼーションと実例

  • 構築、移行、運用に関してのパートナー資格を保有
  • 従来のようなEC2を使う構成はやらない。最初からクラウドネイティブを前提にしていく。
  • でも結構難しい。クラウドCoEを作ったところでそれを推進していくのは難しい。
    • CoE（Center of Excellence：目的・目標を達成するために組織（社内）に散らばる優秀な人材・ノウハウ・設備などの経営リソースを横断的組織として1カ所に集約する）
  • 現状の人員配置はレイヤーごとに役割分担している場合が多いのではないか？
    • アプリ領域とインフラ領域で分ける
  • クラウドネイティブになるためには両者が融合する必要がある。
  • 過渡期の今はマネージドサービステンプレートを使うという方法をとっている。
    • コンテナテンプレート
      • コンテナを置くだけで運用できる（理想）
      • CDK利用、EC2なしでコンテナのみ。
    • クラウド統制運用プラットフォーム
  • CoEの組織は、うまくいかなかった事の情報が集まってくることでうまくいくようになる。
  • デザインからクラウドまでを途切れることなく繋ぐ
  • まとめ
    • クラウドCoE、事業者は専業体制
    • マネージドサービステンプレート
    • デザインアプローチ

CUS-12 クレディセゾンの DX 戦略とクラウド活用 ～基幹系システムをつなぐ GW 基盤移行について～

  • 店舗の提携カードで成長していったセゾンカード（物理が前提）
  • デジタルシフトでデジタル前提の仕組みに移行していく必要
  • Ph1：デジタル組織を立ち上げる
    • 全てを同時に公開を出来ないので三つに分ける。
      • 基幹システム
      • コア業務アプリ
      • デジタルサービス
    • 全社アーキテクチャーの課題と対策
      • 基幹システムが大きすぎる→普遍的機能に絞り込んで安定化・固定化
      • システム関連系が不十分→連携基盤の開発（internal API）
      • 内政開発組織の立ち上げ、クラウド活用の加速
    • 既存のIT部門を尊重しつつも新しいやり方にも取り組んでいく
    • 人材交流をしていく。
    • グラデーション組織
    • 対立は残るが健全な対立
  • Ph2：CSDXの策定と推進
    • 内製化の推進
      • 全てが内製ではなく、ビジネスのコア部分を内製化することを検討する。
      • コモディティなものはOSSやSaaSを使っていく。
      • バイモーダル戦略の推薦
        • モード1も尊重しつつ、モード2の選択肢を持つ
        • それぞれの良さがあり、全然違う。ただし喧嘩する。
        • 混ぜるな危険→分社化、がよくあるパターン
        • HRTの原則
          • 謙虚、尊敬、信頼
          • 日本の会社の掛け軸に書いてありそう
          • 日本人のマインドに合う。馴染みやすい。
      • デジタル人材を三層で定義する
        • Layer1：専門家
        • Layer2：社内教育のリスキリングでIT知識を得た人
        • Layer3：今までのIT部門
    • メインフレームを使っていた
    • メインフレームで更改予定だったが、AWS検証をしたところ、今までのメインフレーム更改の稼働を捨ててでも効率が良くなることがわかったのでAWSへ移行した
    • メインフレームの更改は10年かかったが、AWSへの移行は8ヶ月でカットオーバーできた
    • 経営会議で半分は従来のアジェンダ、半分はアジェンダレスでフリーディスカッションするようにした。

AWS-06 Amazon の事例から学ぶ Observability 活用におけるベストプラクティス

  • マイクロサービスは監視対象が多い
  • インシデント対応はどうするか
    • Observability：システムのどこで何がなぜ起こっているか
    • 質問から入る：何故起きたか？
    • Instrumentation：log、メトリクス、トレースなどのデータを外部に送信できるようにすること
    • 質問に答えられなかったらInstrumentationを増やしていく
  • COE（Collection of Error）
    • 根本原因はほし草の中から針を見つけるようなもの
    • 当たりをつける→ダッシュボードでスパイクを確認→他に傾向がないかを確認→ログ調査から根本原因を見つける
    • Trace IDを伝搬していく
  • 目的別のダッシュボードを作る
  • ダッシュボードは作ったら終わりではない
    • 全てのチームがいつでも報告できる体制を築く
    • 複数のdimensionから複数の視点を持つ
    • 高カーディナリティーのデータを活用することで深い洞察を得られる
  • AWS X-Ray
    • トレース伝搬が自動で行われるかどうかの把握が重要
      • API Gateway->Lambda->S3（全部自動で伝搬される）
      • ECS->SQS->ECS（SQS->ECSで伝搬されない）
      • 伝搬されない箇所は手動でデータを引き継ぐ必要がある
    • Cloudwatch Embedded Metric Format (EMF)
      • EMFだとログを出力するだけでいい
      • カーディナリティーが高いデータはEMFに出す
      • 低いものはログに出す
    • CloudWatch Internet Monitor
      • ユーザから見た場合の可用性とパフォーマンスメトリクスをCloudWatchで可視化できる
      • 特定の条件のユーザのメトリクスを出せる
      • 概ね正常だがラスベガスからアクセスしているユーザはパフォーマンスが落ちている、など
  • まとめ
    • Ovservabilityのサイクルの考え方を理解し、運用を改善して顧客体験を高めていく
    • インシデント調査の過程におけるシステムの状態に関する質問や、顧客影響把握のための質問に答えられるように、トレース、メトリクス、ログを取得していく
    • CloudWatchの各機能やX-Rayの活用により、Observabilityを高め、迅速な解決につなげる。

お昼ごはん

弁当にあまり期待はしていなかったが、まい泉のお弁当だった。 おいしかった。

早期来場特典とはいえ、無料のイベントで弁当が付くのはお得。サーバ代は個人でもまぁまぁ払ってきているので食べる権利はあると思う。

EXPO（事例紹介ブース）

セッションの間に見てきておもしろかったやつ。

Outpostsの実物展示

紙のオンプレことOutpostsの実物が展示してあった。42Uなのもあってくそでかい！！

リージョンルーレット

笑うやろこんなもんｗｗ

「大阪」だとキーホルダー、それ以外だとシールがもらえるというやつだった。AWSの大阪リージョンブースだと後で知った。大阪っぽくてすき。

その他

行った場所とか

以下は気になったもの、資料をもらってきたものの一覧。個人では結構使っているものもあるが提案用として列挙しておく。

  • soracom（IoTのSIM）
  • snowflake（DWH）
  • NetApp（ストレージ）
  • yamory（脆弱性スキャン）
  • SaaSus（SaaS基本機能提供）
  • Hashicorp（IaC）
  • Datadog（APM）
  • Dynatrace（APM）
  • はてな（Mackerel：APM）
  • PagerDuty（エスカレーション）
  • スカイアーチ（SES、人材紹介、採用代行、AWSトレーニング）
  • ウフル（カスタマーサポート）

スライドのメモ方法

最初はPCを持ち込んで会場で要約しまくる気満々でいたが、写真撮影がOKだったので、重要っぽいスライドをバンバン撮影している人が多かったので自分もそれに倣った。

家に帰ってこのテキストをまとめてみると、むしろスライドの撮影が抜けてる個所に重要なことが書いてあったんじゃないの？？となるので、会社に提出するためみたいな用途でアウトプットが必須であれば全スライド撮影というのも一種のやり方な気はする。

とはいえ後で書き出すために思い出すのは労力がかかるので、まずはスライドのタイトルだけ書いて、時間があればスライドの内容の要約をする、話が濃くてそれどころじゃない場合はスライドの写真を撮って、スライドに載ってないことでしゃべったことを優先的にメモる、くらいが現実的なやり方だと思う。

実際はスライドの要約をセッションの時間内にまとめられるかというのはセッションの濃度次第という感じ。NECのようなゆっくり喋ってスライドの内容が濃い目の場合だと比較的要約する時間は取りやすいが、セゾンの小野さんはスライド一枚にそんなに詰めない上に話の内容が濃くてすごい勢いで話が進んでいくのでメモか写真かの判断に迷ったりするので一概に何とも言えない。

要はバランスおじさん「要はバランス」。

今回の所感

初めてAWS Summitに行ったがとにかく規模がでかい。セッションを聞いて会場をうっろうろするだけで普段より疲れた。早期来場特典で弁当がついたり、アンケートに答えると25ドル分のAWSクレジットをくれたりと、とにかく金を感じる。

もはや社会インフラの基盤であるAWSなので、単純にtech企業や活用例だけでなく、システム導入支援、マイグレ、コンサル、人材紹介等々、出店した企業の裾野がとにかく広く、エンジニア的に感じていた1サービスというよりもはや経済圏だった。

今回見たセッションの中ではクレディセゾンの小野さんの話がぶっちぎりでおもしろかった。いろいろな経歴は存じ上げていたが、実際しゃべるとこを拝見すると、とにかく早口でしゃべる様はエンジニアであるけれど、問題解決の切れ口は経営者であり、両方とも迷いがなく知見にあふれていて話が無限に止まらなくて一切暇がないという感じだった。簡単に言えばオタクの早口で、めっちゃ楽しいんだけど内容がぎっしりすぎてすげぇ疲れるといった感じ。自分もそのような人物になりたい。

様々な会社のキラキラな展示を見ていると、どちらかと言えば小手先な小さい案件で稼いでいる自分の会社に対していろいろ思うことがあるものの、結局のところ転職するか、社内で何か打ち出すしかないので歯を食いしばってやるしかないなという気持ちを新たにした。

まとめ

こういう物理会場で熱気にあてられるというのは創作意欲には大事なことだなと改めて思った。

これから蓮ノ空のリリースイベントに行きます。