アジャイルでオフショア開発 その1
僕はシンガポールの現地企業、つまり日系企業でもなく欧米系企業でもない地元企業で、システム開発の仕事をしている、多分かなり珍しい日本人だ。僕が開発しているのは、ある種の金融関係のサービスを行うサーバだ。マーケットは、現在アジア中に広げようと画策してはいるが、今のところは人口がたかだか500万程度のシンガポール。500万といっても、1人当たりのGDPは今や世界トップレベルの国なので、それなりの売り上げはあるのだが、やはり世界をマーケットにしている米系のweb企業や、日本をマーケットにしている日本のweb企業と比較するとどうしても規模は小さくなる。結果、デベロッパーに支払われる給与は低く抑えられていることになる。また、ここへの投稿で何度も書いているように、シンガポールは少なくとも仕事の世界では英語圏で、かつスキルを持つ人への労働ビザは比較的楽に発行される国だ。そのため、東南アジアの周りの国から安い給与で開発の仕事を請け負うエンジニアの流入も多く、給与が低く抑えられている。
僕がいまもらっている給与もかなり低く抑えられており、ここシンガポールの日本より高い（東京都心と同じレベルぐらい？）家賃と組み合わせて、毎月の貯金がほとんどできないような感じだ。
そんな風にコストを少しでも多く抑えることが、そのまま企業としての生存にかかわるような環境で、経営者、もしくは経営に関与するレベルでかつあまり開発のことを知らないプロマネが考えることは、そう、開発を賃金の安い周りの東南アジアの国に委託すること。つまりオフショア開発になる。
彼らが簡単にそう考えるのは、複雑に絡みあう多数のサブシステムから構成されるシステムの開発を、例えば、積み木を積み上げていくようなイメージで達成できると思っているからだろう。もちろん、SOAなどという複数のサブシステムを組み合わせて、システムを創り上げていくソフトウェアの開発のフレームワークが世の中にある。それをうまく利用すれば彼らが思うイメージに近いことが実現できるかもしれない。しかし、それにはSOAを使いこなせる高度な技術を持った技術者が必要なことを忘れてはならない。僕自身それを習得すれば、もっと高い給与を払ってくれる、例えば欧米系の会社に移れるかもしれないと努力している途上で、とてもSOAのプロと呼べるレベルには達していない。今のところはSOAを実践として経験できる場所として、今の現場を利用しようと思っているが……。
さて、僕に課せられた仕事はどんどん増える開発案件。それに当たれるオンサイト開発者は僕以外増やせない。しかし、必要ならバングラデッシュやスリランカ、ベトナムのフリーランスの開発者に開発を依頼できると言われ、渋々、外部の開発者を増やすことになり、気付いたら、知らぬ間に僕を中心にしたASEAN software 開発デリバリーのネットワークができてしまった。
日本で、オフショア開発はかなり行われる時代になっていると思うが、多分まだウォーターフォールで、ドキュメントでがんじがらめにした形で海外のリソースに開発を依頼する形が主流だと思う。しかも依頼先はちゃんとしたシステム開発会社。また、日本のいわゆるweb企業で、オフショア開発を使っているところは、多分まだそれほどないと思う。そういうところは、開発のスピードが半端でないので、ドキュメントなどを作る隙がなくて、開発者は、要件をプロダクトマネージャから直接口頭で聞いて開発することが、基本になっているだろうから。
そういうことで、僕みたいな開発をしている日本の現場はそれほどないと思うが、世の中にはそんな開発もあるということを分かってもらうため、これから何回かに分けて、僕の開発について投稿することにする。初回は、オンサイト側のエンジニアに必須の能力について書く。
利用技術のすべてに精通したオンサイト技術者は必須
（1）まずは、少なくとも1人は、オンサイトに技術者が必要。技術者とここで書いたが、開発に利用する技術のすべてに精通していることが必須。必要とあれば、バグ対策や小さな変更をオンサイトの技術者ができる状態にあることは必須。しかし、既存のシステムに対して変更を入れることは、ある程度の経験を持った技術者なら、それがまったく知らない技術で作られたものであろうと、少し時間はかかるが可能だ。ここで言っているのは、利用する技術を使ったレファレンス実装、それと同時にフレームワークを作れるレベルの技術者ということ。
普通日本でオフショア開発をするとして、オンサイト側技術者に要求される技術は要件定義、そして基本設計程度まで。詳細設計までが要求されることはない。ところが、アジャイルではどうしても、実装を理解できるオンサイト技術者が必要。その技術は、バグ対策や細かい変更を即断即決で行うためというよりは、プログラムの基本構造つまり、アーキテクチャを決定する必要があるから。そして、その構造を作るときに重視することは、プログラム構造の可視化を強制できる仕組み。
例えば、オフショアに実装させて、できたものをチェックするとき、実際に動作させてテストするのではなく、出来上がったソースコードを一瞬見た程度で、意図したものと一致しているかを確認できるレベルの可視化が必要。アジャイルの現場で、少なくともコード納品直後のチェックで、実際に動作させて、いちいち細かい条件を作ってテストする隙はない。
一番簡単な例を挙げると、ユーザー入力のバリデーションチェック。そのチェックを実際にアプリを動作させてテストするのではなく、コードを見て判定する。それを一瞬で行うためには、バリデーションチェックの実装アーキテクチャをあらかじめ指示して置く必要がある。
ウォーターフォールのオフショアでは、バリデーションチェックのすべてのチェック内容を事細かにドキュメントに記述することになるが、アジャイルではそんなことをやっている隙はないので、開発者の自主性に任せて、バリデーションチェックを入れさせることになる。そのためにも、コードの可視化は重要。