『プログラミングの心理学』をコツコツと読み進める試み その5
またまた続き。
『第5章 プログラミンチーム』についての読書メモ
つまり概念的には、あるシステムを作り出すの必要とされる最小限の専門能力と、最小限の期間というものが存在しているわけだ。 これらの量を明確に定義することが不可能であるために、そしてまたプログラムに関する見積もりには必ず不確定性がつきまとうために、マネージャーたちが、どう判断してみても指定通りの仕事を指定期間内に仕上げることは決してできないようなチームを作り上げてしまうことは少なくない。 したがって期限が来て現実に直面せざるを得なく立ったときは、おのずと期間延長が認められることになる。
非常によくある話。なんだけど、1970年代の時点でここまではっきりしていた問題が、いまなお繰り広げられていることが問題ではないか。
それなりの実績と経験を積んだであろう上位のマネージャーでさえ、現場の実情をさっぱり理解してないという職場は経験済み。
要するにいわゆる三現主義（現場・現実・現物）ができていない。私の経験したプロジェクトでは、まず担当者の実力を把握していない、開発対象（機能追加・UI改善）の規模を把握しようともしていない。そこに不慣れなプログラミング言語とフレームワーク。
もちろんデスマーチになったのだが、そしてそこに追い打ちをかけるように上層部の派閥争いという最高のオマケがついていた。
最短の期間はその製品に最良のチームを割り当てなければ達成できない。 最小限度の能力を持つチームえ間に合わせようと思えば、プロジェクトにもっと長い期間が掛かることを我慢しなければならない。 言い換えればどんなプログラムでも、才能の乏しいプログラマに作らせることができないわけではないが、そのためには期間が延びることを容認することと、チームの能力を最小限以下に下げないことが条件となるのだ。
これもIT企業の上層部に理解してほしい。というか、ここだけでいいから暗唱させてやりたい。
期間が短かすぎれば必ず近道を通りたいという誘惑が生ずる。 近道を通れば、そして何もかもうまくいけば、システムを期限までに動かすことに成功する可能性もあるが、何もかもうまくいくことなど滅多にない。
近道を通ろうという試みを何度も繰り返した挙句、トータル一年の納期遅延をやらかした事例を知っています。
絵に描いた餅のように上記のように、「何もかもが裏目に出る」というシビアな毎日でした。
おおざっぱにいって、三人のプログラマがチームを組んだとすれば、同じ能力を持ったプログラマが一人でやれることの二倍しかできない。調整上の問題に時間を食われるためだ。
この数字の正確さはともかく、ソフトウェア開発において、開発速度が人数に比例するとは限らないという点は同意。 一人で数人分の仕事をこなすようなスーバーマンが一人で残り数人を養っているというのが実態ではにか。
多くの人々は、もし新米の訓練生として現場に放り込まれたとしたら、そのプログラミング経験から学べるはずのことを有効に学び取ることはできない。
IT関係のOJT（On the Job Training）は得てしてうまく機能していないような気がしていたが、十数年前の書籍に同じようなことを書かれているのは驚きである。
プログラミング上の仕事には、仕事場のカーペットと同様、地位というものがからんでいるから、チームを編成するときは、仕事の配分がメンバーたちにどう受け取られるか、きわめて慎重に考慮する必要がある。
これは重要。特にテスト作業（動作確認、動作検証）や設備管理を下等な仕事と見なすような職場においては、ジョブアサインほど雄弁に、しかも強烈な上層部の意思表示はない。社内の人事異動の度に、あれこれと下卑た噂が飛び交うのは珍しくないと思われる。
しかも上層部の意図は得てして、誤解と不信感を招く。十分に言葉で説明することなしに、頭ごなしに仕事を割り当てることに問題があると思う。単なる労働力扱いという印象を醸していないか、一度考えてみる価値はある。
『目標の設定需要』
社会心理学者たちは、メンバーの一人以上がグループの目標を自分のものとして共有していない場合、グループの達成度が落ちるということを、プログラミング以外の領域について確認している。
さもありなん。
というのはほかの連中もおのずと、グループの中に分派があり、メンバーの一部が冷淡な態度を取っている、ということを感じ取ってしまうからである。
これはよく解る。「俺には理解」。上層部の派閥争いの噂、不可解な昇進。管理職の心ない一言。 場がしらけたり、ジョブアサインに不満があると、いとも簡単にこういう状況は起こる。
精密さと明快さは同じではない。
シンプルながら名言かも。
明快であるためには、（そして目標の受容における最も重要な要素は目標の明確さなのだが）仕事の概要をそれがどういう意味を持つか、という視点から示す必要がある。 プログラマ単に何をするかではなく、なぜそうするのかを知りたいと思うものだ。
プログラマに限らず、仕事に前向きに取り組めるかどうかのヒントが詰まっているように思う。大手SIerで働いていた頃、この工程ではこの作業をしてこのアウトプットを作成しろ、というのがよくあったが、ほとんど形骸化していた。当然興味もわかず、やる気は起きなかった。 それでも「仕事だから仕方ないよな」と自分なりに「仕事の意義」をこじつけて作業をしていた*1。
管理職（要するに指揮官）の資質の一つは、「仕事の意義」すなわち大義名分を語れるかどうかだと思う。
目標の不明確さという問題は、プログラミングチームがある特定のシステムを作るためにではなく、ほかのプログラミンググループにサービス又は支援機能を提供するため胃働いている場合、特に深刻なものとなる。
一つのミドルウェア製品の開発中に、ユーザーインターフェイス（UI）を担当するチームと、バックエンド（の下位モジュール）を提供するチームで、プロジェクトの達成目標が全く共有されていなかった事例を知っている。
UIチームはユーザーインターフェイスの刷新が目標であったにもかかわらず、バックエンド担当チームはスケジュールを守ることを最優先して幾つかの機能提供を渋った結果、結果はUIチームが泣きを見たのみならず、結果として納期の大幅な遅れという代償を払う結果でしたが。
この辺は管理職の思想に根本的な問題があったという見解ですが、それはまた別の機会に書くか。 あるいは、管理職の働きぶりを適切に評価できていないことの方が深刻な問題か。
『チームにおけるリーダーシップとチームリーダー』
プログラマたちは、創造的な仕事と専門的な能力を高く評価する傾向を持つ人々だから、自分の仕事をうまくやっていると彼らが認識する人々を信用する、という傾向がある。
これを理解してくれる経営者はなかなかいないだろうなあ。プログラマ出身のマネージャでも、これを理解してくれるような人は大手では出世できないんじゃないか。
だが人は人は対等であるかもしれないが、同等ではない。
人間の能力差は、悲しいけど否定できない…。「悲しいけどこれ現実なのよね」…みたいな*2。
だが任命によるりーだーにとって、チームのメンバーに対してうそをついたり、彼らを操ろうとしたりすることへの誘惑は極めて大きい。
まあそうかも。何かと理由をつけて情報のコントロールをする管理職は実際にいた。
リーダーシップのパラドックスの一つは、こうだ。「クビを覚悟のリーダーだけが、成功への真のチャンスを握っている。」
いやはやごもっとも。
『危機におけるチーム』
状況におけるチームのあり方との比較。女性の存在の影響。民主的か、権威主義（任命による）。
『まとめ』
多くのプログラミング状況において、基本的作業主体はチームであって個人ではない。
まあそうかな。
『まとめ』・『設問』
チーム編成についていろいろ。実務を外れているとピンと来ない。
『第5章 「プログラミングチーム」へのコメント』
この「めったにない」というのは日和見的発言である。「何もかもうまくいく」ことなど決してないのだ。
まあ言われてみればそうでしょうかね。
今日、よりふつうなのは、プログラミングプロジェクトにおける二番目に悪いやり方、すなわち「あちこちから契約社員（実は化けの皮をかぶった訓練生かもしれない）の大群を雇ってきて圧力をかけ、監督なしで（または過剰な監督付きで）働かせる」というやり方である。
日本の金融系の現場のことですようか。
概ね三分の一まで到達。 このペースで続きます。今日はここまで。
