シリーズ

伊藤直也の1人CTO Night

2016年8月30日19時30分のログ

スピーカー

株式会社一休　CTO　伊藤直也 氏
株式会社ソラコム　代表取締役社長　玉川憲 氏

別の登壇を頼まれたタイミングで依頼

伊藤直也氏（以下、伊藤）　今日、なぜ玉川さんにこの話お願いしようと思ったかというと。この対談の相手を探していたとき、ちょうど玉川さんに「今度、北海道の講演に出てください」と直前に頼まれたんです。「今だったら、こちらも登壇を頼んでも絶対断られないだろうな」とわかっていたんです（笑）。 （会場笑） 玉川憲氏（以下、玉川）　さすがですね（笑）。 伊藤　まあ、それは冗談で。さっき話していたように、玉川さんは開発者をやっていて、その後エンジニアのマネージャーとしてAWSに行き、今、社長として、CTOの人と一緒にやっています。いろんな経験があって、対談相手にふさわしいなと思ったということにしておきます。 玉川　ありがとうございます。 伊藤　はい（笑）。 玉川　おもしろかったですね、伊藤さんの話。きっと僕、明日から圧倒的に1on1が増えると思います。 （会場笑） 会場の何人か、すでに1on1を入れてますよ（笑）。 今日は「みなさんからのお悩み相談」ということで、実は事前にたくさん質問をもらっているんですね。10問以上もらっています。しかも、エンジニアの人が書いているので全部すごく長いんですよ。 （会場笑） これを書き出している時点で壁打ちになっていて、もう答えが出てるんじゃないのかと思うんですけれど。 （会場笑） さっき直也さんと話しながら、私もバーッと見たんですけど、2人で打ち合わせは全くやってないです。やってないので、寄せられた質問を見ていって「これ、どうなんだろう？」と雑談的にやるのがいいかなと思っているんです。 1個目からいきますか。パスだったら「パス」と言ってもらって（笑）。そういう感じでいけばいいと思うんです。

「指示待ち人間」はマネジメント側に問題がある

質問者1　エンジニアのメンバーが、担当領域では結果を出しますが、 伝えた以上のことは自分の守備範囲外としてなかなか手を出そうとしません。人員不足もあり、チームとしての成果を考えると マネージャーとしてはその人に守備範囲を広げてもらいたいと考えています。マネジメントをする立場として、本人の意思を尊重するのか、チームの成果を優先するのか。何か考える指針があれば、教えていただけないでしょうか。 玉川　なるほど。これどうですかね？ 伊藤　これは僕、さっき話したとおりで、「本人が守備範囲外のことをやるマインドを持つ」は、こちら側では直接コントロールできないですよね。「マインド」なんでね。むしろ守備範囲のことをやらせるしかないという気がします。きちんと1on1をして、1対1で「この範囲までやってほしい」と伝えるのはありますね。 玉川　そうですね。 伊藤　なんか、これは日本の会社特有の悩みのような気もする。 玉川　そうですね。日本的によくある話が、下の人に話を聞きにいくと「……とは言ったって、守備範囲外やったら怒られるんだもん」みたいな（笑）。 伊藤　そうそう。 玉川　絶対、これ言いますよね。 伊藤　言います、言います。「やっていいと思ってませんでした」と。 玉川　そうですね。どっちもどっち的なところがありそうな気がしますよね。 伊藤　「指示待ち人間がなぜできるか？」という話があります。指示待ちの人は「指示を待つ人」じゃなくて、「指示を待ったほうが得だからそうする」。指示を待たないでやると、それこそ怒られたり、損したり、痛い目を見て「指示を待っていたほうが基本的に無難だし」となっている。指示を待つ側に原因があるのではなくて、マネジメントしてる側の振る舞いに原因がある。 玉川　そうですね。うちなんかは「Just Do It」みたいな標語があるんですけど、そういうのはすごい大事だなと思っています。「Just Do It」と言ってるんだから、Just Do Itする。失敗したときに誰か1人でも嫌味言ったら、僕は「それ、言いすぎじゃない？」と、きちっと言いますからね。 伊藤　玉川さんは「Just Do It」の精神で、公の場でギャグを言ってよくすべっていますが、それに対して「すべりましたね」と腐すのは嫌みだと。 玉川　いや、それは嫌味とか関係ないと思います。まあ、すべらないですけどね（笑）。 （会場笑） そういった、そもそも論的なところもありますよね。守備範囲外のことをやったときに称賛される文化だったり、失敗しても誰かがほめてくれたり。 伊藤　根本的にこう、守備範囲が決まっているということですよね、守備範囲外のことをやらないということは。 玉川　そうですね。 伊藤　守備範囲を囲うマネジメントをしているから、守備範囲外のことをやらない。守備範囲外のことをやってほしいのであれば、そもそもの構造を変えないといけないという気がしますけどね。 玉川　うんうん。 伊藤　これは「エンジニア」という認識もそうなりますけどね。エンジニアという枠が強すぎる問題はありますよね？ 玉川　そうですね。エンジニアということで、自分たちで枠を作っているところもありますよね。 伊藤　そうそう。それに近しいものがある。 玉川　このペースでいくと絶対終わらないので、次いきますね（笑）。 伊藤　そうですね、はい（笑）。 玉川　おっと、これもすごいぞ。

フレーミングを怠ると、メンバーの意識は離れていく

質問者2　（1）開発、運用にはプランナー職のメンバーが仕様を決めたりするので彼らが重要なのですが、多忙だったり説明してもその場限りだったりと、うまく巻き込むことができません。チームを1つのベクトルに持っていくにはどのようにしたらいいのでしょうか？ （2）スケジュールを引いてるにも関わらず、遅延が常態化しています。組織改編などがあり、身の丈に合っていない量なので、施策量を減らすように施策を決めるプランナー陣には言ってるのですが、「売上」という免罪符があるのでしわ寄せがユーザや開発陣にきます。どのようにしたら、自分たちの身の丈に合っていないことを理解してもらえるのでしょうか？ （3）「マネージャーをやりたい」というメンバーを増やすには、今マネージャーをやっている人間が楽しく、メリットがあるところを見せないといけないと思うのですが、それをどう見せていいのかわかりません。どのように見せたらいいのしょうか？ （4）マネージャーの目標や評価がはっきりしていないからだと思うのですが、売上に直接コミットしていないマネージャーの目標や評価基準を決めたことがあれば教えてください。 玉川　そうですね。 伊藤　質問が4つありますね。 玉川　1つ目、「チームを1つのベクトルに持っていくには、どのようにしたらいいのでしょうか？」。 伊藤　質問がでかすぎますね、パス。 （会場笑） 玉川　直也さんがおっしゃっていた、フレーミングに近いですよね。 伊藤　まあ、そうですね。 玉川　フレーミングがうまくいってないと、こうなりますよね。「とりあえず上からタスクを振っときました」みたいな感じだと、全然メンバーの共感も得てないし、やる気になっていない。 伊藤　「プランナー職のメンバーが仕様を決めたりするので、彼らが重要」ともありますね。昔あったことで、企画と開発ではなく、エンジニア内の話なんですけど。インフラエンジニアとアプリケーションエンジニアの衝突問題がありました。 インフラエンジニアは、SLA（サービスレベルアグリーメント）を100パーセントに近づけたいじゃないですか。一方、アプリケーションエンジニアは、売上やUUを伸ばしたいんですよね。これは実際にあったことなんですけど、バッチ処理のために、僕が重たいのを書いたら、「こんなSQL、だめでしょ」とインフラエンジニアが言って、実行時にピッとkillされたんですよ。 （会場笑） 「これは長いSQLになっていて、データベースが重くなっているのでkillしときました」と言っていて。「稼働率100%でハッピーですね」と。「おいおいおい！」となって（笑）。 （会場笑） それで、サービス停止にはならない一方、もう「誰が見ても不具合だね」という不具合が出ました。 （会場笑） まあ、どっちもどっちなんですけどね。そのときに、最初は「考え方」をお互いで話していて。でも、ミッションが違うと、その都度どちらを優先するかを考えるのは難しいんですよ。 結局、どうしたらうまくいったかというと、さっきの池田（拓司）さんの話に近いんですけど、インフラチームのメンバーを各サービスにアサインしたんですよ。今まではインフラというくくりだったものを、「〇〇サービスのインフラエンジニアはあなた」としたら、その人とアプリケーションエンジニアが同じミッションを見るようになったので、多少は改善されました。 玉川　チームの中に入れちゃったということですよね？　同じインフラメンバーを。 伊藤　そうそう。 玉川　ぜんぜん違う側面で言うと、AWSが生まれた理由は「アプリエンジニアとインフラエンジニアをもう会話させるな」ということ。 伊藤　（笑）。 玉川　「APIでしか会話させるな」と決めたのも、1つの要因らしいんですよ。 伊藤　日本のどこかの会社でも、それをやったと聞きました。企画と開発を、あえて別のビルに移したとか。 玉川　テクノロジーで解決する軸と、まさにヒューマンなところで解決する軸と、両方あったほうが絶対いいですね。 伊藤　それだけ聞くと、絶対にAWSのやり方のほうがいいですね（笑）。 （会場笑） 玉川　そういう問題で伸びるやつは、そっちのほうがいいですよね。 伊藤　人間の問題を技術で解決しようというほうが、正しい気がしてきちゃった。 玉川　はい。 伊藤　ま、そういうこともありますが、「人の問題を人の問題としてもちゃんと解決しましょうね」ということです。 玉川　もう1個、先いきますか。

内製開発では「気にしている人」を味方にする

質問者3　（1）エンジニアやデザイナが新たに入ってくるなかで、経営陣や社内に、エンジニアやデザイナの働き方を理解してもらい、業務環境を作ったり、人事制度を整備していくにはどうすればよいでしょうか？　何か気をつけるポイントなどありますか？ （2）これまでITの活用を考えたことがなかった弊社で、サービスの中でITをどううまく活用していくか、どう作っていくかなどを考えられるように、社内全体の思考を切り替える・拡げていくためには、どのようにすればよいでしょうか？ 伊藤　「エンジニア、デザイナーに経営を理解してもらうためには、どうしたらよいでしょうか。なにか気をつけることは？」。これ、どう思います？ 玉川　逆に言うと、経営陣がエンジニアやデザイナーのことをあまりよくわかってないんですかね。 伊藤　うん。 玉川　経営に関しては、もともとITとは無関係なところだからということですね。これ、難しいんですけど。さっき直也さんも言ってましたけど、結局、まずは経営陣から信頼してもらえるエンジニアがいることがすごく大事。「あいつが言ってるんだから、まあ正しいんだろう」と（笑）。そういう人が1人いると、だいぶ違いますよね。 伊藤　「人事制度が……」「業務環境が……」だけを切り取って、制度をロジックで変えさせるのはあまりうまくなくて。 玉川　そうですね。 伊藤　そもそもエンジニアのボスとして、信用されるに値するかどうかが重要ですよね。あと僕、正直難しいと思うのは、このレベルは役員くらいにならないとダメなんじゃないかなと。 玉川　対等なところで意見できるということですよね。 伊藤　そうですよね。会社の中の人事制度に対するマネジメント業務は、ふつう、権限を持ってやることじゃないですか。 玉川　少なくとも内製開発を進めてるということは、経営陣の中にそっち思考の人がいるのは確かなんですよね。 伊藤　まあ、そうですね。 玉川　僕、この話を見てふと思い出したのが、日本交通の3代目社長に川鍋（一朗）さんという方が、最近、JapanTaxiという配車サービスを開始されたじゃないですか。川鍋さんご本人いわく、ITをまったくよくわかってないんですけど、リスペクトがあるんですよね。エンジニアも大切にするし、「ITは絶対武器になるから、大切にしなきゃいけない」という思いがあるんですよ。 川鍋さんのような人がいるんだったら、絶対会話になる。エンジニア側の人がきちっとその人と信頼関係を得て、うまくやるというのが大事。内製開発をする方向になる時点で、絶対そういう、気にする人がいるはずなんです。それが大事なんですかね。

すべての人がITリテラシーを持っているわけではない

伊藤　 2番目の質問も、似たような話ですね。 玉川　そうですね。 伊藤　これは「全体の思考を切り替える」と書いてあるけれど、全体を変えなくてもいいんじゃないかなと思いますけどね。 玉川　うーん。これ、一休さんとかどうなんですか？ 伊藤　一休がこれに近くて。 玉川　うん。 伊藤　一休は、営業の人が自分たちをIT企業だと思ってないんですよ。 玉川　それ、言い切っちゃって大丈夫なんですか？ 伊藤　大丈夫です、大丈夫です。 玉川　（笑）。 伊藤　いや、いい意味です。自分たちは、あくまでホテルやレストランの予約事業をやっていると思っている。 玉川　そうですよね。実業はぜんぜん、ITというわけじゃないですよね。 伊藤　一休に入って、2ヶ月くらい「なにかがおかしい」と思ったんですね。営業の人たちと話して、自分だけなにかがズレてる。僕がずいぶんいきり立ってる感じになっているなと思って。「この得体の知れない差はなんだ？」と思って、よく聞いたらそれだったんですね。 玉川　うんうん。 伊藤　僕の中で勝手に「IT企業だったら、ITに関してこういう風に捉えるのは当然」いう常識感、先入観を持っていたんです。 玉川　なるほど。 伊藤　でも、そもそもIT企業に入ってきたと思ってない人に、「ITはこうあるのが当たり前だ」と言うのは失礼な話だなと思っています。逆に、手段としてITを使ってるだけなので、どっちかといえばそっちの方が真っ当だなと。 実際、ビジネスとしてこれまでうまくいってるわけだから、「その人たちにIT全体のことを考えてもらうのが正しいの？」と思ったんですよね。それは自分たちがやればいいことであって、多様であったほうがいいだろうと。僕は結論をそう出したんです。 玉川　なるほど。 伊藤　ただ、Slackは使ってもらいましたけどね（笑）。 玉川　そこは割り切りつつも、便利なものは使っていくみたいな感じなんですね。 伊藤　そうですね。

※続きは近日公開