TOP＞プロジェクト管理＞ 顔合わせ

踊るエンジニア 〜システム開発現場の風景 第９回：標準化に消えたプロジェクトマネージャーの信念 著者：ビーブレイクシステムズ  鹿取 裕樹   2005/10/20

前のページ  1  2   3  次のページ

顔合わせ

6月某日、筆者は都内のとあるビルの玄関をくぐりました。筆者にとってはこの日が今回のプロジェクトの初日でした。プロジェクトルームに入ると、会計チームのリーダーに案内されてプロジェクトマネージャーや他チームの紹介を受けました。

プロジェクトマネージャー

プロジェクトマネージャーは30代後半の男性でした。外見は身だしなみが整っており、いつも背筋がびしっと伸びているような人でした。話をしてみてもまじめで、話す内容も的を射ており、無駄な話をしません。やや近寄りがたい雰囲気がありますが、とても頼りになりそうな人でした。    早速プロジェクトマネージャーからプロジェクトの状況の説明を受けて、このプロジェクトの重要性とプロジェクトマネージャーの意気込みを聞くと、筆者もやる気がかきたてられました。

多忙なリーダー

その後も、生産管理・在庫管理・販売管理の各リーダーの紹介を受けました。その中で販売管理のリーダーの様子が気になりました。何かに追い詰められたようで、余裕のない様子だったからです。    紹介を受けた後で他の人に聞いたところ、彼はこのプロジェクトの他にも4つのプロジェクトに関わっているとのことでした。彼はこのプロジェクトでリーダーを務めており、関わっているプロジェクトの中でも重点を置いているとのことでしたが、他のプロジェクトでも少なからず作業が発生しているようでした。    どうやら紹介を受けたときは他のプロジェクトで問題が発生していたようで、余裕のなさはそこに原因があったようです。

会計チーム

そして最後に筆者が属する会計チームの紹介を受けました。この時の印象はメンバーが若いということでした。    後に設計を担当するあるメンバーと話をしたところ、彼らは今回初めて設計を担当するとのことで不安そうな様子なんだといわれました。しかも会計システムの開発経験が少なく、業務知識にも不安があるとのことでした。    チームには経験が豊富なメンバーもいるとのことでしたが、筆者はやや不安を覚えました。

伝わらなかった仕様

「仕様と違うじゃないか。」    ある日、筆者の席から少し離れた販売管理チームの席で騒ぎが起こりました。何かと思って話を聞いてみると、中国に開発を委託していた機能のうちの一部が完成したためその動作を確認したところ、仕様と異なっていたとのことでした。

「以上」の意味

仕様が満たされていない例として、ある値以上の数値が入力された場合にエラーとするという仕様があります。例えば1000以上はエラーにするという仕様であれば、999まで入力可能で1000はエラーとなるはずです。    しかし中国で実装された機能では1000まで入力可能で、1001がエラーとなっていました。日本の担当者が急いで中国の担当者に確認したところ、仕様書に「以上」と書かれていたからその通りに実装したとの返答がありました。    最初、日本側はこの返答の意味を理解することができませんでした。実装された機能は日本でいう「以上」になっていなかったからです。    しかし、よくよく中国の担当者の話を聞いてみると、中国語では「以上」の意味が日本とは少し異なるそうです。「1000以上」という場合、1000を含むか含まないかは決まっていないとのことでした。そして中国側では1000を含まないという判断をしてしまい、その方針のもとで実装してしまいました。    この問題に対して、自然言語ではなく式であらわすという対策を採用することになりました。

曖昧な仕様

その後も中国に委託していた機能が完成していくにしたがい、日本の仕様担当者が考えていた仕様と完成した機能との食い違いが続出しました。    ブリッジSEを通じて中国の開発者にその旨をつたえると、仕様書どおり開発したという回答が返ってきました。日本側で仕様書を再度確認すると、仕様書があいまいであったことが露呈したのです。    このプロジェクトの元請け会社は中国の開発者への委託の経験が少なかったために、海外に開発を委託する場合、日本人が開発する時に比べて、仕様の精度がより重要であるということを十分に理解していませんでした。    そのため曖昧な仕様書で中国に作業を依頼しており、その曖昧さについても中国の開発者からの問い合わせがなく、そのまま開発が進んでいました。結果として、日本側で考えていた仕様が満たされない機能が完成していったのです。    そこで、すでに完成した機能は日本側で修正することで対応し、中国で開発中の機能については仕様を再度確認し、曖昧な部分をつぶしていきました。

前のページ  1  2   3  次のページ

著者プロフィール 株式会社ビーブレイクシステムズ  鹿取 裕樹 オープン系ITコンサルタント。SAPジャパン社にて、ERP導入コンサルティングを行い、そのユーザ企業の現場でJava及びオープンソースの躍動を感じ、それらに興味を持つ。その後、会社を設立。オープンソース及びJavaを用いたシステム提案活動を行い現在に至る。専門分野はSAP R/3と連携するWEBシステムのコンサルティング。

INDEX 第9回：標準化に消えたプロジェクトマネージャーの信念   はじめに 顔合わせ   混乱するプロジェクトマネジメント

踊るエンジニア 〜システム開発現場の風景 第1回 初心者SEと最初のプロジェクト 第2回 徹夜と謝罪の下流工程 第3回 消された案件とチームの事件 第4回 新人とエンジニアのプライド 第5回 彼女の悲鳴は聞こえない 第6回 怒鳴りこみ・すれ違いと真実 第7回 タイムリミットは10日間 第8回 さらば愛しきプロジェクトマネージャー 第9回 標準化に消えたプロジェクトマネージャーの信念 第10回 エンジニアよ、永遠になれ