Lean Startup for Enterprise Meetup #2@ヤフーに参加しました
概要
ヤフー株式会社で開催されたLeanStartupの事例発表であるhttp://peatix.com/event/107678 に参加しました。 和波さんとヤフーの方4名が対談形式で話すもので、新体制になっての爆速への取り組み方について話をした。 ヤフーの方は、開発部署、開発改善部署、監査、人事の異なる4つの立場の方が参加していた。 形式としては、和波さんがヤフーの方に話を聞き、ヤフーの方が体験や考えを語り、 最後に和波さんがプロセスコンサルの立場からの話をするものであった。
今回は、最初にヤフーの方の発表内容を簡単に書き、主に対談の記録を行なう。
爆速化するときの工夫
人事的な工夫
人事制度としての工夫としては、育成の工夫と評価の軸について話があった。 育成の工夫としては、1on1、ななめ会議、人材開発会議の3つが紹介された。 1on1で上司と部下の定期的に面談し、部下が育つように促す。ななめ会議では、部下が集まって上司について考えてフィードバックする。 人材開発会議では、近い上長が集まり、組織を超えて部下の成長のために議論する。
評価の軸としては、ビジョンに対してどの程度一致しているかという振舞いのものと、事前に立てた目標に対してどの程度達成しているかを 確認する。目標に関しては、上長と相談して柔軟に変更することで、「目標じゃないからやらない」を防ぐ。
組織としても、サービスとラインの2つの方向でマネージャを立てた。
開発支援的な工夫
爆速化の発表がされてから、全社に爆速の仕方を伝えるまでに1ヶ月しかなかったため、1ヶ月に19回の爆速化会議を実施して対策した。 内容としては、爆速化の目的やプロセスを遅くしていることに対して議論した。原則として、上からのコンセプトと現場の意見を合致させて、 プライオリティは現場に置くことを重視した。爆速化が始まってからも、週一で爆速化賞の授与を行なったり、 グランプリなどのイベントも何度も行ない、現場に浸透するようにこころがけた。
和波さんからは、施策を決めるまでに半年かかるような企業もある中、短期間に何度もTryAndErrorできたのは素晴しいことだそう。
パネルディスカッション
- 人事 ヤフーが100名のとき働く人財開発本部 斎藤由希子氏 どう評価するかの立場
- エントリーポイントユニットのプロダクトのマネージャ 岡昌樹氏 どう作るかの立場
- 技術支援本部 三宅敦氏 どう支援するかの立場
- 内部監査室 岡田庫太郎氏 どう対外できな部分でやるかの立場
業務改善で最初に目指すところ。
僕らはどこへ向うのか→課題解決エンジン
ビジョンについて
ビジョンは抽象的すぎても、具体的すぎても難しい。 抽象的でも行動できないし、具体的すぎたら責任放棄してしまう。
咀嚼できないかった。 ユーザへ良いものを届ける非常に良い印象だった。
ライフエンジンでは、抽象的だったので少し具体的になった。
ビジョンが伝わりやすくなったから良かった。
マネジメントの仕事ってどの山に登りましょう、に正解はない。どこが人を動かすかを、探り続けることが大切。
承認フロー
和)自分達も他社と同じことができるようになったと思えるそうですが、 開放されたのは、何から開放されたのでしょうか。
マネージャ) 承認会議が多かった所から権限移譲された。 開発プロセスが12→3 一律のルール適用をやめた。
エンジニアは資料を作る時間があったら、コードを書きなさい。 作りたいものを作ってみようという文化になった。 動くものを見せることが承認になる。
監査) 前は、井上さんに正しい判断をしてもらう。 受け身的な感覚になってしまった。 自分達で判断する感覚がなかった。 しかし、発表で自分達で判断していいんだと思えるようになった。
和) 正当な評価が付いてこないとやめる。
評価
和) 負けないために爆速にする。 爆速にしたらいいの？勝たないの爆速にすることには意味がないの？ 人事ってどう評価するの？
人) 一般的には、上司が部下を評価するだけではなく、 部下も上司を評価する。
作る人と支援する人の連携
和) どう作れば良いのかを考える人、作る人の連携や話合いはったの？
技) スモールチームでコミュニケーションを増やしていこう。 バケツリレー方式で部門ごとがコミュニケーションするのではない。
作) 最初は企画って仕事を無くした。アプリ作っているんだから、みんな開発でしょ。 承認フローが無くなっていったので、プロセスの部署とはコンフリクトが発生しなかった。
和) 毎回、数字が出続けなかったら、ボーナスを心配して押し付けあいになるんだけど？
マネージャ) PVではなくDUBデイリーアクティブユーザに注力するようにしなさい。 全員で徹底的に毎日使ってもらえるようなことを考える。
和) 何をどうすればいいのか分からないときは、組織は全体最適化をし始める。 自分がどう評価を受けようという話ではなく、他と連携して全体を良くしていく。 全体最適を目指している間は、ずっと上手くいく。 部分最適すると失敗する。全員に当事者意識を持たせて。 自分達が上手くいっているかどうかを収益で評価してはいけない。 別のKPIを目指すことで、収益は後から付いてくるという指標が大切。 最終的には、収益の向上を目指しているのだが、それを目指してはいけない。
監査) 収益を追うと、焼畑になってしまって、課題解決をしなくなってしまう。 短期的に収益を目指すことで失敗してしまう。 サービスの責任者は、サービス愛を持っている人にサービスマネージャに任せる。 先になってもいいじゃない。
和) 非常に稀有な事例。やるべきことがなされていながら、忠実に業務改善をやっている自覚がない。 業務改善は、ジレンマとの戦い。 スマホへシフトしますよってことは、PCに貢献していた人は、どんな思いだったのか。 社内には、そういう思いの方は？
マネージャ) PCだけをやっている人はいるんですが、自負があったように思う。 ヤフーのTOPのPC版をやっている人は、誇りをもっている。 マスになればマスになるほど緊張するが、スマホシフトのおかげで挑戦できるようになった。
和) 増収増益を生み出している人をあるべき姿に設定することがあるが、 それが自然にできている。
質問
評価
質問「5倍失敗2倍成功って話でしたが、それまでの評価制度と比べてどうかわったか。」
旧では、チームで誰かが頑張るとフリーライドできていた。 結果で評価をされるようになっていた。 失敗をしたら、評価を甘くするわけではない。 やりきるといった場合には、評価は厳しくなるよ。
途中でも上司と相談することで評価を調整できるようにした。
和) 減点方式ではダメ。減点方式にすると人は挑戦しなくなる。 成功の反対は成功していないことで、失敗ではない
事業を止める指標
「どの時点で作る指標になるのか、どの時点で止める指標になるのか。」
マネージャ) 前者一律でやるプロセスは、今はない。 ユニットマネージャというプロダクトでの長が判断する。
まずはユーザに問う。ユーザインタビューをして、相談して、 ユニットマネージャが判断する。
撤退の基準はあって、具体的な数字は言えないが、 デイリーアクティブユーザを時間軸と成長に対して一律で決まっている。
和) AR,VRなんかも何年も戦うところだけど、 それなんか難しいですよね。 失敗している事例の方が多いのではないかと思うのではないか。
マネージャ) 組織によるが失敗も失敗として捉えるからダメなんだ。 リリースできませんでした。ってなると、 クラッカーを買ってきて、シャンパンをあけ、学べたねってしめる。
上手くいかなかったときは、良い学びをしたと考える。
和)どのくらいの額だったら、クラッカーを撃ち鳴らせるの？
マネージャ) そんなに期間は長くないので、大きい問題にならない。
マネージャ) これが大きい問題になるかっていうことは、かけた時間とお金が影響する。 だから早く切り上げること対策する。
制度への反発への対処
和)上司が評価されるってことは、反発もあると思うんだけど、どやって解決したか。
人)役職者が部下にフィードバックされることは、無かったので、心中穏かではなかったが。 どんなことを考えたか。評価の前にプレバリュー評価というのをやっている。 いきなりやって、ダメでした。ではなくって、半年のスパンだと不味いので、 プレバリュー評価で相互にコメントを書き合う。 どうして、そういう評価になったのかを話合う。本番は、その中間で 変わる努力をする。 混乱は少なかった。 その人の成長のために必要なコメントを書いてくださいと書かれているので。 悪いことばっかり書かれるのではなく、その人の強みなども書いてもらえる。
人格否定のようなことは、人事側で削除することができるのだが、 ほとんど発生していない。
和) 相手を育てるという方針が良いですよね。
企画の今の仕事
企画って役職が無くなったという話だったが、どういう役職になったのか。
誤解が無いように言っておくと、企画職は存在するが、企画と呼ぶことはなくす。 社内調整に主にリソースが使われていた。工程管理など。
承認フローが減ったので、そもそもやっていた仕事が減ったので キャリアプランを。
刺激を推進力にするには
和) 大きな改善に取りくむときって、下の人からするとまちにまった状況だったと思うが、 最初に大きな刺激を貰うと、維持することが難しくなってしまうと思う。 爆速って発表を聞いたときには、大きな刺激があった。 しかし、もう今後そんな刺激はないだろう。どうしますか。
監査) これが常に起きていたら、疲れてしまうと思う。 少し安定的に考えられるようになってきたが、また変えていかないといけないかもって 話もしている。爆速も社内で陳腐化してしまっている。組織では進化を続けている。
技) 爆速化ってのは、あの当時だからできた。そのインパクトで進めるんだという考えがあった。 そのノリで小さいことも変えていっている。次に何を出していくのかは、経営陣は考えていて、今も出している。
新たな文化が形成されて、新たな疑問や歪みは、企業として健全なのではないかと考えている。 これから会社もまた一皮剥けるのではないかと思う。
会社として、完璧じゃないところを良しとしている。 社長であってもフィードバックをもらう仕組みを作る。 経営に関しても社員はこう思っているということを伝える。 積極的にコンフリクトを起している。
和) 強い刺激から始まったことは、刺激がずっと続かないと継続できない。 今は歪みが発生している。 あるべき姿と現状さえ、自ら判断できれば、その間のギャップは乗り越えていける。 この形が形成できれば、業務改善は続けられる。
爆速の500日には、その本に書かれている。
プロセスコンサルタントとして良い思っている。 普通の会社では、1年かかります。社内でヒアリングに時間を費す。
3月、ものすごく動く状態になれば、すぐに実行して 改善を繰替えしていく。 最初の計画の正確性を求め始めると絶対失敗する。 最低限のものができるかどうかで、PDCAを回す。
学んだこと
プロセス改善するメリットは、再現力が生れること
ビジョンを共有するときには、現場がそれを元に動けるようになるものが良い。抽象的過ぎても具体的すぎても上手くいかない。
- 上が判断する仕組みにすると下が判断することを放棄してしまう
- 失敗を受容することで全体的な改善に継がる
- 局所最適されないように工夫が必要なこと
- プロセスにおいてもプロダクトを同じで不完全でも良いので早く試して改善する
必要なのは、ビジョンに忠実に考えて周りのメンバもビジョン通りに働けるように促すこと。 しかし、露骨にビジョンに対して忠実にすることは、チームの空気によっては、 他のメンバに対して息苦しく感じさせてしまうのではないかと思う。 上手く自分やメンバの評価がされるようにしたい。
経営者としてビジョンを決める場合には、現場が行動するときに、 ビジョン通りに行動するにはどっちが正しいかを判断する指標にするとよい。 そのためには、「爆速」、「課題解決エンジン」のような単語だけではなく、 爆速とは、「5倍失敗して2倍成功するために10倍挑戦すること」などのように 定義して伝えることが大切だと感じた。
