梅林 たしかに「メンションの即レスを期待しない」という標語が全社的に使われていますが、それは仕事のコンテキストスイッチを入れないためでもありますね。集中してタスクにあたっているときにレビューやCSのサポートを依頼されますが、そのとき手掛けている仕事の切りのよいタイミングでやってほしいと考えているので。
逆に非同期のコミュニケーションが中心になると、いかにお互いのビジビリティを高めるかが課題になります。例えば開発においては、分からないことがあったら「分からない」と自分で発信できる方がいいんですよ。
コードを書くときに「何か分かんないけど、他のコードではこうなってるな」という状況があったら、黙ってコピーするよりも「何でこうなってるんでしたっけ？」って聞いてくれればその人の理解度も分かるし、なぜそう実装しているかもきちんと説明できます。
そのためには「何でそんなことが分かんないの？」という空気は絶対に作っちゃいけない。会社全体のバリューとして「100回同じことを聞かれても、100回笑顔で答える」というカルチャーでいこうと全員が本気で思っていますし、だからセールスやカスタマーサクセスの人もエンジニアにどんどん質問や相談をしてきます。
── さらにエンジニアの開発スタイルは「マルチタスクアサイン」「セルフサインアップ」「チケットに納期を設定しない」だということですが、これはどうしてでしょうか。
梅林 エンジニアは基本的に管理されたくないんですよ。朝会なんて誰もやりたくないですし、僕自身も管理したくない。僕自身が過去にICとして働いてきた経験から、これは不要だなと感じたマネジメント要素を取り除いた結果、このスタイルになっています5。
梅林 ちなみにチケットは納期こそ決めていませんが、プロダクトマネージャーが状況に応じてソートしていますから、基本的にタスクを上から取っていけばプロダクトにプラスになるようになっています。
その上でレビュー依頼だったり、開発以外のメンバーの相談だったりにはエンジニア個人の裁量で自由に対応できる方がいいですね。要望の本当のペインを確認した上で解決方法を考えるため、エンジニアが直接お客様とのミーティングに参加することもよくあります。
そうして使っているのは誰で、開発すれば誰がよろこぶかということが分かると開発しがいがあります。そうじゃないと何のために開発しているのかが分からなくなりますね。マネージャーのために開発しているんじゃないので。