2015.06.02

水と油?アジャイルとオフショア開発

皆様はじめまして。アジャイル&オフショア開発を推進している 佐々木です。エンタープライズ向けクラウドサービスのIDaaSであるKDDI Business IDの開発メンバーであり、JJUG CCCにて本システムのアーキテクチャについて講演などを行っております。また、KDDI Business IDでは昨年夏よりオフショア開発を採用しており、私自身もオフショア担当として邁進している日々を過ごしております。本日は、これからオフショア開発を検討している方に向けて、先日のAgile Japan 2015にてお話をした我々がこれまで取り組んできた事とその改善内容についてお話します。

「オフショア」 世間的な動向

図2

出典:矢野経済研究所 グローバルアウトソーシング市場に関する調査結果 2014

開発部を率いる企業のマネージャー層の方であれば、開発コストの削減を目的として一度は耳にされたことがあるのではないでしょうか?上記の文献によると、2012 年度から 2017 年度までの日本国内向けオフショアサービス市場は、年平均成長率2.9%で推移し、これからも市場は拡大傾向になるとの予測を発表しています。

目指している姿とは?

KDDI Business IDでは開発コストの低減化の目的以外に、オフショア開発を通じてグローバルベストな製品・技術の追求を考えています。日本の企画担当者・開発者のみで製品を開発するのではなく、グローバルな視点で本当に利用しやすいGUIなのか?また、受発注の関係にならず開発者同士もお互いに切磋琢磨する、そんな関係を持つチームを目指しています。そのために我々はアジャイル開発のスクラムを採用し、日本とベトナムで一つのチームとなり、オフショア先からも製品、技術の提案をもらい、共に磨き上げていくことを目指しました。

しかし一方で懸念点も。Agile とオフショアは「水と油」?

オフショア実例などを調べていくと細かく要件定義書を作成する必要があるとの記載をよく見かけます。日本と異なる点として、日本人はハイコンテクスト、いわゆる行間を読む民族ですが、世界的にみてそれは稀のようで、大抵はローコンテクスト、すなわち要件定義書に記載がある項目については実施をするが、それ以外は行わないために詳細な記載が必要になります。あらかじめ要件定義、設計を行うウォーターフォールであれば向いているかもしれないが、果たしてとアジャイルとオフショアは相交わるのだろうか?という懸念が大きくありました。

やってみて苦労したこと —言語、文化の壁

では、アジャイルを採用したオフショア開発で実際に苦労した点について紹介します。KDDI Business IDでは日本、ベトナムともに同じソースコードで開発をしています。オフショア成果物の初回リリース、日本のコードとベトナムのコードをマージする前に日本側でレビューを行ったのですが、レビューコメントが300以上発生する結果となりました。その中には色々な問題を含んでいたのですが、言語や文化の壁により要件が正しく伝わっていないことが大きな要因でした。

改善の連続

取組みその1:チケットの記載方法のオフショア向け最適化
チケット管理にAtlassian社のJiraを利用していますが、このチケットの記載方法をオフショア向けにカスタマイズしました。具体的に日本ではチケットに実施したいことを記載し、エンジニアがPO(プロダクトオーナー)と密に連携を取り、そのチケットで実現すべき範囲を明確化するとともに、開発側からGUIを提案するといった取り組みを行っていましたが、この方法はPOとの距離が近く頻繁にコミュニケーションが取れないと実現しない方法です。そこで以下のようにチケットの記載方法を変更しました。

  • 受入条件の記載
  • 未決定事項と提案要求事項の明確化
  • ストーリーの背景、理由の記載

図3

取組みその2:ユースケース図を活用した全体像の説明
先に紹介したチケットの記載を工夫することによりチケット単位での認識の齟齬は減りましたが、チケットの繋がりや全体像の説明が言葉だけでは難しく、1日がかりでスクラムイベントを行うような日もありました。そこで共通言語としてUML(ユースケース図)を採用し、「誰がどんな機能を利用し、何をするのか」を説明するようにしました。これによって説明時間が短縮され、今では3時間程度のスクラムイベントで要件を伝えることが可能になりました。

取組みその3:テストファーストとレビューによる仕様の認識合わせ
図4

これらの取組みよって要件理解は進みましたが、機能の詳細な認識齟齬を防ぐにはこれだけでは足りませんでした。そこで従来よりTDD(テスト駆動開発)を採用していましたが、コードの開発のみだけではなく、結合試験のテストを先に作成し、それを日本側がレビューすることによって機能の詳細な振る舞いについても認識齟齬を防ぐように致しました。

取組みその4:コードレベルの品質と定量化
上記の取り組みや、毎週の振り返りと改善によって要件理解は改善していきました。しかしながら日本の受入試験を行うと、細かなバグやデグレードが発生するようになりました。こちらも複数の要因がありますが、複雑なコードというのも一つの原因でした。そこでSonar Qubeというコードの静的解析を行うツールを利用し、実際に測定すると日本チームの倍近い複雑度となっていました。原因についてヒアリングをしてみると、オフショア先のメンバーは動くものができているため問題視もしてなかったとのことでした。これまでコードレビューの都度、簡潔なコードを書くようコメントをしていたのですが、定量化した解析結果を開示し、コードがどのような状態であるべきかを共有することにより、開発メンバーから改善意見が上がるようになりました。定量化は異なる文化でも同じ目標に向かう重要な手段であるとも気づかされました。

最後に

図5

これまでご紹介した通り、KDDI Business IDのオフショアではプロセスの振り返りを重ねることによって改善を続けてきました。これはアジャイルの原則に則ったプロセスであったとも言えます。今回ご紹介した内容はウォーターフォール型の開発や日本国内の開発でも活用できる改善ですが、短い周期で振り返りを行い、改善を繰り返すアジャイル開発とオフショアは水と油ではなく、むしろ相性のあった組み合わせでした。これまでは開発におけるプロセス改善に注力してきましたが、これからは当初かかげた目標である一体となって製品・技術を磨き上げチームとなれるよう改善を繰り返していきます。

カテゴリ
タグ

KDDI株式会社 プラットフォーム開発本部
アジャイル開発センター

佐々木 徹

新着記事
タグ
アーカイブ
カテゴリー
Contact
TOP