このブログの読者はこんな本を買っています。
プログラマ向けオリジナルグッズを販売しています → 　UPSOLD店 / ClubT店

質問の答えを書く

ビジネスによくあるシーン。

　1. ドキュメントを作る
　2. 誰かに見せる
　3. 質問される
　4. 質問に答える
　5. 納得してもらう

例えば、報告書の類とか、我々の仕事なら設計書のレビューなどもそうだ。また、ソースコードのレビューも同じである（以下、「ドキュメント」にはソースコードも含むものとする）。

さて、上記の流れの後でそのまま終わってしまう人も多いのだが、それはよくない。

単純に考えると、質問された内容というのは、「作成したドキュメントから読み取れなかったこと」である。しかも、少なくとも聞き手が質問せずにはおられない程度に「重要なこと」なのである。

そのため、今後、別の人（たとえば上司のそのまた上司）がこのドキュメントを読んだら、同じ質問をしてくる可能性が高い。質問の機会がなければ誤解されてしまうかもしれない。また、説明を受けた人ですら、後になってその内容が思い出せなくなって、違う解釈をしてしまうかもしれない。

「質問をする人に知識や読解力がないせいだ」と言いたい時もあるだろう。しかし、読ませる相手のレベルに合っていないドキュメントは悪いドキュメントである。幼児向けの絵本を漢字ばかりで書いているようなものだ。

★

ドキュメントの説明で質問があったなら、口頭で説明しておしまいにせず、説明した内容をドキュメントから読み取れるように、追記や修正をしておきたい。

ソースコードの場合なら、構造を見直す（リファクタリング）、変数名やクラス名・関数名を見直す、コメントを見直す、といった対応を検討すべきだろう。

特に、品質管理のために行うレビューの場合は、レビューアにドキュメントの内容を伝えることが目的ではなく、ドキュメントを良くすることが目的なのだから、なおさらである。

応援のクリックお願いします →

ついてきなぁ!『設計書ワザ』で勝負する技術者となれ!

posted with amazlet at 10.12.05

國井良昌
日刊工業新聞社
売り上げランキング: 83877

Amazon.co.jp で詳細を見る

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

posted with amazlet at 10.12.05

マーチンファウラー Martin Fowler 児玉公信平澤章友野晶夫梅沢真史
ピアソンエデュケーション
売り上げランキング: 5343

Amazon.co.jp で詳細を見る

むやみに頑張らないこと

誰かに仕事をお願いするときに、「頑張ります」という返事をされるのは好きではない。頑張らないとできないのかと思うと、不安だからだ。できれば、頑張らずに涼しい顔で遂行してくれる人を探したい。

頑張るための余力は何かトラブルがあったときなど、いざという時にとっておいて欲しいのである。もし、依頼した「100 の仕事」に対して、110、120 の結果を出すために頑張ってくれるというのなら嬉しいが、それなら黙って頑張って欲しい。

「頑張ります」という言葉を使うとしたら、「100 の仕事は無理ですが、なるべく 100 に近づけるように頑張ります」といった文脈になるだろう。「95 までの完了は約束しますが、98 を目標に頑張ります」など、具体的な達成内容まで明確にできれば理想的だ。

★

「あいつはいつも頑張っている」という言葉は、「100以上」を目指して頑張っているのなら褒め言葉である（「仲間の仕事まで手伝っている」とか「自己のスキルアップに取り組んでいる」とか）。しかし、常に 100 を目指していつも頑張っているのだとすると、その人は常にトラブルを抱えているか、スケジュールの立て方がおかしいのだろう。

いつも頑張っていると、「頑張っている状態」を基準にしてスケジュールを立てるようになってしまう。普通は１週間かかる仕事でも、３日でできると自分自身が勘違いしてしまっている。実際、残業などして頑張ってやるので、何事もなければ３日でできるのだろう。しかし、そのような「もともと頑張る前提」のスケジュールでは、それ以上頑張れる余地がないため、トラブルが起きるとどうにもならなくなる。

これは個人だけでなく、組織でも同じだ。スタッフがいつも残業したり休日出勤したりして「慢性的に頑張っている組織」は、無理な仕事をどんどん受けてしまう危険性がある。そのうちのいくつかはトラブルが原因で、納期が守れなかったり、品質を落としたりしてしまうだろう。

★

悪いことに、いつも頑張っている人が、頑張らなくなると、手を抜いているように思われやすい（普通の状態に戻っただけなのに）。それが嫌で、ずっと頑張り続けることになるという悪循環。

そんなことにならないためには、「とりあえず頑張ろう」と考えるのではなく、「頑張らずに仕事をするにはどうすればよいか」、「頑張らずにできる範囲はどこまでか」といったことを考える方がよい。

もちろん、トラブルが起こったときなど、本当に頑張るべき時に頑張るのは当然である。そのためにも、「頑張るための余力」を残したスケジュールを立てるようにしたいものである。

応援のクリックお願いします →

ストーリーで考える「見積り」の勘所 (開発の現場セレクション)

posted with amazlet at 10.04.12

中村秀剛
翔泳社
売り上げランキング: 363251

おすすめ度の平均:

内容がわかりやすい

非常に判り易い

経験談は説得力がある

ストーリー仕立てはわかりやすい

Amazon.co.jp で詳細を見る

がんばらないで成果を出す37の法則ーアライアンス人間関係術ー

posted with amazlet at 10.04.12

平野敦士カール
ビジネス社
売り上げランキング: 30918

おすすめ度の平均:

著者の考え方の柱がさらりと書かれている

見開き１0２ページだから、読みやすかったです

日々、職場やセミナーで教わっている大事な事が満載

大事なことがさくっとわかります

デキル社員になりたかったら……

Amazon.co.jp で詳細を見る

低レベルなプログラミング

「低レベルなプログラミング」と聞いて、どういうものをイメージするだろうか。プログラマとそうでない人では、答えが違ってくるのではないだろうか。

一般の人には、「誰でもできそうな簡単なプログラミング」、あるいは「質の悪いプログラミング」といった意味にとられるかもしれない。

しかし、プログラミングについての文脈で「低レベル」といわれる場合は、通常は「ハードウェアに近い」という意味である。つまり、「低レベルなプログラミング」とは、「ハードウェアが理解する言葉」に近い（たとえばアセンブラのような）言語を使ったプログラミングだとか、直接ハードウェアに命令を送って制御するようなプログラミングのことである。

このハードウェアとの「近さ」は測定できる類のものではないが、プログラマ（あるいはその周辺の業界人）は、なんとなく了解していると思う。このブログの「スキルアップのためにラップを剥がしてみる」というエントリで「層」と表現したものにも近いだろう。

★

もともと「レベル」という言葉は「何らかの基準」を意味しているだけである。それが何の基準であるか、ということは文脈によって変わるので、別段ここでの使われ方が特殊であるというわけではないだろう。

しかし、何の説明もなく「低レベル」という言葉を使うと、上記のような了解のない人には、「品質が低い」、「スキルが低い」といった侮蔑的な意味に誤解される可能性があるので、気をつけたい。

また、初心者プログラマの中には、そのような誤解をしてしまう人も多いかもしれない。あるいは「低レベル・プログラミング」と聞いて、「簡単そう」と思ってしまう人もいるかもしれない。しかし、低レベルなプログラミングほど難易度は高レベルだったりもするので、注意が必要である。

応援のクリックお願いします →

CPUの創りかた

posted with amazlet at 09.05.05

渡波郁
毎日コミュニケーションズ
売り上げランキング: 1745

おすすめ度の平均:

基本的な電子回路でCPUができる

趣味の本だよねぇ

読んでもすぐには理解できませんが、他のＣＰＵ本はもっと理解できません

ノイマン型コンピュータを自作する・・・名著かも

CPUの超基本構造

Amazon.co.jp で詳細を見る

真・コンピュータ用語辞典 (ホームページブックス)

posted with amazlet at 09.05.05

tell‐a‐lie
キルタイムコミュニケーション
売り上げランキング: 377785

Amazon.co.jp で詳細を見る

ダーティなデータ

「データがダーティである」という言い方は一般的だと思うが、私の周囲では伝わらないことも多い。

何らかのデータを変更するプログラムにおいて、保存されているデータを直接書き換えるのではなく、データをコピーしてからそのコピーを変更し、最終的に元のデータに書き戻す、という方法をとることがある。このとき、「コピーの方は変更されているが、元データには反映されていない」という状態を「ダーティである」という。

たとえば、ユーザーが画面でデータを編集するようなソフトでは、既存のデータを編集してそのまま終了しようとすると、「変更されています。保存しますか？」といったメッセージを表示するのが一般的だ。このような、データが「ダーティかどうか」という判定を「ダーティチェック」と呼んだりする。

また、データベースで「ダーティリード」という時の「ダーティ」も同じ意味だろう（「汚い」という英語の意味を考えるとこれが語源かも？）。

★

「ダーティ」という言葉を使わなくても、「データが変更されたかどうか」と言えば伝わるのだから、あえて使う必要もない、と思うかもしれない。

しかし、開発チームの中で、このような、「使わなくてもやっていけるが、使うと便利」というレベルの言葉がどれだけ共有されているか、ということは、円滑なプロジェクトの進行のための要素のひとつである。

また、言葉を共有することの効果は、コミュニケーション面の向上だけでなく、ものの考え方（システム開発であれば「設計思想」など）の共有にまで及ぶことも多く、侮れないものである。

応援のクリックお願いします →

■関連記事
・曖昧言葉

2009-'10年版 [最新] パソコン・IT用語事典

posted with amazlet at 09.03.22

堀本勝久大島邦夫
技術評論社
売り上げランキング: 35830

Amazon.co.jp で詳細を見る

IT英語のナゾ

posted with amazlet at 09.03.22

豊沢聡緒方孝文
カットシステム
売り上げランキング: 261531

おすすめ度の平均:

実務英語に即した本です。

多少勉強になる

もっと収録語数をしぼってくれたほうが、個人的にはよかった。

この著者は語学もコンピュータも詳しい

IT業界人に限らず中級以上の英語学習者にもお勧め!!

Amazon.co.jp で詳細を見る

サンプルコードで語る難しさ

プログラミング入門者のための教材として、「カレンダーを表示するプログラムを作れ」という課題がある。この課題に対して「カレンダーなんて OS に付属しているのに、なんでそんなもの作るんですか？」という人がいる。なんという的外れな意見だろう。言うまでもなく、勉強のために作るのであって、使いたいから作るわけではない。

これは極端な例だが、この手の齟齬はよく起こる。ブログのコメントなどを読んでいると、「本来の意図が伝わっていないな」と思うことは日常茶飯事である。

★

CodeZine の「コーディングスタイルの常識をぶち壊せ」という記事のコメントや「はてブ」のコメントを読んでいて、改めて感じた。

この記事の２つ目のサンプルソースについて、「こんな用途に switch は使うべきでない」とか、「配列を使ったほうがよい」などというのは野暮である。「常識」的に考えて、この記事の著者も他の読者もそんなことは分かっているだろう。

ここでは、「同種の記述を繰り返す時は、複数行にせず、桁位置を揃えて書くと見やすい」と言っているだけである（つまり「表」のようなコードにしろと）。サンプルソースでは、その「同種の記述」の単純な例として、たまたま「２つの文字列リテラルの変数への代入文」が書かれているというだけである。もちろん、代入文である必要はなく、数値演算でも関数呼び出しでも、何でもよかったはずだ。

しかし、この何でもいいはずの処理内容（ここでは代入文）に引きずられてしまう読者は意外と多い。プログラマがソースコードを読むということは、普通なら「処理内容を理解する」ということなので、そういう読み方が染みついてしまうのだろう。「ソースはこう読むものだ」という「常識」にとらわれて読み方を変えることができないとも言える。

そういう意味で、「処理内容以外のことを伝える」ためのサンプルソースを作ることは難しい。

★

このブログでも、「コードの書き方」を論ずるためにサンプルソースを載せることがあるが、文章を書く以上に頭を悩ませる。「書き方」を見せるだけだから「処理内容」は何でもよい、といっても、リアリティがなければ上記のように読者の気が逸れてしまう。実例（職場で見つけたコード）を載せればリアルではあるが、逆に複雑になりすぎて論点がぼやけたり、一部だけ抜き出しても意味不明になったりする。

実は、上記の CodeZine の記事と似た内容の記事も書いたことがある。「あなたにもできること」がそれだ。配列を使った簡単なサンプルソースを載せているだけだが、実はかなり悩んだ結果である。今読み返すと、あまりに説明が短いため、意図が伝わっていないような気もするので、ついでに補足しておこう。

コーディングの際、同じような処理を繰り返して書くときには、上に書いた行をコピーして下の行を作り、少しだけ改変していくような書き方をすることが多いと思う。が、そこで、改変し忘れるというミスをしたことはないだろうか？　この手のミスを防ぐには、どうすればよいだろうか？

最低限必要なことは、自分で書いたソースコードを読み返してチェックすることである。その時、「修正箇所」の桁位置が揃っていた方が、ガタガタと不揃いであるよりもずっとチェックしやすい。視線を縦に真っ直ぐ流せるからだ。

コードを印刷してチェックする場合は、指でなぞったり、ペンで印もつけやすい。画面でチェックする場合でも、カーソル（キャレット）を同じ桁位置で縦に動かして記述を追えるので確認しやすい。少なくとも私は、何度もそういう経験をしているので、自然とソースコードの桁を揃えるようになった。

★

このようなソース・チェック時のメリットは、CodeZine の記事で「ケアレスBUGの混入が防げるため、メンテナンス性が上が」ると書かれていることと同じだろう。CodeZine の記事では、「桁位置を揃える」というだけでなく、「複数行にまたがらせない」という点も例示されているという意味では、よい記事だと思う。

しかし、「メリット」の説明がこれだけでは不足だ。「そんなことは誰もが承知している」という前提で書かれているのだろう。つまり、プログラマの「常識」だと。しかし、ソースを読み返さないプログラマは、意外と多い（記述ミスは動作確認でも見つけられるので）。常識と思っていることも、本当は常識ではないのかもしれない。そういう意味でも、「常識をぶち壊す」ということは難しいものである。

応援のクリックお願いします →