自立したエンジニアの集団に求められるマネジメントのキモは、任せること

AWSの最上位コンサルティングパートナーのなかでも、トップの実績を持つクラスメソッド。AWS事業本部 コンサルティング部 AWSシニアソリューションアーキテクトの菊池修治は、AWSからパートナーSEとして表彰も受けています。プレイヤーとしてもマネージャーとしても活躍する菊池が、自身のキャリアを語ります。

根本にあるのは「仕組み」への興味

少年期ははんだごてを使って、ラジオなどいろんなものをつくっていました。初めて運転免許を取得したときには原付バイクを購入し、エンジンをばらして組み立てるところまでしましたね。

そういうふうに昔から、人に任せるより自分でなんとかしてみるのが好きな性分でした。

中身を知りたくなるんですよね。昔はネットに情報が落ちている時代ではありませんから、改造雑誌を読みながらひたすら自分でやってみていました。

だからでしょうか。漠然とエンジニアを目指していました。

ただ、ITという縛りではなく、ハードウェアも含めて幅広い意味でエンジニアができればと思っていたんです。何かモノをつくるところで、自分の仕事が多くの人に影響を与えるような仕事に興味がありました。それで最初は、メーカーに就職を決めました。

キャリアの軸は、自分たちで手を動かせること

最初に入ったメーカーでは、いきなりプロジェクトマネージャーの仕事をしていました。お客様から依頼を受けたシステムについて、グループ会社と一緒に構築する部門に配属されたんです。ITのような汎用的な技術を用いた開発ではなく、特殊な機材を必要とする放送関係のシステムに携わることになりました。

いわゆる「本社」だったので、自分たちで手を動かすことはなく、グループ会社の業務をマネジメントすることがミッションでした。入社当時はひたすら議事録を書いたり、スケジュールをチェックしていましたね。

仕事は本当に忙しくて。幸いなことに残業代の出る会社だったのですが、ボーナスのような給料額になることもしばしばでした。やがて作業量に限界を感じたことと、受託でなく自社のサービスで何かしらしたいという理由で、5年半ほど従事した後に転職しました。

転職後は自動車メーカーで、自社サービスのエンジニアになりました。そこでは自動車に搭載するカーナビに、交通情報や目的地までのルートの配信をするサービスの運営を行いました。

転職前はプロジェクトマネージャーでしたが、業務上必要になることもあり、データベースやインフラを個人的に勉強していたんです。その知識を生かして、自社データセンターにあるLinux系サーバーの運用を行うようになりました。

それまでの仕事ではプロジェクトマネージャーという立場にあって、自分たちで主体的にシステムを触ったり動かしたりすることがありませんでした。プロジェクトマネージャーって偉そうだけれど、問題があると何もできないじゃないですか（笑）。

なので転職後の仕事では、自分たちで手を動かせるのがいいなと思い、その会社に決めました。

AWS、そしてクラスメソッドとの出会い

当時、その転職先のサービスのユーザー数は順調に増えていました。単に増えているだけならよかったのですが、データセンターにサーバーをラッキングして運用していた状態だったので、スケールについての問題が浮き彫りになってきたのです。

カーナビの通信量が増えるのはゴールデンウィークや年末年始です。自動車メーカーで暦通りに勤務するのが通常だったのですが、自分たちが休むときにシステムも混雑を極めます。自動車を運転する人が顧客になるので、コンシューマー事業です。障害時の風当たりもきついシステムです。

事前に予測してサーバー増加などの対策を施すのですが、それは当たったり当たらなかったりと効率が悪かったですね。そこで、クラウド移行の立案をしました。外部のSIerに協力を仰ぎつつも、最終的には自社運用に切り替え、データ移行も含めて手を動かしてシステムを移行しました。

システムが自社のためのものでしたので、突き詰めて作業をすることができました。少人数で運用していましたし楽ではありませんでしたが、自分ごとで作業ができたのは性に合っていました。自動スケーリングしてくれるのは運用上の負荷やストレスの軽減に役立ちました。

ここでAWSに触れ、技術情報を集めるようになりました。さらにWebの情報を活用して自ら勉強をするようにもなったのですが、会社でAWSの運用部隊は、自分の他に新卒の後輩がいるだけでした。AWSにのめり込むには少し物足りなかったのです。

いつしか事業会社のなかでサービスを運営するよりも、AWS自体に触れていることの方が楽しくなってきたんです。そんななか、クラスメソッドが外部の企業向けに開催したイベントに参加しました。2016年のことでした。

当時はクラスメソッドに関して、AWSのプレミアコンサルティングパートナーだ、というくらいの印象しかありませんでした。しかし、イベントにエンジニア向けの相談スペースが解放されており、クラスメソッドのエンジニアと直接話すことができたんです。技術的な話を思う存分できたのがとても楽しかったんですね。そうして2016年9月に、クラスメソッドへ転職しました。

「必要最小限のマネジメント」がクラスメソッド流

クラスメソッド入社後はAWS事業本部 コンサルティング部に配属されました。プロジェクトマネージャーも経験し、事業会社でSIerを活用しながら自社システムの運用することも経験しました。

AWSにとにかく触れることをメインにしたかったんです。昔からの気質なのか、自分でわかるようになるまで取り組んでみたくなりました。嬉しかったのは、事業会社にいたころによく読んでいたクラスメソッドの技術ブログ「DevelopersIO」を自分が書けるようになったことですね。

いいブログを書こうと思うとハードルは高いですが、お客様やAWSの方から「見ています」と言われるのは嬉しいですし、自分や自社の技術力をアピールできるメリットにも繋がっています。

お客様が悩まれているということでご相談を受けに伺って、その場でブログ記事をご紹介して問題が解決したこともあります。自分で調べてわかったことが人の役に立つことはとても楽しいです。

あるとき部長からチャットで「マネージャーやらない？」と言われ、マネージャーをすることになりました。とはいえ、メンバーの仕事を細かく面倒見ているわけではありません。部署のメンバーはバリバリのエンジニア志向が多く、優秀です。自立しているので、僕がとやかく言う必要がありません。指示を細かく出すよりはフルに任せてしまった方が、よりよい結果を出してくれるんです。

多くのマネージメントは、メンバーがやるべきことをきちんとやっていれば、必要ない決まり事に溢れているように思います。クラスメソッドはそういうルールがなく、管理する方もされる方も気持ちよく仕事ができるんです。ウチの様な会社では、マネジメントをしたいというモチベーションで来なくてもいいと思います（笑）。

事業やミッションとしてやりたいことがある。それをするために人手が欲しくなる。そのため必要最小限の管理が必要になる。そういう気持ちでマネージャーをしてもらえれば、クラスメソッドの文化を維持しながら更に大きな仕事ができるようになると思いますし、それができるかどうかが課題とも思っています。

個人的には、事業課題を解決したいというお客様にAWSを使った支援ができればいいですね。自分の知らない技術もまだまだありますし、キャッチアップをしていきながら、外部に発信していく仕事もしていきたいです。

海外など、より刺激の大きいところで活動できたら素敵ですね。