paiza times

paizaがお届けする、テック・キャリア・マネジメント領域における「今必要な情報」を届けるWebメディア

logo

paizaがお届けする、テック・キャリア・マネジメント領域の「今必要な情報」を届けるWebメディア

よいエンジニアチームを作るためにリーダーがやっている6つのこと


Photo by gdsteam

高村です。開発チームのエンジニアリーダーをしています。

以前、このブログでも前職の大手SIerに入社してからpaizaに転職するまでの話を書きました。

paiza.hatenablog.com

今回は、その転職後に私が何をやっているのか、エンジニアのチームづくり・組織づくりに関してやっていること・考えていることについて書きます。

私が誰でどんな仕事をしているのか

paizaの開発チーム全体のリーダーとして、自分で手を動かして開発もするし、メンバーのマネジメント、チームづくり・組織づくり(組織=チームの集合体)、採用などに関する業務もしています。

paizaはスタートアップ企業で、まだまだ成長しながらいろいろな壁を超えていかないといけないフェーズにあります。そのため、業務的にはリーダーとしてのチームづくり・組織づくりの比重も結構大きい感じです。

ただ、私自身はマネジメントや組織づくりの専門性を上げていきたいわけではないです。開発とマネジメントのバランスをとりつつ、どちらもいい感じにやっていけるポジションを目指しています。(現時点では、私自身が一番価値を提供できるのがそのポジションだと自己分析しているので…)

前職ではSIerに8年ほどいて、PM的な仕事をしつつ、よく趣味で(?)炎上プロジェクトの助っ人にも行っていました。チームづくり・組織づくりに関しては、前職で学んだノウハウや、paizaで初体験したことなども含め、改めて見直したり整理したりしている最中です。

趣味で炎上プロジェクトの助っ人に行っていたときの話はこちら
paiza.hatenablog.com

開発チームリーダーとしてやっていること・考えていること

一言で言うと「しなやかで強い」組織を作りたい

チームや組織を作っていく上では、しなやかさ・柔軟さがかなり重要だと思っています。

たとえば、大企業の場合はフローをきっちり決めて、担当を分けて線引きをして、その通りにそこからはみ出さずにやる…といった仕事の進め方もありますよね。(前職の大手メーカー系SIerでもその傾向があったと思います)

ただ、そういった線引きって組織が大きくなったときに混乱を防ぐためにやるものだと思います。paizaはまだまだスモールな組織で、今後もいろいろなやり方を試したり、変えたりするのが必須です。だから、まだまだきっちり線引きするようなフェーズではないと考えています。(もちろんそれぞれメインの担当業務はありますけど)

以下、もう少し詳しく説明します。

グレーゾーン問題を放置しない共通認識を浸透させる

たとえば、エンジニアとデザイナーの両方がかかわる領域で問題が見つかった場合。担当者間、チーム間で「これはそっちの担当だろ」「私の担当はこの範囲だけだからやりません」とか言っていたら、そんな組織はすぐに潰れてしまいます。

理想的なのは、グレーゾーンな問題が見つかったら、「これ見つけたから直しといたで」「サンキュな」とか「ここ直したほうがいいと思うが自分はべつの仕事が立て込んでおってな」「オッケーやっとくわ」みたいなコミュニケーションが自然にとれる、基本的な共通認識と信頼関係のある組織です。

もちろん各々担当分野や得意ジャンルはあるわけですが、大きく組織として目指す目標は同じはずですよね。ってことは、やるべきなのは押し付け合いじゃなくて、目標に向かって協力しあうことです。

あとは、各々の専門知識も共有する機会があったりすると、相互理解やお互いのできる範囲を広げ合えていいかなと。弊社でも、いろいろと社内勉強会を実施したりしています。今週も、エンジニア・デザイナー・ディレクターと希望者の人たちでフロントエンド周りの勉強会を実施しました。

エンジニアだけが強い組織でもいけない

何かひとつの企画を実行するとして、エンジニアとデザイナーと企画がいたら、みんな立場が違うんだから、考えることも違うのは当たり前です。

たとえばエンジニアは技術的なコストや開発しやすさなどを優先したいだろうし、デザイナーは使いやすさや見た目のよさを考えるし、企画は話題性や集客について考えるかもしれない。で、これらのどれが全部重要なのかを考えると、全部重要だし全部必要ですよね。(もちろん状況によって優先度は変わりますが…)

だから、どこかが圧倒的に強すぎる組織にしてはいけないと思っています。

たまに営業が強めな会社だと、「エンジニアの立場が弱くてつらい…」みたいな話を聞きますよね。それも最悪ですし、だからと言ってエンジニアが強すぎる組織もよくない。誰だって、そのポジションと仕事が組織にとって必要だから存在しているわけですし。

自分もそうですが、エンジニアは「エンジニア的にはこうしたい」という目線で考えるし、話しがちです。それはいいんですけど、じゃあ逆にほかの人たちから「デザイナー的には…」「企画的には…」って話が出てきたときに、ちゃんと聞かないといけない。公正に聞いて、みんなでちょうどいい落としどころを見つけないといけないと思います。

最終的な判断軸になるのは「ユーザーのためになるかどうか」

とはいえ、やっていると議論が膨らんでいったり、何を優先して決めるべきなのか、落としどころに迷うケースもあります。

そんなとき、paizaの場合は必ずと言っていいほど「それってユーザーであるエンジニアのためになるの?」に立ち戻って考えるようにしています。

これは組織として絶対にぶれてはいけないポイントです。組織として、この考えを芯としてぶらさないようにしながら、現実的に実現可能な落としどころにたどり着くのが重要です。

採用時に考えていること

エンジニアで中途入社されたけど、退職されてしまった人もいます。原因はいろいろあると思いますが、私は要因の一つに「採用担当者ごとの採用基準にズレがあったのかもしれない」と思っています。

(ちなみに言い訳のような自慢のような補足ですが…退職されたのは私が採用に絡んでいなかった人だけで、私が採用面接をしたエンジニアは、この記事を執筆した時点ではまだ誰も辞めていません。たまたまかもしれませんけど…。)

これは別に辞めるエンジニアが悪いという話ではありません。自分と合わない企業にい続けるほど無駄なことはないですし。

組織としてはこれからの開発チームづくりに長く貢献してくれる人がほしかったはずなのに、採用した人とのズレが生じて退職されてしまったなら「採用基準に問題があったんだろうな」という話です。

「なぜ弊社なのか」が結構大事

今は改めてスキルマップなどを明文化するとともに、選考では「なぜうちを受けてくれたのか、どんなところに興味を持ってくれたのか、うちでどんな仕事をしたいのか、paizaを使って何を実現したいのか」といったマインド面を重視して見るようにしています。(こういった質問をそのまま直接聞くわけではないです。「こう聞けばこれがわかる!」と画一的にはかれるものではないので…)

応募者側にも、給与の高さとか、使う技術とか、作るサービスとか、優先したい条件は人によっていろいろありますよね。それと同じで、私が採用者側として重視したいポイントのひとつがマインド面なのです。(もちろん技術的にもいろいろ見たい部分はありますが)

だって社員の採用って、「とりあえず人が足りないからスポットで一年開発してくれればいい」という話ではないですよね。お互いの人生を提供し合うわけですから、面接は「お互いがハッピーになれそうか」を想像しながらやらねばならないと思います。

特に今のpaizaはそろそろ50人の壁を突破して、その次は100人の壁を突破するフェーズに向かっていくところにいます。いろいろなやり方を取り入れたり、組み換えたりすること自体を楽しみつつ、事業的なの目標にもワクワクできて、paizaをよりよいサービスにしてくれる仲間と一緒に働きたいと思っています。

選考では、現在うちにどんな課題があって、入社してくれる人には何を解決してほしくて…といったことは全部話すようにしています。ここで認識のズレがあると、いったん採用ができたとしても、早期退職につながりやすくなってしまって、結果としてお互いが不幸になってしまいますからね。

これを読んで「この会社、全然合わないな」と思った人もいるかと思いますが、それはそれで健全なことだと思います。エンジニアにとって「合わない企業をちゃんと見極める」のは、志望度が高い企業の選考を通過するのと同じくらい重要ですから。

負債返済DAYを作る

創業時と比べると、当然ながら組織的にもサービス的にも大きくなって、それに伴い技術的負債もたまってきています。

技術的負債とは
qiita.com

私の入社当時から、いやむしろもっと前から、「負債、いつかは返済しないといけないよね…」って意識自体はみんなあったと思います。でも、やれていなかった。目の前の新しい開発要件があるのに、貴重な工数を割いて負債返済に当てるべきか? という面もありますし、そもそもエンジニアが「負債返済したい」と言い出しづらい空気感もあったのかもしれません。

ただ、そのままだと負債は増えるばかりでいつまでたっても返済できないですよね。

私はずっと、リファクタリングする文化を作りたかったし、その前段階として、リファクタリングに限らず不満やもやもやを吐き出せる空気感や、課題を見つけたら「見なかったことにしよ…」じゃなくて「これどうなんでしょう?」って吐き出せる風潮、ひいては「挙げてくれたから直せたね、変えられたね! これからもやっていきましょう」とお互い感謝しあえるチームを作りたいという考えがありました。

だからそういった文化や空気づくりの一貫として、月一で「負債返済DAY」を設け、その日はエンジニア全員が負債返済にあたるという取り組みを実施しています。(もちろん社長公認で)

今のところ月一ですが、開発チーム一丸となって返済にあたることで、どこかひとごとだった(かもしれない)技術的負債が自分ごとになってきた…と思います。

会議を減らして手を動かす時間を確保する

リーダーになったら会議時間が増えて開発時間が減ってしまったので、改善のために会議改革を始めています。

もちろん会議そのものが悪いわけではありません、必要な会議を開くのは大事なことですから。

ただ、見直してみると、議事録や決定事項だけ共有してもらえばいいじゃん、オンライン参加でいいじゃん、60分使うのではなく50分に縮めてもいいのでは?定例で毎週開催しなくてもトピックがあるときだけ開催でいいのでは?…という会議も多い印象でした。みなさんも見直したらあると思います。

で、そういった会議は議事録だけ共有してもらうとか、オンライン会議ツールを導入するとか、会議時間や開催頻度を減らすなどといった取り組みを実施しています。

もちろんこれはエンジニアだけに必要なことではなく、組織全体で取り入れようとしています。現在paizaは一部リモート勤務を導入しているので、離れた場所からでも会議参加できるオンラインツールの利用を進めています。

ちなみに今はappear.inを使っているのですが、まだテスト段階なのでほかにもいいオンライン会議ツール知っている方はぜひ教えてください…。
https://appear.in/appear.in

※後日談
今はMeetを使ってのオンライン会議が主流になっています。
meet.google.com

まとめ

というわけで、私が何をやっているのか、エンジニアのチームづくり・組織づくりについてやっていることの話でした。

前職でもプロジェクトごとのチームづくりは割とやっていたのですが、組織づくりに関してはpaizaで初めてやっているので、まだまだできていないことも多いですが、開発チームはもちろん、組織全体をよりよくしていきたいと思っています。

paiza転職は、転職時のミスマッチをなくし、エンジニアがより技術面にフォーカスしたやりがいある仕事を探せる転職サービスです。プログラミングスキルチェック(コーディングのテスト)を受けて、スコアが一定基準を超えれば、書類選考なしで複数の会社へ応募ができます。

paiza転職について詳しくはこちら
paiza転職





paizaラーニング」では、未経験者でもブラウザさえあれば、今すぐプログラミングの基礎が動画で学べるレッスンを多数公開しております。

詳しくはこちら

paizaラーニング

そしてpaizaでは、Webサービス開発企業などで求められるコーディング力や、テストケースを想定する力などが問われるプログラミングスキルチェック問題も提供しています。

スキルチェックに挑戦した人は、その結果によってS・A・B・C・D・Eの6段階のランクを取得できます。必要なスキルランクを取得すれば、書類選考なしで企業の求人に応募することも可能です。「自分のプログラミングスキルを客観的に知りたい」「スキルを使って転職したい」という方は、ぜひチャレンジしてみてください。

詳しくはこちら

paizaのスキルチェック

paizaのおすすめコンテンツ

Webセキュリティ入門 ハッカー入門 Webセキュリティ講座がスタート!CVは内田真礼さん! Python✕AI 機械学習入門講座 CVに上坂すみれさんを起用!人気の機械学習講座を公開中!
paiza転職 paiza新卒 EN:TRY paizaラーニング 記事内に記載している情報は、記事公開時点でのものとなります。 Copyright Paiza, Inc, All rights reserved.