周りを巻き込む施策をベンチャーで 4 つほどやった結果の知見

はじめに

1 つの能力として「周りを巻き込む力」はエンジニアだろうがなかろうがものすごく大事だと思う。

なにか物事を始めたいときも周りを巻き込めると推進力や協力関係も大きくなる。 例えば、個人開発も本当に個人で開発するよりもデザイナー・フロント・バック・インフラエンジニアなどの知り合いを巻き込んだほうが、 わからないことも聞けたりお願いしたりできるだろう。

というわけで、せっかくスタートアップにジョインしたのもあり、好き勝手いろいろやってみたのでそのときの知見を整理してみた。

試した施策

プライベートタイムにおける社内コミュニティの立ち上げと業務時間中の話も含めて行った施策は下記の通りである。

• 🚀【施策 ①】社内の個人開発を行うコミュニティ
• 🚀【施策 ②】社内の少数精鋭の勉強会コミュニティ（その１）
• 🚀【施策 ③】社内の少数精鋭の勉強会コミュニティ（その２）
• 🚀【施策 ④】業務時間にて学習を兼ねた仕事を行う施策

施策の大方針は「会社内で学習コミュニティを作成すること」

自分がそこのスタートアップにジョインしていたときの自分の基本理念として

「エンジニアリング力を伸ばすこと」

のみをフォーカスしていた。なので、施策方針も

「会社内で学習コミュニティを作成すること」

などエンジニアリング力が伸びることに繋がることにした。

業務中に新人からわからないところを聞かれまくって疲弊する経験もあったのも理由でもある。

なので、あまり、一方的な関係性にはしたくなかったこともあり、「相手の成長を行える環境の提供」「お互いにギブしあえる関係作り」なども考えつつゆるくコミュニティ形成をしてみた。

🚀【施策 ①】社内の個人開発を行うコミュニティ

• 施策
  • 合計８人ほどのエンジニア歴の浅いメンバーを中心にプライベート時間を使ってそれぞれでアプリケーション・サービスの開発を行っていく「個人開発を行うコミュニティ」を社内で立ちあげてみた。
  • 個人開発ではなくチーム開発で行うことも考えたが、エンジニア歴が浅いメンバーばかりなので複数人で作成するほうが作業分割が難しくなりそうだった。なので、個人開発を選択した。
  • 最初に自分が「各メンバーが何を作りたいか？」を会話して引き出して決めた。なのでトップダウンで作るモノを指定はしなかった。
  • 強制的な課題・宿題などをこちらから提示しないで、自主性に任せてみた。
  • 進捗を確認する週に 1 回のランチ会を行った。各メンバーの状況をヒアリングする形で確認してみた。
• 結果 → 失敗
  • 定期のランチ会で状況ヒアリングをしいていたが、毎回ほぼが「なにもやってないです」という状態だった。そのため、最終的にはランチ会自体も消滅した。
• 理由
  • 【時間がない】土日出勤とかするレベルで各メンバーの仕事が忙しく、プライベート時間で開発を行えるだけのバッファが前提として存在しなかった
  • 【モチベーションが低い】メンバー集めの際は「やりたいです」と言っていたメンバーもフタを開けると半数以上のメンバーのモチベーションが弱かった。というのも、結局は自主性ドリブンで任せたらプロジェクトをnewすらしていない人もいた。また、自分もメンバーに対してモチベーション向上・維持を行うための施策を打ち出すつもりもなかったので行っていない。
  • 【主催者が開発していない】自分が言い出しっぺなのにこの会の開発を全然作っていなかった。そのため、リーディングしていく上での説得力が弱い状態だった。一応断っておくと、土日含めて１ヶ月くらい休日がないようなレベルの激務だったので、その時間がそもそも無かったので作れなかった。
  • 【個人開発をできるレベルでない】メンバーのレベル的に仕事についていくのがやっとの状態だった。そのため、業務タスクで手一杯の状態で別途開発していくだけの時間的・精神的なゆとりがなかった。とはいえ、だからこそ、個人開発を通してレベルを上げてほしかった感があるが。
• 🤩 学び
  • 「やる気あります」は信用してはいけない。本当にやる気がある人はすでに手を動かしている。
  • 誰もやっていない状態が続くと「やらないでも良い」という空気感が生まれてしまう。スタートアップと同じで最初のメンバーは厳選し、文化形成は慎重に行うべきだった。

🚀【施策 ②】社内の少数精鋭の勉強会コミュニティ（その１）

• 施策
  • 「教えてほしいです」と直接頼まれたメンバーが 2 人いたので、そのメンバーだけに勉強会を始めた。
  • ２人とも iOS エンジニアで自分がバックエンドを教えた。
  • ２人が自習してきてわからないところ・つまったところ・QA などが出てきたら Slack やランチの時間に対応する。
  • 自分が発表する形での学習は行わなかった。
  • 前回の反省から少数のモチベーションの高い人だけに厳選するために他の人は誘わずに人数を増やさなかった。
• 結果 → 成功
  • 自分の勉強会を卒業。自分でサービスを作れるレベルになった。
• 理由
  • 【教える側の負担が少ない】QA を潰す方式のスタイルにしたので教える側の負担が少なかった。
  • 【高いモチベーション（教わる側）】「教えてほしい」と言ってくるだけの高いモチベーションがスタートの時点からあった。そのため、モチベーション管理などをする必要もなく放っておけば勝手に進めていた。
  • 【高いモチベーション（教える側）】とはいえ、負担が少ないとはいえ、QA の対応とかに自分もそれなりに時間を取って対応してた。教わる側が学習してきてる前提だと教える側も「これだけやってきてるので教えてあげたい」とモチベーションとなった。
• 🤩 学び
  • 学習者の高いモチベーションは大事
  • 人数を絞ることで距離感が近くなりダラケにくい

🚀【施策 ③】社内の少数精鋭の勉強会コミュニティ（その２）

• 施策
  • 今までの施策とは逆に自分に「Elixir 教えてあげるよ」と言ってくれる人がいたので、その人をメンターとして中心に少人数の勉強会を行った
  • 週に 1 回くらい業務後に 1h~2h くらいの時間を取ってもくもく会スタイルで学習した。学習者がそれぞれやりたいことを学習しわからないことが出てきたらにメンターに QA して進める方式。
• 結果：成功
  • 自分が Elixir 初心者の域を脱却して業務で使えるレベルになった
• 理由
  • メンターが言い出しっぺで結構な時間を作ってくれた。
  • その当時は残業時間がカオスな状態でもできたが、忙しくて出来ない週・日も結構あったが、それでもお互いに「やりましょう」と声掛けしてたら消滅しないで継続出来た。
  • そもそもこの勉強会を行う前に自分が個人で勉強していたのでモチベーション維持の必要がなかった。
• 🤩 学び
  • 周りを巻き込んで何かをしてくれる存在は大事。
  • ギブしあえる関係は大事。
  • 炎上プロジェクトをやりながらの学習はキツイ。

🚀【施策 ④】業務時間にて学習を兼ねた仕事を行う施策

• 施策
  • とあるプロジェクトのバックエンドチームのリーダーをやっていたときの施策。
  • 施策内容は「技術的に行ったことがない内容、または日々の業務を効率化するための仕事、を業務時間に自由に行ってもよい」を基本方針に「1 日 1h」「水曜日はフルでこれをやる」などの具体的な時間などもメンバーにお任せにした。
  • 打ち出した理由は、仕事内容がルーティンタスク化し始めた＋メンバーの疲弊とモチベーション低下を感じてきた、ので。
  • 狙いとして、いつも詰まれてしまうタスクを押しのける大義名分をメンバーは得られるので日々のルーチンタスク以外に新たなタスクを創造して行ってくれる、というもの。
  • タスク洗い出しは最初に自分が一通り出しておいて、この中から選んでも良いし自分でやりたいことを０ベースから決めても良い、というルールにしておいた。
• 結果：失敗
  • 全然ワークしなかった
• 理由
  • 【スキマ時間が無かった】前提としてプロジェクトが慢性的な炎上状態だった。徹夜や休日出勤してたりするレベルの状態だったので隙間時間はなく、このタスクを差し込めるだけのゆとりがなかった。
  • 【日々のタスクを押しのけるだけの力が足りなかった】日々の「こなす」タスクに忙殺されないようにこの施策を大義名分に使ってほしかったワークしなかった。ビジネス的な優先度もあり、中長期的な効率化よりも直近の問題解決が是となってしまう社内文化に打ち負けたところが強い。
  • 【根本改善活動を行うべきという意識不足】「日々のタスクをこなすことだけに必死になっている」というネガティブな状況をメンバーが客観的に把握していないように感じた。そのため、その発展として「じゃあ現実的にどう改善するか？」などのタスク洗い出しに繋がりにくかった。
• 🤩 学び
  • チームメンバーの自主性に依存したがよくなかった。ビジネス的なジャッジを行っている人にまで話を通してメンバーの時間が確保できる状況を作らないと厳しかった。

🗒 まとめ

• 時間的・精神的な余裕のある状態から始めないと成功確率が低い

  • なにかを行うにはまずは今行っている中のなにかをやめる必要がある。

    すでに「メンバーが炎上プロジェクトでオーバーワーク状態」がスタートだと、もはや削られるのは睡眠量などになってしまい現実的に継続しない。なので「どう進めるか？」ではなく、メンバーに時間的・精神的余裕があるか？という前提条件をクリアしていることを確認しておくのは大事だと思う。

• モチベーション維持の重要性

  • これらの学習コミュニティ継続のためにモチベーション維持は何より重要だと経験を以て理解できた。一番簡単な方法はそもそもモチベーションのある少数メンバーのみにすると、モチベーション維持という本質以外の活動に注力する必要がなくなる。

• 始めるのは簡単だが維持が難しい

  • 社内の人でも仕事を通じての知り合いはそこそこ出てくるので、そこらへんに声をかければコミュニティをスタートするのは思ったよりも簡単だった。

終わりに

約 1 年半くらいだったが炎上プロジェクトを渡り歩きながらもこれくらいの数の施策を行ってみた。

かなりライトなコミュニティの形成ではあったし寿命が短かったのでコミュニティ維持に関する経験は浅いがとはいえ、それなりに経験を得られた。

主催者としてコミュニティの維持をするコストや熱量を自分が算出していくのは大変なので、今後は外部の勉強会などに参加する形を取っていこうと思う。