この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
コンバンハ、千葉（幸）です。
クラスメソッドは 2021年07月01日に18期を迎えました。
そのタイミングから、わたしは AWS 事業本部コンサルティング部（以下「コンサル部」）のマネージャーとして活動する運びとなりました。
「あ、じゃあ偉い人なんですね」と思われた方がいるかもしれませんが、まったくもってそんなことはありません。そして、まったくもって、そんなことはありません。 *1
コンサル部はおよそ 50 名からなる部署ですが、その中にマネージャーの役割を持つメンバーは 7 名います。プラス部長が 1 人います。そういう感じの位置づけです。
コンサル部のマネージャーって何するの？を頭の整理を兼ねてブログに書いてみようと着手したのですが、そこに至るために「コンサル部とは」という説明をする側面が強くなりました。
というわけで、本エントリでは「コンサル部ってどんな部署なの？」をメインテーマに書いていきます。
主たる想定読者は以下のとおりです。
- コンサル部の雰囲気を知りたい方
- これから応募しようと考えている方
- クラスメソッドの他部署の方
- なんでもいいからポエムを読みたい方
以下の方にとってはそこまで面白くないものだと思います。
- 世間一般のマネージャー論といったものを知りたい方
- コンサル部のメンバーの方（知ってることばかりだから）
- 今はちょっとポエムを読む気分じゃない（ノーポエム、プリーズ）という方
まとめ
わたしの考える誤ったコンサル部のマネージャー像です。
わたしの考えるコンサル部のマネージャー像です。
平たく言えば、主役はチームメンバー自身であって、マネージャーはそのサポートをする役割である、という考えです。
先に断っておくと、コンサル部のマネージャー全員がまるきり同じ価値観をもっているわけではないので、本エントリにおけるマネージャー像はあくまでわたし（しかも現時点の）が描いているものです。
コンサル部の概要
コンサル部について説明していきます。
コンサル部の位置づけ
複数ある事業本部の中の一つである AWS 事業本部、その一部署がコンサル部です。
他の部署もある程度具体的に書こうと思ったのですが、割とガラッと組織変更があるのでやめておきました。18期にも大幅な刷新がありました。
コンサル部におけるロール
大きく以下があります。
- AWS エンジニア
- ソリューションアーキテクト（SA）
- エキスパートソリューションアーキテクト（ESA）
- マネージャー
- スペシャリスト
図はステップアップのパスを表します。2021年07月現在では、以下のロールに該当する職種を募集中です。（時期により募集要項やその有無が変動する可能性があります。最新の情報を確認してください。）
- AWS エンジニア
- ソリューションアーキテクト
新しくジョインされた方は AWS エンジニアもしくは SA としてスタートし、ひとまず ESA を目指します。 ESA になると一人前（一人で対応可能）、という感覚です。元々のスキルに依るところも大きいですが、それぞれのステップアップの間隔は数ヶ月〜 1 年程度となることが多いです。
余談ですが、最近、部署移動により営業職から AWS エンジニアにジョブチェンジしたメンバーがいます。
とてもチャレンジングな試みだと思いますし、実際に行動に移せるところを尊敬しています。
ESA の先としては、マネージャー職があるほか、スペシャリストとされる位置づけも用意されています。このあたりの肩書きは割とコロコロと変わるので言葉自体にそこまで意味はないのですが、社内の等級としては ESA のそれとは厳密に区別されています。何かしら尖った部分を持つ人がスペシャリスト（仮称）という位置づけとなります。
コンサル部のチーム構成
2021/07現在では以下のような構成となっています。
- AWS エンジニアからなるひとつのチーム
- 複数人の ESA がリーダーとして参加（兼任）
- SA/ESA（スペシャリスト含む）からなる複数のチーム
それぞれのチームにはマネージャーが存在します。
17期までは SA/ESA チームは 4 つだったのですが、SA/ESA に昇格したメンバーが増えたこと、1人のマネージャーが見れる人数には限界があることから、 6 チームに増加しました。
ここでのチーム構成は、主にコミュニケーションの単位として機能します。言い換えると、一つのチームとして同じ案件に対応する、という区分けではありません。案件対応については後段でも触れますが、「同じチームのメンバーだけど具体的にどんな案件に対応しているのか知らない」ということはザラにあります。
ちなみに
わたしの所属チーム名は以下のとおりです。
イカしてますよね。他にもいろんなチーム名があります。どんなチーム名があるか知りたい方は……なんらかの手段で、どうにかして聞いてください。
コンサル部メンバーがやること
大まかに以下のとおりです。
- プリセールス
- 案件対応
- アウトプット（ブログ、動画投稿、登壇など）
- 社内活動（タスクフォース、改善活動など）
人によって時間の配分は異なりますが、案件対応に多くの時間を割いているメンバーが多いです。案件対応をしない代わりに他の業務でバリバリバリューを発揮しているメンバーもいます。
稼働を 100% 案件に注ぎ込むのではなく、ほどほどにして他の活動もしようね、というのが基本スタンスです。（最近ではコンサル部が全体的にリソース不足で案件対応に偏りがちではあります、、）
コンサル部の案件対応
「案件」の種類はさまざまです。
- 期間：1 ヶ月〜 6 ヶ月程度
- 工数：10 時間〜 200 時間程度
- 対応人数：1 人〜 3 人程度
- スコープ：要件定義〜構築、アセスメント、QA対応など
上記もあくまで例であり、必ず記載された枠におさまるわけではありません。「単純な構築を一週間でやっておしまい」「数ヶ月 複数メンバーでガッツリ入って要件定義から設計・構築まで実施」という案件もあれば、「細く長くアドバイザー対応」というものもあります。
コンサル部では 3 ヶ月を超える案件は「長い」という印象になります。長くなりそうであればフェーズやスコープを区切って別の案件として切り出して対応する、ということもしばしばあります。
各メンバーはこういった案件を掛け持ちし、複数を並行しながら進めていきます。案件は基本的に挙手制であるため、自身の稼働を見合いながら対応したい案件に挙手し、アサインされる、という流れとなります。（メンバー間の負荷状況により逆指名の場合もあり。）
セルフマネジメント
案件にも波があるので、そこの予測を失敗すると一時的に負荷が高くなります。そういった時はヘルプを頼むか、気合でなんとかします。わたしはだいたい気合でなんとかしてき（てしまっ）たので、マネージャーとしてはあまり良くない実績の作り方だと自覚しています。
メンバーには「忙しくなりそうなら早めに教えて、マジでマジで」というメッセージングを繰り返していきます。（マネージャーやメンターが細やかにそこをウォッチする、という文化ではなく、メンバーがプッシュ型でアラートをあげる、というセルフマネジメントの文化です。）
アラートが上がったときにはマネージャー自身が巻き取ったり、追加メンバーをアサインしたりします。
コンサルティング？
以前どこかで社外の方から「コンサルティングっていうことはパワポで資料を作って提案するのが主で、自分で手を動かしたり技術的なことに取り組むことはできなくなりますか？」と質問をいただきました。
世間一般で「コンサルティング」と聞いて思い浮かべるのは確かにそうだな、と思った記憶があるのですが、実際にはそんなことはありません。
設計や構築を行う機会は沢山ありますし、むしろドキュメント類にはなるべく手をかけたくない、と思っているメンバーが多いです。わたしもパワポはうまく使えません。よくスペースキーを叩いて体裁を整えます。
コンサル部におけるコンサルティングとは、アーキテクチャのレビューやアセスメント、設計支援などを意味することが多いです。いずれもお客様に自走いただくための支援をする、というのが根底にあります。
メンター制度
AWS エンジニア、SA にはメンターがつきます。
AWSエンジニアはチームのリーダー（ESA）がメンターにつき、比較的単純な案件に取り組みます。ある程度 定型化された構築案件が多く、そこでは手厚めのフォローが入ります。
SA は（基本的に）同一チームに所属する ESA がメンターにつきます。案件の属性は設計やアセスメントなど多岐に渡り、ESA が対応するものと区別はありません。SA は主担当としてオーナーシップをもって案件に取り組み、不明点があればメンターに質問・相談をする、という流れです。
案件対応はチーム単位で行うものではない、という話は先にしましたが、案件あたりの対応人数は主に 1 人、多くても 3 人程度です。メンターはその人数とは別カウントとして付きますが、案件にガッツリ入るわけではないし、手取り足取り教えてくれるわけではありません。
正直なところ、メンターとしての取り組みはチームごと、個人ごとに委ねられているのが現状であり、「メンターだったら全員こういうフォローをしてくれる」という定形化されたものはありません。もちろんこういった部分も課題として認識されれば改善が検討されるものですが、過度な期待をしてはいけない、というのが基本スタンスです。
オーナーシップを持つ、分からないことを抱えずカジュアルに質問して解決する、気づいたことがあれば積極的にフィードバックする、というのがコンサル部の求めるメンバー像だと考えています。
（話の流れにうまく組み込めなかったのでここに書きますが、マネージャーもそれぞれのチームでメンターを担当します。）
コンサル部のブログ
コンサル部に限らずクラスメソッドではブログの執筆が業務の一環として認められています。業務や学習を経て得た知識をアウトプットして行こう、というカルチャーです。
コンサル部のメンバーもたくさんブログを書いています。執筆したブログの数を見るとやはりコンサル部によるものが一番おお……あれ？え？ あぁ……え？ *2
まぁなんやかんやありますが、わたしがブログの好きなところをいくつか紹介しておきます。
目に見える
ご存知でしたか？ブログは目に見えます。すごいですよね、こんなにも目に見えないものに溢れている世の中で、ブログは目に見えるんですよ。「想い」は目に見えないけど、ブログは目に見るんですよ。すごいですよね。
誰の目に見えるかというと、それは自分自身であり、同じの部署のメンバーであり、別の部署のメンバーであり、案件で関わったお客さんであり、まだ会ったこともない社外の人であり、そしてその他大勢が該当します。そんなもの他にありますか？まぁいくらでもあるんですけど、それを差し引いてもすごいですよね。
消えない
ブログは消えません。こんなにも儚く消えていくものに溢れている世の中で、ブログは消えないんですよ。すごいですよね。今にもわたしの頭の中の消しゴムがいろんなものを消していっているのですが、ブログに書いたことは消えません。
一年前に必死になって覚えた Transit Gateway のコンポーネントやパラメーターはすっかりわたしの頭の中から消え去りましたが、当時書いたブログは残っています。適当に検索して読み返せば思い出すことができます。安心して忘れることができるし、空っぽになった頭に別のものを詰め込むことができます。
修正できる
ブログ以外にもアウトプットの手段はありますが、書籍や動画の場合、後から修正することは困難です。それらに比べればブログは修正が容易ですので、加筆をしたり、指摘を受けた誤った箇所を修正する、といったことがカジュアルにできます。クラスメソッドではフィードバックを行う/受ける、ということをポジティブに捉えています。
最初から完璧なものを仕上げてアウトプットするというのはハードルが高いですので、「いざとなれば修正できる」を拠り所にまず出してみる、が好ましいと考えています。それで質の低い（誰の役にも立たない）アウトプットになってはもちろんいけませんが、慎重か大胆かで言えば後者を選択するのが会社のカルチャーにマッチしていると思います。
クラスメソッドの入社前から DevelopersIO はよく購読しており、何度も助けられてきました。せっかく DevIO というフォーマット上でブログを書ける立場になったので、どこかの誰かの役には立つ、そんなアウトプットを続けていきたいです。
「クラスメソッドに仕事を頼もうと思ったけど、ブログに全部書いてあったからそれで済んだ」ということになれば最高ですよね。
コンサル部のマネージャーになった
なりました。
マネージャーの打診
期が変わるひと月ちょっと前に打診がありました。
「どう？」と言われてから 96 秒で「やります」と返事をしました。もっと短い記録を目指せると思うので、記録と向き合っていきたいです。
当時はチームが増えることは知らなかったのですが、マネージャーの空きが増えることは把握していました。（自分が所属していたチームのマネージャーが部長に繰り上がることが確定していたため）
以下のような思いから、マネージャーになることをぼんやり考えていました。
- コンフォートゾーンにとどまっている感覚があり、新しい取り組みを行いたかった
- マネージャーってめんどくさそう。でも自分がめんどくさいことを引き受けた結果 ほかのメンバーがパワーを発揮できるならそれはそれで楽しそう
加えて、コンサル部の中で技術的につよつよになる（特定分野を深掘りしている、最新技術にキャッチアップしている、満遍なく知識を有している、など）ことを諦めたというか、自分がそうなっているイメージがつかなかったので、ほかの領域で価値を発揮していきたいなと（これもぼんやり）思っていました。なのでマネージャーになりました。
マネージャーの選定基準
マネージャーになってから、「次のマネージャーは誰がいいだろう？」という過去のチャットでのやりとりが見れるようになりました。
自分のことに関して言うと、ざっくり言うと以下の感じでした。
- 案件対応とかブログ執筆をたくさんやってる
- なんか楽しそうにやってる
- なんか良さそう
もちろん「なんか良さそう」の裏にはいくつかの要素があるのですが、次に新たにマネージャーを選ぶにしても、「なんか良さそう」が一番の決め手になるのかなと考えています。
（少なくとも「マネージャーになるためにはこれを満たす必要がある」といった定形化されたものはありません。）
マネージャーの役割
冒頭の絵を再掲すると、わたしが考えるマネージャーの役割は以下です。
わたし自身は野球にそこまで詳しくないし、過度な例え話は禁物だということは理解しているのですが、今回はポエムなので、ゴリゴリの例え話で進めます。
プレイヤーである各チームメンバーは日々練習したり、試合に出たり、打席に立ったりします。「コンサル部メンバーがやること」で取り上げた、案件対応やアウトプット等が該当します。
マネージャーは、監督の指示を伝えたり、スコアボードをつけたり、ユニフォームを洗濯したり、ボールを拾ったりします。プレーヤーが存分に打席に立てるように、障壁となるものを取り除くのが主たる役割です。
一方で、マネージャーでしかできないことはそこまで多くありません。マネージャーにしか鍵が預けられていない引き出しはありますが、それに関係ない業務はたくさんあります。プレイヤー自身で監督に話に行ってもいいし、自分でボールを拾ってもいいです。練習メニューを考えてきてほかのチームに伝播させていってもいいです。
そして、マネージャーになったからマネージャー業のみに専念するわけではありません。案件対応の割合は抑え目にシフトしていっているのですが、引き続き素振りはするし試合にも出ます。
「今月はプレイヤーであるチームメンバーより多くヒットを打った」というのも実現する気満々です。
くどいようですが、これはあくまでわたしの考えです。（そして「現状のチームにおける」という注釈がつきます。）マネージャーによって考え方は変わります。
上記を踏まえて、チーム発足時にメンバーに伝えたことを書いておきます。
マネージャーとして行うこと
- 各種雑務（申請、手続き、連絡など）
- メッセージング・チームビルディング
- 一次エスカレーション窓口
- プル型の相談受け付け
マネージャーとして行わないこと
- 積極的なプッシュ型のフォロー
- 技術的なリーディング（できない）
- 細かいマネジメント
- 指示
チームとして行うこと
「チーム分けは主たるコミュニケーションの単位」という話を先にしました。社内で使用しているチャットツール（Slack）のチャンネルはチーム単位で分かれているものがあるので、軽い雑談のようなものはそこで行われます。（案件対応チャンネルや技術的な質問チャンネルはチームを横断して存在します。）
テキストコミュニケーション以外に設けている取り組みとしては以下があります。（2021年07月現在、以下は全てリモートで行っています。）
- 週報会
- 原則参加必須
- 週次で 30 分程度
- その週に行った業務の概要や近況の報告
- 雑談会
- 参加自由
- 週次で 30 分程度
- ただ集まってだべる
- 1 on 1
- 月次で 30 分程度
- マネージャーとメンバー間での 1 on 1
- 何を話すかは人による
- JD（ジョブ・ディスクリプション）
- 四半期ごとで 60 分程度
- 四半期の振り返りと次の四半期の目標設定
- マネージャーによるメンバーに対する評価の材料となる
わたしがマネージャーを務めるチームはほぼ全員が ESA であり、一人でなんでもできてしまうメンバーの集まりです。なので、今のところマネージャーらしい動きをしていないというのが正直なところです。
「あいつマネージャーとして何もしてなくない？」と思われるのも、それはそれでいいかもしれません。
小さく興奮し続ける
自身のチームのテーマとして、上記を設定しました。
簡単に言うと以下の通りです。
- 興奮していたい
- ここでいう興奮とは、「つまらない」の対義語
- コンフォートゾーンにとどまっていたり、マンネリ化したタスクを行っているのは楽しくない
- 楽しいと感じるためには、肉体的、精神的に健康である必要がある
- 小さく続けたい
- 何ごともほどほどが一番
- いっときのバーストより安定稼働
- 小さくでいいから、続けることが大事
これはクラスメソッドのカルチャー、Classmethod Leadership Principle（CLP）における「やってみる」と「楽しむ」を特に体現するために設定しました。
なお、理由は思い出せないのですが、わたしは CLP に「興奮する」が含まれているとずっと勘違いしていました。
「まかせろ、俺に。」
先にチラッと紹介しましたが、わたしがマネージャーを務めるチーム名は「まかせろ、俺に。」 *3 *4です。
このチーム名は以下の思いを込めて付けました。
- みんなから頼りにされる
- 助けを求められたら「まかせろ」と言えるスキルセットを持つ
- 誰かが困っているのを見つけたら「まかせろ」と拾いに行けるマインドセットを持つ
これらは CLP における以下を意識しました。
- リーダーシップ
- パートナーシップ
- プロフェッショナル
理想を掲げるのは簡単ですが、実現するのは困難です。現実的に今「楽しんでいるか？」「ヘルプを求められたらまかせろと即答できるか？」と問われたら、 Yes と答えられるメンバーは少ないかもしれません。でもせっかくクラスメソッドで働くなら楽しみたいですし、ビジョンなしに進むのは大変です。（なので理想を掲げていきます。）
案件はそれぞれ別のものに対応しているけれども、チーム一丸となって目標に向かっていく、というのを実現してみたいです。「ちょっと最近マンネリ化してきたな……」と感じていた去年のわたしに対して答えが出せるようにやっていきます。
これから頑張ります。
はい。
特に深い意味はありませんが、いくつかリンクを貼っておきますね。
- AWSエンジニア | キャリア採用 | クラスメソッド株式会社
- 【急募】AWSソリューションアーキテクト | キャリア採用 | クラスメソッド株式会社
- 会社説明会 | キャリア採用 | クラスメソッド株式会社
創立記念日のポエムでした。
以上、 チバユキ (@batchicchi) がお送りしました。
5
