
2025.02.26
10年前とここまで違う 落とし穴だらけの“ERP to ERP”基幹システム刷新が抱えるリスクと実情
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を定義することに注力する」ことを目指しています。
こういった価値提供とはなんぞやに取り組むための仕組みを、今回はご紹介させていただきました。以上、ありがとうございました。
(会場拍手)
2025.03.25
減点を恐れてモチベ低下、果ては離職も… あらゆる“会社の害虫”を大繁殖させる「ラスボス」の正体
2025.03.21
マネージャーの「自分でやったほうが早い」という行動で失うもの 効率・スピード重視の職場に足りていない考え方
2025.03.24
最悪の場合、組織を死に至らせる“会社の害虫”とは 誤った意思決定や品質不祥事を招く要因
2025.03.25
ムダな仕事がなくならない“マッチョな職場”を変えるには 近年の過度な「KPI主義」が組織に与えた影響
2025.03.24
気づけばモラル崩壊……人材育成に無頓着な企業の末路 業績アップや採用にもつながる“人への投資”の重要性
2025.03.19
組織をダメにする“害虫”の正体は間違った思い込み AIやDXなど手段のみにこだわるダメ上司の見極め方
2025.03.21
査定時期に上司から1年前の失敗を指摘される理不尽 変えられない過去を議論する「成果主義」の弊害
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.03.24
AIの進化が行き着く先は「イノベーター」へ ChatGPT開発者サム・アルトマン氏 × 孫正義氏が語る、人工知能変革期の未来
2025.03.27
交渉で「落としどころを探る」という考えは捨てるべき プロが教える、チャンスを逃さない条件交渉のコツ
2025.03.25
減点を恐れてモチベ低下、果ては離職も… あらゆる“会社の害虫”を大繁殖させる「ラスボス」の正体
2025.03.21
マネージャーの「自分でやったほうが早い」という行動で失うもの 効率・スピード重視の職場に足りていない考え方
2025.03.24
最悪の場合、組織を死に至らせる“会社の害虫”とは 誤った意思決定や品質不祥事を招く要因
2025.03.25
ムダな仕事がなくならない“マッチョな職場”を変えるには 近年の過度な「KPI主義」が組織に与えた影響
2025.03.24
気づけばモラル崩壊……人材育成に無頓着な企業の末路 業績アップや採用にもつながる“人への投資”の重要性
2025.03.19
組織をダメにする“害虫”の正体は間違った思い込み AIやDXなど手段のみにこだわるダメ上司の見極め方
2025.03.21
査定時期に上司から1年前の失敗を指摘される理不尽 変えられない過去を議論する「成果主義」の弊害
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.03.24
AIの進化が行き着く先は「イノベーター」へ ChatGPT開発者サム・アルトマン氏 × 孫正義氏が語る、人工知能変革期の未来
2025.03.27
交渉で「落としどころを探る」という考えは捨てるべき プロが教える、チャンスを逃さない条件交渉のコツ