『プログラミングの心理学』をコツコツと読み進める試み その7

性懲りも無く続きます。

audiobook.hatenablog.com

『第3部 個人の活動としてのプログラミング』

『第3部 「個人の活動としてのプログラミング」へのコメント』

25年間で著者の意図通りにはいかなかった？よくわからない。

『第7章 プログラミング作業の多様性』

『プログラミングにおけるアマとプロ』

アマチュアが書くプログラムでは、予定されている利用者はほぼ例外なく彼自身だけである。 それに対してプロは、他人が使うプログラムを書く。

お金をもらうかどうか、だけではない。と。いやむしろ他人が使うプログラムを書かないとお金にならないということか。

プロは、プログラムをきちんとパッケージ化し、冷淡な世間に向けて送り出さねばならない。

冷淡かどうかはともかく、出荷しないとお金にならないんですよね。出荷しないほうが良いプログラムもありますけどね。 何はともあれ、動くものを提供しないとね。

『プログラマがしようとしていること』

プログラムは、どんな人工物もそうであるように、はっきりした太陽期限と応用範囲を念頭において設計されるものだ。 または設計されるべきものだ、というべきか。

あれそうかな？建造物はともかく、ほとんど最低保証期間を考慮されていればいいほうではないかと思うけど。 というか、モノによるのでは？

どんなプログラムにも、払う注意、かける手間に関して適切なレベルというものある。それは、プログラムをどう使うつもりかに依存する。

おっしゃるとおり。ちょっと耳（この場合は眼か）が痛い…。 学校のテストでもそうですよね。時間配分というか、ペース配分？

（前略）だからこの実験の主要な効果は、仕事のいかんにかかわらず、プログラマ間の変動のかなりの部分は、何を達成すべきかについての認識の違いからきている、というところにある。

スケジュールを強調すればするほど（されるほど）、締め切りまでに質の良いものを作ろうということにはなりませんね。とにかく締め切りを守ろう、締め切りまでになんとかでっちあげよう、ということになりがち。 まあ日本の大手企業製品にありがちな、ハードはいいけどソフトがって話の根源でしょう。

これは完了判定条件が曖昧というか、ネジや釘のように杓子定規に判定できないのが問題。 ソフトウェアの品質というのは少なからず主観が入るために、限界があると思います。 ネジや釘は重さや長さといった数値、図面で定義できるし、客観的に判定できます。一方でソフトウェアは、文章という解釈の余地がある、つまり曖昧なものでしか定義できませんから。

たとえば、各活動ごとに完了期限が設定されているようなプロジェクトについて考えてみよう。 （中略） その日になるとすべての問題定義はプロジェクト管理者の手元に渡る。 だが、必ずしもそれはプロジェクトが定義された、ということを意味しない。 それが意味しているのは、問題定義がプロジェクト管理者の手元に届いた、ということだけである。

非常に意味深。要は問題定義（今風にいうと要件定義か）が見かけ上終わったことになっているだけっとことでしょう。 そもそも要件定義に終わりがあるのか、というか、やろうと思えば要件定義は延々と続けることが可能なんでは？

プレゼン資料の作成のように、いくらでも手間暇をかけることのできるタスクもありますし。 ソフトウェア開発に曖昧さが付きまとうように、「やること」リストもなかなかフィックスしませんから。 一種の妥協が必要なんではないかな。

仮にプログラミングプロジェクトを、明確に定義されたいくつかの段階に分割することが可能であったとしても、そのようにすることが得策であるとは限らない。

見事にウォーターフォールを否定ですか。してその根拠は、

もし一つの時期には一種類の作業しかしないのだとすれば、その時期には十分活用されない才能、というものが生じる。 一人のプログラマが孤立して胃働いている場合ですら、意識的に作業を分割して、どの時点でも異なる部分は異なる段階にある、というようにする方がまさっている可能性がある。なぜか。 作業の進捗がより平準化され、プログラマ自身の気分の、日毎の変動に影響されにくくなる見込みがあるからである。

掛け持ちタスクのススメか。言われてみると一理ある。ような気もする。

たとえば必ずしもすべての日がコーディングに適しているとは限らない、というのはよく聞く話である。

言いたいことは理解するけど、江戸時代の職人ならいざ知らず、サラリーマンは邪魔の入らない時間にコードを書くしかないんですよね。不幸なことに。

（前にも書いたような気がするけど）残業時間はコーディングに適しているとは思えません。少なくとも。

同時には一つのフェーズだけを「団体更新」式にやっていくという、という方式のもう一つの問題点は、とにかくある設備だけが過負荷、ほかの設備はがら空き、ということになりやすいことである。

正論。というか、ある時期にはテスト設備がフル稼働、またある時期は機材置き場で閑古鳥が鳴くってパターンはありがち。

だから、プロジェクトを理想的に組み立てようとすれば、そのすべての部分が同時にプログラミングの同一段階にあることは避けることが望ましい。

先行すべきコンポーネント（上記の"部分"）がこけると意図通りにはいかないんですけどね。

残りの節ではプログラマの能力差についてデバッグ作業を例に説明されていますが、引用しにくいので省略。 要約すると、各作業工程にさらに細かい作業が含まれており、各作業によってプログラマの生産性の差は30倍にもなりうる。 たとえば、バグを見つける能力、バグの原因を突き止める能力、バグを修正する能力は別。特に他人の書いたプログラムの場合には。ってところでしょうか。

『まとめ』

（前略）そしておそらくその結果として、われわれは「よいプログラマになるためには」と「よい友情を打ち建てるには」とは似ている、ということに気づくであろう。 その答えは、お互いに認めあることと、個性を大切にすることにある。

皮肉なのか何なのか。まあ笑ってしまったけど。

『第7章 「プログラミング作業の多様性」へのコメント』

わりと著者の自画自賛っぽい内容で締められている。曰く「使用の明確化が重要」と言いたいのだろう。 特に引用する箇所はなし。この章はいいことを書いてある箇所もあるけど、ちょっと論点がぼけているような印象。

次は第8章。

プログラミングの心理学―または、ハイテクノロジーの人間学 25周年記念版

ではまた。