圧倒的主観で語る「こんなクラウドはイヤだ」の4パターン　実体験を踏まえた“イヤなところ“と、そうならないための対策

自己紹介と登壇経緯

増田雄一氏：増田と申します。今日はよろしくお願いします。簡単に自己紹介と、この会に登場する背景、経緯を説明させてください。

私自身の経歴を上のほうに書いています。2010年からSIerのSEとして、主にオンプレミスの上で動くシステムのインフラエンジニアとして仕事をしていました。2020年からクラウドのAWSを利用して、その上で動くシステムの開発のインフラエンジニアとして仕事をしていました。

縁があって2022年11月に現職のほう、クラウド推進アーキテクトという立場で、「クラウドを利用したい」というお客さまに、導入支援をする立場で仕事をしています。なので基本的にオンプレミスで10年間、クラウドは4年目というかたちで仕事をしています。

この会に参加した経緯ですが、この会を運営している浪川さん（浪川舞氏）と2022年、前職の時にアジャイルコーチとして参加されて、出会って。2023年1月に「アジャイルコーチで培った経験を発表しろよ」と提案をいただいて発表しました。

2023年7月ぐらいに浪川さんとまた絡む機会があったんですが、「半年経ってけっこうお前もまともになってきたな。ここでちょっとまた成果を発表しないか」と。特にタイトルとか、私が何かしたいとかはなかったんですが、浪川さんのお言葉というか、師匠のお言葉で成果を発表するように指示をいただいたので、この会に参加したというところで、自己紹介と簡単な参加経緯は終わりになります。

圧倒的主観で語る「こんなクラウドはイヤだ」の4パターン

ではさっそく本題にいきたいと思います。「圧倒的主観で語る、こんなクラウドはイヤだ」というところです。たけし（ビートたけし氏）のモノマネがしたかったからこのタイトルにしただけなんですが、始めていきたいと思います。

本題に入る前に、2つお話ししたいことがあります。これは、自身の経験を通して「このパターンはクラウド利用の失敗につながる気がする」と感じたことです。感じたことを私の圧倒的主観で語っています。2点目として、圧倒的個人の見解である。所属組織の見解や意見を表明するものではないということを考慮いただけると幸いです。

というところでさっそく始めたいと思います。今回のイヤなパターンなんですが、4パターン用意してみました。モノとヒト、そして組織、文化の4つを考えてみたので、さっそくいきたいと思います。

「モノ」のイヤなパターン

パターン1、モノです。概念設計図なのに、最初から100人乗れるF1みたいなモノを作ろうとしている。スケジュールが遅延するし、当初計画していたものと程遠いサービスができがちだったり。コンサルが提案した聞こえの良い概念だけの案件で、違う会社が開発するとそうなりがちというのが、私の意見です。実際に自分が経験したところでこういうことがあったんですね。

クラウド導入をすることになって結果的に頓挫して、この案件自体が終わってしまいました。

イヤなパターンだけを話してもしょうがないので、じゃあどうしたら良かったかを自分の中で振り返ってみました。

最初から大きい完璧なものって、やはり実現できるかどうかもわからない。しかも概念レベルだと、そもそもできるかどうかもわからない。なので、Pocまたはpilotをしっかり実施して、その案件が実現可能かどうかを評価してから臨むところが大事かなと思います。

また、概念レベルって、分かりやすさはあるため、上の人にはけっこう響くんです。だから「やろう」となるんですが、走り出す前に「この概念設計、実装方法がぜんぜんわからないんだけど」と言って、上の人にどんどん詰めることが大事かなと思います。

なので、概念レベルでは始めない。これはクラウドもアジャイルも同じかと思うんですが、ちゃんと具体的な実装方法を検証してから本格着手するというところが通ずるものかなと思っております。

「ヒト」のイヤなパターン

では次です。パターン2、ヒトという軸で考えてみました。クラウド利用する体制メンバーを見てみたら、開発経験（アプリ／インフラ）が少ない人ばかりで構成されている。計画から開発、運用までテックサポートに依存しがち。新しいことにチャレンジングなマネージャーは、素直で柔軟なイエスマンみたいな若手だけで構成しがち。これも自分が体験してきたやつです。

どうすれば良かったかという話なんですが、マネージャーからすると反対意見がないのはやはり気持ち良いんですが、そうではなくて、疑えるような経験豊富なメンバーは必要かなと思います。1人じゃなくて2人は用意したほうが良いのかなと。私の主観ですが。

1人だけだとなかなかみんなを変えることはできないんだけれど、2人揃うと1人が主導しながら2人目がサポートするという、飴とムチな関係が作れます。サポートも、見えない部分をカバーできるということもあるので、2人は必要かなというところです。

あとは経験が乏しい人というのはどうしても出てくるので、こういう人たちをどうするかで、先ほどの大野（大野択生氏）さんの話に通ずるんですが、近道はなくて、やはり基礎は疎かにしないといけないということですね。

「クラウドを使えばみんな簡単にできるよ」という意見も上がっていて、確かにそれは事実としてあるんですが、個人的にはやはりクラウドになったとしてもインフラ部分は同じなので。ネットワークのOSI参照モデルの知識は必要だし、パフォーマンスとしてCPUとかメモリ、IOも見ないといけない、そういう知識が必要である部分は、別にクラウドであったとしても同じです。

確かにクラウドを利用すると簡単に実装もできるし、あまり知識がなくてもできますが、それであったとしても基礎は疎かにせずに大事にしたほうがいいのかなと思います。

「組織」のイヤなパターン

パターン3の組織です。開発グループ間の仲が悪く、決定に時間がかかる。よく見る光景としてインフラグループマネージャーとアプリグループマネージャーの仲が悪くなりがち、主観ですが。オペレーショングループのマネージャーはインフラグループとアプリグループのバチバチを静観しがちだったり。結果的にスケージュールが伸び伸びになることがありました。これも考えてみました。

悩んだのですが、難しいですよね。自分なら定期的なグループ横断の懇親イベントはやるかなと思いました。

チームで閉じてしまうと、そのチームの方針が見れなくて、外の部分、全体もやはり見れなくなります。お互いのことを知ること、あとは全体を俯瞰し共感・共有しあう事がやはり必要で、それがないとバラバラになってしまうのかなと思います。

なので、そういう意味で先ほどお話しした共感と尊敬のマインドと、先ほど大野さんが言っていたことと通じますが、私もそこはすごく大事かなと思います。自分の責任範疇ではないから見ないではなく、一緒に働くメンバーとしてちゃんと尊敬を持ち、共感しあって進めることが大事かなと思います。

「文化」のイヤなパターン

最後のパターン4、文化ですね。オンプレ時代のノウハウをクラウドに持ち込み、結果的にアジリティ・コストを低くするために入れたのに、その効果が出ないという話です。これはオンプレのノウハウが悪いという話ではないというところが注意点です。これも考えてみました。

実践編の話になるんですが、各クラウドベンダーは、クラウド導入フレームワーク、通称CAFと言っているものを提供しています。それは何かというと、まずは目的を明確にして、「目的に合うアクションって何？」というものを出してくれるアセスメントみたいなフレームワークです。そういうものがあります。

それを利用すると、目的がズレずに、適切なアクションが明確化されるのかなと。（スライドを示して）漢字が違うのは許してください。あとマインド的なものでいうと、「なんでクラウドを利用するんだっけ？」とか、「単純にオンプレから持っていくことが目的だったっけ？」「何か理由があるからクラウドを利用するんだよね？」ということを振り返るのが、マインド的には大事かなと思っています。

ちょっと時間が押してしまいましたが、以上になります。ご清聴ありがとうございました。