「はじめて「スクラム」をやることになったら読む本」は、スクラムを実践するための手引きとして増補改訂されました。スクラムの基本概念やルールをわかりやすく解説し、架空の開発現場を題材に実践的なプラクティスを紹介しています。2017年版のスクラムガイドに対応し、最近の開発現場に向けた内容に更新されています。これからスクラムを始める人や導入に苦労している人に適した一冊です。

本書『アジャイルサムライ』は、ソフトウェア開発におけるアジャイル手法を紹介しており、顧客に価値を提供するプロフェッショナルとしてのアプローチを解説しています。内容はアジャイルの基本、方向づけ、計画、プロジェクト運営、プログラミングに関する各部に分かれており、著者は実務経験豊かなアジャイルコーチたちです。

本書は、日本の現場に寄り添ったアジャイル開発の実践を紹介しています。ITエンジニアの江島が、問題の多いプロジェクトを改善するために自らの仕事を見直し、同僚と共に業務改善に取り組む姿を描いています。個人からチーム、さらには全体を巻き込む改革の過程を通じて、アジャイルの考え方やプラクティスを学ぶことができます。初心者から実践者まで幅広い読者に向けた内容で、具体的な手法も紹介されています。

この文章は、アジャイル計画に関する書籍の目次と著者情報を紹介しています。目次は、問題設定からスケジュール作成、情報共有、アジャイル計画の成功理由、ケーススタディまでの7部構成です。著者の安井力はアジャイル手法の専門家で、コーチングやメンタリングを通じてチームの支援を行っています。角谷信太郎は日本Rubyの会の理事で、チーフプログラマとして活動しています。

エンタープライズにアジャイル開発を導入しようとしているすべての人に。 企業にアジャイル開発を導入するときに、何が障壁となり、何が課題となり、どのように取り組んでいけばその中で成功がつかめるのか？ アジャイル開発を成功させるためのチーム作り、プロジェクトの進め方、プランニングからリリースまでの流れ、開発時に必要な技術、評価と改善まで、徹底的に解説。 エンタープライズでのアジャイル開発の実現に向けて様々な経験をし、度重なる試行をしてきた執筆陣が、その実践の中で得た知見とノウハウをこの一冊に凝縮しました。 前半は「導入編」として、「チームを作る」「開発の準備」「開発」「評価と改善」など、それぞれの場面でのアジャイルの理想と現実、そしてどうしたら上手くいくか、を説明しています。これらを参考に、是非、読者自身の組織やチームに適用してみてください。 後半は「実践編」として、「要件管理」「アジャイルで求められる開発技術」「品質管理」「構成管理」「DevOps」「プロジェクト管理」などのトピックを解説しています。 「アジャイルに必要な考え方やプロセスだけでなく、エンジニアリングの解説もしています。これまでの私たちの経験のなかで、アジャイルの実践においてはプロセスだけに力を入れても上手く実践できないことを学んだためです。プロセスとエンジニアリングを両輪として実践していく必要があります。プロセスとエンジニアリングの両方が書かれていることも本書の特徴です。 本書を読んだあと、アジャイル導入に関するあなたの悩みや課題が解消でき、よいプロダクトができ、顧客へさらなる価値が提供できることを期待しています。」（著者「はじめに」） Introduction 1　アジャイル開発の守破離 2　ソフトウェアのビジネス価値 3　アジャイルを始める前に理解しておくべきこと 4　我々の知っているアジャイル開発 5　アジャイル開発のフレームワーク 6　アジャイル開発についてよく聞かれる2つのこと 導入編 Chapter1　チームを作る 1-1　メンバーを集める 　　　1-1-1　プロダクトオーナーを決める 　　　1-1-2　プロダクトオーナーの権限 　　　1-1-3　開発チームのメンバーを集める 1-2　チームビルディング 　　　1-2-1　メンバーの適切な関係を作る 　　　1-2-2　目標に対して一丸となる 1-3　環境を整える 　　　1-3-1　ステークホルダーのサポートを受ける 　　　1-3-2　快適な作業環境を準備する Chapter2　開発の準備 2-1　プロジェクトの方針を決める 　　　2-1-1　方針の決め方 　　　2-1-2　プロジェクトを管理する方法 　　　2-1-3　関係者の認識を合わせる 2-2　プロダクトバックログの作成 　　　2-2-1　プロダクトバックログアイテムを作成する 　　　2-2-2　アイテムの優先順位を決める 　　　2-2-3　リリースのタイミングを決める 2-3　開発のスタートができる状態にする 　　　2-3-1　開発環境を構築する 　　　2-3-2　開発のリハーサルをする 2-4　ステークホルダーへの説明 　　　2-4-1　ステークホルダーへの説明 Chapter3　開発 3-1　イテレーション（スプリント）のプランニング 　　　3-1-1　プランニングの準備 　　　3-1-2　プランニングで目標とスコープを決める 　　　3-1-3　プランニングで開発作業の計画を立てる 3-2　バックログアイテムの実装 　　　3-2-1　リリースまでの開発の進め方 　　　3-2-2　開発中のコミュニケーション 　　　3-2-3　設計 　　　3-2-4　コーディング 　　　3-2-5　他のシステムとの連携 　　　3-2-6　テスト 　　　3-2-7　デイリースクラムの開催 　　　3-2-8　ドキュメントの作成 　　　3-2-9　開発したソフトウェアのレビュー/ 受け入れ 3-3　ソフトウェアのリリース 　　　3-3-1　計画した通りにリリースする 3-4　プロジェクトの管理 　　　3-4-1　品質の管理 　　　3-4-2　プロジェクトの進捗管理 　　　3-4-3　スプリントの進捗管理 　　　3-4-4　バージョン管理 　　　3-4-5　ステークホルダーへの報告 3-5　運用 　　　3-5-1　運用フェーズへの移行 Chapter4　評価と改善 4-1　ソフトウェアの評価と改善 　　　4-1-1　ソフトウェアの評価 　　　4-1-2　ソフトウェアの改善 4-2　組織の評価と改善 　　　4-2-1　組織の評価 　　　4-2-2　組織の改善 4-3　開発チームの評価と改善 　　　4-3-1　開発チームの評価 　　　4-3-2　開発チームの改善 実践編 Chapter5　要件管理 5-1　プロダクトオーナーの役割 　　　5-1-1　プロダクトオーナーの役割・責任 5-2　インセプションデッキ 　　　5-2-1　インセプションデッキを作成する理由 　　　5-2-2　エンタープライズならではのナレッジ 　　　5-2-3　インセプションデッキの活用 5-3　プロダクトバックログの概要 　　　5-3-1　プロダクトバックログとは 　　　5-3-2　プロダクトバックログを見える化する方法 5-4　プロダクトバックログの作り方 　　　5-4-1　ユーザーに届けたい価値を整理する 　　　5-4-2　ユーザー像の深堀り 　　　5-4-3　ユーザーストーリーマッピング 　　　5-4-4　プロダクトバックログアイテムを作る 　　　5-4-5　プロダクトバックログアイテムの見積り 5-5　フィードバックを集める 　　　5-5-1　背景にある考え方 　　　5-5-2　ユーザーのフィードバック 　　　5-5-3　フィードバックを集める Chapter6　アジャイルで求められる開発技術 6-1　オブジェクト指向 　　　6-1-1　オブジェクト指向の基本 　　　6-1-2　アジャイルで必要なオブジェクト指向の考え方 6-2　デザインパターン 　　　6-2-1　デザインパターンの基本 　　　6-2-2　アジャイル開発で効果を発揮するデザインパターン 6-3　テスト駆動開発 　　　6-3-1　テスト駆動開発の必要性 　　　6-3-2　テスト駆動開発のしくみ 　　　6-3-3　テスト駆動開発で利用するツール 　　　6-3-4　テスト駆動開発の本質 6-4　リファクタリング 　　　6-4-1　リファクタリングとは 　　　6-4-2　コードの臭い 　　　6-4-3　リファクタリングカタログ 　　　6-4-4　リファクタリングツール 6-5　ペアプログラミング 　　　6-5-1　ペアプログラミングとは 　　　6-5-2　モブプログラミング 　　　6-5-3　リモートでのプログラミング 6-6　アーキテクチャ設計（マイクロサービス） 　　　6-6-1　サービス化の検討 　　　6-6-2　マイクロサービスの効果と支えるしくみ 　　　6-6-3　サービスメッシュについて 6-7　マイクロサービスの採用と組織 　　　6-7-1　マイクロサービスの概要 　　　6-7-2　アジャイルの組織とマイクロサービス Chapter7　品質管理 7-1　アジャイルの品質管理 　　　7-1-1　アジャイル開発の品質課題 　　　7-1-2　アジャイル開発の品質管理の基本 　　　7-1-3　エンタープライズで押さえるポイント 7-2　テスト技法 　　　7-2-1　アジャイルテストの分類 　　　7-2-2　Q1 エリア: テクノロジー観点の開発支援テスト 　　　7-2-3　Q2 エリア: ビジネス観点の開発支援テスト 　　　7-2-4　Q3 エリア: ビジネス観点のプロダクト評価テスト 　　　7-2-5　Q4 エリア: テクノロジー観点のプロダクト評価テスト 　　　7-2-6　アジャイルテストの重要ポイント 7-3　ソフトウェアメトリクスの収集と改善 　　　7-3-1　ソフトウェアメトリクスによる品質チェック 　　　7-3-2　ソフトウェアメトリクス収集の仕方 7-4　アジャイルの品質報告 　　　7-4-1　ウォーターフォール開発との成果物比較 　　　7-4-2　アジャイルの品質報告 Chapter8　構成管理 8-1　分散型バージョン管理 　　　8-1-1　分散型バージョン管理とは 8-2　Git 　　　8-2-1　Git 誕生の背景 　　　8-2-2　ノンリニア開発のための分岐システム 　　　8-2-3　Git の仕組み 　　　8-2-4　基本操作 　　　8-2-5　ブランチモデル決定の3 つのポイント 　　　8-2-6　主要なブランチモデルの概要 8-3　まとめ Chapter9　DevOps 9-1　DevOpsとは 　　　9-1-1　背景 　　　9-1-2　DevOpsの考え方 9-2　DevOpsのためのインフラ構築の自動化 　　　9-2-1　クラウドのリソースの構築/管理を自動化する 　　　9-2-2　ミドルウェアの構築/ 管理を自動化する 9-3　DevOpsのためのアプリケーション開発の自動化 　　　9-3-1　基本となる技術 　　　9-3-2　自動化の種類 　　　9-3-3　チームや組織に合致した自動化の選択 　　　9-3-4　自動化を実現する構成 9-4　DevOpsを導入する 　　　9-4-1　エンタープライズのDevOpsの問題点 　　　9-4-2　DevOps の準備 　　　9-4-3　DevOps の環境を試運転する 　　　9-4-4　DevOpsを実践する 9-5　組織のパフォーマンスを高めるための体制 　　　9-5-1　エンタープライズに多い組織体制 　　　9-5-2　従来の組織体制が引き起こす問題 　　　9-5-3　パフォーマンスを向上させる組織体制への変更 Chapter10　プロジェクト管理 10-1　プロジェクトプランニング 　　　10-1-1　ウォーターフォール開発 　　　10-1-2　アジャイル開発 10-2　体制作り（チームビルディング） 　　　10-2-1　ウォーターフォール開発での体制作り 　　　10-2-2　アジャイル開発での体制作り 10-3　開発の進め方（リリース計画） 　　　10-3-1　Quality（品質） 　　　10-3-2　Delivery（スケジュール） 　　　10-3-3　Cost（お金） 10-4　まとめ Conclusion　本書のまとめ 　　　1　魔法の杖ではない 　　　2　アジャイルの導入をはじめる 　　　3　アジャイルのチームづくり 　　　4　改善サイクル 　　　5　BizDevOps 　　　6　最後に

この文章は、エクストリームプログラミング（XP）に関する書籍の目次と著者情報を紹介しています。第1部ではXPの実践や価値、原則について探求し、第2部ではXPの哲学やその起源、適用方法について論じています。著者はケント・ベックとシンシア・アンドレスで、彼らはソフトウェアエンジニアリングや組織行動学の分野での専門家です。また、角征典はアジャイル開発の導入支援を行うプログラマーです。

エイミー・エドモンドソン教授の著書は、心理的安全性を重視した新しいチームワーク「チーミング」を提唱しています。著者は20年以上にわたり多様な組織を研究し、変化の時代における効果的なチームの作り方を解説。特に、流動的なチーム構成や学習を重視し、成功するためのリーダーシップや組織作りについて述べています。本書は、現代のチームが機能するために必要な要素を探求する内容となっています。

この書籍は、対話を変えることでアジャイルな組織文化を築く方法を解説しています。オープンな自己表現と相手理解を促進する「対話診断」を用い、信頼と心理的安全性を築きながら共通の目標に向かう会話の進め方を提案。具体的には、信頼の構築、心理的安全性の確立、目的の共有、コミットメントの構築、説明責任の遂行という5つの対話ステップを実例を交えて紹介し、日々のコミュニケーションを通じて組織のエネルギーを高める方法を示します。リーダーやチームメンバーにとって必携の一冊です。

この書籍は、官公庁の大規模システム開発におけるカンバンシステムを用いたプロジェクト進行を、著者の実体験を基に描写しています。リーンソフトウェア開発の実践方法を具体的に解説し、プロジェクトの構成やチーム編成、デイリーミーティング、カンバンボードの活用などを紹介しています。著者は、開発とマネジメントの経験を持つコンサルタントであり、アジャイル開発の技術や戦略についても詳しく述べています。

チームづくりをストーリーで学ぼう！ スクラム・アジャイルを導入した現場で直面するチーム・マネジメントの問題解決を詳説。 「ともに考え、ともにつくる」――スクラムやアジャイルを導入した現場で 直面する開発チーム・マネジメントの問題に立ち向かうすべ、 チームづくりの要点をストーリーで学ぼう！ 【本書の特徴】 ・現場のストーリーから、考え方とプラクティスを一緒に学べる ・単一チーム、複数チームなど、様々なチーム・マネジメントの問題を扱う ・日本の現場を前提にしているので、実践しやすい ・アジャイルをこれから始める人だけでなく、もっとうまく実践したい人にも最適 【本書に登場するプラクティス】 出発のための3つの問い ／ 段階の設計 ／ ドラッカー風エクササイズB面 ／ 割れ窓理論 ／ フォーメーション・パターン ／ コンウェイの法則 ／ 越境のデザイン ／ 重奏型仮説検証　ほか 【あらすじ】 チームによるプロダクトづくりができる環境を求めて “太秦（うずまさ）”が転職した先は、デベロッパー向けのツールを開発、提供する、 小さなベンチャーだった。しかし会社期待のタスク管理ツールを開発するチームに 配属され、いきなりチームリーダーをつとめることに。 ……とうていチームとは呼べない“グループ”（個人活動の集合）の状態から、 本当のチームになれたと思ったのもつかの間、経営陣はタスク管理を含めた 3つのツール統合を発表。太秦はそれらプロダクトの統合を行う開発リーダーを 任されたのであった。 チームとは何か？、チームのファーストとは？、分散チームへの適応など様々な 「単一チームの問題」、複数のプロダクト統合に伴うチーム間の断絶や衝突、 チームが上手く連携できないなど様々な「複数チームの問題」……これらを乗り越え、 太秦たちがたどり着いた「ともに考え、ともにつくる」とは？ 推薦のことば ・私たちは他者を必要としている｜宇田川元一 ・その先へ！Beyond the Agile｜新井剛 第1部　僕らが開発チームになるまで─1チームのジャーニー □単一チーム 基本編 ・第01話｜グループでしかないチーム ・第02話｜一人ひとりに向き合う ・第03話｜少しずつチームになる ・第04話｜チームのファーストを変える □単一チーム 応用編 ・第05話｜チームをアップデートする ・第06話｜分散チームへの適応 ・第07話｜チームの共通理解を深める ・第08話｜一人の人間のようなチーム 第2部　僕らがプロダクトチームになるまで─複数チームによるジャーニー □複数チーム 基本編 ・第09話｜塹壕の中のプロダクトチーム ・第10話｜チーム同士で向き合う ・第11話｜チームの間の境界を正す ・第12話｜チームの境界を越えてチームをつくる □複数チーム 応用編 ・第13話｜チームとチームをつなげる ・第14話｜クモからヒトデに移行するチーム ・第15話｜ミッションを越境するチーム ・第16話｜ともに考え、ともにつくるチーム 付録　リーン・ジャーニー・スタイルのプロダクト開発

本書は、初心者向けのシステム開発解説書で、発注者と受注者の視点を両方考慮し、システム開発の全体像を理解するための基礎知識を提供します。関係者間の認識のズレを解消し、円滑な連携を促進することを目的としています。内容は、1週間でシステム開発の重要な局面や注意点を学べるよう構成されています。システム開発初心者にとって、役立つ一冊です。

第1部 XP概要(XPとは ソフトウェア開発とは 従来の開発手法とXP XPの考え方) 第2部 開発プロセス(XP開発の流れ) 第3部 プラクティス(プラクティスの変遷 全員同席 計画ゲーム ユーザテスト 短期リリース シンプル設計 ペアプログラミング テスト駆動開発 設計改善:リファクタリング 常時結合 コード共同所有 コーディング規約 メタファ 最適ペース プラクティス以外の項目) 第4部 まとめ(XPの開発事例 XPが困難な開発 今後のXP)

アジャイル開発の概要から，エクストリーム，スクラムを使った開発プロセス，リスクマネジメント，開発事例まで網羅した指南書 アジャイル開発の指南書 アジャイル開発は従来のウォーターフォール型とは対照的に顧客にとって価値の高い機能を優先し，迅速・適応的な開発が行えるが，我国ではまだ開発手法の主流であるとはいいがたい．本書は今後導入が期待されているこのアジャイル開発の概要から，エクストリーム，スクラムを使った開発プロセス，リスクマネジメント，開発事例まで網羅した指南書とである．ソフトウェア開発者必携の書である． 1.アジャイル開発の現状と課題 2.アジャイル開発の概要 3.アジャイル開発の特徴 4.アジャイル開発プロセス 5.アジャイル開発の効果とリスク 6.上流工程を組み込んだ拡張アジャイル開発 7.アジャイル開発の事例 補遺：P2Mプログラムマネジメントとアジャイル開発 参考文献 付録1.アジャイル開発に用いられる自動化ツール 付録2.コードの不吉な匂い

本書は、理解しやすいコードを書くための方法を紹介しています。具体的には、名前の付け方やコメントの書き方、制御フローや論理式の単純化、コードの再構成、テストの書き方などについて、楽しいイラストを交えて説明しています。著者はボズウェルとフォシェで、須藤功平氏による日本語版解説も収録されています。

本書は、アジャイル開発の基本をストーリー形式で学べる内容で、特に過去にアジャイルに挫折した人にも適しています。主人公の相良真希乃が大手メーカーでの異動を通じて、問題だらけの現場をアジャイル手法で改善していく様子を描いています。アジャイルとウォーターフォールの共存を実現し、チームワークや部署間の連携を促進する方法が紹介されています。読者は、実践的なテクニックやキーワードを通じて、変化に対応し、競争力を高める手法を学ぶことができます。

アジャイル開発はスピードの速いビジネスに迅速に対応する新しい開発手法です。今までは中小規模のプロジェクトでの採用に留まっていたアジャイル開発手法ですが、いよいよ大手ベンダーもアジャイル開発手法の導入に本腰を入れてきました。本書はこれからアジャイル開発のマネジメントをしていく方のために、導入のポイントをコンパクトにまとめたハンディな解説書です。アジャイル開発のメリットを最大限に生かし、一歩先行く開発スタイルをいち早く確立したい方のための必読書です。 1章 日本におけるソフトウェア開発の課題(日本のソフトウェア開発の実態 開発工程別の職種とプログラマ ほか) 2章 アジャイル開発手法とは(反復でビジネスリスクを制御する ビジネス視点で小さな開発を積み重ねる ほか) 3章 アジャイル開発手法導入のポイント(アジャイル開発手法導入のポイント クラウドでアジャイル開発をしよう ほか) 4章 アジャイル開発の実際(アジャイル開発の始め方 要件調整と進捗管理 ほか)

世界のエンジニアが支持するプロジェクト運営法「スクラム」。その生みの親が、あなたのチームで今すぐ実践する方法を解説。住宅リフォームから宇宙船の開発まで、あらゆる現場に革命が起きる！　

本書は、アジャイル開発の普及が進む中で、自己組織化や奉仕型リーダーシップを基にした新しいマネジメントのスタイル「マネジメント3.0」を提案しています。複雑系の科学やマネジメント理論に基づき、組織が変化に柔軟に対応し、イノベーションを生み出すための実践的な方法を紹介しています。著者は、アジャイルなマネジメントに情熱を持つ学習者向けに書かれていると述べています。

治したと思っても再び蘇る「ゾンビスクラム」との戦いに辟易していませんか？本書は、あなたのスクラムの「困った」を解決します！ 　スクラムを上手く扱えていますか？世間で言われていような、あるいは想像していたようなメリットを享受することはできていますか？　実際には何ら恩恵をもたらさず、治したと思っても再び蘇る「ゾンビ」のようなスクラムとの戦いに辟易していませんか？ 　本書は、スクラムを上手く扱えていないと感じるすべての人のために書かれた、「上手くいっていない」状態から脱却することを主眼にまとめた実用書です。本の冒頭には「応急処置キット」がついているため、すべてを読んでいる暇はない人でも素早く行動を起こすことができます。応急処置を終えたら、ゾンビスクラムがなぜ起こっているかを根本的なレベルで理解し、改善に取りかかるための実践的なツールを身につけます。ユーモラスかつ非常にビジュアルな内容で、すべてのスクラムマスター、プロダクトオーナー、開発チームのメンバー、アジャイルコーチ、管理職にとって必携の書となるでしょう。 デイヴ・ウェストによる序文 ヘンリ・リプマノヴィッチによる序文 日本語版に寄せて 謝辞 著者紹介 第1章　はじめに 　この本の目的 　この本は必要？ 　この本の構成 　一刻の猶予もない！　さあ行こう！ 第2章　応急処置キット 第1部　（ゾンビ）スクラム 第3章　ゾンビスクラム入門 　スクラムの現状 　ゾンビスクラム 　　症状1：ゾンビスクラムチームはステークホルダーのニーズを知らない 　　症状2：ゾンビスクラムチームは速く出荷しない 　　症状3：ゾンビスクラムチームは（継続的に）改善しない 　　症状4：ゾンビスクラムチームは障害を克服するための自己組織化をしない 　　すべては繋がっている 　　これってカーゴカルトスクラムやダークスクラムの話？ 　ゾンビスクラムに希望はあるか？ 　実験：一緒にチームを診断する 　　手順 　　私たちの発見 　次はどうしたらいいんだ？ 第4章　スクラムの目的 　理解するカギは複雑で適応的な問題 　問題 　複雑、適応的な問題 　複雑性、不確実性、リスク 　経験主義とプロセス制御理論 　経験主義とスクラムフレームワーク 　スクラムフレームワークが可能にすること 　スクラム：常に進化している、経験的に働くための最小限のルール 　ゾンビスクラムと効率主義 　単純な問題についてはどうだろう？ 　次はどうしたらいいんだ？ 第2部　ステークホルダーが求めるものを作る 第5章　症状と原因 　なぜ、わざわざステークホルダーを巻き込む必要があるのか？ 　実際のところ、ステークホルダーは誰？ 　　価値に関する仮説の検証 　なぜ、私たちはステークホルダーを巻き込んでいないのか？ 　　プロダクトの目的をあまり理解していない 　　ステークホルダーが必要とするものを決めてかかっている 　　開発者とステークホルダーとの間に距離をとっている 　　ビジネスとITは別物と考えている 　　プロダクトオーナーが実際にプロダクトのオーナーになることを許されていない 　　価値よりもアウトプットを測る 　　開発者はコードだけ書いていればよい 　　関与しなくてもよいと思っているステークホルダーがいる 　健全なスクラム 　　誰がステークホルダーのことを理解するべきか 　　ステークホルダーをいつ巻き込むか 　次はどうしたらいいんだ？ 第6章　実験 　実験：ステークホルダーを知る 　　ステークホルダートレジャーハントを始める 　　ステークホルダーとの距離を測って透明性を作り出す 　　ステークホルダーの席をスクラムチームの近くに用意する 　　プロダクトの目的に合わせてチームの部屋を飾りつける 　実験：プロダクト開発にステークホルダーを巻き込む 　　“フィードバックパーティー”にステークホルダーを招待する 　　ユーザーサファリに行く 　　ゲリラテスト 　実験：価値あるものに集中し続ける 　　プロダクトバックログの長さを制限する 　　プロダクトバックログをエコサイクルにマップする 　　やるべき作業ではなく、望ましい成果を表現する 　次はどうしたらいいんだ？ 第3部　速く出荷する 第7章　症状と原因 　速く出荷することの恩恵 　　あなたの環境の複雑さ 　　プロダクトの複雑さ 　要するに、速く出荷しないのはゾンビスクラムのサイン 　　なぜ、私たちは十分な速さで出荷しないのか？ 　　速い出荷がリスクを減らすことを理解していない 　　計画駆動型の管理が妨げになっている 　　速く出荷することの競争優位性を理解していない 　　速い出荷の阻害要因を取り除かない 　　スプリントで扱うアイテムが非常に大きい 　健全なスクラム 　　リリースするかしないかを決断する 　　リリースはもはやゼロイチではない 　　スプリント中に出荷する 　　「ビッグバン」リリースはもうしない 　次はどうしたらいいんだ？ 第8章　実験 　透明性と危機感を生み出す実験 　　継続的デリバリーに投資するための説得材料を集める 　　リードタイムとサイクルタイムを測る 　　ステークホルダーの満足度を測る 　もっと頻繁に出荷するための実験 　　インテグレーションとデプロイ自動化への第一歩を踏み出す 　　完成の定義を強化する 　　スプリントごとに出荷する 　　ゴールを達成するためにパワフルクエスチョンを使う 　フローを最適化するための実験 　　スキルマトリックスでクロスファンクショナルを強化する 　　仕掛中の作業を制限する 　　プロダクトバックログアイテムをスライスする 　次はどうしたらいいんだ？ 第4部　継続的に改善する 第9章　症状と原因 　なぜ、わざわざ継続的に改善する必要があるのか？ 　　継続的改善とは何か？ 　　継続的改善かアジャイルトランスフォーメーションか？ 　なぜ、継続的に改善しないのか？ 　　ゾンビスクラムでは、失敗に価値を置かない 　　ゾンビスクラムでは、具体的な改善をしていない 　　ゾンビスクラムでは、失敗するための安全性を作らない 　　ゾンビスクラムでは、成功を祝わない 　　ゾンビスクラムでは、仕事における人間的要素を理解していない 　　ゾンビスクラムでは、仕事のやり方を批評しない 　　ゾンビスクラムでは、仕事と学習は別と考える 　健全なスクラム 　　自己批判的なチーム 　　木を見て、森も見る 　次はどうしたらいいんだ？ 第10章　実験 　深い学習を促すための実験 　　阻害要因ニュースレターを組織内で共有する 　　スプリントレトロスペクティブでパワフルクエスチョンを使う 　　問題点と解決策を一緒に深く掘り下げる 　改善を具体化するための実験 　　15% ソリューションを生み出す 　　何をやめるかに焦点を当てる 　　改善レシピを作成する 　新しい情報を集めるための実験 　　公式・非公式のネットワークを利用して変革を促す 　　ローテクな指標ダッシュボードを作成し成果を追跡する 　学習環境を整える実験 　　成功体験を共有し、それを基に事を進める 　　お祝いケーキを焼く 　次はどうしたらいいんだ？ 第5部　自己組織化する 第11章　症状と原因 　なぜ、わざわざ自己組織化する必要があるのか？ 　　自己組織化とは何か？ 　　シンプルなルールによる自己組織化 　　自己管理による自己組織化 　　自己組織化は複雑な世界におけるサバイバルスキル 　　要するに 　なぜ、私たちは自己組織化しないのか？ 　　ゾンビスクラムでは、自己管理が十分にできていない 　　ゾンビスクラムでは、市販の解決策を使う 　　ゾンビスクラムでは、スクラムマスターがすべての阻害要因を解決していく 　　ゾンビスクラムでは、スクラムマスターはスクラムチームだけに集中する 　　ゾンビスクラムでは、ゴールがないか、押し付けられている 　　ゾンビスクラムでは、作業環境を外部記憶として使わない 　　ゾンビスクラムでは、標準化が妨げになっている 　健全なスクラム：自己組織化とはどのようなものか 　　スクラムチームはプロダクトに対する自律性を持つ 　　管理職がスクラムチームを支援する 　次はどうしたらいいんだ？ 第12章　実験 　自律性を高める実験 　　パーミッショントークンで自律性の低さによるコストを可視化する 　　統合も自律も高める行動を見つけ出す 　　ルールを壊す！ 　自己組織化を促進する実験 　　自己組織化のための最小限のルールを見つける 　　助けてほしい気持ちをはっきりと言葉にする 　　何が起きているか観察する 　自己アラインメントを促す実験 　　パワフルクエスチョンでもっとよいスプリントゴールを作る 　　物理的なスクラムボードを使う 　現場での解決策を見つける 　　阻害要因を話し合うスクラムマスターの集いを開催する 　　オープンスペーステクノロジーで現場での解決策を作る 　次はどうしたらいいんだ？ 第13章　回復への道 　グローバルな活動 　どうにもならない場合は？ 　さらなる参考情報 　さいごに 訳者あとがき 参考文献 索引

デジタル化で人間性が軽視されつつある中、心理的に安全なチームを築くカギとは。『恐れのない組織』のエドモンドソン氏のお墨つき。 心理的安全性がない組織には、未来もない。 職場の恐怖を取り除き、幸福と成果を約束する！ 【序文】 エイミー・C・エドモンドソン （心理的安全性の権威、『恐れのない組織』著者） 【内容紹介】 デジタル時代にチームワークを生み出す最重要な要素は、 「心理的安全性」と「アジャイル」である。 様々な業務がデジタル化・自動化・遠隔化され、 現代の職場から人間性が失われてきた。 そんな中で組織が競争力を保つには、 健全に働けるチームづくりが不可欠だ。 実際のところ、社会のデジタル化を推し進めてきた 巨大IT企業からは、社員＝人がのびのびと働く様子が聞こえてくる。 彼らは一体何が違うのか。それは真似できないのか。 予測不可能なVUCA世界でも有効な考え方がここにある。 コロナパンデミック後の働き方の理想像も追う。 【心理的安全性とデジタル化を共存させるキーワード】 ・信頼、学習、実験 ・リモートとフレックス ・柔軟性と回復力 ・EQ（感情指数） ・印象操作の回避 ・人的負債の削減 【巻末インタビュー】 ジーン・キム （『The DevOps 逆転だ！』著者） 【目次】 エイミー・エドモンドソン教授による序文 第1章　今日の仕事、明日の仕事 第2章　プロセス vs. 人 第3章　チームと好業績の探求 第4章　心理的安全性――高いパフォーマンスのための唯一のスイッチ 第5章　心理的安全性と感情指数を数字に置き換える 第6章　ソフトスキルは難しい（ハード） 第7章　次になにが起こるのか、そしてパンデミック以降の世界での働き方 特別付録　ジーン・キムへのインタビュー エイミー・エドモンドソン教授による序文 第1章　今日の仕事、明日の仕事 ・VUCA、デジタル・ディスラプションとテクノロジーのスピード ・「人的負債」 ・組織 ―― 人、チーム ・明瞭さを手に入れる ・「発言できる」文化 ―― 連携のために真の対話を生み出す ・本当の「ToDo」リストを作る ・人事を再び偉大にする ・許可を与える ・チームに重点を置く ・真にアジャイルになる ―― WoWのためのWoT 第2章　プロセス vs. 人 ・新しい働き方と考え方 ・新しい働き方は新しくない ・アジャイルではないもの ・デザインによる、または「トランスフォーメーション」によるアジャイル ・WoT（考え方）なくしてWoW（働き方）なし ・アジャイルと人 ・なぜアジャイルが難しいのか ・アジャイルのスーパーヒーローたち ・アジャイル、DevOps、WoW、そして「人的負債」の削減 第3章　チームと好業績の探求 ・チームとはなにか？ ・現代のチームと新しい働き方 ・リーダーシップ2.0 ・形成期――チームの立ち上げ、カルチャーキャンバス、契約作成、共同作業 ・混乱期――健全な対立、真の対話と機能不全 ・規範期、成就期、ハイパフォーミング：チーミングおよびリチーミング――チーム構成vs.チームダイナミクス ・プロジェクト・アリストテレス 第4章　心理的安全性――高いパフォーマンスのための唯一のスイッチ ・心理的安全性 ―― 高いパフォーマンスのための唯一のスイッチ ・経営陣における心理的安全性 ・心理的安全性ではないもの ・信頼 ・「柔軟性」と「回復力」 ・意見を言う、すなわち「勇気」と「オープンさ」 ・「学習」―― 学び、実験し、失敗する ・士気と「やる気」 ・印象操作を回避する ・バブルでの対話 ・チームの幸福と人的負債 第5章　心理的安全性と感情指数を数字に置き換える ・人的負債を削減する ・行動的基礎 ・チームへの介入と改善 ――「人間中心の行動」 ・さまざまな業界からの教訓 ・ビジネスではなぜ数字を見る前に人とチームのことを気にかけないのか ・実験しようとする実験 ・大きく勝利するために小さく、しつこく、頻繁に測定する 第6章　ソフトスキルは難しい（ハード） ・ハードスキルと未来 ・職場における感情 ・IQ vs. EQ ・勇気と脆弱さ ・情熱と目的 ・「数字で共感力」は実現できるか？ ・人間らしくある許可 ・「人間中心の行動」 ・チームの枠を超えて 第7章　次になにが起こるのか、そしてパンデミック以降の世界での働き方 ・2020年のパンデミック ・リモートvs.柔軟（どこでvs.どうやって） ・新しい現実を共にデザインする ・突然のリモートへの移行の影響 ・リモートとワークライフバランス ・世界的不況の中でのVUCAなデジタル世界における生産性とパフォーマンス ・パンデミック以降の世界での働き方 ・次に仕事とチームに待ち受けているものは？ 特別付録　ジーン・キムへのインタビュー 用語集

開発者必読のロングセラー『コードコンプリート』の著者マコネルが推奨するアジャイル実践法を公開。 開発者必読のロングセラー『Code Complete（コードコンプリート）』の著者として著名なスティーブ・マコネルの新刊が15年ぶりに登場！　本書は“More Effective Agile: A Roadmap for Software Leaders”（Construx Press、2019年）の日本語版です。企業活動やビジネスが今後ますます「ソフトウェアファースト（ソフトウェア主導）」になっていく中で、リーダーシップを発揮できる人材である「ソフトウェアリーダー」を目指すために、アジャイルから「価値を引き出す」ための実践的なプラクティスを解説します。監訳者にはアジャイル分野で著名であり、『Adaptive Code（旧名『C#実践開発手法』）』で実績のある長沢智治氏を起用しました。 本書に寄せて 謝辞 Part 1　より効果的なアジャイル 第1章　はじめに 1.1 効果的なアジャイルはなぜ重要か 1.2 本書の対象読者 1.3 他のアジャイル本との違い 1.4 本書の構成 1.5 あなたの意見をお聞かせください 第2章　アジャイルの本当の違いは何か 2.1 アジャイルの恩恵の源は何か 2.2 アジャイルの境界 2.3 推奨リーダーシップアクション 2.4 参考文献 第3章　複雑さと不確実さという課題に対処する 3.1 Cynefin 3.2 複雑系のプロジェクトを成功させる：OODA 3.3 基本原則：検査と適応 3.4 推奨リーダーシップアクション 3.5 参考文献 Part 2　より効果的なチーム 第4章　より効果的なアジャイルの始まり：スクラム 4.1 基本原則：スクラムから始める 4.2 スクラムとは何か 4.3 スクラムの基本 4.4 スクラムロール 4.5 スクラムの一般的な失敗モード 4.6 スクラムの失敗モードの共通点 4.7 スクラムの成功要因 4.8 成功するスプリント 4.9 一般的なスプリントの時間配分 4.10 スクラムへの移行の問題 4.11 スクラムのスコアカード 4.12 スクラムでの検査と適応：デイリースクラム 4.13 その他の検討課題 4.14 推奨リーダーシップアクション 4.15 参考文献 第5章　より効果的なアジャイル：チーム構造 5.1 基本原則：機能横断的チームの結成 5.2 テスト技術者の組織化 5.3 基本原則：テスト技術者を開発チームに統合する 5.4 プロダクションサポートの組織化 5.5 ブラックボックスとしてのアジャイルチーム 5.6 組織はアジャイルのチームづくりに前向きか 5.7 その他の検討課題 5.8 推奨リーダーシップアクション 5.9 参考文献 第6章　より効果的なアジャイル：チーム文化 6.1 基本原則：自律、熟達、目的によるチームの動機付け 6.2 基本原則：成長マインドセットを培う 6.3 基本原則：ビジネスフォーカスを培う 6.4 その他の検討課題 6.5 推奨リーダーシップアクション 6.6 参考文献 第7章　より効果的なアジャイル：分散チーム 7.1 基本原則：よりタイトなフィードバックループ 7.2 分散アジャイルチームの成功を目指して 7.3 基本原則：人ではなく仕組みを修正する 7.4 その他の検討課題 7.5 推奨リーダーシップアクション 7.6 参考文献 第8章　より効果的なアジャイル：個人および対話 8.1 個人重視のポテンシャル 8.2 基本原則：個人のキャパシティを向上させることでチームのキャパシティを向上させる 8.3 より効果的な対話（チーム） 8.4 推奨リーダーシップアクション 8.5 参考文献 Part 3　より効果的な作業 第9章　より効果的なアジャイル：プロジェクト 9.1 基本原則：プロジェクトを小さく保つ 9.2 基本原則：スプリントを短く保つ 9.3 ベロシティベースのプランニング 9.4 基本原則：バーティカルスライスでのデリバリー 9.5 基本原則：技術的負債を管理する 9.6 バーンアウトを回避する作業構造 9.7 その他の検討課題 9.8 推奨リーダーシップアクション 9.9 参考文献 第10章　より効果的なアジャイル：大規模なプロジェクト 10.1 大規模なプロジェクトにおけるアジャイルの本当の違いとは 10.2 大規模なプロジェクトにおけるアジャイルの重点 10.3 ブルックスの法則 10.4 コンウェイの法則 10.5 基本原則：アーキテクチャを通じて大規模なアジャイルプロジェクトをサポートする 10.6 大規模なプロジェクトではコラボレーションの種類が変化する 10.7 大規模なプロジェクトでの協調性の課題 10.8 大規模なアジャイルプロジェクトのスコアカード 10.9 スクラムから始める 10.10 その他の検討課題 10.11 推奨リーダーシップアクション 10.12 参考文献 第11章　より効果的なアジャイル：品質 11.1 基本原則：欠陥検出のギャップを最小化する 11.2 基本原則：完成の定義を作成し、使用する 11.3 基本原則：リリース可能な品質水準を維持する 11.4 手戻りを減らす 11.5 その他の検討課題 11.6 推奨リーダーシップアクション 11.7 参考文献 第12章　より効果的なアジャイル：テスト 12.1 基本原則：開発チームが作成した自動テストを使用する 12.2 効果的なアジャイルテストに対するその他の秘訣 12.3 その他の検討課題 12.4 推奨リーダーシップアクション 12.5 参考文献 第13章　より効果的なアジャイル：要求の作成 13.1 アジャイル要求のライフサイクル 13.2 アジャイル要求では何が異なるのか 13.3 Cynefinと要求作業 13.4 アジャイル要求：ストーリー 13.5 アジャイル要求のコンテナ：プロダクトバックログ 13.6 プロダクトバックログに要求を追加する方法 13.7 基本原則：プロダクトバックログのリファインメント 13.8 基本原則：準備完了の定義を作成し、使用する 13.9 その他の検討課題 13.10 推奨リーダーシップアクション 13.11 参考文献 第14章　より効果的なアジャイル：要求の優先順位付け 14.1 プロダクトオーナー 14.2 Tシャツのサイズ分け 14.3 ストーリーマッピング 14.4 その他の検討課題 14.5 推奨リーダーシップアクション 14.6 参考文献 第15章　より効果的なアジャイル：デリバリー 15.1 基本原則：繰り返し行う作業を自動化する 15.2 継続的インテグレーションと継続的デリバリーを支援するプラクティス 15.3 継続的インテグレーションと継続的デリバリーの利点 15.4 その他の検討課題 15.5 推奨リーダーシップアクション 15.6 参考文献 Part 4　より効果的な組織 第16章　より効果的なアジャイル：リーダーシップ 16.1 基本原則：細部ではなく成果を管理する 16.2 基本原則：「司令官の意図」を使って目的を明確に表現する 16.3 基本原則：活動ではなくスループットに焦点を合わせる 16.4 基本原則：鍵となるアジャイルな振る舞いをモデル化する 16.5 推奨リーダーシップアクション 16.6 参考文献 第17章　より効果的なアジャイル：組織文化 17.1 基本原則：間違いを許す 17.2 心理的安全性 17.3 基本原則：チームキャパシティの計測に基づいたプランニング 17.4 プラクティスコミュニティを確立する 17.5 より効果的なアジャイルを支援する上での組織の役割 17.6 推奨リーダーシップアクション 17.7 参考文献 第18章　より効果的なアジャイル：計測 18.1 作業の量を計測する 18.2 作業の品質を計測する 18.3 計測全般に関する検討課題 18.4 その他の検討課題 18.5 推奨リーダーシップアクション 18.6 参考文献 第19章　より効果的なアジャイル：プロセス改善 19.1 スクラム：プロセス改善のベースライン 19.2 生産性を向上させる 19.3 原理原則に従って仕掛かり作業をマッピングし、監視する 19.4 アジャイルのレトロスペクティブ 19.5 計測ごっこに注意 19.6 検査と適応 19.7 その他の検討課題 19.8 推奨リーダーシップアクション 19.9 参考文献 第20章　より効果的なアジャイル：予測可能性 20.1 リリースサイクルの違いによる予測可能性 20.2 予測可能性の種類 20.3 コストとスケジュールの厳密な予測可能性 20.4 フィーチャーセットの厳密な予測可能性 20.5 予測可能性に対するより大まかなアプローチ 20.6 予測可能性と柔軟性 20.7 その他の検討課題 20.8 推奨リーダーシップアクション 20.9 参考文献 第21章　より効果的なアジャイル：規制産業 21.1 アジャイルは規制産業での作業をどのように支援するか 21.2 スクラムは規制産業での作業をどのように支援するか 21.3 規制環境のアジャイルの境界 21.4 その他の検討課題 21.5 推奨リーダーシップアクション 21.6 参考文献 第22章　より効果的なアジャイル：ポートフォリオマネジメント 22.1 WSJF 22.2 その他の検討課題 22.3 推奨リーダーシップアクション 22.4 参考文献 第23章　より効果的なアジャイル：導入 23.1 変革の大まかなアプローチ 23.2 ドミノ変革モデル 23.3 組織全体に改革を行き渡らせる 23.4 続：上空40,000フィートから見たロールアウト 23.5 検査と適応 23.6 推奨リーダーシップアクション 23.7 参考文献 Part 5　おわりに 細工は流々、仕上げを御覧じろ 28の基本原則のまとめ 監訳者あとがき 参考文献

この書籍は、歴史における重要な対立を通じて、現代の仕事や人生に役立つ教養を提供する内容です。古代から現代までの53の主要な争いを扱い、ペルシア戦争やアヘン戦争、資本主義と社会主義の対立などが取り上げられています。

企業の経営層に向けてソフトウェア開発手法の「アジャイル」とその手法の一つである「スクラム」を体系的に解説。スクラムはソフトウェア開発のみならず、組織や企業活動、企業経営全体にまで適用できることを提示する。さらに、この手法を取り入れ、ビジネスと一体になってソフトウェアを開発する組織や、その組織に息を吹き込む、新しいタイプのリーダーシップ像についても考える。日本におけるアジャイル開発の第一人者と世界的な経営学者・スクラム産みの親による提言。業界をリードするリクルート・富士通・楽天の最新開発事例を収録。 第1部 アジャイル開発とは何か、スクラムとは何か(アジャイル開発とは何か? なぜ、アジャイル開発なのか スクラムとは何か? アジャイル開発の活動(プラクティス)) 第2部 アジャイル開発とスクラムを実践する(スピード時代に独自のアジャイル手法ワンチームマインドで挑むリクルート 小さく始めて浸透させる-楽天のアジャイルによる組織改革 「IT新市場」におけるアジャイル開発に取り組む富士通の挑戦) 第3部 アジャイル開発とスクラムを考える(竹内・野中のスクラム論文再考 スクラムと知識創造 スクラムと実践知リーダー)

本書では、プロジェクトマネジメントにおける問題の根源は「不確実性」にあると指摘されています。プロジェクトは常に新しい挑戦であり、成功するための固定された進め方は存在しません。そのため、各プロジェクトに応じた「固有のプロセス」を設計する必要があります。この考え方を「プロセスデザインアプローチ」と呼び、著者が具体的な方法を解説しています。内容は、プロジェクトの本質、不確実性の管理、プロジェクトの全体像、計画や進捗管理の方法、振り返りの重要性など、幅広いテーマを扱っています。著者は、実行品質を高めるためのコンサルタントであり、実践的なアプローチを提供しています。

本書は、リスク管理の重要性を説く内容で、リスクのないプロジェクトには価値がないと主張しています。目次はリスク管理の必要性や方法、数量化の手法、リスク管理の検証に分かれており、著者はプロジェクト管理に関する豊富な経験を持つトム・デマルコとティモシー・リスターです。彼らは、リスク管理を通じてプロジェクトの成功を目指すことを提案しています。

アジャイル開発における各プロセスを可視化し、問題点の抽出と解決方法を定量化する手法 開発に関わる全工程の詳細を定量化し より強く、より高パフォーマンスなチームへ 【本書の内容】 本書は Christopher W.H.Davis, "Agile Metrics in Action", Manning Publications 2015 の邦訳版です。 アジャイル開発は、その特性である「反復」によって、経験に基づく継続的な改善に最適な開発手法です。 この手法に、追跡システム、テストおよびビルドツール、ソース管理、継続的統合、およびプロジェクト ライフサイクルといったさまざまなコンセプトとツールを援用することで、製品やプロセス、 さらにはチームそのもののパフォーマンス改善できる豊富なデータを入手できます。 本書は、そういった実際に生成されるデータを計測し、結果を的確に分析し、効果的な対処法を指南してくれます。 パフォーマンスや進捗度合いなどを定量化することで、経験値による知見だけではなく、 より合意しやすいチームへと組織や方法論を改善してくれることでしょう。 【読者が得られること】 ・プロセスやタスクを定量化できるようになる ・定量化したデータから現状を正確に把握できるようになる ・コミュニケーション、生産性、透明性、士気を向上させる ・客観的にパフォーマンスを測定する 【著者について】 Christopher W. H. Davis（クリストファー・M・H・デイビス） ソフトウェアエンジニア。20年以上にわたり、旅行、金融、ヘルスケア、通信、製造業などの分野で開発チームのリーダーを務め、 世界中のさまざまな環境で多様なチームを率いてきました。 熱心なランナーでもあるクリスは、妻と2人の子供とともに、オレゴン州ポートランドの美しく雄大な太平洋岸北西部を満喫しています。 目次 第1部　アジャイルチームを測定する 　　第1章　アジャイルパフォーマンスを測定する 　　第2章　生きたプロジェクトを観察する 第2部　チームのデータの収集と分析 　　第3章　プロジェクト管理システムからのデータと傾向 　　第4章　ソースコード管理 　　第5章　継続的インテグレーションおよびデプロイからのデータと傾向 　　第6章　本番環境から届くデータ 第3部　メトリクスをチーム・プロセス・ソフトウェアに適用する 　　第7章　収集したデータの扱い：データの集約 　　第8章　ソフトウェア品質を測定する 　　第9章　メトリクスの公開 　　第10章　アジャイルの原則に照らし合わせてチームを測定する

10年以上のロングセラーとなっているシステム設計レビューの解説書、待望の増補三訂版。AIシステム、アジャイル開発に対応 10年以上のロングセラーとなっているシステム設計レビューの解説書、待望の増補三訂版。AIシステム、アジャイル開発に対応 　失敗レビューを防ぐワザ、この1冊ですべて学べます！　「要件定義書や設計書などのドキュメントレビューに時間をかけているのに、重大な問題を見逃してしまう」「どうでもいい問題の指摘ばかり」「なかなか問題を出し切れず、夜遅くまで会議が続く」「人格を攻撃するレビューアーが出てくる」――。　検出した問題を指摘し、よりよいシステムを作り上げるためのレビュー会議が、どうも適切に運営できない。そんな経験はありませんか。原因は、間違ったレビューのやり方にあります。ITエンジニア出身で、現在は研究者として企業とレビューの共同研究に長年取り組む著者が、失敗レビューを防ぐワザの数々を紹介します。　例えば、重大な見逃しを防ぐ「問題種別の設定」、1時間で問題を出し切る「ゴール確認」、的確な意見を引き出す「指針となるシナリオ」、意識合わせを促す「ウオークスルー」といったワザを詳しく解説しています。これらのワザを取り入れることで、適切な時間で重大な問題を漏らさず見つけ出すレビュー会議に変わるはずです。　本書は10年以上のロングセラーとなっている設計レビューの手順書の第3版です。第3版では、システム開発の現場で近年重要性が増している「人工知能（AI）システム」や「アジャイル開発」におけるレビューの手順などを新たに盛り込みました。 第1章 レビューの間違い 1-1 レビューの目的の間違い 1-2 問題検出の間違い 1-3 問題指摘の間違い（方法編） 1-4 問題指摘の間違い（マインド編） 第2章 準備と問題検出 2-1 レビューの準備（リーダー、作成者） 2-2 レビューの準備（レビューアー） 2-3 問題検出の手順 第3章 レビュー会議の進め方 3-1 問題指摘の手順（前半） 3-2 問題指摘の手順（後半） 3-3 問題の修正・フォロー 3-4 レビュー技法 第4章 さらなる効果向上 4-1 レビューの改善・効率化 4-2 問題種別の設定対象を広げる 4-3 保守開発、クラウド開発への応用 4-4 AIシステムへの応用 4-5 アジャイル開発への応用 付録 レビュー観点絞り込みの効果 参考文献 索引

この書籍は、ソフトウェア開発の原則、デザインパターン、プラクティスを統合した内容で、プログラマ向けの実用的なガイドです。アジャイル開発や設計、具体的なケーススタディを通じて、効果的な開発手法を提供しています。著者は、経験豊富なソフトウェア専門家たちで構成されており、各分野での豊富な知識と実績を持っています。

この書籍は、アジャイルソフトウェア開発の核心となるプラクティスを包括的にまとめたもので、特定の方法論に偏らず、様々な方法論に共通する実践を結びつけて全体像を示しています。目次には、アジャイルの基本からフィードバック、コーディング、デバッグ、コラボレーションに至るまでの章が含まれています。著者は、アジャイル開発の専門家や経験豊富なプログラマたちで構成されています。

システム開発の上流工程の1つである、システム設計にスポットを当てた入門書です。システム設計を大きくアプリケーション設計とインフラ設計の2つに分類し、各分類における設計内容を軸に、実践のポイントや注意点などを紹介しました。関係者間で共通の認識を持って開発を進め、システムの品質を高められるようになるはずです。また、設計書の活用方法についても解説されているので、メンテナンスも効率的にできるようになるでしょう。 CHAPTER1 「システム設計」の位置付け Section 01 本書の前提とシステム「開発」の全体像 Section 02 「要件定義」とは Section 03 「設計」とは Section 04 「開発テスト」とは Section 05 「リリース」とは Section 06 「保守・運用」とは COLUMN どの工程にどれくらいリソース（工数）が必要なの？ CHAPTER2 「システム設計」とは Section 07 本書における「システム設計」の整理方法 Section 08 設計書を作成する理由 Section 09 設計書の種類 Section 10 「全体設計」の概要 Section 11 「入出力設計」の概要 Section 12 「データベース設計」の概要 Section 13 「ロジック設計」の概要 Section 14 「ネットワーク設計」の概要 Section 15 「サーバ設計」の概要 COLUMN システム設計は広く、深い CHAPTER3 「システム設計」 に影響する考え Section 16 ソフトウェア設計モデル Section 17 フレームワーク Section 18 社外要因・社内要因 Section 19 オンプレミスとクラウド Section 20 仮想化技術 Section 21 ミドルウェア COLUMN ソフトウェアを作るのは勉強も必要だが、本来は楽しいもの CHAPTER4 全体設計 Section 22 全体設計の流れとポイント Section 23 システムアーキテクチャ設計 Section 24 信頼性・安全性設計（全体編） Section 25 環境設計（全体編） Section 26 性能設計（全体編） Section 27 セキュリティ設計（全体編） Section 28 運用方式設計（全体編） Section 29 外部接続方式設計（全体編） Section 30 標準化設計 Section 31 テスト方式設計（全体編） Section 32 移行方式設計（全体編） COLUMN こんなにも全体設計が必要なの？ CHAPTER5 入出力設計 Section 33 設計書一覧 Section 34 画面系：画面一覧 Section 35 画面系：画面遷移図 Section 36 画面系：画面共通設計 Section 37 画面系：画面レイアウト Section 38 画面系：画面入力設計 Section 39 帳票系：帳票レイアウト Section 40 IF系：外部接続先一覧 Section 41 IF系：外部接続方式設計 Section 42 IF系：IFレイアウト Section 43 その他：送信メール設計 COLUMN 入出力設計は、システム知見に加えてコミュニケーション力が必要 CHAPTER6 データベース設計 Section 44 設計書一覧 Section 45 ボリューム一覧 Section 46 RDB：データベース設定 Section 47 RDB：ER図 Section 48 RDB：テーブルレイアウト Section 49 ファイル：ファイル設計 COLUMN データベース設計といえば、まずはRDBです CHAPTER7 ロジック設計 Section 50 設計書一覧 Section 51 ユースケース図 Section 52 アクティビティ図 Section 53 クラス図 Section 54 シーケンス図 Section 55 処理フロー図（フローチャート） Section 56 状態遷移設計 Section 57 バッチ全体設計 Section 58 処理設計（プログラム仕様書） COLUMN システム構築には「システムならではの考え方」や「業界特有の知識」が必要 CHAPTER8 ネットワーク設計 Section 59 設計書一覧 Section 60 ネットワーク全体構成図（物理構成） Section 61 ネットワーク全体構成図（論理構成） Section 62 ネットワーク提供サービス一覧 Section 63 通信要件一覧 Section 64 IPアドレス設計 Section 65 ネットワークサービス設計 Section 66 FW（ファイアーウォール）ルール設定方針書 Section 67 流量制御設計 COLUMN ネットワークの基礎はOSI参照モデルを知るのが早い CHAPTER9 サーバ設計 Section 68 設計書一覧 Section 69 サーバ仕様設計 Section 70 仮想化設計 Section 71 サーバプロダクト構成書 Section 72 サーバ稼働サービス一覧 Section 73 サーバ設定仕様書 Section 74 サーバ構築手順書（クラウド編） Section 75 サーバ運用設計 Section 76 障害対応手順書 COLUMN サーバ設計ができれば、たいていはなんとかなる CHAPTER10 設計書の活用 Section 77 設計書は開発のためだけではない Section 78 設計書は継続したメンテナンスが重要 Section 79 設計書は影響調査に使用する Section 80 設計書はシステムの品質を高めるために使用する Section 81 設計書は教育に使用する Section 82 設計書は移行の元ネタに使用する COLUMN 設計書は不要、という暴論

* Teaches how to write good tests * Uses state-of-the-art open source software * Offers real-world insights from an expert author Code is written by humans who make mistakes UPSILONV hence bugs and the need for testing. Savvy Java developers know that not all testing is created equal. In addition to traditional functional testing, many shops are adopting developer testing techniques such as unit testing. Specific, automated tests are created to verify the accuracy and function of code while or even before itUPSILON s written UPSILONV to catch bugs early. Unit Testing in Java teaches how to write good tests that are concise and to the point, useful, and maintainable. This book focuses on tools and practices specific to Java. It introduces emerging techniques like specification by example and behavior-driven development, and shows how to add robust practices into developers toolkits.

本書は、DX時代におけるアジャイル開発の重要性と実践方法を解説しています。著者陣はソフトウェア開発の専門家で、具体的な手法や改善策を図解を用いて丁寧に紹介。アジャイル開発を実践したいエンジニアや経営者、企画担当者に向けて、実践的なノウハウを提供しています。目次にはアジャイル開発の基礎から、実践的なカイゼン手法まで幅広い内容が含まれています。

著者がエンジニアリングにおける課題解決のための思考整理法やメンタリング手法を解説する本です。コミュニケーションの不確実性、技術的負債、経営陣とエンジニア間の認識のずれを解消する方法について詳しく述べています。若手を育成し、成長する組織を設計・運営するための実践的なアプローチが紹介されています。著者は技術と経営の接続に関する豊富な経験を持つCTOです。

本書は、情報システムの設計手順を体系化し、ユーザーと開発チームをつなぐ方法を明示します。各工程の目的や作業内容を示しながら、データ、業務プロセス、画面UIの設計を「概要定義から詳細定義へ」「論理設計から物理設計へ」と進める手順を説明します。特定の開発手法に依存せず、実装技術や環境変化に左右されない原理原則を実践に即して解説しています。著者はシステム設計や業務改革に携わる専門家です。

本書は、現場のストーリーを通じて仮説検証やアジャイルなプロダクトづくりを学ぶ内容です。プロダクト開発における課題や理想とのギャップを解消する方法を探求します。目次は、既存プロダクトの再探索と新たな価値の探索に分かれ、仮説検証の重要性やプロトタイプ作成の意義が強調されています。著者は、アジャイル開発の実践に豊富な経験を持つ市谷聡啓氏です。

この書籍は、システム保守における複雑なコードの分析手法や対処方法を解説しています。具体的には、コードの理解、テスト、リファクタリング、機能追加のためのテクニックを紹介。内容は、ソフトウェアの変更メカニズムや、変更作業における課題、依存関係の排除手法に分かれています。著者は、テスト駆動開発やオブジェクト指向設計に関する専門家たちです。

この教科書は、論理トレーニングを通じてシステム理論の基礎を学び、情報システムの開発に応用することを目的としています。情報システムをソフトウェア工学ではなくシステム理論の観点から扱い、2007年に発行された『形式手法モデル理論アプローチー情報システム開発の基礎』の改訂版です。内容は論理、集合、オートマトン、関係データベースに関する章で構成されています。著者は各大学の教授陣です。

この本は、世界最高峰の経営コンサルティング会社で教えられている問題解決の考え方を、中高生向けに身近なストーリーとイラストを交えて解説しています。問題を小さく分けて考えることで解決策が見えてくることを学び、自ら考え行動する力を育む内容です。目次では、問題解決能力の習得、原因の見極め、目標設定と達成方法についての章が設けられています。著者は、経済を専攻した後にマッキンゼーでの経験を持つ渡辺健介氏です。

この本は、問題発見に焦点を当てた内容で、特に自動車用トンネルのヘッドライトの点灯に関する具体例を通じて、問題を解くよりも発見することの重要性を強調しています。著者は、実生活において問題を見つけることがいかに難しく、面白いかを述べ、特に若者にこの知識を身につけてほしいと願っています。目次では、問題の本質やその解決方法についての章が展開されており、読者に新たな視点を提供します。

『ソフトウェアエンジニアリング・スタンダード 第9版』は、1982年に初版が発行されて以来、45万部以上のベストセラーとなった書籍の最新邦訳です。ソフトウェアエンジニアや学生に向けて、ソフトウェアエンジニアリングの最良の手法を解説しています。内容は、ソフトウェアプロセス、モデリング、品質とセキュリティ、プロジェクトマネジメント、先端的な話題に分かれています。著者はRoger S. PressmanとBruce R. Maximで、それぞれがソフトウェアエンジニアリングの分野で豊富な経験を持つ専門家です。

この書籍は、日本人がロジカルな表現を苦手とする理由を探り、効果的なライティング技術を身につけるための方法を提供しています。序章では誤解を解き、各章で読み手の関心を引くためのOPQ分析、メッセージの整理、ロジックの展開、文書の構成を解説。終章では日常のメールを通じてこれらの技術を実践する方法を提案しています。著者の山崎康司は経営コンサルタントで、ビジネス思考やライティングに関する教育を行っています。

本書は、高橋寿一氏による「開発者テスト」の実践ガイドで、ウォーターフォールやアジャイル開発における上流品質の向上を目指します。開発者が行うべきテスト手法（単体テスト、リファクタリング、テストの自動化など）を実例を交えて解説し、アジャイル開発に特化した内容も強化されています。著者の豊富な経験を基に、現場で必要な手法と学術的な根拠を提供する一冊です。

本書は、プロジェクトマネジメント（PM）の重要性を解説し、目標設定、計画、実行・修正の3つの視点から具体的な知識とツールを豊富な図を用いてわかりやすく紹介しています。企業や組織が求めるPMスキルを習得するための内容で、ISO21500に準拠しています。著者は、プロジェクトソリューションズの代表であり、大学でPMの講師も務めています。

本書は、体系的かつシンプルなロジカル・コミュニケーション技術を習得することを目的としています。著者たちは、訓練を通じて誰でもこの技術を身につけられると確信しています。内容は、伝えることの重要性や論理的思考の整理、構成技術に関する具体的な方法を提供しています。著者は共にマッキンゼーでの経験を持ち、コミュニケーション戦略やトレーニングに従事しています。

この書籍は、システムテストの自動化を技術と組織の両面から実践的に解説しており、Seleniumなどのツールを用いた事例も紹介しています。内容は、テスト自動化の技法、保守性の高いテストの構築、メトリクス、ツール選択など多岐にわたります。また、著者はソフトウェアテスティングの分野で豊富な経験を持つ専門家です。

「Lean UX」は、リーン思考を取り入れたユーザー体験設計プロセスで、短期間で最適なデザインを導き出す手法です。本書では、プロトタイプによる仮説検証やMVP構築、ユーザーフィードバックの効率的な取得方法を解説します。改訂版では「Lean UXキャンバス」を紹介し、チーム内のギャップを埋める方法を説明しています。著者たちは、プロダクト開発におけるコラボレーションや実践の重要性についても触れています。

バーバラ・ミントが著した本は、コミュニケーション力を向上させるための文章の書き方を紹介しています。内容は、書く技術、考える技術、問題解決の技術、表現の技術の4部構成で、特にピラミッド構造を活用した文書作成法に焦点を当てています。また、構造がない状況での問題解決や重要ポイントのまとめも含まれています。

先を制してライバル企業に勝つためのポイントとは?決算を早期化して利益を稼ぎだすには?業務改革で会社をよみがえらせるには?最高のシステムをつくるための「亀のコウラ」とは?ベンチャーから中堅企業まで50社以上、業務設計・改善から会計監査さらにIPO支援まで20年近いコンサルティング実績を誇る「公認会計士兼システムコンサルタント」という異色の著者だからこそ書ける成功のノウハウが満載! 第1章 「稼げるシステム」と「稼げないシステム」の分かれ道はどこにあるのか? 第2章 先を制してライバル企業に勝つ"経営の視点" 第3章 決算を早期化して利益を稼ぎ出す"会計の視点" 第4章 業務改革で会社をよみがえらせる"業務の視点" 第5章 正しい知識で最高のシステムをつくる"システムの視点" 第6章 プロジェクトを成功に導き、会社を飛躍させよう

プロダクトマネジメントの考え方と行動について解説！プロダクトマネジメントは理論的には人々に愛されるプロダクトを作ることであり、ビジネスゴールとユーザニーズを計測することとされていますが、実際は、問題に直面しているプロダクトを改良するための粘り強い取り組みであり、ビジネスの「ゴール」が何かを明らかにするために執拗に働きかけることです。プロダクトマネジメントにおけるあいまいさや矛盾、不本意な妥協を紹介し、プロダクトマネージャーに必要な考え方と日々の行動、過ごし方を解説します。

この書籍は、リーダーシップは特定の人に与えられるものではなく、日々の小さな行動を通じて信頼し合うチームを作れることを説いています。著者はNetscape、Apple、Slackでの経験を基に、リーダーに必要な振る舞いを30のエッセイで紹介し、具体的なマネジメントのテーマ（傾聴、信頼関係の構築、仕事の任せ方など）について解説しています。著者はシリコンバレーのエンジニアリングリーダーで、現在Appleに勤務しています。

本書は、IT業界での技術系マネージャーを目指すエンジニアに向けて、マネジメントに必要なスキルやキャリアパスを解説しています。著者のカミール・フルニエは、テックリードからCTOに至る自身の経験を基に、メンタリング、プロジェクト管理、チーム管理、経営幹部の役割など、各ステージで求められる役割や考え方を具体的に紹介します。技術力の維持やチームの立て直しなど、管理職に伴うさまざまな課題への対処法も提案されており、マネジメントキャリアを志すエンジニアにとって必携の一冊です。

本書は、DevOpsの文化的側面に焦点を当て、組織内での変革を促進する方法を解説しています。DevOpsは単なる技術的な手法ではなく、異なる部門をつなぐ組織文化の構築が重要です。具体的には、チーム間の親和性を高め、異なるゴールを調整する方法や、コラボレーション、アフィニティ、ツール、スケーリングの「4つの柱」を通じて、持続可能な組織を作るためのノウハウが紹介されています。ソフトウェア開発や運用に関わるすべての人にとって必携の一冊です。

経営学のレリバンスを問いつつ，組織行動論の主立った理論・尺度を紹介する好評上級テキスト。3つの新章を増補し，さらに充実。 経営学のレリバンスを問いつつ，組織行動論の主立った理論・測定尺度を紹介する好評上級テキスト。リサーチ・プラクティス・ギャップを学説史的に掘り下げた第２章，実証主義とは何かを概説した第６章，実践家との共同研究の成功要因を探る第15章を増補。 第１部　組織行動論の立ち位置 第１章　組織行動研究の俯瞰⑴：現状把握のための横断的レビュー／第２章　組織行動研究の俯瞰⑵：学説史的レビュー／第３章　「知っている」ということについて／第４章　概念と理論／第５章　組織行動の測定／第６章　実証主義とは何か 　第２部　組織行動論は何をどう測るか 第７章　リーダーシップ／第８章　組織の中の公正／第９章　欲求とモティベーション／第10章　人的資本，社会関係資本，心理的資本／第11章　組織と個人の心理的契約／第12章　組織コミットメント，ジョブ・エンベデッドネス／第13章　組織行動の成果 　第３部　組織行動論の充実のために 第14章　２つの知のサイクルが共振する共同研究／第15章　共同研究が成功する条件／第16章　共同研究の鍵を握る共同イベント／第17章　組織行動研究のレリバンスを求めて

この文章は、組織行動学に関する書籍の目次と著者情報を紹介しています。目次は、組織行動学の基本、個人の行動、集団の行動、組織のシステムに関する4つの部に分かれており、それぞれのテーマを扱っています。著者はスティーブン・P・ロビンスと高木晴夫であり、ロビンスは組織行動学のベストセラー教科書作者で、国内外の大学で広く使用されています。高木は慶應義塾大学の教授で、経営学の専門家です。

本書は、Spotifyでのアジャイルコーチやエンジニアの経験を持つ著者が、ユニコーン企業のソフトウェア開発と働き方を解説しています。成功するテック企業は、スタートアップの手法をエンタープライズレベルに拡張し、ミッションを通じてチームに目的を持たせ、権限を与えて信頼関係を築きます。複数のチームが連携し、高品質なプロダクトを迅速にリリースする方法や、デリバリープロセスの改善についての事例が紹介されており、エンジニアやマネージャーにとって必携の一冊です。

本書は、全社員が仕事に喜びを感じる環境を作るための経営手法を紹介しています。著者リチャード・シェリダン氏が率いるメンロー・イノベーションズ社の成功事例をもとに、官僚主義や長時間労働などの問題を解決する方法を提案。階層のない組織やペア作業、オープンなコミュニケーションなどを通じて、社員に安心感と成長の機会を提供し、持続可能な成果を生むことを目指しています。経営者にとって必携の一冊です。

本書は、2018年に発行された機械学習に関する書籍の全面改訂版で、不確実性の高い機械学習プロジェクトを「仕事で使う」という視点から整理しています。新たに「ML Ops」や「機械学習モデルの検証」などの章が追加され、読者が直面する問題解決に役立つ内容となっています。著者は機械学習分野の専門家で、実践的な知識を提供しています。