できるプログラマになる! "伝える"技術

[表紙]できるプログラマになる!

A5判/224ページ

定価(本体1,980円+税)

ISBN 978-4-7741-4642-3

ただいま弊社在庫はございません。

→学校・法人一括購入ご検討の皆様へ

書籍の概要

この本の概要

―「単なる」プログラマと「できる」プログラマの違いは? プログラマという頭脳労働者には特別な仕事術が必要なのでは?― プログラミングの指導を通して著者がたどり着いた上達のポイントは,「3つの説明力」だ。プログラマの仕事には常に3つの説明相手,すなわち自分・コンピュータ・他人があり(おり),それぞれに適した"伝える"技術を磨く必要がある。豊富な情報科学の知識をベースに,「うどん屋のパイプライン」など巧みな比喩を駆使した語り口で,それぞれの方法論を明らかにしていく。

こんな方におすすめ

  • ステップアップしたいプログラミング初級者
  • プログラマになりたいと考えているひと・学生

この書籍に関連する記事があります!

プログラマの夫とその妻へ
「お使いを頼むわ,牛乳を1パック買ってきてちょうだい。卵があったら6つお願い!」しばらくして夫は牛乳を6パック買ってきました。妻は聞きました。「なんでまた牛乳を6パックも買ってきたのよ?」そこで夫は答えました。「だって卵があったよ」

目次

第1章 頭脳労働者としてのプログラマ

1.1 頭脳労働の極端な例

  • 1.1.1 プログラマという特殊な職業
  • 1.1.2 単純作業と頭脳労働の違い
  • 1.1.3 ゴールに近づくほど,ハードルが上がる?
  • 1.1.4 プログラミングの困難さは,近づいてもゴールが見えないこと

1.2 プログラマとして何を目指すか

  • 1.2.1 エンジニア・職人・芸術家
  • 1.2.2 考え方の流れが「動く」「残る」

1.3 どうやって上達していくか?

  • 1.3.1 まずは本で独学する
  • 1.3.2 辞書を覚えても,小説は書けない
  • 1.3.3 「採掘場」のように,深く広く理解する
  • 1.3.4 ゆっくりとした大きな動きを見る

1.4 プログラマが持つべき3つの説明力

  • 1.4.1 3つの説明相手
  • 1.4.2 自分向け(その1):説明することで考えを整理する
  • 1.4.3 自分向け(その2):その瞬間の脳内コンテクストを固定する
  • 1.4.4 コンピュータ向け:説明としてのプログラミング
  • 1.4.5 他人向け:いわゆる「説明」
  • 1.4.6 3つの説明を意識して使い分ける
  • 第1章のまとめ
  • Column 公開プログラミングの効果

第2章 土台としての情報科学

2.1 土台の必要性

  • 2.1.1 知って何が変わるのか?
  • 2.1.2 根本は「計算と記憶」なのだと知る

2.2 ノイマンとチューリングのおかげです

  • 2.2.1 知らずにプログラミングすることの弊害
  • 2.2.2 ノイマン型のいったいどこが特徴なのか?
  • 2.2.3 区別がないから,「虫」と「穴」が生まれる
  • 2.2.4 ビンの首がボトルネック
  • 2.2.5 頭の中のコンピュータ:チューリング・マシン
  • 2.2.6 仕様書通りか? バグはないか? 盗作か?

2.3 プログラムの動作速度はどうやって決まるか

  • 2.3.1 偉大なる不公平 ~メモリ参照の局所性~
  • 2.3.2 メモリの階層構造
  • 2.3.3 プログラム側でも,メモリ階層を意識しよう
  • 2.3.4 計算量:教科書的な話
  • 2.3.5 計算量:より現実的な話

2.4 イマドキのハードウェア

  • 2.4.1 CPUのお仕事,またはうどん屋のパイプライン
  • 2.4.2 条件分岐すると遅くなる理由
  • 2.4.3 1人でダメなら手分けせよ
  • 2.4.4 アムダールの呪い
  • 第2章のまとめ
  • Column バスとは何か?

第3章 説明としてのプログラミング

3.1 OSという層 ~複雑さから逃げる手段~

  • 3.1.1 人数が増えて開発スピードが落ちるわけ
  • 3.1.2 人間の脳の限界
  • 3.1.3 コンテクストをやりくりする
  • 3.1.4 台本のスイッチング

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.3 情報は,使うところに置いておけ

  • 3.3.1 「時間」こそ最重要リソース
  • 3.3.2 過去の自分も未来の自分も,他人である
  • 3.3.3 処理はひとつ,書き方はいろいろ
  • 3.3.4 「今の自分」は,なぜその書き方を選んだのか?
  • 3.3.5 コメントにはコードで説明できないことを
  • 3.3.6 情報は散らかさない ~変更可能性への対処~
  • 3.3.7 変数名はわかりやすく,長く
  • 3.3.8 計算式を,自分の頭で計算するべからず

3.4 脳との食い違いを埋める

  • 3.4.1 printfと「シートベルト」
  • 3.4.2 assertの活用は,未来への説明

3.5 C言語のいろいろ

  • 3.5.1 C言語 = 構造化アセンブラ
  • 3.5.2 ポインタ:C言語の遭難の名所
  • 3.5.3 ポインタと配列はどう違う?
  • Column 配列とポインタの文法の混乱(C言語)
  • 3.5.4 Javaは中道を行く
  • 第3章のまとめ
  • Column C++はなぜ++Cでないか

第4章 自分への説明で仕事を効率化する

4.1 人間とコンピュータ

  • 4.1.1 機械的労働と頭脳労働
  • 4.1.2 コンピュータの性能向上の要素
  • 4.1.3 人間はコンピュータから何を学べるか?
  • 4.1.4 頭脳労働ではデコードが重い

4.2 時空間を越えて情報を共有する

  • 4.2.1 自分は現在にしかいない
  • 4.2.2 効率アップの基本は,コンテクストの共有
  • 4.2.3 情報を手元におくツールは何でもよい
  • 4.2.4 リアルタイムにログを取りながら進む
  • 4.2.5 後ろにさがらないことも重要
  • 4.2.6 説明性を高める例:ペアプログラミング
  • Column アイディアの出し方

4.3 何を残して何を切り捨てるか

  • 4.3.1 段取りソコソコ,仕分けもテキトーに
  • 4.3.2 コンテクストスイッチの重さを知る
  • 4.3.4 可能性に応じて労力をつぎ込む
  • 第4章のまとめ

第5章 他人に説明する技術

5.1 アナロジーで要点をつかむ

  • 5.1.1 よい説明と悪い説明
  • 5.1.2 人間が理解できるのは,易しいことだけ
  • 5.1.3 アナロジーの2段階:「類」と「推」

5.2 よい説明に近づくためのポイント

  • 5.2.1 失敗についての説明:失敗の理由は腐るほどある
  • 5.2.2 外来語の紛らわしさを知る
  • 5.2.3 「言葉」という道具は1次元配列
  • 第5章のまとめ
  • Column エンディアンの由来

第6章 プログラマとしての今後

6.1 壁がなくなる時代

  • 6.1.1 プログラマは昇進する必要があるか?
  • 6.1.2 中国やインドの安い人件費にどう対抗するか
  • Column 1日にできる作業量は,作業時間に関係ない

6.2 どう働き続けるか?

  • 6.2.1 目の前の仕事に何を見い出すか?
  • 6.2.2 プログラマとしての人生のゴール
  • Column プログラミングと作曲
  • 6.2.3 プログラマだけが「動く」コードを書いている

6.3 すべての労働はプログラミングに通ず

著者プロフィール

梅津信幸(うめづのぶゆき)

京都大学卒業(情報工学科),東京大学大学院博士課程修了(情報科学専攻)。博士(理学)。現在は茨城大学に勤務。著書に『マイクロソフト・シンドローム』(オーエス出版),『「伝わる!」説明術』(筑摩書房),『あなたはコンピュータを理解していますか?』,『あなたはネットワークを理解していますか?』,『仕事を加速する技術』(ソフトバンク・クリエイティブ),『なぜコンピュータの画像はリアルに見えるのか』(NTT出版)など。