エンジニアリングエッセイのススメ

人月と神話

第2章 人月の神話

• 見積もり技術は、人と月とが相互に交換可能だという過程を隠している
• 人と月が交換可能になるのは、作業者の間でコミュニケーションを図らなくても仕事を分担できる時だけである
• 人を一人追加したとしても、ひと月で一人月分の作業が進むわけではない
  • 要員追加時には教育・訓練のコストが発生する
  • コミュニケーションコストも増える
  • タスクの分解粒度も見直され、システム（結合）テストの工数も増える
• 人月交換可能な見積もりに対してプロジェクトが遅延し、さらに人員を追加し、また遅れていく負のスパイラル
• 遅れているソフトウェアプロジェクトへの要員追加は、さらにプロジェクトを遅らせるだけ（ブルックスの法則）

第16章 銀の弾丸などない

• ハードウェアの分野ではエレクトロニクスやトランジスタ、LSI などで、生産性や信頼性が大幅に改善された
• ソフトウェアの領域ではそんな特効薬はなさそうに思える
• ソフトウェアは本質的に複雑である
  • 本質的な複雑性と偶有的な複雑性を区別する
  • 本質的な複雑性は、解決すべき問題によってもたらされるもの
    • 取り除くことはできない
  • 偶有的な複雑性は、目下の生産には付きまとうが、本来不必要な複雑性
    • ソフトウェア開発者自身が発生させている解決可能な問題
    • 例えば、クラス設計やハードウェアの性能などから生じる複雑性
• ソフトウェアの基本的要素に含まれる固有の性質
  • 複雑性
    • どの二つの部分をとっても似通うことがないので、大きさの割に他のどの人工物よりも複雑
    • 夥しい数の要素と状態、組み合わせがある
  • 同調性
    • インターフェースを人間の社会制度やシステムへの適合を強要される
    • 周りのものに従わされる運命にある
  • 可変性
    • 大当たりしたソフトウェアは大抵全て変更される
  • 不可視性
    • 目に見えないもので、具現化しようとすると一つの有向グラフでは無理
• 本質的な複雑性は取り除くことができないが、改善はできる
• 複雑性への対抗策
  • 作るより買う
  • 要件の洗練とラピッドプロトタイピング
  • インクリメンタル開発
  • 偉大なコンセプトデザイナーを育てる

ピープルウェア

第1章 今日もどこかでトラブルが

• ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである
• マネージャーの責務を果たす上で大事なのは人間中心に考えること
  • しかし、これはいつも蔑ろにされがち
  • なぜなら、人間同士の問題に対応するより、技術的問題を解消する方が簡単だから
• どのように仕事するかは教えるが、どうマネジメントするかは教育しない企業が多い

第4章 品質第一、時間さえ許せば

• 作る側の品質理論は自尊心と強く結びついている
  • プログラマを満足させる最低の基準は、今までに達成した最高の基準である
  • この水準はマーケットが望み、金を払って手に入れようとするものよりずっと高い
• ユーザーは品質ほど大事なものはないと言うが、それにお金を払う段になると品質について本当はどう考えているかが明らかになる
  • 「あと三週間あれば品質を高くできる」と聞いても、「いや三週間は待てない」という人がほとんど
• 早くリリースしろとせっつき、低品質の製品を受け入れてきたことを考えると、ユーザーの品質意識はかなり低いことは明白である
• 長期的には、市場に品質を合わせるとコストは増える
• エンドユーザーの要求を遥かに超えた品質水準は、生産性をあげる一つの手段である
• 「どの組織、文化、国家が、品質の高いことで有名か？」と問えば、ほとんどの人が日本と答えるだろう
• 「どの組織、文化、国家が、生産性の高いことで有名か？」と問えば、これもほとんどの人が日本と答えるだろう
• 高品質と高生産性は両立する

第21章 全体は部分の和より大なり

• ヒステリックな楽観主義によるマネジメント
• 部下が放っておいても組織の目標を受け入れると思うのは、未熟な楽観主義の表れ
• 個人が組織の目標を引き受ける仕組みは遥かに複雑である
• 上司であるあなたは組織の目標を心から受け入れているが、部下も同じとは限らない
  • あなたの目標への情熱は単なるプロ意識を超えたところから生じている可能性がある
  • 自分の上司や経営者によって強固な動機付けをさせるための巧妙な仕掛けが作られているかもしれない
• しかし、平社員の動機付けはもっと複雑
  • 宗教団体のような信仰でもなければ、組織の目標に対する自然な親しみを持つことを当てにできない
  • 重役会が利益の大幅な増加で盛り上がっていても、平社員には増益などほんのつまらないものでしかない
• チーム編成の目的は目標を達成することではなく、目標を一致させることである
  • 方向性の一致は大きな力を生む
• 結束する前は給料、地位、昇進ルートといったものが極めて大事だが、結束後はそんなものどうでもよくなり、退職率も下がる

第23章 チーム殺し、7つの秘訣

• 守りのマネジメント
• 官僚主義
• 作業場所の分散
• 時間の分断
• 製品の品質削減
• ハッタリの納期
• チーム解体の方針

ハッカーと画家

第2章 ハッカーと画家

• ハッキングと絵を描くことにはたくさんの共通点がある
  • ハッカーと画家はどちらもモノを創る人間
• 偉大なソフトウェアも、同じように、美に対する熱狂的な没頭が必要だ
  • 良いソフトウェアの中身をみてみれば、誰も見ないような箇所でさえ美しく創られていることがわかるだろう
• ハッキングには、絵を描く時と同じように、周期がある
• ある時は新しいプロジェクトに夢中になって、1日16時間それをやり続ける
• 別の時には何も面白いと感じられない
• 絵画と同様、ソフトウェアも多くは人間が見て、使うもの
  • だからハッカーも、画家と同じように、本当にすごい仕事を為すには、 共感する力が必要
  • ユーザの視点からものを見られるようにならなくちゃいけない
  • 共感能力は、おそらく良いハッカーと偉大なハッカーの、 たった一つの最も重要な違いだろう

第12章 普通のやつらの上を行け

• ソフトウェアビジネスは極めて競争の激しい業界
• ある会社が他の会社より、他が同じ条件で、より良いソフトウェアをより速く書いたとしたら、他の会社はいずれ潰れる
• ベンチャーは他のベンチャーと同じことをやっていてはいけない
• 私たちは Lisp を選んだ。一つには、このマーケットで素早く開発することが重要だというのが明らかだったからだ
  • Lisp はソフトウェアを素早く書くのに良い言語だ
  • 他の会社が Lisp を使いたがらなければ、それは良いことだった
• Lisp のおかげで私たちの開発サイクルは非常に速く、相手がプレスリリースを出した1日2日後にはもう同様の機能を作ったこともしばしばある

第16章 素晴らしきハッカー

• ほかの多くの分野でも同じだが、プログラミングでも、難しいのは問題を解くことではなく、どの問題を解くかを決めることだ
  • 想像力を測るのは難しい
• しかし、現実にはそれはコードの行数で測られるような生産性を遥かに凌駕するだろう
• 技術は生産性の差を拡大する

参考

ポールグレアムのエッセイ和訳一覧

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

共有は慎重に

• 大学を出たてで、自分の能力を証明したくてしょうがなかった頃
• 初めて仕事を任された時、担当部分の作業にこれまで自分の学んできたことをどうしても実践してみたくなった
• 内容が似通っているコードを出来るだけライブラリ化してみた
• しかし、意気揚々と臨んだコードレビューでそれが失敗だったことを思い知らされる
• コードをライブラリ化してしまったことで、それを利用する部分には依存関係が発生
• ライブラリのコードを1行変更しただけで、その影響は複数箇所に及ぶ
• 考えた結果わかったのは、「コンテキスト」が大事ということ
• システム内に同様の処理を行う部分が2つあったとしても、それらのシステムにおける役割が大きく異なっていれば、再利用によるメリットは小さい
• たとえコードが4行ほどのもので、行っていることが同じだったとしても、それはたまたま一時的にそうなっていただけのこと
• 再利用は基本的に良いことだが、システム全体の構造がわかるまでは共有は慎重に行う

良いプログラマになるには

• 良いコードは何の根拠もなく勝手に生まれたりはしない
• 良いコードを書きたいと心の底から願い、努力をした人だけが本当に良いコードを書ける
• ただ技術が優れているというだけでは良いコードは書けない
• 素晴らしいアルゴリズムを考え出せる知性を持ち、プログラミング言語についての知識も十分なプログラマが、実にひどいコードを書くというのは珍しくない
• 反対に、能力は平凡でも、シンプルなコードを書こうと細心の注意を払った結果、美しく、わかりやすいコードができあがったという例がたくさんある
• 良いプログラマとそうでないプログラマの最大の違いは「取り組む姿勢」にある
• 良いプログラマの姿勢は、プロフェッショナルという言葉にふさわしいもの
  • 常に、最大限の力を尽くして良いコードを書こうとする
  • リソースの制約のある中、早く作業を終わらせろと会社が圧力をかけてくる中、それでもできる限り良いコードを書こうと努力をする
• 良いプログラマになりたいのなら、常に次のことを心がける必要がある
  • どんな場合でも、「とりあえず動きそう」というだけのコードは決して書かない
  • わかりやすいコード(どういうコードなのか、何をするコードなのか、他人が見てすぐにわかるコード)、保守しやすいコード(自分自身や、他のプログラマが、将来、簡単に修正を加えることができるコード)、正しいコード(単に見かけ上、動くだけでなく、問題を間違いなく解決できるコード)を書く
  • 他のプログラマと協調する
  • 自分が扱ったコードは、必ず、自分が最初に見た時よりも少しでも良いコードにする
  • 絶えず積極的に新しい言語、イディオム、テクニックを学ぶ。ただし、学んだことをむやみには使わない

参考

ネット上で公開されているサイト

情熱プログラマー

第1章 市場を選ぶ

• 一番の下手くそでいよう
  • 自分より優れた人たちがいるチームで働く
• GitHub に専念するためにマイクロソフトの30万ドルの仕事を断った
  • 振り返って 「確かにあれは安全だった」と思うより「あれは冒険だった」と思える方がいい
• 愛せよ、さもなくば捨てよ
  • 向上するには、情熱が必要
  • やっている仕事に情熱を持てるかどうかがパフォーマンスに影響する

第5章 研鑽を怠らない

• すでに時代遅れである
• 僕らがIT業界に引き寄せられるのは、常に変化があるから
• その反面、手に入れた技術がすぐに陳腐化する
• 一生安泰な技術はない
• その技術が主流に近くなればなるほど、技術の石器時代に取り残されるリスクが大きくなる
• 全てはタイミング
• 今何を勉強するべきか先取りして考える
• どの知識に投資するかはある意味ギャンブルではあるが、賭けなければ確実に負ける
• 選択をミスすると将来の仕事確保に繋がらないスキルをせっせと学ぶことになる
• 将来のことをよく考えてギャンブルに乗り出す