「力を貸して」と言えることが重要──開発マネージャー陣、本音のリーダーシップ論

Contents

• マネージャーまでの道に、王道はない。それぞれが選んだチャンスの掴み方
• すべてはメンバーのために。管掌領域と関わり方
• 「力を貸して」と言えるか？「判断軸」は統一できているか？一人ひとりの個性
• 意外に激論？各マネージャーはここを見る。人事評価の軸の考え方

「カオナビ」の開発はプロダクト本部で行われており、アプリケーションを開発する“サービス開発部”と、インフラ基盤を開発する“SRE部”の2つの部署から成り立っています。

“サービス開発部”は5つのグループに、“SRE部”は3つのグループに分かれており、各グループでミッション達成に向けて切磋琢磨しながら技術を磨き、プロダクトを洗練させています。

今回は、そんな各グループを率いるマネージャー6人が集結し、マネジメントをする上で大事にしていることや悩みなどを赤裸々に語り合いました。個性溢れるリーダーたちの想いを、前編と後編に分けてお届けします。

Interviewee

プロダクト本部サービス開発部　Kaizenグループ　マネージャー
服部 大輔
新卒で証券システムの運用保守を経験後、シングルサインオンをサービス提供している会社に転職し、開発から運用保守まで幅広く業務に従事する。2019年3月にカオナビに入社。既存システムの改善案件を主に行い、マネージャーも担当。

プロダクト本部SRE部　オペレーショングループ　マネージャー
棚橋 敬
新卒でEDIパッケージの開発や保守、運用を経験後、2019年1月にカオナビに入社。現在はカオナビの運用保守を行い、マネージャーも担当。

プロダクト本部SRE部　productivityグループ　マネージャー
石川 善幸
モバイルコンテンツやスマホアプリ（ゲーム）業界でサーバーサイドエンジニア・ゲームプランナーとして開発に従事。 2018年3月にカオナビに入社し、リリース作業・顧客対応など、運用保守業務を担当。現在はプロダクト本部の生産性向上支援を担いつつ、マネージャーとして活動。

プロダクト本部サービス開発部　Strategyグループ　マネージャー
尾張部 佑亮
新卒で独立系SIerに入社後、3年ほどSEとして働く。放送作家になりたくて脱サラするが上手くいかず、ソーシャルゲーム会社に転職する。その後、2019年にサーバサイドエンジニアとしてカオナビに入社。プロジェクトのエンジニアリーダー的なポジションを経て、マネージャーに就任。

プロダクト本部サービス開発部　Platformグループ兼Data Frontierグループ　マネージャー
大倉 悠輝
大手メディア系サイトのシステム開発・PjMを担当。その後、スタートアップ企業で広告・開発・運用までサービス運営の全行程を担当。動画配信サービスの開発でプロダクトマネジメントを知り、コミュニティ活動にも従事。2019年3月にカオナビに入社し、システム連携関連の案件を主に担当。Platformグループに加えData Frontierグループのマネージャーも兼任。

プロダクト本部SRE部　インフラグループ　マネージャー
大久保 智之
新卒入社先のSES（システム・エンジニアリング・サービス）事業を提供する企業や、MSP（マネジメント・サービス・プロバイダ）事業の企業で幅広くインフラ開発・運用を経験。2018年9月にカオナビに入社し、インフラ基盤の運用や保守、整備を一貫して担い、マネージャーに就任。

マネージャーまでの道に、王道はない。それぞれが選んだチャンスの掴み方

──皆さん、キャリアのスタートはエンジニアですが、もともとマネジメント職には興味はあったのですか？

服部：
私は前職でマネージャーを経験していましたが、現場での業務をやっていきたかったので、むしろ「マネージャーはやりたくない」と思ってここに転職をしてきたんです（一同：笑）。
けれど、働いている中で徐々に、マネジメントに対する意識も変わっていき、今はチームとして成果を出す上でも、自分のマネジメント経験を活かしていきたいと思うようになりました。皆さんは、どうでしたか？

大倉：
新卒で入った企業で、わりと早い段階からプロジェクトマネージャーを経験し、前職でもマネージャーを務めていました。意識していたわけではありませんが、マネージャー寄りの仕事をすることが多かったですね。
けれど、「現場の人たちと親しくならないと、マネージャーとしては認められない」という自覚があったので、当社に来てすぐはマネージャーになるつもりはありませんでした。現場を2年ほど経験してから、マネージャー業務を引き受けました。

棚橋：
私も初めから「マネージャーをやりたい」と思って転職してきたわけではないですね（笑）。前職では、プロジェクトリーダーやプロジェクトマネージャーを経験しましたが、組織マネジメントの経験はなかったので、チャンスがあればやってみようと手を挙げました。

──なるほど。初めから「マネージャー職にしか興味がない！」という方には、転職先として当社を選ぶのは少し違うのかもしれませんね（笑）。

尾張部：
そうだと思います。私は、前職で現場のチームリーダーを経験しましたが、組織のマネージャーをやるのは初めてです。会社組織で管理職という経験ができるのであれば、いつかチャレンジしてみたいと思っていたので、会社が求める状況と自分の希望がうまくマッチして今に至っています。

石川：
それで言えば、私はマネージャーのキャリアもスペシャリストのキャリアも、どちらも興味を持っていました。けれど経験を積むうちに、プロジェクトの進捗を管理したり生産性の改善に取り組む方が自分には向いていると気が付きました。
管理職であれば、自分の得意なことを活かして会社に貢献できますし、きちんと評価してもらえる。そう思い、マネージャーを希望しました。

大久保：
それでいうと、私は今でもエンジニアのつもりなんですが……（笑）。カオナビにはプレイヤーとして転職して、1年半後にマネージャーになりました。前職でもマネージャーの経験はありましたが、コロナ禍でフルリモートのなかマネジメントをするのは初めてなので、違った難しさを感じています。

すべてはメンバーのために。管掌領域と関わり方

──マネージャーになられた背景は、三者三様というか、六者六様ですね。せっかくですので、みなさんそれぞれがどのようなお仕事に関してマネジメントをしているのか、具体的に聞かせていただけますか？

尾張部：
Strategyグループで管掌している領域は、「カオナビ」の機能のなかでも、人事業務の効率化や経営の意思決定支援をする機能の開発です。チーム内で私はメンバーの悩みや課題に対して、相談を受けてサポートしていくことが多いです。
相談相手や内容によって解決案を提示するか、答えを引き出すように問いを投げかけるかというアプローチは変えるようにしています。

大倉：
Platformグループで担当しているところは、サーバーサイドの開発言語であるPHPや、その上で動くフレームワークLaravel（ララベル）のバージョンアップ、ログインや検索、メール、外部連携のためのAPIといった共通機能の保守や改修ですね。
私はディレクターとしての経験が長く、エンジニアとしてのバックグラウンドはあまり持っていません。でも、プロダクトを支えるこういった基礎的な技術には以前から興味があったので、面白さを感じています。
もう一つ担当しているData Frontierグループは、主にワークフローの機能を担当しているチームが一つある組織です。クロスセル商材である単独プロダクトに近い商材を扱っており、ほぼ組織運営＝チーム運営になっているので、プロダクトマネージャーに一任しています。

服部：
Kaizenグループでは顧客側の改善業務に関わる機能を担当しています。主に「カオナビ」のデータを収集する機能と、収集したデータを可視化したり、分析に使える機能になりますね。
実は2年ほど前まで、機能に関わらず既存機能の改修をすべて1つのグループで担当していました。組織体制が変わり、現在は各グループごとで担当する機能が明確になっています。その結果、より自分たちが携わる機能に注力しやすくなったと感じています。
それと、Employeeグループについても、私から紹介させていただきますね。このグループはいま本部長の草亭さんがマネージャーを兼務しているのですが、業務内容としてはその名の通り、一般従業員向け機能の開発を担当しています。HRテックのプロダクトは人事担当者や経営者をターゲットユーザーにしている場合が多いのですが、カオナビはそうした方々はもちろん、一般従業員の方にとっての価値向上にも注力しているので、このグループの存在は重要なんです。

──ここまでの3人はサービス開発部ですね。続いて、SRE部の3人からもお願いします。

棚橋：
オペレーショングループでは、主にリリース管理、社内のセールスやサポートデスクからの問い合わせに関する対応、本番環境における作業や運用、さらに業務の効率化や自動化などを中心に担当しています。2022年1月より、今はProductivityグループのマネージャーになっている石川さんの後を引き継いでマネージャーに就任しました。

大久保：
私が所属するインフラグループでは、カオナビに対するサイトの信頼性の維持・品質向上を継続して行っていく役割を担っています。また新機能の開発時には、サービス開発部のメンバーと連携して、ソリューション提供していく形で機能開発を行うこともあります。
他のグループと比べて、インフラグループは比較的年齢層が高いこともあり、豊富な経験やさまざまなバックグラウンドを持っているメンバーがいるので、それぞれの強みを活かせるような組織運営を心がけています。

石川：
Productivityグループでは、プロダクト本部における生産性向上の支援をおこないます。具体的には、E2Eテストによるバグの事前検知、膨大なデータを使って負荷をかけて処理能力を検証するボリュームテスト用のデータセットの策定、さらにボリュームテストデータに対する表示速度の検証など。それらを通じて、どれくらい業務が改善されたかを管理し、生産性向上につなげていきます。
私自身が昔から「同じ作業はしたくない。いかに効率化できるか」と考えるタイプなので、その経験が業務にも活かされていますね。

「力を貸して」と言えるか？「判断軸」は統一できているか？一人ひとりの個性

──ありがとうございます。皆さん、チームのマネジメントに日々取り組まれるなかで、意識していることや大事にしていることは何ですか。

大久保：
インフラグループとしては、「プロダクトがいつでも安定して使える状態を作ること」が至上命題になります。「カオナビ」を常に使える状態にしておくこと以上に、重要なことはありません。
マネージャーと言っても、チーム内での役割に違いがあるだけで、メンバーとの関係は対等だと思っています。ですから、メンバーの話にはしっかり耳を傾けることを大事にしています。他にも苦手なことや、うまくいかないことは、強がらず「わからない」と素直に伝えたり、私自身が忙しくて手が回らない時は「力を貸してほしい」って正直に言うようにしています。

大倉：
「力を貸してほしい」って自分から言えるのは、大事ですよね。

大久保：
そうですね。マネージャーがそのように自分の弱みを見せることで、結果的にメンバーも周りに助けを求めやすくなるのではないか、という考えもあります。

石川：
私がマネジメントをする上で心がけていることは2つです。1つは、KPIを意識すること。特にProductivityグループは、生産性向上がミッションのため、その指標は単に「頑張りました」というレイヤーではないんですね。「作業時間が何分短縮された」「バグがいくつ減った」など、数字を出さなければ、それに対する評価がされません。逆に言えば、必ず数字で表現できるので、それを怠らないようにしたいというわけです。
ですから、メンバーが新たな業務改善の提案をする際は、「何がどれくらいよくなるか」を、ある程度イメージを持って提案するように伝えています。
2つ目は、業務の配分を原則、運用に50%・改善に50%で取り組むことです。理由としては、運用に全力を注いでしまうと、時間配分が足りず改善が一時しのぎになり、逆に生産性を落とすことになってしまうからです。それを防ぐために、改善のための時間も確保しています。

棚橋：
オペレーショングループでは、本番環境に対する作業が安全かどうかを常に意識することが重要だと感じています。お客様にサービスや機能をリリースする際、オペレーショングループが最後の門番役を担っているため、万が一、ここでミスが起きてしまうとお客様に直接影響が出てしまうからです。作業を効率化したり、仕組み化をすることで、ミスがそもそも起こらないようにしています。
また、私個人として意識しないといけないことは、メンバーに対してタスクをもっと積極的に振ることです。プレイヤーの時期が長かったので、今でも自分でタスクを取りにいってしまうことがしばしばありますね（笑）。

大久保：
私にも同じ経験があるのでわかります。最近ようやくメンバーにタスクを任せられるようになってきました。

──その脱却のカギは、ずばり何でしょう。

大久保：
自分が手を動かさずに、同じ結果を出すにはどうすればいいか、とにかく考えることです。そして、絶対に自分では「やらない」と決めて、意識してメンバーに任せる。そうしないと、私も棚橋さんと同じく、自分でタスクを取りに行ってしまいますから。
とはいえ、最近も、「ダメです。マネージャーは、そんなことやらないでください」って言われたばかりなんですが（笑）。

棚橋：
でも、それを言ってもらえるというのは、いいチームワークですね。たとえ自分でタスクを見つけても、それをメンバーに振ること。自分は「やらない」という意思を貫くことが大事だということですね。

──マネジメント論が盛り上がってきましたね、大倉さん、尾張部さん、服部さんは、どのように考えて取り組んでいますか？

大倉：
私が毎回組織を作る上で、メンバーに伝えていることは2つあります。1つは、ディズニー・フィロソフィー。ディズニーテーマパークで大事にされている行動規範で、Safety（安全）、Courtesy（礼儀正しさ、目線を合わせる）、Show（ショー）、Efficiency（効率）という4つの行動基準を設けています。それぞれの頭文字をとって“SCSE”と呼んでいて、これらは優先順位の高い順に並んでいます。メンバー一人ひとりが、この考え方に沿って主体的に考えて動くことが大事だと伝えています。
2つ目は、ユーザー、デベロッパー（開発者）、ビジネスの3者から見たバランスが取れているかどうか。何かアイデアを出した時に、いわば「三方良し」の状態になっていなければ、良いプロダクトなど絶対にできないと思っているんです。
そして、この2つの軸があれば、エンジニア同士、2人以上で話し合って決めたことは、マネージャーに許可を取らなくても実行OKというプロダクト本部の方針のもと動いてもらっています。

尾張部：
大倉さんが今おっしゃった“判断軸”の話ともつながりますが、私は“仮説思考”を意識するようにメンバーには伝えています。
話し合いの場面においては、それぞれの立場や見解で意見や提案を述べることになります。「判断軸」が参加者で揃っていないと、いつまで経っても結論を導き出すことができなくなってしまいます。限られた時間で物事を進めていくためには、判断材料となる「決定条件を洗い出していこう」という話をよくしています。
その判断軸を「仮説」から生み出さなければいけないことが、プロダクト開発においては多いと思っています。

服部：
私はメンバー個人にフォーカスをしたマネジメントを意識しています。
例えば、人事評価をする際、メンバーの中には、「達成できなかったらどうしよう」という不安から、目標設定を低く書いてしまったり、すぐに達成できる目標を立ててしまったりするケースがあるんです。そのため、「目標を達成できなくても、その理由をアピールできればマイナスな評価にはならないよ」と声をかけて、安心感を持ってもらえるように意識していますね。

大倉：
評価と目標って、やっぱり難しいですよね。

──画一的なやり方ではなく、チーム内でのカルチャーや個に合ったやり方で評価をしているというマネージャーの皆さん。後編の記事では、それぞれチーム内での評価のやり方についてもう少し深掘りしていきます。

▼その他インタビューをご覧になりたい方はこちら
kaonavi vivivi（カオナビの「人」と「組織」が見えるメディア）