オフショアなんて、怖くない:システム開発プロジェクトの現場から(11)(2/2 ページ)
開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。
日本での開発はなくならない
ですが、プロジェクトを進めていく中で気付いたのです。日本で開発をする機会が失われることなどないということに。
事実、このプロジェクトでは、アプリケーションのアーキテクチャとなる部分や汎用的に使用する共通クラスのようなものは日本であらかじめ作成しておき、その後オフショアに展開しました。プロトタイプの作成も日本で行いました。技術的な課題についても、きちんと日本で検証を行い、実装可能な状態まで持っていきました。
例えば、帳票をJavaのWebアプリケーションでMicrosoft Wordのファイルにするという仕様がありました。Apache POIなどを検証した結果、Microsoft Office 2003からXML形式でドキュメントを保存できることに着眼し、帳票フォームをXSLで作成してDOMでXML形式のWordドキュメントを生成するという方法に決定しました。そしてアーキテクチャとして組み込み、オフショアに展開・量産しました。
このように、アプリケーションのコアとなる部分については日本でプログラミングを行うので、オンショア側にはより高度な技術力が求められます。プロジェクト全体の開発効率を上げたり、品質を高めたり、運用効率を上げたりする、そういう部分の責任はオンショアがきちんと持つ必要があるのです。このプロジェクトを経験したことで、私はオフショア開発の1つの形というものが見えた気がしました。
また、このプロジェクトでは、開始時期の遅いサブシステムについては新入社員数人をプログラマとするチームで開発を行っていました。こういった取り組み1つで、若手の育成もできるのだと感じました。
オフショア開発をするには、やはりそれなりの準備期間が必要であるということも実感しました。そうであれば、例えばアジャイル開発のようなプロジェクトにはオフショアは向いていないのではないでしょうか。やはり、日本で開発する機会がなくなるなんてことはありませんね。そう思えるようになったのも、大きな収穫です。
中国人エンジニアは怒ってる?
このオフショア開発を通して、ほかにもいろいろな経験をすることができました。人生で初めて「海外出張」というものを経験しました。ホテルからオフィスまでタクシーで行きましたが、日本ではあまり経験することのないアグレッシブな運転でした。
現地での説明は通訳を介して実施したのですが、初めのうち中国語でのやりとりではみんな怒っているように見えて、少しひるみました。「な、なんで怒ってるんだ?」と。慣れてみれば「そういうものなんだ」と分かりましたが……。
設計書は、日本語のままでほぼOKでした。漢字は意味が似ているものも多いですし、中国のメンバーは日本語の勉強もしてくれていたので。ただしカタカナは難しいようです。それ以来、私は設計書にはカタカナを書かないよう気を付けるようになりました。それから日本語の音読み・訓読みの区別も相当難しいらしいです。
オフショアのメンバーは、みんなとてもいい人たちでした。オフショア開発であろうとなんだろうと、システムって人が作っているんだなぁということを実感しました。
よく「オフショアを使う」という表現を見掛けます。「使う」という意識がどこかに残っていると、問題が起こったときに責任を押し付けたくなるような気がします。場所が離れていようとも、国が違っていようとも、仲間として認め、尊敬し合う。そうでないとオフショア開発はうまくいかないのではないのでしょうか。
オフショアなんて怖くない
オフショアについてはいろいろな場所で語られていますが、「品質が……」「コミュニケーションが……」「文化の違いが……」といった内容が多いように思います。オフショアの認知度が上がっている一方で、現場ではマイナスのイメージが大きいという印象を受けていました。ですので、少し違った視点からオフショア開発を紹介してみました。
私はこのプロジェクトの後に、ニアショア(ATSが北海道に立ち上げた国内開発拠点)との協業も経験しました。これらの経験を通して、日本と中国の開発手法だけでなく、リモートとの連動方法なども学ぶことができました。今後はそこで経験したことにさらに磨きをかけ、次のプロジェクトをより良いものにしていけたらと思います。
皆さんも、「オフショア」というだけで恐怖心を持たず、機会があればぜひチャレンジしてみてください。勉強になること請け合いです。
筆者紹介
新楽清高
1973年生まれ。東京生まれの東京育ち。大学で都市計画を専攻後、社員100人ほどのシステムインテグレータにてSEとしてセールス〜要件定義〜開発・テスト〜運用までを行う。その後2003年11月にアクセンチュア・テクノロジー・ソリューションズに入社。Java、.NET、SAPにて大規模な基幹システムの構築に携わり、現在に至る。基本ポリシーは「楽しく」。趣味はトラブル対応。
- 文書ドリブン開発 テスト文書編
- 文書ドリブン開発 詳細設計文書編
- 文書ドリブン開発 DB設計文書編
- 基本設計文書の質を下げる「4つの心理バイアス」
- 本当は楽しいドキュメント作成
- 新人(3年目)、プロジェクトで「忍耐」を学ぶ
- 新人、集合研修で「伝説」を作る
- 新人(3年目)、先輩デビューで「最悪の振る舞い」
- 新人、アーキテクチャチームで「運命の出会い」
- 1人チームで悩む新人。「この作業って意味あるの?」
- 現場デビューのお供はビジュアル多用の報告書
- 大規模プロジェクトでは「同じ言葉を、同じ意味で」
- 「バッファ込み」の工数がスケジュール遅延の原因
- 運用って、あまりいいイメージはなかったけれど
- 最強チームで挑んだ、「40時間でデータ移行」の壁
- 障害対応とチューニングの危うい関係
- オフショアなんて、怖くない
- 3プロジェクト同時にリード! どう乗り切る?
- この案件、ぜひ新しいテクノロジでやりましょう!
- 初めてのトラブル対応。これで直ると思ったのに!
- 「できるか!」な設計書に、どう立ち向かう?
- 専門用語で「カッコよく」話すのは簡単だけど
- メンバーとの仕様打ち合わせは海を越えて
- 定まらない要件、ユーザーからのむちゃな要求
- 未経験のデータベース構築に挑戦
- セットアップ全国行脚で九州弁に大苦戦
- 試行錯誤で分かったスパゲッティコード撃退法
Copyright © ITmedia, Inc. All Rights Reserved.