2016年8月30日、これまで2社のCTOと5社の技術顧問を経験してきた一休の伊藤直也氏による「1人CTO Night」が開催された。主催は転職サイト「DODA」を運営する、インテリジェンス株式会社。開発知識に加え、マネジメントスキルも求められるプロダクトマネージャーが最速・最高のアウトプットを生み出すにはどうすればいいのだろうか。本パートでは、伊藤氏が「チームなのに1人になってしまう問題」の原因と、解決するためのヒントを語りました。
- トピックス一覧
- スピーカー等詳細
- シリーズ
-
伊藤直也の1人CTO Night 2016年8月30日19時30分のログ
- スピーカー
- 株式会社一休 CTO 伊藤直也 氏
チームなのに「1人」になってしまう構造
伊藤直也氏（以下、伊藤） ちゃんと作っていくものやミッションと組織の構造をきちんと合わせていきましょうというのが、マネジメントの基本としてものすごく大事です。しかし、形を合わせただけでは、その通りに機能してくれないことがあります。
これはKaizen Platformにいたときにあったことですが。Kaizen Platformは内製組織らしく、さっきみたいにプロダクトマネジャーが真ん中にいて、エンジニアがいて……という構造になっていて、各ユニットごとにきちっと切ってありました。
しかし、よく見ると、各ユニットのなかではエンジニアが3人くらいずついますが、エンジニア同士があまり一緒に仕事をしていないんですよね。
そこで、エンジニアと1:1の面談をして「最近どう？」と聞くと、「う～ん、なんか最近1人で仕事している感じですね」とみんな言っていて、「あれ、なんかおかしいな」と思ったんですよ。チームとしてミッションはちゃんと持ってるのに、みんな1人で仕事してると感じている。
なぜそうなっていたのかというと、仕事をアサインするとき、PM（Product Manager）がなんとなく過去の経緯でエンジニアに「これお願いします」とアサインする構造になっていたんですね。
さっきの日経さんの兼務の話と一緒なんですけど、このPMの人が「この人が終わったら、次この人にお願いします」「この人が次に空きそうなので、このプロジェクトやってもらいます」といって、全部詰め詰めでプロジェクトを切っていくんですよ。
そうすると、PM的にはリソースを無駄なく使ってスループット（時間あたりの処理能力）が最大化されるように見えるからいいんだけど、数人のエンジニアからすると、プロジェクトが終わった瞬間に、前のプロジェクトとぜんぜん関係ないことを仕事として振られて、毎回コンテキストスイッチが発生しちゃうんですよね。
各エンジニアが仕事を始めるタイミングも、それぞれバラバラになっちゃうから、1つの物事にチームで取り組んでる……という認識ができ上がりにくい。
そこで、「これよくないね」「これだと、チームに事業のラーニング結果が溜まらないからなんとかしたい」と話をしました。
そのときは、たまたま会社の中にチームとしての会話がうまくいってるところがあったので、そこと同じ構造にしようという話をしました。そのチームの中にはリーダーシップを発揮できる人がいて、基本的にはPMとこのリーダーがよく話していたんですよね。このリーダーが、その他のメンバーを巻き込んで「どうやってやっていこうか」と話をする形になっていました。
PMが個々人のエンジニアのアサイン権限を持つのではなく、例えば、エンジニアのリーダーと話し合いながら「どうやってやっていくか」を決める構造を持っていたのと、チームのなかに業務のコンテキストが閉じやすい業務割り振り……独立性の高い業務をチームとしてミッションに持っていたのが大きかったんですよね。
その他のチームもこの構造に変えて、だんだんとチームがチームとして機能するようになっていきました。
ふだんうまくいってるときは別にいいんですけど、チームがチームとして機能してないとき、ある人が見積もりをミスしたり、思っていたりよりも大変で作業が進まなかったりすると、みんな1人で仕事してるからヘルプできないんですよね。隣の人が同じコンテキストを持ってないですし。そして、ドツボにはまっちゃうエンジニアが出てきて、けっこうしんどい思いをしてた。
隣の人がきついときにヘルプできるためには、常日頃ラーニング結果を一緒に蓄積していくのがものすごく重要なので、そういう形にしていくことをしました。
人ではなく、組織構造をコントールする
ここから言えることとして、まず1つは「マネジメントは“偶然”を期待しちゃいけない」です。組織のチーム構造やチーム活動は、偶然いい人が入ってきて、いい感じにやる気を出して、いい感じにチームを作ってくれるというのは、なかなか起こらないんですよ。
まれにそういうことはあるんですけど、マネージャーとしてはそこ頼みではよくなくて。いかにして、そういう状況を自分で作り出すかが重要だと思います。
これはすごく重要なことなんですけど、もう1つは、マネジメントの対象をきちんとコントロール可能なものかどうかを見極めることです。
個々人の意識や心がけといった、そういうものは基本的にコントロールできないものと思ったほうがいいですよね。本当は、放っておいてもチームメンバーとうまくやってほしいし、情報共有も積極的にしてほしいんだけど、チームというものの捉え方や情報共有の意識が高い・低いには個人差があります。それを「意識を高く持て！」と言っても高くならないじゃないですか。
意識はコントロールできない。でも組織構造は、当たり前ですが、いくらでもコントロールできるんですよね。だからといって、あんまりごちゃごちゃ変えちゃいけないんだけど。
基本的には、なにか会社や組織で問題が起こったときに、たとえそれが人に起因する問題でも「これはあの人ができないからダメですね」と言ってそこで議論を終わらせてしまうのではなく、常に人ではなく「構造」に原因を求めるように思考を働かせて、その構造的問題を見抜こうとするのがすごく重要です。
さっきのKaizenの例がいいんですけど。エンジニアと1on1で面談すると「1人で仕事しちゃってます」と言うけれど、「なぜ2人も3人も、同じようなことを言うんだろう？」なときに、どこの構造が「1人で仕事をしちゃってる」状況を招いているのかをきちんと探って見つけ出すのが、マネージャーとして重要だったということです。