1. はじめてリーダーを打診されたとき、どう思った？
最初にリーダーを任されたのはユーザベースに入る前。新卒2年目くらいだったかな。やりたかったとかではなく、任されたからには「よし、頑張ろう」って感じでした。システムの設計など、リーダーとして考えられる裁量があったので、いろいろ試せるなとワクワクしていました。でもプロジェクトは大炎上でした（苦笑）。今だから言えるけど、当時は会社にほぼ泊まり込んでいましたね。
チームの仲は良かったけど、今振り返ると至らない部分がたくさんあります。プロジェクトメンバーのスキルレベルにばらつきがあったんだけど、相対的にスキルが低い人にキツく当たってしまっていたなと後悔していて。
いや、今でもメンバーに強く当たってしまうことがあり、都度反省しているんですけど……（苦笑）、その人をもう少し引き上げるような指摘や、チーム全体として生産性を上げる取り組みができたんじゃないかって今でも思います。
当時もプロジェクトが終わった後ずっと考えていましたね。そのプロジェクトのようなことはしたくないと思ったこともあって、アジャイル開発にたどり着き、勉強して取り組んできた形です。
エンジニアってプロジェクトベースで、そこにアサインして動くことがほとんどなので、そのプロジェクトが終わったら解散！ みたいなケースが多いんですよ。新卒2年目でリーダーをやったけど、その後フリーランスになるまではリーダーをやる機会はなかったです。
2. ユーザベースで実際にリーダーをやってみてどう？
ユーザベースで働き始めてから結構経ちますが、最初はフリーランスだったんですよ。フリーランスでもリーダーをやらせてもらっていました。今思うと本当に恥ずかしいんだけど、当時はチーム内のメンバーに強めのコミュニケーションをしてしまっていたし、ビジネスサイドの人ともぶつかっていましたね。
フリーランスとして働いていた30代前半で、50人くらいの大きなプロジェクトでリーダーをやっていたんですよ。プロジェクトリーダーとしてチームを率いる経験は何度もしていたので、ユーザベースでフリーランスとしてリーダーをやっていたときも、他のプロジェクトとあまり変わらなくて。
でも2017年に社員になってからは、考えるポイントが変わってきました。ぶっちゃけ社員になってもやることは変わらないと思っていたし、稲垣さん（稲垣 裕介／Co-CEO）からも「社員になったらこうしてほしい」みたいなことは言われてなかったんですね。
けど、やっぱり評価やキャリアパスをどう示すか？ など、組織の人間として考えていかなければと強く意識するようになりました。それまではプロジェクトチームのメンバーと、そのプロジェクトをどうするかに主眼を置いていたけど、ピープルマネジメントは別の視点・意識が必要だなって。
特に意識して大事にしていたのは、メンバーのキャリアパスです。プロジェクトを通してもそうだし、組織をどうつくっていくのか評価形態も含め、すごく意識してきました。エンジニアって昔は「プログラマー35歳定年説」みたいなのがあったんですよ。30代後半からは、もっとビジネス寄りのことをしないと生きていけないって言われていたけど、僕はそういうのがイヤだった。
プログラマーはプログラマーとして価値を上げていってもいいと思っていて。なんとなくリーダーやマネージャーが出世する・給料が高くなる傾向があるけれど、僕は「プログラムを書く」っていうアウトプットを出す価値も同じくらいあると思っているんですね。
ビジネスサイドの人たちとの仕事を通じて、よりそう思うようになりました。1人のリーダーから指示が飛んでくるような組織じゃないほうが、個人が輝けるのでは？ って思うんです。だから僕は特定のリーダーを敢えて置かず、全員がリーダーという組織運営をしています。
いろいろな技術を取り上げるのも、移り変わりの激しいエンジニア業界で「5年前はたしかに流行っていたけど、今はこっちのほうが市場価値が高い」みたいな話ってよくあるからなんです。
1つの技術に絞る戦略も間違いではないけれど、エンジニアのキャリアを考えたとき、いろいろな選択肢を内包しているほうがいいと考えています。「この技術を使いたいから転職」ではなく「この技術を使いたいから、別チームに異動」のほうが会社にとってもいいと思うし。
でも最初は反発もありました。こういった僕の方針と違うっていう人はいて。どちらが正しい・正しくないの話ではないし、反発がゼロになることはないのかなと思っています。ただ、方向性のすり合わせはメンバーみんなと話し合いながらやっていきました。
2017年に社員になる前からフリーランスとして働いていたので、そもそも僕の考え方を知っている社員も多かったんですよ。いきなりリーダーを任された人より、僕はフリーランス時代の下地があったので、やりやすかったのかなと思います。
評価制度については、ユーザベース全体で360度評価を取り入れていますが、僕らの組織では「経営」「運用」「エンジニアリング・マネジメント」「プロダクト・マネジメント」「アジャイル」「アーキテクチャー」など、かなりたくさんの観点で評価を行っています。各項目を1〜7の等級に分けて、数字が増えるにつれてそのスキルに対する深さ・広さが求められるように設計しました。
僕がゼロから生み出したわけではなく、もともとUBにあるコンピテンシークライテリアの評価項目をより細かくできたら、エンジニアのメンバーにキャリアパスを示せるんじゃないかと思ったのがキッカケです。UBの創業者3人が考えたものがベースにあるので、コンピテンシークライテリアがなかったら思いつかなかったんじゃないかな。いや、別に3人を持ち上げるわけじゃないんですけどね（笑）。
3. 何を大事にしているの？ 仕事だけでなく、人生でも。
僕、仕事のせいでプライベートが犠牲になるの、すごくイヤなんですよ。26〜27歳の頃、尊敬しているリーダーがいたんですが、彼が率いるプロジェクトがめちゃくちゃ大変で炎上していて。その人の初めてのお子さんが生まれるタイミングで、みんな出産に立ち会いに行きなよって言ったんだけど、彼は責任感が強くて立ち会えなかったんです。
そのプロジェクトで別の人にも同じようなことがあって。当時はまだ結婚していなかったけど、「これでいいんだろうか？」って思ったのを今も覚えています。その経験があるので、仕事が楽しくてやるのはいいんだけど、それによって家庭やプライベートに弊害が出るような状況はつくりたくないなと思っているんです。
エンジニアってよく「炎上」とか「デスマーチ」って言われるように、僕が20代の頃は特にめちゃくちゃ激務になることが多かったんですよ。体調や精神を崩していく人を見るたびに、こういう開発プロジェクトには絶対にしたくないと思ってきました。なのでアジャイル開発を取り入れて、単に働く時間を減らすのではなく、成果もちゃんと出しつつ、定時で終われるような開発組織を目指しています。
ユーザベースの社内副業制度「DIVE」って、すごくいいですよね。今の開発スタイルだと、みんな同時に仕事が終わるので「もうちょっとやりたいな」と思ってもできないんですね。そういうメンバーに、ちゃんと対価も払いつつ、会社としても成果が還元される。DIVEはもっと活用していきたいと考えています。
4. ワークライフバランスについて、どう考え、実践している？
僕自身、あんまりバランスが取れていると言えないかも……（笑）。うちは奥さんの母親と同居していて、子どもの面倒を見てくれるんですよ。夜は寝かしつけることもあるけど、最近は僕に寄ってきてくれなくて……平日は基本的に仕事に集中していて、あまり子育ての役には立てていないかな。
あ、でも朝は保育園に送って行っていますよ！ その分、土曜の午前中は1人で子どもを見ることが多いかな。よく近所の公園に連れて行って、一緒に遊んでいます。
夜遅くまで働いているというより、プログラムの勉強をして遅くまで起きていることが多いかな。日中はチームメンバーとのコミュニケーションに時間を割いて、夜はリーダー陣とSlackでやり取りすることもあります。夜遅いといっても、夕食やお風呂、子どもの寝かしつけの後にちょっと稼働するくらい。僕だけでなく、プロダクトチーム（エンジニア組織）はあまり残業しているイメージはないですね。
5. うまくいかなかったとき、どうした？
大きな壁にぶつかった記憶はあまりないんだけど、僕がいつも意識しているのは「小さな壁」に早くぶつかること。その壁が大きくなる前に乗り越えることを意識しています。質問の答えとしてはズレちゃうかもしれないけど、早めに察知する・失敗することを常に心がけていますね。
それでも悩んだりすることは当然いっぱいあるけど、そのとき自分で考えて本を読んだり整理したりします。よくやるのは、稲垣さんや昔からいるメンバーと飲みに行くこと。自分1人で考えていると整理できないこともあるので、コーチング的に壁打ちしてもらうイメージです。話す場を設定して、話しながら整理することが多いかな。
6. メンバーと話すときに意識していること
コーチングに重きをおくパターンと、「技術的にも教えてほしいです」っていう、いわゆるティーチング的なパターンがあるので、そのときの相手・状況によって使い分けているかな。
7. 1on1のときに気をつけていることは？
特に相手に準備してきてね、みたいなことは言っていなくて、そのときに話したいことを話してもらう感じかな。準備してくる人もいるけど、そうじゃない人もいるし。話すことが思いつかない人に対しては、いかに引き出すか？ っていうコーチング的な要素も重要なスキルかなと。うまくいかないこともありますけどね。
ティーチング要素が強く出すぎないように意識していて、「こういういときってどうするんですか？」って聞かれても、それにすぐ答えるんじゃなくて、「そもそもどういう対処パターンがあると思う？」って先に相手の考えを引き出すようにしています。そのうえで「僕だったらこういう選択を取るかな」って、「絶対に僕が正しい」みたいな伝え方はしないように意識しているかな。
8. メンバーと意見が対立したとき、どうしているか？
よくやるのは、まずそれぞれから話を聞いたうえで、関係者全員が集まる場をつくって対話すること。僕はその対話の場でフラットにファシリテーションをすることが多いです。
意見が対立するときって、たいていお互いの解釈がちょっとズレていることが根本原因なんですよ。僕も何度かそういう状況になって学んだんですけど。なので、お互いの話・意見をまず伝え合う。その中で、お互いの解釈をズレなくすり合わせるようなファシリテーションすることが多いかな。
そうするとお互い「なるほどね」ってなるんです。ただ、メンバー同士がぶつかること自体、あんまりないかな。みんないい人たちなので。
それ以外だと、たとえば思ったよりパフォーマンスが出ないメンバーがいたとき、それが本人の自己認識とズレているのであれば、コンピテンシーマップと照らし合わせて整理するとか。
ちなみにプロダクトチームって、評価に対して疑義が挙がったことが1回もないんですよ。細かい項目ごとに評価を全部オープンにしているし。以前、何で疑義が出ないんだろう？ エンジニアはおとなしいタイプが多いから？ 僕が恐いから？ って思ったことがあったんだけど、よくよく考えてみたらコンピテンシーマップを整備したのが大きいのかなって。
9. ユーザベースのD&Iについてどう思う？ 林さんにとってのD&Iは？
純粋に素晴らしいなと思っています。今回のインタビューもそうだし、メンタリングプログラムとか。頑張っている人に対して、自分ができることがあれば手伝いたいと思っているので、僕もメンターをやらせてもらっているし。
自分にとってのD&Iは？ って問いかけられると、あまり明確な答えはないんだけど、ユーザベースが目指していること・やろうとしていることは大賛成です。
ユーザベースのダイバーシティは、バリューが土台としてあるうえでダイバーシティをいかに実現するかを考える、インクルージョンは包むイメージですよね。僕はエンジニアなので技術的な部分で考えることが多いけど、いろいろなエンジニアのタイプがいて、彼らがそれぞれ活躍できるし、評価もされるような状態に持っていきたいなと思っています。
ただ、いろいろ悩む部分もあるんですよ。たとえばプロダクトチームで掲げているバリューもあるんだけど、そこからズレている人がいないわけではなくて、じゃあその人をどうするのがいいのか？ とか。僕の中での整理は、バリューが前提でのダイバーシティだけど、どこからがダイバーシティなんだろう？ みたいなことは最近よく考えています。
10. D&Iに取り組むメリットは？
純粋に組織の可能性を大きく広げるんだと思います。バリューが土台としてはあるけれど、その前提でいろいろな考えを持っている人が集まれば、その組織の力って大きく上がると思っています。
あと組織とか事業以外の面で言うと、いろいろな国、人種、キャラクターの人と知り合いになれていろいろ話ができるって、単純に人生の大きな糧になる・人生を豊かにすると思います。以前2年間ほど外資系広告代理店にいたのですが、そこでいろいろな人と話をすることができたのは、僕の中で人として成長する大きな要素だったと思っています。
＜私にとってのD&I＞
組織マネジメント系の本はほとんど読んでいなくて、アジャイル開発に関する本を参考にすることが多いかな。
