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

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

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

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

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

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

• 開発スケジュールの作成

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

• 作業内容の明確化

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

• 責任範囲の明確化

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

• 工程会議制度

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

• 進捗チャート

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

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

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

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

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

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

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

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

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

• コーディングの標準化

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

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

• システム全体像の共有

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

• ノウハウの共有

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

• 自動テスト

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

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

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

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

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

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