1. はじめてリーダーを打診されたとき、どう思った？
はじめてマネジメントを経験したのは、新卒2〜3年目のときです。メンバーは5人くらい。ポジションがプロモーション（昇格）したので、必然的にチームを持つことになりました。
ユーザベースに転職する前、一番多いときで80〜100人のメンバーをマネジメントしていましたが、リーダーになったばかりの頃はダメでしたね（笑）。尖っていたというか、ねじれていたというか……命を削って製品をつくるのが当たり前だと思っていたので、とにかく自分にも周りにも厳しくて。自分の生活なんて関係なくて、お客さんにいい製品を届け続けられたらそれでいいと思っていました。
なんだか焦ってたんだと思います。
たとえば日曜の夜にお風呂に入りながら新しい機能を思いついたとしたら、そのまま眠れなくなっちゃう。月曜日になるのが待てなくて、「いま頭の中にあることを、いまアウトプットしたい」という衝動に駆られて、終電で会社にいって朝まで開発して、そのまま月曜日も仕事をすることもありました。
いま思うと、「いい製品をつくらなきゃ」という思いが強すぎましたね。「僕だけじゃなくてみんなも、開発に打ち込むのが楽しいに違いない」と無邪気に思い込んでいたように思います。自分が好きなことに夢中になってたら、気づけばお客さんに喜ばれて昇格もして給料も上がって最高じゃん！ と思っていました。
本当はみんなそれぞれ思いがあって、それぞれの生活があるはずなのに、僕はピュアに「エンジニアリングって楽しいに決まってんじゃん！」と思い込んでいました。
2. ユーザベースで実際にリーダーをやってみてどう？
AlphaDrive/NewsPicksに来てからは、「無理やりなんとかする」のをやめました。ドラクエのコマンドでいう「いのちだいじに」で働いています。
そのとき一時的に「なんとか」できたとしても、そのままの状態で進めるといつか必ず「なんとかならない」状態になってしまいます。もちろんお客さまは一番大事ですが、命や家族を犠牲にしてまでやらなきゃいけない仕事なんてないと、僕は本心で思っていて。
メンバーやその家族を大切にすることと、お客様のためになることが矛盾しないような組織体制をつくり、コントロールするのが僕たちマネジメントの仕事だと思っているんです。
一度、佐久間さん（佐久間 衡／Co-CEO)が、「組織体制やリソースが足りなくて、OKRが達成できなさそうなときはどうすればいいですか？」って聞かれて、「じゃあ、目標を変えるしかないですね」って答えていたのを見たことがあります。
僕は、これぞアジャイル開発の本質だと思うんですよ。エンジニアリングの世界におけるアジャイル開発って、自分たちの器に何をどれだけ埋められるのかを考えていく手法であって、ゴールをどう無理やり達成するかという手法ではないので。
つまり、自分たちの実力を見誤らないようにすることが大事だと思うんです。もちろん、大きなプロダクトのリリースへ向けて一時的にスパートをかけるときはあります。だけど、体力にものを言わせて無理に人で解決しようとすると、最終的に大きく失敗してしまう、というのが僕が過去にやらかした経験から学んだことです。
3. 何を大事にしているの？ 仕事だけでなく、人生でも。
この点について、僕は大きくふたつ大切にしていることがあります。ひとつは、「良い・悪い」ではなく、「合う・合わない（適している・適していない）」で判断するということです。技術選定ひとつとっても、良い技術・悪い技術なんてありません。すべては「タイプと特性」であって、その技術が目的に適しているか・適していないか、ですから。これは採用のときも同じポリシーで考えていますね。
ふたつ目は、人を見るときは極力、加点方式にすることです。これはシンガポールのときの経験が大きいですね。
たとえば締切を守るのが苦手なメンバーがいたとして、そのメンバーはとにかく締め切りを守るのが苦手だった、でもものすごく技術的に難しい開発や面白い機能を開発するんです。一般的なマネジメントの考え方では「締め切りを守れ」と弱点にフォーカスしてハードマネジメントしてしまいがちな部分ではないかと思います。
でも大きく考えとスタイルが変わった結果、「まぁ締め切り守るのが強みじゃなくて圧倒的な機能開発が彼の強みだな」と、得意なところ軸で任せるようになりました。
得意なところは何か、本人が伸ばしたいところは何かを考え、本人が評価されやすい状況、みんながWin-Winになる状況をつくるのもリーダーの役割です。加点方式で人間関係を築けるようになったら、会社の人間関係もパートナーや家族との関係も、もっと楽しくなるんじゃないかと思うんです。
4. ワークライフバランスについて、どう考え、実践している？
僕個人のワークライフバランスでいうと……正直、ぐちゃぐちゃです（笑）。これはユーザベースがフルフレックス制だからできることなんですが、朝から夜遅くまで開発している日もあるし、一方で散歩や買い物した後短時間で仕事を終わらせる！ という日もあります。わかりやすく言うと、働きたかったら働くし、働きたくなかったら働かないスタイルですね（笑）。良い意味で、メリハリがきいていると思います。
そのスタイルが一番ストレスなく働けるんですよ。これはメンバーに対しても同様で、個々人が「ノッたとき」にパフォーマンスを出せればいい。
つまりもちろん「労務的に問題のないかぎり」というところは絶対外しちゃいけませんが、メンバーがどこにいて、何をしているのかについては、僕は管理しないし、関知しません。人それぞれ、家族に合わせて16時くらいにあがって夜また働くメンバーもいれば、朝早く起きて働くのが一番パフォーマンスの高いメンバーもいる。僕みたいに散発的に働くのが向いているメンバーもいる。
その分、働く時間が合わなくても大丈夫なようにドキュメントやコミュニケーション設計はかなり気をつけています。非対面・非同期を念頭にソースコードを含め「モノで会話する組織」ですね。優秀なメンバーたちが働きやすい環境をできるだけつくろうと考えています。
5. うまくいかなかったとき、どうした？
かつては「開発に没頭し続けるのが楽しいに決まってるじゃん！」という価値観をメンバーに押し付けてしまったこともありましたし、その結果、チームが健全とは言えない状況になっていたこともあって強く反省しています。
それを変えようと思ったきっかけが先にも触れたシンガポールでのマネジメント経験です。
当時の僕は「お客様に最高の製品を届けよう」と思うあまり、自分にもメンバーにも異常なハードワークを課していたんです。だけど海外では日本よりも家庭や家族を大事にする文化が根付いていたし、メンバーごとに「高いクオリティで製品を開発する力はあるけれど、締切を守れない」などの特性もありました。
なのに僕は、一律に「あるべき論」でマネジメントしてしまった。結果的には目標達成と引き換えにチームとの信頼関係が損なわれるような状況に陥ってしまったこともありました。
そのとき、当時のメンバーが僕と真剣に向き合ってこう指摘してくれたんです。
そのときはショックと嬉しさが同時にやってくる不思議な感じでしたが、いま振り返ってみても本当にありがたかった。そのときから、仕事に対する向き合い方が大きく変わったんです。
一番大きな変化は、サステナブルな働き方をしていないと、お客様のためにならないと思うようになったことです。命や体力を削って製品をつくったところで、サステナブルな働き方や組織でなければ安定的にサービスを供給できなくなってしまいます。それはお客様、特に我々が対している法人のお客様にとって、すごく大きな不安要素なんですね。
「仕事を楽しめて、家族や友人も大事にできて、技術力も研鑽できる。しかも会社として適正に利益を稼げることこそが、長くお客さまのためにメリットを提供し続けることにつながる」という考え方の大転換が起きたんです。
6. メンバーと話すときに意識していること
ちょっとしたポイントなんですが、たとえばSlackのスタンプを押しまくることとかですかね（笑）。社内でも、僕と文字さん（文字 拓郎／NewsPicks CTO / CPO）はめちゃくちゃスタンプを連打する方だと思います。僕は「ええやんええやん」とか「すごい！」「わかりみ」のスタンプが多いかな。
他のリーダーには「Slackのスタンプを押すのは、リーダーの責務だと思うんだよね」って言っています。スタンプって、対面コミュニケーションにおける「表情」と同じだと思うんですよ。うんうん、ってうなずいたり、共感している様子って、ユーザベースみたいなフルリモートの環境ではわかりにくい。
忙しくて返信できなくても、スタンプを押しているだけでメンバーにとっては精神的な安心感が高まります。非対面・非同期の環境で心理的安全性を担保する一番の近道だと思うんですよ。
スタンプはね、押しまくった方がいいです。こんなん、なんぼあってもいいですからね！
7. 1on1のときに気をつけていることは？
オーバーリアクションすることを気をつけています（笑）。いや、もともとオーバーリアクションでもあるんですが、どうしてもしゃべりすぎちゃうタイプなので、メンバーの話を聞きリアクションに徹することを心がけています。
それからメンバーとの会話で気になったことはメモしていますね。どこをケアした方がいいとか、何週間か経ったらこういう話をしよう、とか忘れないようにしています。
メンバーの「好きなこと」についても意識的に聞くようにしています。好きなアニメ・美味しかったお店・良かったサービス・好きな映画など多岐にわたります。
これは、好きなことに熱くなっている人の話を聞くのが好きだからというのもあるんですが、サービスを開発する人は、良いものに対する感度を高くしておく必要があると思うから。僕がすごいと思っている人たちが好きだと言っているものは、たぶんすごく良いものだろうと思って吸収しています。
8. メンバーと意見が対立したとき、どうしているか？
大きな対立はないですが、健全なコンフリクトはあると思います。必要に応じて、徹底的に議論します。誰かが感じた違和感を無視したら、よくないことが起きることが多いですから。
メンバーとディスカッションして考えが変わることもしょっちゅうです。よくよく聞いてみたら、メンバーの方が考え尽くしていたということは多いですよ。「メンバーが専任で担当しているから、やっぱ彼・彼女の言うことの方がいい案だわ」ということも当然多いですよね。
ただ、その過程で熱くなりすぎちゃうことはあって。僕もよく後からメンバーに「ごめんなさい、熱くなっちゃいました！」って謝ります。でも全体として、適正な衝突は必要だと思う派です。
9. ユーザベースのD&Iについてどう思う？ 赤澤さんにとってのD&Iは？
一次情報が日本語であり、日本語の情報の方が手厚いという現状を海外のメンバーはどう感じているんだろうと気になることはありますね。これまで働いてきた企業では、基本的に英語でコミュニケーションする環境だったこともあって。
たとえば、Slackの「DeepL」の翻訳機能を使ったBotなどもテスト導入しているところなんですけど、こういうところからはじめて、一次情報の速度と濃度に日本のメンバーと海外のメンバーの間で格差が生まれないようにしたいなと思っています。
その点では、正直なところユーザベースの海外メンバーは前提条件として諦めているところがあるんじゃないでしょうか。
ユーザベース内でマジョリティである日本語を母語とする自分としては、優秀な海外メンバーが「結局、日本語優先なんでしょ？」と思ってしまわないか、ちょっとモヤモヤしています。
10. D＆Iに取り組むメリットは？
お客様に良いサービスを提供するための合理的な戦略であり、手段だからです。と言い切ってしまうとちょっと語弊がありますが、多様性の実現って公平性の担保や目の前の人に対する優しさのためだけにあるものじゃないと思っています。
企業として達成したい目的があるなら、優秀な人が集まるためのあらゆる手段を取るべき。その際、ジェンダーや国籍、子育てしていることなどがキャップになっていたら目的は達成できないんですよ。
たとえば前職でグローバルのメンバーをマネジメントしていたときは、国籍や宗教ごとに食べ物・大切にしている考え方・禁忌事項などをチャート図にしていたこともあります。東京へ出張に来たときのために、ハラル認証やベジタリアンのためのレストランマップをつくったこともありますね。イヤイヤじゃなくてそういうのも楽しかったです。それくらい、一緒に働く仲間が何を大切に人生を歩んでいるか、については大事にしたい。
すでにユーザベースにいるという時点で、そのメンバーは信頼できる人であり仲間です。だから「みんなが働きやすい環境をつくること」に取り組むことは必須だと思っています。
＜私にとってのD&I＞
シンガポールオフィスにいたときのマネジメントディレクターの、海外のメンバーとの接し方や、得意なことにフォーカスするという考え方が、D&Iについて考える上で指針になりました。
メンバーとの会話や、柔らかい接し方などを間近で見られたことは、D&Iを大切にした職場づくりをする上で、肌感として非常に勉強になりました。そのディレクターの振る舞いを見て、僕自身のマネジメント方法を大きく変えるきっかけになったと思っています。
これからも、1人ひとりのメンバーを大切にしていきたいですね。
