このエントリーをはてなブックマークに追加LINEで送る

2.5. 根性、根性、ド根性

ハッピィ・エンジニアリング表紙


ゆとりは一種の投資である。ゆとりを無駄と考えず投資と考えることが、ビジネスを理解している組織と、単に忙しいだけの組織との違いである。
『ゆとりの法則』トム・デマルコ著, 伊豆原弓訳, 日経BP社, ISBN4-8222-8111-6

 

 たいていの国では週休1〜2日の休みがあり、1日の労働時間は7〜8時間である。

 

 国によっては、ランチタイムをたっぷり取って、少々の昼寝ができるほどの優雅な昼休みの場合もあるが、それでも、1日の労働時間は7〜8時間である。人間が一番効率よく仕事をするために、十分な睡眠時間を確保してなお、少々の自由な時間が過ごせるように、1日の労働時間は7〜8時間ということになっているのだ。

 

 しかし、システム開発の場合、それはあくまでも建前にすぎない。システム開発プロジェクトでは、むやみに奨励されていると言っても過言ではないくらい、残業するのが当然という考え方が根づいている。能率が上がらないまま、仕事そのものは雑になっていく。
 雑な仕事からまともなシステムが生まれるわけはないのだが、それでも残業によってすべてをやりきろうとする無意味な根性論を捨て去ることができない。月間の残業時間こそが勲章である。「残業してがんばったけれど……」という、できなかったときの言い訳の余地を残すために行われているのが残業の実態といえなくもない。

 

残業が続く原因

 

プロジェクトが残業の連続になるのは、いくつかのパターンがあるように思われる。このような状態のプロジェクトは、だいたい以下のパターンのどれかに該当するだろう。

 

  • プロジェクトが計画されていない
  • プロジェクトの計画に妥当性がない
  • 的確なプロジェクトマネジメントが行われていない

 

● プロジェクトが計画されていない

 丸投げ文化で書いたとおり、要件定義以前に金額が決まり、かなりいいかげんな要求のまま、いいかげんな規模見積もりとスケジュールを立ててしまうことが、プロジェクトが崩壊する第一歩である。見積もり金額と同様に、システム規模とスケジュールにも根拠がない。ただし、これを「無理」とか「実現性がない」というのは禁句である。そもそも、元請けが実現可能性を検討した場合、ごくごくざっくりと「採算が取れそうだ」とか「二次、三次開発で取り返せる」と考えたときには、そのプロジェクトは常に実現可能なものとなってしまうのだ。しかし、この先どれだけ綿密なプロジェクト計画を立てるかが、実際のプロジェクトが完結するか、破綻するかの別れ目となる。本当に実現性のある計画なしに進んでいくのは、太平洋戦争の日本軍の姿勢そのままである。「勝ちに不思議の勝ちあれど、負けに不思議の負けなし」という野村克也の言葉を肝に銘じておきたいものだ。

 

● プロジェクトの計画に妥当性がない

 プロジェクト計画の妥当性を考えるうえで、一番の問題となるのはプロジェクト体制のミスである。システム開発には適切で必要十分な要員と時間が必要である。ところが、スケジュールに根本的な問題がある場合、これが適切に処理できない。プロジェクトメンバが不足した状態でカミカゼアタックをするか、あるいはプロジェクトメンバを過剰に増員して、その結果コントロールを失い、期待していたほどの生産性が生まれない。特に、統一性が重要視される設計作業などは、標準化が不十分な状態で多人数が行うことになれば、間違いなく品質は低下する。メンバが少なすぎると、スケジュールどおりに作業を進めるために、問題の先送りや手抜きにつながっていく。マネージャやリーダまでもが「プレイングマネージャ」などという幻想的な言葉で作業に入り込んでしまい、リーダシップを発揮することができなくなる。マネジメントする人間が作業を兼務することにより、課題への対処、関連部門との調整などが立ち遅れていき、全体の作業に大きく影響を及ぼす。

 

● 的確なプロジェクトマネジメントが行われていない

 納期要求に対するありがちな、そして間違った対策が打たれるのはプロジェクトの常である。管理職やプロジェクトマネージャは、念仏を唱えるごとく、ただひたすらに生産性の向上を訴え始める。しかし、その具体的な策は間違いなく生産性を低下させるものでしかない。

 

 たいていの場合は、技術者の手が空かないことだけに注力する。しかし、チームで作業をする場合、すべてのメンバの手が空かないように作業を割り当てるのは現実的に困難である。要員のスキルもまちまちで、プロジェクトにおいて発生する作業を誰でも肩代わりできるわけではない。仮にすべてのメンバの手が空かない状態を作ってしまった場合、リスクが顕在化した場合など予想外の対応をするメンバが不在となってしまうだろう。

 

 無理に手が空かない状態を作ったとしたら、技術者は自分が担当する作業が早く終わったとしても、自分に次の仕事が回ってくるのを待つことすらできなくなる。ほかのメンバの作業終了を待っていることが、仕事をサボっているように見えてしまうからである。結局、効率的に仕事が進められるときであっても、「待ち時間」があるように見せないためにダラダラと作業することになってしまうのだ。

 

 進捗状況がスケジュールと一致していることに注力しすぎた管理を行った場合には、結果として中途半端な状態で次の工程に進もうとする。要件定義をおろそかにし、設計をおろそかにし、すぐにでもコーディングを始め、テスト計画をせず、デバッグをひたすら繰り返す結果を招く。作っては直し、作っては直し、プログラムに呪いを込める仕事である。

 

 ブルックスが「銀の弾などない」と言ったのは、もう30年以上前の話である。それは今でも真実とされている。しかし、現代において今なお「効率を何倍に上げよ」と言うマネージャは多い。「私は素人以下です」と言っているに等しいということを、彼らは理解しているのだろうか?

 

運命からの脱却

 

ゴールの明確化

 根性論のプロジェクトマネジメントが、組織に向上をもたらすことはない。残業が続き、プロジェクトメンバが疲れていく過程で、生産性はどんどん落ち込んでいく。これを避けるには、プロジェクトゴールを明確にし、スコープや作業範囲の変化に対応しながら進めていくための方法論を持たなければならない。

 

 まずは、プロジェクト計画をしっかりと立てることである。プロジェクトの目的・目標は何か、前提条件や制約条件は何か、新たに調査が必要な項目は何か、どこにリスクがあるのか、などプロジェクト開始時に与えられた情報を分析し、「既成事実」「想定」「不明点」などに分類することが第一歩である。

 

 さらに、作業タスクを洗い出し、必要となるリソースをまとめる、それに合わせてスケジュール・工数・予算を見積もるべきである。スケジュールありきで計画を進めるとどこかに無理が出てくるが、必要なタスクからスケジュールを組み立てることで、前提となるスケジュールのどこに問題があるかがわかる。ここで初めて、どの作業をどのように簡略化・軽減化していくかの判断と計画をすべきである。

 

生産性の向上

 生産性を向上させるうえで重要なことは2つ考えられる。ひとつは、生産性の上がる環境を用意すること、もうひとつは、生産性が上がるようなマネジメントを行うことである。

 

 環境には、作業ロケーション、オフィス、開発環境の整備、企業(あるいはプロジェクトマネージャや管理職の)文化などの要素が含まれる。プロジェクトチームが同じロケーションで仕事をしていること。作業するにふさわしいオフィス環境であること。安定かつ高速な開発環境が維持されることなどが必要である。プロジェクトチームのロケーションがバラバラではコミュニケーションを十分に取ることができない。コミュニケーション手段が電子メールによる文字のコミュニケーションのみとなってしまうことが多い。

 

 パイプ椅子と平机が置かれたホコリっぽいスペース、夏だというのに気温が0度に近い北極のようなマシンルーム、活気がありすぎて常に電話が鳴り響くオフィス、キーボードを打つのにひじが隣の人に当たってしまうような狭いスペースなどで作業したら、生産性が低下しないわけがない。

 

 作業環境について言及されている文献はごく限られている。最近ではXP開発において、作業環境について提唱されている。しかし、実際の開発プロジェクトでは作業環境の善悪と生産性について語られることはほとんどないと言える。

 

 しかも、オフィス環境の問題以前に開発環境の整備がなされていない場合が多い。生産性の計測がきちんと行われていないという前提では、生産性とコストを比較し、生産性向上のために投資するのは難しいが、劣悪な環境下での作業が生産性を低下させることは計測するまでもない。

 

 また、生産性を上げるマネジメントには、いくつかのポイントがある。第一には、計画を重要視することだ。プロジェクトには常に変動要因とリスク要因があるが、変動要因が大きいのは見積もりを軽視してよい理由にはならない。作業工数やスケジュールに十分な検討を重ねる必要があるのは言うまでもない。まずは安定運用するために、きちんとしたプロジェクト計画を策定することがスタートである。

 

 次に行わなければならないことは、効率化ではなく時間的なロスの減少である。

 

 プロジェクトにおいて多くの時間を必要とするものは、「考える作業」と「やり直し」である。考えなければならないとは、多角的かつ十分に検討され、その結果を順守して作業を行うスタイルを取らなければならないということである。要件定義や基本設計が不十分なために詳細設計やプログラミング工程で本来設計者ではないプログラマが、事実上要件の再定義や基本設計のやり直しを行いながらプログラミングを進めるケースが多々発生している。プログラマは基本設計に従い詳細設計から単体テストまでの工程をスムーズに進めるべきだし、それが可能なようにプロジェクトをコントロールするのがプロジェクトマネージャの仕事である。

 

 上述した例は、要件定義や基本設計を詳細設計やプログラミングの工程でやり直していることにほかならない。仕様変更は避けられないが、要件や基本設計はその工程でバグが発生していないことを十分に確認した上で次の工程に進まなければならない。品質は作り込まれていくものである。作り込まれたものを修正するのは、正確なものを作るよりも多くのコストを必要とする。仕様の不良は、後の工程になればなるほどコストが莫大に膨れ上がっていく。工程の初期の不良を出荷後に修正した場合、工程の初期で修正するよりも100倍のコストがかかると言われている。それぞれの工程ごとに不良を出さないように作ることこそが、結果として納期の短縮と品質の向上につながることは言うまでもない。プロジェクトマネージャが見た目の進捗率のみに気を取られ、「一刻も早くプログラミングを開始せよ」という指示を行った瞬間から、納期と品質に対する要求を満足させることはできないと認識すべきである。

 

 そして、プロジェクトメンバをプロジェクトの途中で離職させないことが重要だ。プロジェクトを失敗させないためには、各メンバがゴールを共有できていることが重要である。そして、システム化の意義、開発規約や仕様など多くの情報などメンバの教育には沢山のコストがかかる。プロジェクトに最初から参加しているメンバと、三ヶ月後に参加したメンバのスキルがほぼ一致しているとしたら、プロジェクトに最初から参加しているメンバの方が明らかに戦力として優れている。知識と経験が生産性を向上させるのである。

 

主力メンバの活用

数人から十人程度のチームを率いると、技術者の力の差は、チーム内で明確に出てくることが分かるだろう。このような場合には、部下の中のエース格の者を中心に、如何にして仕事を完結させるかを考えるべきである。

 

 戦力にならないメンバには、本来はお引き取り頂きたいところだが、契約の問題や、主力メンバをアサインするためのバータとして送り込まれていることもあり、そのまま置いておかざるを得ない。

 

 戦力にならないメンバを戦力に変えるには、プロジェクト期間は短すぎる。さらに、短いプロジェクト期間の中で、戦力に変わるかどうかが分からないものに過剰なコストをかける意義は低い。そして、仕事を完結するスキルが無い人間に責任のある仕事をまかせたとき、仕事の大幅な手戻りが生まれ、技術力のあるメンバがケツを拭くことになる。結局、力の無い人間がマイナス工数を生むのだ。腕の無い人間は下手に邪魔するぐらいなら遊んでいてもらった方がマシなのだ。

 

 しかし、他から見て遊んでいるように思われると、さらに上層や同格のマネージャからは「戦力に余裕がある」と判断されてしまうことがある。このような場合は、プロジェクトのエース級を引き抜かれる口実とされかねない。そのため、アリバイ工作として、「うちのプロジェクトは忙しいから、使える奴を引き抜くな」というアピールのために、どうでもいいレベルの技術者には、重要ではない仕事を割り当て、遊ばせないようにしておく必要がある。それは、プロジェクトリーダやチームリーダにとって、決して本質的な仕事ではない。チームリーダの本質的な仕事は、あくまでも中心選手のスケジュール把握にある。

 

コラム:やらないほうがマシ

 世の中には、やらない方がマシな仕事が沢山ある。誰もが勝者とならない敗者のゲームである。

 

 ある開発会社は、詳細設計からシステムテストまでの工程を受託した。しかし、その仕事の前提には大きな危険があった。基本設計を担当した会社と元請けの関係が悪化し、基本設計の途中でプロジェクトが崩壊したのである。

 

 開発する機能はおよそ150。納期までの期間はあと一ヶ月半、営業日で考えて30日である。開発を受託したソフトハウスは8人を投入した。基本設計がないので、元請けのSEと根拠なく仕様を固めてやらざるを得なかった。一気呵成になんとかプログラムを開発することができ、納品にはこぎつけたものの、当然安定した運用などほど遠い状態であった。

 

 ユーザ企業は、検収条件を明確にし、検収を行うべきではなかった。元請けは瑕疵責任を問われ、ソフトハウスはプログラム改修に一年半以上を要したということである。12人月で開発した仕事に、それ以上のコストをつぎ込んだのである。

 

 ユーザ企業はシステムを利用することができず、元請けの信用は地に墜ち、下請けの開発会社は大赤字。一旦プロジェクトをストップして、きちんと仕切り直ししておけば、これほどの期間を必要とせず、莫大な赤字を生むこともなく、ユーザ企業の運用開始も早まったはずである。プロジェクト全体が玉砕した典型的な例であろう。

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

2.5. 根性、根性、ド根性 ハッピィ・エンジニアリング関連ページ

2.1. 丸投げ文化
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
2.2. 価格破壊+やらされ仕事=低い満足度
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
2.3. 中間搾取でボロもうけ
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
2.4. 人手余って人材足らず
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング