開発プロセス

■ 弊社のオフショア開発は「日本と海外」は単純に場所が離れたプロジェクトチームと認識している。

日本サイドで通常のオフショアより優秀な要員を多く配置することは、一見、コストが高くなる印象がありますが、実際は逆なのです。
優秀な人材によってプロジェクト全体をしっかりコントロールすることで、無駄な作業の軽減、トラブルの回避、納期の確保が確実に実現できますので、かえって大幅にコストが下がります。

■ システム開発の最初段階（提案、要件分析/定義、設計）と最終段階（システムテスト、システム運用以降）は日本サイドで行う。

日本の顧客からオフショアを意識しなくて、「オフショア」の価格で、「オンサイト」の品質を享受できる。
意思伝達、仕様伝達を円滑に行うことができる。
オフショア開発の商習慣、異文化の壁を越えられる。
日本型システム開発の特徴－仕様変更にも迅速に対応できる。
開発の全プロセスをコントロールできる。
システム稼動時のトラブルに迅速対処できる。
最高のサービスを顧客に提供できる。

■ 最も開発要員と費用が掛かる開発段階はオフショアで行う。

大幅な開発費削減を実現できる。
大規模のプロジェクトを対応できる。
スキルの高い開発要員を確保できる。

■ 発注元との緊密な協力関係

発注元に技術の側面からバックアップ。

発注元が業務、仕様などもっと重要な所に専念できるよう、必要があれば、こちらの開発チームは技術的な問題、実装方法などを調査し提案できる。

発注元の意思を正確、迅速に理解する。

発注元の意思（開発の優先順位、作業の流れなど）、仕様などを正確に理解し、迅速に開発メンバーに伝達し、浸透させる。

実装レベルでシステム設計および仕様の矛盾、不備などを早期に割り出し、発注元に正確に伝える。

プロジェクトを遂行している間発生するすべての問題を誠実、迅速に発注元に報告する。

■ 進捗管理

開発スケジュールの作成

発注元のマスタースケジュールに合わせ、できるだけゆとりを持つ現実的な開発スケジュールを細かく作成する。開発スケジュールに開発の各フェーズの目標と成果を明確に記述する。

作業内容の明確化

開発スケジュールにより、作業内容を分担し、各メンバーに作業内容を明確にする。

責任範囲の明確化

チームリーダー、テスター、プログラマーの役割と責任範囲を明確する。

工程会議制度

各チームは週二回の工程会議を開く。月曜日の朝一番の工程会議で各担当者に作業内容の徹底周知をする。金曜日の会議では進み具合をチェックし、問題点をピックアップする。開発上に問題がある場合、随時、チームメンバーとの対話によって、作業を調節し、問題を迅速に解決する。

進捗チャート

毎週、開発の進み具合を進捗チャートに記入する。進捗チャートは開発チームにも、発注元にも、目に見える形で提示する。

■ レビューによって、問題を早めにフィードバックする。

仕様書理解のレビューにより、設計および仕様上の不備を早期に発見し、発注元に報告する。

ソースのレビューにより、仕様書を元に実装しているかどうか、セキュアのシステムを実装しているかどうか、ソースコードの妥当性、可読性、コーディング規約に準拠しているかどうかなどの問題を早期に発見できる。

フェーズごとに成果物のレビューにより、システムを動く形で検証できる。

開発スケジュールのレビューにより、開発スケジュール自体に問題を発見し、発注元に相談し、早期にマスタースケジュールを調節する。

テスト企画のレビューにより、テスト手順、テスト内容は妥当か、テストケースは偏らず、網羅性のものになっているかチェックできる。

■ 開発に必要なリソースを確保する。

効率高い開発ツールを使用する。

グループで共同作業のためのネットワーク環境を用意する。

海外開発チームとの通信環境を確保する。

■ 質の高いプログラミングのための環境を作る。

コーディングの標準化

ソースコードの妥当性、可読性、コーディング規約に準拠する質の高いソースを作成できる。

バージョン管理ツールの使用

システム全体像の共有

チームメンバー全員がどのシステムを開発しているか十分理解する必要がある。自分で書いたコードはどのようにシステムに影響を与えるか認識する必要がある。

ノウハウの共有

モジュール化できるものはモジュール化し、部品化できるものは部品化し、チーム内またはチーム間で使う。効率よい作業法、新技術、作業テクニックなどは工程会議の場でみんなが交流し、チーム内、チーム間、日本チームと海外チームの間で共有する。

自動テスト

■ できるだけ速く

できるだけ速くシステムの基幹ルートを動くようにする。

システムの基幹ルートが動くと、システムの検証できる、また、各画面、サブ機能の実装メンバーが自分で作業している部分がシステムとの関係が分かるだけではなく、テストもしやすくなる。

できるだけ速くテストデータを用意する

テストデータがあれば、コーディングの間、実装メンバーが効率よく書いたコードをテストできる。

できるだけ速く動くシステムを発注元に動かせる

システムは発注元が予想しているシステムになっているかどうか早期検証できる。また、設計上の不備、仕様書の不備の改善に役立つ。