和波さんとヤフーの方4名が対談形式で話すもので、新体制になっての爆速への取り組み方について話をした。異なる4つの立場の方が参加していた。最後に和波さんがプロセスコンサルの立場からの話をするものであった。今回は、最初にヤフーの方の発表内容を簡単に書き、主に対談の記録を行なう。人事制度としての工夫としては、育成の工夫と評価の軸について話があった。1on1で上司と部下の定期的に面談し、部下が育つように促す。ななめ会議では、部下が集まって上司について考えてフィードバックする。人材開発会議では、近い上長が集まり、組織を超えて部下の成長のために議論する。目標に関しては、上長と相談して柔軟に変更することで、「目標じゃないからやらない」を防ぐ。組織としても、サービスとラインの2つの方向でマネージャを立てた。爆速化の発表がされてから、全社に爆速の仕方を伝えるまでに1ヶ月しかなかったため、1ヶ月に19回の爆速化会議を実施して対策した。内容としては、爆速化の目的やプロセスを遅くしていることに対して議論した。プライオリティは現場に置くことを重視した。グランプリなどのイベントも何度も行ない、現場に浸透するようにこころがけた。和波さんからは、施策を決めるまでに半年かかるような企業もある中、短期間に何度もTryAndErrorできたのは素晴しいことだそう。業務改善で最初に目指すところ。僕らはどこへ向うのか→課題解決エンジンビジョンについてビジョンは抽象的すぎても、具体的すぎても難しい。抽象的でも行動できないし、具体的すぎたら責任放棄してしまう。ユーザへ良いものを届ける非常に良い印象だった。ライフエンジンでは、抽象的だったので少し具体的になった。ビジョンが伝わりやすくなったから良かった。マネジメントの仕事ってどの山に登りましょう、に正解はない。どこが人を動かすかを、探り続けることが大切。開放されたのは、何から開放されたのでしょうか。承認会議が多かった所から権限移譲された。一律のルール適用をやめた。エンジニアは資料を作る時間があったら、コードを書きなさい。作りたいものを作ってみようという文化になった。動くものを見せることが承認になる。前は、井上さんに正しい判断をしてもらう。受け身的な感覚になってしまった。自分達で判断する感覚がなかった。発表で自分達で判断していいんだと思えるようになった。正当な評価が付いてこないとやめる。負けないために爆速にする。部下も上司を評価する。スモールチームでコミュニケーションを増やしていこう。バケツリレー方式で部門ごとがコミュニケーションするのではない。最初は企画って仕事を無くした。アプリ作っているんだから、みんな開発でしょ。承認フローが無くなっていったので、プロセスの部署とはコンフリクトが発生しなかった。PVではなくDUBデイリーアクティブユーザに注力するようにしなさい。全員で徹底的に毎日使ってもらえるようなことを考える。何をどうすればいいのか分からないときは、組織は全体最適化をし始める。自分がどう評価を受けようという話ではなく、他と連携して全体を良くしていく。全体最適を目指している間は、ずっと上手くいく。部分最適すると失敗する。全員に当事者意識を持たせて。自分達が上手くいっているかどうかを収益で評価してはいけない。別のKPIを目指すことで、収益は後から付いてくるという指標が大切。最終的には、収益の向上を目指しているのだが、それを目指してはいけない。収益を追うと、焼畑になってしまって、課題解決をしなくなってしまう。短期的に収益を目指すことで失敗してしまう。サービスの責任者は、サービス愛を持っている人にサービスマネージャに任せる。先になってもいいじゃない。やるべきことがなされていながら、忠実に業務改善をやっている自覚がない。業務改善は、ジレンマとの戦い。スマホへシフトしますよってことは、PCに貢献していた人は、どんな思いだったのか。PCだけをやっている人はいるんですが、自負があったように思う。ヤフーのTOPのPC版をやっている人は、誇りをもっている。マスになればマスになるほど緊張するが、スマホシフトのおかげで挑戦できるようになった。5倍失敗2倍成功って話でしたが、それまでの評価制度と比べてどうかわったか。旧では、チームで誰かが頑張るとフリーライドできていた。結果で評価をされるようになっていた。失敗をしたら、評価を甘くするわけではない。やりきるといった場合には、評価は厳しくなるよ。途中でも上司と相談することで評価を調整できるようにした。減点方式にすると人は挑戦しなくなる。「どの時点で作る指標になるのか、どの時点で止める指標になるのか。前者一律でやるプロセスは、今はない。ユニットマネージャというプロダクトでの長が判断する。ユニットマネージャが判断する。デイリーアクティブユーザを時間軸と成長に対して一律で決まっている。それなんか難しいですよね。失敗している事例の方が多いのではないかと思うのではないか。組織によるが失敗も失敗として捉えるからダメなんだ。リリースできませんでした。クラッカーを買ってきて、シャンパンをあけ、学べたねってしめる。上手くいかなかったときは、良い学びをしたと考える。そんなに期間は長くないので、大きい問題にならない。これが大きい問題になるかっていうことは、かけた時間とお金が影響する。早く切り上げること対策する。和)上司が評価されるってことは、反発もあると思うんだけど、どやって解決したか。人)役職者が部下にフィードバックされることは、無かったので、心中穏かではなかったが。どんなことを考えたか。評価の前にプレバリュー評価というのをやっている。プレバリュー評価で相互にコメントを書き合う。して、そういう評価になったのかを話合う。