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

私は前職でマネージャーを経験していましたが、現場での業務をやっていきたかったので、むしろ「マネージャーはやりたくない」と思ってここに転職をしてきたんです（一同：笑）。

けれど、働いている中で徐々に、マネジメントに対する意識も変わっていき、今はチームとして成果を出す上でも、自分のマネジメント経験を活かしていきたいと思うようになりました。皆さんは、どうでしたか？

新卒で入った企業で、わりと早い段階からプロジェクトマネージャーを経験し、前職でもマネージャーを務めていました。意識していたわけではありませんが、マネージャー寄りの仕事をすることが多かったですね。

けれど、「現場の人たちと親しくならないと、マネージャーとしては認められない」という自覚があったので、当社に来てすぐはマネージャーになるつもりはありませんでした。現場を2年ほど経験してから、マネージャー業務を引き受けました。

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

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

それで言えば、私はマネージャーのキャリアもスペシャリストのキャリアも、どちらも興味を持っていました。けれど経験を積むうちに、プロジェクトの進捗を管理したり生産性の改善に取り組む方が自分には向いていると気が付きました。

管理職であれば、自分の得意なことを活かして会社に貢献できますし、きちんと評価してもらえる。そう思い、マネージャーを希望しました。

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

Strategyグループで管掌している領域は、「カオナビ」の機能のなかでも、人事業務の効率化や経営の意思決定支援をする機能の開発です。チーム内で私はメンバーの悩みや課題に対して、相談を受けてサポートしていくことが多いです。

相談相手や内容によって解決案を提示するか、答えを引き出すように問いを投げかけるかというアプローチは変えるようにしています。

Platformグループで担当しているところは、サーバーサイドの開発言語であるPHPや、その上で動くフレームワークLaravel（ララベル）のバージョンアップ、ログインや検索、メール、外部連携のためのAPIといった共通機能の保守や改修ですね。

私はディレクターとしての経験が長く、エンジニアとしてのバックグラウンドはあまり持っていません。でも、プロダクトを支えるこういった基礎的な技術には以前から興味があったので、面白さを感じています。

もう一つ担当しているData Frontierグループは、主にワークフローの機能を担当しているチームが一つある組織です。クロスセル商材である単独プロダクトに近い商材を扱っており、ほぼ組織運営＝チーム運営になっているので、プロダクトマネージャーに一任しています。

Kaizenグループでは顧客側の改善業務に関わる機能を担当しています。主に「カオナビ」のデータを収集する機能と、収集したデータを可視化したり、分析に使える機能になりますね。

実は2年ほど前まで、機能に関わらず既存機能の改修をすべて1つのグループで担当していました。組織体制が変わり、現在は各グループごとで担当する機能が明確になっています。その結果、より自分たちが携わる機能に注力しやすくなったと感じています。

それと、Employeeグループについても、私から紹介させていただきますね。このグループはいま本部長の草亭さんがマネージャーを兼務しているのですが、業務内容としてはその名の通り、一般従業員向け機能の開発を担当しています。HRテックのプロダクトは人事担当者や経営者をターゲットユーザーにしている場合が多いのですが、カオナビはそうした方々はもちろん、一般従業員の方にとっての価値向上にも注力しているので、このグループの存在は重要なんです。

オペレーショングループでは、主にリリース管理、社内のセールスやサポートデスクからの問い合わせに関する対応、本番環境における作業や運用、さらに業務の効率化や自動化などを中心に担当しています。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というプロダクト本部の方針のもと動いてもらっています。

大倉さんが今おっしゃった“判断軸”の話ともつながりますが、私は“仮説思考”を意識するようにメンバーには伝えています。

話し合いの場面においては、それぞれの立場や見解で意見や提案を述べることになります。「判断軸」が参加者で揃っていないと、いつまで経っても結論を導き出すことができなくなってしまいます。限られた時間で物事を進めていくためには、判断材料となる「決定条件を洗い出していこう」という話をよくしています。

その判断軸を「仮説」から生み出さなければいけないことが、プロダクト開発においては多いと思っています。

私はメンバー個人にフォーカスをしたマネジメントを意識しています。

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

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