360度評価は多面的評価の仕組みではなさそう

360度評価ってあるじゃないですか。日本語でググると多面的評価とか出てきたりします。

いくつかの北米企業やコンサルの方に聞いてみたところでは(調査対象が偏っている可能性はあります)、360度評価の目的は、「課題のあるマネージャーをみつけること」です。つまり、部下が「あのマネージャーとは仕事しづらい」というのをフェアに報告できる制度です。もちろん部下のなかでも、仕事しやすいという意見とそうでない意見が混在する可能性も高いかなと思います。なので全員に聞く。

パフォーマンスを引き出すのがマネージャーの仕事

マネージャーの責務、会社が期待することは、部下の人たちに仕事をしてもらって、組織全体としてパフォーマンスを最大化することです。一方で、事業のトップや人事部にとって、マネージャーの評価ってとても難しいんです。うまい人は上司や人事部にはいい顔しつつ、部下にはつらく当たったりしますから。ですので、360度評価という仕組みを使って、直接情報を引き出します。

マネジメントを改善する責務がより上位のマネジメントに課せられる

課題を見つけたら、事業のトップはその課題を改善する(問題を取り除く)必要があります。放っておけば、実際に収益を上げている社員のパフォーマンスが落ちたり、辞めてしまうリスクが高まるのですから。

課題の取り除き方は、その人自体を配置転換/解雇することもあるでしょうし、再教育やメンタリングで改善することもあるでしょう。その実施責任は当該マネージャーの上司にあります。

...と理解したのですが間違ってたら教えてください

私の取材先が偏っている可能性はありますが、個人的にはとても納得しました。マネージャーは組織のパフォーマンスにとって、とても大事 .... だとすれば、きちんと課題を発見して、改善する仕組みを作るというのは、とても健全だなぁ、と思います。

間違っているかもしれないので、違うよー、って話があればぜひ教えていただきたいです。

f:id:wayaguchi:20190219065720p:image

電動スクーターシェアリング Bird と Lime

先週1年ぶりのアメリカ、1.3年ぶりのサンディエゴに行ってきたのですが、街中に見慣れないものが。キックボードみたいなこれが、電動スクーター Bird です。

f:id:wayaguchi:20180811150504j:plain

 

結構走ります。どこにモーターやバッテリーが載ってるんだかわからないくらいコンパクトなのに、25km/hくらいでるそうです。セグウェイの技術で作られているようです。


Bird

 

スマホポケモンを探すように近くのBirdを探して、筐体のQRコードを読むと、ロックが解除されて乗ることができます。

f:id:wayaguchi:20180811154234j:plain

 

こちらはもう一つのサービス Lime。後発っぽいけど自転車も探せるし、バッテリーパックが追加されていて航続距離は長そうです。こちらは免許証登録が不要です(Birdは初回に免許証の写真を送ります。日本のでOK。アメリカの免許証だとバーコード写真に撮るだけで登録できるみたい)。

免許が不要なせいか、一緒にカンファレンスに行ってた楽天の内定者の学生さんたちは「ぼくらLime派なんで」って言ってました。

f:id:wayaguchi:20180811154413j:plain

 

下りて、Ride終了!とすると課金が確定します。星が4つ以下の場合、どこがおかしかったのかを報告する選択肢が出ます。たまにハンドルのバーがぐらつくやつがあったくらいで、ほとんど壊れてるのにはあたりませんでした。(壊れているやつは使用不能ラベルになって、そもそも乗れないようです。)

f:id:wayaguchi:20180819091221p:plain

 

自分で充電を意識することはなく、アプリに出てくる各個体の電池残量をみながら、いいBirdを探します。では充電は誰がしているのでしょうか?

じつは、アプリで「充電しませんか?」というのが常に出ていて、ここに登録すると家にバッテリー充電キットが送られてくるようです。充電するとキックバックがあるのでしょう。トラックで一気に運んで充電している業者さんみたいな人もいました。  

f:id:wayaguchi:20180808214941j:plain

Birdは21時すぎは使えないみたいでした(LimeはOK)。全般的にBirdの方が先行しているのか、運転免許証登録が必要だったり(日本のでOK)、コンプラ対応が進んでいる印象です。

f:id:wayaguchi:20180819103256p:plain

 

朝、建物を出るとこんな感じで並んでます。いつのまに。
筐体が小さいので駐輪スペースが少なくてよく、しかも一人一台所有しなくていいんです。

(昼もフル充電で並んでたりします。2毛作かな。)

f:id:wayaguchi:20180805100921j:plain

 

Agile Conference でも話題でした。
カンファレンスのふりかえりのセッションで、一番よかった経験の第2位がScooter。

f:id:wayaguchi:20180806074855j:plain

f:id:wayaguchi:20180810100605j:plain

Agile2018のふりかえりでも話題に

Bird社は1.25年で評価が20億ドル。史上最速のユニコーン企業(10億=1B超え企業)になったそうです。追いかけるLime社もユニコーン企業になったそうです。

qz.com

www.businessinsider.com

 

 

全米に広がっているみたいです。東京にこないかなぁ。

toyokeizai.net

 

都市部では一気に増殖して問題になっているところもあるようです。サンフランシスコ市では一旦禁止した上で、業者を免許制にすることにしたよう。で、募集したらBirdとLime以外に10社の応募があったそうです。

 

In SF, Uber, Lyft and 10 others vie for five electric scooter permits - CNET

Twelve companies -- including Uber and Lyft -- are vying for just five permits that would allow them to operate a dockless, rentable electric scooter program on city streets, according to the San Francisco Municipal Transportation Agency (SFMTA).

 

2020年の東京オリンピックにあわせて、東京でも解禁できたらすごいですね。どうやったらいいんでしょう。

 

許可を求めるな謝罪せよの源流、グレース・ホッパー

海外カンファレンスの講演でちょくちょくでてくる軍服の女性がいる。

f:id:wayaguchi:20180819065318j:image

File:Grace Hopper.jpg - Wikimedia Commons

 

グレース・ホッパーさん。

グレース・ホッパー - Wikipedia

 

話を聞いてる英語圏のソフトウェア系の人はみんな知っているだろうけど、Wikipediaによれば、最初のコンピュータENIACを設計したエッカートとモークリーが立ち上げた商用コンピュータプロジェクトUNIVACに参加して、「機械語ではなく、英語に近い言語によってプログラミングできるようになるべきである」というポリシーのもとCOBOL作った人でもある(らしい)。

f:id:wayaguchi:20180819065526j:image

File:Grace Hopper and UNIVAC.jpg - Wikimedia Commons

 

Wikiquote によると “It's easier to ask forgiveness than it is to get permission.” 許可を求めるより許しを乞う方が容易い、と言っている。

https://en.m.wikiquote.org/wiki/Grace_Hopper

 

許可を求めるな、謝罪せよ

hyoshiok.hatenablog.com

の源流であった。

 

ちょっと補足(2020年3月7日)

「許可を求めるな謝罪せよ」 という言葉は、Agile Japan 2009 (第一回) の基調講演であったメアリー・ポッペンディークが長く働いた3Mの社是として紹介したところを、平鍋さんが逐語通訳でこう訳したのを私が聞き取っていたものです。あとでそれをちょくちょく言っていたところを、吉岡さんが拾ってくれて広めてくれた感じのものです。

この訳はどうなんだという議論もあったんですけど(私の記憶があっているのかとかもあります)、今の所まあ、この訳で悪くないんじゃないかな、と思っております。

謝罪するんじゃなくて許しを請うっていう意味だよね、という指摘ですね。

「許可を求めるな謝罪せよ」は、クリエーションラインさんのモットーになってるそうです。


デブサミ再演!クリエーションライン安田氏が語るどん底からのジョイインクジャーニー7年記

 

 

コードレビューのアンチパターン(とパターン)

@nihonbuson さんから、アジャイルでのレビューについて話してほしいというご相談をいただいた。そういえばレビューについてあまり調べたことがないし、カンファレンスでもテーマとしてそれほど聞いた感じがしない。

 森崎先生が書かれた連載が本になっていて大変勉強になったのだけど、ご本人曰くこれは設計レビューであってコードレビューではないとのこと。スプリントレビューもまた違う観点もあるかなと思いつつ、指摘のダメパターンはだいたい共通している気がしている。

 

Erik Dietrich さんの Manual Code Review Anti-Patterns という記事が出てきた。

blog.submain.com

  • The Gauntlet - ガントレット - 審査員が撃ってくる
  • The Marathon - マラソン - 長くて枝葉末節
  • The Scattershot Review - 乱れ打ち - 指摘に一貫性がない
  • The Exam - 試験 - 説明によって合否が決まる
  • The Soliloquy - 独り言 - 本当にレビューしてる?
  • The Alpha Dog - アルファドッグ - 特定の人々が牛耳って学ぶ意欲がなくなる
  • The Weeds - 雑草 - 枝葉末節に時間使う

需要あるなら、ちょっと時間とって訳したい気もします。

 

レビューといえばパターンランゲージのコミュニティの人たちは時間をかけてレビューにレビューを重ねる文化を持っていたので、参考になる気がする。文章に対して真摯で、英語圏ってそういうものかな(とういうと日本語も真摯な人がたくさんいるのでよくないけれど)。

 

と思ったら、検索順位のその下に、C2Wiki に「Code Review Patterns」というのがあった

http://wiki.c2.com/?CodeReviewPatterns

Regional Scrum Gathering Tokyo 2018 三日目(土曜日)のオープンスペーステクノロジー

RSGT2018まで2週間を切りました。今回は久しぶりに Open Space Technologyを行うのですが、全然説明しておらず、「3日目ってなにやるの?岩切さんのキーノートだけ?」というお問い合わせを複数頂きましたとのことで、遅ればせながらこちらに説明を用意しました。カンファレンスサイトには準備でき次第掲載いたします。
2018.scrumgatheringtokyo.org



オープンスペーステクノロジー

まだ議論し足りない?
聞きたいことが聞けてない?
誰かに聞いてほしいアイデアがある?

本年のRSGT3日目は、東京では3年ぶりのオープンスペーステクノロジー(OST)を行います。

Regional Scrum Gathering Tokyo 2018 - Program Schedule | ConfEngine - Conference Management Platform

 

OSTは事前にアジェンダを決めないセッションです。その場にいる人が議論したい内容を提案し、自分でセッション枠を割り当て、自己組織化でセッション表を作っていきます。OSTスクラム "ギャザリング(集まる)" の象徴ともいえるセッションの1つで、海外で行われる Global Scrum Gathering では定番となっており、近年ではさらにCSPやCSTだけが集まる前日イベントでも同様の形式が取り入れられています。実践者自らが未来を考え、同じ課題を持つ人同士が繋がりあう、この"ギャザリング"とクロージングキーノートをもって会期を締めくくります。

 

 

セッションの流れ

OSTの流れは、オープニング、ディスカッション、クロージングのパートで構成されます。(写真は Global Scrum Gethring 2014 New Orleans での風景です。)

 

オープニング: 概要説明とトピック提案の時間です

f:id:wayaguchi:20140507091030j:plain

f:id:wayaguchi:20140507091106j:plain

f:id:wayaguchi:20140507095323j:plain

ディスカッション : 各トピックのディスカッションを進める時間です。Law of two feet ( 近くに集まったら参加、離れたら離脱の自己組織化ルール ) に従って議論を進めます。

f:id:wayaguchi:20140507100233j:plain

f:id:wayaguchi:20140507095554j:plain

 

クロージング : 最後に全体で集まってトピックごとの議論について簡単に報告します。(そのままクロージングキーノートに移る予定です)

 


ディスカッションの進め方

ディスカッションのパートでは、セッション表に従ってその時間その場所に集まります。

議論の進め方の原則は以下の通りです。

Whoever comes is the right people
そこにいる人は誰でも正当な参加者です。わからないことを質問したり、知っていることをアドバイスしたり、そのトピックに集まった人たちの成果に貢献しましょう

Whenever it starts is the right time .
When it's over, it's over
スケジュール表はありますが、始める時間も終わる時間も自由です。開始時間も終了時間も自己組織化してかまいません。



Wherever it is, is the right place

場所の割り当てはスケジュール表作成時に行いますが、みなさんでよい場所を見つけたらそこが開催場所です。

Whatever happens is the only thing that could have, be prepared to be surprised!
そこで起こることが全てです。驚くようなことを知ることができるかもしれません

 

3つの役割

代表的な役割が3つあります。

Bird (さえずる鳥) : トピックを決めて議論をファシリテートする人(たち)です。もちろんその場所のは優秀なファシリテーターが他にもいるでしょうから、助けを求めてもいいでしょう。

Bee (群がる蜂) : トピックに群がる(スウォーミング)する人たちです。寄ってたかって議論を前に進めたり、建設的な提案や促しをしていきましょう

Butterfly (飛び回る蝶) : 1つのトピックにずっと居たくない人も重要です。複数のトピックを回りながら、他家受粉を促しましょう。許可をとって写真を撮るのも大事な役目です。

 

参考: Wikipedia : Open Space Technology
https://en.wikipedia.org/wiki/Open_Space_Technology

玉川憲さんのお話 - Tech Crunch Japan 2017

Tech Crunch Japan 2017 に参加してきた。2日目の最初のセッションはソラコムの玉川憲さんのトーク(聞き手は西村賢さん)で、だいぶクラウドメモ帳(Facebook)にメモったのでここに置いておきます。素晴らしい聞き手と素晴らしい答え。ありがとうございました。メモ内容の正確性は...ごめんなさい(指摘いただければ直します)。

jp.techcrunch.com

f:id:wayaguchi:20171118023204j:plain

IVSとWiLから7億調達。
起業に不安はなかった。
クラウドによって起業しやすくなった。

以前はラック立てるために一億円とか
しかし日本であまりスタートアップが出てこないという葛藤が
安川さんとシアトル出張
ビールを飲んで盛り上がる
クラウドでなんでも作れるよね。でも世間は思ってない
銀行の基幹システムとか
別れてホテルに帰ったあとねれなくて仮装のプレスリリースを書いた(アマゾンの文化
その時の名前はコネック
起きたらこれいけるんじゃないかと
朝ジャグジーで安川さんに共有
でもすぐはいけなかった
AWSでやるということもあったと思うが、AWSのユーザーとしてやった方がいいなと思った

KDDIの投資額は正確には公開してない。Amazonへの売却もありえた。キャリアかクラウドベンダーの2つの選択肢がありえた。(世界中の候補を回って) KDDIを選んだのはM&Aの後のシナジー。昨年からすでに一緒にやっていた。KDDIのIoT向けはソラコムの技術を使っていて、いち早く採用してくれた胸熱な相手。

松本さんは投資家ですが元々起業家でヤフーに事業を売却して、起業家と投資家の両方の視点でわれわれに寄り添ってくれた

5Gとかになると帯域は大きくなるが、IoT向けではそれほどいらなくてモジュールが小さくてどこにでも入るというのが重要。

多くのスタートアップで使ってもらっている。例えばファームノート。牛の胎内の体温を測る。まごチャンネルのチカクさん。おじいちゃんおばあちゃんが孫の写真を簡単に観れる。

ソースネクストの通訳端末のデモ。29800円でSIM込み。音声データをそのままクラウドに送っていて言語によって違う翻訳エンジンを使う

f:id:wayaguchi:20171118023403j:plain

IoTは無限の可能性があって、産業ごとにIoTがある。メイカーズムーブメントによって色々なデバイスがでてきて。Twitterが出てきて、みんな悔しがるみたいなことが起こるんじゃないかと。
 
 ソラコムの平均年齢は36-7。玉川さんが39の時に起業。おっさんスタートアップって言ってたら広報に言うなと言われてる。嫁ブロックはなかった。初期メンバーはほとんどが即決できなかったので、場合によっては自分も直接会って。ビジョンと、ブラックじゃないというところを説明。ソラコムは子だくさん。関東IT保険は子供の数が多くて断られたくらい。でもメンバーは未来があるから子供を産むわけだからこれを誇ろうと。ソフトウェアテクノロジーで価値を作っている会社なので。優秀なソフトウェアエンジニアかどうかはゼロイチができるかどうか。完全にフルフレックスで満員電車に乗るなと。私も乗ってない
 
テクノロジープラットフォームを作る会社でグローバルにやりたい。着実な売り上げ成長より一気に成長するスタートアップにしたかった。少人数で価値の高いプラットフォームを作ろうと。15年以上の経験があるいわゆるフルスタックエンジニアにストックオプションしっかり払って。基本的な給料はそのまま以上で入ってもらって、ボーナスはストックオプション。日本だとストックオプションの額がよくわからないけど、アメリカだとシリーズと役職で業界標準ストックオプションの数が決まっている。アメリカから入ってくる人はそれを期待してくるのでそれに合わせようと思ってやってる。額は公開していない。プライベートなことなので。
 
投資家から見るとあまりたくさん出すのは価値の希薄化になるので嫌がる。だが会社が成長するために必要なこと、といえばオプションプールは作れる。ストックオプションがないと特に海外は優秀な人材が採用できなかったと思う。日本だと理解してない人が多いかもしれない。我々は説明しようとしている。ある意味どうなるかわからないものなので細かい値はどうでもよいところがあって、それよりどれだけのスピードで成長できるかが大事。0.1ポイント増やすとかで交渉しなくてよくなった。ソラコムは2年で売却なので時間がかからなかったが長くなると疲弊してくるが、ストックオプションならそこは明らかなのでいい仕組みだと思う
 
スタートアップの技術的負債について。ソラコムはすでに10個のサービスを持っているのでそのメンテナンスが重荷になる。ソラコムでは開発と運用を分けてないので元々汚いコードは自分を苦しめるので書かない。技術的負債のお掃除の期間をとったりしている
 
アメリカヨーロッパ、シンガポールにオフィス。アメリカはオープンドアが顧客についたので立ち上がってきた。内見用の鍵のIoT。う埋め込みのチップ型SIMも。IHIはプラントに。旭硝子は労働者の移動の最適化のためのデバイスをやっている。
 
スタートアップの苦労。苦労話はずっとあるけど、自分でやってるので...。きつかった時期は何度かある。シリーズAを受けるまでは心臓が痛かった。手持ちの金でやっていたけど、資金調達できなかったらどうしようというのはあった。なので資金調達のニュースがあったらおめでとうと言ってあげたい。資金調達は何かのマイルストーン、KPIを超えてるから受けられるもの
 
私自身ここに偉そうに座らせていただいているけど、最初に西村さんに声かけた時は全く思ってなかった。昨年のTechCrunchの時はM&Aを考えてなかった。それがスタートアップのダイナミクスAWS時代に既にVCなどの人に沢山あっていたので、投資を受ける時にも初対面じゃなかった。そこは結構ポイントなのでTechCrunchなどで是非知り合ってほしい

Zero Bug tolerance (既知のバグをゼロにしてデリバリーする)

いつだったか、たぶん今年だけど、Zero Bug tolerance (既知のバグをゼロにしてデリバリーする) の話によしおかさんから「それは現実的じゃない。」という指摘を頂いた。確かに昔はやってなくて アジャイルとか CI/CD とかで変わってきたところだと思う。

むかし、半年以上のスパンで出すときは、リリース時にQAで見つかったものに重要度/緊急度の分析をして対応決める(トリアージ)が普通だった。深刻じゃないバグは注意書きしたりした。一定以上、深刻なのは小さく再リリース(HotFix)したり。なのでリリース後は結構忙しかったり。

あ、HotFixっていうのもマイクロソフトが自動アップデートするようになったWindowsの方のXPあたりから聞くようになった単語ですね(個人的にはそうだけどもっと前からあったのかもしれない)。

継続的デリバリーの世界では毎日潰してく。品質が上がったというよりマインドの問題っぽい気がする。扱うシステムの粒度が違ったり、リリースの頻度も違うんだろうけど、基本的なパスのエンドツーエンドテストを毎日やるようにしたりとかかなぁ。 

で、同じようにQAしたらそれなりに発見されるんだろうけど、問題はクラウドというオープン系では2週間も状況を固定してテストしたりできないってことかな。(だから、品質の"判定"を会議でやるのはもう無理だと思う。)

あ、昔は完全な動作確認環境も作れなかったりした。 ハードウェアがあってドライバ違いで出るやつとか。プリンタ機種依存問題とか辛かったな。仮想化とクラウドでずいぶんやりやすくなった、というのはある。

なんでこんな話を再考してるのかっていうと、Hunter の Chris Lucian が モブ始めて一年半バグが出なかったので、信頼を得て次のステップに進めた話をしてて、そうそううまくいかないプロダクトはバグ対応に自分たちが潰されちゃうんだよね、って思い出したことによる。

アンクルボブのClean Code の世界。これもアジャイルやってる人はみんな知ってると思うけど、意外と知られてなかったりするのかもしれない。きれい(Clean)といっても美意識の問題じゃないのです。ビジネス直結の話。

いまどき、リリース前のQAでボコボコ基本的な指摘が見つかるようなブロダクトに近づきたくないですよね。

 

Clean Code アジャイルソフトウェア達人の技

Clean Code アジャイルソフトウェア達人の技

 

 

 

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化