そのリファレンス誰のため？ ユーザ活用に向き合う タイトル

会社紹介 みずほ情報総研、みずほ総合研究所、 みずほトラストシステムズを合併（2021年） みずほ向けIT中核子会社 社員数：4,294人（2022年4月1日現在） CCoE設立 みずほAWS 一般企業向けSI 公共入札案件 認定取得支援（SAA 500+） 実践ハンズオン／ワークショップ 社内専門性認定 コクリエdev支部発足（クラウドネイティブ開発） 講演、ハンズオン、ノウハウ共有等 みずほ向けAWS利用 人材育成 外販向けAWS利用 ERG（社員リソースグループ）

みずほリサーチ&テクノロジーズ株式会社 先端技術研究部 今西 貴洋 略歴 2010年～ 大阪から上京して新卒入社。みずほ向けネットワーク担当 2014年～ みずほ勘定系仮想化基盤リーダー 2019年～ パブリッククラウド（AWS）導入推進 職務内容 みずほ／社内のパブリッククラウド（AWS）導入推進 - 一般先向けのAWS共通プラットフォームのプロダクトマネージャー - AWS案件の立ち上げ支援、各種技術支援、基盤開発 - グループ向け開発者コミュニティの運営 - 社内技術ブログ編集部 自己紹介 好きなAWSサービス AWS CDK、AWS Organizations @takaimanishi takahiro.imanishi @mizuho-rt.co.jp

AWS Summit2023ありましたね https://aws.amazon.com/jp/blogs/news/aws-jam-report-aws-summit-tokyo-2023/ https://aws.amazon.com/jp/blogs/news/aws-gameday-at-aws-summit-2023/ AWS JAMの集合写真 AWS JAMの盛り上がり練習 AWS Game Dayのトロフィー JAMもGame Dayも9位でした

AWS活用における課題感 課題 ・セキュリティ要件の漏れのない実装と客観的な説明 -オンプレミスの環境と異なり、設定1つで公開されてしまうリスク -AWSの豊富なサービスが故の網羅的な対応の難しさ ・AWSの特性を理解して設計・実装できるエンジニアの不足 -セキュリティも含めて適切かつ効果的にAWSを活用するには一定以上のスキルが必要 -育成は重要な解決手段であるが、委託先も含めると育成だけでは解決困難 -リファレンスや共通基盤等の選択肢を絞ることで設計・実装の総量を減らす手立てが必要

金融リファレンスアーキテクチャ日本版の良いところ 良いところ ・公式であること -AWSさんが金融リファレンスアーキテクチャ日本版を公開したこと自体に価値 -役員やセキュリティ部門に構成を説明する際に事例や実績は重要 -同様のアーキテクチャを採用する場合に公式と同じですよ！と言える ・モダンなサービスが活用されていること -Control tower、コンテナ、CDK等、 今アーキテクチャを作るならこうだよねというようなアーキテクチャになっているので、 とても安心感がある。 AWS Control Tower AWS Cloud Development Kit (AWS CDK) Amazon Elastic Container Service (Amazon ECS) Amazon Connect

ここまではパネルディスカッションで話をした内容と大体同じです。 ここからは架空の話で、実際に活用することを考えてみましょう。

ペルソナとは 要件定義を行う際、プロジェクトの各メンバーが「ユーザーとは～だ」「ユーザーは～する はずだ」といった発言をするものの、各人が思い描いているユーザー像が異なるために、議 論がかみ合わないことがあります。このようなユーザーは、自身の都合のいいように伸び縮 みできるので「ゴムのユーザー」 と呼びます。 これに対し、プロジェクト内で「ユーザー」の具体的なイメージを共有するために作成する のが、仮想の人物像であるペルソナです。 ターゲットユーザ= エンジニア ユーザは〇〇するはずだ いや、きっと ××するでしょう。 前置き

ターゲットユーザ= エンジニア 誰？ リファレンス/テンプレートのペルソナ リファレンス/テンプレートを自社でお持ちの方はいますか？ リファレンスとテンプレートって誰が使いますか？ 自社のビジネス部門？ 情報システム部門？ システム子会社のエンジニア？ 委託先のSIer？ みなさまは誰か明確に答えることができますか？ 答えることができなかったり、PJのメンバ内で回答が異なると そのリファレンスやテンプレートは見直した方がよいかもしれません。 ビジネス部門だ！ SIerだ！

リファレンス/テンプレートの活用について(本当にフィクションです) あなたは金融機関のCCoEの一員です。AWSスペシャリストでCDKも大好物です。 上司から、リファレンスとテンプレートを作成し、統制と標準化を実現するように 指示されました。 リファレンスとテンプレートの作成に悩んでいると、なんと！ AWSさんが公式で「金融リファレンスアーキテクチャ日本版」というものが公開されており、 その内容はあなたが実現したいリファレンスとテンプレートと一致しており、 作成の必要がなくなりました。嬉しい！ さぁあなたはこのリファレンスとテンプレートは最高なので、 実際に見るであろうユーザも活用できるであろうと社内に展開しました。 問い合わせもきており、おそらくは使われている気がします。

ビジネス部門が使おうとした (ユーザ像) ・早く安く作りたい ・開発は委託先にお願いしてるので、AWSあんまりよく分からない。 ※本来、ペルソナはもっと細かく設定しますが説明の都合上、簡易版です。 とてもいいものあります。 どうぞ参考にしてください CCoEが出した立派な資料 使ってみよう。 CCoE ユーザ

ビジネス部門が使う(1/2) CCoEからテンプレートでてるわ。 CCoEからは中身参考にして作ってねって言われてるので、委託先さん参考にしてな。 うわ。CDKやん。TypeScriptとか書いたことないねんけど。 FISC準拠って書いてるけど、社内システムだしセキュリティもいらないし ユーザさん。これCDKっていうツールで書いてるんですけど、 正直いらないと思うんですわ。 後、こんなセキュリティ実装想定してないんですわ。 これ使ってねっておっしゃるなら見積追加させていただきたいんですけど。 なんやて！CCoEに確認しますわ。 ユーザ 委託先

ビジネス部門が使う(2/2) CCoEさんこれ全部そのまま使うの難しいって委託先から言われてるけど、 どうすればええの？ まぁ全部使うのはこっちも難しいと思てるんで、使えるところだけ使ってーな。 (お、なんか照会来てるな。使われてる感じするわ。) 委託先さん、CCoEさんから使えるところだけって言われてるから、 見積追加にならん範囲で参考にしてな (あんまりないねんけど) 分かったでー！ユーザさん確認ありがとうな。 ユーザ 委託先 CCoE

何が違う？ -ユーザ ・早く安く作りたい ・開発は派遣・引入にお願いしてるので、AWSあんまりよく分からない -CCoEのユーザ ・ユーザも活用できるであろう ⇒ユーザを定義してない。確認してない。 ・リファレンスとテンプレートは最高 ⇒最高とは？使う人が定まっていないのに最高？あなたが使うんじゃないですよ！ ・統制と標準化は何のため？ ⇒ユーザのビジネス価値(コスト、スピード、品質等)が向上できないと意味ない -ユーザ(委託先) ・実は開発技術がそれほどでもない CCoEが暗黙的に想像しているユーザ像と合ってない

まとめ リファレンス/テンプレートをしっかり活用していくためには ユーザが活用できないと意味(ビジネス価値)がないです。 このユーザはみなさんそれぞれ異なるので、自社のユーザをヒアリング・分析した上で 活用を検討いただくことが大事だなと思います。 AWSさんや他社の事例等はとても優れたものが多く参考にすることは大事なのですが、 ビジネス価値を向上するために技術ソリューションを活用するという観点では、 優れたソリューションだけでなく、ユーザが活用できるかを真剣に考え抜くことが 大事だなって思います。

おすすめ資料 ・UX/ペルソナ UXの入門におすすめ HCD普及活動のためのツール／HCD入門講座教材 https://www.hcdnet.org/hcd/column/materials_01/hcd-1177.html ・Platform Enginnering プラットフォーム(テンプレート/リファレンス/共通基盤等)をどうやって普及させていくか。 統制部門が現場にプラットフォームを展開していく上でとても参考になります。 UX(ペルソナ)の概念も内包されています。 Platform Enginneringへの招待 https://speakerdeck.com/player/0c73acc1a21a4f3dba43908cac4570d8