納入物の品質問題と対策方法(オフショア開発失敗あるある)

オフショア開発の品質に悩んでいる人
・納入物の品質が悪い。
・どうして納入物の品質が悪いんだろう?
・どうやって品質をあげれば良いんだろう?

といった質問に答えます。

オフショア開発でもっとも課題が多いのが

おそらく

・「品質」

だと思います。

ソフトウェア開発において品質とは、

・コードの不良(バグ)
・ドキュメントの質
・ソースコードの読みやすさ(質)
・要件の作り込み不足(実装もれ、実装不十分)

などいくつかありますが、

今回は品質としてもっとも影響度の大きい

・要件の作り込み不足(実装もれ、実装不十分)

にフォーカスして、

この問題が発生する原因と対策について話をします。

その他の問題は、改めて別のブログで取り上げる予定です。

ちなみに、この問題に対する解決のキーワードは

・「コミュニケーション」

です。

それでは、説明をはじめましょう。

目次

目次は次の通りです。

1.納入物をチェックしたら不良が山積み?
2.要件の作り込み不足が発生する原因
3.普段の状況報告の中で不良が見つけられない理由
4.対策方法
5.まとめ

それでは、1つ1つ説明していきますね。

1.納入物をチェックしたら不良が山積み?

オフショアから、完成したソフトウェアが納入され、

いざ受け入れ検査を実施すると次から次へ見つかる問題点。

ソフトウェアなので、

不良が「ゼロ」ということは絶対にないものの。

それにしても不良が多い。

しかも、そもそも論として、

・開発を依頼した要件通り動作しない
・要件そのものが実装されていない

などが発覚。

「なんだこれは???」

受け入れ側の日本の企業では、受け入れ検査後の

品質の悪さに大慌て。

そこから品質向上のための議論を開始し、その後の日程の調整など、

いっきに現場が騒然とし始める。

といった光景を、私は何度も見てきました。

あ、私のプロジェクトではないですよ。

私なら、こんな状態になるまで放っておいたりしません。笑

こういう状態になった後に、

問題の対応と事態の収拾のために駆り出されたことは何度もあります。

オフショアを活用したプロジェクトでは、

多かれ少なかれ、

皆さんも同じような経験を一度はしたことが

あるのではないでしょうか?

では、何故このようなことが起きるのかを深掘りしてみましょう。

2.要件の作り込み不足が発生する原因

要件の作り込み不足が発生する理由として考えられるのが以下です。

・発注側の要件仕様書の質の問題
・オフショア側の要件仕様書の理解不足

です。

まず1つ目の

・「発注側の要件仕様書の質の問題」

についてですが、

日本企業がオフショアを活用する際に直面する

多くの問題の原因がこれです。

国内請負に開発を発注する場合、

発注側は要件仕様書は用意するものの、

ドキュメントの記載内容が充分ではない事がほとんどです。

これは、前回のブログにも書きましたが、

ここには日本人同士の「行間を読む」手法が使われているからです。

日本の企業同士の場合は、

全てことがらをこと細かく書かなくても、

プロジェクト共通の「暗黙のルール」があったりします。

そこをわざわざ書き下すこと自体が時間の無駄になるので

そこを書かないままでプロジェクトが進んでいきます。

オフショアを活用するようになっても、

この習慣が変わることはなく、同じレベルの仕様書を

オフショアに渡して開発を依頼することになります。

とうぜん、オフショアとの間には「行間を読む」手法が通じるわけはないので、

発注側の意図が正確に伝わらず、

実装もれや実装不十分といった問題が発生することになります。

次に、

・「オフショア側の要件仕様書の理解不足」に関してですが、

これにはいくつかの原因が考えられます。

・発注側の書き方の問題
・翻訳時(日本語→英語)の翻訳の仕方の問題
・オフショア側のスキルの問題

です。

大抵は原因は1つではなく、複合で発生しているケースがほとんどです。

私の経験からすると、

・「発注側の書き方の問題」

が多いと感じます。

これも結局「発注側の要件仕様書の質の問題」と同じで、

仕様書に情報が書かれていたとしても、記載が間違っていたり

分かりにくかったりします。

ちなみに、オフショア活用時に翻訳を依頼する場合には、

翻訳先を選ばないととんでもない翻訳結果になったりします。

以前OSの「Windows「を「窓」と訳しているのを見てびっくりしたことがあります。

多少コストが高くても、業界用語が分かる翻訳会社に依頼するのが良いです。

オフショアのスキルの問題に関しては、

発注コストが安い会社は、スキルもそれなりです。

業界標準からあまりにもかけ離れた会社は、

発注時はコストが安くとも、

後々品質問題を引き起こし多大なるコストがかかり

逆に開発費が高くなることがあります。

コストとスキルのバランスを見て、発注先を選定するようにしましょう。

ただし、私の今までの経験では、現在はオフショアのエンジニアの方が

はるかにスキルの高いエンジニアが多いという印象です。

要件の作り込み不足が発生するのは、

発注側の仕様書の質が主な原因となる場合が多いです。

3.普段の状況報告の中で不良が見つけられない理由

問題点の解決策を説明する前に、

どうしてこういった問題を事前に見つけられないのか、

その点に関しても少し深掘りをしておきましょう。

おそらく、どの会社でもプロジェクトの進捗状況に関しては

週に1度くらい

・「進捗報告会」

が実施されていると思います。

多いところは、毎日実施しているところもあり、

筆者である私のプロジェクトも

わずか15分ではありますが毎日ステータスの確認をしています。

普通、オフショア開発でも同じようなやり方で進捗の確認を

しているはずなのですが、何故か納入前に問題が発覚することなく

納入後に問題が発生し炎上することになります。

これは何故か?

これは、日本とオフショアの仕事のやり方が異なるからです。

というのは、

・日本はボトムアップ方式+チーム型
・海外はトップダウン方式+自己責任型

であるためです。

たとえば、日本の進捗報告会では、発注側は請負側からの

進捗状況を確認し、問題があれば一緒に解決するアプローチを

とります。

なので、なにも報告がなければ問題がないと判断します。

ここには、双方に対する信頼関係があります。

これに対して海外の進捗報告会は、

発注側からの作業指示や意思決定が行われるトップダウンの場です。

各請負先で発生している問題に関しては、基本請負先での解決が求められ、

解決できないとなると発注先を変えられてしまう場合があります。

請負先では決断できない案件に対してのみ報告会で報告され

発注側はその場で対応を決定し、請負側に作業指示を出します。

日本の会社は請負も発注側も一体となって

プロジェクトを推進しようとしますが、

海外の場合は自己責任を基本としており、

議論される内容も求められる責任も変わってきます、

このことが、報告会で日本側の想定する情報が出てこない

理由でもあります。

では、対策はどうするか?ですが、2つあります。

・オフショア側に日本式のやり方を学んでもらう
・発注側は、グローバルのやり方を理解して、トップダウンで課題を収集できる仕組みを作る

です。

要はお互い歩み寄る感じですね。

どのような場合もそうですが、一方的に片方のやり方を

押し付けるのはうまくいきません。

互いのやり方を理解し、お互いが歩み寄ることが重要です。

日本式の状況報告では問題点の把握がうまくできません。

お互いのやり方を尊重しつつ、双方がやりやすい方法を

考えましょう。

4.対策方法

では、具体的な対応策について説明します、

対応策は以下です。

(1)成果物の詳細な定義
(2)中間成果物入手と小まめなチェック
(3)15分のDailyチェックと情報共有

では、詳細を説明しますね。

(1)成果物の詳細な定義

当然といえば当然ですが、最終成果物の仕様を明確に定義し、

それを文書に定義しましょう。

繰り返しになりますが、オフショア開発では

・「行間を読む」

やり方は通用しません。

きちんと文書に落とし込むことが重要です。

もし、事細かに書き起こすことが難しいようであれば、

口述により説明し、オフショア側に文書に落と仕込むよう

依頼するのもいいでしょう。

もちろん、落とし込んだ文章を発注側でチェックする必要はあります。

ドキュメントで成果物をきっちり定義しましょう

(2)中間成果物入手と小まめなチェック

どんなに文書に落とし込んだとしても、

どうしても認識のずれは発生するものです。

これに関しては、文書を完璧に仕上げようと考えても無理です。

それよりは、中間成果物を小まめに納入してもらい、

実際の成果物をチェックしてフィードバックをかけましょう。

オフショアを活用する場合の一番重要なことは、

・小まめにチェックすることで、問題が小さなうちに早めに摘みとる

です。

請負先から完璧なものが出てくるようにするのではなく、

間違いが発生することを前提に、

その対策方法を組み込んでおくことが需要です。

中間成果物を納入してもらい、小まめにチェックしましょう

(3)15分のDailyチェックと情報共有

中間成果物と同じですが、オフショア開発においてはオフショア側と

たとえ短い時間でも毎日コミュニケーションをとることが重要です。

報告書などに上がってこない課題なども、

直接会話することで問題点が見えてくることがよくあります。

コロナの影響で、テレワークにも慣れてきているものと思います。

議題がない日も、Zoomなどを使って

オフショアと毎日15分程度の定例会を持ちましょう。

たとえ短くても、毎日オフショアとコミュニケーションを取りましょう

5.まとめ

では、まとめです。

今回は、

・納入物の品質が悪い。
・どうして納入物の品質が悪いんだろう?
・どうやって品質をあげれば良いんだろう?

という質問について話をしてきました。

まず最初に、

オフショアを活用する場合は国内請負を使う場合と比較して

やり方を変えるべきとの話をしました。

なぜなら、オフショアは「日本人」ではなく、

日本のやり方、習慣、考え方を知らないからです。

具体的には、仕事の進め方として下記の3つを説明しました。

(1)成果物の詳細な定義
(2)中間成果物入手と小まめなチェック
(3)15分のDailyチェックと情報共有

これらを実施することで、

オフショアとの認識の齟齬(そご)は減り、

コミュニケーションは向上し多くの課題を解決していけるはずです。

今回のブログの情報から、読者のみなさんが担当するオフショア開発が

1つでも多く成功することを祈っています。

それでは、また!

あつし