みなさん、こんにちは。介護経営支援開発グループでグループ長をしている岩田文彦です。
事業やサービスの成長に合わせて開発組織も大きくなると、新しい課題が浮かび上がってくることがあります。とくに、複数のチームに分かれて開発を進めていると、各チームで最善を尽くしていても、サービスやプロダクト全体で取り組む課題や舵取りが必要になってきます。サービス全体の技術的な課題にトップダウンで取り組んでしまうと、現場のエンジニアに、コミュニケーションの乖離やモチベーションの低下が生じがちになります。
そこで、私たちは、複数の開発チームの横断的な課題を対象にして意思決定する「プロダクトボード」という活動を始めました。この活動により、規模の大きなサービス開発でありながら、現場のエンジニアも参加しつつ、プロダクト全体を舵取りできるよう体制を整えようとしています。
エンジニアリングマネージャーの方や、一定規模の大きな組織でマネジメントやチームビルディングをどのように進めていくか考えている方、エンジニアで将来リーダーや組織のマネージャーになって、自分で何か決めていきたい方などに読んでいただいて、当社の開発の雰囲気を一部でも感じて頂ければ幸いです。
横断的な情報共有と意思決定が必要
介護経営支援開発グループでは、介護事業者向け経営支援サービスカイポケを開発・運営しています。
『カイポケ』は、介護業務に加えて勤怠管理や給与管理などの40以上の機能・サービスで構成されています。機能・サービスごとに開発チームを組んでおり、運営担当者及びエンジニアを含む、大小合わせて10ほどのチームで構成されています。 特定業界向けのWebサービスとして、それなりの規模になっていると思います。
一方で、カイポケのシステム全体は、どちらかというとモノリシックになっています。ライブラリ・フレームワークのバージョンアップや、セキュリティの観点での取り組みの強化など、横断的な課題対応が欠かせませんが、各チームとしても優先順位を抱えています。
このくらいの規模になると、グループやサービス全体を見ての情報共有や意思決定が不可欠になります。
なお、カイポケの技術的な特徴や開発の様子は、次の記事でも紹介しています。
規模の大きなサービスで、全体の舵取りに現場の納得感が得られるか
2019年の夏ぐらいまでは、全体ミーティングの参加者も10名ほどだったので、1時間くらいの打ち合わせで、必要に応じて意思決定できていました。しかし、2020年春ごろから30名くらいに膨れ上がってきて、そこから事業の成長に合わせて、さらに開発組織が大きくなることが見えていました。
このころ、大きな意思決定や舵取りは、エンジニアリングマネージャーである私と、プロダクトマネージャー担当の人および技術責任者の田辺の３名でしていました。
とはいえ、あまり現場のなかに入って動いていない自分たちが、重要な舵取りを意識的にしていくのは、組織の拡大と成長を考えると厳しいところがありました。判断の的確さであったり、現場の納得の度合いであったりが、どんどん弱くなっていくだろうと考えていました。
現場のメンバーには、自分たちが開発している大きな意味でのプロダクト全体に対して、意思決定などの舵取りに、積極的に参加する機会を提供したいと思っていました。
プロダクト全体を対象に意思決定を責務に持つプロダクトボードを設置
そこで、プロダクト全体の運営について、横断的に自分たちで意思決定するプロジェクトチームみたいな場所を設けることにしました。これが「プロダクトボード」です。
ボードというのは、ボード組織とかボードメンバーといった、重要なメンバーが集まるミーティングといった意味合いです。
プロダクトボードは、組織図上で上位にあるマネジメントチームではありません。各開発チームと並列に存在している、ゆるいフラットな集まりです。各開発チームは担当する機能やサービスに責務を持っているのに対して、カイポケというプロダクト全体を対象にして、何かしらの意思決定を責務として持つということになっています。
ボードメンバーに必要になる、普段の取り組みと異なる考え方
プロダクトボードを設置するにあたっては、まずはボードの設立委員会を立ち上げました。そして、参加するメンバーや、位置付け、方針、意思決定する内容、運営プロセスなどを明確にしていきました。
プロダクトボードを立ち上げて、まだ数か月程度です。春ごろに、法令改正や大きな修正があったので、そのあとスタートしました。現在は、週に1回、1時間ほど、このプロダクトボードで、全体的な意思決定と舵取りを行っています。
現在のメンバーは、カイポケのコア機能のエンジニアや、プロダクトマネージャーなど、およそ10名ほどです。クローズドな会議ではないので、必要なら誰でも自由にオブザーバーとして参加できるようにしています。
現在のところプロダクトボードでは、今期のロードマップやサービス全体としての優先順位を決めています。たとえば、ライブラリやフレームワークをバージョンアップするタイミングだとか、セキュリティの観点での取り組み強化、脆弱性診断など、個々の開発チームでは決めにくいテーマを取り上げるといった具合です。
プロダクトボードで決まった内容は、各チームのロードマップに反映してもらっています。
参加するメンバーには、自分たちのチームでの普段の取り組みと異なる考え方が求められます。自分のチームの個別最適化だけを考えるのではなく、プロダクトの全体最適化を考える必要があるからです。メンバーによって差異はあると思いますが、以前より納得感が得られているのではないかと思います。
課題解決に取り組む幅広い機会を、エンジニアに提供したい
このような全体を調整する取り組みは、システムや組織規模が一定以上の大きさになれば、どこでもやっていると思います。しかし、リーダーやマネージャーの会議体として、上位組織に位置付けてあると、現場のメンバーには、やらされ感が出てくると思います。その点、フラットなゆるい位置付けのプロダクトボードという取り組みは、ちょっと珍しいかも知れません。
今後は、チーム横断的なプロジェクトとして発足して適宜アサインしたり、個人が善意で拾っていたものをシステム化したりというように、個人としてチームと折り合いを付けやすい形になっていけばと思います。
また、ボードを経験することで、他チームとの連携や上位レイヤーとのコミュニケーションを体験するという人材育成の側面もあります。マネージャーであったり、アーキテクトであったりと、弊社にもエンジニアのいろいろなキャリアラダーがある中で、プロダクトの課題を技術で解決していく幅を広げる機会になればと思っています。
最後に
元々、私もエンジニアとして、いくつかの大きな開発組織で仕事をしてきて、上位のメンバーが何かを決めて、それを下位のチームが実行するという硬直した状況をいくつも経験してきました。そのたびに、「上の方でまた何かやってるなぁ」といった違和感であったり、「もっと参加できたらなぁ」といった想いを少なからず持っており、いつかは、このような取り組みを実現してみたいと思っていました。
そして、プロダクトボードのような取り組みが有効に機能していって、チーム全体が自立的に意思決定できるようになっていくことで、組織をマネジメントする自分のような立場の人間が、ゆくゆくは見えなくなると良いなと思っています。
今後の取り組みや結果についても、このブログで共有していけたらと考えています。
