システムの品質を格段に向上させる方法

リーダブルコード

Amazon.co.jp: リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice): Dustin Boswell, Trevor Foucher, 須藤 功平, 角 征典: 本

1章 理解しやすいコード
    1.1 「優れた」コードって何?
    1.2 読みやすさの基本定理
    1.3 小さなことは絶対にいいこと?
    1.4 「理解するまでにかかる時間」は競合する?
    1.5 でもやるんだよ

第I部 表面上の改善

2章 名前に情報を詰め込む
    2.1 明確な単語を選ぶ
        もっと「カラフル」な単語を探す
    2.2 tmpやretvalなどの汎用的な名前を避ける
        tmp
        ループイテレータ
        汎用的な名前のまとめ
    2.3 抽象的な名前よりも具体的な名前を使う
        例:DISALLOW_EVIL_CONSTRUCTORS
        例:--run_locally
    2.4 名前に情報を追加する
        値の単位
        その他の重要な属性を追加する
    2.5 名前の長さを決める
        スコープが小さければ短い名前でもいい
        長い名前を入力するのは問題じゃない
        頭文字と省略形
        不要な単語を投げ捨てる
    2.6 名前のフォーマットで情報を伝える
        その他のフォーマット規約
    2.7 まとめ

3章 誤解されない名前
    3.1 例:filter()
    3.2 例:Clip(text, length)
    3.3 限界値を含めるときはminとmaxを使う
    3.4 範囲を指定するときはfirstとlastを使う
    3.5 包含/排他的範囲にはbeginとendを使う
    3.6 ブール値の名前
    3.7 ユーザの期待に合わせる
        例:get*()
        例:list::size()
    3.8 例:複数の名前を検討する
    3.9 まとめ

4章 美しさ
    4.1 なぜ美しさが大切なのか?
    4.2 一貫性のある簡潔な改行位置
    4.3 メソッドを使った整列
    4.4 縦の線をまっすぐにする
        整列すべきなのか?
    4.5 一貫性と意味のある並び
    4.6 宣言をブロックにまとめる
    4.7 コードを「段落」に分割する
    4.8 個人的な好みと一貫性
    4.9 まとめ

5章 コメントすべきことを知る
    5.1 コメントするべきでは「ない」こと
        コメントのためのコメントをしない
        ひどい名前はコメントをつけずに名前を変える
    5.2 自分の考えを記録する
        「監督のコメンタリー」を入れる
        コードの欠陥にコメントをつける
        定数にコメントをつける
    5.3 読み手の立場になって考える
        質問されそうなことを想像する
        ハマりそうな罠を告知する
        「全体像」のコメント
        要約コメント
    5.4 ライターズブロックを乗り越える
    5.5 まとめ

6章 コメントは正確で簡潔に
    6.1 コメントを簡潔にしておく
    6.2 あいまいな代名詞を避ける
    6.3 歯切れの悪い文章を磨く
    6.4 関数の動作を正確に記述する
    6.5 入出力のコーナーケースに実例を使う
    6.6 コードの意図を書く
    6.7 「名前付き引数」コメント
    6.8 情報密度の高い言葉を使う
    6.9 まとめ

第II部 ループとロジックの単純化

7章 制御フローを読みやすくする
    7.1 条件式の引数の並び順
    7.2 if/elseブロックの並び順
    7.3 三項演算子
    7.4 do/whileループを避ける
    7.5 関数から早く返す
    7.6 悪名高きgoto
    7.7 ネストを浅くする
        ネストが増える仕組み
        早めに返してネストを削除する
        ループ内部のネストを削除する
    7.8 実行の流れを追えるかい?
    7.9 まとめ

8章 巨大な式を分割する
    8.1 説明変数
    8.2 要約変数
    8.3 ド・モルガンの法則を使う
    8.4 短絡評価の悪用
    8.5 例:複雑なロジックと格闘する
        より優雅な手法を見つける
    8.6 巨大な文を分割する
    8.7 式を簡潔にするもう1つの創造的な方法
    8.8 まとめ

9章 変数と読みやすさ
    9.1 変数を削除する
        役に立たない一時変数
        中間結果を削除する
        制御フロー変数を削除する
    9.2 変数のスコープを縮める
        C++のif文のスコープ
        JavaScriptで「プライベート」変数を作る
        JavaScriptのグローバルスコープ
        PythonとJavaScriptのネストしないスコープ
        定義の位置を下げる
    9.3 変数は一度だけ書き込む
    9.4 最後の例
    9.5 まとめ

第III部 コードの再構成

10章 無関係の下位問題を抽出する
    10.1 入門的な例:findClosestLocation()
    10.2 純粋なユーティリティコード
    10.3 その他の汎用コード
        思いも寄らない恩恵
    10.4 汎用コードをたくさん作る
    10.5 プロジェクトに特化した機能
    10.6 既存のインタフェースを簡潔にする
    10.7 必要に応じてインタフェースを整える
    10.8 やりすぎ
    10.9 まとめ

11章 一度に1つのことを
    11.1 タスクは小さくできる
    11.2 オブジェクトから値を抽出する
        「一度に1つのタスク」を適用する
        その他の手法
    11.3 もっと大きな例
        さらなる改善
    11.4 まとめ

12章 コードに思いを込める
    12.1 ロジックを明確に説明する
    12.2 ライブラリを知る
    12.3 この手法を大きな問題に適用する
        解決策を言葉で説明する
        手法を再帰的に適用する
    12.4 まとめ

13章 短いコードを書く
    13.1 その機能の実装について悩まないで――きっと必要ないから
    13.2 質問と要求の分割
        例:店舗検索システム
        例:キャッシュを追加する
    13.3 コードを小さく保つ
    13.4 身近なライブラリに親しむ
        例:Pythonのリストとセット
        ライブラリの再利用はなぜいいことなのか
    13.5 例:コーディングするよりも
        Unixツールボックスを使う
    13.6 まとめ

第IV部 選抜テーマ

14章 テストと読みやすさ
    14.1 テストを読みやすくて保守しやすいものにする
    14.2 このテストのどこがダメなの?
    14.3 テストを読みやすくする
        最小のテストを作る
        独自の「ミニ言語」を実装する
    14.4 エラーメッセージを読みやすくする
        もっといいassert()を使う
        手作りのエラーメッセージ
    14.5 テストの適切な入力値を選択する
        入力値を単純化する
        1つの機能に複数のテスト
    14.6 テストの機能に名前をつける
    14.7 このテストのどこがダメだったのか?
    14.8 テストに優しい開発
    14.9 やりすぎ
    14.10 まとめ

15章 「分/時間カウンタ」を設計・実装する
    15.1 問題点
    15.2 クラスのインタフェースを定義する
        名前を改善する
        コメントを改善する
    15.3 試案1:素朴な解決策
        このコードは理解しやすいか?
        読みやすいバージョン
        パフォーマンスの問題
    15.4 試案2:ベルトコンベヤー設計
        二段階ベルトコンベヤーの実装
        これで終わり?
    15.5 試案3:時間バケツの設計
        時間バケツの実装
        TrailingBucketCounterを実装する
        ConveyorQueueの実装
    15.6 3つの解決策を比較する
    15.7 まとめ

付録 あわせて読みたい
    高品質のコードを書くための書籍
    プログラミングに関する書籍
    歴史的記録

解説(須藤 功平)
    実際にやる
        実際にやるとぶつかること
        他の人に読んでもらう
        おさらい
    当たり前にする
        既存のコードを読みやすくする前にやること
        続けることが大事
    コードで伝える
    読みやすいコードがもっと当たり前であり続けるために
        コミットメールのススメ
        まずはあなたが読む
        添削コミット
        おさらい

プログラマが知るべき97のこと

Amazon.co.jp: プログラマが知るべき97のこと: 和田 卓人, Kevlin Henney, 夏目 大: 本

    01   分別のある行動
        セブ・ローズ(Seb Rose)
    02  関数型プログラミングを学ぶことの重要性
        エドワード・ガーソン(Edward Garson)
    03  ユーザが何をするかを観察する(あなたはユーザではない)
        ジャイルズ・カルバン(Giles Colborne)
    04  コーディング規約を自動化する
        フィリップ・ヴァン・ラーネン(Filip van Laenen)
    05  美はシンプルさに宿る
        ヨルン・オルムハイム(Jorn Olmheim)
    06  リファクタリングの際に注意すべきこと
        ラジット・アタパトゥー(Rajith Attapattu)
    07  共有は慎重に
        ウディ・ダーハン(Udi Dahan)
    08  ボーイスカウト・ルール
        ロバート・C・マーティン(Robert C. Martin アンクル・ボブ)
    09  他人よりまず自分を疑う
        アラン・ケリー(Allan Kelly)
    10  ツールの選択は慎重に
        ジョヴァンニ・アスプローニ(Giovanni Asproni)
    11  ドメインの言葉を使ったコード
        ダン・ノース(Dan North)
    12  コードは設計である
        ライアン・ブラッシュ(Ryan Brush)
    13  コードレイアウトの重要性
        スティーブ・フリーマン(Steve Freeman)
    14  コードレビュー
        マティアス・カールソン(Mattias Karlsson)
    15  コードの論理的検証
        イェッチェル・キムチ(Yechiel Kimchi)
    16  コメントについてのコメント
        カル・エヴァンス(Cal Evans)
    17  コードに書けないことのみをコメントにする
        ケブリン・ヘニー(Kevlin Henney)
    18  学び続ける姿勢
        クリント・シャンク(Clint Shank)
    19  誰にとっての「利便性」か
        グレゴー・ホーぺ(Gregor Hohpe)
    20  すばやくデプロイ、こまめにデプロイ
        スティーブ・P・バーチャック(Steve Berczuk)
    21  技術的例外とビジネス例外を明確に区別する
        ダン・バーグ・ヨーンソン(Dan Bergh Johnsson)
    22  1万時間の訓練
        ジョン・ジャガー(Jon Jagger)
    23  ドメイン特化言語
        マイケル・フンガー(Michael Hunger)
    24  変更を恐れない
        マイク・ルイス(Mike Lewis)
    25  見られて恥ずかしいデータは使わないこと
        ロッド・ベグビー(Rod Begbie)
    26  言語だけでなく文化も学ぶ
        アンダース・ノラス(Anders Noras)
    27  死ぬはずのプログラムを無理に生かしておいてはいけない
        ヴェリティ・ストブ(Verity Stob)
    28  「魔法」に頼りすぎてはいけない
        アラン・グリフィス(Alan Griffiths)
    29  DRY原則
        スティーブ・スミス(Steve Smith)
    30  そのコードに触れてはならない!
        カル・エヴァンス(Cal Evans)
    31  状態だけでなく「ふるまい」もカプセル化する
        アイナー・ランドル(Einar Landre)
    32  浮動小数点数は実数ではない
        チャック・アリソン(Chuck Allison)
    33  オープンソースプロジェクトで夢を実現する
        リチャード・モンソンヘーフェル(Richard Monson-Haefel)
    34  API設計の黄金律
        マイケル・フェザーズ(Michael Feathers)
    35  超人の神話
        ライアン・ブラッシュ(Ryan Brush)
    36  ハードワークは報われない
        オルヴ・モーダル(Olve Maudal)
    37  バグレポートの使い方
        マット・ドーア(Matt Doar)
    38  余分なコードは決して書かない
        ピート・グッドリフ(Pete Goodliffe)
    39  最初が肝心
        マーカス・ベイカー(Marcus Baker)
    40  プロセス間通信とアプリケーションの応答時間の関係
        ランディ・スタッフォード(Randy Stafford)
    41  無駄な警告を排除する
        ヨハンネス・ブロドワル(Johannes Brodwall)
    42  コマンドラインツールを使う
        キャロル・ロビンソン(Carroll Robinson)
    43  プログラミング言語は複数習得すべき
        ラッセル・ワインダー(Russel Winder)
    44  IDEを知る
        ハインツ・カブーズ(Heinz Kabutz)
    45  限界を知る
        グレッグ・コルヴィン(Greg Colvin)
    46  すべきことは常に明確に
        ダン・バーグ・ヨーンソン(Dan Bergh Johnsson)
    47  大量のデータはデータベースで
        ディオミディス・スピネリス(Diomidis Spinellis)
    48  いろいろな言葉を学ぶ
        クラウス・マルカルド(Klaus Marquardt)
    49  見積りとは何か
        ジョヴァンニ・アスプローニ(Giovanni Asproni)
    50  Hello, Worldから始めよう
        トーマス・ゲスト(Thomas Guest)
    51  プロジェクト自身にしゃべらせる
        ダニエル・リンドナー(Daniel Lindner)
    52  「その場しのぎ」が長生きしてしまう
        クラウス・マルカルド(Klaus Marquardt)
    53  正しい使い方を簡単に、誤った使い方を困難に
        スコット・マイヤーズ(Scott Meyers)
    54  見えないものを見えるように
        ジョン・ジャガー(Jon Jagger)
    55  並行処理に有効なメッセージパッシング
        ラッセル・ワインダー(Russel Winder)
    56  未来へのメッセージ
        リンダ・ライジング(Linda Rising)
    57  ポリモーフィズムの利用機会を見逃さない
        カーク・ペパーディーン(Kirk Pepperdine)
    58  テスト担当者はプログラマの友人
        バーク・ハフネーゲル(Burk Hufnagel)
    59  バイナリは常に1つ
        スティーブ・フリーマン(Steve Freeman)
    60  真実を語るはコードのみ
        ピーター・ゾンメルラード(Peter Sommerlad)
    61  ビルドをおろそかにしない
        スティーブ・P・バーチャック(Steve Berczuk)
    62  プリミティブ型よりドメイン固有の型を
        アイナー・ランドル(Einar Landre)
    63  ユーザの操作ミスを防止する
        ジャイルズ・カルバン(Giles Colborne)
    64  プロのプログラマとは?
        ロバート・C・マーティン(Robert C. Martin アンクル・ボブ)
    65  バージョン管理システムを有効に使う
        ディオミディス・スピネリス(Diomidis Spinellis)
    66  いったんコンピュータから離れてみる
        バーク・ハフネーゲル(Burk Hufnagel)
    67  コードを読む
        カリアンヌ・バルク(Karianne Berg)
    68  「人間」を知る
        ケース・ブレイスウェイト(Keith Braithwaite)
    69  車輪の再発明の効用
        ジェイソン・P・セージ(Jason P. Sage)
    70  シングルトンパターンの誘惑に負けない
        サム・サーリスト(Sam Saariste)
    71  パフォーマンスへの道は地雷コードで敷き詰められている
        カーク・ペパーディーン(Kirk Pepperdine)
    72  シンプルさは捨てることによって得られる
        ポール・W・ホーマー(Paul W. Homer)
    73  単一責任原則
        ロバート・C・マーティン(Robert C. Martin アンクル・ボブ)
    74  「イエス」から始める
        アレックス・ミラー(Alex Miller)
    75  面倒でも自動化できることは自動化する
        ケイ・ホルストマン(Cay Horstmann)
    76  コード分析ツールを利用する
        サラ・マウント(Sarah Mount)
    77  偶然の仕様ではなく本物の仕様のためのテストを書く
        ケブリン・ヘニー(Kevlin Henney)
    78  テストは夜間と週末に
        ラジット・アタパトゥー(Rajith Attapattu)
    79  テストのないソフトウェア開発はあり得ない
        ニール・フォード(Neal Ford)
    80  1人より2人
        エイドリアン・ワイブル(Adrian Wible)
    81  エラーがエラーを相殺してしまう
        アラン・ケリー(Allan Kelly)
    82  他者への思いやりを意識したコーディング
        アスラム・カーン(Aslam Khan)
    83  UNIXツールを友にする
        ディオミディス・スピネリス(Diomidis Spinellis)
    84  正しいアルゴリズムとデータ構造を選ぶ
        ヤン・クリチアン・"JC"・ヴァン・ウィンケル(Jan Christiaan “JC” van Winkel)
    85  冗長なログは眠りを妨げる
        ヨハンネス・ブロドワル(Johannes Brodwall)
    86  WETなシステムはボトルネックが見つかりにくい
        カーク・ペパーディーン(Kirk Pepperdine)
    87  プログラマとテスターが協力してできること
        ジャネット・グレゴリー(Janet Gregory)
    88  コードは生涯サポートするつもりで書く
        ユーリー・ズバリョフ(Yuriy Zubarev)
    89  関数の「サイズ」を小さくする
        ケース・ブレイスウェイト(Keith Braithwaite)
    90  コードを見る人のためにテストを書く
        ジェラルド・メサローシュ(Gerard Meszaros)
    91  良いプログラマになるには
        ピート・グッドリフ(Pete Goodliffe)
    92  顧客の言葉はそのまま受け取らない
        ネイト・ジャクソン(Nate Jackson)
    93  エラーを無視するな
        ピート・グッドリフ(Pete Goodliffe)
    94  リンカは魔法のプログラムではない
        ウォルター・ブライト(Walter Bright)
    95  ペアプログラミングと「フロー」
        グドニー・ハウクネス(Gudny Hauknes)、カリ・ロスランド(Kari Rossland)、
        アン・カトリン・ガナット(Ann Katrin Gagnat)
    96  テストは正確に、具体的に
        ケブリン・ヘニー(Kevlin Henney)
    97  ステートに注目する
        ニクラス・ニルソン(Niclas Nilsson)

日本人プログラマによる知っておくべき10のこと

    01  命を吹き込む魔法
        森田 創
    02  ロールプレイングゲーム
        関 将俊
    03  ルーチンワークをフローのきっかけに
        宮川 達彦
    04  プログラマが持つべき3つのスキル
        吉岡 弘隆
    05  快適な環境を追求する
        舘野 祐一
    06  見知らぬ人ともうまくやるには
        小飼 弾
    07  不具合にテストを書いて立ち向かう
        和田 卓人
    08  育ちのよいコード
        森田 創
    09  Noといえることの大事さ
        宮川 達彦
    10  名前重要
        まつもと ゆきひろ

ソフトウェアアーキテクトが知るべき97のこと

Amazon.co.jp: ソフトウェアアーキテクトが知るべき97のこと: 鈴木 雄介, Richard Monson-Haefel, 長尾 高弘: 本

01 システムの要件よりも履歴書の見栄えを優先させてはならない
    ニティン・ボーワンカー
02 本質的な複雑さは単純に、付随的な複雑さは取り除け
    ニール・フォード
03 最大の問題は、たぶん技術的なことではない
    マーク・ラム
04 まずコミュニケーション、そのための明快さととリーダーシップ
    マーク・リチャーズ
05 パフォーマンスの決め手はアーキテクチャー
    ランディ・スタッフォード
06 要求仕様の本当の意味を探れ
    アイナー・ランドル
07 立ち上がろう!
    ウディ・ダーハン
08 すべてのものは、かならずエラーを起こす
    マイケル・ナイガード
09 それは交渉だということに気付け
    マイケル・ナイガード
10 定量化を求めよ
    キース・ブレイスウェイト
11 500行の仕様書より1行のコード
    アリソン・ランダル
12 フリーサイズのソリューションを求めるな
    ランディ・スタッフォード
13 パフォーマンスの検討に早過ぎるということはない
    レベッカ・パーソンズ
14 アーキテクチャーとはバランスを取ること
    ランディ・スタッフォード
15 犯罪的なコミットエンドランを防ぐには
    ニクラス・ニルソン
16 選択肢を1つに絞らないための現実的な方法
    キース・ブレイスウェイト
17 ビジネスサイドに主導権を渡せ
    デーブ・ミュアヘッド
18 一般性より単純性、再利用よりもまず最初に使えること
    ケブリン・ヘニー
19 アーキテクトは手を汚さなければならない
    ジョン・デービーズ
20 継続的にインテグレーションを実行せよ
    デビッド・バートレット
21 日程による失敗を避けるために
    ノーマン・カーノベール
22 アーキテクチャーではトレードオフは避けられない
    マーク・リチャーズ
23 要塞としてのデータベース
    ダン・チャック
24 不確定性が潜むという感覚を磨け
    ケブリン・ヘニー
25 鏡に映る問題は見かけよりも大きい
    デーブ・クイック
26 再利用は、アーキテクチャーだけではなく人と教育の問題と心得よ
    ジェレミー・メイヤー
27 アーキテクチャーにI(自我)なし
    デーブ・クイック
28 地上300mからの目
    エリック・ドーネンバーグ
29 選ぶ前に試せ
     エリック・ドーネンバーグ
30 ビジネスドメインを理解せよ
     マーク・リチャーズ
31 プログラミングは製造ではなく設計だ
    アイナー・ランドル
32 デベロッパーに自己裁量を与えよ
    フィリップ・ネルソン
33 時間がすべてを変える
    フィリップ・ネルソン
34 「ソフトウェア・アーキテクト」のAは小文字だけ。それで満足せよ
    バリー・ホーキンス
35 大きなスコープは敵
    デーブ・クイック
36 役者ではなく執事になれ
    バリー・ホーキンス
37 ソフトウェア・アーキテクチャーが倫理的な意味を持つことを考えよ
    マイケル・ナイガード
38 摩天楼はスケーラブルではない
    マイケル・ナイガード
39 未来はヘテロジニアスとともにある
    エドワード・ガーソン
40 パフォーマンスがまず大事
    クレイグ・ラッセル
41 ダイアグラムの空白に注意せよ
    マイケル・ナイガード
42 デザインパターンに習熟せよ
    マーク・リチャーズ
43 状況が何よりも大切
    エドワード・ガーソン
44 ドワーフ、エルフ、ウィザード、キングの4種類の人々
    エバン・コフスキー
45 建物のアーキテクト(建築家)から学ぼう
    キース・ブレイスウェイト
46 繰り返しと戦え
    ニクラス・ニルソン
47 現実の世界にようこそ
    グレガー・ホープ
48 支配せず、観察せよ
    グレガー・ホープ
49 アーキテクトは2つの顔を持つ
    デビッド・バートレット
50 アーキテクトは境界とインターフェイスに注意を注げ
    アイナー・ランドル
51 デベロッパーに力を
    ティモシー・ハイ
52 理由を書き留めよ
    ティモシー・ハイ
53 暗黙の仮定、特に自分自身のものを疑え
    ティモシー・ハイ
54 あなたの知識と経験を共有しよう
    ポール・W・ホーマー
55 パターンの病理学
    チャド・ラヴィーニュ
56 たとえ話の使いすぎに注意
    デビッド・イング
57 アプリケーションの保守に力を入れよ
    ムセディシ・カスパー
58 3つから2つだけを選ぶ覚悟を決めよ
    ビル・デオーラ
59 趣味や個人的な意見ではなく、原理原則に従え
    マイケル・ハーマー
60 動くスケルトンから始めよ
    クリント・シャンク
61 データがすべて
    ポール・W・ホーマー
62 単純なものは単純に
    チャド・ラヴィーニュ
63 アーキテクトは何よりもまずデベロッパーであれ
    マイク・ブラウン
64 ROI変数を意識せよ
    ジョージ・マラミディス
65 目の前にあるのはレガシーシステムだという前提で設計せよ
    デーブ・アンダーソン
66 解決策が1つしかない場合には、セカンドオピニオンを求めよ
    ティモシー・ハイ
67 変化の影響を把握せよ
    ダグ・クロフォード
68ハードウェアの理解も必要
    カメル・ウィックラマナヤケ
69 今の近道、後で大損
    スコット・マクフィー
70 「完璧」は、「十分よい」の敵
    グレッグ・ナイバーグ
71 「よいアイデア」を避けよ
    グレッグ・ナイバーグ
72 優れたコンテンツは優れたシステムを作る
    ズービン・ワディア
73 怒れるアーキテクトとしてビジネスと対立するな
    チャド・ラヴィーニュ
74 主要な指標の耐久性を試してどこで壊れるかを確かめよ
    ステファン・ジョーンズ
75 設計するならコーディングできなければならない
    マイク・ブラウン
76 他の名前でバラを呼べば、キャベツにしかならない
    サム・ガーディナー
77 しっかりとした問題には高品質のソリューションが与えられる
    サム・ガーディナー
78 勤勉さが必要
    ブライアン・ハート
79 自分の判断に責任を持て
    イ・ジュウ
80 クレバーになるな
    イーベン・ヒューイット
81 武器は慎重に選べ、安易に手放すな
    チャド・ラヴィーニュ
82 本当の顧客は目の前の顧客ではない
    イーベン・ヒューイット
83 設計した通りにはならない
    ピーター・ジラードモス
84 フレームワークは相性で選べ
    エリック・ホーソーン
85 強力なビジネスケースを作れ
    イ・ジュウ
86 コードだけではなくデータをコントロールせよ
    チャド・ラヴィーニュ
87 技術上の借金は返済せよ
    バークハート・ハフネーゲル
88 問題を解こうとするな
    イーベン・ヒューイット
89 システムは用具的に作れ
    キース・ブレイスウェイト
90 問題解決に情熱を注げるデベロッパーを探して手放すな
    チャド・ラヴィーニュ
91 ソフトウェアは実際には存在しない
    チャド・ラヴィーニュ
92 新しい言語を学べ
    バークハート・ハフネーゲル
93 未来永劫安泰なソリューションはない
    リチャード・モンソンヘーフェル
94 ユーザーの拒否感情の問題
    ノーマン・カーノベール
95 コンソメの重要性
    イーベン・ヒューイット
96 エンドユーザーの立場からはインターフェイスこそがシステム
    ヴィナヤク・ヘッジ
97 優れたソフトウェアは構築されるのではなく、成長する
    ビル・デオーラ

日本人アーキテクトによる知っておくべき11のこと

01 アーキテクチャは縦と横の基本構造を持つ
    萩原正義
02 ビジネス・アーキテクトを目指せ
    萩本順三
03 問題にフォーカスせよ
    榊原彰
04 問題にとらわれるな
    榊原彰
05 煩雑なことを非属人化し、創造性を高める
    萩原正義
06 手段的な技術と陳腐化しない本質的な技術
    伊藤直也
07 開発スタイルをデザインする
    小野和俊
08 システムではなく、コミュニケーションをデザインせよ
    鈴木雄介
09 移り気な利用者を捉える
    牧野友紀
10 受動的アーキテクトと能動的アーキテクト
    江島健太郎
11 説明責任を果たす
    萩本順三

プロジェクト・マネジャーが知るべき97のこと

Amazon.co.jp: プロジェクト・マネジャーが知るべき97のこと: 神庭 弘年, Barbee Davis, 笹井 崇司: 本

01 できるだけ早期にユーザーを巻き込む
    バービー・デイビス(Barbee Davis)
02 モグラたたき開発を避けよう
    ベンカト・スブラマニアム(Venkat Subramaniam)
03 ローカライゼーションのせいで締め切りに遅れる
    パベル・シムサ(Pavel Simsa)
04 プロジェクト・オーナーは強力なプロジェクトサポーター
    武谷 美世子(Miyoko Takeya)
05 複雑よりもシンプルな方がいい
    スコット・デイビス(Scott Davis)
06 負債を支払う
    ブライアン・スレッテン(Brian Sletten)
07 スキルでなく素質のある人を加えよう
    リチャード・シェリダン(Richard Sheridan)
08 シンプルにいこう
    クリシュナ・カダリ(Krishna Kadali)
09 あなたは特別ではない
    ジャレッド・リチャードソン(Jared Richardson)
10 スクロールから学んだこと
    キム・マッコーマック(Kim MacCormack)
11 問題にかかるコストを削減する
    ランディ・ルーミス(Randy Loomis)
12 すぐれた開発者を見つけるには
    ジェームス・グラハム(James Graham)
13 熟練と並の開発者の生産性
    ニール・フォード(Neal Ford)
14 大きさが重要
    アヌパム・クンドゥ(Anupam Kundu)
15 手順を文書化して、守られているか確かめよう
    モンテ・デイビス(Monte Davis)
16 さあ、プラクティスを投げ捨てよう
    ナレシュ・ジャイン(Naresh Jain)
17 要求と仕様
    アラン・グリーンブラット(Alan Greenblatt)
18 成功はビジネス価値で評価される
    バービー・デイビス(Barbee Davis)
19 休暇をキャンセルしない
    ジョー・ゼネビッチ(Joe Zenevitch)
20 集中する時間を取る
    ジェームス・リー(James Leigh)
21 プロジェクトマネジメントはプロブレムマネジメント
    ローリン・アンガー(Lorin Unger)
22 開発者を活かす
    ケン・サイプ(Ken Sipe)
23 巧妙なコードはメンテナンスが困難
    デイビッド・ウッド(David Wood)
24 人的要素を管理する
    ジェームス・グラハム(James Graham)
25 Wikiを使う
    エイドリアン・ワイブル(Adrian Wible)
26 ミッシングリンク
    ポール・ワゴナー(Paul Waggoner)
27 見積もって見積もって見積もる
    リチャード・シェリダン(Richard Sheridan)
28 PMOの導入:開発者の足並みをそろえる
    アンジェロ・ヴァーリ(Angelo Valle)
29 労力ではなく結果を評価する
    ベンカト・スブラマニアム(Venkat Subramaniam)
30 プロジェクトの失敗は組織の失敗
    ブライアン・スレッテン(Brian Sletten)
31 顧客からの声
    マーティ・スコマル(Marty Skomal)
32 物事を正しくとらえる
    ジェームス・グラハム(James Graham)
33 「完了」をどう定義するか
    ブライアン・サムボッデン(Brian Sam-Bodden)
34 60/60ルール
    デイビッド・ウッド(David Wood)
35 我々は敵に出会った。それは我々自身だ
    バービー・デイビス(Barbee Davis)
36 サイクルで働く
    ジェームス・リー(James Leigh)
37 自らに誠実であれ
    ハリー・タッカー(Harry Tucker)
38 ミーティングはコードを書かない
    ウィリアム・J・ミルズ(William J. Mills)
39 変化のための道筋を描く
    キャシー・マクドゥガル(Kathy MacDougall)
40 ITプログラムの管理
    デビッド・ディアス・カスティロ(David Diaz Castillo)
41 現実を考慮して計画する
    クレイグ・レタベック(Craig Letavec)
42 完全な実行という誤った考え
    デイビッド・ウッド(David Wood)
43 アジャイルなコミュニケーションシステムを導入する
    ブライアン・サムボッデン(Brian Sam-Bodden)
44 方法論を崇拝しない
    ファビオ・テイセイラ・デ・メロ(Fabio Teixeira de Melo)
45 人的問題にスプレッドシートを持ち込まない
    アヌパム・クンドゥ(Anupam Kundu)
46 ひとつの成果物にひとりの責任者
    アラン・グリーンブラット(Alan Greenblatt)
47 完全な知識という誤った考え
    デイビッド・ウッド(David Wood)
48 スプリントでなくマラソンのためのチームづくり
    ナレシュ・ジャイン(Naresh Jain)
49 プロジェクトマネジメントの三位一体
    ポール・ワゴナー(Paul Waggoner)
50 ロードマップを作ろう
    キャシー・マクドゥガル(Kathy MacDougall)
51 プロジェクトスコープ記述書の重要性
    キム・ヘルドマン(Kim Heldman)
52 ビジョンと期待される成果に合わせる
    デビッド・ディアス・カスティロ(David Diaz Castillo)
53 アリスはもうここにはいない
    バービー・デイビス(Barbee Davis)
54 契約紛争を避ける
    ジョージ・ギルバート(Jorge Gelabert)
55 評価指標に基づいて行動する
    ナレシュ・ジャイン(Naresh Jain)
56 「自前主義」に陥るな
    ポール・ギアンマルヴォ博士(Paul Giammalvo)
57 「もうすぐ」よりも「今」を大切に
    スコット・デイビス(Scott Davis)
58 スピードこそ命、速ければ速いほどいい?
    マット・"ブーン"・ダニエル(Matt "Boom" Daniel)
59 チームのモラルづくり
    デイビッド・ボック(David Bock)
60 プロジェクトはチームワーク次第
    レリオ・ヴァレラ(Lelio Varella)
61 チームのために働く
    カレン・ギリソン(Karen Gillison)
62 大きな丸いボールという誤った考え
    デイビッド・ウッド(David Wood)
63 危機への対応
    ジェームス・グラハム(James Graham)
64 インテグレーションポイントを知る
    モンテ・デイビス(Monte Davis)
65 分散したプロジェクトにおける積極的なコミュニケーション
    アヌパム・クンドゥ(Anupam Kundu)
66 結果を想定して始める
    ルイス・E・トーレス(Luis E. Torres)
67 約束事が明確なら友情も長続きする
    マッテオ・ベッキ(Matteo Becchi)
68 一番うまく見積もれるのはその仕事をする人である
    ジョー・ゼネビッチ(Joe Zenevitch)
69 コミュニケーションが重要
    ゲナディ・ミロノフ(Gennady Mironov)
70 プロジェクトは解決策の追求である
    シンシア・A・バーグ(Cynthia A. Berg)
71 鍵は人間にある
    エイドリアン・ワイブル(Adrian Wible)
72 ドキュメントは手段であり目的ではない
    パトリック・クア(Patrick Kua)
73 アーンドバリューとベロシティは共存できるか
    バービー・デイビス(Barbee Davis)
74 スコープ変更に慣れよう
    パベル・シムサ(Pavel Simsa)
75 既製のソフトウェアを購入するということ
    エルナーニ・マルケス・ダ・シルバ(Ernani Marques da Silva)
76 よいスポンサー、わるいスポンサー、ひどいスポンサー
    ジョージ・ギルバート(Jorge Gelabert)
77 約束以上にすべきか、約束以下にすべきか
    ジョー・ゼネビッチ(Joe Zenevitch)
78 プロジェクト・マネジャーは契約管理者である
    ファビオ・テイセイラ・デ・メロ(Fabio Teixeira de Melo)
79 重要だが緊急ではないこと
    アレックス・ミラー(Alex Miller)
80 プロセスについて教える
    リチャード・シェリダン(Richard Sheridan)
81 ステータスという間違った考え
    ウディ・ダーハン(Udi Dahan)
82 みんなが聞きたいことは何ですか?
    マーサ・レガーレ(Martha Legare)
83 モラルの重要性を認識する
    デイビッド・ボック(David Bock)
84 ステークホルダーをずっと参加させる
    ルークマン・ラワル(Lukeman Lawal)
85 計画の価値
    デリー・ジンメル(Derry Simmel)
86 「メッセンジャー」にならない
    マット・セコスキ(Matt Secoske)
87 成果物を効果的に管理する
    エルナーニ・マルケス・ダ・シルバ(Ernani Marques da Silva)
88 私たちはスーパーヒーローではありません
    アンジン・J・ショック-スミス(Angyne J. Schock-Smith)
89 頻繁に即座にミーティングする
    リチャード・シェリダン(Richard Sheridan)
90 柔軟性がプロジェクトマネジメントをシンプルにする
    クリシュナ・カダリ(Krishna Kadali)
91 Webが道を示す(今のところは)
    デイビッド・ウッド(David Wood)
92 ステータスレポートは開発者に嫌がられ、マネジャーに愛される
    パベル・シムサ(Pavel Simsa)
93 あなたはコントロールしていない
    パトリック・クア(Patrick Kua)
94 ビジョンを共有する
    ジャレッド・リチャードソン(Jared Richardson)
95 真の成功にはサポートする組織が必要
    シンシア・A・バーグ(Cynthia A. Berg)
96 ガバナンスを確立する
    エルナーニ・マルケス・ダ・シルバ(Ernani Marques da Silva)
97 あなたのWebサイトが嫌いな9.7の理由
    バービー・デイビス(Barbee Davis)

日本を中心に活躍するプロジェクト・マネジャーによる
知っておくべき11のこと

01 自分に対する約束をどう守るか
    冨永 章
02 プロジェクトの目的と成功の条件
    芝尾 芳昭
03 「正しい判断」にこだわるな
    重木 昭信
04 「見積り=不幸の始まり」にしないために
    初田 賢司
05 プロジェクトによる人材育成
    芝尾 芳昭
06 「しなければならないこと」と「できること」
    奥沢 薫
07 まずプロジェクトの「目的」を確認せよ
    重木 昭信
08 人を従えるのか、人が従うのか
    神庭 弘年
09 予防的なプロジェクト管理のすすめ
    重木 昭信
10 踏み込めば権限がついてくる
    冨永 章
11 プロジェクトの条理と不条理
    林 衛