2024.10.21
お互い疑心暗鬼になりがちな、経営企画と事業部の壁 組織に「分断」が生まれる要因と打開策
OKRとカンバンで組織の学習効率が3倍になった話(全1記事)
リンクをコピー
記事をブックマーク
渡邊優太氏:私からは「OKRとカンバンで組織の学習効率を3倍にする」というテーマで、具体論についてお話をさせていただきたいなと思います。
このセッションはパーティーマネージャーやステイクホルダー、子連れの方など、ユニークな方が多いので、ちょっとネタ用意しときゃよかったなっていう後悔があるんですけど。とにかくがんばります。
私は、Speeeという会社に属しています。Speeeでは、プロダクト推進室というPMの所属する部署がありまして、そこに所属しております。私は昨年まで3年間人事をやっておりまして、主にエンジニアの採用・組織づくりをやった後に「エンジニアと一緒にモノがつくりたいんや」ってなりまして、ここ半年ほどPMをやらせてもらっています。
今回は、私が実際に行った学習効率をあげるための組織的な取り組みを、みなさんにも共有したいと思います。
私がPMになって最初に感銘を受けたのは「モダンアジャイル」という考え方です。人事という組織側の人間だったので、「人びとを最高に輝かせる」という要素や、「安全を必須条件にする」という思想がとてもいいなと思いまして、そこを意識してチームをつくっています。
「そもそもどんなチームなのか?」について、約1年ぐらい前にプロダクト推進室という組織ができたので、その前後での変化を紹介したいなと思います。
私が所属している事業部にはエンジニアが9名おり、PMというロールはそもそもなく、デザイナーも別の組織でした。POという表現が正しいかもしれないですが、事業責任者からオーダーされたモノをそのまま受け取って作るという、社内受託っぽい開発環境や、チームの振り返りが弱く、個人としての成長や変化感を感じにくいといったことがありました。
プロダクト推進室という部署ができたタイミングで、PM、エンジニア、デザイナーで構成されたプロジェクトベースの少人数のチーム編成とし、長期・中期・短期というかたちで、それぞれの取り組みを連続的につなげながら改善していく仕組みを用意しました。
我々の開発組織では、ミッション・ビジョンを実現するためのプロダクトコンセプトを規定しています。それを実現するためのプロセスの精度をあげる仕組みとして、計画書やOKR、カンバンがあります。時間軸が異なる取り組みをつなげながら、持続可能な成長を実現する仕組みとなっています。
ここからちょっと簡単に、事例をまじえて紹介していきます。まず1つは、プロダクトのコンセプトとプロダクト計画です。
これまで私どもの会社ではビジネスの色が強く、簡単にいうと、モノづくりの気概が弱かったんですね。なので、事業計画書はあるけど、プロダクトとして具体的に何をする計画なのかといったことが決まっていなかったので、PMはプロダクトのコンセプトを作成し、プロダクトの方向性を規定するところを最初の業務としています。
我々のボスがよく言ってる言葉で「PMはドキュメントで語る」というのがあります。今回実際につくった成果物をみなさんに共有したいと思います。
私が属しているのは不動産マーケットの事業なのですが、これは実際にプロダクトコンセプトといったかたちで、「プロダクトを通じてユーザーに何を提供したのか?」をまとめたものになります。
そのコンセプトをベースに、半年から1年のスパンで何をつくっていくのかをまとめたものが、プロダクト計画書になります。実際にはまだまだ課題が残っているんですけど、これまでの場当たり的な開発ではなくて、大きなロードマップをベースに方針の決められた開発をするためのものとしてやっています。
次にOKRですが、OKRを業務に使っている方ってどのくらいいらっしゃいますか?
(会場挙手)
あー、少ないですね。5パーセントくらいですかね。
では、ちょっとOKRについて簡単に紹介します。OKRについては、(スライドを指して)この本に興味を持ったメンバーが「実際にやってみよう」と言ったことからはじまり、それが比較的手ごたえあったので開発チームに導入して、今では全社でOKRを使って業務の挑戦をしていこうという取り組みに発展しています。
OKRは「Objective」と「Key Result」によって成立します。Objectiveには普通に頑張るだけでは到達できないゴールを設定し、それを満たすための条件としてKeyResultを設定する。詳細は本を読んでいただければと思います。
開発は比較的、事業部が持つ数字と距離が遠い部署だったりします。なので、僕らにとってはObjectiveが重要になります。逆の視点で言えば、事業責任者サイドからするとKeyResultがめちゃくちゃ重要になってきます。それらをつなぐためにOKRを設定しようというかたちになっています。
上から会社のミッション・ビジョンと事業のミッション・ビジョン、そしてそれを実現するためのプロダクトコンセプトと計画をまたいで、開発陣のOKRにつなげるという取り組みをしています。
これはまだはじめて3か月目の取り組みです。OKRそのものを3か月周期でまわしているので、まだ1週目なんですけども。開発陣は自分たちのやっている取り組みが、事業のどこにつながっているのかが理解できて、それによって事業と個人の間のつながりがよくなり、日々成長していくというような仕組みができるようになりました。
最後、カンバンですが、カンバンを使われている方ってどれくらいいますか?
(会場挙手)
あっ、これはめっちゃ多いですね。5割ぐらい。
これまでは、ZenHubでタスクを管理してました。たぶんよくある話だと思うんですけども、プルリクがぜんぜん消化しねえとか、クローズされずたまり続けるとか、あとはPMってなにやってるのかZenHubではわからない、みたいな話がありました。
それなら物理にしようとなりまして、物理カンバンで見える化し、朝会でちっちゃく問題解決をしていきましょうというスタイルにしました。これについてはけっこう伝えたいという思いがありまして、大きくはOKRとカンバンとKPTが物理に集約されたものになります。一番上に、神棚っぽくOKRを設定して、「我々はここを見据えて仕事してるんだぞ!」と常に意識しています。
それを実現するために日々やるべきことがカンバンになっていて、その横にKPTの結果があります。そして、毎週行うKPTで洗いだされたTRYを、そのまますぐカンバンにアクションとして記載していくかたちで、開発のタスクだけではなくPMがやってるものも含めて、すべてのタスクを物理として共通の場所に集約したボードになっています。
このOKR-KPT-カンバンの運用ですが、最初めちゃくちゃ失敗しまくって、2か月ぐらいでようやく完全に馴染んだなあという感覚があります。なかなかカンバン上に表現できないフラストレーションとか、もやもやを表現する場所がなくて、「もやっとコーナー」っていうのをつくったんですよ。これがすごい機能していて。
これはなにかというと、口には出せない「もやっとしたこと」を付箋で貼ります。付箋の色は全員共通にしていて、だれが書いたかわかりにくい仕様にしています。
この「もやついていること」を、次の日の朝会で「今日のもやっとコーナー」の確認を行い「日々のもやっとは、小さいうちに解消する」という改善のかたちをとっています。
ただ、どうしても朝会だけで解決できない問題もあるので、そういったものは「トニックタイム」という時間を用意しています。週次のスプリントの振り返りをしたあとに、カフェスペースでやります。
弊社には、「Speee Lounge」というカフェスペースがあるんですけども、そこでコーヒーを入れながら、朝会では解消しにくい大きめの「もやっと」を雑談しながら解決していくというやり方を組み込んでいます。
(スライドを指して)写真に写っているのはエスプレッソにトニックウォーターを混ぜたエスプレッソトニックというもので、これを飲みながら、みんなで殺伐としていない雰囲気の中で課題解決をしています。
今日、3つの取り組みを紹介したんですけども、ぶっちゃけ最初は失敗しまくってて、まだ僕らも3か月ぐらいの取り組みなんですけど、ようやくそれっぽくなってきたんで、今回少し共有させていただきました。
いま大事にしていることは「文化を育む」ということです。簡単にいうと、チームはプロジェクトによってメンバーが入れ替わりますし、事業は競争環境において、日々変動するものなんで、基本的には不確実なものだと思っています。
一方で変わらないものはなにかというと、その組織に根付く文化だなと思っています。文化を育む仕組みづくりに取り組んでいるようなかたちです。
僕らは3チームがそれぞれ自分で考え、工夫し、挑戦するので、「3倍チャレンジ」って勝手に呼んでいるんですけども。小さいチームを3つ作って、社内WikiとOKRのWinセッションという、金曜日に今週やった成果を共有する会というのを3チーム合同でやることで、良い取り組みを3チームに伝播させていくことをやりました。
Kibela(キベラ)という社内Wikiを使っているんですけども、改善事案で当時試した内容とその結果であったり、先ほど共有したOKRの取り組み事例を共有しながら、組織としてひとつの取り組みで、2倍3倍の成果をあげるってことを意識してやっています。
まとめると、Speeeの開発では、長期・中期・短期の時間軸、および会社と個人をつなげる取り組みとして改善サイクルをまわしていて、その思想はモダンアジャイルに根付いていますという話でした。
ツイートで反響をいただいたので最後にお伝えしますと、「自走するチームによって、どうやって実現するかのHowに紐づく課題は、問題解決のプロであるエンジニアやデザイナーに一任し、PMはプロジェクトマネジメントの係数を減らし、その時間で顧客に向き合い、提供すべき価値であるWhatを定義することに注力する」ことを目指しています。
こういった価値提供とはなんぞやに取り組むための仕組みを、今回はご紹介させていただきました。以上、ありがとうございました。
(会場拍手)
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.21
40代〜50代の管理職が「部下を承認する」のに苦戦するわけ 職場での「傷つき」をこじらせた世代に必要なこと
2024.11.20
成果が目立つ「攻めのタイプ」ばかり採用しがちな職場 「優秀な人材」を求める人がスルーしているもの
2024.11.20
「元エースの管理職」が若手営業を育てる時に陥りがちな罠 順調なチーム・苦戦するチームの違いから見る、育成のポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.19
がんばっているのに伸び悩む営業・成果を出す営業の違い 『無敗営業』著者が教える、つい陥りがちな「思い込み」の罠
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.11
「退職代行」を使われた管理職の本音と葛藤 メディアで話題、利用者が右肩上がり…企業が置かれている現状とは