PR

これまでいろいろなソフトウエアをオフショアで開発してきました。ミドルウエアのようなIT技術中心の開発は,委託先に経験や技術があれば比較的うまくいきます。しかし,アプリケーション開発の場合はなかなか計画通りに進みませんでした。

 開発されたソフトウエアの品質を確認するため,最終的にテストを行います。その際,試験要項書(テストケース)や不具合対策書(バグリスト)などのテスト関連ドキュメントが使用されます。今回はこれらのドキュメントにまつわる苦い経験について述べてみたいと思います。

 オフショア開発においては,外注計画・契約・開発・管理・受入検査など,最初から最後まで様々な管理の切り口があります。それらのプロセスの良し悪しが,最終的にテストで顕在化することになるのですが,今回はテストという側面に絞ってお話ししましょう。

受入基準の確認,試験要項書の作成なしで失敗

 最初に,データベースを活用した情報システム開発での出来事をお話しします。

 日本人SEが要求仕様を丹念に検討し詳細を数百ページの仕様書にまとめ,その開発を海外ソフト会社に委託しました。工数約20人月の規模でした。

 このプロジェクトでは,(1)仕様書が詳細に記述されていること,(2)画面の処理はそれほど難しいものではない,(3)海外委託先に同様のシステム開発の経験がある,ことから,委託先で十分な品質管理をやってくれるだろうと安心して,手間がかかる試験要項書の作成はなしとし,受入検査は仕様書をベースに行うことにしました。

 結果的には,200件以上の不具合が発生し,その対応も長引きました。

 例えば,検索処理で納期欄に日付を入力するとエラーとなってしまうという,基本的な不具合もありました。

 さらに日本側においても体系的な受入検査が行われず,現場でのシステム仮運用が逐次拡大されていったため,不具合が検出される都度,慌てて対応するという悪循環が数カ月続きました。

 最終的に,日本側と海外側双方の人的努力で何とか乗り切ることができたものの,オフショア開発スタートする前に,設計や技術面だけでなく,試験要項書,受入基準,そして委託先の品質体制を確認しておくべきだったと反省しました。

試験要項書は万能ではない

 このような事態を再度起こさないために,私は根幹となる設計をしっかり押さえ,試験要項書で詳細を確認し,枝葉となる画面表示等は修正対応すれば,ある程度の品質は確保できると考えました。

 ちょうどその頃,デバイスをコントロールするソフトウエア開発をオフショアでスタートしました。日本側SEが要求仕様をまとめ,現地に理解しやすいよう英訳して渡しFace-To-Face打合せで詳細を確認しました。開発要素はドライバ部とアプリ部に分かれ,それぞれスキルがある海外技術者が担当して開発がスタートしました。開発工数は約20人月のプロジェクトでした。

 以前の教訓により,設計のポイントとともに試験要項書による確認が不可欠と考え,日本側で作成した資料を現地で理解できるように英訳して渡し,海外側にそれに基づいて試験を行いその結果を記録するよう依頼しました。そして,試験要項書の内容に関して不明点があれば必ず日本側に確認して実行するよう念を押しました。

 結果的には,諸条件もからみお,またもや仕様確認漏れも合わせると200件近い不具合が発生しました。

 操作ミスやハードウエア故障時の異常処理がうまくできていないという不具合が多く検出されました。この原因の中に,ドメイン知識の移転の問題や試験要項書に関する取組みの問題がありました。

 試験要項書には,エラーを発生させて処理をチェックするという項目がありましたが,海外側でそのエラーを発生させる方法がわからないため,結果欄に「テスト不可」と記載された項目も多くありました。

 海外側が日本側より適切な情報を入手して深く検討することができればテストできる内容もありました。日本側は長らくその開発サポートをやって慣れているので,その資料さえあればテストのやり方や不具合検出時の対応は一目瞭然であり,海外側でも当たり前にやってもらえることと考えていました。

 しかし海外側は,渡された試験要項書を見て,「これに基づいてテストさえやればよいのだな」と思っていたのでした。海外側はそのソフトウエアを開発する技術スキルは有していましたが,そのデバイスに関する背景やドメイン知識を知っていませんでした。海外の常識と日本の常識とは異なっていたのでした。

 試験要項書さえ渡せば解決するという考えは間違いでした。書類に書かれていない,テストにまつわる背景を理解してもらい,実際に緻密にテストして不具合が見つかれば記録し,徹底的に調査して対策するアクションをとってもらうことが大事でした。日本での常識 ,背景も含めてしっかり海外側に移転し品質意識を醸成することが重要と認識した次第です。

 Software Inspectionに関連してMr. Tom Gilbの下記の言葉があります。

 “Don’t misuse Inspection as a ‘Clean-up’ process,Use it to motivate,teach,measure,control quality,and to improve your processes.” 意訳すると『検査をクリーンアップ(掃除)プロセスとして誤用してはならない。それを品質のモチベーションや指導,測定,管理のため,さらにプロセスを改善するために使用せよ。』となります。このことを痛感しました。

不具合対策の内容がわからない問題も発生

 不具合が検出されたとき,海外の担当技術者による原因調査とソフト修正対策が行われました。しかしその後,同様の不具合が再発したり,発生原因と対策内容が第三者にわからない問題が発生しました。

 その技術者に,不具合の現象,原因,対策などを不具合対策書に記入してもらうことにしていたのですが,対策検討で頭が一杯だったためかそれが習慣化していないためか,なかなかそのとおりに実行してもらえませんでした。

 そのため,日本側メンバが毎日テスト終了後その技術者と一緒に不具合対応の記録を整理しました。しかし,コミュニケーションしてまとめるためにかなりの時間を要し,このように日本側の手間をかけていたのではペイしません。

 そこで次のステップでは,不具合対策書の中に,再現方法,対策詳細などの項目を加え,海外の上司のプロジェクトリーダーの照査の後,日本側に送ってもらうようにプロセスを変更しました。

 このレビューの効果は大きく,2次的な不具合が発生しなくなりました。また同プロジェクトリーダーはコミュニケーションがうまく報告書作成スキルが高いので,報告書の内容が第三者によく理解できるようになりました。この経験により,適材適所で海外人材を活用するのが効果的と実感しました。

オフショアで試験要項書を作成してもらい品質を向上

 これらの経験から,日本からテスト要項書を単に渡しただけでは,オフショア側に品質意識を醸成しにくいことがわかりました。

 それなら海外側で作成して勉強してもらってはどうだろう。

 ちょうどそのとき,Web情報システムのプロトタイプの開発をオフショアでうまく開発終了し,その本番開発を検討する段階にありました。これまでプロトタイプ開発はうまくいってもそのまま進めると本番開発では大きな問題が発生したケースも多かったので私は不安を感じていました。そこで本番ソフトで要求される品質はプロタイプと異なること,また日本で一般的に海外側が考えるより高い品質が常識的に求められることを開発チームによく話しました。

 そして,育成も兼ねて,(1)海外側で試験要項書を作成して実際にテストする,(2)要求仕様を理解しているオンサイトSEが日本でさらに確認テストする,(3)それらのプロセスと結果を日本側が確認する,という3重のチェックを行いました。

 結果はまずまずの出来栄えでした。作成したテストケースの数は約2500で,前半1回,後半1回計2回のテストを行い,前半かなりの数の不具合が検出されましたが,後半では不具合件数は約20件でした。

 試験要項書の記述に不備を見つけたときは指摘して直してもらいました。不具合内容を分析すると,処理結果が正しく表示されていないという表示ミスがほとんどでした。テスト結果データを分析すると一定の指標を達成していることがわかりました。

 この開発はオープンソースをベースにしており,開発チームの品質向上意識も高く,そのテストをかたく実行フォローしたところにうまくいった鍵があると思います。このプロジェクトはこの段階までで総工数70人月以上を要したプロジェクトで,長期展望でオフショア開発を進めたこともプラスに寄与しています。海外側で試験要項書の作成とそれによるテストができれば,現地の理解や意識が向上するとともに,日本で行うより大きなコストメリットがあります。

テストドキュメントの課題

 テストに際しては,(1)試験要項書作成,(2)試験実施,(3)結果記録,(4)結果レビュー,などのプロセスが必要になります。

(1)試験要項書作成

 正常処理/異常処理を含めて,テスト方法,入力,条件,確認事項,あるべき結果などを記載することが必要となります。

 そして誰がどこまで書くか,またどの程度まで機能を網羅するかがポイントになります。各画面入力項目など詳細まで書こうとすれば大きな工数が必要になります。また異常処理などについては詳細仕様を理解した人材の対応が必要です。そのため急ぐプロジェクトでは仕様書を代用して結果を確認するケースもあり,その場合どこまで確認するかの双方の理解が異なるとテストの中身が食い違ってきます。

 また試験要項書に書いてあることだけやればよいのか,さらにどこまでテストを考えて対応してもらうかなどについて合意が重要です。

 詳細仕様を理解していない人が書くと,読む人が理解しにくい内容となり,後で問題が出ます。

(2)試験実施

 要項書に従って正確にテストしてもらうことが重要です。そしていつ誰が実施し誰が確認照査したかの記録を確認することが必要になります。

 これまで海外側のテストでOKとなっていた項目が日本でテストするとNGになったこともありました。責任の所在を明確にするため,海外側責任者の確認記録をとることも大事です。そして実施者は対象システムに関する適切な知識を有していることもポイントです。さもなければ,要項書にもとづきただチェックするだけの作業で品質改善に結びつかないことにもなりえます。

(3)結果記録

 テスト結果を正確に克明に記録してもらうことが必要です。これまで記録すべき項目の記載がなかったり,記述があいまいなケースも多くありました。問題がある場合は指摘し直してもらうことが大切です。

(4)結果レビュー

 最終的に,テストの結果が試験結果書や不具合対策書などに集約されますが,書くだけ書いてソフト開発は終わりの対応も多く見受けられます。これらは宝の宝庫です。この中から対策案を出し継続的に改善を積み重ねることが品質向上につながります。またテストした項目は検証されても,テストされていない部分の品質は不明であるため,設計段階での品質作りこみに十分な焦点を当てておくことが大事であることはいうまでもありません。

 IT技術を中心に急速に成長した歴史の浅い海外のソフトウエア会社は,欧米や日本からのアウトソーシング対応の中で要求品質を認識し対応改善を続けていますが,中には,日本の製造業が長年培ってきている品質つくり込みの対応レベルには至っていないケースも見られ,その場合は育成指導が重要になります。

オフショアにおける品質

 また顧客やプロジェクトにより要求品質が異なることも経験しました。

 プロタイプはその技術や有用性の評価のために開発するものであり,スピード最優先で,次にある程度の品質が要求されます。

 社会システムと関連するソフトウエアでは極めて高い品質が要求されますが,インターネットビジネス関連では一定レベル以上の品質が要求されます。そのため,ビジネス的にその案件の要求に合った適切な品質のソフトウエアを効果的に開発することが大事ということを認識しました。

 最近はオフショア開発に際して,要求品質レベルを確認してから開発をスタートさせることにしています。

 ところで,これまでのオフショア開発であるパターンを経験しています。それは,最初のいくつかのプロジェクトで成功して安心していると,次のプロジェクトで問題が発生するというパターンです。すなわち一定の品質を継続して達成することは難しいという現実です。

 海外取引先でオフショア開発を10年以上やっている信頼できるSEも「そのとおりです。海外開発で一定の高いレベルの品質を保つことが難しいと実感します。」と話していました。

 日本側として,オフショア品質管理を海外側に要求するだけではなく,プロセスとヒトの管理やナレッジ蓄積を押さえ継続的な改善を図ることが大事だと思います。


雨季で浸水しても普段通りのベトナム
[画像のクリックで拡大表示]