伊勢氏、及川氏、よしおか氏が登壇したCROSS 2016の名物パネルを実況

チーム作りやモチベーションをどうする？CROSSで先達の濃い話を聞いた

エンジニアを巻き込むには声をかける？むしろかけない？

　前のテーマに引き続く内容となった次のお題は「どのようにチームを巻き込むか？」。これに対して、よしおか氏は「日本ではなにかと根性論になり危険。でも、ベースとしてはきちんとした技術力とゴールが明確にされているかが重要だと思う。あと、モチベーションがあっても方向がずれていたら、チームとしてのパワーは出ない。だから、コミュニケーションをどう実現するかが重要」と指摘する。

コミュニティにも精通する楽天のよしおかひろたか氏

　具体的な方策としてよしおか氏は朝礼や雑談などを挙げる。「昨日やったこと、今日やったことを話す。こんな簡単なことを隣の人と話し合って来なかったことに気づく。上手なマネージャーはエンジニアの顔色を見て、席に話に行く」とよしおか氏。

　及川氏はリーン開発におけるMVP（Minimum Viable Product）や世界観（テーマ）をチームで共有できているかが鍵だと指摘する。「Google Chromeの場合は、Speed、Security、Stabilityの3つの“S”しかない。今のChromeにはいろんな機能があるけど、この3つを阻害する場合は実装できない」と語る。このテーマやディレクションがきちんと決まっていれば、ソフトウェア開発の手法がどれを選んでも構わないというのが及川さんの持論。「世界観さえ共有されていれば、あるところはスクラム、あるところはウォーターフォールでもOKだと思います」（及川氏）。

　これに対して、森藤氏は「世界観を持つ場合にメンバー間で齟齬が出る場合はどうするか？」という質問を浴びせる。これに対して及川氏はリーダーが人として信頼されるかどうかが重要だと説明。「信頼を得るためには、これまでの実績やアチーブメントが重要。でも日本人はこれをあまりやらない。たとえば日本ではLinkedinが流行らないけど、米国人はきらびやかに履歴書を書きまくっている」と指摘する。一方で、優れたリーダーや伝説的なプログラマーがいない場合は、ファシリテーターに入ってもらって、全員で合議で決めていくという方法になるという。

　一方、インフラ系のエンジニアである伊勢氏には、よしおか氏のような「コミュニケーション重視」、及川氏のような「世界観重視」という感覚があまりないようだ。「昨日なにもやってませんなんて言えないし、僕自身は毎日朝礼やられるのすごいいやだった（笑）。だから1週間後の期日まではやるから、それまではなにも言ってくれるなという感じ」と語る伊勢氏は、その思いをマネジメントに適用。「デイリーミーティングなんてやらない。（経験上は）ゆるい制約と完全な自由でお願いする。お願いしたら、期日まで一切口は出さない」と断言する。

　途中経過はトラッキングしないという伊勢流マネジメント。「いかにもリスキーですね」と森藤氏は突っ込むが、「失敗しても、全人類が死ぬ訳じゃないんで」と伊勢氏は意に介さない。とはいえ、あらかじめバックアッププランを考えておいたり、単純にお金で解決するなどリカバリの方法は用意しておく。さらに追い込んだ方がパフォーマンスを発揮する人、へこむ人など、相手によってもケースバイケースで対応を変えているという。伊勢氏は、「『自由』は気持ちいい言葉だけど、チームのメンバーが素人だと困る。自律的に仕事ができる人がいるのが前提なので、その意味ではプロの集団。ただ、タスクやジョブなりを割り当てる際は、その人にあったものを割り振っていく」と語る。

部下の失敗をどのように次につなげていくか？

　マネジメント論で話が盛り上がる中、会場からは「失敗した時に怒鳴られるのがいやなので、会社を辞めたことがある。できなかったとき、失敗した時にどう声をかけるのか聞きたいです」という質問が飛ぶ。

　これに対して、伊勢氏は「経営者には言えないけど、あまり気にしない（笑）」と相変わらずマイペース。「過去にバックアップとってないデータ消したり、オンラインで接続している5000人全部落としたとか、けっこう失敗している」とどっきり発言をした伊勢氏は、「でも、人が死ぬわけでもないし。怒鳴られても、殴られるわけじゃないでしょ。殴られても自然治癒できるくらいなら、別に問題なくないっすか？」という破天荒な回答を送る。これに対して、質問者も「まあ、そうっすねえ……」と苦笑い。そこに及川氏が「あなた、それで納得しちゃいけないよ！」と割り込むという展開に会場も盛り上がる。

Googleでの経験を元に正当的なアドバイスを展開する及川卓也氏

　伊勢氏を引き継いだ及川氏は、やはり失敗を経験することで、同じ過ちを二度と繰り返さないように学べると指摘。「失敗をしかる組織というのは、やはり失敗しないように動いてしまっている。失敗しないということはリスクをとれないので、当たり前のことを当たり前のようにやるようになり、イノベーションがまったく起きない」（及川氏）と語る。ある程度の勝率でよしとし、いろんな試みをボトムアップで生み出す組織を作る。これにより、失敗から学び、次に活かすことができるというのが及川氏の主張だ。

　質問者が「しかるのはよいと思うが、怒鳴るとハートに響く」と語ると、及川氏も「僕も体育系のところは苦手なので、辞めちゃいます」と応じる。失敗するにも事前の兆候が必ずあるはずで、それを吸い上げられなかった組織にも問題があるというのが及川氏の論。自身の怒った経験を聞かれた及川氏は、「僕は笑いながら怒るんですよ（笑）」と言いつつ、「怒る時は同じ間違いを何度もやるとき、情報を共有しないとき」と語る。

　情報共有しやすいチーム作りも重要だ。これについて伊勢氏は、「納期が過ぎてから、できませんと言われるのは一番困る。でも、なんらかの予兆はあったはずで、それを感じ取れなかったチームが悪いのかもしれない」、よしおか氏は、「カジュアルに報告できない雰囲気を上が作っちゃって、自分でリカバリしようとして墓穴を掘るという話はある。だから情報共有する体制を作っておくこと、あとは傷口を拡げないようにする部下の詰め方も考えなければならない」とコメントする。

　もちろん、チーム内で馬の合わないメンバーがいると、コミュニケーションに齟齬が起こるし、不本意にも雰囲気のよくないチームに放り込まれてしまう場合もある。こうしたチーム内の人間関係について及川氏は、「正直、君と話しづらいと相手に面と向かって言ってしまう。同じプロジェクトチームなんだから、どうすればいいか尋ねてみる。このチーム、雰囲気悪くないですか？と言ってみる。苦手なメンバーと一生付き合うのは勘弁かもしれないけど、プロジェクトの間という話であれば、プロとして付き合わない理由はない」と語る。

　これに対して「お言葉を返すようですが……」と応じたよしおか氏は、「それができれば苦労がない」とコメント。「退職する理由で、上司や同僚と馬が合わないというのはけっこうある。これを解決する1つの仕組みとしては、やはり社内で異動できる方法を作っておくこと。むしろがんばらなくていいんじゃないかなというのが私の結論でした」（よしおか氏）とまとめる。伊勢氏の「IT業界はわりと人材流動性がある業界なので、社内異動がダメなら、転職という手段もあるよね」という意見を受けて、よしおか氏は「エンジニアは技術力を付けて、転職市場で評価してもらう必要がある。スキルを身につけるのは当たり前のこと」と応じた。