2024.12.19
システムの穴を運用でカバーしようとしてミス多発… バグが大量発生、決算が合わない状態から業務効率化を実現するまで
多忙なアーキテクトのためのクラウド導入フレームワーク (CAF) ダイジェスト(全1記事)
リンクをコピー
記事をブックマーク
平岡一成氏:トップバッターなんですが、どうぞよろしくお願いします。タイトルは『多忙なアーキテクトのためのクラウド導入フレームワーク (CAF) ダイジェスト』で、20分の時間をちょうだいしています。
自己紹介をしたいと思います。平岡一成と申します。日本マイクロソフト株式会社で、パートナー事業本部というマイクロソフトパートナー様向けに事業をしている部署の者です。今日のイベントのタイトルのとおり、クラウドソリューションアーキテクトを担当しています。右上にTwitterのアカウント (@hoisjp) も載せているので、よければフォローをよろしくお願いします。Azureパートナー向けの技術支援の仕事をしていますが、いくつか担当が分かれていて、クラウドソリューションアーキテクトのロールも、データベースや機械学習、AIなどと担当が分かれています。私はアプリケーションの開発を見る担当です。
実は、オルターブースさんのウェビナーには何回もお声がけいただいて、今回で8回目になりました。いつもトップバッターをやっているんですが、今日はこのあとMicrosoft MVPのみなさんや、小島さん(@techno_officer)など、重鎮のみなさまの手前なので、ちょっとドキドキしています。スベらないようにがんばります。
今日のアジェンダですね。アーキテクトの話を私のロールも踏まえて紹介しつつ、メインのトピックはクラウド導入フレームワークを紹介したいと思います。
まず、ロールについて少し頭出しをしたいと思います。今日参加されているみなさんにもそれぞれロールがあると思います。アーキテクトと言ったときに、やっていることは一緒でも会社ごとに通称はいろいろあるかなと思います。
アーキテクトと呼ばれたり、テックリードと呼ばれたり、最近だとSREと呼ばれたり、シニアエンジニアがアーキテクトの役割を担っていたりがあると思います。
ほかにも例えば、今日参加されている方には部下がアーキテクトで、いつもは上長の立場でカワイイエースの部下を見守っている立場の人や、自分自身がアーキテクトをやっている人や、業界に入ったばかりで見本とするアーキテクトの人が先輩にいるという方もいると思います。
それぞれの立場からアーキテクトのイメージを少し思い浮かべてもらいたいなと思います。いろいろとたくさんの複雑なことを解決しなきゃいけない。(つらそうな)って書いたんですが、アーキテクトは非常に大変な仕事というイメージがあるんじゃないかなと思います。
「いろいろ」「たくさん」「複雑な」の大変さを少しでもこのあとの話題で軽くできればいいなと思っています。ここで、日本マイクロソフトのクラウドソリューションアーキテクトというポジションの紹介をします。
こういう紹介はHRのイベントではあるかもしれませんが、みなさんはあまり聞いたことがないかなと思いますし、いい機会だと思うので、やっている私自身から紹介したいなと思います。
日本マイクロソフトのクラウドソリューションアーキテクト。人材募集のページがあって、たくさんポジションがあるんですが、そこにジョブディスクリプションというかたちでResponsibilityという、責務や必要なスキルが書かれています。
ズラッとあるので、そこから引っ張ってきました。ちなみにマイクロソフトだけではなくて、複数社を比べるときはLinkedInが実はおすすめです。こういう会社はこういう人材を求めているなっていうのがわかります。
今日は「Cloud Solution Architect」のポジション。ちょうどいいので私と同じ「アプリケーション開発」のポジション。「カスタマーサクセス」というエンドユーザー向けに支援をしているポジションの例をもってきました。
実際は英語で書いてあるのですが、かなり意訳してキーワードだけを引っ張ってきました。キーワードだけ拾っていきたいのですが、読んでいくと、なかなか大変そうな仕事だなという印象を持たれるかなと思います。
先ほどのアーキテクトという単語から想像できる、設計したり、ソリューションを作ったりといったところからちょっとスコープが広がって、いろいろなことを見なきゃいけないなというのがわかってくると思います。
1つずつ紹介していくと、まずはお客さまのアプリケーションの全体像を見なきゃいけません。あとはITだけではなくて、ビジネスの優先事項を理解しなきゃいけません。単語としておもしろいのは、プロジェクト成功の基準を、きちんととデザインしなきゃいけないなどですね。
ほかにもプロジェクトの成功の確率を上げるために、それに必要なリソース、インフラ、アプリケーションなどを自分で考えて調達してきましょうとか。このあたりからは顧客に寄った話も入ってきて、顧客のインサイトや観察して分析した結果をもって、よりモダンなロードマップを作成しましょうと言っています。
このへんがよくイメージされるところかもしれないですね。パフォーマンス、セキュリティ、スケーラビリティうんぬんを保ったアーキテクチャを考える。このへんもおもしろいですね。お客さまの中でも重要な意思決定者と深い関係、つまりリレーションシップをきちんと築きましょう。本人がお客さまの声になって、代弁していろいろなステークホルダーにお伝えできるようにしましょうなどもあります。
お客さま向けで、自分が関係する仕組みだけではなくて、体系立った学習計画を立ててあげましょうという話もあります。アーキテクトに大変そうというイメージのある一部分について、余談ですが、1つおもしろい話があります。
日本マイクロソフトは、2020年にコロナの影響が始まって以降、お客さまのことにより多くの時間を使いなさいとすごく言われるようになったんですね。私もこれは非常にいい刺激だったと思っています。アーキテクトとして、有意義な時間の使い方をしているかを振り返るきっかけになったと思います。
アーキテクトの大変さを感じている大半の時間はあまり本質的ではないというのはわかってはいるけれど、どうしても「やらなきゃいけないこと」に時間を使っちゃっているんじゃないかなと思うところもあります。
ここに書かれているキーワードにスコープをどんどん広げて、やる責務を増やすきっかけについても今日の話題にしたいなと思っています。
さっそく今日紹介するクラウド導入フレームワークですね。下に英語の訳を書きましたが、「Cloud Adoption Framework」と呼んでいて、我々は頭文字を取ってよくCAFと言っています。先ほどの大変なところ、つらさを軽くしてくれるんじゃないかなと思って紹介したいと思います。
具体的な内容はこのあと紹介したいと思いますが、どういうものかをお話しします。マイクロソフトにはいろいろなお客さまがいます。スタートアップからエンタープライズな世界規模で展開している企業さまなど、幅広い企業と協力しながらやっています。長年に渡って企業のクラウドの導入を何件も支援してきました。
その支援の過程で、マイクロソフトの従業員やパートナー、あとはエンドユーザーの顧客経験やベストプラクティスをヒアリングしていて、そのヒアリング結果を蓄積して、共通のパターンを見つけてきましたよ、というのがこのCloud Adoption Frameworkのもとになっています。
赤字で書いているところですね。まさに実際の案件のフィードバックからガイダンスを作っていきました。その教訓の結果をまとめて文書化した内容です。
プロセスごとに共通の考え方が必要だよね、というのはフレームワークという名前のとおりですね。そういう定義をしています。
戦略定義をして、計画して、導入準備をして、採用して、それをクラウドに移行したり、新たな価値を与えたりするのに並行して、統制の管理や運用の管理をしなきゃいけないのでいろいろなスコープがあると思うんですね。
日々のみなさんの業務や会議などをイメージしてもらえるといいと思うんですが、これらのステージごとにたくさんの意思決定をしなきゃいけないんですね。ここではこういう計画にしよう。ここではこういう戦略にしようという意思決定をしていると思います。
Cloud Adoption Frameworkは、スコープの中で関連する人たちがどうやって協力をして機能できるかというフレームワークになっています。
ちょっとフワフワした話になってしまったので、掘り下げて具体的にします。当然みなさんが全部やっているわけじゃなくて、それぞれ主戦場というか、いつもだいたいこのへんをやっているというのがあると思います。
私の場合、お客さまの戦略コンサルティングは別の営業ロールの者がいるので、戦略を立てた途中からその者と入っていきます。このへんの大枠を見ながら、パートナーさまやお客さまが管理できるように裏でやっています。
なので、場所的にはだいたいこういう範囲になります。みなさんも、PoC(Proof of Concept)はよくやっていると思います。
結局、企業それぞれに得意な領域や専門領域があるように、これらの工程をすべて完璧にできる会社や人は存在しないはずです。それぞれデコボコがあるはずなので、それらを埋め合わせするのを気にしてもらえればいいと思います。すごくたくさん情報があるので、かいつまんで自分の専門領域や、不得意な場所やここが弱いというところを見てもらえればと思います。
ちなみに、クラウドソリューションアーキテクトのオンボーディングのプログラムは、Cloud Adoption Frameworkがしっかりと組み込まれていて、すごくたくさんのビデオを見て、テストをしています。
具体的にどこを見ればそれがあるのかですが、Azureの公式ドキュメントの中にアーキテクチャセンターというものがあります。これがアーキテクチャセンターのトップページですね。
上のメニューの中のアーキテクチャというメニューを開くと、Azure向けクラウド導入フレームワークというメニューがあるので、そこから入っていきます。
サラっと書いてあるので、一見すると見やすそうですが、中身は非常に多岐に渡っていて、ボリュームもあります。1個どれかドキュメントを開けて、目次を見ていこうかなと思います。
大項目で分けると、戦略、プラン、Ready、採用、ガバナンス、管理、整理と分かれています。最初の入り口は7つくらいに絞られているのですが、その下のツリーが多岐に渡っています。
全部でどのくらいのボリュームがあるか数えてみました。ここにURLを出しているのですが、bit.ly/caf-indexというページを開けてみてください。目次のページを全部リスト化したページを作ってみました。
数えてみたら、なんと650ページ以上あるんですよ! 全部は読みきれないのが当然だと思うので、みなさんにはこのページを開けてもらって、スクロールをしてちょっと単語を拾ってもらうといいのかなと思っています。
さっき、お客さまを長年支援した経験から積んでいて、なにがうまくいって、なにがうまくいかなかったを全部まとめたガイダンスなので、実証済みのものだという紹介をしたんですが、おもしろいのが、きちんと読んでいくと壮大なるしくじり大全みたいなかたちになっています。
あんまり言い過ぎると怒られるかもしれませんが、中には壮大な失敗集、うまくいったパターンとそうではなかったパターンがあって、そういうのを想像しながら見ると非常におもしろいと思います。
先ほど開いた、650ページくらいのリストをちょっとなぞっていきましょう。7つのカテゴリがあります。戦略はスコープの手前の工程の部分ですね。なぜビジネスをやるのかとか、なぜプロジェクトをやるのかという動機やビジネスの成果をどこにスコープしていくかという内容が入っています。
次にいきます。スコープが次に移って、プランのところ。最初に書いてあるのはデジタル資産です。既存の資産や武器は何なのかを決めていこうというところです。
3つ目はちょっとおもしろくて、最初の組織の配置です。ガバナンスを決める人たちと、クラウドの導入をする人たちで相反するところです。ガバナンスと言うと穏やかな言い方なんですが、いわゆるリスク警察です。こういうことはやっちゃいけないというサイドと、それを導入するサイド。
この2つが対立するのは自然なことであるとも書かれています。どうしたら導入の速さを失わずにバランスが取れるかが書いてあります。
次は、Readyですね。準備をする段階の話が書かれています。ここでは多くのコンテンツはランディングゾーンという言い方をしていて、オンプレミスからクラウドにアプリケーションを持ってくるときの共通設計が書いてあります。こういうふうに共通設計しておくと、例えば規模が小さいときから大きいときに変化しても、その変化にちゃんと耐えられる設計になると書かれています。
具体的に言うと、Azure ADのテナントをどう構成するかとか、アイデンティティやRBACのアクセス管理をどうするかとか、サブスクリプションの構成やネットワークの構成をどうするかなど、そういう構成について書いてあります。
次はAdopt。実際の移行とイノベーションです。ただ移行するのではなくて、もうちょっとこういう要素を与えるとクラウドの強みを活かせるよと書いてあります。
実はここがリストとしては一番情報量が多くて、Javaの案件ではこういうものがあるとか、.NETのものがあるときはこういう移行をするとか、シナリオ別に書いてあるので、そこも参考になると思います。
ほかにもガバナンスの話や管理の話があります。工程ごとになぞってみてください。お役立ち情報的に、ツールやこれを使ったらいいんじゃないのっていうテンプレート類もあります。
とてもたくさんの情報をカテゴリ別に紹介したんですが、さすがに650ページの内容をここで紹介するのは難しいので、もっときちんとこの内容を解説しているオンデマンドのビデオも用意しています。この資料もあとで展開するのでぜひ参考にしてください。
今日のまとめです。Cloud Adoption Framework、今日はこの単語だけ覚えてもらいたいと思います。読み方を覚えればCAFの3文字でわかりますね。aka.ms/CAFというページのリンクで、先ほどの大きなドキュメントのトップにいくので、ぜひこの単語だけ覚えて帰ってもらえればと思います。
実際の経験や知見に基づいたベストプラクティス集になっているので、そこからつらさを改善するものを少しかいつまんでもらえればと思います。私のセッションは以上です。ありがとうございました。
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2024.12.19
12万通りの「資格の組み合わせ」の中で厳選された60の項目 532の資格を持つ林雄次氏の新刊『資格のかけ算』の見所
2024.12.16
32歳で成績最下位から1年でトップ営業になれた理由 売るテクニックよりも大事な「あり方」
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
2024.12.13
ファシリテーターは「しゃべらないほうがいい」理由 入山章栄氏が語る、心理的安全性の高い場を作るポイント
PR | 2024.12.20
モンスター化したExcelが、ある日突然崩壊 昭和のガス工事会社を生まれ変わらせた、起死回生のノーコード活用術
2024.12.18
「社長以外みんな儲かる給与設計」にした理由 経営者たちが語る、優秀な人材集め・会社を発展させるためのヒント
2024.12.12
今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは
PR | 2024.11.26
なぜ電話営業はなくならない?その要因は「属人化」 通話内容をデータ化するZoomのクラウドサービス活用術
Climbers Startup JAPAN EXPO 2024 - 秋 -
2024.11.20 - 2024.11.21
『主体的なキャリア形成』を考える~資格のかけ算について〜
2024.12.07 - 2024.12.07
Startup CTO of the year 2024
2024.11.19 - 2024.11.19
社員の力を引き出す経営戦略〜ひとり一人が自ら成長する組織づくり〜
2024.11.20 - 2024.11.20
「確率思考」で未来を見通す 事業を成功に導く意思決定 ~エビデンス・ベースド・マーケティング思考の調査分析で事業に有効な予測手法とは~
2024.11.05 - 2024.11.05