インドの3つ星シェフの腕を見抜く2つの質問：山浦恒央の“くみこみ”な話（3）

CMMレベル5の認定を受けたインドのソフトウェア開発会社にきちんとしたモノを作ってもらうための2つの質問と4つの具体策を伝授しよう

[山浦恒央 東海大学 大学院 組込み技術研究科 准教授（工学博士），＠IT MONOist]

　インドが大量に供給する高レベルのハイテク技術者を、日本の組み込み系ソフトウェア開発現場で活用する……。両者の思いや利害はきれいに一致しているのですが、うまく融合できている例はほとんどありません。こうなる原因や、悲劇が発生するメカニズムについては、前々回「『懐石料理』でインドの『スパイス』をうまく使う方法」、前回「幻の白いカラスを追い求め、僕らはインドにたどり着く」で説明したとおりです。

　今回は、老舗の懐石料亭が、3つ星インド・レストランの花形シェフを招いて成功するにはどうすればよいかを具体的に検討していきたいと思います。

　インドのソフトウェア開発会社が日本でセールスを展開する場合、殺し文句として使うのが「ウチは、CMMのレベル5の認定を受けています」でしょう（これは前回お話ししたとおりです）。もし、こうした場面に出くわしたのならば、「（CMMのレベル5か〜）じゃあ、お願いします！」といってしまいそうになるのをグッとこらえて、このコラムを思い出してください。

　前回のコラムにも書きましたが、CMMのレベル5は開発プロセスの成熟度の最高レベルであり、ソフトウェア開発のプロセスが確立しているのはもちろん、開発プロセスを具体的な数値で測定して、プロセスを最適化する能力があるということであり、決して高品質ソフトウェアを効率よく作ることができる「絶対的な能力」ではありません。

　もし、インドのソフトウェア開発会社の技術者から「ウチは、CMMのレベル5（もしくはレベル4でも）認定を受けています」といわれたら、3秒だけ感心した後、涼しい顔をして次のように質問してみましょう。

要求仕様定義のフェイズからテスト・フェイズまで、実際にどのように開発するか、御社の開発プロセスを具体的な成果物を例示して教えてください。

　相手に、ソフトウェア開発の一般的な話を聞くと、優等生的な当たり前の答えしか返ってきません。レベル5の認定会社であれば、そんなことでは絶対にボロを出しません。こんな場合は「現物」でチェックするに限ります。差し支えのない範囲で、実際に開発したモノ（ドキュメント）を見せてもらいながら、開発プロセスを説明してもらいましょう。「百聞は一見にしかず」です。仕様書、設計書、ソース・コード、テスト仕様書、デバッグ・テストの実施結果、品質分析書などを見ると、相手のソフトウェア開発能力が一瞬で分かります。特に、具体的な品質の確保策、制御方法を実際の成果物（ドキュメント）を例に説明してもらいましょう。

　続いて、第2の質問をぶつけてみましょう（これもさらに涼しい顔をして）。

ソフトウェア開発での具体的な統計データを教えてください。

　世のスポーツ新聞でさえ、プロ野球選手のデータ、例えば野手の場合、打率、得点圏打率、出場試合数、打席数、打数、得点、打点、安打数、三振、四死球、犠打、盗塁、出塁率などを毎日のように示しています。ソフトウェア開発でも、いろいろな数値を測定し、プロセスを制御しようとします。計測していないのは問題外。「受付で交通費をもらってお帰りください」と丁重にお引き取り願いましょう。社外秘でない範囲で、具体的なプロジェクトの生産性、品質データ（総バグ数、バグ発生曲線、影響度別バグ数、修正・未修正バグ数）などを提示してもらうと、相手の実力がはっきりと見えてきます。プロセスの具体的な値を提示できることもレベル5（もしくはレベル4）の能力のうちです。

　では、発注後の品質確保の進め方はどのような点に注意すればよいのでしょうか？ 以下で具体策を見ていきましょう。

　発注直後の数カ月間は、仕様書や設計ドキュメントがインドから期日どおりに出てきます。ところが、いざ開発フェイズが進み、インドで作ったソース・コードを検収のため日本で動かしてみると、機能漏れやバグが！ なんてことはよくあります。その瞬間から、お互いが大混乱し、後始末に奔走して眠れない日々が続くことになります……。

　せっかくソフトウェア開発能力が非常に高いインドの開発会社に発注したのに、これでは救われません。どうしたら品質の高いものを作ってもらえるのでしょうか？

　ここで登場するのが、インド発注の切り札「テスト・スイート」の同時発注です。

　どういうことかというと、単にソフトウェア開発を発注するだけではなく、テスト項目を設計してもらい、さらに、それを自動実行するテスト・スイートも同時に作ってもらうのです。

　具体的な手順は、以下のとおりです。

1．仕様書が完成した段階で、テスト仕様書を作成してもらう

　完成した仕様書を基に、インド側にテスト項目を洗い出してもらい、「テスト仕様書」を作成してもらいます。テスト項目とは、具体的な入力値と期待する出力値の組み合わせで記述した「変形版の仕様書」です。テスト仕様書の作成段階で、仕様関連のバグ（特に、仕様の抜け）を早期に見付けだすことができます。

2．受け取ったテスト項目の内容、過不足をチェックする

　インド側が作成したテスト仕様書にある各テスト項目で、期待している品質を確保できるのか、日本側でしっかりとチェックします。一般的に「テスト項目には20％前後のバグがある」ということを頭に入れ、内容を細かく分析しましょう。

3．完成したテスト項目の全件合格が検収条件

　つまり、「このテスト項目にすべて合格しないと、受け取りません」という検収条件を突き付けます（実際には発注の段階で事前に取り決めをしておきます）。ソフトウェア開発とテスト・スイートを同時発注することは、自分で自分の首を絞めることと同じです。テスト・スイート全件合格を検収条件にすると、いいかげんな品質のソフトウェアは作ってきませんし、機能の抜けもありません。また、検収条件が事前に提示されていますし、非常に明確です。

4．テスト・スイートでバグを検出した場合、どう対処したかをチェックする

　インド側が作成したテスト項目によって摘出したバグを単に修正しただけでは「モグラたたき」式品質確保です。これでは不十分。熱が出たら、薬を飲んで熱を下げ、それでよしとする対症療法と同じです。実は、発熱の原因が盲腸の化膿（かのう）かもしれません。摘出したバグを基に、以下の分析を実施することが必要です。インド側がきちんと分析しているか、チェックしましょう。

• （a）技術的な原因の分析
  メモリの解放漏れ、排他制御の不良など、技術的な要因を分析して、相手が類似バグを分析するプロセスを実施しているかを見ます。
• （b）統計的なバグの分析
  経験的に、80％のバグは20％のモジュール（あるいは、機能）に潜んでいるといわれています。多数のバグが見つかったモジュールは、たたけばたたくほど、バグが出ます。統計的なデータを分析して、デバッグをしているかをチェックします。
• （c）組織的・人的な原因の分析
  　そのバグを作り込んだのは、時間がなかったためか、十分に時間をかけたのにバグが潜り込んだのか、設計者の癖によるものか、組織的なものかの分析をして、類似バグを見直したかをチェックします。

　以上が、日本とインドとの国際共同開発を成功に導くためのポイントです。

　インド人エンジニアは、異常にプライドが高く、孤高の哲学者に見えます。ソフトウェアの開発能力が非常に高く、特に、ソース・プログラム以外のドキュメントがないソフトウェアの解析能力は世界で圧倒的に最高です。

　優秀で思慮深く誇りも高いインド人技術者とソフトウェアを共同開発する場合、「こちらが金を払うのだから、いったとおりにしろ」と頭ごなしに命令したり、品質の低さをなじったりしてはいけません。また、「相手が一方的に悪い」という考えを持たないことも重要です。日本側にも誤解や悪いところがあるはずです。「お互いの考え方が違う」「宗教が違う」と相手の考えや気持ちを理解することも時には必要です。

　ただし、情に流されてはいけません。いうべきことはキチンと主張しましょう！ 改善してほしいプロセスがあれば、数値を示して具体的に説明しましょう。CMMのレベル5取得企業なら、こちらの要望が満たされるように、相手が開発プロセスを最適化してくれるはずです。これが、レベル5本来の意味です。

　自分自身を客観的に見ることができ、相手の特徴を理解していれば、ソフトウェアの国際共同開発は必ず成功します。日本の老舗懐石料亭が、新しい和食を開拓するために3つ星インド・レストランの花形シェフを招き、成功するより、はるかに簡単です。（次回に続く）

【 筆者紹介 】

山浦 恒央（やまうら つねお）
東海大学 大学院 組込み技術研究科 助教授（工学博士）

1977年、日立ソフトウェアエンジニアリングに入社、2006年より、東海大学情報理工学部ソフトウェア開発工学科助教授、2007年より、同大学大学院組込み技術研究科助教授、現在に至る。

主な著書・訳書は、「Advances in Computers」 （Academic Press社、共著）、「ピープルウエア 第2版」「ソフトウェアテスト技法」「実践的プログラムテスト入門」「デスマーチ 第2版」「ソフトウエア開発プロフェッショナル」（以上、日経BP社、共訳）、「ソフトウエア開発 55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」（以上、日経BP社、翻訳）。