はじめに
私は現在の会社でエンジニアリングマネージャーとしてエンジニア組織をマネジメントしています。
社内開発部が発足して1年程度のタイミングでジョインできたこともあり、組織が成長していく過程をエンジニアとマネージャー双方の立場で経験してきました。
今回の記事では、組織を向上させるため行われてきた施策の整理と内容の振り返りを行います。現状を整理し、改めてこれからを見つめ直すきっかけにしたいと考えています。
以下に当てはまる場合はより共感できる内容かと思われます。
- 社内で自社プロダクトを内製開発している
- 組織として発展途上にある
- 今後も組織を拡大する計画がある
振り返る中で良い点・悪い点どちらも出てきますが、それらが皆様にとって何かしらの参考になれば幸いです。
なぜエンジニア組織を向上させたいのか
本題へ入る前にそもそもの動機を簡単に説明します。
会社や組織が掲げるミッションは魅力的であると同時に難易度も高く困難がつきまといます。達成するためには人も組織も成長を続ける必要があります。
メンバーの成長をサポートしクラフトマンシップを発揮できるよう、組織の体制と開発者体験(Developer Experience)を向上させることが組織の生産性向上と将来のミッション達成につながる認識です。
組織が行ってきた施策
以下図に整理してみました。各施策に対して、関わる頻度とプロダクトかヒトかという属性で便宜的に分類しています。
整理した結果、プロダクト側で取っている施策に課題が多い点が傾向として見えてきます。なお、プラス評価をしている施策も改善のために取れるアクションはまだまだある認識です。
以降は各施策についての振り返りを羅列していきます。長いので興味を持った項目だけでも目を通してもらえれば幸いです。
各施策の概要と振り返り
各施策は「私」だけではなく、チームメンバーである「私たち」が話し合って改善のため取り組んできたものになります
記載する順番は図の右上から列に沿って左下へ向かう方向になります。
コード管理
- コードリポジトリのバージョン管理については私の入社当時からGitHubが採用されており、GitHub Actionsとの連携等も含め活用を継続していきたいと考えています。
- Gitフックとして
pre-commitを活用し、コミットメッセージの整形やブランチ-issue番号間の紐付けを自動で行っています。
改めて振り返ると、上記動作はずっと変更がなく何か改善の余地がありそうな感じがしています。
開発環境・H/Wスペック
- Gitフックと後述のリンターとフォーマッターの設定が可能ならエディターは自由としていますが、セットアップの容易さと利便性からVS Codeを使用しているメンバーが大半です。開発対象となるビジネス要件から、OS環境は残念ながらWindows固定となります。
- H/Wスペックは私が入社した3年ほど前から以下のように変遷してきました。※CPUの詳しい型番などは省略させていただきます。
「デスクトップPC;メモリ4GB;CPU4コア;HDD512GB」
-> 「デスクトップPC;メモリ8GB;CPU4コア;HDD512GB」
-> 「ノートPC;メモリ16GB〜;CPU12コア〜;SSD256GB〜」 + 「純正のドック」
当初はひどいもので、非IT業務スタッフと同様のマシンを使っていました。(だとしてもひどい……) 手頃にできるメモリ増設から上長へ提案し、その間にビジネス用ノートPCの最新ハイスペックモデルと純正のドックを買い足していきました。
タスク管理
- 現在はタスク(バックログやスプリントボード)管理としてJira Softwareを採用しています。
背景として、開発初期は参画人数も少なかったためGitHub上のissue、pull-reqベースでタスク管理は完結していました。プロダクトの拡大に伴い参画人数が増えるなかでタスク管理の重要性も増していき、スクラムに則った開発を効率的に推進するためJiraを採用しました。
スプリントごとのレポーティング機能やカスタムフィールドの追加と集計など、計測の観点からも便利な印象です。 - GitHub Actionsを活用することで、issue作成時にJiraのバックログも自動生成されるように運用しています。基本的にissueとバックログを紐付けてタスク管理をしています。
開発手法
- 基本的にアジャイルに開発を行い、フレームワークとしてスクラムを採用しています。ただし、厳密なスクラムが実践できているかはチーム内でも定期的に議論が行われ、現状はプロダクトの特性も踏まえスクラムバンのような手法に落ち着いている節があります。ここは今後も継続的に改善していくべき点だと認識しています。
部内情報の透明性
- 情報の非対称性が組織的な負債となることが、オンボーディングなどを通して強く周知されています。その際には心理的安全性と合わせてSECIモデルの重要性について共有しています。特に以下スライドがものすごく参考になるため助かっております。
- 部内の情報基盤としてGitHub上のWikiを長らく使っていましたが、最近はアクセスとコラボレーションの容易さからNotionへの移行が進んでいます。
情報の階層化が簡単で、階層ごとにゲストユーザーの追加やアクセス制限も可能です。部内だけでなく部外のメンバーとの情報共有にも活用できるため移行を進めています。
コミュニケーションツール
- テキストベースのコミュニケーションを重視しており、全社で導入しているTeamsを業務では活用しています。一部雑談系botとの連携のためSlackも使用しています。
- リモートワーク時のバーチャルオフィスとしてoViceを使用しています。oViceはかなり便利なのですが、口頭のみでやり取りが完結してしまうと情報の非対称性が増しかねないため、然るべき場所に情報も残すよう周知しています。
心理的安全性
- 以下記事の心理的安全性について記載した章が振り返りになります。
以下節で構成されています。
GKPTで賞賛文化と組織改善文化を醸成する
オンボーディングを活用する
1on1を活用する
働き方
- 課題が目立つと自己評価した働き方ですが、現状は完全出社の形態となっています。感染症対策としてのリモートワークとハイブリッドワークは過去に何度か組織として経験しており、今後も状況に応じて適宜適用されます。一方で平常時の働き方を変えるためには、組織を通り越して会社が変わる必要があるため困難さを感じています。
個人的には、優秀なエンジニアをコア人材として採用し定着させないと組織のさらなる成長や技術の蓄積が進まないと考えているので、会社には柔軟性を持っていてほしいです。 - 上記以外ではフレックス(コアタイムはあり)や昼休憩の入り時間が選択できるなど、それなりに自由には働ける認識です。
CI
- GitHub Actionsを活用してunit testの自動実行を行っていますが、テスト自動化範囲の拡大など向上すべき点がまだまだ残っている状態です。開発サイクルと品質向上のため、unitだけでなくintegration testや本番環境を模したテストもCIで流せるように取り組んでいる最中です。
IaC／CD
- CDを推進するため、開発周りのインフラのコード化と自動化は今後進めていきたい課題のひとつとなっています。開発しているプロダクトの都合上、リリースの自動化は現状のままでは一筋縄ではいかないことが見えています。
リンター／フォーマッター
- Pythonをメインで使用しているのでリンターとしてPylance、フォーマッターとしてBlackを導入しています。チーム開発を行う上で、コードの統一感(と可読性)を自動的に担保する仕組みは大切です。
コーディング規約
- 上述のリンターとフォーマッターに加えて、リーダブルコードをベースにしたコーディング規約を運用しています。
コードレビュー
- 各リポジトリへコードをマージするために必ずレビューを挟むルールとしています。プロダクトにもよりますが基本的にはレビューは二次まで行っています。(つまりレビュアーが最低2名) 一次レビューはそのタスクが属するプロダクトやプロジェクトのリードメンバー、二次レビューは全メンバーからランダムに選定することが多いです。
GKPT／振り返り
- 以前の記事でGKPTについて整理しています。スプリントから他イベントまで、振り返りフレームワークとして幅広く使用しています。
GKPTはKPTという振り返りフレームワークにG(Good)を追加したものになります。お互いにGoodを挙げることでメンバー間の賞賛文化が少しずつ醸成します。
振り返りMTGの際にはスプリント中にあったGoodとProblemを各自に発表してもらっています。その後は深堀りしたいProblemや既存のTryの実践状況について話し合い、TryとKeepを整理します。継続的にProblemとTryの話し合い続け、成果を積み上げることでチーム内に組織を改善しようという力学が生まれます。
1on1
- 上長との1on1を定期的に開催しています。チームメンバー数の多さとメンバーの習熟度から現在は月に1回程度ですが、希望するメンバーとは2週に1回など要望(と状況)に応じて期間を設定しています。
アジェンダや気をつけている点は過去記事をご覧ください。
- 相互理解と心理的安全性向上のため、メンバー同士の1on1も定期的に実施しています。
リファクタリング頻度
- 課題が目立つと自己評価した項目です。どうしても外部から求められる結果を短期的にこなす機会(攻めの開発)が増え、リファクタリングの頻度は低下傾向にあります。改善のため、リファクタ強化月間やスプリントなどを設定すること、ステークホルダーにリファクタリングの重要性をわかりやすく説明することが求められる認識です。
技術的負債の返済戦略
- 開発を進めていくなかで技術的負債は避けて通ることができない認識です。定期的な返済を続けるため、現状の把握から対策立案や優先順位付けなどの戦略と計画が都度必要になります。リファクタリング頻度と同じく、周囲を巻き込んで改善策を進めることが求められます。(言うのは簡単ですが継続的に実践することは大変です)
ペアプロ
- 課題のタイプやチームの状況によってペアプロを適宜行っています。VS CodeのLive Shareプラグインが便利なので、こちらで行う場合が多いです。(Teamsの画面共有でも可能)
組織の目標設定
- 年度単位で必ず組織の目標設定を行っています。目標は領域ごとに複数上げ、プライオリティを組織内で話し合う形で策定しています。組織の目標をブレイクダウンして個人の目標設定を行うため、組織の目標設定も全員参加で行っています。
LT会(勉強会)
- 2ヶ月ごとに部内LT会を開催しています。LTにしている理由は準備の負荷を上げず、発表のハードルを下げることにあります。以前から部内で勉強会を開催したいとの声はありましたが、個人の負荷が上がることもあり定着しませんでした。今のところLT会は定着しているので、文化として醸成が進めば良いなと思っています。
発表した内容をQiitaなどでアウトプットすることで、モチベーションの面でも相乗効果がある認識です。
評価制度
- 過去記事に詳細はありますが、評価者と被評価者双方が納得できる制度とするため見直しを行いました。今年度から運用中なのですが、色々と改善したい内容も出てきたので継続的なメンテナンスの重要性を実感しています。
エンジニア採用／広報
- 人材不足と評される昨今なのでエンジニア採用は苦戦しがちです。ダイレクトリクルーティングを活用し、エンジニアメンバーも採用に参画することで改善してきた面もあります。採用と合わせて、組織の魅力を広報し、知名度を高める必要もある認識です。(この記事も遠いところでは広報の一環です)
使用技術のバージョン更新
- プロダクトの規模が大きくなるなかで、言語やライブラリーなどのバージョン更新が滞るケースが出てきました。CIを強化しているのも、スムーズにバージョン更新作業ができる環境にしたいという思いがあります。
エンドユーザーとの距離感
- 社内用プロダクトの開発をしていてエンドユーザーとの距離は近いはずなのですが、なかなか開発に巻き込めないケースも散見されます。コミュニケーション頻度を増やせるように周囲をどう巻き込むか、最善パターンを模索しています。
社内教育コンテンツ
- オンボーディングと入社後研修には力を入れているのですが、実務配属後のコンテンツはまだ薄い部分があります。社内Wikiの情報整理やキャリアパスに応じた教育コンテンツ拡充などに取り組む予定です。
経営情報の透明性
- 開発組織がスピード感を持ってアジャイルに開発しているのに対して、経営側が考えていることや動いている内容について見えてこない状態が続くのはコンフリクトになると感じています。
(これは組織でどうこうできる問題ではないのですが……)
アウトプット文化
- 定期的なLT会の開催と合わせて、Qiita Organizationも始めました。自社テックブログほど敷居を上げず、まずはカジュアルにアウトプットする習慣が浸透すれば良いなという目的があります。作成した記事が会社だけでなく個人の資産となる点も良い点だと考えています。(なお、ZennでもPublicationという類似の機能がリリースされます)
- 上記を踏まえ、敷居の高い記事も増やしていくことが今後の改善点として考えられます。
- OSSコミッターのメンバーからノウハウを共有してもらうことで、OSSにコミットするメンバーも増えてきています。
中長期ロードマップ
- 年度単位の目標だけでなく中長期の目標も策定していますが、目標設定や目標達成に向けたロードマップ策定には弱みを感じています。年度単位よりも不確実性が増す中で、達成イメージが持てるロードマップをどう定義するか、振り返りや修正をどう取り込むかなど難易度が増す印象です。
ロールモデル
- 評価制度の刷新と合わせてキャリアラダーも見直しを行いました。(参考: 過去記事) 評価制度を運用する中で、こちらも定期的な更新が必要だと感じています。
書籍補助／学習補助
- 会社の書籍はかなり自由に追加購入できるため大半のメンバーが活用しています。ただし、現状は個人所有ではなく会社所有となってるので、ここは今後改善の余地があるかもしれません。
- 最近はオンライン上の講演会や勉強会が多く、この辺りも裁量をもって参加できる状態にあります。
Notionに勉強会ページを作っていて、各自で主体的に資料や内容をまとめたりもしています。
オンボーディング／研修
- 採用インタビュー記事や求人票にも記載しているように、オンボーディングと研修には力を入れて取り組んでいます。
資格補助
- 現状はエンジニア向け資格の補助が存在しないため、将来的な改善点のひとつだと考えています。(受託開発を行っているわけではないため、対外的にスキルを表明するニーズも会社として強くないことが背景として挙げられます)
個人で資格を取得しているメンバーも多数いるため、補助は組織のためになる認識です。