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

まだまだ続きます。

audiobook.hatenablog.com

『第6章 プログラミングプロジェクト』

『変化を通じての安定性』

大きな組織が持っている様々な特性のうちでも、もっとも深く心をそそるものの一つは、それがどのメンバーの所属期間よりも長いこと存続しうる、ということである。

言われてみればその通り。ソフトウェア開発の世界で、最初のプロジェクトメンバーが全員退職した結果、見事にブラックボックスと化したとか、OEM元が倒産してバグに対処不能というのは良くある話。

ある意味でプログラムチームやプログラミングプロジェクトは川に似ている。 そこに流れる水は絶えず入れ替わっているが、川はいつも同じ川だ、というわけだ。

川というのは非常にいい例えですね。これは会社にしても同じ。

大幅な昇級を与えてみたら、それからあまり経たないうちに、（または場合によってはその場で）プログラマがプロジェクトから抜けてしまったので驚いた、という管理者は極めて多いものである。

給料が高いほど退屈な仕事であるように感じるのは私だけではないと思いたい。

（承前）彼らがあれほど驚くとは驚きだ。 というのは、プログラマたちのこの挙動には、少なくとも二つの合理的な心理的理由があるからである。 ときにプログラマたちは昇給を、責任を積み増しされた、というように解釈する。 そして万人が責任を積み増しされて嬉しがる、とは限らない。 プログラマは、より多くの金をもらうからには、もっとたくさん働けということだろう、と考える。

何というか、よくぞ言ってくれたという感じの文章。安月給は嫌だけれど、責任を押し付けらるのも（ある意味でトカゲの尻尾切りのようで）嫌なんですよね。特に自分のキャパシティーを超えているようなときには。

よく、「責任のある仕事を任せてもらえない」と嘆いたり、大学に入り直したりする人がいますけど、私は上記のように「 まだ俺に仕事をしろって言ってんのかよ」って心境でしたね。

特に私の所属していたSIerは、担当者≒責任者でしたね。「言えば仕事を任せる」と言えばきこえはいいですが、実際のところは、責任の押し付けといった感じでしたね。当たり前ですが、仕事に興味など持てませんでした。

もっとよくある解釈は、本当に望んでいる何かをくれない代償として金をくれると言うのだろう、というものである。

日本では臨時昇給はあまりないですよね。ベテラン開発者を割り当ててくれとか、機材不足を解消して欲しいと言ったときに限って、経験ゼロの派遣社員だったりします。 なだめすかして人を仕事に縛り付ける、という管理職は多しですし。 ましてや仕事の引き継ぎ云々で非常に辞めづらいというのがあります。

人々は自分の能力から見て役不足だ、と感じる仕事に飽きてしまうものである。

これはありますよね。特に自分の特技を活かせていないとか、これまでのキャリアを無視されたりすると。

プロジェクトは、一人の「キーマン」がいなくなったとたんに崩れ落ちる、トランプで組み立てた空中楼閣のようなものではない。少なくともそうあるべきではない。

異論の余地なし。そのためのドキュメント。できればペアプログラミングとか、チームで仕事をする。

もしあるプログラマがかけがえのない人物だというなら、彼をできるだけ早く追い出せ

本書では珍しくこの文章だけは太字になっている。 要するに早めにジョブローテーションしろってことか。

以前の職場の事例ですが、ある製品開発プロジェクトにおいて、その製品を担当すること12年（!!）という猛者がいらっしゃいましたね。もちろんお局様でしたし、影のリーダーと化していました。

顧客からの要望もそのお局様が「製品コンセプトは云々」と言えば一発でお蔵入りでした。 何かあればみんなが（頼りたくないのは本音だけど）お局様を頼るという構図。生き字引ですから仕方がないのですが、朝からお局様の機嫌が悪いときは近寄りがたくて辛かったですね。 GUIの刷新プロジェクトなのに、「（この製品は）コマンドラインで使う製品なんだけど？なんでGUIなんか使ってんの？」とプロジェクトの目的をほぼ骨抜き…。ジョブローテーションの失敗例です。

『作業成績の測定』

プログラム開発の進捗状況を評価するというのはきわめて主観的な仕事であり、ある一つのプログラムについてどれほどの進展があったかという一点だけを見ても様々な意見が出てくる可能性がある。

この発想は無かった。いつも見積もり行数に対して何行で〜とか、見積もりページ数とか、バグ目標（笑）とか、 何月何日までに何たら工程完了とか、そういうある意味でアホな進捗の把握方法に脳が麻痺していた。

それとこの話、いわゆるアジャイル開発とか、継続的インテグレーションの場合、ますます進捗の把握ができないような。

進捗報告と心理学となると、いろいろと心当たりがる。 たいていの人は、多少問題があっても「問題ありません」といいたくなるのが人情だし、かなりの問題があったときでも、さも問題がないかのように作文して、「問題が起き得るケースは稀ですから、問題ありません」って報告になりがち。

問題があると報告する場合は、スケジュールに響く場合でかつ、対処のしようがある場合。対処不能であり、かつ隠蔽可能であればたいていの場合は、隠蔽が行われてもおかしくない。それが人情というか、優等生の心理学。

『プロジェクトの構造』

プログラミングプロジェクトにおいて、進捗状況の評価に内在する心理学的落とし穴を回避したいと思うなら、作業することとその評価とを、何らかの形で分離することが必要である。

どちらかというと、これは日本人の大好きな「見える化」ですね。日本の生産現場の生産性が高いのは、部品在庫や仕掛かり品、最終的な出荷製品の数量という否が応でも見える化されているところにあると思っています。

たとえばドキュメンテーションチームは、しばしばプログラミング開発チームの連中から見下される。

まさにそのとおり。テスト担当もしかり。

ほかのグループとの関係においてむずかしい立場に立ちがちなグループとしてもう一つ、テストグループがある。

よくご存知で。テスト担当者を見下すような風潮の会社の製品には、人々の軋轢が乗り移っているんではないかと思うことがある。

『大規模プロジェクトに共通する社会問題』

管理者が自分には理解できない仕事の責任を持たされると、きっと彼は仕事そのものではなく、見かけ上仕事らしいものを基準として労働者の成績を評価するようになる。

ああなるほど。理解できないから作文の優劣で判断するわけか。

だが夜遅く働いているプログラマは報いられるとは限らない。 彼らが深夜に働いているところを管理者が目撃することは、まずないからである。 ほかの人に話しかけているのを見られたプログラマは、働いていないじゃないか、と思われる。

まあ、パソコンに向かって何かをしているだけでは、仕事をしているのかネットサーフィンしているのか区別はできないのは当たり前。

だが管理者に、ほかに何ができようか。プログラミング作業の成果物は何ヶ月も先にならなければ手に入らない。 誰のプログラムは動き、誰のプログラムは動かないか分かるまで待っている、というわけにはいかない（たとえ彼が動くプログラムと動かないプログラムを見分ける力を持っていたとしても）。 恐らく管理者にできることは、第一層の管理者信頼して、仕事を実際に観察してくれ、プログラムを読むというところまでやってくれ、と頼むことであろう。

深淵な文章。最後の一行が素晴らしい。でも実際、せいぜい係長というか、給料に影響を与えるようなポジションの人は、こういうことは決してやってくれない。プログラムを読むところまでいかなくても、プログラムを実際に動かすだけでいいのに。

『第6章 「プログラミングプロジェクト」へのコメント』

プロジェクトは次々にはじまったり終わったりしているが、共通の社会的問題は変わることなく存在している。 いまや私は、それらの問題の多くが、自尊心の欠如を源泉としているということ気づいた それを癒すには、自尊心を高める環境が必要だ。自尊心を破壊するような環境入らない。

なんとなく「うつ病」の問題と構図が似ていますね。自尊心がキーワードか。

私個人についていえば、細部に開いた最大の穴はプロジェクト管理の情緒的次元であった。

抜書きだと意味不明ですが、ソフトウェア開発プロジェクトを成功させるための最後のピースが「情緒的次元」だったという文章。これは別の本に書いてあるのでしょう。

一日開いてしまいましたが、まだまだ続きます。明日からは第3部。ではでは。

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