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

新しいプログラムを作ることは新しいコンピュータの使い方を発見すること。たかが技術と侮るなかれ。プログラムのかき方を学ぶと…

Peter Seibel interviews 15 of the most interesting computer programmers alive today in Coders at Work, offering a companion volume to Apress's highly acclaimed best-seller Founders at Work by Jessica Livingston. As the words "at work" suggest, Peter Seibel focuses on how his interviewees tackle the day-to-day work of programming, while revealing much more, like how they became great programmers, how they recognize programming talent in others, and what kinds of problems they find most interesting. Hundreds of people have suggested names of programmers to interview on the Coders at Work web site: www.codersatwork.com. The complete list was 284 names. Having digested everyone's feedback, we selected 15 folks who've been kind enough to agree to be interviewed: * Frances Allen: Pioneer in optimizing compilers, first woman to win the Turing Award (2006) and first female IBM fellow * Joe Armstrong: Inventor of Erlang * Joshua Bloch: Author of the Java collections framework, now at Google * Bernie Cosell: One of the main software guys behind the original ARPANET IMPs and a master debugger * Douglas Crockford: JSON founder, JavaScript architect at Yahoo! * L. Peter Deutsch: Author of Ghostscript, implementer of Smalltalk-80 at Xerox PARC and Lisp 1.5 on PDP-1 * Brendan Eich: Inventor of JavaScript, CTO of the Mozilla Corporation * Brad Fitzpatrick: Writer of LiveJournal, OpenID, memcached, and Perlbal * Dan Ingalls: Smalltalk implementor and designer * Simon Peyton Jones: Coinventor of Haskell and lead designer of Glasgow Haskell Compiler * Donald Knuth: Author of The Art of Computer Programming and creator of TeX * Peter Norvig: Director of Research at Google and author of the standard text on AI * Guy Steele: Coinventor of Scheme and part of the Common Lisp Gang of Five, currently working on Fortress * Ken Thompson: Inventor of UNIX * Jamie Zawinski: Author of XEmacs and early Netscape/Mozilla hacker What you'll learnHow the best programmers in the world do their jobs! Who this book is for Programmers interested in the point of view of leaders in the field. Programmers looking for approaches that work for some of these outstanding programmers. Table of Contents * Jamie Zawinski * Brad Fitzpatrick * Douglas Crockford * Brendan Eich * Joshua Bloch * Joe Armstrong * Simon Peyton Jones * Peter Norvig * Guy Steele * Dan Ingalls * L Peter Deutsch * Ken Thompson * Fran Allen * Bernie Cosell * Donald Knuth

エンタープライズにアジャイル開発を導入しようとしているすべての人に。 企業にアジャイル開発を導入するときに、何が障壁となり、何が課題となり、どのように取り組んでいけばその中で成功がつかめるのか？ アジャイル開発を成功させるためのチーム作り、プロジェクトの進め方、プランニングからリリースまでの流れ、開発時に必要な技術、評価と改善まで、徹底的に解説。 エンタープライズでのアジャイル開発の実現に向けて様々な経験をし、度重なる試行をしてきた執筆陣が、その実践の中で得た知見とノウハウをこの一冊に凝縮しました。 前半は「導入編」として、「チームを作る」「開発の準備」「開発」「評価と改善」など、それぞれの場面でのアジャイルの理想と現実、そしてどうしたら上手くいくか、を説明しています。これらを参考に、是非、読者自身の組織やチームに適用してみてください。 後半は「実践編」として、「要件管理」「アジャイルで求められる開発技術」「品質管理」「構成管理」「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　最後に

お金の力を正しく知って、思い通りの人生を手に入れよう。変化の時代のサバイバルツールとして世界中で読まれるベスト＆ロングセラー オリエンタルラジオ 中田敦彦さん「YouTube大学」で紹介、大絶賛！ □最初に読むべき「お金」の基本図書 毎年多くの「お金」に関する本が出版され,書店に並び、そして消えていきます。 そんな状況の中で、「金持ち父さんシリーズ」は刊行から20年経った今でも変わらず多くの支持を得ています。 その第1作目である『金持ち父さん 貧乏父さん』は、時代が変わっても古びない原理原則を示す「お金」の基本図書。 「目からウロコの連続でした! 」という声が絶えず寄せられ、これまで数多の人々の「お金観」を変えてきました。 日本やアメリカのみならず、本書が刊行された2013年時点で51ヶ国語に翻訳され、109ヶ国で読まれています。 教えの書―金持ち父さんの六つの教え 金持ちはお金のためには働かない お金の流れの読み方を学ぶ 自分のビジネスを持つ 会社を作って節税する 金持ちはお金を作り出す お金のためでなく学ぶために働く 実践の書 まず五つの障害を乗り越えよう スタートを切るための十のステップ 具体的な行動を始めるためのヒント

基礎 データ構造 整列 探索

複雑で変化の激しい問題に強いチームで立ち向かう。要求、見積り、進捗、問題を可視化する。ふりかえりとレビューにより、改善を繰り返す。属人化を解消し、チーム全体を成長させる。導入時に起こりがちな失敗を回避する。DeNA、GMOペパボ、mixiのノウハウを凝縮。 ソフトウェア開発の困難にスクラムで立ち向かう スクラムチーム スクラムイベント スクラムの作成物 スクラムを支えるプラクティス GMOペパボの事例-どのように導入したか mixiの事例-導入失敗からの立てなおし DeNAの事例-大規模開発、業務委託への適用 スクラム導入時によくある問題と解決策 スクラムチームでよくある問題と解決策〔ほか〕

Winner of the 2011 Jolt Excellence Award! Getting software released to users is often a painful, risky, and time-consuming process. This groundbreaking new book sets out the principles and technical practices that enable rapid, incremental delivery of high quality, valuable new functionality to users. Through automation of the build, deployment, and testing process, and improved collaboration between developers, testers, and operations, delivery teams can get changes released in a matter of hours- sometimes even minutes-no matter what the size of a project or the complexity of its code base. Jez Humble and David Farley begin by presenting the foundations of a rapid, reliable, low-risk delivery process. Next, they introduce the "deployment pipeline," an automated process for managing all changes, from check-in to release. Finally, they discuss the "ecosystem" needed to support continuous delivery, from infrastructure, data and configuration management to governance. The authors introduce state-of-the-art techniques, including automated infrastructure management and data migration, and the use of virtualization. For each, they review key issues, identify best practices, and demonstrate how to mitigate risks. Coverage includes * Automating all facets of building, integrating, testing, and deploying software * Implementing deployment pipelines at team and organizational levels * Improving collaboration between developers, testers, and operations * Developing features incrementally on large and distributed teams * Implementing an effective configuration management strategy * Automating acceptance testing, from analysis to implementation * Testing capacity and other non-functional requirements * Implementing continuous deployment and zero-downtime releases * Managing infrastructure, data, components and dependencies * Navigating risk management, compliance, and auditing Whether you're a developer, systems administrator, tester, or manager, this book will help your organization move from idea to release faster than ever-so you can deliver value to your business rapidly and reliably. Foreword by Martin Fowler Preface Acknowledgements About the Authors Part I Foundations 1 The Problem of Delivering Software 2 Configuration Management 3 Continuous Integration 4 Implementing a Testing Strategy Part II The Deployment Pipeline 5 Anatomy of the Deployment Pipeline 6 Build and deployment scripting 7 Commit Testing Stage 8 Automated Acceptance Testing 9 Testing Non-Functional Requirements 10 Deploying and Releasing Applications Part III The Delivery Ecosystem 11 Managing infrastructure and environments 12 Managing Data 13 Managing components and dependencies 14 Advanced version control 15 Managing Continuous Delivery Bibliography Index

「スクラムチームの母」と呼ばれる著者が「スクラムマスターは何をすればよいのか」に答えた本 「スクラムマスターは何をすればよいのか」に答えてくれる本 本書は、「スクラムチームの母」と呼ばれ、著名なスクラムトレーナーでもある著者が、 その経験則――スクラムマスターは何をすればよいのか――をまとめた、 Addison-Wesley Signature Series（Cohn）『The Great ScrumMaster: #ScrumMasterWay』 の日本語版です。 スクラムには、3つの役割があります。 プロダクトオーナー、開発チーム、スクラムマスターです。 プロダクトオーナーは、プロダクトの責任者であり、 開発チームは、プロダクトを開発します。 一方で、スクラムマスターは「サーバントリーダーであり、 促進と支援に責任を持つ」とあります（スクラムガイドより）。 これを読んで、何をすべきか理解できますか？ そう、スクラムマスターは、縁の下の力持ちであるがゆえに、 何をし、どのような姿勢でいればよいのか、理解が難しいロールなのです。 著者のZuzana Sochova氏も、本書の中で 「スクラムのロールの中で一番誤解されやすい」と述べています。 たとえば、突然、あなたはスクラムマスターを命じられたとします。 明日から、スクラムマスターとして、チームを支援していかなければなりません。 ●何から始めたらよいでしょうか？ ●スクラムマスターとして、どのようなスキルが必要でしょうか？ ●これから起こる困難に、どのように立ち向かっていけばよいでしょうか？ ●もっとチームが機能するにはどんな働きかけをしたらよいでしょうか？ 本書は、これらの疑問に真っ直ぐに答えてくれます。 開発者としてスクラムチームに参加した当初は、 まったくスクラムが好きになれなかったという著者。 そして、その後スクラムの良さに気づき、 その「スクラムチームの母」となっていく経験を通じ、 「スクラムマスターというロールについてもっとよい説明が必要だ」と、 彼女自身が #ScrumMasterWay というコンセプトで始めた活動がもとになったこの本。 スクラムマスターだけでなく、アジャイルコーチや、 組織改革を担うリーダーにもぜひ読んでいただきたい一冊です。 組織改革に立ち向かうあなたに、知恵と勇気を与えてくれることでしょう。 序文 ― リンダ・ライジング 日本語版に寄せて ― 永瀬美穂、ロッシェル・カップ CHAPTER 1　スクラムマスターの役割と責務 　自己組織化したチーム 　エクササイズ：自己組織化したチーム 　スクラムマスターの目標 　スクラムマスターの責務 　役割を兼務するときの落とし穴 CHAPTER 2　心理状態モデル 　ティーチングとメンタリング 　障害物の除去 　ファシリテーション 　コーチング 　例　アジャイルを始める 　例　障害物 　例　立ち往生 　例　責任 　エクササイズ　現在の心理状態 　このパズルに欠けているピース 　エクササイズ　未来の心理状態 CHAPTER 3　#スクラムマスター道 　エクササイズ　#スクラムマスター道 　レベル1 ― 私のチーム 　レベル2 ― 関係性 　レベル3 ― システム全体 　スクラムマスターのグループ 　1つのシステムとしての組織 　クネビンフレームワーク CHAPTER 4　メタスキルとコンピタンス 　メタスキル 　コンピタンス 　コアコンピタンス CHAPTER 5　チームを構築する 　タックマンの集団発達モデル 　チームの5つの機能不全 　チームの毒 　責任に目を向ける 　部族としての組織 　正しいリーダーシップのスタイルを選ぼう 　分散化のテクニックを使う CHAPTER 6　変化を実装する 　変化を求めて 　行動を変える 　変化を成功させるための8つのステップ CHAPTER 7　スクラムマスターの道具箱 　守破離をマスターする 　システムルール 　ポジティブさ 　ファシリテーション 　コーチング 　根本原因分析 　インパクトマッピング 　大規模スクラム 　カンバンから見たスクラムのチェックリスト 　XPプラクティスのチェックリスト 　プロダクトオーナーのチェックリスト CHAPTER 8　私は信じています 　偉大なスクラムマスター 　アジャイルやスクラムが自分たちに合っているのかどうかわからない？ 　組織をアジャイルに変えたい？ 　良いプロダクトバックログの作り方がわからない？ 　偉大なスクラムマスターになりたい？ 　チームを改善する方法を探している？ 　対立を解決したい？ 　偉大なプロダクトオーナーになりたい？ 　モダンなアジャイル組織になりたい？ 　あなたの組織を次のレベルに引き上げたい？