fkm_y' log

技術や日常のログ

チームを外注メインから内製メインへ切り替えた話

去年、現在所属する組織で「チームを外注メインから内製メインへ半年で切り替えたこと」について書いてみる。 PJ開始から約1年経過(完了後約半年)して振り返った結果のTipsがなにかに役立てば良い。

簡単に背景説明

  • 約1年前にエンタープライズな企業に入社したサーバサイドエンジニア
  • PMの経験はなし、管理職でもない
  • オウンドメディアの保守運用(内製)をするはずだったんだが…

プロローグ:内製できない!?

内製するつもりで入社したけど内製できる状態ではなかった。 主観も入るけどどんな状況だったか列挙してみる。

状況

  • 内製についてステークホルダーである事業責任者と合意が取れていない状態
  • バグ、障害は実サイトを利用して気付く
  • 社内の担当エンジニアは不在(ディレクターは2名)
  • タスクの可視化はされていない
  • ドキュメントは構築当初のものしかない
  • 開発環境はなし
  • 協力会社について
    • 窓口担当は技術者ではなくかつサイト仕様も疎い
    • 開発速度も速くなく不具合も多い
    • 開発費用も高額で費用対効果が見合っていなかった

課題がいくつもあり「内製どころではないのでは…」とも思ったけれどとりあえず年内にプルリクを出せる状態にしようという目標を立て少しずつ改善していきました。

入社2ヶ月目から怒涛の半年間を過ごすことになりました。

内部環境の環境整備

タスクの可視化

私が入るまではシステムのメンバーが2人だけだったので個々人でタスクを管理して会話すれば済んでいたようでした。ただ人数が増えるに従って状況把握が難しくなる未来が予測されたこと、日々の改善や定期的にチーム内の情報を共有する場が必要と考えスクラム手法の以下3つの導入を提案しました。

  • カンバン
  • 振り返り
  • スプリント

導入時に厳密すぎないルールで始めたことや説明スライドを作って丁寧に導入を進めたことは良かったと思います。 当初はカンバンにポイントを付けていませんでしたが現在はポイントを付けるようにしており、タスク量が多くなりすぎないように管理できる状態に出来たのもよかったです。また基本的なことですが打ち合わせ時のアジェンダも事前に作ってから始めるようにしたため効率化も出来たと思います。

ステークホルダー説得

入社時に内製の話は進んでいる話だったはずなのですがステークホルダーである事業責任者への話が済んでいない状態だったので説得、提案を行いました。

  • なぜ内製が必要であるかの説明
    • 社内にナレッジが残ること
    • PDCAが高速に回しやすくなること
    • コミュニケーションコストを下げられること
    • 金銭面でのコストも下げられること
  • 社内で開発できるエンジニアの人数が不足していたため、協力会社との共同開発体制で進めること

開発環境刷新

協力会社の変更

  • 既存協力会社との共同開発は断念し新しい協力会社と共同開発することにした
    • 開発用リポジトリが協力会社管理で共用も断られた
    • 実は2次請けまで存在しており1次請けに技術力がないことがわかった
      • 開発MTGで技術の話をしても要領を得た回答を得られず毎度持ち帰って回答
      • ソースコードのコメントなどからリポジトリが他社にあることがわかった

プロジェクトを進めるスタンス

スコープ

  • 最低限の引き継ぎを行い、デプロイ/リリース可能な状態にすること(システム全体を把握するのは後々の改修でコードを読んで把握する戦略にした)
    • 開発環境の構築
      • 開発フローのルール
      • 開発環境やステージング環境の設計/構築
    • リポジトリの移行
    • デプロイ環境の構築

良かったことの振り返り

  • 学習
    • PM経験なかったので学習しながら進めたのはよかった
      • 外部勉強会への参加
      • 書籍による学習 ※後述に参考図書あり
      • Web記事を読む
  • スケジュール
    • スケジュール草案を作ったら、メンバーの合意を得て進める
    • スケジュールにはバッファを設ける
    • マイクロマネジメントはしない
    • 基本は不確実性が高いところから順にスケジュール
      • 関係性が遠いところからって軸でも考えてた(社外 > 社内チーム外 > 社内チーム内)
  • コミュニケーション
    • 要点を絞って密に取る
      • 事前に何を決めるか決めてからMTG
      • SlackやZoomなどのツールを有効活用する
    • 基本は言語化(文章化)
    • 期日プレッシャーを掛けない
    • 小さな成功体験を積み重ねる

悪かったことの振り返り

  • 一人に役割が集中しすぎた
  • もっと技術的な知識の学習も必要
    • 知識不足起因で予定外の作業が発生した
      • スケジュールにバッファを設けていたので助かったが知識/経験があれば防げた

エピローグ:数カ月後…

  • 開発スピードは予定通り向上しシステムパフォーマンスも以下のように向上した
  • 不要なバッチ停止や非効率な処理の改善によりパフォーマンスも上昇
    • NewRelic APMトランザクションタイムを切り替え直後と半年後を比較した結果、速度が2/3になっていた
      • 150ms → 100ms
      • PV数はほぼ変わっていない
  • エラー数も激減した
    • 協力会社切り替え時点で月間75,000件超のエラーが発生していたが月間10件程度のレベルになった  * 切り替え直後はrollbarが2日程度で無料枠5000件を使い切っていた…
      • エラーレート換算だと 0.375% → 0.00005%
        • メディアは月間2000万PV
  • 何をしたか?
    • 特別なことはしてなくて以下を実施していた

参考図書

PM経験がなかったので書籍や外部勉強会で学習しながらプロジェクトを進めていました。その時に読んでいた書籍を一部紹介します。