こんにちは。クオリティマネージャーのおすぎです。
私は中国やベトナムの企業を活用したオフショア開発プロジェクトのPMOとして活動してきました。
昨今のオフショア開発は日本企業内にノウハウが蓄積されて開発プロセスも成熟してきましたし、オフショア企業も日本企業の商習慣や品質基準の理解が進んできたことで成果物の品質も安定してきた印象があります。
いまやオフショア開発なしのソフトウェア開発に出会う方が少ないのではないでしょうか。
しかし数年前のオフショア開発では、これまでのソフトウェア開発ではあまり出会うことのなかった問題が出てくるため、日々新しい課題と向き合いながらプロジェクトを進めていました。
そんなオフショア開発でよく目にしていた事例と、その改善策の一例をご紹介いたします。
問題：動くことを優先する傾向がある
オフショア開発の魅力の１つにコーディングのスピードがありますが、仕事の進め方を聞いてみるとトライ＆エラーを繰り返して作り込んでいくメンバーが多かったです。
オフショアメンバーが不慣れなプログラム言語であっても、習得速度は早くどんどん作り込んでいきます。
しかし、正しく実装しているかは受入側が慎重に確認する必要があります。色々試したけど上手く動かなかったという理由で、基本設計の方針（例えばアーキテクチャ設計）とは違った独自の設計で対応することがあるからです。
コードレビューで検出できるものもありますが、コード量が多いと見落としてしまうケースがあります。他にも動作確認すると動いているように見えてしまうためレビューが甘くなることもあります。そのためプロジェクトが進んでいくと従来の設計と独自の設計で整合が取れなくなる処理が出てくることがあります。
修正するにも工程を遡らないと修正できない重篤なバグに繋がることがあり、品質を安定させるために多くの工数が必要になってしまいます。
対策
詳細設計書を日本側で作成する、作業指示書内容を充実する、リリースされたソースコードを細部までレビューする、など対応できることは多くありますが、現実的にはその工数に耐えられないことが多いです。
このような場合はすべてを一気に解決しようとしても無理があるため、優先度をつけて段階的に解決するように進めるのが良いと思います。
一例として軽微なバグには目をつむり、重篤なバグ検出を減らすために基本設計に沿っているかという観点のみ集中してレビューする、という対策が考えられます。
効果
基本設計以外のコードレビューは優先度を下げることになるため、バグの検出数が大きく減ることはないと思いますが、重篤なバグを減らすことでバグの再指摘の件数やデグレの発生が減り、バグの消化件数が伸びていきます。
また、レビューを通じて設計の理解も深まっていき、最終的にはオフショア側の内部レビューだけで基本設計からの逸脱を予防できるようになり、品質が安定していきます。
時間の経過とともに品質が向上していくため、その後の計画も立てやすくなるのではないでしょうか。
問題：影響範囲に対する認識の違い
オフショア開発をしていると商習慣や文化の違いに戸惑うことがあります。
例えば私がプログラマーとして活動していたときは、ある関数を変更する場合、その関数が使用されている処理すべてで問題ないことを確認していました。
それは誰かに指示されたりドキュメントに明記がなくてもすることと教育されていたため、プログラマーだったら当たり前の行為だと思い込んでいました。
そのため影響範囲が記載されていないドキュメントを見ても、影響範囲は調べればわかることなので気にすることはありませんでした。
オフショア開発は設計書と作業指示書をベースに作業を進めてもらうことが多いですが、影響範囲について言及しないと対応漏れに繋がり、修正を繰り返すことになってしまいます。
対策
「影響範囲を理解している日本側ですべての影響範囲を記載する」という対策も取れますが、オフショア開発を長い目で見ると問題を先送りしているだけで、次のオフショア開発でも同じ問題に直面することになるでしょう。
「影響範囲も確認するように指示する」といった意見が出ることもあります。しかし、日本人相手なら通用するかもしれませんが、オフショア開発だと指示が抽象的で上手く伝わらないケースが多いです。
「影響範囲を確認する」という依頼をする場合は、日本側が考えている影響範囲とは何か、どのようなプロセスを踏んだ結果なのか、こちらの想定や考えを含めて伝えるようにしましょう。
例えば、「この処理は他の機能でも共通で使用される」「他の機能の処理が変わらないことを確認する」「この処理の使用箇所を検索して、使用箇所すべて処理が変わっていないことを確認する」などです。
また、それらをチェックリスト形式で記載することにして、適切に実施されたのかをレビュー時に確認することを徹底すると、より良いと思います。
効果
検索の仕方まで明記するのは冗長かと思いましたが、こちらが何をしてほしいのか明確に理解できるとオフショアメンバーからは好評だったりします。
レビューを繰り返すなかで作業が定着していくものは、徐々に記載を省略できるようになりますが、チェックリストに沿って影響範囲を確認した上でリリースしてくれるようになり、品質が安定していきます。
このように作業プロセスを浸透させたり、育てていくことで品質の向上に繋がります。
さいごに
ITのプロジェクトはオフショアに限らず品質に関する問題が発生するものですが、オフショアではさらに「時差」「言葉」「商習慣」「文化」の違いがあるため、より多くの問題が発生します。
特に「情報が正確に伝わらない」ことに起因する問題に頭を悩ますことが多く、今回ご紹介した事例も情報の伝達や意思疎通がきちんとできていれば回避できたのではないかと考えています。
日本人は行間を読み解いて作業を進める傾向があるので、日本側で作成したドキュメントは情報が不足している、曖昧な表現が多い、主語／述語／目的語を省略している、など誤りや勘違いを生む内容になりやすいです。
私が設計書や作業指示書を作成するときに、2つ実践していたことがあります。
1つ目は「文章で表現せずに箇条書きにする」です。
これだけで主語／述語／目的語を省略し辛いのと、表現も簡潔なものになるため翻訳も容易になりました。
2つ目はレビューです。
このような表現の問題は作成している本人では気づきにくい事が多いため、第三者にレビューして貰うことを徹底していました。
繰り返しになりますが、ITのプロジェクトは品質に関する問題が必ず発生します。
品質の問題といっても多種多様で、改善策も一括りにこれというものはなく、日々頭を悩ませていますが、今後もプロダクト品質やプロセス品質、いずれの品質問題も適切なアプローチで解決できるクオリティマネージャーになれるように精進して参りたいと思います。
【サービス紹介】ドキュメントインスペクション ドキュメント品質にお困りのみなさまへ、第三者視点によるドキュメントレビューをサービスとして提供しています。 ■ドキュメントインスペクションのサービス紹介はこちら｜株式会社AGEST
