全員が“勉強マン”でなくていい--伊藤直也が説く「多様性ある組織の強さ」

「プロジェクト管理のための管理」は意味がない

質問者9：自社サービス開発に携わっています。チームの成長を開発速度で見られたらいいなと思っています。開発の速度を定量化できたらいいなと思いますが、何かいい指標はありますか？ もしくは同じことを考えたことありますか？ ベロシティはプロジェクト、チーム構成で定まらないので難しいなと。

玉川憲氏（以下、玉川）：チームの成長を開発……。

伊藤直也氏（以下、伊藤）：僕、こういうのあまり得意じゃないんですけど、スクラム的なベロシティみたいなのをやっています？

玉川：ベロシティ、やっていますね。最近、ベロシティ的にデータを取り始めているんですけど。どちらかというとチームの人数も多くなってきたので、こういうことも。

でもこれ、あくまで気をつけないといけないのが、決して相対的でしか見られないんですよね。絶対値ではないので、「ベロシティ100が偉い」「200が偉い」じゃなくて、「先週90だったのが100になったのがいい」ということなので。そういうかたちでは見られるんじゃないかな、チームの成長を開発速度で。

チームごとに比較したいということなんですかね？

伊藤：それはスクラムをきちんとやって見積もりをして、それに対してどれくらい成長したかのベロシティを取ったりという、いわゆるそんなことやったり？

玉川：そういうことです。いわゆるストーリーにもポイントつけて「それをどのくらいこなせたか？」みたいなやつですね。

伊藤：えー、ちゃんとやってます？

玉川：ちゃんとはやってないです（笑）。「ちゃんとはやってない」と言ったら変ですけど、「プロジェクト管理のためのプロジェクト管理」になると、あまり意味がないと思っていて。

伊藤：ないですね。

玉川：こういうのを見ることで気づきを得られるというか。「この人に負荷が集中しちゃっている」「これは明らかに、どうやっていてもここのイテレーションで入りきらないよね」とか、そういう気づきレベルの話ですよね。

だから、もちろん定量化ベースなんだけど、どちらかというと定性的な判断するための指標レベルですかね、僕らがやれているのは。

伊藤：僕はここパスですね。苦手です。

全員が「勉強マン」でなくていい

質問者10：技術力を上げていきたい場合、どうすればいいでしょうか？　古いやり方に固執して会社として成長していきません。決して学ぶことが嫌いというわけではないようですが、新しいことにチャレンジすることが苦手な人が多いです。心理的ハードルを下げ、組織として学習意欲とチャレンジ精神を養っていくよい方法はありますか？

伊藤：ああ、これね。これは僕、けっこうはっきりとした意見がありますね。

玉川：はい、どうぞ。

伊藤：いいですか？　先にどうぞ。

玉川：直也さん主役なので、どうぞ（笑）。

伊藤：僕は、最新技術を学びたいエンジニアは全体の中の一部で構わないと思っているんです。

「React.jsが……」「Dockerが……」など、あるじゃないですか？　インターネットを見てるとああいう人……たぶん僕もその1人ですけど、そういう人ばかりが目立つので、あれがエンジニアのあるべき姿だと思われているところがあります。でも、絶対そんなことなくて。そういうエンジニアも会社にいないと、新しい技術やツールが導入されていかないんで大事は大事なんです。しかし、それがすべてかというと、そんなことは絶対ない。

業務知識として、すごくドメインの知識が豊富で、難しい業務でもきちんとシステムに落とし込んでてくれる人も必要だし。あるいは、最新技術は学んでいないけどアルゴリズムやデータ構造、コンピュータサイエンスなど、そういう古典をよく知ってるみたいな人もいるし。「ワーク・ライフ・バランスを重要視して、プライベートではそういうことやりません」でも、仕事はとてもスムーズ……という人もいるんですよ。それをすべて「勉強マン」にするのは、あまりよくないと思っていて。

基本的に、組織は多様であるほうが、全体としては強いんですよね。同じような考え、同じようなことをしている人たちでそろえると、だいたいなにかあったときにうまくいかない。Reactマン、Dockerマンみたいな人ばかりいると、なにかすごい無駄にテクニックを使ったシステムになるんだけど、やたら複雑でぜんぜん問題解決しないことが起こるんですよ。

そういう最新技術が云々は、やりたい人が一部でやればいいというのが、僕の正直な感想です。勉強マンは個人の生存戦略としてはありだと思いますが、組織論においては、個々人の価値の出し方は人それぞれであるべきですよ。

玉川：確かに。私もそれに近いですかね。とくにスタートアップなので、生き残らないといけないじゃないですか？　

僕、よく漂流船という例えを使うんですけど。いくばくかの食料が残っていて、これでこのチームの人数が乗っていると半年後に死にます……と。でも、宝島に着いたらハッピーです、という状況なんですよね。そのときに、みんなが「新しいことやりたいマン」だと、絶対に無理で。

それぞれに役割はある。さっきのサッカーチームに近いですよね。もちろん、新しい技術をやりたい人はすごく貴重なので、そういう人もいてしかるべきだし。そうじゃなくて、すごく泥くさいんだけど、大事な課金システムやオペレーションの仕組みも大事なので。

伊藤：そうですね、そういうの、すごくあるので。一休の場合は新しいことが好きな人がけっこういるので、その人たちには技術基盤をやってもらって、そうじゃない人はそうじゃないところで活躍してもらって。

玉川：だから、マネジメントというよりはポートフォリオの問題なんですよね。新しいことをやるポートフォリオとそうじゃないという。そこのバランスなんですかね。

伊藤：そうですね。あとは根本的な話なんですけど、さっきの本にも書いてあるんですけど。

ちょっと精神論的なんですけど、結局リーダーがやっているかどうかがほぼすべてなんですよ。リーダーシップをとっている自分が、コツコツ努力して新しいことを学んでやっていれば、周りの人は勝手にそれをまねしていく。それ以外に学習意欲などをコントロールするのは、基本的には難しいじゃないですか？

玉川：確かに。日々、当たり前のように、空気の中でということですね。それをやっているか・やってないかを、みんな見ていますと。

伊藤：ここは、あまりこの状況を悪くとらえずに、今あるカードをどう組み合わせればきちんとした組織になっていくかと考えたほうがいいかなと僕は思います。

玉川：ありがとうございます。

「1on1の頻度問題」に正解はない

伊藤：スライドによる質問が終わりましたね。

玉川：会場から質問いけるかな？　これ、予想外にうまくいきましたね。

じゃあ、会場からご質問はありますか？　ぜひ。

（会場挙手）

伊藤：じゃあ、向こう側の方、どうぞ。

質問者11：組織の状態によると思うんですけど、1on1をどのくらいの頻度でやっているのか、そういうのを知りたいなと思いました。

玉川：1on1の頻度問題です。

伊藤：うちは基本的に1ヶ月に1回くらいやっているっぽいです。僕はあまり頻度を決めていないんですけれど。

玉川：組織のフェーズや状況にもよりますよね。

伊藤：やはり、問題をたくさん抱えているときは頻繁にやったほうがよくて。

玉川：頻繁にやったほうがいいですね。

伊藤：そういうときは、ヘタしたら週1でやったほうがいいし。あと、見られる人数にもよりますね。3人や4人くらいのチームで、自分のチームに3人だったら、毎週やってもいいし。

玉川：そうですね。

伊藤：僕、昔は1週間に1回ペースでやってたんですけど、話すことなくなるんですよね（笑）。なんか、1on1の相手に言われてました。話すことなくなってきて、「じゃあ、雑談しようか」と言って、Webの最近あったなにかおもしろいできごと、「なんかコードレビューの話で盛り上がってたね」と話していると、「もうこれはなんかRebuild.fmみたいですね」と言われて（笑）。

（会場笑）

そうなってきたら、あまりいらないですね。隔週とか。

玉川：そうですね。

質問者11：少なくとも月1？

伊藤：なんか、別にあまりそういうのがなくて。正解はないですね。

玉川：実は、僕は2つ前の会社だと週1やってましたね。前の会社だと1ヶ月に1回くらい。今、うちはやってないですね。なぜかと言うと、コミュニケーションがとれているので。あまり不安に感じない。

伊藤：いや、意外とそれやると何か出てくるんじゃ……。

玉川：今日、帰ったらやってみます。

（会場笑）

伊藤：僕は本当に本末転倒にならない頻度というのが重要かなと。1on1マンみたいになっちゃうと。

玉川：そうですね。じゃあ、次。

（会場挙手）

人事的な話をするミーティングを限定する

質問者12：ヒューマンマネジメントのところで、「人の問題は意識を強く持っていかれる」ということ、すごいあるなと1人でうなずいていたんですけども。

「誰かやばそうだ」「リタイアしそうだ」などに対して、時にはドライに気持ちを切り替えることが必要だと思うんですけど、実際すごく難しいと思うんですね。マネージャーが切り替えるためのコツ、あるいはチームをあえてドライにするための仕切りなど、そういうのがあれば、ぜひ教えていただきたいです。

伊藤：なるほど。

玉川：今の話は、辞めさせなきゃいけないとダメで……？

質問者12：辞めそうだとか……。

伊藤：途中で話した、なにか「人が辞めたい」という話が組織にポーンと出てくると、突然それが最大優先度になるじゃないですか？　そういうときにそればかり話していたら、大事なこと話さなかったみたいなことが起こるよねという話なんだよね。

だけど、「人が辞めたい」みたいなショッキングなニュースはどうしてもみんな気を取られちゃう。それに気を取られないように冷静に判断するにはどうしたらいいですかという。

玉川：難しいですね。なにかありますか？

伊藤：どうしたらいいんだろう？

玉川：ある種の儀式的なものも必要ですよね。儀式、セレモニーと言ったらあれなんですけど、きちっと送り出してあげるとか。

伊藤：辞めるときはね。でも、それは辞めると決まった後じゃないですか？　今の質問はそうじゃなくて、辞めそうみたいな。

玉川：辞めそうな感じのときですか？

質問者12：辞めそうな感じ。

伊藤：辞めそう、悩んでいるとか。

玉川：確かにそのことがあると、けっこう頭の一部分が引っ張られますからね。

伊藤：あまりばっちりとした答えないな、これ。1番は、僕らもチームで意識してやっているんですけど、マネジメントが集まる会議でそういう話するんですよ。「誰それさんが辞めそうだ」の話。

とはいえ、「辞めそうだ」の話は、基本的にはアジェンダの1番最後に持ってきていますね。だから、事業の話やプロダクトの進捗、あと組織の転換時期など、そういう話を先にして、人の話は1番最後に持ってくる。そういうことで、必要以上に時間使わないようにしています。

玉川：そうですね。どうするんだろうな。どうしていたかな？　

でも、辞めようという方向性にもよりますよね。送り出してあげたいようなときと、本当に後ろ向きなときで、だいぶ違うような気がしますけどね。

送り出してあげたいときは、そういうふうにチーム全体を持っていったほうが絶対いい。ある意味きちっと送ってあげたり、いい方向で転職していったりとか。

今後はどんどん市場全体も、当たり前のように会社を移っていくというような時代になっていくので、そういう方向の切り替えというのは1つ、あると思います。

伊藤：ただ、退職の話に絞っちゃうとそうなるんですけど、基本的に人の話は……。うまい言葉が見つからないですけど、ある意味でおもしろいんですよ。

玉川：そういう話ばかりしちゃうということね。

伊藤：だから、「誰それさんがイケてない」「あいつがこういうことで悩んでる」「辞める」みたいな話で、本当にうまく言えないけど、興味のアテンション的にすごく引っ張られる……。たぶん、おもしろいんでしょうね。

玉川：だから、その観点で言うと、人事的な話をしていいミーティングは限定するというのはありますね。僕らはあえてそうしてましたね。ふだんのマネージャーミーティングでそういう話はしないので、本当に。レビューなど、そういうときにしかしないというのはある。

伊藤：そういう話をしたいのをグッとこらえるみたいなのは、マネージャーの心持ちとしては大事だととりあえず思っておくというのが前提としてありますね。

玉川：そうですね。

伊藤：すみません。こんな感じで。

玉川：こんな感じで大丈夫なんでしょうかね？

質問者12：はい。

信頼を得るには、地道にやるしかない

玉川：あと、もう1問くらいですかね。

（会場挙手）

伊藤：じゃあ、そこの方。

質問者13：ありがとうございます。先ほどの伊藤さんの話の中で、「『こいつが言うなら大丈夫』というような信頼を勝ち得ることが重要」という話があったと思うんですけど。例えば、新しい環境に行かれたときに、伊藤さんが信頼を勝ち得るために……。

伊藤：（笑）。

質問者13：どういうことするのかみたいなことはありますでしょうか？

伊藤：僕、ずるいんですけど、なんで一休入りを「わかりました」と言ったかというと、信頼関係を勝ち取っていたからなんですよね。まったく新しい会社に入るとそこを苦労するから。一休は顧問を2年間やっていたので、多少はそこをゲタはいた状態で始められるかなというのはありました。

まったく新しいところ……。それだと時間かかるでしょうね、基本的に言うと。でも、やはり一休に入ったばかりのころと、入って半年くらい経った今とではだいぶ経営陣のほかのメンバーからの信頼を、自分で話していても感じるんですよね。最初のころは「エンジニアを増やしたい」と言ったら「えっ!?」という顔されてたんですけど、今は「確かに」という感じで。

こればかりは、地道に積み重ねるしかない気がします。とにかく対立構造に持ち込むのだけはやめる。それくらいですね、すみません。

質問者13：ありがとうございます。

会社は“外の人”の言うことを聞きやすい

玉川：もうひと方。さっき手を挙げてたんで、いけるかもしれないですね。最後、せっかくなのでぜひ直也さんに。

質問者14：ありがとうございました。「問題にフォーカスする」というところで質問したいんですけれども。今、最初に対象とされた組織規模より、自分は大きいところにいると思っているんですけれども。それだと、やはり組織でチームごとにやっていることが細分化されすぎていて、自分のチームでコントロールできるものがけっこう少ない状況になっていますという。

それで、最終的に「じゃあ、リードタイム上げましょう」「開発よくしていきましょう」と言ったときに、自分の組織組織やチームでコントロールできる範囲がけっこう狭くて。

伊藤：限定されていると。

質問者14：活動をしようとしていても、けっこうグチが出てしまって、なかなか……。そういうところは置いておいて、どんどんやれるところで改善をしていきたいと思っているんですけど、かえってフォーカスしづらい状況になっています。変えなければいけないとは思いつつ、まずは、できることに適切にフォーカスしていくためのコツなどがあったら、教えていただきたいです。

伊藤：今できることをどうしたらいいかは、先ほど話したとおりなので。あまりそれ、よくないですよね。自分の手もとでできることだけで、物事を完結させるというのが。そもそもなんですけれど。

結局、その問題の最も根っこの部分の解消をせずに、脇部分ばかり芝刈りしていくということじゃないですか？　それを続けていても、けっこう疲弊するというのが正直な感想です。だけど、根本から大転換を図ろうとすると、さすがにそれも難しいですよね。どうするんだろう？

玉川：難しいですね。だから、さっきの似たようなかたちで言うと結局、経営層が技術をわかってなくて。下からどうにか突き上げていかなきゃいけないみたいなのと、かたちは似ていますよね。

自分のチームではどうしようもない、外のチーム。それを力が及ばないこととしてあきらめるのか、力が及ぶところに持っていくのか、引きずり込むのか。

伊藤：そうですね。最後に重たい質問がきちゃいましたね（笑）。

玉川：きちゃいましたね。

伊藤：華麗に答えて「ありがとうございました！」と言おうと思ったのに（笑）。

（会場笑）

玉川：すいません。モデレーターのミスですね。最後は1個、難しい質問を持ってきちゃった（笑）。とはいえ、どうしましょうか？　なにか一言。

伊藤：飛び道具としてあるのは、それこそコンサルタントというのもあるんですよね、最近でいうと技術顧問なんですけど。

「外部の人を連れてきてトップダウンで変えさせる」というのは、わりとうまくいくんですよ。会社は中の人の言うことは聞かないけど、外の人の話ということでほいほいと聞くので。それはありだけど、あまり好きじゃないですね。

すみません。ちょっとわかりません。それはたぶん、その状況にきちんとダイブして、その組織の意思決定フローなどを含めて、トータルで見たうえで「こういう道があるはずだ」と分析しないとたぶんいけなくて。一般論としてこういう方法があります、と語れる感じがしない。

玉川：そうですね。

伊藤：問題が大きいなという感じです。

玉川：最後も華麗ににお答えいただきまして、ありがとうございます。

（会場笑）

ということで、みなさん、長い時間お付き合いいただきまして、ありがとうございました。直也さんに改めまして、どうもありがとうございました。

（会場拍手）