6/20～6/21にAWS Summit Japan 2024が開催され、生成AIをはじめとする最新の技術動向や実践的なユースケースが多く紹介されました。
私は初日に参加しましたが、会場の熱気に圧倒され、とても刺激的な1日となりました。
現在、7/5までの期間限定でセッションのオンデマンド映像と資料が公開されています。（おそらく7/5以降にはアーカイブとして恒久的に公開されるはず）
今回は事例セッションを対象に、私が特に印象に残ったものを備忘として紹介します。
プログラムを書けないゼネコン社員が、3 年でどこまでやれるのか ～戸田建設の技術的自立と現場力の向上～
スピーカー：戸田建設株式会社 佐藤 康樹 様
戸田建設では内製力を高めることで、現場力の向上を目指しています。IT 未経験の事業部出身者が AWS を活用して自らシステム開発できるようになった背景、具体的内製事例（業務効率化プラットフォーム、BIM データ活用、Amazon Kendra 活用等）の紹介に加え、彼らが「三種の神器」と呼ぶサーバレスの基本となる AWS サービスや、SPA と JS のフレームワーク、最新の生成 AI やエンベディングなどの活用ポイントを含めて紹介します。また、AWS 認定資格の取得と内製化支援パートナーの活用などで、内製技術力を高めるプロセスにも言及します。
セッションでは、内製開発した業務アウトソーシングツールや生成AIツール(チャットボット/議事録作成)などのデモが紹介されました。どれも機能が豊富でUIもかなり凝っており、またS3やLambda、API Gatewayを活用したサーバレスネイティブなアーキテクチャを採用していると聞き、「本当に非エンジニアの社員が構築したのか」と驚かされました。
外注依存の場合だと、ベンダー側が事業への理解が乏しいことから、本当に現場が求めているシステムが開発できるのかという問題意識があり、自ら試行錯誤できる人財の育成（人財DX）を進めたとのことです。
ここで出た人財DXに必要な要素として以下が紹介されました。
- 学習意欲
- 共に歩める同士
- 没頭する時間
- 旬な教材
- 自由に使えるクラウド環境
- 頼れる教師
- アプローチ可能な実務データ
- 実務的課題
内製化を志向する多くの企業では、エンジニアの中途採用に取り組みがちです。一方戸田建設では、現場をよく知っているプロパー社員を時間をかけて一から育成するという方針を取っており、一見すると遠回りに思えますがビジネス価値の向上に直結する取り組みだと思いました。
参考サイト：
創薬を加速する第一三共のセルフサービス型クラウド基盤 ～モブワークで挑む基盤内製と人材育成の両立～
スピーカー：第一三共株式会社 岡本 敦之 様
第一三共株式会社では、創薬研究プロセスの変革を目的として、セルフサービス型クラウド基盤を新たに設計・構築し運用を開始しました。本講演では、なぜ新たな基盤が必要であったのかについて説明し、全面的に IaC を採用して構築した基盤の概要をご紹介します。また、モブワークでの内製にこだわった理由と伴走パートナーとの納品物のない協業など具体的な進め方、人材育成面におけるモブワークの効果、そして今後の展望、についてお話しします。
創薬では薬の種を見つけ、磨き上げて、開発候補物質を創出する「ディスカバリー研究」が重視されています。このセッションでは、当該プロセスを高度化するため、データ活用基盤を構築した事例が紹介されました。
研究部門が自律的にデータを活用でき、ビジネスとITが一体となることを、データ活用基盤のコンセプトとしています。
当初は社内でITシステムを外部委託する風潮があり、経営層の理解を得られづらい状況が続いていました。そこで研究開発関連のグループ会社である第一三共RDノバーレの社長の支援を取り付け、人材育成を進めつつ内製化に向けたCCoEを組成したとのことです。
将来的に自分たちが運用することを意識し、CCoEチームとして理解を深めるため、構築の土台となる知識を習得していました。具体的にはAWS ProServeの伴走支援のもとワークショップを開催したり、実機でTerraformを利用した環境構築を行ったりといった取り組みを実施されていたとのことです。
今後はBedrockやDatazoneを利用したラボスマート化を検討するとのことで、生成AIを活用したデータ分析に期待が寄せられています。
東京都のクラウド戦略
スピーカー：一般財団法人 GovTech東京 杉井 正克 様
都政の構造改革戦略である"シン・トセイ 4 "のコアプロジェクトの一部に「クラウドインフラ」の整備があります。都庁各局の業務システムをクラウド転換するにあたりどのような戦略で推進するのかをご紹介します。
GovTech東京が推進するクラウドインフラ整備の全容について知ることができました。
クラウドのプラットフォームを提供するにあたり、「適切にクラウドを使うこと／選択すること」「使いやすいプラットフォームであること」を考慮ポイントとして挙げていました。前者は、データの機密性や災対などシステム特性に応じたクラウドの選択およびアーキテクチャを検討することを指します。
なるほどと思ったのが、後者です。これは「ユーザーのニーズを把握している」「統合管理が効率的である」といった管理側の傲慢さを捨て、現場の声をもとに仮説検証を進め、使いやすいプラットフォームを整備することを指します。東京都ではサービスデザイン全般のガイドラインを公開しており、GovTech東京が整備するクラウドプラットフォームもこのガイドラインに沿って検討しているとのことでした。利用者のペルソナを設定し各属性の課題や状況を整理しつつ、何をもって成功と判断するのか指標を定義するといった取り組みをされているようです。システムを構築するとき、いきなり要件定義に着手するケースをよく見ますが、まずは利用者の分析からコンセプトを固めるべきなのだと改めて実感しました。
プラットフォームの提供におけるアンチパターンについても説明がありました。具体的には、あれもこれも機能を盛り込みユーザビリティやコストが悪化する、規模や非機能要件が異なるシステムを無理やり統合管理したところ思うように効率化が進まない、といったことが挙げられました。プラットフォームの機能は最小限にとどめ、使いやすさを重視することが必要とのことで、利用者ファーストの考えを大事にしている印象を受けました。
セッションの最後では、シャクルトンによる南極探検隊募集広告の文言が引用されました。行政システムはまだまだ利便性が低く時代遅れのものも見られますが、果敢にチャレンジすることで首都の未来を変えるということで、力強いメッセージで締めくくっていました。
参考サイト：
1,700 以上の AWS アカウントを抱えるドコモ CCoE チームが実践した AWS Control Tower 導入の歩み
スピーカー：株式会社NTTドコモ 中村 拓哉 様
NTT ドコモは、今から約 15 年前の 2009 年より AWS の利用を開始し、2024 年時点では 1,700 を超える数の AWS アカウント上で多種多様なワークロードを実行しています。AWS の利用が社内の様々な部門へと拡大するにつれ、セキュリティ対策レベルのバラつきや対策漏れによる情報インシデントの発生が問題になりました。本セッションでは、多数の AWS アカウントを管理するドコモの CCoE（Cloud Center of Excellence）が問題解決のために実践するマルチアカウント管理戦略と、 AWS Control Tower を活用した統制プラットフォーム構築の歩みをご紹介します。
過去にControl Towerを利用した小規模なマルチアカウント環境を構築した経験があり、1000以上のAWSアカウントを対象とした大規模な統制について興味があったので視聴しました。
ドコモでは、AWSアカウントの増加に伴い、設定不備が原因のインシデント発生やセキュリティチェックのリードタイム増加といった課題がありました。そこでCCoEが利用部門のビジネスアジリティを阻害しないことを目的として、Control Towerの導入を決定したとのことです。
Control Towerを活用した統制施策として、セキュリティの共通化だけではなく、Locker Studioによるセキュリティダッシュボードでアカウントを管理している点が特徴的でした。ダッシュボードではアカウントの検出結果やログを統合的に表示し、全社的に相互閲覧可能な状態にしており、利用者が自発的にセキュリティ施策を進めるよう工夫しているとのことです。確かにControl Towerはガードレールを設定することはできるものの、個々のアカウントのステータスを把握できない課題があるため、興味深かったです。
またアカウント数が膨大であるが故の問題もあるとのことでした。例えばControl Tower有効化時、各アカウント内にCloudTrailのログ格納用S3バケットが作成され、試算したところ年間最大で数億円のコストが発生することが判明したようです。そのため証跡の取得をオフにするようカスタマイズしてControl Towerを設定されていました。
現在は500程度のアカウントがCotrol Towerに参加しており、今後は各部署への説明を丁寧に行いつつ、提供できる機能を追加していくとのことでした。既存のアカウントを参加させる場合、どのような影響が発生するのか気になるところです。
リニア中央新幹線における設備 IoT 化に向けて～データドリブンによる徹底的な省人化の実現～
スピーカー：東海旅客鉄道株式会社 宮本 真樹 様、藤原 海渡 様
東海旅客鉄道株式会社のリニア開発本部ではリニア中央新幹線の運営に向けて、地上設備の運用・保全業務においてデータドリブンによる徹底的な省人化の実現を目指しています。山梨リニア実験線に地上設備稼働データを収集・蓄積するデータ分析プラットフォームを構築しています。その第一フェーズとして「保守用車リアルタイム状態監視」「開閉器動作音による異常検知」の 2 テーマについて、AWS プロトタイピングプログラムを活用した取り組みを行っていますので、その一端を紹介します。
基調講演でも取り上げられていた、リニア中央新幹線の設備IoTに関する内容です。JR東海ではこれまで人力に頼った運用保全作業が行われていましたが、AWSを活用し省人化を目指しています。具体的な取り組みとして、セッションでは「保守用車リアルタイム状態監視」と「開閉器動作音による異常検知」という2つのテーマが紹介されました。
「保守用車リアルタイム状態監視」では、線路の状況を確認する保守用車をリアルタイムで監視し、データの可視化を行っています。アーキテクチャとしては、AWS IoT SiteWiseでリアルタイムにデータを取得し、可視化のためFargate上に構築したGrafanaを利用しているとのことです。こうした取り組みにより、車両の故障発生時に電話で状況確認を行っていた従来の時間を要するオペレーションが、故障発生前の異常を検知しプロアクティブに対応できるようになります。
「開閉器動作音による異常検知」では、電気の入切を制御する開閉器の音を頼りに非接触で異常を検知する仕組みを実現されています。音のデータについてはSagemaker Pipelineを利用した機械学習で推論を実行し、QuickSightによる可視化まで自動化することで、誰でもどこでも遠隔監視が可能になりました。
予知保全の分野でIoTやMLが活用される話は聞いていましたが、本セッションを受け具体的な活用例を知ることができました。個人的には可視化のツールとしてGafanaとQuickSightを使い分けており、どのような選定の判断が行われたのか知りたかったです。
従来の方法に囚われず、最新技術を積極的に導入し、効率化と安全性向上を同時に追求する姿勢は、他の産業にも参考になる取り組みだと感じました。
参考サイト：
エンタープライズシステムが抱える課題とマイクロサービスアーキテクチャ
スピーカー：株式会社カインズ 池照 直樹 様
伝統的な企業においては、これまで積み上げてきた重厚長大で複雑化したシステムがあるため、新しい技術を使って新しい基盤に乗せ換えていくことは容易ではありません。カインズでは、2018 年に「IT小売業宣言」を行い、内製化組織を立ち上げながらデジタル化に取り組み、各事業部からの要求に迅速に応えるためにマイクロサービスを活用して MD システムや EC、店舗システムなどを再構築するプロジェクトを進めています。このセッションでは、カインズがどのようなコンセプトで根本的なシステムの刷新にチャレンジしているかをご紹介します。
カインズは小売業界の中ではいち早く内製化に舵を切り、経営層のトップダウンのもとデジタル化を進めていることは知っていましたが、具体的な取り組みや課題についてセッションで知ることができました。
はじめにシステム担当部署の体制について簡単に話がありました。6年前までは担当者が数名しかいなかった状態から、開発組織を立ち上げ現在はインドのオフショア部隊も含め数百名規模まで拡大したとのことです。どうやら国内では優秀なエンジニアの採用が難しいため、海外から人材を確保したとのことで、はじめは言語の壁もあったものの今は効率的な開発が行えているようです。
組織の立ち上げ当初は、ポイントカードの顧客基盤がありましたが、あまりデジタル活用が進んでいなかったようです。対顧客については、アプリを開発しコミュニケーションの双方向化を図りました。対現場については、まず組織風土改革のためデジタルの苦手意識や不信感を払拭するため、矢継ぎ早に現場向けのアプリケーションをリリースすることでオペレーションを徐々に改善し信頼関係を構築していったとのことです。
DXのアンチパターンとして、いきなり大きな目標を立て時間をかけすぎた結果、目立った成果を上げられないといったケースがありますが、カインズでは小さな成功を積み重ね大きな変革に取り組むというアプローチをとっており参考になりました。
この後のアーキテクチャやそれを取り巻く開発体制の変革も進めている話が続きました。従来は、システムは個別機能の開発に焦点が当たり、密結合化、機能の重複、運用とコストの負荷といった課題が存在しました。開発はベンダー任せで、システム部門はビジネス部門の口利きとなって動いていたようです。
改善のため、まずアーキテクチャは、マイクロサービスを採用し、具体的には基幹システムの機能をAPIで公開し、フロントアプリケーションが再利用できるようにしたとのことです。またカインズの中で要件定義～テストまで実施できる体制に変え、ビジネスとシステム部門がともにリーダーシップをもって自らコントロールできるようにしたとのことです。
また内製化の体制も工夫しており、システム部門がはビジネス部門に従属することを排し、責任のなすり付けや奴隷制をなくし、プロダクトオーナーを中心としたリーダーシップのもと推進することとしています。開発体制も海外のスクラムチームを参考に編成し、プロダクトを適切な単位に分割し、MVPを定めツールやコミュニケーションを整備しています。ここには時間をかけたようで、一つのプロダクトでプロセスが定まるまで半年要したとのことです。ただこの後は金太郎あめのように他のプロダクトに対し横展開が見込めます。
今後の課題として、基幹システムの刷新とグループ間の連携が挙げられていました。各基幹システムはベンダー依存型の仕組みになっており、似たようなシステムが乱立している状態を見直す必要があるとのことです。特に、POSに縛られたアーキテクチャからスケーラブルなコマースシステムへの移行は、重要な課題と位置付けていました。
総じて、この講演はカインズの大胆かつ計画的なデジタル変革の取り組みを示しており、伝統的な企業がいかにしてデジタル時代に適応していくかの一つのモデルケースを提示していると言えます。技術面だけでなく、組織や文化の変革にも注力している点が、成功の鍵となっているように感じられます。多くの企業にとって、この事例は大いに参考になるものと考えられます。ただこうした活動にAWSがどのような貢献をもたらしたのかという点が説明されなかった点は、少し残念でした。
終わりに
数年前の事例セッションでは、オンプレからクラウドへの単純シフトの話が多く見られました。
しかし、今年のセッションを見ると、多くの企業ではクラウド移行が一巡し、ビジネス価値の向上につながる次なる施策を着々に進めていることが分かりました。また最新の技術に過度にとらわれず、これまでのルールや組織構造、人材育成といった領域を改善する動きも活発化しています。
AWS Summitを通じ、次世代のクラウド活用はいかなるべきか改めて考えさせられました。