エンジニアチームの生産性の高め方 ～開発効率を向上させて,人を育てる仕組みを作る（技術評論社） [電子書籍]

エンジニアチームの生産性の高め方 ～開発効率を向上させて,人を育てる仕組みを作る（技術評論社） の 商品概要

• ソフトウェア開発の世界では，生産性の向上は永遠のテーマです。ユーザーニーズの変遷や技術の進歩など，環境が変化し続ける中でいかにして効率的に開発を継続していくかは，多くのソフトウェア開発チームにとって切実な問題です。本書は，そのような問題に対する解決のヒントを提供することを目指しています。
  しかし，本書が提供するのは汎用的な解決策や，普遍的な理論ではありません。各章に記されているのは，それぞれの著者が，自身の経験と専門性をもとに導き出した，生産性を向上させるための具体的かつ実践的な自説です。生産性を向上させるための網羅的な解説書というわけではなく，むしろ多角的な視点からの提案と捉えてください。
  本書は2部構成になっています。第1部『開発プロセスと生産性』では，開発プロセスの改善をどう実現するかについて述べます。具体的には，Product Requirements DocumentやDesign Docといったドキュメント作成や，ブランチ・リリース戦略，リアーキテクト時のテスト戦略というトピックから，生産性を向上させる方法を解説します。第2部『開発チームと生産性』では，チームの立ち上げ，スキルの向上，開発基盤の改善というトピックで，開発者とその組織に焦点を当てて解説します。
  本書は，エンジニアリングマネージャーやテックリードを含む，開発生産性を改善したいと考えている方々に向けて書かれています。必ずしも，すべてを通して読む必要はありません。それぞれの章は，独立して理解できるように構成されているため，必要に応じて部分的に読むことができます。興味のあるトピックや現在直面している課題に関連する章を読み，そのアイデアをご自身のチームに採用してみてください。
  

• 目次

  第1章 Product Requirements Document
  1-1 Whatを書くPRD
  チーム開発の難しさ
  PRDとはプロダクトへの要求が書かれた文書
  PRDと似た文書
  1-2 PRDに記載すべき内容
  決まった章立てで書く
  代表的な章立て
  1-3 運用時の注意点
  PRDの書き進め方
  PRDを書く単位
  1-4 まとめ
  
  第2章 Design Doc
  2-1 Design Docとは
  コードレビューの限界
  書くべきか，書かざるべきか
  書くタイミング
  何を使って書くか
  ウォーターフォール開発の設計書との比較
  2-2 Design Docの構成
  構成の基本方針
  タイトル
  目次
  目的セクション
  背景セクション
  設計の概要セクション
  設計の詳細セクション
  計画セクション
  その他の関心事セクション
  Design Docのメタデータ
  2-3 運用上の注意点
  短いフィードバックサイクルを心がける
  タスクごとに使い捨てる
  ドキュメントへのリンクを活用する
  Design Docの共通認識を持つ
  Design Doc以外の選択肢を持つ
  2-4 まとめ
  
  第3章 ブランチ・リリース戦略
  3-1 現代のソフトウェア開発におけるブランチ・リリース戦略の重要性
  3-2 CI/CD（継続的インテグレーション，継続的デリバリー）
  CI/CDとは
  CI/CD実践のための考え方
  3-3 ブランチ戦略
  ブランチの種類と役割の定義
  代表的なブランチモデルの特徴と比較
  CI/CDとの関係
  featureブランチの扱い
  releaseブランチの扱い
  ケーススタディ：モバイルアプリのブランチ間オートマージ
  3-4 リリースサイクル戦略
  技術ドメインごとのリリースサイクル戦略
  最近のリリース戦略の傾向
  ケーススタディ：モバイルアプリのリリースサイクルアップデート
  3-5 リポジトリ戦略
  Polyrepo
  Monorepo
  選択にあたっての論点
  ケーススタディ：Monorepoベースの開発体験
  3-6 フィーチャーフラグの活用
  フィーチャーフラグの実装
  フィーチャーフラグの用途
  ブランチ戦略との関連性
  3-7 まとめ
  3-8 参考文献
  
  第4章 リアーキテクトにおけるテスト戦略
  4-1 リアーキテクトにおけるテスト
  検証と妥当性確認
  限られた開発期間におけるテスト
  4-2 リアーキテクトにおけるテスト戦略例
  リアーキテクトにおけるテスト戦略
  各工程詳細
  リアーキテクトにおけるテストの課題への対応
  4-3 ケーススタディ：出前館アプリリアーキテクトにおけるテスト
  出前館におけるソフトウェア開発
  実践結果
  注意点
  4-4 まとめ
  4-5 参考文献
  
  第5章 実践エンジニア組織づくり
  5-1 なぜエンジニア組織を作ることになったか
  筆者がやることになった経緯
  なぜ社内で開発したいのか
  社員として採用する必要はあるのか
  メガベンチャーから転職したらエンジニアが10人と少しの会社
  社内でサービス開発ができるようになるには何をすればよいか
  5-2 兎にも角にも採用
  エンジニアフレンドリーな会社にするために
  中途採用と新卒採用
  エンジニアだけ増えてもよくない
  5-3 定着と育成
  オンボーディングは大事
  定着のためにできそうなこと
  育成について
  5-4 開発と運用どっちもやる
  「実装だけをする開発組織」からの脱却
  運用支援ツールの導入
  技術的負債の返済は専任チームでやるべきか
  DevOps／SRE／プラットフォームエンジニアリング
  5-5 チームで動き，スケールさせる
  なぜ少人数チームを単位にするか，なぜチームの大きさはピザ２枚か
  いわゆる「大規模アジャイル」をいくつか
  フィーチャーチームかコンポーネントチームか
  アーキテクチャと組織構造，コンウェイと逆コンウェイの話
  全貌は誰が見るか。分割統治をしすぎると……
  コミュニケーションは大事。エスパーではない
  5-6 まとめ
  
  第6章 エンジニアリングイネーブルメント
  6-1 エンジニアリングイネーブルメントとは
  エンジニアリングイネーブルメントが目指す姿
  エンジニアリングイネーブルメントが必要な理由
  6-2 能力向上と成果向上
  能力向上と成果向上のためにチームを分化
  6-3 エンジニア職以外でのイネーブルメントの活動
  6-4 エンジニアリングイネーブルメントの活動の進め方
  エンジニアリングイネーブルメントの活動の外観
  6-5 開発プロセスの全体像
  開発ステップの定義
  開発プロセスの成功ファクターの定義
  開発プロセスの見直し
  6-6 能力向上のための仕組み
  スキルマップの作成
  チームのスキルの把握
  スキルマップに基づいた能力向上施策
  6-7 成果向上のための施策
  アウトカムを高めることが成果向上に必要ではなかったのか？
  ドキュメントの整備
  オンボーディングプロセスの整備
  ツールの整備
  6-8 エンジニアリングイネーブルメントは誰がやるべきか
  6-9 まとめ
  
  第7章 開発基盤の改善と開発者生産性の向上
  7-1 開発基盤の改善とは
  7-2 誰が基盤を開発するのか
  小規模なチームでの開発基盤
  大規模なチームでの開発基盤
  7-3 開発者生産性とは，価値提供の速度を高めること
  7-4 開発基盤の改善の様々な取り組み
  実装，価値検証のサイクルを高速化する
  オペレーション業務を省力化する
  開発上の迷いや不安点を減らす
  7-5 開発効率の改善のサイクルと全体像
  1. 抽象課題の発見
  2. 課題の具体化と改善策の発見
  3. メトリクスを使ったベンチマークの考案と検証
  4. 改善の実行
  7-6 抽象課題の発見（Step 1）
  プロダクトコードとの接触を増やす
  コードレビューを通した課題発見
  可能な限り自分で実装する機会を持つ
  プロダクト開発者との対話を通して課題を発見する
  7-7 課題の具体化と改善策の発見（Step 2）
  抽象課題：CIの実行時間が長い
  課題の具体化のアイデアを出すには
  7-8 メトリクスを使ったベンチマークの考案と検証（Step 3）
  開発者生産性とメトリクス
  定量化できないメトリクス
  生産性を定義するメトリクスの考案
  モバイルアプリ開発の生産性をSPACEフレームワークで定義する
  メトリクスを多次元的に評価する
  開発者生産性の定義のまとめ
  7-9 改善の実行（Step 4）
  開発基盤改善のアンチパターン
  他の開発者と協調していくために
  7-10 まとめ
  

エンジニアチームの生産性の高め方 ～開発効率を向上させて,人を育てる仕組みを作る（技術評論社） の商品スペック