|
開発プロセス |
■ 発注元との緊密な協力関係 |
|
発注元が業務、仕様などもっと重要な所に専念できるよう、必要があれば、こちらの開発チームは技術的な問題、実装方法などを調査し提案できる。
|
|
発注元の意思(開発の優先順位、作業の流れなど)、仕様などを正確に理解し、迅速に開発メンバーに伝達し、浸透させる。 |
- 実装レベルでシステム設計および仕様の矛盾、不備などを早期に割り出し、発注元に正確に伝える。
|
- プロジェクトを遂行している間発生するすべての問題を誠実、迅速に発注元に報告する。
|
■ 進捗管理 |
|
発注元のマスタースケジュールに合わせ、できるだけゆとりを持つ現実的な開発スケジュールを細かく作成する。開発スケジュールに開発の各フェーズの目標と成果を明確に記述する。
|
|
開発スケジュールにより、作業内容を分担し、各メンバーに作業内容を明確にする。 |
|
チームリーダー、テスター、プログラマーの役割と責任範囲を明確する。 |
|
各チームは週二回の工程会議を開く。月曜日の朝一番の工程会議で各担当者に作業内容の徹底周知をする。金曜日の会議では進み具合をチェックし、問題点をピックアップする。開発上に問題がある場合、随時、チームメンバーとの対話によって、作業を調節し、問題を迅速に解決する。
|
|
毎週、開発の進み具合を進捗チャートに記入する。進捗チャートは開発チームにも、発注元にも、目に見える形で提示する。
|
■ レビューによって、問題を早めにフィードバックする。 |
- 仕様書理解のレビューにより、設計および仕様上の不備を早期に発見し、発注元に報告する。
|
- ソースのレビューにより、仕様書を元に実装しているかどうか、セキュアのシステムを実装しているかどうか、ソースコードの妥当性、可読性、コーディング規約に準拠しているかどうかなどの問題を早期に発見できる。
|
- フェーズごとに成果物のレビューにより、システムを動く形で検証できる。
|
- 開発スケジュールのレビューにより、開発スケジュール自体に問題を発見し、発注元に相談し、早期にマスタースケジュールを調節する。
|
- テスト企画のレビューにより、テスト手順、テスト内容は妥当か、テストケースは偏らず、網羅性のものになっているかチェックできる。
|
■ 開発に必要なリソースを確保する。 |
|
- グループで共同作業のためのネットワーク環境を用意する。
|
|
■ 質の高いプログラミングのための環境を作る。 |
|
ソースコードの妥当性、可読性、コーディング規約に準拠する質の高いソースを作成できる。
|
|
|
チームメンバー全員がどのシステムを開発しているか十分理解する必要がある。自分で書いたコードはどのようにシステムに影響を与えるか認識する必要がある。
|
|
モジュール化できるものはモジュール化し、部品化できるものは部品化し、チーム内またはチーム間で使う。効率よい作業法、新技術、作業テクニックなどは工程会議の場でみんなが交流し、チーム内、チーム間、日本チームと海外チームの間で共有する。
|
|
■ できるだけ速く |
- できるだけ速くシステムの基幹ルートを動くようにする。
|
システムの基幹ルートが動くと、システムの検証できる、また、各画面、サブ機能の実装メンバーが自分で作業している部分がシステムとの関係が分かるだけではなく、テストもしやすくなる。
|
|
テストデータがあれば、コーディングの間、実装メンバーが効率よく書いたコードをテストできる。
|
|
システムは発注元が予想しているシステムになっているかどうか早期検証できる。また、設計上の不備、仕様書の不備の改善に役立つ。
|