エンジニアチームの生産性の高め方

https://m.media-amazon.com/images/I/813C9zuBFlL._SL1500_.jpg https://www.amazon.co.jp/dp/4297145022?tag=1000ch-22

第一部 開発プロセスと生産性

インターネットや Web が使われるようになり 30 年が経った、ソフトウェアは大きく複雑になり、その開発を遂行するチームは継続的な改善を求められる

なぜ開発するのかが最重要課題。市場調査・ニーズの分析・競合分析・財務的見積もりを Marketing Requirements Document にまとめる

何を開発するのか、Why の後半の工程で検討する。ニーズの特定・要求定義・優先順位・コンセプトの決定・フィードバックの収集を Product Requirements Document にまとめる。これがプロダクト開発における指針となる

誰がどこでいつまでに開発するのか。ウォーターフォール・アジャイル開発・リーン開発。アジャイル開発では、スクラムやカンバンを用いる

どのように開発するのか。ソフトウェアエンジニア・テストエンジニア・デザイナー・法務・情報セキュリティ・広報といったチームが統一された理解を共有し、効果的な協働を実現する

インターネットとデバイスの高性能化により、絶え間ないリリースが実現される。これに対応することを開発プロセスでも求められ、デプロイやリリースの効率化、継続的な品質の確保が鍵となる

これらの要素として、Product Requirements Documents・Design Doc・ブランチリリース戦略・リアーキテクトによるテスト戦略に焦点を当てる

Product Requirements Documents

PRD の存在がプロダクト開発に関わる全員の合意形成に導く。チームの参加者は多様な職種で関心も異なり、それぞれの矜持が存在する。それぞれの正解があってもプロダクトとして一貫していなければ、期待値に添えないものができあがる

PRD 製品要求文書はプロダクトへの要求 What を明確にする。なぜ開発するのかは Marketing Requirements Document で、どのように開発するのかは Design Doc で、誰が開発するのかとどこで開発するのかはプロジェクトマネジメントで明らかにされる

これによって、関係者の認識を統一し、プロダクト品質を向上させ、後で振り返ることを可能にする。似た文書に、プレスリリースやインセプションデッキ・基本設計書と外部設計書がある

PRD の章立てを統一する。概要・背景・製品原則・対象ユーザー・ユースケース・市場分析・競合分析・機能要求・技術要求・スコープ・KPI・スケジュールとマイルストーン・マーケティング計画

Design Doc

調査事項・設計と実装方針・開発者の考えなどをまとめた技術的な資料。何を書き書かざるべきか？の判断軸

タスクにかかる工数や複雑度

コードベースや環境に対する習熟度

ステークホルダーや関連要素の数や種類

選択肢の多様性

セキュリティやプライバシー、法律関連

何をするかが決まっていないと書けないので、PRD が固まった段階で書き始める。しかし、実際には PRD と密な関係になることも多く、変更に応じて Design Doc も短いフィードバックサイクルで追従する。実装へも同様

タスクの目的を明確にすること、トップダウンに理解できる構成であること。全体から部分、抽象から具体、概念から事例、事実から理由、原則から例外

Design Doc に限った話ではないが、ドキュメントの完成度を求めて時間をかけすぎない、WIP でもいいので協働で完成させていく

ブランチ・リリース戦略

ソフトウェア開発における統合（インテグレーション）はソースコードをまとめてビルドしテストするプロセス、展開（デプロイメント）は完成したソフトウェアを運用環境に配置し利用可能にするプロセス、構成管理（コンフィグレーション）はソフトウェアの構成情報を一元的に管理し変更履歴の追跡や特定バージョンの再現を可能にするプロセス

ソフトウェア開発全体における最重要事項ではない。この作る工程における最適化は進化し続けて出来て当たり前になり、優位なものではなくなっていく

ブランチ管理ポリシー、リリースポリシー、フィーチャーフラグ運用ポリシー、リポジトリ運用ポリシーといったポリシー群が生産性を高め、複雑な要求に効率的に対応するための基盤になる

Trunk-based development (TBD)、Git Flow、GitLab Flow、GitHub Flow など様々なブランチ運用があるが、昨今のプロダクトにおけるリリース頻度を踏まえて CI/CD を含めたイテレーションを作ることが肝要

常に主ブランチへの変更を行う TBD は、feature ブランチの生存期間を短くし、コードの統合とテストの頻度を高くする。そして CI/CD との親和性も高い

Backend/Frontend/Mobile といった技術ドメインごとに利用環境の特徴差異があり、リリースサイクルを検討する。リリース戦略の傾向として、任意のタイミングで頻繁にリリースしたり、リリーストレインを用いた頻繁なリリースがある

リポジトリを分割する polyrepo は高い柔軟性と自由度があり、依存関係もない故に全体的な協調を要する場合にコストが必要。ひとつのリポジトリで管理する monorepo は、コードの一貫性や再利用性を向上させ、依存関係を効率的に管理するが、スケーラビリティやアクセス制御といったリスクも孕む

フィーチャーフラグで実装中の機能をガードしたり、A/B テスト、キルスイッチ、特定のユーザーグループやパーセンテージベースのロールアウトなどに用いる。ブランチ戦力と合わせて検討する

リアーキテクトにおけるテスト戦略

テストは欠陥があることは示せるが、欠陥がないことは示せない

テストは計画し、分析し、設計し、実装し、実行する。機能ごとに優先度を算出して、分析や設計における重み付けを行う

出前館アプリのリアーキテクトのケーススタディ。PdM/PjM がステークホルダーを議論し要求定義を行う、その結果をバックログに案件として記載し、関係者と議論して優先度を決定する

プロトタイプとしてはじめて、既存アプリの改修と並行して進行した。既存アプリに機能追加がある場合、注意深く取り込む必要があるが、既存アプリの改修担当が新アプリにも取り込む責任を持つことでリスクを低減した

テスト分析と並行し、テスト対象の優先度を算出した。過去の障害報告書ならびにソースコードの複雑性を複合的に評価した

第二部 開発チームと生産性

第一部で取り扱った開発プロセスの改善を組織レベルで実践するには、文化の醸成が欠かせない。取り組むべき課題は大きく2つで、ソフトウェアエンジニアの採用とスキル向上、開発プロセスの標準化と組織文化の改善

一つのチームで取り組み効果を計測することも良いが、最終的には評価として一貫性をもたせる必要がある。一つの開発チームが取り組む、専門的な集団が実践する（チームトポロジーにおける複数のストリームアイランドチームにまたがって支援するイネーブルメントやプラットフォーム）、最終的に意見を集合しマネジメントがトップダウンに意思決定する

実践エンジニア組織づくり

内製化を目指す組織にジョインすることになり、組織づくりに取り組むことになった。VPoE としてプレイングはせず、組織づくりを中心としたマネジメントに専念した

日本は事業会社とシステム開発会社がわかれており、今もその流れは根強い。インターネットでビジネスが完結する事業が増えてきたことを皮切りに、社内で内製化を狙う会社が増えている

コストダウン

開発のスピードアップ

目的にあった良いシステムづくり

任せきりにすることの不安

社内に技術を蓄積する

ソフトウェアネイティブな会社に対抗したい

採用するエンジニアは社員である必要があるのか？雇用規制が強い日本においてはコストコントロールの側面もあるが、組織の基礎を作る上で社員として採用していくことは欠かせない。まず、業務委託の場合は式管理系統に置けない。そして、プロダクトカンパニーとしての目指す方向性への共感を求めにくい

開発の企画、デザイナーへの依頼、技術的な設計の相談、実装と QA、そして運用といった一連のプロセスを社内だけで回せるようにならなくてはならない

比較的流動性が高いと言われるエンジニア業界で、定着率を高めることはできるのか。オンボーディングを大切に、やりたい仕事だけを渡すようなことはしない、やりたがらない仕事を拾う人を評価する。新しいことをさせて、自分よりすごい人を置く。技術書購入の敷居を下げる

開発だけではなく運用も行う組織にする。DevOps、Site Reliability Engineering、プラットフォームエンジニアリング

なぜ少人数チームを単位にするのか。一人の伝説的なエンジニアは SPOF になりうる。一つのシステムを一つのチームが担当するのは理にかなっているが、規模が大きくなるにつれてそれは難しくなっていく、チームの集合体がマイクロサービス的な発想でひとつの大きなものを作り上げていく

チームの定義に、チームとして機能実装と価値提供を担っていくことがあるが、フィーチャー単位なのか（システム）コンポーネント単位なのかという対立がある。コンポーネント単位のチームはシステム開発を容易にするが、チームをまたいで使用を調整しなくてはならない。いずれにしても目的は価値のデリバリーであり、何らかのトレードオフがあるのでどちらが正解とは言えないのではないか

アーキテクチャは組織を左右し、組織はアーキテクチャを左右する（コンウェイの法則、逆コンウェイの法則）

失敗を経験すると「より綿密なコミュニケーションをとって再発を防ごう」という本能が働く。すべてのチームにコミュニケーションを取るとコストの泥沼になるが、チームごとに祖になりすぎると「組織の歯車」になってしまう。そこで、組織横断の事項にアサインしたり、目標を接続するフレームワークとして OKR があったりする

エンジニアリングイネーブルメント

エンジニアリングイネーブルメントは何も特別なものではなく、勉強会や輪読会などのエンジニアの能力向上を目論んだ組織的支援を指す。単なる能力や成果の向上だけではなく、どのエンジニアでも活用できる汎用性、日々の現場に活かせる実効性、を両立させる。そのためにはナレッジ・ノウハウ・トレーニングの実践が必要

イネーブルメントはエンジニア職に限った話ではなく、セールスイネーブルメントという流れが米国であるように、業務遂行の必要なスキルを定義し、教育コンテンツを提供することは発達している。一度「イネーブルメント」という領域を包括的に考える価値があるのではないか

開発プロセスの全体像を定義し、必要な能力を明らかにする。能力向上と成果向上に分けて施策を考え、実施する。開発プロセスそれぞれの成功ファクターが何かを、計画フェーズ・設計フェーズ・開発フェーズ・リリースフェーズ・運用フェーズに分けて定義する

能力向上に向けては、スキルマップを作成し、それを進むための道標を作る。定義したファクターの実践に必要なスキルが求められ、その到達水準としてレベルを用意する。プログラミングスキルだけではなく、プロダクトに必要な様々なドメイン知識を含めて良い。また、レベルは社内の等級水準に合わせても良い。

作成したスキルマップに応じて、メンバーの現在地を把握すると能力向上プラン作成に役立つ。それに基づいて、研修や勉強会を開催したり、モブプロやペアプロといった業務を通じて実施したり、費用補助によって自発性を促したり、横断チームへの移籍を通じてスキルの移転を行うなど

アウトプットではなくアウトカムにフォーカスすべきか？少ない努力で大きな成果を出す、いわゆる low-hanging fruits の話もあるが、いずれにしてもアウトカムの向上にはアウトプットが必要になる。木こりのジレンマ「刃を研ぐともっと早くたくさんの木を切れまよ」「気を切るのに忙しくて刃を研いでいる暇はない」

ドキュメントの整備と更新、オンボーディングプロセスの整備、オフボーディングプロセスの整備

開発基盤の改善と開発者生産性の向上

抽象課題の発見、課題の具体化と解決策の発見、ベンチマークの考案と検証、改善の実行、を繰り返す。開発基盤は、継続的デリバリーの推進、テスト基盤の整備、コーディング規約やアーキテクチャの導入、開発環境の整備などを指す。開発生産性とは、価値提供の速度を高めること

取り組みとしては、OpenAPI や Protocol Buffer などの導入により実装速度を高めたり、ビルド時間の短縮によって、実装にかかる時間を短縮する。それ以外のオペレーション業務によるオーバーヘッドにも目を向ける。開発上の迷いや不安を減らす

抽象課題の発見

プロダクトコードとの接触を増やす、レビューを通じて課題を発見、可能な限り自分で実装する、開発者との対話を通じて課題を発見する

課題の具体化と改善策の発見

例えば「CI の実行時間が長い」という課題にしても、コードのチェックアウトなのかツール類のビルドなのか依存関係の解決なのか、何がボトルネックになっているのかが明らかではない。要素分解し、仮設を立てる

メトリクスを使ったベンチマークの考案と検証

改善を実施してもどのような効果があったかわからない状態にしないために。一日あたりに書いたコード行数、コミット数、デプロイ回数、PR の数、open/close したイシューの数などが思いつくが、例えば品質の観点が欠けている。DX で語られるいわゆる感覚的なものは、数値化することが難しい

Four Keys では、デプロイ頻度、リードタイム、サービス復旧時間、変更失敗率というメトリクスが定義されている

GitHub や Microsoft が中心に発表した論文で提唱された SPACE では、Satisfaction & Well-being、Performance、Activity、Collaboration & Communication、Efficiency & Flow というメトリクス次元があり、これらを個人・チーム・システムの視点でメトリクスを定義する

改善の実行

基盤に集中しすぎると、特定領域への理解が薄れてしまう

プロダクトコードや手薄な部分にも理解を持ち、抽象課題を発見し続ける

定量化が局所最適を起こしてしまう

複合的なメトリクスを設定する

改善を優先して開発を止めてしまう

前方互換を重視した移行計画を設計する

過剰に規約や規律、正当性を重視してしまう

落とし所を明確にする

他者と協調するために

心理的に相談してもらいやすい環境を作る

こまめな状況の共有

夢を語る