顧客がベンダーやITエンジニアを見る目は,年々厳しくなっている。最新技術を追いかける根性や,徹夜してでも納期を守る体力だけでは,もはや評価してもらえない。「注文通りのシステムを作ればよい」というエンジニアは,消え行くのみだ。

イラスト 野村 タケオ

 介護用品の販売・リースを手がけるA社は2003年11月,新・販売管理システムの導入に踏み切った。ここ数年で問い合わせや受注が激増し,従来のシステムではさばききれなくなったことがきっかけである。同社はこれまで,商品への問合せや見積作成,在庫確認,成約といった一連の受注業務を,それぞれ異なるソフトを使って個別に処理していた。このため,顧客からの見積依頼から成約処理までに1週間近くかかることが珍しくなかった。二重,三重入力作業が発生するためミスも起きやすく,顧客からクレームを受ける原因になっていた。

 そこでA社は,受注関連業務を一元的に管理できる新システムの導入を決断。さっそく,SIベンダー3社に見積もりを依頼した。コンペの結果,中堅ベンダーであるY社が大手2社を押しのけて開発を受託した。社員数が約200人と企業規模は小さいながら,ユーザーであるA社の要求以上の機能をシステムに盛り込んだ提案内容が評価された。

 こうして2004年1月,同年11月のシステム稼働を目指してプロジェクトが動き出した。Y社からは,Fマネジャーを筆頭に10人がプロジェクトに参加した。そのメンバーの1人が,今回の主人公であるC君(28歳)である。

設計段階での検証を怠る

 C君は,Y社に入社して5年。主に客先での常駐サービスに携わってきた。最近では,プログラム開発だけでなく基本設計や詳細設計業務もこなしており,仕事の領域をぐんと広げつつある。そうした実績を買われて,A社プロジェクトでは見積システム開発チームのリーダーに抜擢された。C君は「納期はわずか10カ月。設計・開発をどんどん進めて,1日も早くテストにこぎつけよう」と,自分なりの戦略を立ててプロジェクトに臨んだ。

 C君の思惑通り,見積システム開発チームは,業務内容の把握とシステム化の要件整理までを手早く済ませ,設計フェーズに入った。作業は順調そのもの。プロジェクト開始から2回目の月例進ちょく会議を迎える時には,設計工程をほぼ終わらせようとしていた。

 その進ちょく会議でC君は,「私たちのチームの進ちょくは極めて順調です。この調子で一気に設計を終わらせて,開発本番に進めるつもりです」と胸を張って報告した。作業は予定より先行しているし,トラブルもない。「Fさんはきっと評価してくれる」と信じていた。ところが,Fマネジャーの口から出たのは意外な問いだった。「設計段階で,A社の担当者にレビューしてもらったんだろうね?」。

 「え?」。C君は一瞬戸惑ったもののすぐに気を取り直し,「その必要はないと思います。客先の担当者にヒアリングして作成した仕様書通りに作業していますから。あとは,テストの時に検証してもらいます」と応じた。これを聞いたFマネジャーは,「それではだめだよ。もっと顧客の業務担当者とコミュニケーションを取りなさい」とC君を叱りつけた。「システム・テストになって初めてユーザーが機能検証するのでは遅すぎるんだ。万一,そこで問題が見つかり手戻りが発生したら,納期が危なくなるだろう」。

 褒められるどころか,皆の前できつく注意されたC君は,なぜ自分の仕事が認められないのか理解できなかった。「それでは,何のための仕様書なんですか。私たちのチームは,仕様書と違いが発生しないよう,お互いにチェックしながら開発を進めています。これ以上,慎重で十分なやり方はないでしょう?」と顔をゆがめた。

仕様書が金科玉条

 他のメンバーは,2人の言い合いを黙って見守っていた。Fリーダーは席を立ち,窓際まで歩いて行った。「このプロジェクトは納期が極めて厳しく,要件定義や仕様決めを駆け足でやらざるを得なかった。そのため,我々の誤解やもれがあるかもしれない。後工程での手戻りを1つでも減らすには,設計段階で要所要所を顧客に確認しながら進めるしかないんだ」。C君はまだ納得できず,「でも,仕様書は顧客も目を通して承認しています。後から文句を言われても,こっちの責任ではないですよ」と反論した。

 FマネジャーはC君の方を振り返り,「確かに君の言うことは正論だ。決められたこと,指示されたことを確実に実行することは,とても重要だよ」とうなずいてみせてから,こう言った。「だが,仕様書通りに開発をすることだけでは,我々中堅ベンダーは合格点をもらえないんだ」。

 さらにFマネジャーは,メンバー全員を見回して「いい機会だから,君たちに覚えておいて欲しい。決められた期間内に仕様書通りのシステムを開発するだけなら,エンジニアの頭数をそろえる大手が圧倒的に有利。当社はとてもかなわない」と言い切った。

 「当社は生き残れないということですか」。誰かが声を上げた。Fマネジャーはそちらを見て,「いいや。我々ならではの強みがある。受注したシステムに,仕様書以上の付加価値を与えることだ」と答え,「当社がこの案件を受注できたのも,顧客の要求以上の機能を提案したからだよ。顧客と一緒になって,問題解決を図る姿勢が評価されたんだ」と付け加えた。

 Fマネジャーは再び正面に向き直ると,「君たち現場のエンジニアも,顧客との対話から隠れたニーズを探り,どんどん提案して欲しい。当社が大手と伍して戦うには,開発力だけでなく提案力という武器が不可欠だぞ」と締めくくった。

 C君は,目からウロコが落ちる思いがした。「自分の考えが浅かった。仕事のとらえ方には,もっと上の次元があるのだ」と痛感した。周りのほかのエンジニアを見回すと,やはりFマネジャーの言葉に感じるところがあったらしい。会議前に比べて,皆の顔つきが引き締まって見えた。

今回の教訓
・仕事のやり方に絶対はない。時と場合によって,柔軟な思考が求められる
・結果的には間違った意見でも,発信しなければ前進しない
・開発現場は,成長の糧に満ちている。問題は,それをどう生かすかだ

岩井 孝夫 クレストコンサルティング
1964年,中央大学商学部卒。コンピュータ・メーカーを経て89年にクレストコンサルティングを設立。現在,代表取締役社長。経営や業務とかい離しない情報システムを構築するためのコンサルティングを担当。takao.iwai@crest-con.co.jp