この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
どうもどうも、荒井です。チョコはもらえましたか？
先日はAWSのマネージャーに話を聞いてきたので、今回はその第二弾！
クラスメソッドで代々PMとして携わってきて、現在データインテグレーション部（DI部）でマネージャーを務める田子さんにインタビューしてきました！
「技術は好きだけど、次のステップアップとしてマネジメントも必要かも？」と思い始めたそこのあなた！！ 刺さることがあると思うので、どうぞ、最後までお読みください。
インタビュースタート
ー所属とお名前、または通り名をお願いします。
データインテグレーション部プロジェクトマネージャーの田子です。
一部でTGと呼ばれています。名付け親はもういません。
ーΣ(´⊥｀lll)ん!!
ーええと、では、TGがマネージャーになるまでの簡単な経緯を教えてください。
最初からその枠で入りました（笑）
現在は2社目で、入社9年目ですね。
ーえ〜、長いですね。そもそもなぜクラスメソッドに入社されたんですか？
当時（2008年頃）は、Flexやろうぜ！RIA（Rich Internet Application）/ リッチクライアントだぜ！って時代だったので、僕もRIAやりたいなと思ったんですよ。で、@ITとかで調べてたら、クラスメソッドの福田さんが記事を書いてて、面白そうなことやってるなぁと思って、選びました。
参考記事：EclipseベースIDEとTomcatで始めるFlex＋Java開発 (3/3) など
ー現在所属されているDI部のプロジェクトは、どんなものが多いんですか？
AWS上で、ビッグデータの分析基盤を作って提供するのがメインの仕事です。データはあるので、分析をしたいんだけど、そのための環境がないお客さんのために、入れ物と、そこにデータを入れるための仕組みを提供しています。
既存のシステムからファイルが出て来て、Amazon Redshift に入れるとかが多いので、いわゆるETL処理のバッチを作ったりとか。Tableau（タブロー）入れてBIの環境整えたりとかですね。
基本の形は一緒なんですけど、どういう仕組みでどういう風に連携させるかはお客さんによって違ってくるので。
今のところ、データの解析部分はお客さんですが、今後はそこもやっていこうかなという話もあります。今は、環境が整っていないので、基盤提供までですが・・・。
ー気を遣うところが多そうですね
セキュリティは気をつけてますね。やっぱりデータを預かるところもあるので。ただ、AWSで作っておけば、セキュリティをかけることも容易にできるので、まぁ、作りやすい環境ではあるかなと思います。
ーでは次に、プロジェクトマネージャーの主な仕事内容を教えてください。
案件をうまく進めて、成功させることですね。成功というのは、お客さんに満足していただけるものを出して、かつ、利益を出すこと。
具体的には、お客さんとの折衝とか、合意形成・・・あとは、作業や要員の計画を作ったりします。
ー要員計画！！この会社も作ってたんですね（爆）
作りますよ（笑）
じゃないと、人を当ててもらえないので（笑）
要員計画を持って、部長に、こういう人欲しいから、アサインしてよって交渉します。
プリサー(モバイルアプリサービス事業部の社内略称)もDI(データインテグレーション部の社内略称)も、まずは案件ありきで、そこに人を当てはめていくような形ですね。
ー普段、技術とマネジメントの割合はどれぐらいですか？
8:2 か 9:1 ぐらいで、ほぼマネジメントですね。
技術は、設計に関わることが多いんですけど、使いたいサービスとか、ちょっと自分で触ってみたりといった技術調査はします。
ー技術職と比べていちばんの違いはなんですか？
やっぱりフロントに立つので、いろんな人と接する機会が多いかなと思います。特にDI部のメンバーだと、打ち合わせ出ることもありますけど、そんなに直接やり取りすることもないので。お客さんにせよパートナーにせよ、いろんな人と接する機会が多いなぁと思います。
違いといっても、やっている仕事の割合が違うだけで、そんなに変わらないのかなぁと。
ープロジェクトのメンバー数はどれくらいですか？
最近は、メンバーが1人か2人くらいの小さいプロジェクトをいくつか担当するっていうことが多いです。
割と大きめの案件を担当することが多かったので、10数人のメンバーで、半年から1年ぐらいってのもやってたりしました。最近は、長くても3ヶ月から半年ぐらいじゃないですかね。去年は例外的に、1年ちょっとやってた案件もありましたが。
ープロジェクト管理はどうやってるんですか？
基本、Backlogを軸にして、他のツール使ったり、対面で話をしたりして進めています。
お客さんによっては、Redmineでやってくれと言われたりもしますが・・・。
最初の計画を立てるときだけ、MS Projectを使うこともあります。小規模の案件だと、trelloとか、githubのissueで管理してます。
ー勤務スタイルを教えてください。
僕自身は、出社することが多いです。お客さんの環境によっては、IPアドレス制限かかってたり、あとは、パートナーさんに常駐してもらってるので。でもいちばんは、自宅に仕事できる環境を整えていないので集中しにくいってことですかね。
今は、特に出社しないといけない理由はないんですが、社内のほうが環境整っているので来ちゃってる感じです。
なので、基本10割出社ですね。メンバーとのやり取りもチャットで行えるので。最初に予定も立ててますし、Backlogで課題割り振ってるので、基本的にはそれで進むんですよ。特にサボる人もいないし、リモートでやってるメンバに対しても特別な配慮もしてないです。その日の成果物が出てればいいんで。
ーTGから見て、クラスメソッドの技術者の印象を教えてください。
みなさん、スキルも高いし、成長意欲も高いんじゃないかなと思います。
ー面接では何を見てますか？
どういう風に仕事に取り組むか、とか、過去にどういう問題があって、どういう風に解決したか？とか、自分で問題解決をできる人に来て欲しいなぁとは思います。もちろん、自分で抱え込むのではなくて、いろんな人の助けをもらいながら、解決ができる人ですね。
そういっても、たまに抱え込む時もあるので、そこをフォローするのもマネージャーの仕事かなとは思っています。
ー前の職場との違いはありますか？
そんなに変わらないですかね。
前職が10年前なので、環境も変わってきてますよね。10年前だとようやくtracとか使ってチケットで管理しましょうよ、という話が出て来た頃なので。環境の違いはあれど、それほど変わらないのかなと。
一番大きいのは、チャットでのコミュニケーションが多くなったことですかね。昔、僕はチャットあんまり好きじゃなかったんですよ。隣にいるなら喋れよって思うんですけど。今ではそんなに違和感がなくなって。まぁ、隣の人とは喋りますけどね（笑）
ーずっとSIerでPMやってる人でも対応できますか？
技術は知りません、管理はします！って人は厳しいと思います。たぶん、メンバーともうまくやれないと思いますよ。
お客さんからも技術的なことを聞かれることが多いので、ある程度は答えられないと、信用されないんですよ。 やっぱり、クラスメソッドは技術の会社ってところもあるので、自分でも技術的な知識やスキルは持ってないと、マネージャーは難しいと思います。
ーマネージャー職の面白いところはなんですか？
案件うまくいって、リリースして、安定して動いているのを見ると、よかったなぁと思いますが……。
マネージャーだから面白いということは特にないですね。技術職と何が違うのといっても、割合ぐらいしか違わないと思うので。マネージメントが面白くてやってる人は、たぶんいないんじゃないですかね（笑）
マネージャーやっていても、自分で手を動かす人はいるし、ちょっとした構築や修正も、手が空いてたらやりますし。設計とかコードに口出したりしますしね。コードレビューもなるべくやりたいと思ってやっていますし。
クラスメソッドのマネージャーやってるといいのは、一次請けなので、お客さんと直接話せるんですね。だから、無駄な層が入らずにできるので、そこは面白いと思います。意図がわからず、いったことやれっていうだけよりは、やりがいはあると思いますよ。
あとは、お客さんに提案した内容が、うまくマッチして受けたときは、気持ちがいいですね！
ーマネージャー職のつらいところはなんですか？
つらいのは・・・、ぼく、計画あんまり得意じゃないので。案件の立ち上がりはいつも辛いです。といえ、やりきりますけどね（笑）
ーたごさんは、PMに向いていると思いますか？
たぶん向いてるんじゃないかなと。
ーどんな人がPMに向いてると思いますか？
僕は人の話を聞くのが好きなので、人の話を聞きながら、理解できるかはわかんないですけど、うまいことまとめていくことができるのかなと思っています。
その人の背景を考えつつ、どういうのを求めているのかなということは考えますね。
まぁ、過去に自分自身も思い込みで判断して痛い目を見てきているので、予断は許さず、必要なことは確認しつつ進めるようにしています。
ーまた技術者に戻りたいと思いますか？
たまにコード書きたくなりますけど、今後もPMとしてやっていくんじゃないかなと。
ーそれは、技術者としてもプロジェクトに関われるからですか？
そうですね、それはありますね。
管理しかやれないとしたら、ヤダっていうと思うんですけど（笑）
ークラスメソッドの開発は、アジャイルで進められているんですか？
開発を、大人数でお客さんと絡みながらやる場合は、どの手法でやりたいかより、どの手法が適するかどうかが大事だと思うんですよ。アジャイルのほうが適している場合もあるだろうし、ウォーターフォールが適している場合もある。そこは仕事に合っているほうを使えばいいと。なので、今関わっているプロジェクトでも、半々ですね。割と最初に計画を立てますし、あとは、まぁ、状況とかお客さんの意向とか聞きながら、組み替えたりしますかね。
基本は計画に添いつつ、あとは臨機応変でって感じです。
ーカンバン張り出したりしないんですね。
うちはしないですね。プリサーはしてたりしますけど。
まぁ、カンバン張り出す代わりにtrello使ったり、ツール使ったりしてやってる感じですね。
ーチーム内で流行っていることはありますか？
DI部の開発言語はJavaがメインだったんですけど、これからは、Pythonで行こうという話をしていますね。社内勉強会もやっていて、Hadoopとかもやってますけど・・・。
あと、僕はやってないですけど、一部の人はFEヒーローズで遊んでるそうです。
ー今注目している技術は？
やっぱりAWSのサービスは気になりますよね。あと、まだ出てないですけど、グルー（AWS Glue）とか。早く出て欲しいなぁと思いますし。使い道が本当にあるかどうかは、検証が必要になりますけど。
ーでは、改めて、クラスメソッドのマネージャーってどういう人が向いてると思いますか？
クラスメソッドのマネージャーってそんなにマネージャーマネージャーしてないと思うんだよなぁ。
実際に技術に触りながら、次のステップとしてマネジメントも考えてる人？いきなり、技術できなくなるわけでなくて、両方やりながら、どっちにするか考えることできますよ、みたいな。うちにいる以上は、マネジメントだけやってればいいってのがないんですよ。部長になったとしても、それは変わらなくて。
プロジェクトマネージャーとしてプロジェクトに関わると、いちメンバーとして入るよりは、割と広い範囲を見れるってのはあるので、いろんなことに関わりたいって人にはいいかもしれないです。個別最適というか、フェーズによって分けたりするので、メンバーのスキルを見ながら。メンバー全員が全体を把握するのが望ましいっちゃあ望ましいんですけど、小さい案件ならまだしも、大きい案件だと難しくなってくるので。メンバーとして入るよりもマネージャーとして入った方が、全体を見渡す関係上、色々理解しないといけない部分もあるけど、逆にそういったことがわかって、全体像が把握できる点は、強いと思う。
メンバーがその辺知らなくてもいいよっていうわけではないんですけどね。ただ、得手・不得手とか、負荷の関係もあると思うので、メンバーがそのメンバーの力を発揮できる土壌を作ってあげるのが、マネージャーの大事な仕事のひとつかなぁと思っていて。
やっぱり、雑用も多いですよ・・・。
いかがでしたでしょうか？
クラスメソッドのマネージャーは、どの部も「技術も好き！」じゃないと務まらないようですが、こんな人が向いているのではないでしょうか？
ひとことで表すならば、
技術一本でいくか、マネジメントもできるようになるか、 迷ってるなら・・・クラスメソッドに来れば叶うかもよ！
です。
一度、マネージメントに特化してしまうと、技術職に戻れるのか不安に思う方は多いと思うのです。 その点、クラスメソッドは、技術からは離れられないし、部署間移動の希望も通りやすいのでオススメですよっ
まぁ、まずは 2/22に開催するMEETUP に来るといいですよ |дﾟ)ﾁﾗｯ
まとめ：クラスメソッドのPMにはこんなかたが向いてます
- お客さんと直接交渉してプロジェクトに関わりたい
- マネジメントとリモートを両立したい
- 技術職に戻る可能性も残しながら働きたい
- マネージャーっぽくなくマネージャーしたい
さて、いくつか当てはまるかた！2/22にMEETUPを行うので、ぜひ来てみてくださいネ。当日は、TGはもちろん、他のマネージャーも勢揃い！すぐに役立つかもしれないtipsの紹介はもちろん、ビール飲みながら直接話せるので、不安や疑問は全てぶつけてください。
お申し込みは、下の画像をクリック！
会場でお待ちしておりまーす(ง `ω´)ง
4
