小さい会社の開発組織をまるっと改善した

概要

タイトル通り。転職を機に2022年の1年間、開発組織の改善に取り組んできた内容とその結果です。
取り組んだ範囲が広いため、方針・取り組み内容・結果と分けています。
同じように小さな開発組織の改善にチャレンジしている方のヒントになれば幸いです。

前提

• 災害対応に関するWebサービスを提供している会社
• 外部提供しているサービスは5つ（+新規プロダクト開発）
• 共通チームもある（基盤、インフラ、情シス、テクサポチーム等）
• 事業の性質上、基本フルリモート。今後もフルリモートをベースに続けていく予定
  • （事業開発の合宿等、必要に応じて出社することもある）
• 多くのプロダクトが古い技術の組み合わせで作られていた
• 開発スタイルは属人化・閉じたコミュニケーションスタイルだった
• 技術部門の責任者としてオファー
• これまでの経験
  • iOS, Android, Webフロント, バックエンド開発
  • 開発チームの立ち上げ複数回。（新規サービス、共通プロダクト、事業化検証チームなど）
  • エンジニア、リーダー、技術責任者、PdMなど、様々な立場でチャレンジさせてもらってきた
• 転職を機に、 会社の技術に関すること全ての方針決定・ 技術部門全体を見る ことになった

方針

施策を行う上で、下記の3点を心がけました。

1. とにかくチームで進める。チーム開発。
   なぜなら

• 属人化は 担当者の能力の限界 そのプロダクトの限界 になってしまう傾向がある
• 人はミスをする生き物。一人・少人数で閉じて相談できない状況では、かけた労力の割にクオリティが下がる傾向にあるからです。

2. 教え合う姿勢・壁打ち相手になる姿勢を応援・評価する
   なぜなら

• 協力する雰囲気が醸成されると、組織で開発するスケールメリットが大きくなる
• 教え合えば楽にスキルアップできる🕺
• 経験年数が短くても、特定のFramework・API等を集中して使っていれば誰よりも詳しくなることはよくある。
• 会話がきっかけで新しいアイディア※が生まれることが割とある。
  ※技術的なアイディア・事業のアイディア
• 教えることは無理だと感じても 積極的に壁打ち相手 になることで結局教え合う雰囲気が醸成される

3. 心理的安全性->自律した行動を取れるようにしていく
   なぜなら

• 私一人で全ての6つのプロダクト・9つのチームの細かい設計・実装・取り組みを進めることは不可能。ボトルネックになるだけと分かっていた。
• 組織としての方針・チーム間の調整等、 このポジションだからこそ発揮できる価値提供 に注力する方が良さを活かせる。
• 主体性を持って能動的に取り組んだ方がイノベーションも生まれ、成長しやすいため。

これまでの組織

• 少人数の担当者制開発スタイルだった。（のでやめた）
  • 担当者の負荷が高まると、開発着手の見通しも立てられなくなる状態だった。
  • 開発項目が集中すると、
    →積み上がったタスクを見る
    →頑張っているけど進んでいないように見える
    →結果、ストレスが大きくなっていた。
• DMやプライベートチャンネルでの会話がほとんど。そのために連携が取れていないことがよくあった。（のでやめた）
  • 担当者間でお互いにボールを持っていて進めていると思ったり、その逆が発生したりと、作業を効率的に進められていなかった。
  • 会話に入っていない人が方針決定に影響するような情報を持っていて、取り組んできた方針がひっくり返ることもあった
• PRのレビュー・マージを社員に限定していたチームもあったが、それによる弊害が発生していた（のでやめた）
  • レビュワーの得手不得手によるレビュー品質のばらつき。
    • レビュワーはレビューが中心となっているので、技術力が上がりにくい傾向。
    • レビュワーのテンションが低下する
• 障害対応をインフラチーム中心で行なっていた。（のでやめた）
  • 細かいコードの内容まで知っているわけではないので、対応に限界がある（めちゃめちゃ頑張ってくれていました）
  • 小さい範囲であっても設計・実装変更をしないと根本解決できない内容に対応することが難しい

取り組み内容

• エンジニア採用を集中して行い、チーム開発できるようにした。
  • 業務委託の方・正社員の方ともに。
    • 手を挙げてくれたエンジニアの方にカジュアル面談/面接/採用プロセスに入ってきてもらった🙋
      • 採用チーム結成。定例。定例以外でも随時会話。
    • 選考方法の改善を続けた。
• コミュニケーション
  • DMでのやり取りを原則禁止にし、slackのpublic channelでの会話をルール化
  • 各チーム、日次定例を行うようにした。
  • gather.townの導入。
    • それまでもzoomやSlack、Discord等色々試してきたものの、私達のフルリモート環境に合ったスタイルはバーチャルオフィス。
    • 導入しただけでは活用できず、離席エリア・集中エリアに居る人以外には「いつでも」話しかけてオッケーといったルールを導入した。
    • 基本ルールは全チーム同じ。チームを超えて話かけられるように仕組みを作った。
  • 勉強会やブログ、システム関連携等、会話が生まれるような施策を行なった。
• 開発文化の構築
  • 相互レビューの導入。PRのレビューもチームで。
  • 障害対応を開発チームで行うように変更
  • 仕事の効率化・スキルアップを応援する制度の導入
  • 貸与制度の構築
    • これまでも貸与はしてきましたが、明文化されていなかったことで言いにくい雰囲気がありました。
    • 貸与制度の申請フォームをGoogleFormで作ることで申請しやすい制度とした。
    • 対象機材はPC、ディスプレイ、キーボード、ディスプレイアーム、イヤホンマイク、カメラ、ソフトウェアライセンス、書籍、GCP・AWSのプロジェクト・アカウント・・・などなど。
    • PCは基本フルスペックに近いものを選ぶ
  • 勉強会の推奨。勉強会運営チームを募集。
  • 技術ブログ制度を開始。技術ブログ運営チームを募集。
  • オンライン飲み会の推奨。補助。
  • 失敗しても心のダメージが小さくなるように開発・調査研究項目を設定。
    ->最初は小さくお任せ。だんだんお任せする範囲を大きくするようにした。

結果

• 属人化していたタスクが減った。
  • 0にはなっていないが、気軽に相談できるような状態になった。
• 大小を問わない技術的なチャレンジ をほとんどの方が行うようになり、組織の技術力が向上した。
• チーム横断で技術についての会話をするようになり、多くの方がチームを超えて教え合うことを意識してくれている状態になった。
• 障害対応・パフォーマンス・監視に対する意識も高まり、相互レビューも盛んになった。
• 技術レベルの高いエンジニアが入社・参加してくれるようになり、元から居た方の技術力向上も相まって技術レベルが上がり続けるサイクルが出来上がりつつある。
• 組織の文化をみんなで作る雰囲気が芽生え、勉強会運営チーム、ブログ運営チームが立候補で集まる。
• Gatherの運用の改善なども興味のある人の参加してもらえるようになった。
  （PublicチャンネルやGather上で声かけ。雇用形態関係なく参加してもらえている）

まとめ

大変なこともありましたが、会社の技術部門をまるっと改善する役目は貴重な経験でした。
各Webサービスの方針をプロダクトチームで行うことになったため、結局技術だけではなくプロダクトの方針にも関わるようになり、それ以降は更に 考える->アクション が格段に増えて面白い1年を過ごせたと思います🕺

日中は打ち合わせが多いため、振り返ると平均して6hour/dayくらい打ち合わせをしていました。
技術的な取り組みは定時後や土日に取り組むことがほとんど。
そうして作った時間で（自分にとっての）新しいFramework・APIを触って遊んだり、開発チームで採用予定の技術を試したり。
手を挙げてくれたメンバーと一緒に、土日に集中してペアプロリファクタリングをしたのも楽しかったですね。
そんな感じでとにかく時間を捻出して技術的なキャッチアップ・チャレンジを続けています。
そもそも技術に触れることに楽しく感じる性格ですし、それがマネジメントにも効いているとも感じています。

昔からいたメンバーにとっては開発スタイルがガラッと変わり、ストレスも大きかったと思います。
それでも今では楽しんでくれているようで安心しています。
新しく入ったメンバーも馴染むのが早く。一安心。
改善後の組織は多くの人から様々な提案があり、能動的に様々な取り組みをしてくれています。

ポイントは 心理的安全性を持ったままチャレンジをしやすくする 皆でスキルアップをする文化 皆で組織を作っていく雰囲気 で、
個々の良さ・能力を引き出すことを重視して改善を行ったことが良かったのだと思います。
まだまだ課題・改善ポイントはありますが、
楽しくチャレンジしているメンバーの姿を見ると、目指す組織像に一歩近づいたかなと思えた1年でした🕺