アンチパターンから考えるクラウド活用

三行でまとめると

• クラウドを始めてみたものの、人や組織の問題等でうまくいかないケースを目にする。
• うまくいかないクラウドにはパターンがある。
• アンチパターンへの対処策をまとめていきたいと思う。

自らを振り返るに

私がクラウドを使ったSI、もしくは導入をお手伝いしてうまくいかない場合は、実際に技術と戦っているケースよりは、 人(社内組織や体制や運用ルール)と戦っているケースに多く出会う。 他にもクラウドを使っただけ(仮想マシンをクラウド上に立てただけ)で、DevOpsの実現は出来ず、 実際の業務やエンジニアリングはオンプレミスの頃と変わらず活かしきれていない、そんなケースにも出会う。 どうして変化できず、もがいている組織や人が多いのか。これは何なのかずっと考えてきた。 クラウドの機能的な問題だけではなく、よく起こりやすい問題、及び対処方法としてまとめたい。 ※考えうる対処は、試行中であり、これからも考え続けていく問題ではあるが、 我々は何よりクラウドが提供する価値の本質を理解、再認識して、マインド(哲学)を変える必要があるのではないか。

1.運用設計に失敗

実際に数時間で構築できるものを稟議をあげて、社内でいくつかの打ち合わせを通し、 承認後、仮想マシンの作成ボタンをポチッと押す。 ほとんど、オンプレで新しい筐体を購入し、仮想環境にOSをインストールし、立ち上げていたリードタイムと変わっていない、という皮肉のようなケースがある。 その運用ルールだと依頼は二週間前にかけてください、構築にも半月強見てください、 というのはオンプレミスと変わらない、クラウド運用設計の失敗である。

→この場合、クラウド運用チーム(もしくは提供サービス企業)に依頼することは、 仮想マシンを作ってくださいという都度のお願いではなく、 運用を自分たちで効率化、自動化できるように指南してください、 もしくは現場で迅速に使えるように移譲してください、であるべきではないか。 特に継続して使い続ける場合、人が不要に関わる部分が継続してコストとしてかかってくる。

2.権限移譲していないため速度が鈍化

速めるには体制や現場への権限移譲が必要だ。現場に任せるべきである。 上の仕事は現場が迅速に回せる体制が出来ているかをチェックすることであってインフラや権限を囲い込むことではない。

→変われない組織の解決策として、社外から特命的なチームを呼ぶのは良いかもしれない。

3.DevOpsが回っていない

機能を改修したいという要望を受けてから、あなたのサービスは何時間で改修できるだろうか。 文言を直してくださいに対して、何分で改修できるだろうか。この速度が改善されていない場合、あなたのクラウドは大幅に見直す必要がある。 インフラの増強申請に数日でかつ作業は別業者、自社の社員がコントロール出来ないという状況だと技術的な負債を抱えている状態での運用と言って良い。

4.管理の自動化をしない

クラウド上での管理作業はほとんが自動化でき、多くのメンバーの労力や時間を解放する。 人的なミスがなくなり、運用の安定化を生む。継続的に改善していくのにも必須だが、そこに踏み込まず、手間のまま続けて運用してしまう。

→継続的に使用するケースは自動化されていない作業の見直しを。

5.何を監視するのか把握していない

監視だけ別の会社に依頼するというのもあるが、単にCPUやメモリやディスクを監視して対応が後手に回るケースは多い。 もちろん環境の監視は重要だが、それ以上に安定したサービスの状態を定義して、共有することが重要だ。

→何をもって正常とするかが大事。何をもって正常なのか、定義できるのはサービスを作った人間で、その意見に従って監視を組むべきである。 特定のサービスやURLのステータスコード、及び処理時間など、サービスとして監視することが重要だ。 DevとOpsがわかれると、サービスの質ではなく、CPUやメモリ、ディスクといった問題の側面を見る役が出来てしまう。

6.速度の価値について理解していない

速度は欲しいサービスがすぐ手に入るクラウドの代表的な恩恵の一つだ。 速度の違いは何を生むか？競争力である。1日何件改善できるか？PDCAを高速に循環する。 失敗を早い段階で得て、少ないコストで成功への舵を切り直す。高速で回すほど差がつく時代になった。

→速度については、実際に見せてみる、実績を作ることで賛同者を増やしていくことが大事かもしれない。

7.減点主義組織との相性は悪い

クラウドの特徴として、日の浅さ、新機能が随時提供され変化が激しい点がある。 これに対し、変化に追従できず、仮想マシンを立ち上げて終了、クラウド上にある有効な他のサービスを使わずという恩恵を十二分に得られないケースがある。 失敗から得られる経験や教訓は何にも代え難く、サービスの血となり肉となるわけだが失敗を許容しない組織では、チャレンジが難しい。 組織自体が減点主義の場合、クラウドでもチャレンジしにくくなる。

→その場合は、超ミニマム体制で仮説検証を続けチャレンジするチームを作るなど、体制自体考え直すことができる。

8.工数積算の考えを捨てていない

自動化が進むクラウドの世界では、工数積算の考え方ではビジネスしづらい。 ※これについてはネットコマース社の資料によくまとめられている。

→クラウドでの安定運用には自動化は必須であり、しようと思った場合、 いかに頑張ってインフラを作るかというところから、いかに頑張らないかにシフトしてくる。クリックかスクリプトか設定ファイルで、作れるのだ。 頑張らない事を頑張る人の方が向いている。(一般的なエンジニア素養の一つでもある) 苦労している場合何らかのフローが間違っているか最適化されていない。

9.オンプレミスと比較してのデメリットを伝えていない、知らない

ある王子が言っていたが、クラウドは使うと良いですよ！というメッセージに固執したため、 オンプレミスと異なる部分についてなどデメリットを説いてこなかった。 ゆえにオンプレミスと違う部分について、仕様の違いを受け入れられない人が生まれ、 オンプレミス仕様に固執する人もいる。

→オンプレミスとの違いを事前に伝え、マインドを変えてもらうことが必要

10.プロトタイピングせずリスクを負う

大号令のもと1,2年くらいかけてリニューアルするような大規模開発より、現場の担当者が即時に環境を立ち上げ、 数時間後にはサービスプロトタイプを作りあげるような形が求められている。 が、やはり要件定義からゴールの見えないウォーターフォールを行っている企業は多いように思われる。

→組織構造が複雑な場合、プロトタイピング専門のチームを作るのが良い。

11.自社の社員(メンバー)が触っていない

導入したクラウドを自社の社員が触っていないという状況は良くない。 クラウド＝インフラ＝専門の人が触るものという固定観念がある。 実際に目の前でポータルやスクリプトから構成を組むと、こんなに簡単なんですねと皆さん言ってもらえるわけだが、触る事によってマインドも変わってくる。 作ってミスしたら作り直せば良い。この速さに触れると、仕事の概念が変わる。 失敗が許されるようになり、試して確認してダメならやり直しが当たり前になる。 速度が優先され、失敗に寛容になり、経験から同じ過ちをおかさないようになり、精度があがる。組織に良い影響を与える。

→目の前で構築の様子を見せて、触ってもらおう。

12.一括⚪︎⚪︎クラウドへ移行という思考停止

一昔前だと聞こえが良いかもしれない。が昨今だと唱えるのが楽であるだけで、思考停止に近いかもしれない。 そもそも企業のインフラはオンプレミスの際一社の何かで統一されていただろうか。あまりないはずだ。 パブリッククラウド海外大手や国内、プライベートクラウド全てどこかが優れているということはなく、いずれも得意な領域、突出したサービスを持つ。 これらを組み合わせで適材適所で使うことが企業の競争力となる。

→一括⚪︎⚪︎は思考停止の結果ではないか、見直した方が良い。他の選択肢を持たないリスクについても把握した方が良い。

13.クラウドが好きというメンバーがいない

AWSでもAzureでも良い。導入に関わっている人に注目している機能、最近のニュースを振ってみると良い。 必要以上に教えてくれたり、まだGAしていない機能を試した結果や課題を教えてくれる。 特定の機能はその人の技術者としての人生、サービスの在り方を変えるくらいの影響を持つ。 当然、好きな技術者は追いかけ、追いかけていない方とさらに差がつく。

→クラウド好きな人と仕事しましょう

14.マインドの変え方がわからない

→コミュニティにいきましょう。 コミュニティで活き活きとした人を見れば、ヒントになるはず。 最近はイベントもコミュニティよりなのと、お堅い人向けで微妙に分けられてしまっている感がありますが、なるべくコミュニティよりに。 クラウドを使ってもっと幸せになるには？ 是非、みなさん議論して、良い世の中にしていきましょう。