OKRは導入しない

OKRを読み終わったので所感を。

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法

結論

OKRは導入しない。いや、OKRは導入できない。組織がMBOでやっているから。理由はそれだけ。

原田隆史監修 目標達成ノート STAR PLANNER

自分が経営する会社なら、OKRを導入しただろう。いや、OKRなんて名前はないが、既にMBOベースでOKR相当のことをやっているのでOKRを導入する必要がない。

OKRの良さ

OKRは、OKRのフォーマットに書き込み、それがいつでも見えるところに掲示しておく。ホワイトボードがあればホワイトボードに、壁があれば紙に書いて張り出しておく。

毎日、いつでも、OKRが視界に入る環境を作る。

 これはカンバンをホワイトボードでやるのと同じだ。チームは、全員が同じ物を見ていなければならない。

だから見えるところに貼っておくのではないか。

OKRの良さは、チームの目標を常時貼っておくことである。

達成されないチームの目標も個人の目標は、その多くがexcelかwordかpowerpointのフォーマットに目標を書いた後、サーバやPCのストレージの奥底に収められている。

次に見るのは早くて半年後、最悪は1年後の期末である。

そんな運用で目標が達成できるわけがない。それに気づいたから、1on1をやってメンバにリマインドしているのではないか。

ヤフーの1on1―――部下を成長させるコミュニケーションの技法

でも、毎日目標を自然とメンバの視界に入るようにできるのなら、チームの目標の達成のために活動することをお互いにフォローしあえるのなら、その時間もチームの目標達成に必要な活動に使えるではないか。

改めて何か別の活動をする必要がいらないのがOKRの良さなのだ。

MBOで十分やれる

それでもOKRには移行しない。組織がMBOを採用している（OKRを人事部門が知らないのかもしれない可能性がとても高い）ためだ。

ただ、組織がMBOを採用しているからOKRを採用しない訳ではない。

OKRではないが、OKRのようなものを実際やっているから、組織のMBOと自チームでOKRを採用するような無駄な二重管理をしないだけだ。

では、どうしたらMBOでOKRができているかに興味を持つだろう。

OKRなMBO

 年初にチームのMBOを作る。これがなければメンバのMBOに展開できない。チームのMBOに最初に書くことは、チームの存在理由を書くことにしている。

チームの存在理由は、チームが組織上に編成されたときに人事報に書かれたチームを創設したビジネス背景である。

それが存在理由。

それをチームのMBOに書く。

 そしてメンバにチームのMBOを説明したときにホワイトボードに書き込んだ様々なチームのディスカッションのスクショを撮り、チームのスケジュールに貼っておく。

このスケジュールは少なくとも週１回はチーム全員が見る。

１対１ではないが、チームのMBOがメンバの心にリマインドがかかる仕組みを作ってあるのだ。

チームのスケジュールはチームのMBOから今週やること、次回やること、その先々でやることを予定として入れておく。その予定を毎週見直し、チームとしてやらなければならないことをやるのである。

そうした繰り返しは、メンバの意思決定に反映される。メンバの行動に結果がついてくる。

だから、自分のチームにはOKRは要らない。MBOで十分なのである。

エンジニアが作るスライドが3ページ目くらいで紛糾する現象に名前をつけたい

最近、国際会議向けの資料提供の依頼があってスライドを作ったのだが、どうにもうまくまとまらない。依頼元のレビューを受けてもピンとこないようだ。

ピンとこないならそのピンは何かを話してくれればいいものだが、それはうまく言えないらしい。仕方がないので、何度か修正しては眺め、こんな感じかと見てもらうとやはり違うという。

さて、何がずれているのか。

エンジニアに資料を作らせると、いつの間にかエンジニアが読むことを暗黙に前提とした資料になっていることが多い。資料作りを依頼した側として資料確認をすると、ああ、違うよ、とすぐにわかる。

それは読み手が誰かを知っているからだ。でも、資料を作るエンジニアはそれを知らないか、伝えても書いているうちに忘れてしまっている。

結果的に、読み手がずれてしまいレビューで違うと言われることになる。

この『読み手』は何度となく言われても忘れやすいもののようだ。

ペルソナで設定したユーザがどのような行動をするかを書き出そうというワークショップをしても直ぐにペルソナのユーザ視点に切り替えることが難しいのは、そのユーザの設定と自分が違うからだろう。話しているうちに、自然とエンジニア目線に横滑りしていく。

エンジニアに限らず、人は自分が経験してきたことをベースにしか物事を考えられない生き物なのだろう。でなければ、ペルソナのユーザにスパッと視点が切り替わっても良いはずだ。それができていないのは、もちろん、そういった視点を切り替える場数で得る経験もあるのかもしれないが、そう簡単にはいかないものなのだ。

話を戻して、国際会議向けのピンがずれているのは結局、こちらが読者に当たる会議出席者のペルソナを理解できていなかったことが原因であったことに気付いたわけだが、そうした読み手に当たるペルソナが違うとどう影響するかは試作した資料を並べて眺めるとペルソナを意識してスライドを作らなければ受け入れられないということがわかる。

端的な違いを言えば、こう表現できるかもしれない。

1. ペルソナを間違えた資料は、エンジニア視点が抜けきれておらず情報過多で資料のメッセージがペルソナには理解できない
2. ペルソナを意識した資料は、（ペルソナに合わせて）資料のメッセージが概念的でシンプルである

この差は大きい。

ここまで資料の読み手をペルソナとして書いてきたが、ペルソナがわかりにくければ、役職に変えても良い。例えば、エグゼクティブが読む資料に技術的な情報をこと細かく書いても意味がない。

なぜなら、エグゼクティブは役職に応じた経営判断をするのが仕事だからだ。であれば、経営判断して欲しいメッセージを伝えなければならない。そこに担当課長レベルの資料を出しても役職に応じた意思決定をできる状態ではないから、資料の隅々を見始め、結果的に資料の不出来を指摘されるのがオチである。

それも宿題がいっぱいついて。

資料の読み手を考え、メッセージとして何を伝えるのか、それを終始忘れてはいけない（戒め）。

 これは良本だと思う。

外資系コンサルのスライド作成術 作例集: 実例から学ぶリアルテクニック

仕事の、時間の、使い方

これは悪いお手本のようなものかもしれないので、文面どおりにやっても同じように出来るかどうかは、それは貴方がこれまでどれだけ仕事を事細かくチェックされないだけの信頼を貯金してきたかに依るかもしれないし、自分のポジションと貴方のポジションの違いからかもしれないし、チームで働くメンバとの関係かもしれないので、それらの状況判断をしつつ、適宜、お試しください。

仕事8割

 自分は、あまりかっこいい話ではないかもしれないが、時間があればあるだけ仕事に使ってしまう性格のようだ。新人の頃、ひとりプロジェクトで先輩エンジニアから

『ここまでしか進捗していないのに、もう1000時間使ったのか』

 と呆れられたことがある。周りの先輩が『まぁまぁ』と割って入ってくれたのでそのまま流れてしまったが、その場面が強く印象に残っている。

仕事8割は、ご存知のグーグルの仕事の仕方に由来する。自分のメンバには

『仕事は8割で終わらせて、残りの2割を自由に使って。考えることに使って』

と繰り返し言っているが、実は自分ができていない。言わないからね。自分ができていないことは。

ただ、実際には、マネージャ業があるので仕事8割どころではない。実稼働の6割か5割かもしれない。そのくらいのリソースで出来るようにはしている。

仕事に自分のリソースを100％突っ込まなくて済むようにするポイントは、

『仕事を終えられる見通しをつけられる程度に仕事ができるようになること』

という他ない。それができるようになるためには、仕事の道筋をつけ、段取りし、必要な関係者を手配し、揃えながら1つずつ仕事を片付ける。

そういった、仕事の流れを組み立てるとき、自分の実力と仕事の難易度なり物量なりを推し量れる力を身につけなければ、いつ終わるか見極められない。

このいつ終わるか見極められるようになれるかどうか、これがミソ。

仕事中の勉強

仕事の中でアルゴリズムを調べて実装したのは勉強として扱って良いのか。機能比較をするために調査してメリデメ表を作って製品知識をつけるのは勉強と扱って良いのか。

どちらも、仕事の中でやっているのでいわゆるOJTの扱いとすればいい。OJTで今仕事で必要だからWebで調べたり、本を読んだりする。

では、それ以外はどうなんだろう。

自分は、あまり仕事の時間の中で仕事で必要ではない別の技術や方法論を調べることにあまり関心がない。

自分のパイを広げるために本を読むとか、自分が興味をたまたま持ったキーワードを勉強するのはほとんど、自分のオフの時間である。

上述の理屈（メンバへ言っていること）から言えば、同じように自分も仕事のリソース割り当てを２−3割はそっちに振ったほうがいいのだ。

ふと気づいたが、普段から作業にはアウトプットがつきものだと思っているので、そうした思考がそうさせているのかもしれない。

チーム活動

前にもエントリで書いたが、週次のミーティングを決まったテーマで使った残りをメンバに開放している。開放とは、メンバが自主的にやりたいことをやっていいということだ。メンバ全員であるテーマについて調べてみようとか、もくもく会とかしたいと言えば、それで使ってもらう。自発的な活動の中での気になるところだけ口を挟むか、キーパーソンを後で呼んで、それを伝える。

コミュニケーション

気になることはとにかく、直接声を掛ける。メールやチャットは、リマインダーとして使う。

声を掛け、気になることを確かめ、頼みごとをお願いし、くだらない話をして席に戻る。

このコミュニケーションの中に管理という概念はない。

メンバの管理

基本的にしない。

成人した大人なんだから。

やりたいと言えば『承認』の意思表示をする。やりたいと言ってきたことが手続きを考えていないようだったら、アドバイスをする。『担当のAさんに確認してから、申請処理した方が手戻りないよ』など。

事務処理能力

平社員でも、マネージャでも事務処理能力が求められる。これは組織の中で生きて行く限り必要な能力だし、個人事業主であれば、さらに重要になる。

こうしたやらなければいけない仕事（これも立派な仕事である）を諦めて、さっさと片付ける。それも何度もやり直しをしなくていいように済ませる。

そのためには、事務処理の受け手と仲良くなっておく必要があるし、仲良く頼めるフレンドリーで下手に出て物事を進めるスキルが必要になる。

ゾウの時間 ネズミの時間―サイズの生物学 (中公新書)

マンガでわかる! 幼稚園児でもできた!! タスク管理超入門 impress QuickBooks

『謎自信』を発動せよ！

ある案件での資料作りで、顧客からものすごい圧が掛かることがあった。あの圧を真面目に受け取っていたらちょっとしんどかったかもしれない。

どちらかと言えば、顧客からの圧よりは、資料の締め切りの方が自分としてはとてもプレッシャーを感じていたのだ。

顧客が圧を掛けてくる言い分（想像）

資料のコンテンツ自体は、あなた（自分のこと）で担当している領域の今後についてである。 であれば、どうしていくのかはあなた自身が一番わかっているだろう。

よって、あなたが資料を書くのが一番の適任者だ。

それを聞くひとはこんな人達だ。それを念頭に資料をまとめて欲しい。

こちらの言い訳（言わないけど）

 先に書いておくが、顧客との関係は悪くはない。冗談を言える間柄だし、ロジックを持って話せば理解してくれる。

それにコンサルティングのようなものだし、領域の範囲内なので契約上問題ない。

ただ、顧客が変わっていることには変わりはない。

ただ、それを言うと『お前が言うな』と言われそうだが。

で、である。

資料の範囲が広く、それに関わる関係者、ステークホルダーが多い。多過ぎる。それに加え、今後のことはザクっとは決まっているが、まだふわふわしている個別テーマばかりだ。

それをどう計画作っていくか…である。その状態でオーダーされた資料のレベルが高過ぎた。

資料のレベルが高いと言うのは、より概念に違い（詳細な実行計画のようなものではない）と言う意味合いで、である。

『謎自信』発動。

 生命に危機を及ぼすような資料ではない（今後の個別テーマである意味、生命に少しだけ危険が及ぶ可能性は否定できない）のである。

多くの場合、生命に関わることはほんの一握りしかない。これを意識できるようになると仕事はとても楽になる。

それに自分ひとりで仕事をしようなんて思わなくなる。結果的に、正しい人を巻き込み、助けてもらうような仕事の仕方をするようになる。

個人の、自分自身の顧客からの評価はさておき（今更感はある）、命に別状がないなら、求められる品質を備えたアウトプットをすればいいだけである。

それに、過去の案件の方がマジでやばかった。そこまで閾値に迫っていない。

それにその過去案件を思って計画した通りにやり遂げたのである。

これが『謎自信』である。

謎自信が発動すると、顧客から出来はどうかと聞かれても『大丈夫ですよ』『まー、心配しないでください』と平然と言える。

締め切りは気になるが、顧客を巻き込み切れているので最後は『じゃあどうしたいのか』と踏み込めばいい。

若いエンジニアと仕事の進め方やタスクのアサインを受けたいかどうかを話すとき、やはり『謎自信』を発動してくることがあるが、それはその自信がどこからくるかを確かめると裏がないので『若さ』が自信の源泉であることがわかる。

それはそれでいい。

一方、こちらは経験に基づく『謎自信』である。

格が違うのだよ、謎自信の。

小さなことに左右されない 「本当の自信」を手に入れる9つのステップ

10代のうちに知っておきたい折れない心の作り方

チームの役割は冗長化しなければならない

プロジェクトチームを作るときに欠かせないことの1つに、分掌、役割分担を決めることである。

プロジェクトチームは、機能組織である。ある目的を達成するためだけに作られた組織であるから、その目的を達成するための機能を有していなければならない。

その機能をチームの役割に割り当てる。

ここで勘違いしてはいけないのは、役割に機能を割り当てるのであって、人に割り当ててはいけない。人に割り当てた途端、属人化が急速に始まるためである。

役割に機能を割り当てると、役割のポジションに人を置くとき、役割として必要な機能をこれから割り当てようとする人が持っているかどうかという観点でアサイメントの正しさを評価できる。これを人をポジションに置こうと考えると、その人の評価になってしまう。

これを取り違えてはいけない。

ところで、機能を役割に割り当てるとその機能の役割に支障が起きた場合、SPOFになってしまう。そうならないために、階層化の形態を取り、上位者によって冗長化を図る。

この例でわかることは、上位者は配下の機能も理解し代替できなければならないということである。

役割の冗長化は、小さなプロジェクトチーム、ワークの高速化を考えるチームには必要な考え方である。小さなチームは人ひとりがチームに占める割合が大きなチームよりとても大きくなる。

つまり、小さなチームになればなるほど、SPOFが高まる。トラックナンバーが１に近く、というのと同じである。

だから、技量の程度の違いはあるにせよ、役割の冗長化に取り組まなければならない。その取り組みにより、冗長化が進み、仕事が止まらないチームが出来上がる。

止まらないということは、仕事の平準化が何かしら利くということでもある。そして止まらないため、継続してアウトプットされる。

こうした考え方は、何も小さなチームの専売特許ではない。大きなチームのブロックでこの考え方を取り入れれば良い。大きなチームの中にあるブロックのチーム全てが冗長化を進めるとき、大きなチームは大きいままで止まらないでアウトプットが続けられるようになる。

チームの役割は冗長化しなければならない。

Spof the Andes

エンジニアが悩んでいる時にブレークスルーする方法

カンファレンスで自分の講演やワークショップをするときは、前後の時間はこれまで講演者の控え室にいることが多い。スライドを見直して、話す内容を心に留めたりして時間を潰しているわけだ。

終わったら終わったで、一仕事終えてぐったりとして何もする気になれないのでやはり控え室で甘いものでも口にしている。

ところが、あるカンファレンスでワークショップが終わった後、知り合いの方がワークショップをするのを思い出して、それに参加しようと思った。

珍しい。

ワークショップの内容は、今市場に出ているいくつものプロダクト集め、それぞれのプロダクトで想定している顧客セグメントとしている設定が、それが本当にそのセグメントで良いかを評価して欲しいというものだった。また、イチ押しのプロダクトを選んで欲しい、とオーダーがあった。

気楽にやって欲しい。そういうことで、プロダクトに触れてみて、依頼されている内容を評価票に記入していく。

終わった翌日、ふと、これは現状に対する疑問（上記の場合は想定している顧客セグメントが実は違うのではないか）があって、それを自分だけで判断せず、想定しているセグメントの顧客に評価させてしまえばいいと思い至ったのではないか、と気づいたのだった。

エンジニアが仕事をしているとやっていることが正しいかどうか、進む方向がわからなくなるときが多々ある。それは、エンジニアの仕事が決められたプロシージャで決められた通りに処理すれば片付く仕事ではないからだ。

そうしたとき、上記のように早い段階で、実験をしてみるのが良いのだ。実験といっても選んでもらうとか、行動として現れる方法を取ればいい。

実験で得られた結果は、1つのサンプルでしかないから、それが神様というわけではない。それは注意した方が良い。

ただ、実験をしなかったら、気づくことができないことに気づけるだろう。それを実験しないでて早くやりたければ、いくつも視点の違う帽子を自分で着替えられるようにスキルとなりきりに必要なペルソナを持つことだ。

それはそれでそこにたどり着くまでが大変なので、聞いてしまった方が手っ取り早いのである。

この手っ取り早く聞いてしまうも、実際は、1人でくよくよ悩む時間は何も得られないので、それを止める方法が聴く、ということだけの話なのである。

ブレークスルーする方法なんて実は大したことではない。

スラスラ読める Excel VBA ふりがなプログラミング (ふりがなプログラミングシリーズ)

10年続けられる技術テーマを持つということ

 カンファレンスや研究会の後に懇親会が開かれると基調講演された登壇者やゲストが招かれる。運営は時間枠の都合で質疑を切らざるを得ないので、その場で出来なかった質問や個人的なリレーションはそちらでと誘導し、懇親会も賑やかさをキャリーするように促す。

そういった登壇者の多くは、講演で取り上げたコンテンツや経験談の背景にある経歴は10年単位である。

そう、10年もの間、どういった巡り合わせで興味を持ったのかは講演者それぞれだろうが、10年もの間続け、その界隈で自分の考えを発信したり、わからないことを先人に尋ねているとそうした先人に目をつけられ発信を求められ、結果的にその分野で一定の認知をされることになる。

そういった方に懇親会で10年続けることについて伺うと、ほとんどの方が視線を上に伸ばしつつも、謙遜しながら、感慨深く様々な経験を語ってくれる。

先日もネットでは名前だけを認識していた（いや、以前にどこかでパネルディスカッション的なものをみたことがあるかもしれない…）方が基調講演で話される機会があった。

カンファレンス後の懇親会で名刺交換後、10年続けることについて話を聞くと『10年続けられるテーマに出会えて幸せだ』と話されていた。

講演を思い出すと、スライドには多くの情報があるが、10年続けてきた過程の中で、ただ、一方的に情報を得るばかりではなく、集めた情報を整理し、整理した情報から特性を見出し、仮説を立て、検証していく様が見えてくる。

その分野で10年続けられているエンジニアの方々は、10年もの間、研究をし続けているといってもいいのかもしれない。その研究の節々で声が掛かり、成果発表されることでそれが専門でない自分のような一兵卒のエンジニアの視界に入り込み、認知されるのだ。

10年続けられるテーマを見つけられること、それ自体が幸せだといっていたが、それを見つけられるかどうか、それもまたエンジニア自身が何に関心を持つかエンジニア自身に委ねられているのである。

あなたはエンジニアとして続けられる研究テーマをお持ちだろうか。

マンガと図解でスッキリわかる プログラミングのしくみ