こんにちは。10年ぐらいエンドユーザー企業の情報システム部門でAWSを担当し、AWSが大好きになってしまい、ついにAWS専業のクラウドインテグレーターに転職してしまった大瀧です。
きっと、私と同じことを思っている方も多いかと思いますので、クラウドインテーグレーターで働くとはどんな感じなのか、エンドユーザー企業でAWSと接するのとクラウドインテグレーターとしてAWSに接するのと何が違うのか？について紹介したいと思います。
「サーバーワークスに興味がある！」または「クラウドインテグレーターで働きたい！」という皆さんの参考になればと思います。
クラウドインテグレーターで働くってどんな感じか？
一口にクラウドインテグレーターと言っても働くポジションは様々です。 サーバーワークスにも沢山のポジションがありますが、大まかに分類すると以下になるのかと思います。
- 事務／総務
- 営業
- 営業支援（ソリューションアーキテクトはこのポジションになります）
- 構築する人（実際にAWS上にリソースを構築する、運用保守に必要な仕組みを構築する）
- 構築するものをマネージメントする人（プロジェクトマネージャー）
- 構築したものを保守する人（保守サポート）
- 保守しているAWSをよりよくするために活動する人（カスタマーサクセス）
- AWSを社外社内に啓蒙する人（エバンジェリスト？）
私は現在、5のポジションで仕事をしています。なので5のポジション目線でクラウドインテグレーターで働くってどんな感じかをお伝えしたいと思います。
どんなことをするの？
基本的にはプロジェクトマネージャーと同等の仕事と思っていただいて問題ないかと思います。 仕事の流れ、仕事の内容としてはざっとこんな感じです。
案件を理解する
上記でお話しした営業、営業支援にてお客様から獲得した案件を理解し、AWSの構成構築内容や運用保守に必要な仕組みを理解します。
案件に必要な作業工数を算出する
案件を完遂するための作業工数を割り出します。 案件の受注範囲にもよりますが、通常はAWS環境の構築、運用保守要件定義作業とその仕組みの実装が主な工数となります。 実際は工数算出したものはプロジェクト計画書という社内共通の案件管理シートに記載し、社内的な承認や共有することになります。このプロジェクト計画書の策定が最初のタスクとなります。
工数管理
メンバーの工数、自身の管理工数が予定とオーバーしていないかとかを定期的にチェックします。 工数が確定すると、自動的にそれは日々この案件に割ける時間の制約となるため、週単位で厳しく管理します。 工数オーバーは原則NG（案件として赤字計上となるため）、オーバーの際は理由を明確にして対策を講じます。
進捗管理、課題管理
案件を進めていく上で必要なタスクを洗い出し、課題化、WBS化して行きます。課題管理システムはBacklog、Jira等を利用しますがお客様管理の課題管理システムを利用することもあります。 課題化については構築メンバーに主体的に挙げてもらいますが、WBS化や課題化の抜け漏れのチェックは、このポジションを担うメンバーの大切な仕事です。
お客先対応／お客様窓口
主に定例のファシリテーションを起点にお客様と案件を担当するお客様側の担当者とのブリッジを行います。 案件を完遂する上で、お客様との定期ミーティングは不可欠です。
通常は週一回1時間程度、案件を進める上での課題や問題点の共有、進捗の報告（時間節約で概況程度）、お客様への要望やお願いなどもここで行います。原則、ファシリテーションはこのポジションを担う人が行うのがBESTです。
1時間という枠の中で、わかりやすく、効率的にミーティングが進められるかどうかは腕の見せどころかと思います。 ミーティングをスムースに進めるためには、事前準備（的確な課題抽出と解決ストーリー）と事前ネゴ（Slackとか関係ドキュメントの事前共有など）もとても大切です。
構築したものを保守チームへ引き継ぐ
サーバーワークスではお客様に対して構築したAWSを、サーバーワークスの保守スキームに乗せてそのまま運用保守をする方向で商談を実施しています。
弊社内の保守チームへ保守に必要な情報を提供し、案件のカットオーバー後に円滑に運用ができるよう調整を行います。引き継ぎに必要な項目としては以下となります。
- 保守項目と保守フロー
- 保守手順書
以上の作業がおおまかな一連の流れですが、これ以外にも関係部署へのプロジェクト進捗報告の適宜実施、工数管理はプロジェクト計画書とセットで、プロジェクトが終了した際に収支報告（赤字だったのか黒字だったのか）を全社的にアナウンスしなければいけません。 無論、赤字となった場合は、その原因を明確にし、今後そういったことが他案件でも起こらないよう、社内的な共有も必要となります。
そう考えると、なんだか、ちょっとした個人経営者みたいな感じがしますね。
大変なところ、難しいところってなんでしょうか？
はっきり言って、要件はズレます。絶対ブレます。
お客様も私たちも、AWSの仕組みを使ってより良いものにしたい気持ちは同じで、その気持ちがコスト（工数）と期間（納期）を無視させがちです。（これはIT関連全般に言えることですね）
その辺をやんわりとあまり波風たたないよう、円満に軌道修正することはとても大変で難しいです。 自身が矢面に立つことになるので憎まれ役をやらねばいけないこともあるし、立場上自分のポリシー（正義感とか）と反する意見を言わないといけないシーンもあり、ストレスになることも確かです。
やっていてよかったと思うところってありますか？
構築するのも悪くないですが、先ほども少しお話しした通り個人経営者的な感覚で案件全体を見渡せコントロールできる感覚は充実感があります。
言い方は良くないかもしれませんが、プロジェクトが赤字か黒字かでビジネスの白黒（勝ち負け）がはっきりさせられます。 例え、赤字であっても何を犠牲にし何を得たのか？その得たものは会社的に貢献できるものが残せたかが明確に説明できるのであれば、社内的にはOKなので心配ありません（と思っています。。）
サーバーワークスでは沢山のポジションがあるとお話ししましたが、クラウドインテグレーターのビジネスモデルを最も体感できるポジションではないかと感じています。
エンドユーザー企業でAWSと接するのと、クラウドインテグレーターとしてAWSに接するのと何が違うのか？
この記事を書いている現在、サーバーワークスにJoinし2ヶ月が経過しました。 入社前に思い描いていたことと、実際に入社してみて感じるギャップはやはりあります。 （この辺は、面接前にしっかり自分への期待値、仕事の仕方や進め方を面接官と無論すり合わせしており、予想はしていたのですが。。） 率直な今時点でのギャップついてお話しします。
AWSに対する接し方が全然違う
ここはAWS好きの私にとっては、まさに入社してよかった！と思うところでもあります。いい意味でのギャップですね。
圧倒的なAWSに関する情報量
社内Slackでは常にAWSのUpdateが流れ、それに関する社内検証の結果や討論、お客様案件で困っていることの相談と回答が頻繁に行われています。 課会ではAWSの気になるUpdateや技術を持ち回りで発表したり、案件共有会では実際に構築した案件の内容やポイントが定期的に発表されています。 まさに、リアルAWSデザインパターンの宝庫で、しかも現実的なトラブルシューティング付きの解説付きです。これはGoogleで検索しても出てこないし、AWSの技術サイトでは載っていない情報がほとんどです。
資格取得に対する姿勢の違い
AWS認定取得に関する社内優遇はハンパないです！
受験費用補助、合格時のインセンティブ、合格に必要なノウハウの社内共有の仕組みも充実しており、やる気さえあれば全てのAWS認定資格取得の夢ではない環境ですね。 あと名刺に取得した認定資格がプリントできる仕組みがデフォルトであるのもサイコーです！！ 合格時には週次の全体朝礼でのアナウンス、Slackでのアナウンスもしてもらえます。
本当にAWS漬けになる
おそらくポジションに関わらず、なんらかの形で常にAWSに触れることになります。 エンドユーザー企業だとAWS担当と言ってもそれ以外の業務、技術もやらないといけないと思いますが、サーバーワークスに転職すれば、AWSが仕事のメインで会社としてのメインテーマとなるので、AWS以外のこと考えなくて良くなります。会社の価値観がAWSって、AWS好きにはたまらない魅力だと思います。 だって、自分の好きなこと追求すれば、会社で褒めてもらえるんですから。
AWSが得意な人しかいないので、話題がコアすぎる
エンドユーザー企業にいた当初は自分がAWSのテックリードで、めちゃめちゃ詳しいと思っていましたが、残念ながらサーバーワークスに入社すると、自分のスキルなど一般的なAWSの技術者に過ぎなかったことを思い知らされます。 （私もAWS認定資格は6個取得しており、転職市場ではかなりの高評価だったのですが。。） 社内Slackを眺めていると、討論されている内容は理解不能なレベルのものが多々あるため、勉強することには事欠かない状況になります。 おそらくソリューションアーキテクトのプロフェッショナル認定を持っていても、知らない情報がやりとりされています。 AWSから表彰されている人はいっぱいいるし、認定資格5~6個は当たり前、目標とすべきAWSエンジニアはゴロゴロ存在しています。目標とするエンジニアが身近にいっぱいいて刺激になりますね。
案件に割ける工数が決まっており、より良いものを作る時間に制約がある
ここは今時点で一番辛いところです。悪い意味でのギャップですね。。
サーバーワークスに入社する前はエンドユーザー企業のIT部門で働いており、以前であれば自社製品の開発となるため、良いものを作るためには、その手間隙を考えず妥協なく仕様の変更や工期の変更は当たり前でした。
基本、ほとんどメンバーは裁量労働制で残業や作業時間（工数）という縛りで仕事をしているわけではなく、OKRと呼ばる成果目標に従って評価がおこなれるため、ある意味コスト度外し（工数と成果が比例しないことも多い）で、良いものを作ることだけに没頭していました。 なので、”販売原価が決まっているので、赤字にならないよう決まった時間内しかこの作業をしたらいけないよ”みたいな縛りでモノづくりに関わっていかないといけない今の状況はとてもストレスです。
案件に紐づく売上の範囲の中で最善なモノを提供するといった考えは理解しているつもりですが、あーここはさらに手間暇かけて議論、設計したいなと思う気持ちを抑えるのは、まだまだ時間がかかりそうです。
圧倒的に1案件に関わる時間が少ない
これはインテグレーターである以上、当たり前なんですが。。
サーバーワークスでは無論沢山のお客様のAWSの構築、保守運用を行っており、案件を回すスピードは概ね6ヶ月程度（早いものであれば2~3ヶ月を切るものも多いです）しかありません。 私のポジションは、運用保守ではなく、案件構築に関するものなので、お客様案件をハンドリングし運用保守のスキームに乗せた時点で、そのお客様からは担当としては離れてしまします。
以前のような自社案件を熟成させる仕事の仕方ではないため、数ヶ月単位で仕事のしきり直し（案件内容も全く違えば、そこで接するお客様も、社内のアサインメンバーも異なるという意味）が必要で、そこは少し寂しい気持ちになってしまうことはあります。。
沢山のAWSのデザインパターンに触れたくて、自分で決めて飛び込んだ世界ではあるので、そこは自分にそう言い聞かせつつ精進しています。
最後に
最後まで読んでいただき誠にありがとうございます。 実は私、IT業界歴は長いものの社外に向けIT系のブログを書かせていただくのは、この記事が第一号となります。 サーバーワークスの一員としてブログを書けたことを少し興奮しています。
これからは、さらにAWSマニアの皆様のお役に立てる記事、共感してもらえる記事をバシバシ投稿して参りますので今後ともどうぞよろしくお願いいたします。
