はじめに
こんにちは、PLG 事業部 開発部 部長のきのぴです！
今回は 20 人ほど在籍している我々開発部の雰囲気を知っていただこうと思い、ペンを走らせております✍
新卒入社して部長になったまでの成り立ちを織り交ぜながら組織づくりで何を意識しているのか、どんな雰囲気の組織なのかを書いていきたいと思います。
また、この記事は記憶を元に書かれているため、一部誇張されている表現などがございます、ご了承ください。
自己紹介
改めまして、きのぴです。
17卒でベーシックにエンジニアとして入社しました。
当時の CTO からは「Nikon がすきだったから」という理由で採用された話を聞きました。🤔
新卒一年目 + α
昔話をします。
入社後に新卒研修として 1 ヶ月間のエンジニア研修があり、 Ruby on Rails を使ってすきなサービスを作ろうというものでした。
研修を終え、初めての配属先はメディア系を取り扱う事業部で、CakePHP を使っていました。
いや Rails じゃないんかいと思いましたが、 PHP は学生時代に使っていたのでまあ大丈夫やろと思っていました。
当時の僕を一言で表すなら、「裸一貫でサバンナに放り込まれた状態」です。
全然大丈夫じゃなかったです。
初めてのフレームワーク（CakePHP）。初めて使う Git。怖い先輩。cd と ls コマンドしか分からない Linux 知識。怖い先輩。あと怖い先輩。
怖い先輩はさておき、このスキルセットでよく採用されたな〜と思いました。
仕事が始まっても、
- コードレビューは何をレビューすればええんや？
- 初手タスクがサイトマップ改善ってつらくね？
- そもそもこのプロダクトはどういうプロダクトなんや！
- 「すみません、今質問いいですか」「だめです（真顔）」「🥺 」「嘘だよ」「🥺 」
今思えば、先輩も同期もみんな強くて、自走できる人がほとんどだったように思います。
しかし、 今後入ってくる人たちがそんな強くていきなり自走できる人ばかりではないはず、しっかりとサポートできる環境を作りたい！ という思いが徐々に大きくなっていきました。
時は流れ、エンジニアの内定者インターンが入ってくることになり、僕は「メンターをやらせてください！」と申し出ることにしました。これが今の組織の第一歩です。
その後、新卒採用や新卒エンジニアの研修の旗振りも担当しました。
この経験で気づいたことは、「みんな最初は不安である」ということでした。
裸一貫サバンナ状態の後輩を作ってはいけないと、より思うようになりました。
マネージャー期
チームビルディングについて書いてみようと思います。
上司・先輩の退職はチャンス
最初に配属されたメディア事業部から SaaS 事業部へと異動になった矢先、担当していたプロダクトの開発チームの先輩たちが退職されました。
開発・保守、ステークホルダーとのやりとり、意思決定などあらゆる面でネガティブな考えもよぎりましたが、逆にいえばチャンスだと思いました。
今まで先輩が担っていた業務に挑戦することができる、ある程度の裁量を任せてもらえる、自分が考えるチームを作ることができる、というポジティブな思考が巡りました。
実際に、色々やらせてくださいと当時のマネージャー（兼CTO）に伝えたところ、開発チームのマネージャーを担うことができました。
採用と育成と山本五十六
マネージャーになったタイミングでは、自分を含め4人ほどで構成されたチームでした。
プロダクトとしてやりたいことがたくさんある中で、圧倒的に開発メンバーが不足していることが問題になっており、プロダクトをさらにグロースさせるためにも採用活動を行っていくことになりました。
結果として中途人材を6人採用することができました。
新入社員へのオンボーディングで意識したのが山本五十六の 「やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ..（略」 です。
どんな人でも「みんな最初は不安である」という思いから、まずは開発文化に慣れてもらう、プロダクトに慣れてもらうために自ら伴走を行いました。
手順書的なドキュメントを用意してそれを渡す、という方法もあるとは思うのですが「チームで仕事をしている」ので人とのつながりを感じてもらうためにも、そのような形で進めました。（前提ですが、このタイミングではリモートワークとなっております）
心理的安全性
今までの文章を読んで思われた方いらっしゃるかもしれないのですが、淡々としていますよね..。
ただ実際の中を見るともっとワッショイしながら仕事をしています！
普段はもっと絵文字を使ったり柔らかな表現を使って、伝え方伝わり方大事ファーストでコミュニケーションをしています ✌
ここでいう心理的安全性とは、「お互い何でも率直に言い合え、安心して前向きに挑戦できる状態」と定義し、それを担保することを意識しています！
こういうことが担保できる行動だよ、という例がいくつかあるのですが、ひと記事書けそうなのでここでは割愛させてください..！🙇
そして少しでも雰囲気を味わっていただきたいので Slack メッセージの一部をお届けいたします 💛
リモートワーク
弊社、2020年2月くらいからリモートワークを採用しております。
リモートワークでのコミュニケーションってなかなか難しいものあると思うのですが、そこで意識していることを書いてみます。
三密
一時期流行りましたね。
それに乗っかった感あるのですが、リモートワークにおけるコミュニケーションの方法を「三密」としてまとめてみました。
①綿密なコミュニケーション
オンラインで仕事をする上で、オフラインと比べコミュニケーションが少なくなったと感じることが多いと思います。綿密にコミュニケーションをとると、施策の仕様決めや方針などの認識に齟齬が発生しないようになり、次の親密な関係にも関わってくると思っています。
②親密な関係
仕事をする上で、お互いを信頼できない状態というのはとてもストレスだなと思っています。「この人にはこれを任せられる」「この人がやるなら問題ない」と思えるような関係であれば、自分は自分の仕事に専念することができると思います。
また、どうせ仕事をするならみんなで楽しくやりたいと思うのも大きな理由の1つです。心理的安全性にも大きく繋がると考えています。
③脱秘密
人は失敗を隠したがる生き物だと思っています。ただ、仕事をする上では失敗を隠すことは NG だとも思っています。理由は純粋に周りを巻き込んだ大きな失敗のトリガーとなるからです。
また、クローズドな環境でやり取りが行われた場合に、間違った決定が発生したりなど、解決策を持っている人からのヘルプが入りづらくなってしまいます。
このように理由は様々ですが、例え失敗したとしても隠すことのメリットがないと思っているため、脱秘密が大事だと考えています。
マイクの音質で他者の生産性に配慮する
リモートワークで仕事をする上で一番大切なものはなんだと思いますか？
そう、マイクです。Bluetooth イヤホンのマイク？避けましょう。せめて Mac 本体のマイクです。
お風呂からしゃべってますか？って方たまに見かけますよね。
時間も限られている中で聞き取りづらいと再び聞き直すことも憚られることも多々。「すみません、もう一度お願いします..！」というコミュニケーション、幾度となく見てきました。
終止符を打ちましょう。
最近では Amazon さんが 3,000 円ほどのコンデンサマイクを出してくれていましたね。実際に使ってみましたが、耐久性は分からないですが音質は問題ないように感じました。
3,000 円で他者の生産性が上がる..とても素敵ですね。ハッピー x 3 です。
部長期
上記のようなチームビルディングなどで色々奮闘してきた結果、プロダクトも組織も大きくなり、開発部としては 20 人規模のチームとなりました。
いちマネージャーとしてこの規模を一人で見るのは流石に無理があり、カバー範囲も無限大になってきたため、マネージャーを何名か登用し、僕は部長となりました。
次に整えようと思ったのは評価制度でした。
評価制度
弊社では来期これくらい期待しています、だからこのグレードです。という期待役割グレード制を導入しています。
評価で大切なのはマネージャーとメンバーが「納得」できている状態にすることだと思っています。
なぜグレードが上がらないのか、変わらないのか、上がるのか、をちゃんと説明できるようにしなくてはなりません。
メンバーのグレードは人事部と開発部で執り行う査定会議で決めています。（SLG 事業部という隣部署にも開発部があり、一緒の座組みで取り組んでいます）
フラットな状態で相対的に評価を行いますが、正直、今までの評価はマネージャーのプレゼン能力次第なところがちょっとあったと思います、ちょっと。
そこでより相対的に評価できるように、一定グレードまでに対して「このグレード帯だとこのくらいできるようになっていてほしいよね」というスキルマトリクスを作りました。
マネージャーは毎回頭を悩ませる回数が減りますし、メンバーも何をすればいいのかが明確な状態になると思っています。
まだまだ発展途上ではあるのでブラッシュアップしていく必要はありますが、部全体を動かす取り組みを実施中です。
（もちろん評価軸はそれだけではないですが！）
今後やりたいこと
開発部として今後進めていきたいことは下記 2 つです
- 技術力の循環
- エンジニア主体のプロダクト開発
新卒を含めたメンバーも急激に増え、新しい機能もどんどん開発される中で、技術的にムラのあるプロダクトになってしまっている部分があります。
チーム全体の技術力を底上げするためにも、勉強会、共有会、ペア・プログラミング（コードレビュー）などの定期的な実施をして技術力の循環を目指そうとしています。
また、要求に対して自ら要件定義をし、プロダクトに寄り添っていくエンジニアをさらに育てたいとも思っています。
「ドメイン知識」「課題解決・要件定義能力」「コミュニケーション能力」「UI/UX」「エンジニアリングスキル」これらのスキルをバランスよく身に着けた、つよつよエンジニアを目指したいですね。
もちろん全員がそうするわけではなく、技術力でチームを牽引する人も必要なので、割合としては 3:7 くらいだと思っています。（ 3 がエンジニア主体でプロダクトに寄り添う）
まとめ
振り返って思ったことは、
- 「しっかりとサポートできる環境を作りたい」という一貫した考えがずっとある
- 火中の栗を拾いに行くスタンスである（性格？）
- 心理的安全性を意識する
- マイクの音質は大事
ということです。
ここまで走ってこれたのは、たくさんの方々にサポートいただけたからということが大きいです、ありがとうございます！
本当はもっと書いてみたいのですが、長すぎるのでこの辺りで締めたいと思います。
興味あるな〜気になるな〜という方はぜひ 2026 新卒採用からエントリーをお願いいたします 💛
また、会社のことが気になる場合、アドベントカレンダーを実施しておりますので、ぜひご覧くださいませ！