マルチワークの勧め

Last Update : 2/15/97

 昔から、ソフトウェア・エンジニアには、マネージャーからの要請に対して一つの「殺し文句」をもっています。それは、

  「今、その作業を入れれば、メインの仕事が1週間遅れますョ」

という言葉です。

 マネージャーが、メンバーのソウトウェア・エンジニアに対して、別案件の見積もりや、ちょっとした報告書などの作業を持ち込もうとすると、上の言葉が返ってきます。もちろん、朝言って、夕方までにというのは論外ですが、1週間ぐらいの余裕をもってしても、上の言葉が返ってきます。この言葉はマネージャーを一瞬硬直さてしまいます。

 こうして、ソフトウェア・エンジニアは昔から「シングル・ワーク」を認めさせて来ました。それが“あたりまえ”の状態となっているといってもいいでしょう。

 勿論、複数の「骨のある」仕事を同時にこなすことは難しいことですし、必ずしもそれが正当化されるとは限りません。しかしながら、判断や決定に必要な作業は、必ずしも2ヵ月前に予測できる訳ではありませんし、状況の展開によって何時でも発生してきます。したがって、ある立場のエンジニアにとっては、そのような作業は随時「並行」させる必要があります。

 別の項でも触れましたが、高性能なパソコンとネットワークの発達によって、情報の伝達という役割が組織から消え、それに伴って組織は簡素化され、組織の主な役割は“決定すること”になってきました。

 当然、ソフトウェア・エンジニアといえども、ある程度の立場であれば、そのような決定に関わる仕事が割り込んできます。
 ・市場情報の収集・分析、及びそれに関わるレポートの作成
 ・技術動向や社会動向の情報収集と分析、及びレポートの作成
   さらに、それに基づいてメンバーや組織への働きかけ
 ・メンバーからの状況報告(進捗報告を含む)の分析及び指示
 ・電子メールを介して多方面から集まってくる情報の分析・整理
 ・インスペクションやウォークスルーの資料検討
 ・未決・保留事項の進捗促進の為の手配、及び働きかけ
 ・プロセス改善のための現状分析と着手のためのプランニング
 ・プロセスに関する知識やノウハウの習得
 ・メンバーのスキルアッププログラム
 ・外部の人との接触や決定に関わる一連の会議
などなど。

 これらを効率良くこなせるかが、これからのマネージャー、特にプレイング・マネージャー(技術リーダーを含む)にとって、重要な要素となってくるでしょう。勿論、必要に応じて補助要員を付けることは認められるかもしれませんが、あくまでも「補助」の要員であって、彼に指示を出すのは当人でなければなりません。

 情報技術(IT)の発達を背景に、これまでのような細切れの役割分担は、組織の簡素化という面だけでなく、意思決定の効率の面からも通用しなくなって来ます。

 勿論、この分野は技術分野であることには変わりなく、そのため、「スペシャリスト」も今以上に高度な専門職として残っていく思われますが、総合的な意思決定に関わる人の場合は、より広範囲な役割が求められるでしょう。そうでなければ、迅速な意思決定に支障を来します。

 この時、入社以来、身体に染み着いた「シングル・ワーク」のスタイルが邪魔をする可能性があります。ちなみに、上に挙げた項目を「直列」に並べたらどうなりますか?

 「今、インスペクションの資料を読んでいる最中だから、夕方まで電子メールを開けない」ということが通用するでしょうか。10年前なら、まだ通用したかも知れませんが、今日ではとても通用しません。それは、今日、そしてこの先に求められているのは「判断のスピード」だからです。情報技術はそのバックグラウンドを提供した。にも関わらず、以前と同じ作業のやり方では通用しないことは言うまでもありません。

 それでも、“組織の中”では通用するように見えることがありますが、それは「赤信号、みんなで渡れば怖くない」という状況であって、通用しているように見えるだけです。市場は、そのような組織の内情を斟酌して待ってくれるわけではありません。

 詩人のウォルター・スコットと言う人の言葉に、次のようなのがあります。

  時間を十分に使いこなせないと、次第に悪い性癖に悩まされることになります。
  ・・・気晴らしの時間は仕事の後に回すこと。・・・最初の仕事にすぐ取り掛
  かり、着実にてきぱきと処理していかないと、他の仕事がたまりはじめ、やが
  ては山積した課題に押しつぶされ、事態を収拾できなくなってしまうでしょう。


 仕事をシングルにすればするほど、後に皺寄せがいってしまいます。判断を遅られば暫定的な処置が講じられることになり、その殆どはリワークとなって、数倍の時間を吸い取られてしまいます。しかもその時は「最優先」の待遇を要求してくるため、その時点で予定していた作業は、すべて後ろにずらすしかありません。当然、スケジュールが逼迫することになり、表面的に取り繕うために必要な(はずの)作業の何割かは飛ばされてしまうのですが、これが再び優先度の高いリワークとなって戻ってくるのです。

 その結果、この人の作業は全て優先度の高い作業になってしまいます。既にそれらをスケジューリングする余地はなく、依頼元の力関係で優先順位がつくといった有り様になるでしょう。一体、彼にどのようなスキルが身に付くと言うのでしょうか。

 その間にも、時代の支援を受けた市場は、開発のスピードの短縮と、コストの圧縮と、品質の向上を求めてきます。「マルチ・ワーク」は、小さなことのように思われるかも知れませんが、基礎体力のようなもので、これが身についていないと、いざというときに走れないのです。

  「今、その作業を入れれば、メインの仕事が1週間遅れますョ」

というエンジニアの要求を安易に受け入れることは、そのエンジニアにとっても決してプラスにならないのです。もちろん「マルチ・ワーク」にも“限度”はありますが、ある程度はエンジニアに「工夫」を要求すべきです。それがエンジニアの身を守ることでもあるのですから。

 ただし、そこには「誠意」が求められるでしょう。それは、この「マルチ・ワーク」は命令や指示で出来るものではないからです。マネージャーのこの「要請」が、エンジニアの人生を思う心からでたものなのか、あるいはマネージャーの保身からでたものかは、実に際どいからです。少しでも邪心が混じれば、人は動かないからです。たとえ動いたとしても、それは権力に対する阿りからであって、その結果は粗悪なものが残されるはずです。

  「事をなすに誠意に非ざれば、則ち凡百成らず」(佐藤一斎)


この一斎のいう「誠意」が分からなければ、この問題は行き詰まるかもしれません。


「Index of Manager の為の講座」に戻る