マネージメントに必要なことは全てゲームから学んだ
この投稿は毎年恒例、pyspa Advent Calendar 2020の1日目の投稿になります。 どうもご無沙汰しております、akisuteです。すっかり年に1回アドベントカレンダーのときにだけ顔を見せる人になっておりますが、おかげさまで無事平穏に過ごしております。 さて突然ですが私はプログラマーを引退しました。 なぜなら今年で36歳だからです。プログラマーは35歳になったら定年ですね。 実際のところ、このぐらいの年になると、よほど何らかの意志が働かない限り、技術に対する情熱みたいなものが失われてくると思います。もちろん本当に技術とプログラミングが好きな人は間違いなく35歳なんかで情熱を失ったりはしないと断言しますが、残念ながら私はそうではなく、もはやiPhoneには大した興味が湧いておりませんし、最近はJavaだのGoだのTypescriptだのVue.jsだのといったものを必要に応じ
なぜSpotifyはOKRをやめた？アジャイル組織に最適な目標管理「Spotify Rhythm」とは｜加藤 章太朗
なぜSpotifyはOKRをやめた？アジャイル組織に最適な目標管理「Spotify Rhythm」とは こんにちは、加藤章太朗（@katoshow）です。 前回のnoteでは、自律分散型の組織の1形態である「アジャイル組織」について説明しました。 今回は、アジャイル組織の代表Spotifyが採用する目標管理のフレームワーク（戦略フレームワーク）についてお伝えします。 Spotifyでは、2014年まではOKRを採用していました。Googleなどで大きな成果を上げたOKRは、日本でも昨今導入が進んでいます。しかし、SpotifyはOKRをやめ、Spotify Rhythm（スポティファイリズム）という独自の目標管理フレームワーク（戦略フレームワーク）に移行しました。 SpotifyがなぜOKRをやめたのか？そしてSpotify Rhythmとはどのようなものか？について説明していきます。 ※
OKR運用失敗の3つの理由―、なぜ高すぎる目標が逆効果になるのか | Coral Capital
会社などの組織、そこで働くチームや個人の目標管理のフレームワークとしてOKR（Objective & Key Results）を取り入れている会社は増えてきていると思います。似たツールとして、MBO（Management By Objective）やKPI（Key Performance Indicator）がありますが、私の理解では以下の点で、OKRはそれぞれMBOやKPIと違います。 まず、KPIのほうは簡単です。KPIはビジネスに関係する把握すべき数値のうち、ここを注視して改善すればビジネスが成功するという指標のことです。最近SaaSで特に注目されているのは、チャーンレートとNRR（Net Retention Rate）の2つです。ほかにも、CVC、CAC、LTV、MRR、ARPU、NPSなどをモニターしているのが普通かと思います。もちろん営業部であれば売上や利益、あるいは獲得したリ
OKRは難しい｜dora_e_m
だが、その2年目の取り組みの中で「OKR-based Scrum Team」という考え方を生み出すことができた。組織と個人をつなぎプロダクトと市場をつなぐあり方として、現時点で私がベストだと考えている方法だ。これはAgile Tech Expoで話したものがYoutubeに上がっている。 というわけで、成功と挫折を経験し、自分流といえるような考え方にたどり着き、OKRについてはそれなりにわかってきたつもりだ。 それでも、3年目になっても、思うのだ。OKRは、難しい。 定性的な指標と定量的な指標の対話OKRのもつ大きな特徴のひとつが、「Objectiveは定性的、KRは定量的」というものだ。そして、個人的にはこれこそがOKRの独自性を際立たせている特徴だと考えている。 「○○をn件リリースする」「XXを完成させる」といった、計測可能で、一見悪くなさそうな目標があったとする。OKRという仕組み
自律的なチームを作るときにより効果を大きくするための教育心理学＋教育現場の動機づけ
Japan Product Manager Conference 2016のアンカンファレンスで話させていただいた内容です #pmconfjpRead less
経験の少ない技術者にどのような気付きの機会を作るべきか - Kengo's blog
チームで仕事をする上で気づきの機会を提供することが大切であると考えているのですが、では新人の技術者には何を気づかせるべきなのでしょうか。基本的には以下だと考えています。 目的を忘れないこと コミュニケーションの大切さとその理由 作ったものがどう使われるか想像する必要性 日々の学習がなぜ必要なのか、危機感を持つこと まずそれぞれについて「何に気づくべきか、なぜ気づくべきか」を述べ、次に「そのためにどのような機会を作るべきか」について述べます。 気づくべきこと 目的を忘れないこと 技術者とは技術のエキスパートであり、技術とは問題解決のための手段です。ゆえに技術者は問題解決のために自分の技術がどう活きるか、どんな技術をどう組み合わせるのかを考えなければなりません。 流行や新技術もいたずらに追うのではなく、なぜ今それが流行なのか・既存技術と比べての利点や欠点は何なのかを咀嚼し自分なりの解釈を作った
「副業マネジメントは難しい」のか？
YOUTRUSTというサービスを運営していると、副業を採用したい／したけど「うまくマネジメントができない」「管理方法がわからない」というお話をよく伺います。 弊社もまだ人数は少ない（フルタイム2名、副業3名）ながら副業の方に手伝ってもらっている中でコツではないですが、いくつか学びがあったので一つずつ共有できればと思います（主にインターネット業界における継続性のある「副業」について言及します）。 副業だからといって、一切特別扱いしない「副業だからといって、特別扱いをする必要はない」と考えています。 人間誰しも「自分がそのコミュニティの一員だと思われているのか／お客さんだと思われているのか」は認識したうえでコミュニケーションする生き物のような気がします。お客さん扱いは、いわゆる疎外感を生みます。 疎外感を感じている人は、「正社員じゃないし、ここまで言うべきではないかな…」「副業のくせに厚かまし
まあまあ複雑なシステムを少人数で開発するときにやったほうがいいと思うこと - yoheimuta’s blog
はじめに 例えば、友達 2 人でアプリを作るとか、副業やフリーランスに手伝ってもらいつつ社内で数人が集められただけの新規プロジェクトとかを想像してもらいたい。 このアプリやらプロジェクトが、大して複雑でないなら集まった個々人の能力や気合で乗り切れるだろうし、複雑であるとわかっているなら十分な準備と体制で望むだろう。 問題はまあまあ複雑な場合である。本当はまあまあ複雑なのに、業務要件や類似アプリやシステムの不十分な理解のせいで見た目の単純さに引きづられてこのプロジェクトは楽にすぐに終わると錯覚するケースを過去にいくつか、近くからも遠くからも見てきた。 これは ダニング＝クルーガー効果 のようなものである。 ダニング＝クルーガー効果（ダニング＝クルーガーこうか、英: Dunning–Kruger effect）とは、能力の低い人物が自らの容姿や発言・行動などについて、実際よりも高い評価を行って
計画性とか言う前に考えて欲しいこと：101回死んだエンジニア：エンジニアライフ
いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 なぜそのプランがうまくいかないか IT業界にいると、うまくいかないプロジェクトの話を腐るほど聞く。そういう話については、語り尽くせぬほどネットに出回っている。今更私が語ることでもなさそうだ。今回のコラムでは、IT系のプロジェクトでなぜうまくいかないかではなく、どうすればうまくいくかということを考えてみようと思う。 と、その前になぜ計画というのを立てるのだろうか。計画を立てるというのは一つの手段に過ぎない。物事を成すにあたって、まず行動してみる、考えながら行動する、という手段もある。時と場合によって、これらを使い分けるのが最善ではないだろうか。 もし、計画を立てて行動するのが常に最善と考えるのであれば、まず行動する、考えながら行動するという、二つの手札を使わないことに
進捗管理は「遅れ」か「残り」か - 現場のためのソフトウェア開発プロセス - たかのり日記
久しぶりに記事を書くなぁ。 しばらく忙しかったので、サボってました・・・ そしたら、年が明けてしまったよ。 さて、話は変わって、私はSEPGのリーダとして、いろいろなプロジェクトの進捗を見ることが常です。 そのような中で、 「進捗は何日（もしくは、何人日）遅れ？」 と聞くことは多い。 これは、顧客からも、そのような進捗報告を求められることが多いし、WBS線表では、遅れ日数が進捗を把握する対象となるため。 でも、進捗は、遅れだけ管理していても回復しない、というのが私の感覚。 遅れだけ見ていると、遅れが拡大していることには気づきにくい。 「タスクAは、3日遅れ」という進捗状況ならば、そのタスクは3日経てば完了しているはずだが、多くの場合は完了するまでに3日以上かかる。 そのような場合、「タスクAは、あとどれだけかかかるの？」という質問をすると、3日遅れであっても「5日ぐらい」という回答になるこ
Life is beautiful: ゴール設定の際に意識すべき四つの点
会社を経営しているとしばしば「ゴール設定」の話が出てくる。会社全体のゴールであったり、グループのゴールであったり、従業員一人一人のゴールであったりもするのだが、そもそも何のためにゴール設定が必要なのかを理解せずいると、「できるだけ売り上げを伸ばす」とか「誰よりもがんばる」みたいなあいまいで抽象的なゴールを設定してしまう。 そもそもゴール設定が必要なのは、三年後とか五年後とかに会社が実現しようとしている大きな目標に向かって進む時に、その目標までの距離の大きさ故に方向を見失ったり、自信を失ったりしないためである。大きな目標に向かって、長期・中期・短期のいくつかのゴール設定をしておくことは、方向性を失わずに着実に一歩ずつ前進していくのに必要不可欠なのである。 ゴール作りの際には以下の四つの点を強く意識する必要がある。 １。ゴールは明確に定義されており、達成できたがどうかが明確に計測できるものでな
マネージャ歴10数年がこっそり教えるキャリア設計のチート方法 - 室長のひとりごち
マネージャ歴10数年…嘘じゃない。こっそり…目標設定ができないエンジニアにそっと教えている、キャリア設計…キャリアデザインの一部がその年の目標だから合ってる、チート方法…一から考えるよりは。 よし、大丈夫。 新人エンジニアはもちろん経験がない、少ないからそうだよねーとは思うけれど、異動してき中堅エンジニアでさえマネージャが指導していなかったのかと思うような目標を立ててくるケースが後を絶たない。 個別に指導するのはするけれど、こういったチートっぽいやり方があるよ、と。 そうそう、考え方だからね。具体的な目標はこれをベースに具体的に考えて。それぞれのエンジニアとしてのキャリアになるからさ。 3−5年後の自分 具体的なイメージを文字として書き起こす。自分のイラストを描いてキャプションを書いても良い。 そのときに、ロールを書くこと。ロールは役割だ。プロジェクトマネージャ、プロダクトマネージャ、マネ
「エンジニアならリモートワークは簡単だ」と思ってはいけない | おそらくはそれさえも平凡な日々
「強いチームはオフィスを捨てる」を読んだ。「小さなチーム、大きな仕事」でもそうだったが、 とにかくやって見ろ。やれば分かるさ やらない理由がない というふうにガンガン煽っていくスタイルが小気味良い。 とは言えしっかりリモートワークのリスクについても述べられていて、リモートワークは難しいなと思わせる内容でもあった。特に、メンタル面を含めた健康リスクに関しては相当気を使わないといけないように感じた。 リモートワークを実現する上で大事なポイント 個人的に大事だと思ったのが以下の2点。 信頼 自由と規律 相手をとにかく信頼して、自由と裁量を与える。 信頼された側は信頼に応えようとする。ただ、自由を与えられた場合に上手くいかないことがある。そこで、決まりをお仕着せてしまうのではなくて、本人が規律を決めるようにする、それまで待つのが大事なのだろう、と感じた。 例えば、始業時間は会社が決めるのではなく、
自走するチームづくりをサポートするときのパターンぽいもの - Mitsuyuki.Shiiba
プロジェクトデザインパターンを読んだ。内容は企画に携わる人向けなんだけど、ちょっと言葉を変えると、エンジニアとしても「わかる！」って感じで読んでてワクワクした。良かった。 ということで「そういえば、チームづくりのサポートをするときに、ある程度パターン化してるものが僕の中にもあるなー」と思ったので、それっぽく書いてみる。 立ち止まる時間 やることが多すぎてチームが疲れている。 その状況において 少しでもタスクを早く終わらせてチームに余裕を作りたい！と、手が空いたメンバーに対して五月雨式にタスクをアサインしていると、メンバーは終わりが見えなくて疲弊してしまう。そして、効率良く作業をするほうが損をしているように感じてしまう。 そこで 5または10営業日の短い期間で区切り、その期間で終わらせるタスクを前もって共有しておく。その期間の終わりにはチームで時間を取って、何を終わらせることができたかを振り
『知的マネジメントの技術』のすすめ | タイム・コンサルタントの日誌から
梅棹忠夫・著「知的生産の技術 (岩波新書)」は、学生時代に読んでもっとも影響を受けた本の一つだった。この本を読んで初めて、“知的生産”という概念を学んだ。そして、知的生産のために『技術』が存在するのだ、とのメッセージは鮮烈だった。知的生産とは、自分の目的意識を持って学び、考え、書く（表現する）ことである。学ぶと考えるの間には、情報を蓄積し、整理し、また自在に組み合わせるための、いわば情報のハンドリングがある。この本は情報のハンドリングを中心に、学ぶ・考える・書くためのいろいろな技法を、著者である梅棹忠夫氏自身が苦心しながら発明していくありさまが書かれている。 もともとこの本の存在を知ったのは、受験生のときだった。通信制の受験講座で送られてくる冊子に、解答・解説や順位発表の他に、受験生からのＱ＆Ａのコーナーがあった。そこに、“試験まであと３ヶ月を切りましたが、急に東大に行きたくなりました。勉
VOYAGE GROUPの『公開技術力評価会』に行ってエンジニア評価と給与設定について本気出して考えた - Hack Your Design!
人の評価は難しい 納得感のある評価 技術力評価会 定量化しない オープンな評価 揚げ足取りをしない 複数人の専門家による評価 社外評価者 ビジネス指向 エンジニアの評価制度の設計と導入 ランクと給与をマッチさせるべきか？ 給与テーブル 市場価値で給与を決定 人を正しく評価する社会であってほしい 参考文献 先日VOYAGE GROUP エンジニアの公開ガチ評価会というイベントに行ってきた。イベントの細かな内容まとめは他の方のブログに譲るとして、エンジニアの評価についていろいろ考える良いきっかけとなったので書いてみる。 人の評価は難しい （エンジニアに限らず）人の評価は難しい。自分も人を評価する立場になって改めて思う。 付与できる昇給額やインセンティブに対して使える原資は限られている。加えて、本人の高い自己評価に対して組織の求める期待値との乖離や、他のメンバーとの相対評価の間にミスマッチがある
チームファーストがプロダクトを殺す。｜市谷 聡啓 (papanda)
プロダクトづくりには2つのモードがあると思う。チームファースト(Team Fisrt)と、プロダクトファースト(Product First)。チームファーストは、チームとしての状態がより良くなることに重きを置き、その基準でプロセスや活動、評価、時間軸の最適化を行う。 一方、プロダクトファーストは、成果を重視する。具体的にはプロダクトの開発だったり、事業としての目標達成を活動の中心に据える。もちろん2モード間でゼロイチということではなくて、判断基準をチームとプロダクトのよりどちらに置くのかという考え方である。 まず一つの結論として、2つのモードの間でどちらかが正義で、一方がダメだとかそういう捉え方ではなくて、どちらも局面によって必要になる。何らかのプロダクトを軸に事業をスタートアップしようとする局面なら、まずはプロダクトが無いと始まらない、プロダクトファーストを取る場合が多いだろう。あるいは
スクラム・OKR・ホラクラシーによるデータサイエンスチームの運営方法｜masa_kazama
Ubieの2020アドベントカレンダー5日目の枠です。Ubieのデータサイエンスチームの取り組みについてご紹介できればと思います。 イントロUbieのデータサイエンスチームは、2020年に社員が2人から8人へと増えました。チームとしてデータサイエンスのプロジェクトを進めていく上で、目標管理にOKR、開発プロセスにスクラム、フラットな組織実現のためにホラクラシーを導入して試行錯誤しながら生産性をあげようとしています。チームにマネージャーは存在しておらず、メンバー一人一人がアイディアを出し合って運営方法を改善しています。この記事で紹介する内容もチームで取り組んできたものになります。 この記事では、具体例を交えつつどのようにデータサイエンスチームがプロジェクトに取り組んでいるかを失敗談を含めご紹介できればと思います。この記事が、データサイエンスの業務に関わるエンジニアやPOの方にとって、何かしら
【図解】現場の”よい反応”の兆しは測りにくい | サーバントワークス株式会社
習熟曲線 コンサルタント、エバンジェリストとして活動していると「改善をどう測るのか」がテーマになることがあります。いや、これは避けては通れません。測ることができないと改善が見えず、スポンサードしてくれている経営陣も耐えられませんし、現場で実践しているチームも長続きできません。 何か新しいことに取り組むときには、必ず生産性が落ちることはもはや知らない人がいないでしょう。習熟曲線ですね。 新たな取り組みによるパフォーマンスの一時的な落ち込み 何かの取り組み（プラクティスの実践でも、ツールの導入でも、教育でも）をするとそれに慣れるまで生産性や良い兆しがでるには “おあずけ” 期間があります。そして生産性は大なり小なり落ちます。落ちないことはないので、ここでは単に「落ちる」という共通認識を持つことが大切です。 どんなによい取り組みをしても、一旦パフォーマンスは「落ちます」 落ち込みを最小化 では、
非対称性の連鎖（情報→楽しさ→モチベーション）を超えていくために - yo-log
マネージャーになって2ヶ月ほど経ったが、最近思うことがあったので書いてみる。 情報の非対称性とは 情報の非対称性と調べると市場における情報格差が出てくるが、ここでは組織における情報の非対称性について話す。 情報の非対称性自体は、2者がいるとき一方が知っていて一方は知らないものがある状態のことを指す。 組織における大きな意思決定の情報は、権限のピラミッドにおいて上から下に流れる。簡単のため、経営陣→マネージャー→社員という3ステップで考える。このとき非対称性と呼ばれるのは、「経営陣が知っていてマネージャー、社員が知らない情報」、「経営陣、マネージャーが知っていて社員が知らない情報」がある状態のことを非対称性が発生しているという。 この組織の意思決定における情報の非対称性は単に伝達の途中で間違って伝わったりロストするリスク以外にも様々な問題があるのではないかと思ったことが発端である。 情報の非
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
