2007/07/18

■ IT技術者は3Kではない・・・なぜデスマチが(ほぼ)根絶できたか
 IT系、特にソフトウェア開発が「3K職業」呼ばわりされて大分経ちます。
実際、当時まだ会社員だった私の身の回りでも、1999年から2003年位まで、ITプロジェクト=デスマチ位の勢いだった気がします。
 その後、自身で起業して最初も営業的に無理な案件もこなさなければならず、やはり当初2-3年はデスマチになるケースが多かった気がします。

 しかし、この2年ほど弊社は「忙しいのは無論忙しい」ですが「徹夜だ休出だ」といういわゆるデスマチ状態には殆どならなくなっています。
 現在4つのプロジェクトを回していますが、どのチームもそういった状況にはなっていません。
 「「やりがいのある忙しさ」を会社全体で共有できているのかなー。」と思ってみたりしています。

 そのことを取引先や応募者に説明すると「3K職場でなくなった理由」を聞かれます。
 しかし、いままでは「弊社はそういうものです。というか仕事とは(長くやりがいをもって続けるために)本来そうあるべきです。」としか説明してこなかったので改めて理由を考えてみました。

ちょっと社内を見渡して思った理由は・・・


?マネージャー
?プロジェクトの請け方
の2点です。

?ですが、単に「優秀」と言われても面白くないと思いますので具体的に上げましょう。
弊社が特徴的なのは「PM・リーダー全員が、技術力があること(実装ができること)」でしょうか。

 なぜ「? 技術力があること(実装ができること)」が必要かといえば、第一点、見積もりをはじめとするプランニング全般の精度や信頼性が高いということす。
 見積もりだけなら、統計的な指標(COCOMOやISBSG)やツールに頼る方法もあります。
 しかし、実際にプロジェクトを運営していく中で、スケジューリングの妥当性や機能追加の影響を実装能力があると即時にしかも正しく判断できます。
 すなわち、顧客の変更や追加の要求に対しても、精度の高いジャッジで予算内で対応できるか否かなどを判定できます。その結果、顧客の希望を可能な限りかなえるが、プロジェクトにも悪影響を与えない範囲の変更要求を的確に受け入れることができます。
 また、技術力があると、「雑用」の自分自身による即時解決(書面を作ってアサインをしているコストの方が高くなるような細かい雑用の解決)が可能となります。
 ちょっとサーバーの設定を変えたり、開発環境で購入する機器を選定したり。などさまざまな面での技術力(実装能力)があることという側面は非常に良い影響を及ぼします。 実際にPMをなさっている方は「雑用係」としてご自身のタスクが多いことにも気づいていると思います。
 また、顧客との打ち合わせ時にリスクポイントを見抜く「カン」も実装能力によって強化されます。
 顧客の突然の要望が一見簡単そうでも、実際にはどんなリスクが潜んでいるかをかぎ分けることになります。その逆に非常に少ないコストで、良い提案(解決策)を提供することもできます。

 プロマネの優秀さに交渉力、観察力、統率力などいろいろありますが、弊社の場合それ以上に「技術力」を要求しています。

 もう一点は、メンバーを引っ張るという意味でPMやリーダーには「職人の棟梁」的な部分があるからです。
 棟梁は、自身が、作業に長年携わり、職人の最終形の一つとしてなった状態です。
 別に職人として一番である必要はありません。技術力は少なくとも平均的な職人程度ないしそれよりすこし優秀であれば十分といえます。それに、経験や、交渉力、観察力、統率力などを加えてメンバーの敬意を勝ち得て、統率力を発揮します。あるいは、作業の適正やメンバーの能力の有無も精度の高い判定ができます。
 そこに近い部分がITプロジェクトのPMにもあります。
 「いい棟梁」のもとで、多くの技術者は自身の能力を安心していかんなく発揮できます。

?は言わずもがな、「作りだけを請けない」という姿勢です。
 さきほど「きちんと見積もれること」をポイントに挙げていましたが、そもそも見積もりや、スケジュールが顧客と調整できない状況では、「かじ取り」は難しいものになります。
 「作る」部分を請けるにしても、プロジェクト全体にかかわれる形で
請けるようにしないと、やはりリスクは高まってしまいます。

 若干余談ですが、かつてクラウゼビッツ(だったはず)が「軍隊の運用で一番していけないことは、別の利害関係者に指揮権を預けてしまうことだ」と言っていましたが、ITプロジェクトの運営でも同じです。自分でかじ取り出来ない船が、効率よく安全に目的地にたどり着くのは不可能です。
 たとえば、設計やプロジェクト運営をほかの会社に預けて、構築作業だけを行うような体制を作ってしまったとします。
 その状況で「上流工程の分担企業」にすれば、顧客満足度を上げるためには、なるべく作る側に無理をさせた方が良くなってしまいます。
 もちろんそれでは、信頼関係を損なうので、そんな横暴がまかり通るわけではありませんが、小さな、細かいところで、この「利益相反」下におけるプロジェクトの指揮権の喪失は危険な要素になります。

というかんじでしょうか。
まだまだ、このあたりは社員ともども追及中の命題です。
posted at 18:05:43 on 2007/07/18 by sato - Category: ITプロジェクト運営

■ コメント

コメントはありません。

■ コメントの追加

:

:
:




■ トラックバック

このエントリにトラックバックはありません

次のURLを使ってこの記事にトラックバックを送ることができます。

もしあなたのブログがトラックバック送信に対応していない場合にはこちらのフォームからトラックバックを送信することができます。.