読物『ピープルウェア』 - でぃするだいありー？

　昔から、この世には二つの価値観がある、というのが歴史学者の間では定説になっている。その一つは、スペイン流の考え方である。これは、地球上には一定量の価値しかない、したがって、豊かになる道は、大地や民衆の苦役から、どうやってうまく冨を搾り取るかに長けることである。もう一報は、価値は発明の才能と技術で創造するものである、というイギリス流の考え方である。その結果、イギリスでは産業革命が起こり、スペイン人は植民地を求め、新大陸のインディオからの搾取に明けくれた。スペイン人は大量の金をヨーロッパへ持ち帰ったが、その代償として得たものは、ひどいインフレ（金貨がダブついているのに買えるものがない）であった。

　スペイン流の価値観は、管理者の間に今も脈々と生きている。これは管理者が生産性について能書きをたれるのを聞いているとすぐわかる。本来、生産性とは、一時間当たり、どれだけ多くのものを作れるか、ということであるべきなのに、現実には、一時間当たりの賃金から、どれだけ多くのものを搾り取るか、という意味にゆがめられていることが多い。この二つの生産性には大きな違いがある。アメリカのソフトウェア業界では、年俸あるいはプロジェクトベースで給料が支払われるため、通常は残業しても残業手当がつかないが、スペイン流の管理者は、タダ働きの残業を利用して、生産性を上げようと夢みたいなことを考えている。この連中にかかると、一週間で仕上げた成果を、実際に八〇時間、九〇時間働かせても、四〇時間で割り、一時間当たりの生産性とする。

P.39

　シャロンは、すぐれた管理者の本質をよく知り抜いていた。つまり、管理者の役割は、人を働かせることにあるのではなくて、人を働く気にさせることである。

P.71

　一九六〇年代にコーネル大学の研究者が「生産性と音楽について」というテーマで一連の実験を行った。コンピューターサイエンス学科の学部学生から希望者を募り、二つのグループに分けた。一つは音楽を聴きながら勉強をするのが好きな学生で、もう一つは静かでないと勉強が手につかないグループである。各グループの半数ずつを、それぞれ無音室とオーディオ装置付きの部屋に入れた。そして、両方の部屋の学生に仕様書を配り、Fortranのプログラム作成という課題を与えた。その結果は、予想されたとおり、プログラム完成に要した時間、および、正確さには大きな差はなかった。これは、例えば音楽を聴きながら数学の宿題をする場合、数学及び数学的思考を司る大脳の部位は音楽の影響を全く受け付けないためである。すなわち、音楽用の脳細胞は別の場所にあるのだ。

　この実験には、一般に知られていない事実が隠されていた。この実験でのプログラムの仕様は、入力データ中の数字にある操作を行い、出力データを出力するというものであった。例えば、入力データの各数字を二桁左にシフトし、それを一〇〇で割り、同様の処理を全部で一〇回程度繰り返す。もちろん、仕様書には書いていないが、入力データを左へ二桁シフトし、一〇〇で割って出力された結果は、もとの入力データと全く同じであり、入力データをそのまま出力データとして出力出来る。これに気付いた学生もいたし、全く気付かなかった学生もいた。注目すべきことは、気付いた人の大部分は無音室側の学生だったということだ。

　プログラマーのように専門分野の高度な知識が必要となる職種では、順序立った論理的思考を司る左脳が非常に重要である。通常の作業は大部分がここで処理され、音楽の影響はほとんど受けない。音楽のように感覚的、直観的なものは右脳で処理されるためである。しかし、プログラマーの作業すべてが左脳で処理されるのではない。例えば「あっ、そうだ！」という突然のヒラメキで問題が解決することもあるし、何ヵ月分、何年分もの作業時間が、独創的なヒラメキで節約出来ることもある。この思考は右脳の機能なのである。有線放送で「1001ストリングスオーケストラによる魅惑のムードミュージック」を流すと、右脳は音楽に占領され、とてもヒラメキが起こる余地はない。

P.136

　どうも最近は、開発技術者をどんどん官僚主義に駆り立てる、あまり芳しくない傾向がある。恐らく、これは自己防衛的管理という病がはやっている証拠であろう。しかし、この傾向はあまねく行き渡っているとはいえ、必ずしもすべてが一様ではない。我々がよく知っている会社にも、開発技術者が、カフカが『城』で描いたような官僚主義的な悪夢と同じようだ、といっているところや、ペーパーワークの負担はとるに足りない、といっているところもある。

P.221

日本語訳書は1989年2月に刊行されている。

我がプログラマ人生は1995年くらいから始まっていて、以来約20年、本書がテーマとするような「あるべき職場環境」にめぐりあったことはない。大企業ほど本書の真逆を行っているという印象もある。

本書の主張のひとつは、「プログラマは集中する必要があるので、電話を取らせたりとかいう雑事を並行させるのは生産性を低下させますよ」というようなことだ。確かにその通りだと思う。本文中にも「プログラムは夜作られる」というような記述があったが、これはまさにかつて実感していたことで、週に五日間泊りこんで作業したりしていたのは、実際そのような理由による。着替えのストックをもっと持ち運べたなら、一カ月でも泊まりこんだことだろう。当時は体力的にそういう余裕があった。

本書はまたチームの大切さを語ってもいる。これについては実体験が不足しているためか、ピンとくるものがなかったが、性善説に基づいた主張であり、全面的に肯定できない。残業代を稼ぐために月300時間残業を果たした方を知っているが、昼間は半覚醒状態が常であった。

また、スケジュール表に並行して線を引かれた経験が何度もある。それはつまり一定期間で他のメンバーよりも多くの仕事量を課されていることになるわけなのだが、もちろんこれを達成したからといって褒めてもらえるわけでもない。「俺と同じ名前のプロジェクトメンバーがいっぱいいるんですね」くらいのイヤミはいうが、この差別についてとくに苦情を述べたことはない。管理者が管理すべきスケジュールの問題を当方に押し付けているのだから、その対価として品質が犠牲になることを認めさせたくらいだ。

このような背景を知ってか知らずか、チームのメンバーから品質の悪さを皮肉られたことがある。皮肉った当人は、担当していたたった一つの共通関数の納期を延ばしに延ばし、当方に悪影響を及ぼしたことを覚えていないようだった。

本書のチームに関する主張は、チームメイトがある一定水準に達しているという前提が不可欠となる。

管理者については、官僚主義的という事例には覚えがある。

個人的経験では「いい人なんだけれどね」という管理者にあたることが多かったが、これは組織が管理者養成を行っていないという感触を得ていたので、思うところはあまりない。

前世紀、WebなどでMicrosoftのオフィス環境を初めて見たときには「ここまで必要だとは思わないが、こんなカンジの作業空間であったならさぞかし捗るだろうな」と感じたものだ。超大企業でありかつ、プログラミングという作業について理解のある経営者でないと、本書が理想とするようなオフィス環境は実現できまい。

現在の職場には開発担当者は我が身のみで、基本的に開発担当者は顧客と直接折衝をしない、電話を取らない、という指示が出されている。とはいえ、まったく取らずには済まされないし、インタラプトも入らないわけではない。

プログラマに対して理解があるというよりは、プログラマが電話を取ると儲けどころを失する場合があるからという理由のようであるが、理由がどうであれ、本書が主張するところを一つでも実践している職場にめぐりあったのは初めてのことかもしれない。