CTOがHRチームの組織化に取り組んだ話
この記事はUMITRON Advent Calendar 2022 25日目、最終日の記事です。
はじめに
こんにちは。UMITRONのCo-founder / CTOの岡本(@um_takuma)です。今年2回目の記事になります。今年も最終日の記事を書きます。今年のAdvent Calendarもソフトウェア、ハードウェア、HRと仕事においても多岐に渡っていたり、全く仕事に関係ないものもあったり、海外のメンバーも参加してくれたりでバラエティに富んでいていいですね。
私のUMITRON Advent Calendar 2022の1回目の記事はこちら。
Advent Calendar 25日目は CTOがHRチームの組織化に取り組んだ話 という内容をお届けします。ウミトロンにはTeam successチームという全社の組織の課題を解決し、会社を成功に導くことをミッションにしたHRチームがあります。やることは組織づくりから、社内で働く上での困り事を解決したり、人事施策や社内制度を整備したり、採用や全社イベントの運営などの人事としての機能も含んでいます。
チーム発足時から私を含む経営陣3人はこのチームに属していましたが、今年の7月から私が経営陣を代表してこのチームに属して組織化に取り組むようにしました。この半年でどのようなことをしてきたかについて記そうと思います。
Team successチームの組織化に取り組んだ背景
Team successチームの課題
Team succeesチームはもともと経営陣3人 + Team successのリード1人(あこてぃす @akotisumitron) の4人のメンバーで成り立っていました。メインでTeam successのリードが手を動かし、チームの方向性を経営陣と議論しながら決めるという体制でした。最初はこの体制で運営できていましたが、会社の事業やプロダクトが広がり、組織も大きくなっていく中で経営陣がだんだんとTeam successチームに時間を割けなくなっていき、実態はほとんどTeam successのリードのみの1人チームになってしまっていました。また時間が割かれないだけでなく、経営陣の中で誰が最終的に意思決定するかが明確になっていなかったため人事施策がなかなか実施できなかったり、経営陣とTeam successのリードとの間でミスコミュニケーションが起きチームの方向性が一致しなかったり、といった問題が起きていました。定期的にディスカッションする機会も月に30分と限られていました。
新しい体制
Team successチームがうまく運営できていない状態では会社組織もうまく運営することはできないということで、経営陣の中で私が代表でTeam successチームにコミットする事にしました。これは経営陣の中で誰が責任を持って人事施策や社内制度の意思決定をするかを明確にするため、またTeam successチームにコミットする時間あたりの成果を最大限にするためです。私がコミットするようになったのは会社のメンバーの大部分を占めるエンジニアのマネージメントをすでに行っていて業務でオーバーラップする部分が大きかったから、会社の組織化に興味と適正があったから、うまく回っていないものをうまく回るようにするのが得意だから、といった理由と自分の意志でやることを決めました。
そして、私 + Team success (リード + メンバー) 2人の計3人でチームを再始動することにしました。(ちょうどこのタイミングで育休から復帰したTeam successのメンバーが1人加わってくれました。)
Team successチームのチーム作りで取り組んだこと
今まで実質的に1人チームだったTeam successチームをちゃんと3人のチームにすることからはじめました。チーム作りは今まで自分がやってきたエンジニアチームの作り方と全く同じやり方をしました。
言語化する
まず、チームでの業務内容を全てタスクとして言語化しました。すでに前のチーム体制のときにチームメンバー間で認識が統一されていないということが大きな問題だということがわかっていたので、その問題を解決するためです。タスクをやる目的、タスクのクローズ条件、担当者、期日、現状のステータスを全て明確にしてNotionのテーブルを使って起票していきました。タスクの管理はカンバン方式に則り行いました。タスクのクローズは全員で確認する、やる業務は必ずタスクにする(= タスクにない業務はやらない)といった原則や、一人で一度に多くのタスクを進行中にしない、タスクは大きくても1週間でクローズできる粒度にまで分解する、といったプロダクト開発で行うような運用方法に従いました。これにより誰が何をやる必要があるか、現状の課題は何かということが明確になりました。
粒度は細かく頻度は高く
また、チームで週に一度のミーティングを設け、タスクの進捗確認、OKRの進捗確認、課題の共有と議論といったことを以前よりも高頻度で行うようにしました。業務もタスク化しカンバン方式に従って粒度を決めることで、課題解決のために必要なアクションの大きさが以前よりも小さく保てるようになり、行動にすぐ移れるようになりました。チームが軌道に乗るまでは新しいことに慣れる意味も含めて粒度は細かく頻度は高くということを意識して、間違ってもフィードバック・軌道修正が早くできるようにしました。
時間を割く
これらを行うために私は週に最大1日を使うことを決めました。今までプロダクト開発などの業務を優先して、Team successチームの業務を後回しにしてしまっていたという反省もあり、割く時間数でコミットを明確にするようにしました。具体的に月曜の午後をカレンダー上でブロックしてその時間はTeam successチームの業務に当てるようにしました。プロダクト開発チームのメンバーにも今日はTeam suceesの業務をやりますと共有します。もちろんプロダクトの緊急対応などで時間が避けない日もありますが、時間を決めておくことで自分の頭の中で時間を割けていない、コミットできていないという意識が生まれるので、長期間その状態が続かないように改善しようという力がはたらくようになりました。時間を決めることで他のTeam successチームのメンバーにも自分がコミットできる量の可視化ができ、チーム内での業務分担が円滑に行えるようになります。
Team successチームによる課題解決のために取り組んだこと
Teams successチームがチームとしてまとまってきたので、次は会社組織の課題を解決するための人事施策を作り実行するプロセスの改善に取り組みました。一つ一つの課題に対して有効な施策を作ること、その施策を実行することを理解してもらうこと、実行した後本当に効果があったか確認すること、それらをきちんと再現性高く行えるような仕組み化に取り組みました。
計測を行う
課題を正しく捉える、適切な問題解決ができたか確認する。このように問題解決をすることにおいては計測することが大事です。実際に数値で現状を把握しなければ、解くべき課題が正しいか、その課題に対する打ち手が正しかったか、といった判断をすることはできません。数値はチーム全員で共通の認識をもつための指標として強力なので、プロダクト開発やビジネスと同様にTeam successチームにおいても活用します。社内の問題を把握するために、全社員にGoogle formでアンケートを取ったり、Slackのログを集計したり、採用プロセスの各ステップの通過率といった数値を分析したりということを当たり前に行うようにします。OKRの計測可能なKey Resultを設定する、進捗を正しく測るといった目的にも、これらの数値を活用します。
小さく試す
人事施策は社内全員に影響するため、失敗を恐れて慎重になるあまりなかなか実行に移せない場合があります。前のチーム体制ではTeam successのリードから施策の提案があっても、その影響や失敗を考えて経営陣がすばやく意思決定できなく、実行までに時間がかかってしまうという問題がありました。これは施策の不確実性が高く、かつ影響範囲が大きいためという側面があります。そこで、そのような問題を解決するために、不確実性が高く失敗したときの影響が大きい施策は、最初から社内全体に行うのではなく人数が少ないスモールチームでまず試す、ということを行うようにしました。また、実施するときに、これはトライアルなのでうまくいかない可能性があること、実施した後にフィードバックをもらい今後の改善に役立てること、を事前に説明することで対象のチームの協力を得ることができ、失敗したときの影響も最小限にすることができます。場合によってはこのトライアルを複数回、複数チームで行い、改善を繰り返すこともあります。また、このような試行錯誤のプロセス自体も社内にオープンにすることで、このプロセスの意図や背景も伝えることができ理解を得ることに役立ちます。
最初から完璧を目指さない
組織の課題によっては、初めは全くいい解決方法が思い浮かばないこともあります。こういう場合にはそのまま考え続けても事態が進展することは少ないので、まず具体的な行動をすること、最初から完璧な解決方法を目指さないこと、を意識します。
最初は質よりも量を重視します。ある課題に対していい解決方法が浮かばないときは、次回週次ミーティングまでと期限を決めてそれまでにチームメンバー全員がどんなにくだらない方法でもいいので最低5つアイデアを文章にしてくる、ということを実行していました。期限を決めることで強制的に行動に移させる、一人がアイデアを複数考えることで課題を多角的に捉えることを促す、くだらない方法でもいいという条件をつけることでアイデアを出しやすくする、文章化することでそれぞれの思考が明確になったりする、といったことが狙いです。これらで集まったアイデアをベースにすると何もアイデアがなかったときよりも議論が進み、より良いアイデアが産まれ(所謂マクドナルド理論)、最終的には実行にたる解決方法までたどり着くことができます。
おわりに
Team successチームにコミットするときに意識したこととして、具体的にどのような人事施策をするか、社内制度を整備するか、ということではなく、どのような意識がチームに根づき、どのようなプロセスを回せば効率的に素早く課題を解決できるチームになるかということです。これは、実際の問題の解決策を考えるというよりも、どのようにすれば問題解決ができるチームを作れることができるか、ということです。また、自分がコミットできる時間は限られるため、どうすれば自分がボトルネックにならずに他のメンバーが自律的に動けるかを考えました。実際にやったことはプロダクト開発やエンジニアリングチームにおいては当たり前のことをやっただけです。これはHRという領域でも問題解決の本質は変わらないため十分に機能して、よりよいチームを作るのに役立ちました。
ウミトロンでは一緒に働く仲間を募集しております。持続可能な水産養殖を地球に実装するというミッションの元で、私たちと一緒に水産養殖xテクノロジーに取り組みませんか？
この記事が気に入ったらサポートをしてみませんか？