ベテランならホントに安心なのか？：開発現場の天国と地獄（3）（1/3 ページ）

[佐藤大輔（オープントーン），＠IT]

　第2回「真のボトルネックは“顧客”なのか？」では、真の成功プロジェクトとは何かという問題を考察しました。いままでの2事例はUPやWebアプリケーションの開発におけるMVCの活用など、比較的新しいプロセスの導入とチーム運営に関する事例を中心に話を進めてきました。今回は伝統的ともいえる体制の問題について考えてみたいと思います。

　本題に入る前に、前回の事例でモチベーションの高さについてのご質問が多かったのでお答えいたします。開発期間中、モチベーションの高さを支えたものは、以下の3つでした。

1. ムード
2. 自由さ
3. 信頼関係

　特に「信頼関係」については「昔なじみのチームだから？」という疑問を持たれた方が多くいらっしゃいました。しかし、断言します。このチームで仕事をしたのは、このプロジェクトが初めてでした。もちろん、メンバーの中にはお互いが以前から知り合いの者もいましたが、それはどのプロジェクトでも特に珍しいことではないでしょう。

　また、「自由さ」は「信頼関係」と相互補完の関係にあります。チームのメンバー1人1人が互いに信頼関係で結ばれていれば、信頼に基づく自由がチームのメンバーに（自然に）付与され、同時に責任感も芽生えさせるのです。

「管理」と「自由」

　私の場合、進ちょく管理には、プロジェクトシート片手に「今日は何行コードが進みましたか？」と実装作業者にインタビューして歩くものと、「この機能はいつまで。以上！」というにとどめる2つの方法があると考えています。これは私自身も実験中ですが、この手法は前者・後者ともそれぞれメリット・デメリットがあります。

　前者は技術者にとって、たまたま技術的問題が発生して進まなかった日は、あたかも「あなたの能力不足を説明しなさい」といわれているようでモチベーションを下げる効果を生じさせてしまうことがあります。また、説明のつじつま合わせのため、スケジュール表の日付を細工することに工数を浪費する典型的な負の効果も見られます。一方、後者の手法においても、技術者の能力に問題があった場合、発見が遅れやすいというデメリットがあります。

　ただ、実装経験のある方なら分かると思いますが、後者の方がモチベーションの維持に向いています。

　モチベーションを維持しやすい後者の手法を取ったとき、問題発見のリスクはどのように避けていけばいいのでしょうか。それは、個々の進ちょくを「陰になり日なたになって日々監視する」方法が有効なようです。「日なた」はよくある「一定期間ごとにインタビューとレビューを設ける」でよいでしょう。それ以上に陰の監視は確実にリスクを低減してくれます。現在多くのプロジェクトはCVSやVSSなどを利用し、実装の成果物を集中管理できるようになっています。つまり、CVSやVSSを監視することにより、作業者の進ちょくと品質をひそかに監視できるのです。この方法は「確実に進ちょくや問題点が分かる」ことになります。また、管理者が勝手に進ちょく管理をしているので「作業者はつじつま合わせに無駄な時間を使わなくてよい」ことにもなります。

　これらの手法を使うことにより「実装よりスケジュール表の修正に意識しなければならないような事態を避ける」「実装を行う際に技術的問題を腰を据えて検討できる」「実装者が主体的に手法を探る余裕を与える」といったことが可能になります。このことにより「自由さ」を与えることが可能になったプロジェクトのモチベーションは、ほかの実装チームより上がることでしょう。

　つまり、この自由さがおそらくほかのプロジェクトよりもいく分かモチベーションの高さを生み出すことになった要因だと思っています。

　さて、前回の疑問に答え終わったところで本題のプロジェクト事例です。今回のプロジェクトはいわゆる「丸投げの論理」で、「プロセスが」「技術が」というより、従来のシステム開発プロジェクトが持つ典型的な問題の事例になります。

　この案件は、受託案件を、実装経験のない責任者がスキルシートを頼りにチームを形成し、人月に見合う人員数を集めただけで、いかなる管理も行わなかった例です。この業界によくある「丸投げの論理」と現場の実例です。

［プロジェクト概要］
名称	プロジェクト3 「丸投げの論理」
案件	需要予測システム
言語など	VisualBasic
プロジェクトの規模	4カ月以内、5名
結果	カットオーバー成功（納品延期3カ月OVER）、赤字400万
予算	600万
経費	1000万
顧客満足度	△

［問題点］
作業者の管理	×
開発プロセス（UP）	×
開発能力	×（建て直し後は○）
分析設計	×
チーム全体のコミュニケーション	×（建て直し後は○）
コメント	納期になって、納品不能であることが発覚。2人だけで事実上作り直す。能力に問題のあるSEが多人数いるより、効率の良いSEが2倍作業する方がリスクの少ない事例の典型
［凡例］ ◎＝良（問題なし） ○＝やや良（ほぼ問題なし） △＝やや難（やや問題あり） ×＝難（問題あり）

　以下、この開発プロジェクトを時系列で検証していきます。