クラウドワークス エンジニアブログ

日本最大級のクラウドソーシング「クラウドワークス」の開発の裏側をお届けするエンジニアブログ

ノリで社内の「日報カイゼンプロジェクト」のPOをやってみたら、大変だったけどめっちゃ学びになった話

クラウドワークス Advent Calendar 2022の21日目の記事です。 qiita.com

はじめに

簡単に自己紹介

クラウドソーシングサービス「クラウドワークス」のプロダクト改善などに携わっている小橋と申します。

エンジニアとして2020年9月クラウドワークスに入社、EMを経て、現在はUXリサーチプロジェクトのリーダーや、マーケティングオートメーションツールの導入検討など、プロダクト/事業の垣根なく、会社やサービスのために色々やっています。

ちなみに、こちら入社1ヶ月目で書いた記事です。 まだクラウドワークスに入社して、2年ちょっとしか経っていないんですね。 入社後、いろいろなことをやってて濃厚な日々を過ごしているせいか、もう3年以上在籍しているのかと思っていました。 engineer.crowdworks.jp

この記事の概要

この記事では、社内横断プロジェクトである「日報カイゼンプロジェクト」のPOをやってみた件について書いていきます。

クラウドワークスの日報とそれに関するカルチャーや、日報カイゼンプロジェクトに入った経緯、入った後にやったことなどをつらつらと書いていきたいと思います。

クラウドワークスのカルチャー紹介 兼 新米PO体験記みたいな感じで、読んでもらえればと思います。

それでは、ちょっとボリューミーな記事になってしまいましたが、興味ありそうなところだけでもお付き合いください!

目次

日報カイゼンプロジェクトのPOになったきっかけと、その背景

そもそもクラウドワークスの「日報」とは?

クラウドワークスでは、全社員が毎日、退勤時にその日の業務を通じて感じたこと・考えたことなどをフリーフォーマットで投稿する「日報」という文化があります。

※「日報」とは(カルチャーブックより)

毎日、業務で「感じたこと、考えたこと、ばぶばぶ*」をデンタツし、仲間の仕事を称賛するもの。 *業務報告ではない解釈を書く上で必要な業務内容(事実)があれば書く

*ばぶばぶ(社内用語) 結論のない発言、まとまってない発言、事実のない解釈のみの発言などをおこなうこと (例:意見がまとまっていないのですが、ばぶばぶ良いですか? ) ばぶばぶしても誰にも怒られない。

日報は、slackのワークフロー・gasなどを活用して作成されており、手軽に投稿が可能で、スタンプでのリアクションが飛び交っています。

(新入社員用オンボーディング資料より)

日報カイゼンプロジェクトのPOになったきっかけ

元々、日報の運営・開発などに携わっていなかったのですが、全社朝会(※)で「日報カイゼンプロジェクトPO募集!」と公募があり、軽い気持ちで応募してみました。

ノリです。 プロジェクトに携わっているメンバーが、一緒に仕事したら楽しそうだなーという感じだったので、具体的な業務内容・責任範囲とかろくに確認しないで、応募してみました。

…が、 その後、予想以上に苦労することになりました。

※全社朝会について

週の初めに全社員が参加する朝会が行われています。 各種成果の発表、新入社員の紹介、社長はじめ経営陣からの発信などが毎週行われています。

(CW Cultureより)

ある日の全社朝会にて、日報カイゼンプロジェクトからの活動報告とともに、POの募集が行われました。

これを聞いてなんかビビッときたみたいです。 発表しているメンバーの熱量・意志みたいなものを感じたんですよね。

朝会が終わって、午後イチでDMしてました。 すごい決断力ですね。(それをノリという)

日報カイゼンプロジェクトの成り立ち

そもそも、クラウドワークスの日報自体は昔からあるものでしたが、最初から現在のスタイル(slack)であったわけではありません。

元々は内製ツールでやっており、UI/UX観点・メンテナンス観点ともに課題がありました。 また、日報の立ち位置・意義などもあいまいで、人によって書いたり書かなかったりなど中途半端な感じでした。

それを改善すべく2021年4月に立ち上がったのが「日報カイゼンプロジェクト」です。

プロジェクトメンバーの努力によって、現在のスタイルにカイゼンされ、社員の投稿率もほぼ100%。 リアクション・コメントなどが飛び交う活発な社内コミュニケーションツールに生まれ変わりました。

この時のカイゼンプロジェクトは、2021年10月の全体キックオフにて、社内MVT候補にも選ばれ、成功を収めました。 めでたしめでたし。

(MVT資料より抜粋)

…が、そのあとに、停滞をしてしまいます。

日報カイゼンプロジェクトPOが募集された経緯

上記のように、「管理者不在の内製ツール」→「slack」の置き換えという大きなカイゼン・成功を収めたプロジェクトですが、上記成功を区切りとして一部メンバーを除いてプロジェクトが解散となりました。

残されたエンジニアメンバーが中心で細かいカイゼンなどをおこなっているものの、「管理者不在の内製ツール」→「slack」のようにわかりやすいゴールや達成基準もなく、プロジェクトの方向性・目標などもない状態になってしまいました。

そこでそれを打破すべく残されたプロジェクトメンバーから「日報カイゼンプロジェクトPO募集!」が行われ、そこに自分が飛び込んでいくのでした… そんな状況であることも知らぬままに…

プロジェクトに入ってやったこと

ミッションの定義

プロジェクトに入ってまずやったのは、日報のミッションをあらためて明文化することでした。

カルチャーブックに毎日、業務で「感じたこと、考えたこと、ばぶばぶ*」をデンタツし、仲間の仕事を称賛するもの。という定義は明文化されていますが、何のために日報がそれをやっているのか? 日報の行き着く先はどこか?ということは、なんとなくみんなの頭の中にあるものの明文化されている状態ではありませんでした。

なので、具体的なカイゼンのための施策・手段を考える前に、まずはそもそもの日報の立ち位置・目的にしっかりと向き合いあい、ミッションを明文化していくことにしました。

CW Value「One CrowdWorks」と日報の関係

まず、日報に大きく関連するクラウドワークスの会社のValueとして「One CrowdWorks」というものがあります。

(カルチャーブックより抜粋)

カルチャーブックを見ると「One CrowdWorks」の関連項目として日報の概要は明文化されていましたが、日報が何をどうやって目指すかは明文化されていませんでした。

また、「One CrowdWorks」に関連するアクションは、日報以外にも「全社朝会・全体キックオフ」「週報」など、さまざまあります。

なのでミッション考える以前に、カルチャーブックに記載されていないものも含めて、「One CrowdWorks」に関連するアクションを整理して、日報の立ち位置を見定めることにしました。

こうやってみると、めっちゃいろいろなアクションがありますね。 クラウドワークスはカルチャー浸透にかなり力を入れている会社だというのがよくわかります。

立ち位置を整理することによって日報の特性が見えてきました。

  • 全社員が必須で同じフォーマットで発信する媒体は、入社時の「自己紹介」と「日報」のみである。
  • 他の媒体は、MVPなど代表者だけが発信するものだったり、週報だとチーム単位での発信となる。
  • 他の媒体に比べて、気軽に投稿・確認ができる。

これで、ミッションが考えられそうですね。

ミッション決定

それらの日報の特性を踏まえて、ミッションは 「個のデンタツを促し、One CrowdWorksを推進する」 としました。

ミッションの構造としては

  • 手段:「個のデンタツを促し」
  • 目的:「One CrowdWorksを推進する」

となっています。

最終的なゴールは「One CrowdWorksを推進する」に尽きます。 前述のカルチャーブックにもあるように、日報はOne CrowdWorksを推進していくためのひとつの手段になります。

ミッションを考えるにあたって、日報ではどうやって「One CrowdWorksを推進する」のか?をシンプルに言語化したいと思いました。

まず「One CrowdWorks」の説明で 「他のメンバーやチーム、部門と連携・協力して、成果をうみだす姿勢をもつ」 とあります。

日報は毎日気軽に投稿・リアクションできるツールではありますが、ライトな反面、日報内だけで濃厚なコミュニケーション・連携が行われるのは難しいと思っています。

ただ、前述したように「全社員が必須」かつ「気軽に投稿」できるのが日報の特徴です。 なので、濃厚なコミュニケーション・連携の前段階として、個と個の認知を拡大するためのツールとしてかなり有用なものなのではないかと思いました。

普段接点のない人だったり、表面的な仕事のコミュニケーションしかできてない人でも、日報でライトに少しでもお互いの認知を増やして、なんらかの交流・連携のきっかけになればいいな。と思いました。

例えば、たまたまオフィスで顔を合わせた時に日報に書いてあるネタを思い出して会話が弾んだり、他の部署の人が何気なくつぶやいたことが自分の仕事のヒントになったり、共通の趣味があることがわかってその人との距離が縮まったりとかとか。

それをシンプル「個のデンタツを促す」と表現してみました。

「個の」の部分は、会社のミッションである「個のためのインフラになる」のオマージュ的な。

「デンタツ」はカルチャーブックにも「成果をデンタツ・称賛し誇りを高めあうカルチャー」などとあるように、日常的にも社内でよく使われる単語です。

こんな感じで、言葉選びもみんながしっくり馴染みやすいようにと考えてみました。

そんな思いを込めて「個のデンタツを促し、One CrowdWorksを推進する」というミッションにきめました。

文字にするとめっちゃシンプルなんですが、実は、かなり色々考えられたミッションなんですよ!(自己アピール。これも一種のデンタツです!)

目標へのブレイクダウン

ミッションは決まりましたが、それだけではすぐには施策・アクションにはまだ落とし込むは難しいので、ミッションからブレイクダウンして具体性を上げていきます。

One CrowdWorks(ワンクラ)な状態とは?

「個のデンタツを促し、One CrowdWorksを推進する」のミッションにあるように、最終的な目的は「One CrowdWorksを推進する」なので、そもそも「One CrowdWorks」な状態ってなに?ってところを深ぼってみました。

以降「One CrowdWorks」を「ワンクラ」と略させてもらいますね。

(社内では、こんな感じで「ワンクラ」って使われたり、slackのスタンプにもなっていたりします)

カルチャーブックに「他のメンバーやチーム、部門と連携・協力して、成果をうみだす姿勢をもつ」と記載があるものの、定量的にワンクラを示すような指標はありませんでした。

なので、どうすればワンクラな状態を定量化・可視化することができるか?と考えてみました。 もし、その状態が定義することができれば、如何にその状態に近づけていけばいいか。その状態に近づくためにはどんな認知を促進していけばいいかとわかると思いました。

そんな考えから、雑でありますが、以下のような「ワンクラマップ(仮)」を作ってみました。

自身に近いことを認知・興味・協力をもつのはあたりまえとして、距離の離れたタスク・組織等にたいして、コミットメント度合いが増えれば増えるほど、ワンクラに近づくということがわかります。 なので、組織・チームの離れた個のデンタツを重点的に促すことができれば、日報によってよりワンクラが促進されると考えました。

一旦理想の状態を考えてみる

日報はslackで運用されていますが、slack上で既読率を取るのは難しいので、リアクション数が追いやすい定量指標となります。

単に「リアクション数を増やす」ことを目標指標としてしまった場合、極論、全社員に全部の日報に目を通してもらって、全文の日報にリアクションしてもらうことをトップダウンで強要すれば、いくらでもリアクション数はあがっていきます。

また、クラウドワークスはまだまだ成長フェイズの会社で、会社規模もこれからどんどん拡大していくことが想定されます。 そのため、意識をしていかないと、社員数増に伴い、1日の日報投稿量の総数も増えて日報を読む時間の負荷も増えていくことが予想されます。

なので、制約条件として、日報を読む時間を設定してみるのは良いのではないかと思いました。 その限られた制約条件・時間の中でワンクラにつながるようにするためにはどうすればいいか?と考えれば良いのではないかと。

そのために、まずメンバー全員で、各社員が1日あたりに日報にかける時間はどの程度が適切か?というのを議論してみました。

MGRだと人によって要求する時間の認識などばらつきはでましたが、メンバーはおおむね5分くらいが標準時間だなという認識がそろったので、この「5分」を「日報を読む時間」としてピン留めすることにしました。 ゆくゆくは、MGR等の役職など社員の属性によって時間設定を変えていった方がいいかもしれませんが、まずはシンプルに「全社員が日報を読む時間は5分が標準」と言い切ってしまうことにしました。 (もちろん、意志をもってたくさん読んでくれるメンバーはwelcomeです!)

標準的な読む時間が定義できたところで、次はその限られた時間内でどの程度の日報が認知できるのかな?ということを調べてみました。

もうこれは、実際読んで計測した方が早いよね。ということで、全社員の日報を全部読んでみて時間を計測してみることにしました。

日報を読む時間を測る際にはフラットなデータが取れるように、元エンジニアでプロダクトに関わっている私と、サブPOの榊さん(メイン業務はクラウドテックの営業)で、それぞれ測ってみることにしました。

身近な組織・職種の日報は割と読みやすいのですが、離れた組織・職種の日報だと前提知識も少ないですし見慣れない言葉・単語などもありその分時間がかかると思ったので、違うバックボーンを持った2人がそれぞれ測定すればちょうどいい結果が得られるかなという仮説です。

実際、測ってみましたが、現時点で300名近くの社員がおり、全員分読むだけで20分以上かかってしまいました。 (なかなか濃厚で楽しい時間でしたが、さすがに毎日は大変そうです…)

組織によって読む時間にブレがあるものの、全体をならすと、1日報を読んでリアクションをするのに、平均5秒程度かかるということがわかりました。 2人とも同じような結果になったので、これを基準値として採用することにしました。

1日にかける時間と、1投稿あたりの読む時間が定義できたので、これによって標準的なユーザーに対する目標値ができました。

  • 「1日あたり5分 / 1投稿あたり5秒 = 1日あたり60投稿」

そして、ここからさらにチームで議論を行い、さらに解像度を上げていきました。

議論の結果、日報ではワンクラを推進していくので、標準的なユーザーで「自組織10-20件 + 他組織40-50件」を目指すという目標を掲げました。

ただ、これはビジョンに近い中長期的な目標なので、現状を踏まえて直近の目標にさらにブレイクダウンしていきます。

現状の状況をもとに直近の目標を決定

「自組織10-20件 + 他組織40-50件」という中長期的な目標を掲げたので、その目標と現在の状況を分析・比較しました。

まずは、ワンクラを目指すということで組織横断的なリアクション数を見てみましたが、まだまだ目標の数字にはほど遠いことがわかりました。

また、さらにいろいろデータを分析していったところ、そもそも同組織も含めて、まだまだリアクション数も少ないのだなということもわかりました。

データを見ると、自組織・他組織問わず1日あたり10件以上のリアクションをしているユーザーが30%にも満たないということがわかりました。

「自組織10-20件 + 他組織40-50件」というのが理想的な状態ではありますが、直近半年スパンでは「1日あたり10件以上のリアクションをしているユーザー数を30%→45%(1.5倍!)にする」という目標を掲げました。

直近は、まず質より量を目指し、次の段階で、質(≒ワンクラ)につなげていきます。

みんなで施策決め

直近での明確な目標が決まったので、これをもとにチーム内で具体的な施策を検討しました。

エンジニア・PO・組織開発部・営業・MGRなど色々なメンバーが参加している日報プロジェクトですが、職種とか関係なく、みんなで施策案・アイディアを出し合いました。

やはり、日報は職種関係なくみんなが日常的に使っているものなので、活発に意見が飛び交いました。

全員で意見の発散をしたあと、メインPOである自分が取りまとめて、数案に絞り込み、意思決定のための議論を行いました。

各施策がどのユーザー層に向けたものなのか?実装難易度がどうなのか?など色々なフィードバックをもらい議論を進めました。

あと、施策を決める際に、単に成果・数字だけでなく、「プロジェクトメンバーがわくわくするか?」って観点もとても大事にしました。

自分も含めて全メンバーがメイン業務をもっており、この日報カイゼンプロジェクトは有志の善意で成り立っているプロジェクトです。

なので、いくら成果・数字が上がるからといって、みんなが嫌々やるようなプロジェクトにしたくないなーと思いました。

会社のvalueとしても「“働く”を通して人々に笑顔を」とあります。 カルチャーに直結するプロジェクトなので、まず「プロジェクトを通して我々が笑顔に」なりたいなと。

最後の候補二つになって、どっちも効果ありそうで、自分的にはBだけど、Aも良さそうだよなーとなったとき、最後はエンジニアに対して「ぶっちゃけ、どっちの方が実装するの楽しそうですか?どっちがやりがいありますか?」って聞いて、それで最終意思決定をしました。

これでダメなら、決めた自分(PO)のせいだ! 気にせずみんな楽しくやっていこう!と。 (とはいえ、これを成果につなげるようになんでもやるのがPOである自分の仕事です)

プロトタイプ実装〜試行錯誤中

そして、現在ですが、ちょうどプロトタイプを実装中で、一部ユーザーにも利用してもらい、日々改善しながら実装を進めています。

こんな感じで課題リストを各メンバーからあげてもらって日々議論・改善しています。

プロトタイプ公開から、1週間ほど経過した時点で、プロトタイプユーザーにフィードバックのためのアンケートを依頼し、その結果を見ながら課題の優先順位づけなどを行なっています。

こんな感じで活発にワイワイと開発進めている状態です。 (偉そうにいってますが、もう自分は口ばっかりで、みんなメンバーがガシガシ進めてくれています。感謝of感謝!)

あと、今回は割愛しますが、施策と並行して技術的な課題をどうしていくか?の議論・調査・試行錯誤などもエンジニア中心に行われています。

例えば、現状、slack+gas+スプシで運用しているが、組織・社員数の拡大や、今後の施策を考えるとバックエンド周りを中心とした根本改善が必要になりそうなどなど。

このあたりも、機会があれば発信できればと思います。

最後に

クラウドワークスの「日報とそれに関するカルチャー」や「日報カイゼンプロジェクト」の紹介から、そこに自分がPOとして参加してから現在までの道筋などを書かせてもらいました。

クラウドワークスでは、カルチャーをプロダクトとして見立てて、社員はそのユーザー兼開発者として、より良くしていこうという考え方があります。

カンパニーデッキより)

この日報も単なる社内ツールと捉えてしまうこともできますが、そうではなく一つの立派なプロダクトとして真正面からしっかり向き合ってPO業務をやってみました。

PO初めてだし、メイン業務のある中でやっていくのは結構大変ではありましたが、めちゃめちゃ楽しくて学びになりました。

自画自賛ですが、「日報カイゼンプロジェクト」はクラウドワークスのValueである「One CrowdWorks」「be agile」が体現されためっちゃいいチームになっていると思っています!

この記事を通して、クラウドワークスのカルチャーに興味が出る人が増えると嬉しいです。

また、新米POの試行錯誤の記録として、PO・PdMをやっている方・やってみたい方に少しでも参考になれば嬉しいです。

クラウドワークスでは、この「日報カイゼンプロジェクト」以外にも横断的な取り組みがたくさん行われており、チャレンジしたいこと、やりたいことがあれば、組織・職種問わずなんでも積極的にやっていけるような社風・雰囲気になっています。

クラウドワークスでは、さまざまなサービス・職種で社員を募集していますので、ちょっとでもクラウドワークスという会社に興味が出た方がいれば、お気軽にエントリーお待ちしております。

crowdworks.co.jp

© 2016 CrowdWorks, Inc., All rights reserved.