オフショア開発でスピードを出せるよう、発注側ができる工夫

2014年1月3日

最近のソフトウェア開発では、もの凄くスピードが求められます。

昔は３ヶ月〜１年間の開発が常識でしたが、今は１ヶ月、そして１−２週間単位の仕事が求められます。

このスピードを実現させるためには、請ける側のみならず、発注する側も仕事のスタイルを変えないといけません。

弊社は数多くの工夫と失敗を重ね、やって数週間サイクルの開発の成功率を高めることが出来ました。
この工夫のいくつかを共有させて頂きたいと思います。

1) 急げば良い訳ではない。開発リズム（規則性）を作ることが大事。

「時間が無い」「急がなくちゃ」と発注側が心配し、朝から晩まで、何か思いついたらすぐにチャットや電話で開発担当者を呼び出し、細かい質問や仕様確認などをしたりすることがよくあります。

問題なのは、やりとりの頻度ではなく、呼び出しタイミングの不規則性です。

開発者がまともなプログラムを書くには、最低でも３−４時間ずっと集中できる時間が必要です。
１時間ほど仕様を頭に入れて、１時間ぐらいで頭の中で作るべき物を想像し、そこから１−２時間ぐらいにぱっとプログラムに書き上げます。
その間に呼び出されると、それまでに頭の中に整理できた情報が全部ふっ飛ばされます。

この状況が繰り返されれば、開発者が全体設計を考える余裕が無く、ただ言われることをひたすらプログラムの中にパッチを与え、最終的に矛盾だらけのソフトウェアが出来上がり、いつまでも終わらない開発となってしまいます。

弊社では、チャットも電話も、必ず時間帯は事前に決めております。
「午後１時と５時に情報交換しましょう」という意味より、
「２時から５時までの間は絶対邪魔しないので、安心して取り組んで下さい」という意味の方が大きかったです。

ただし、開発者がダラダラしたり、どうでも良いことにハマったりして、開発効率が悪くなることがあるので、
定期的に４−６時間ほどで声をかけ、思考をリフレッシュさせる必要もあります。

このサイクルを規則正しく回せば、「頑張っているのに、気持ちいい！」という感覚が生まれ、結果的に一番早くゴールに到着できると考えております。

２）二重報告を避ける。

昔、仕事を出す側の私がよく、日報のみならず週報も開発チームに提出の要求をしていました。
その上に、「何かあったら、すぐメールで報告」とも要求していました。
進捗のことが心配していたからです。

でも、逆効果のことが起こりました。
問題が上がっても、担当者がすぐその日に報告せず、あえて週報のタイミングに遅らせました。
「ネタが無くなると週報を書けないから」ですって。

そして、日の終わりに出された日報には、「メールですぐくれれば、１５分で解決できたのに」のネタばかりです。
これはまた、「ネタを取っておく」という現象です。

このような重複報告は、あえて課題の早期発見・解決を遅らせることに気づきました。

それ以来、社内では日報と週報を廃止し、Redmineなどの課題管理システムでリアルタイムに課題・進捗を管理することにしました。
もともと、日報や週報に頼った時点で、課題解決サイクルを１日以下に短縮できません。

課題管理システムを導入し、いつでも課題の状況を確認できるようにするのは、開発スピード向上の必須条件です。

３）発注側が手伝えるとしたら

開発は、受注側が責任をもって全部こなすのは普通ですが、発注側が手伝いたいことだってあります。
もともと厳しい期間であったり、途中でトラブルが起こったり、仕様変更があったりする際、発注側が受注側と一緒になって必死にプロジェクトを成功させようとすることがよくあります。

どうしても開発チームを手伝わないといけなかった経験から、色々な手伝い方の効果をまとめてみました。

–
「逆効果」

    • 「状況どうですか、どうですか」の催促、必要以上の確認。
      必要以上の確認や催促は、開発者の集中力を下げてしまう危険性があります。
    • 仕様が伝わらないと恐れて、念押しのため、仕様書以外のところでメールやチャットで補足説明をする。
      補足説明の内容が仕様書の内容と同じであるかどうかを判断するだけでも、開発者がかなりの時間を使わないといけません。
      補足説明が仕様書の内容と同じなら、時間の無駄です。
      内容が少し違ったら、「本当の仕様はどこにも無い」という事態に繋がります。

–
「あまり効果無かった」

    • 実際のコーディング参加
      一時的に実装の完成が早くなるかもしれませんが、発注側の作ったソースコードを受注側がメンテできず、バグ修正段階に入ると時間がかかります。
    • 実装が終わっていない段系のバグ報告
      実装が終わっていない段階で報告されたバグは、ほぼ開発者の想定内で、実装が終わったら自動的に消えることが多い。
      実装に追い込まれた開発者は、早期のバグ報告を真剣に見ることが少ないのです。

–
「効果あり」

    • 情報の調査・整理
      特定のサービスに写真を投稿するのに、ベトナムエンジニアたちが２００ページの日本語API仕様書を渡されたことがあります。
      実際に使うのは2-3ページ程度ですが、それを特定するのに２−３日かかりました。ベトナムのエンジニアが日本語の資料を消化するのに、時間がかかります。
      その調査、またはAPI制作元との確認で手伝えると、一気に時間短縮ができます。
    • データベース設計のレビュー
      意図したデータ項目がデータベースにあるかどうかを確認するだけでも、大半の仕様漏れ・誤認識を防ぐことができます。
    • システムテストの手伝い
      オフショア開発はシステムテストが弱いです。
      海の向こうの人達は日本人のパソコン環境、操作の習慣、業務の背景を理解するのに限界があります。テスト観点が不十分で、バグを早めに発見できず、品質が安定するまで時間がかかってしまうことがよくあります。技術がわかれば、システムテスト仕様書をレビューし、足りないテスト観点を指摘できればベストです。
      技術が分からなくても、ユーザ目線で出来上がったソフトウェアを使いこなせば、品質安定期間を短縮することに貢献ができます。