エンタープライズ

現役コンサルタントが語る

システム開発の落とし穴

2006年6月13日　　文●システムクリエイト代表取締役
田中徹

第6回
SEを見極める（1/2）

今回のポイント

システム開発が成功するか、それとも失敗するかは開発会社のSEに左右されるところが大きい。ならば、SEを見極める目を養うことも、発注担当者の重要なスキルであろう。技術者として、そして開発のリーダーとして、SEを正確に判断したい。

開発会社を見極める必要性

　このコラムでは、発注側の体制の不備、会社としての姿勢などからシステム開発が失敗する事例を紹介してきた。それはひとえに「システムの失敗は開発会社だけの責任ではない」ということを言いたかったからに他ならない。つまり、発注側であるユーザー企業の問題で失敗することも当然のようにある。こうしたユーザー企業側の責任による「事故」を防ぐ術を身につけることも重要だということだ。車の運転にたとえるなら「事故を起さない運転技術」だけでなく、「事故に巻き込まれない運転」も大切だというところだろうか。

担当者はあくまで人

　大手の開発会社に発注したから大丈夫、あるいは名のとおったシステムインテグレータ（SI）だから安心というのは、ある意味間違いではない。ただ、実際に開発するのは人であり、担当（プロジェクトリーダー）のSEであるということに目を向ければ、そのSEの力量を知ることが重要だと気づく。SEに求められるスキルはプロジェクト管理能力、提案力、技術力など多岐に渡る。すべてを兼ね備えたSEなら言うことはないが、そのプロジェクトに最低限必要だと思えるものが欠落していたら、担当を替えてもらうしかないだろう。打ち合わせ中の会話や、何気ない一言からもそのSEの考え方や姿勢などが顕著に表れるものである。そこにSEを判断するポイントが隠されているのだ。今回はいくつかの例を見ながら、SEの見極め方を解説していきたい。

ケース1：代替案を出せるSEか

　発注側の要求・要望が、SIの判断でシステムに組み込めないことがある。たとえば追加要求の場合に、スケジュールの関係で無理だと判断したり、あるいは処理が煩雑すぎて組み込まない方が無難であると判断した場合である。

　システム開発の現場において珍しくない状況だが、このとき単に突っぱねるだけなのか、それとも代替案を提示できるSEなのかで評価は大きく異なってくるだろう。もちろん、発注側の思いつきのような要求なら別だが、仮にシステムに組み込めないとしても、ユーザー企業の希望に沿い、ポイントを突いた代替案を出してもらえれば、発注側としても検討するなどといった新たなアクションを起こすことができる。さらに代替案を見ることによって、その内容からSEのスキルを判断する材料としても使える。

ケース2：悪い内容の報告は早いか

　これはシステム開発のSEに限った話ではないが、言いづらい、悪い内容の報告を迅速にできるかどうかは重要なポイントである。たとえば、システム開発において実際にトラブルが発生してから、それを報告されたとしても対処することはできない。ある程度の経験があるSEなら、不具合が起きる予兆を感じ取った時点でまずは発注側に報告する。悪い報告はなかなかできるものではないが、最悪の事態を想定し正直になるべく早く報告する姿勢は、それだけ早くトラブルを回避しようという意思の表れだと捉えられる。

　少し前に私が関わったプロジェクトでも実際に起こった事例である。結論から言えば、通信に利用するソフトウェアのバグが原因で、謳い文句どおりの処理ができなかった。このときのSEは通信ソフトの検証を重点的に行なっており、システムの心臓部を担う機能について開発と並行して作業にあたっていた。

　通信ソフトのバグだということに確証を得るまでに時間がかかりそうだったが、もしそうなら通信ソフトの見直しも必要になり、発注担当者に取り急ぎ事態を報告した。発注側もSIの責任とは言えない問題なので、解決策を探ることに協力を惜しまなかったのである。結果的にスケジュールを多少延長する程度でそのシステムを開発することができた。もしこれが土壇場まで報告されなければ、発注側の協力が得られたかどうかは疑問である。

ケース3：スケジュールの説明は十分か

　分析・調査が終わり、要望や機能についての洗い出しが終われば、開発のためのスケジュールが作成される。SEが作成する開発スケジュールはおおむね設計・開発・テストと大きく分類され、それぞれの詳細作業にどれくらいの工数がかかるのかということが示されている。SEがこのスケジュールを発注側に渡すときに「こういうスケジュールで作業を進めます」で終わりにしてはいけない。スケジュール表にあるそれぞれの項目について、その作業内容を説明しないSEは駄目だと考えていい。スケジュールの簡単な説明だけでは、その妥当性を発注側が判断できないからだ。

　またスケジュール表の内容からもSEのスキルは判断できる。プログラムはそれ単体で動くのではなく、共通処理や共通データの受け渡しなど、ほかのプログラムと連携するものが多い。つまりAというプログラムが作成できなければB、Cが作成できないというケースもあるのだ。できればそういった関連性なども分かるようになっていれば、仮にスケジュールの遅れなどが報告されたときにも的確に対応できるだろう。また、スケジュール表には、それぞれのプログラムの難易度や開発工数の算出理由が明記されていることが望ましい。

ケース4：業務知識と技術スキルはどっちを重視すべきか

　プロジェクトのリーダーとなるSEには、業務に精通していて、技術スキルが高いことが望まれる。しかし、そういうSEに恵まれなかった場合、つまりどちらかが欠けているとしたら、どちらを重視するべきなのだろうか。

　開発するシステムの業務がかなり特殊な分野であったり、知識を吸収するのに長い時間がかかると思われるなら迷わず業務知識に長けているSEを選ぶべきだろう。逆に一般的な業務で、ある程度の期間があれば業務知識を会得できるなら、その期間を割いてでも技術スキルに長けているSEを選ぶべきである。たまたまその業務を経験していなかったからというだけで、技術スキルをはじめとして他に問題なければ、開発するにあたっての知識吸収も問題ないと思われるからである。