2023年7月にプロダクトデベロップメント本部長に就任した尾張部 佑亮氏。約4年半在籍するなかで、カオナビが拡大し、大きな組織となっていく変遷とともに辿っていきました。
カオナビサービスの企画～保守を担う、100人を超える開発組織のトップに立ったなかで、どのような課題があり、どのような組織作りをしていくのか──就任当時を振り返りながら、今後の展望についてお伺いしました。
迅速な経営判断のため、現場の声をより正確に伝えるべく本部長に就任
カオナビに入社したきっかけを教えてください。
カオナビに約4年半ほど在籍しているのですが、入社当時はタレントマネジメントの考えも今ほど浸透しておらず、エンジニア組織も小規模でした。ちょうど自分のキャリアを考えたときに、エンジニアだけでも数百人いるような大きな組織ではないところで、リーダーやマネジメントの経験を積んでおきたいと考えていたんです。当時のカオナビの組織規模は自分の理想にフィットするなと思い、入社を決めました。
プロダクトデベロップメント本部長
尾張部 佑亮新卒で独立系SIerに入社後、3年ほどSEとして働く。放送作家になりたくて脱サラするが上手くいかず、ソーシャルゲーム会社に転職する。その後、2019年にサーバーサイドエンジニアとしてカオナビに入社。プロジェクトのエンジニアリーダーやマネジメントを経て、2023年7月よりプロダクトデベロップメント本部長を務める。
昨年7月にプロダクトデベロップメント本部長に就任されました。就任の背景について教えてください。
2022年の終わりごろから「カオナビ」の新しい機能を次々と作り、製品としての魅力を高め、新規で契約してくれる企業を増やしていこうという方針で動いてきました。そのために採用を増やし、開発ラインを多く作ることで、たくさんの新機能をリリースしてきました。
そのような中で、プロダクトデベロップメント本部長に求められる資質も、変わっていったんです。よりスピーディーに経営会議で意思決定ができるように、経営レイヤーや他部署の責任者に向けて、本部長がプロダクト開発に潜むリスクの説明やリリース日付の変更理由、不具合の内容などを、よりわかりやすく説明できることが重要視されるようになりました。
そこで、マネジメント経験よりもエンジニアとしての開発の経験を重視して私に本部長を任せてもらえることになったと思っています。
事業戦略に則った開発を優先させたことで生じた課題
本部長に求められるものが変わっていったからこその抜擢だったのですね。就任にあたり、課題もあったと思います。
はい、大きく分けて3つの課題があったと感じています。
まず1点目は、「リリース後の改善サイクルが築きにくい」ことです。先程もお話したように、ここ1年は事業方針である「製品としての新しい魅力を増やし、カオナビを新規で契約してくれる企業を増やしていく」という開発を強化していました。
そのため、お客様には影響がない開発の裏側の部分、例えばコードが整っていない、拡張がしにくい状態で新規リリースを優先していきました。加えて、効率的に進めるために、「開発」と「保守・運用」のチームを意図的に分けていました。ただプロダクトが成長していくなかで、自分たちが作っていない機能を保守・運用するのは限界があるという声や、リリース後の改善サイクルが築きにくくなっている状態がありました。
2点目は、「ビジネスサイドとの意識のズレ」です。新しい機能を早くリリースすることを優先すると、「既存のユーザー視点が足りないままに開発が進んでいるのではないか」という指摘を他部署からもらうことが多くありました。一方で、開発部門である私たちからすると、事業方針に則って開発をして成果を出してきたという思いもあります。ここで意識にズレが生じてきてしまいました。
最後は、「開発組織が拡大して、共通認識を持ちにくくなっている」ことですね。私が入社したころは小規模だった組織が、今やいくつもの開発チームやラインに分かれ、業務委託の方も含めると100人以上ものメンバーがいます。
以前は、大事なことは全員がいる場で一度伝えるだけで済んでおり、さらにコアメンバーだけで話を進めていれば良かった。これからは大事な情報は何回も発信し、確実に組織全員に届けられるようにしていかなければいけないと思っています。
課題解決のために、チームトポロジーの考えを取り入れた体制へ
それらの課題の解決に向けて、どのような取り組みをされているのでしょうか。
これからの事業戦略のフェーズとして、既存の機能をより成長させることも必要になってきています。だからこそ、1点目の課題である改善サイクルを築きにくい体制は早急に整えていきたい。そのために、開発と保守・運用を一気通貫で行う組織作りを進めていっています。
具体的には、本部会で「チームトポロジーの概念をいれていきたい」という話をしました。「チームトポロジー（Team Topologies）」は組織設計モデルの1つであり、顧客への価値提供のためのフローを重視した組織構造について書かれている書籍です。
その中で特に意識しているのは、チームトポロジーに記されている4つのチームタイプを実現することです。以前の組織からストリームアラインドチームを意識した体制にはなってきていたので、チームの強化に繋がるような施策やそれらを支えるチームを組成をしてより安定していて速度のあるフローを実現することが目標です。
これにより、組織の拡大とともに曖昧になっていたチームの役割というのが、より明確化されることでチーム同士が効率的に仕事が進められるようになるのではないかと思っています。
他の2つの課題は、組織でのコミュニケーション課題かと思います。これらに対して、どのようなことを考えられていますか？
2点目の「ビジネスサイドとの意識のズレ」は、他部署との議論する場を積極的に増やし、QCDS*の共通認識を持つことで解消しつつ、「なぜ自分たちはこのような機能を開発しているのか？」「どのような価値をユーザーに届けていきたいのか？」ということを開発組織が主導して進められるように取り組んでいます。
3点目の開発組織内での共通認識を持つことは、大きくなにか変えるのではなく、足元から着実に実行していっています。例えば、私がメインでパーソナリティを務める社内ラジオを行いました。ちょうど全社で取り組んでいた1年がかりの大きなプロジェクトが一段落したので、経営層が全社向けに結果報告を行っていました。それを受けてラジオの1回目は自分もそのプロジェクトに関して深掘りした内容を発信したんです。
今まで経営層から全社向けに説明があったからと終わらせていたものを、開発の現場メンバー向けに本部長の言葉で伝えていくことで理解度を深めたうえで仕事に臨んでもらいたいという狙いです。
*品質（Quality）、コスト（Cost）、納期（Delivery）、サービス（Service）または安全性（Safety）の頭文字を取ったもの
組織視点をもち、主体的に他者を巻き込める人材を求める
これら以外にも尾張部さんが変えていったものはありますか？
非同期コミュニケーションを増やして自分の作業できる時間を増やす取り組みを行いました。いきなりメンバーのMTGをなくすのではなく、「自分としては定例MTGの時間を減らしたいと思っている」と発信し、棚卸ししました。結果的に、40人近いメンバーが参加していた週1時間の開発進捗確認のための定例MTGをなくし、非同期でできる進捗レポートの仕組みに切り替えました。
具体的には進捗管理シートを整備して、週に一度そのシートをアップデートできる仕組みを整えました。それを確認し、もし心配な部分があれば個別にそのチームのリーダーに確認すればいいだけなので、シンプルで効率的になりましたね。
これからどのようなことを目指されていくのか教えてください。
開発組織をより良くするために、現実と理想のギャップを埋めていきたいですし、それがしばらくの自分のミッションになりそうです。
これまで、30人ぐらいの開発組織のやり方やルールをずっと引きずってる印象がありました。今の規模とは合っていないのに、ルールを見直す機会を持てておらず、無理やり当てはめてやっている部分もあったんです。だからこそ、以下の2点を本部長としてやっていきたいと考えています。
①成長性と持続性のある組織づくり（社内への認知を高める活動も含む）
②各領域の課題に取り組むチームの任命と上記に伴う責任＆権限移譲の仕組みづくり
理想は具体的に整理しきれていませんが、会社をイチから作る、自分が経営するような意識を持って、現状の課題と向き合いながら組織作りを行っていきたいと思っています。
最後に、カオナビで働くことを検討している方へメッセージをお願いします。
エンジニア経験はもちろん大切です。ただ組織の規模感も拡大しているので、マネジメント経験をお持ちの方が入ってもらえると助かります。組織単位での課題も多く、1つの施策で複数の課題を解決していくようにしないと、理想の組織にするために時間がかかりすぎてしまいます。
そうした課題解決に主体的に取り組んでいける仲間を増やして、開発チームがよりプロダクト開発に注力していけるようにしていきたいです。従業員の人数は増えてきましたが、まだまだベンチャーマインドを重視している環境ですので、周りを巻き込んで会社を大きく動かしたいという方と一緒に働けると最高ですね！
