2010-01-20

もしも、アル中ハイマーなプロマネがいたら...

もしものコーナー...
もしも、アル中ハイマーなプロマネがいたら...だめだこりゃ!

人生は短い!アル中ハイマーと出会ったがために無駄な時間を過ごしたメンバーも多いことだろう。この記事を運の悪いメンバーに謝罪を込めて捧げたい。

1. プロジェクトマネジメントは肩が凝る
マネジメントとは、肩の凝る仕事である。クビを賭けねば勤まるものではない。とはいっても、滅多にクビになるわけでもないが、それだけの覚悟がなければ思い切った判断は下せない。ましてや優秀な人材を簡単に手放すはずもない。ちなみに、おいらの場合は簡単であったが。昔、捺印済みの辞表を机の奥に忍ばせ、あとは日付を書き込めば提出できる状態にしていた。だが、こうした行為は愚かである。人間は衝動の誘惑に駆られるのだから。
技術屋さんをマネジメントするのは、比較的楽である。だいたい論理的な説明をすれば納得してくれるから。技術屋さんには、気難しい奴や、人付き合いの嫌いな奴が比較的多いかもしれない。それでも、あまり感情論に振り回されない分、付き合いやすい。おいらはこんな奴らが好きである。そう言うおいらが、人見知りが強く気難しい人間である、と言っても誰も信じてくれない。
一方で、経営的立場にある人は、論理的な説明があまり通用しない。政治的な思考でなければ納得しない。だから、彼らが現場をマネジメントしても上手くいくはずがない。それぞれの社会的立場で思考の違いが生じるのも自然であろう。マネジメントとは、極めて社会学的な領域にある。
マネージャが権力者になっては、技術チームの発想力を失う。マネージャのカリスマ性に頼ったチームもあるが、極端な個人崇拝が永続的であるはずがない。そうした組織には、キーマンがいなくなった途端に崩壊する脆さがある。
マネージャは、しばしば様々な人間関係で衝突する。不思議なことは、最初に苦労した人間関係ほど後々うまくいくことが多いことだ。最初から本音をぶつけるからであろうか?また、人間的にどんなに努力しても合わないという直観は最初に働く。こうした現象を経験から学ぶが、その理由を論理的には説明できない。
プロジェクトには失敗がつきものである。もし「失敗したことがない!」と発言するマネージャがいたら、それは失敗するような仕事を任されていないか、失敗したことすら気づいていないかのどちらかであろう。失敗の規準は個人によっても違うものである。
プロジェクトの成功は、偶然性やその人の生まれ持った何かによっても微妙に左右される。あらゆる成功例は、実に多くの成功要因によって構成され、すべての要因を解明することは難しい。ここに成功例から学ぶことの難しさがある。一方、失敗例は、多くの要因の中の一つでも満たさなければ失敗するので、その要因も顕になりやすい。したがって、失敗例の方が学びやすいであろう。成功者の判断力は天性のセンスがあって、真似してもうまくいくものではない。結局、判断力は自ら磨くしかあるまい。したがって、マネジメントに基本原則のようなものがあるにせよ、形式化した黄金手法などないと考えている。

2. プロ意識の持続
組織戦略には長期的な視野が求められる。その中で最も重要な要素は人材であろう。目先の成果のみを追求して邁進しても、完了した途端に人材が逃げだすのでは大失敗である。技術者にとって大切な精神はプロ意識の持続である。技術者たちは、革新的な精神を望み、自らの成長を願う。よく、マーケティング戦略で生産物の品質を妥協せざるをえないことがある。だが、技術者に仕事の質を劣化させるように要求することは危険だ。かつて、アル中ハイマーは「プロジェクトの必殺仕事人」と言われたことがある。いくつかのプロジェクトを抹殺してきたのは事実であるが、実に不本意なネーミングである。くだらないプロジェクトを無理やり創出して無駄な予算を計上するぐらいなら、早く潰した方がいい。メンバーの意欲が湧かない仕事は、恐ろしくチームの体質を劣化させる。失敗しても、やってみる値打ちのある仕事を見出したいものである。ちなみに、20年以上前、先輩に言われた言葉が鮮明に記憶されている。
「初めての技術だから失敗したなんてのは、プロの言葉じゃないね!」
これにはエンジニア魂の伝統のようなものを感じた。当時、説教されたというよりは、聞き惚れたものである。
チームの意欲を持続させるためには、哲学的な共通意識が必要である。メンバーに同じ目的と共通意識があれば、重要な問題が発生した場面でも少々無理がきく。技術チームのマネジメントは、マーケティング戦略や技術能力の管理と考えがちである。悩みが技術的なものであれば、まだ健全である。チームの問題は、技術的な問題以上に手ごわい。マネージャが人間面よりも技術面に注意を払うのは、それが重要だからではなく解決しやすいからであろう。プロ意識の持続とは難しいもので、マネジメントの仕事のほとんどが、この問題と対峙する。
メンバーはあらゆるストレスの中にある。意気消沈したり、愚痴っぽくなったりと微妙な変化を見せる。マネージャの仕事は、技術的な助言も必要であるが、メンバーの精神状態に応じて対処することの方がはるかに重要である。プロジェクトは生き物のようにうごめく。したがって、流れ作業的な手法が通用するはずがない。優れたマネージャは、自然にコミュニティを形成できるようだ。その振る舞いは仕事として意識されるわけでもない。マネジメント能力とは、人間を知ることかもしれない。マネジメントは仲良しグループを形成することが目的ではない。チームワークとは、ぬるま湯の関係ではない。現実に、うまくいっているチームでも人付き合いの嫌いなボスがいる。とっつきにくく、わがままなくせに、誰よりも人材を育成しているオヤジがいる。好かれるというのと尊敬を集めるというのでは、意味が違うということだろうか。こういうマネージャは、部下に一流の仕事を要求すると同時に、自らも一流の仕事を課す。仕事に対して、感情論に動かされることなく、論理的思考で合理的に評価しようとする。一見ドライに見えるが、余計な雑念に振り回されない信念のようなものがある。技術チームにおいて、その人の好き嫌いに気を遣わなければならない状況は、最悪の人間関係と言えよう。くだらないストレスから解放されないと、純粋に課題に立ち向かうこともできないのだから。哲学的な共通意識で動機づけ、かつ目標設定が高ければ、くだらない政治的な思惑も自然と消える。知識労働者の動機付けは、ボランティアの動機付けに似ている。満足のいくコミュニティを形成して成功したチームには、人を惹き付ける何かがある。プロジェクトの完成で得られる達成感は金銭的なものより得難い。むしろ芸術の完成に見る喜びと似ている。

3. チーム殺しと技術チームの形成
プロジェクトの失敗は見事に呪縛に嵌る。チーム殺しの多くは、仕事を蔑むかメンバーを蔑むことによって効果的にダメージを与える。ヤル気を出させるための規定は、見事にヤル気を削ぐ。ワークシートといった愚行は、管理部門による嫌がらせでしかない。技術業界に人材派遣業が蔓延するのは、まさしく技術者を部品扱いしている証であろう。
中には、顧客の要求をそのまま技術者に伝える伝言板役に徹するマネージャがいる。そして、双方の機嫌をうかがいながら、決定事項だから仕方が無いと政治的に丸め込む。こうした行為は、人の良さを見せながら無神経なだけに余計に罪が重い。プロジェクトを成功させたければ、重要なのは部下を管理することではなく、上層部と喧嘩する覚悟を持つことだ。
一方で、あらゆる管理手法を駆使して、やたらと凝った手法を用いるマネージャがいる。そもそも、管理なんて必要なのか?哲学的な共通意識が根付けば、特に部下を管理する必要もあるまい。しばしば、マネージャが悪役になることで、周りがうまく回転することがある。辛い立場の時にどのように行動するか、メンバーたちは敏感に読み取っている。人が良く、保身的な人間ほど厄介なものはない。
プロジェクトはいつ危機に見舞われるか分からない。技術的課題、突然の仕様変更、厳しい日程など、要因を挙げると切りが無い。ストレスが増せば、人間関係もぎくしゃくする。問題発生は常に想定しておくべきである。そこで、チーム内には笑いのネタにできる人物が一人ほしい。馬鹿を演じられる人間は貴重で、実は賢いと認められた人間の成せる技である。また、チーム内にはいつも笑いを起こせる共通のネタを仕込んでおきたい。おいらは自分自身を笑いネタにするために、夜の武勇伝を大げさに公表する。ほとんど作り話であるが、メンバーたちは素朴なもので簡単に信じてしまう。
経営者は従業員よりもマーケティング戦略を優先する。これも理解できる。ただ、中間管理職が経営者と同じ立場に立てばパワーバランスは崩れる。そもそも、技術者が組織に所属する必要があるのだろうか?日本型の組織が、税金から何もかも雑用の面倒をみてくれるのはありがたい。確定申告まで免除される。だが、サラリーマン馬鹿に飼い馴らされる。そこで、大工さんのような一人親方のような制度は技術者向きだと思う。個人で企業と契約し、棟上げなど忙しい時に集まって、後は一人でコツコツと家を建てる。必要な人材を揃えられるのは、ひとえに信頼関係と言っていい。対して、固定された部署単位に仕事を作る方が、人材確保という意味では安定するのも確かである。そして、少々の人員不足は派遣を利用すればいいと安易に考える。だが、技術レベルの確保という意味で健全なのか?
社内の就職活動によってチームを形成するというのもいいかもしれない。組織内に一緒に仕事をしたいマネージャがいれば、個人的に売り込むのもいいだろう。逆に、マネージャからメンバーに誘うのもありだ。ここで注意したいのは、人間には好き嫌いがあることである。悪い方に傾けばイジメに発展する。いずれにせよ、会社の看板に寄り掛かった技術者と交流したいとは思わない。技術畑では、組織を超えた文化交流は必須であろう。

4. 愚痴れる環境
チームの状態を見るには、メンバーに本音を言わせることが手っ取り早い。それには愚痴らせるのが良いだろう。それも冗談で言える段階から。愚痴れるということは、反発するパワーが残されている証でもある。体制の維持が目的ならば、イイ子ちゃんほど都合の良いものはない。だが、革新が目的ならば、むしろ弊害となる。もし、組織が完璧だと満足しているならば、宗教化が進み思考停止状態に陥っていると見る方が正しかろう。完璧な体制などありえないのだから。沈黙の抗議が始まれば手遅れである。そうならないように、笑いながら愚痴れる環境を作ることに専念する。アル中ハイマーのプロジェクト手法は、これに尽きる。
技術的な問題は比較的対応しやすい。もし、メンバーが技術問題を抱えていれば、人前で喋らせればいい。技術者には、内気で喋るのが苦手と言う人も多い。だが、責任の範囲を明確にすれば、いい加減にはできないはず。メンバーは、自分で喋っているうちに思考を整理しながら、いつのまにか自ら解決策を見出す。周りはそれを聞いてやるだけでいい。悩み事を相談していたはずが、いつのまにか解決方法を自ら自信満々に語っている。こうした光景がしばしば見られるからおもしろい。ここには、一種のプレゼン効果がある。ただ、マネージャの存在感が薄いのがちょっと寂しい。プロマネは少し存在感が薄く、ちょっと馬鹿ぐらいがちょうどいいのかもしれない。みんなが愉快になれば、そのまま場所を変えて宴会となる。これに付き合わされるのが辛い。どっちが付き合わされてるかって?したがって、プロマネは概してアル中ハイマー病患者になるであろう。

5. 現場の精神
マネジメントの仕事でも、必ず自ら設計するモジュールを持つことにしている。それがどんなに小さくても。それも、設計者の気持ちを忘れないためと言い訳しているが、実は設計が楽しい。ただ、マネージャがモジュールを担当するのは、ちょっと辛いものがある。ちなみに、おいらの仕事は、デジタル回路設計やその実装のためのアルゴリズム設計といったところだろうか。いわゆるハード屋か?回路設計と言っても言語で設計するし、検証環境ではプログラム設計もやる。アルゴリズム設計ではプログラミングは必須。となれば、ソフト屋か?なんとも微妙だ。はたしてその実体は...雑用係である。したがって、アル中ハイマーは、ソフトなピロートークを武器にハードボイルドをモットーに生きるのであった。
検証作業は大嫌いだが、検証環境を作るのは案外おもしろい。よって、立場を利用して環境構築を担当したりする。回路設計を言語で行うといっても、その記述方法は実装の制限に見舞われる。その点、検証モジュールは機能のモデリングや環境の自動化など、その手段において制限に見舞われることはあまりない。顧客によっては使う言語を指定してくる場合もあるが、手抜きをする方向でなければ、だいたい交渉で誤魔化せる。
昔、ある経営者に、マネージャはコーディングしてはならないと言われたことがある。おいらはこの意見に否定的だ。マネージャであっても、設計の醍醐味を忘れたくはない。
ドナルド E. クヌース曰く、「システムを担当する設計者は、実装にも全面的に関わらなければならない。」

6. 無駄から学ぶもの
目先の作業に惑わされて、突っ走らないと気が済まない人がいる。全体の方針が決まらないのに、勝手に設計を始めたり、コーディングを始めたりといった行動をとる。自分の作業が遅れることで責任を負うのが嫌だ!と明るみに主張する人もいる。誰も責任を押し付けようなどと思っていないのだが、そのような政治的な体験をしてきた技術者は多い。部分的に進んでも、足並みが揃わないと、後戻りすることになると説明しても無駄である。あえて、そうした人の行動を止めたりはしない。それでステレスから解放されるならば、それもいいだろう。こういう人は作業をしていないと落ち着かない。コードを書くことがある種の精神安定剤になっている。無闇にコンピュータに向かっている時間が長い人の仕事量が多いとは限らないのだが。人間を言葉だけで啓蒙するのは無理である。おいらは、他人を啓蒙したり説得するのが嫌いだ。新たな思考方法を書籍に求めるにしても、どこかに興味や共感できる思考の欠片を持っているから、その本を選ぶことができる。むしろ言葉だけで簡単に操れる人間の方が怪しい。目先の作業に惑わされる人には、事前検討や上流工程を綿密にやれば、日程の精度が高まり、結果的に仕事が加速することを体験させてやることだ。それまで我慢するしかない。何事も結果が付いてこないと説得力はない。よく検討された仕様が日程の精度を高めることを知っていれば、上流工程の大切さを無視して目先の作業に囚われることはなくなるだろう。
また、仕事のパターンをなんでも形式化してしまうマネージャがいる。形式化できるに越したことはないのだが。コーディングルールなどを細かく規定すれば、それなりに品質は維持できるし、技術レベルの個人格差を吸収することもできる。だが、厳密な規定は意欲の妨げになることもあれば、ワンパターンの仕事スタイルは思考の硬直化にもなる。人間であるからには、作業よりも思考することに価値を見出したい。
優秀な人ほど事前検討を大切にし、無駄を排除しようと努力しているように見える。彼らは、一番大きな無駄は後戻りすることだと知っている。それだけ、無駄な努力を経験してきたとも言えるわけだが。世の中は無駄に満ち満ちている。無駄から学べば、無駄は無駄ではなくなる。

7. 政治力と評価
人の評価は難しい。どんな人間でも、必ず好き嫌いの感情が介入する。客観的な評価を求めるために、数字で段階評価する光景をよく見かける。これがまったく意味がないとは言わないが、どれほどの効果があるのか?カリスマ性2、技術力3、発想力4、協調性1、まるで戦略シミュレーションゲームだ。評価項目に当てはまらない事象や表現できない事象も多い。評価される側も、売上の数字などで部署や人の評価を求める人がいる。しかし、経営の立場から考えると奇妙な話である。誰が担当してもそれなりに成果の出る仕事と、失敗する可能性は高いが将来を見込んで挑戦したい仕事とでは、どちらに優秀な人材を投入するだろうか?困難な仕事ほど優秀な人材を配置するのが合理性というものである。おいらの評価基準は単純だ。その人が組織にとって居なくなったらどれだけ困るかである。ただ、居なくなって初めて、その人の価値が認識できるから困ったものである。恋愛は別れた時に、その人の良さが見えるものである。
プロセスの遵守の度合いを評価の重点に置いている組織がある。そこには、定められたプロセスに従ってさえいれば、この世は全てうまくいくという宗教じみた理屈がある。失敗した時の責任逃れに絶好の言い訳にもなる。ISOを取得して喜んでいる組織のお偉いさんは、それでうまくいくと狂信する。だが、規定されたプロセスが、禍をもたらすケースは意外と多い。
応急処置が泥沼の原因になることは、多くの技術者が初期の段階で経験しているだろう。応急処置は悪魔のように誘惑してくる。だが、長期的に考えれば自ら地雷を埋め込むようなものだ。常に物事の本質を解明しようとすることが、プロ意識というものであろう。計画段階では、安易に流用モジュールを使えばスケジュールが短縮できるといった意見が必ず飛び出す。だが、流用できるかどうかの検討は慎重でなければ危険である。そこには、政治的な思惑が絡むことが多い。既にモジュール設計者が辞めていて、問題が発覚しても原因すら追求できないといった事態も珍しくない。そんな事は新人君でも分かりそうなものだが、なぜか?部長クラスのお偉いさんは政治力で捻じ伏せやがる。彼らには、開発の結果よりも、もっと重要なことがあるに違いない。

8. 割込みと雑音
頭脳労働者にとって、割り込みを発生させないことは重要である。技術者が理想とする精神状態とは、フロー状態といったところだろうか。完璧に集中すると、時空を超えた一種の心地よさを感じる。無我の境地とでも言おうか。一旦集中してしまえば音など気にならないが、集中する手前ではリセットされる。電話のベルが鳴ろうものならイライラしてなかなか集中できない。電話のない時代、研究者は手紙で情報をやりとりしていた。頭脳労働者にとって技術革新は劣悪な環境をもたらすのだろうか?メール受信のポップアップですら鬱陶しいが、自動受信を止めればいい。メールとはおもしろいもので、即返信すると、なぜか?即返事がくる。まるでチャットだ。ビジネスマンはせっかちなのだろう。そこで、わざと時間を置いて返信することにしている。鬱陶しいのはメッセンジャーであるが、ほとんど切っているので、気分転換ツールと言った方がいい。
それにしても、やたらと電話をかけてくるマネージャがいる。ほとんどメールを活用しないのだ。こういう輩は技術者を部品ぐらいにしか思っていないのだろう。発言したことが証拠に残るのを嫌うのか?いや、嫌がらせに違いない。ちなみに、酔っ払いにとって割り込みの最優先は携帯メールだ。ホットな女性からのメッセージを優先せずして、人生で何を優先するというのか!
複数のプロジェクトを掛け持ちしていた頃は、一日に200通以上のメール処理に追われた。逆に言うと、何一つ仕事をこなしていない。メンバーも「緊急!」とか「重要!」といったサブジェクトで気を引こうとする。しかし、中身は酒の誘いだったりで笑わせてくれる。気を遣っているのか?邪魔しているのか?よくわからん連中だ。
プロジェクトの掛け持ちは避けるべきだろう。それだけで人生を無駄に過ごした気になる。高度な情報化社会が生産性を高めたことは認めよう。だが、創造性や思考力を高めたかは疑問である。利便性は人間の思考力を奪ってはいないか?
ところで、音楽を聴きながら作業すると効率が下がるというのは本当だろうか?「ピ-プルウェア」には、プログラムのような論理思考は左脳が働き、音楽のような直感的なものは右脳が働くので影響がないという実験結果を紹介していた。だが、技術者は突然のヒラメキによって直観的に問題を解決することがある。右脳が音楽に占有されるとヒラメキの余地が無くなるので、やはり音楽は邪魔になりそうだ。とはいっても、音楽は精神を安定させる効果がある。そこで、精神をリラックスさせることが優先か、思考することが優先かは、状況に応じて使い分ければいい。独立した空間を一人で占有できるならば、音楽は特権である。だが、チームで職場を共有するならば、無音環境が良いに決まっている。

9. 会議
会議で召集されるのはいいが、事前に何をするのかはっきりしない会議は実に多い。1時間の会議をしようとすると、主催者は下準備に半日ぐらいはかかるものである。会議中は、担当者の作業を止めることにもなるので、だらだらとした会議は作業者のストレスを招く。だから効率良くやろうと気をつかう。ほとんどの場合、事前準備の要領が悪い人の説明は異常に難しい。何をするのかシミュレーションできていないのだろう。しばしば、会議がお偉いさんの勉強会になることもある。事前資料にも目を通さないので、用語の意味すら通じない。会議とは議論するところなのに。前提を出席者に浸透させておくのも主催者の務めであろう。
また、会議でマネージャが目立つのは、議論の活性化を妨げることにもなる。互いに対等でなければ、まともな議論はできないので、権力者は遠慮するぐらいでちょうどいい。司会者が目立つ討論会が、ろくなものになるはずがない。ましてや、発言中に司会者が割り込んで黙らせては、深夜の討論会「朝まで生ビール」となってしまう。

0 コメント:

コメントを投稿