コレだけ準備すれば分散開発に失敗しない分散開発のABC(前編)(1/3 ページ)

» 2005年07月20日 12時00分 公開
[三橋和広,株式会社オープントーン]

分散開発はまだリスクが高い

 最近、多くの開発現場で海外を含めた分散開発の話を耳にするようになりました。筆者の周りでは、特に中国やインドをはじめとするアジアの事例を非常に多く聞くようになりました。しかし、あまり多くの成功事例を耳にしないのもまた事実です。これはやはり、まだこのビジネスモデル自体が成熟しておらず、手法などが手探り状態であることが最大の原因だと思われます。つまり、「分散開発では何をしたらいいのか? どんな手法を用いればいいのか? 何に気を付ければうまくいくのか?」といった要素がまだまだ見えておらず、いわば地雷原の先頭を歩いているような状態であるといえます。よって、分散環境での開発というのは、まだまだリスクの高い開発の体制であるといわざるを得ないようです。

 そこで今回は、われわれが体験した分散開発事例のノウハウをできるだけ多くの読者(開発企業)に見てもらうことによって、「どの辺りに地雷があるのか」をぜひ学び取っていただければと思っています。なお、今回紹介する事例(中規模の国内分散開発プロジェクト)は、納品・稼働を無事に済ませることができました。この案件を実例として示し、効果的だった手法を紹介したいと思います。

分散開発の検討ポイント

  • アーキテクチャの選定と分散開発
  • 分散開発における要件定義から詳細設計までの手法と粒度
  • プロジェクトの運営と分散開発
  • チーム運営と役割分担の実際

本案件の概要

 この案件は、BtoCサイトの管理画面と基幹への連携を行うシステムでした。

ALT 図1 BtoCサイトの管理画面と基幹への連携を行うシステム

 主な要件は「カタログショッピング方式の業務を改善すること。カタログの機能をWebサイトで補完すると同時に、購入処理もできるシステムの構築」でした。ただし、電子決済などは行わず、バックエンド的な処理は、基幹システムとの連携で行う方式でした。システム自体はよくあるものです。問題は開発体制にありました。

分散開発体制

 開発体制を一言でいうと「日本全国に散らばったかなり入り組んだ体制」です。具体的に述べますと、福岡県、東京都、福島県にまたがる各社が月に数度の打ち合わせを頼りに開発を行う体制です。福岡県の顧客のシステムを東京都の会社が請け、実装を東京都と福島県の会社が分散して行い、東京都のわれわれの会社がWebシステムの開発を担当しました。結論からいうと、このシステム構築案件は作業者の負担が少なかった……とはいい難いですが、少なくともスケジュールに沿った納品稼働ができた事例となりました。

ALT 図2 日本全国に散らばったかなり入り組んだ体制

スケジュール

 最近のシステム開発案件は、対象が基幹システムであっても、長い開発期間を与えられないケースが非常に多くなっています。今回の事例もご多分に漏れず、でした。設計からリリースまでの期間はわずか6カ月間です。スケジュール上、着手時点ですでに1カ月強程度の遅延が発生しており、このリカバリーを考慮しながらのスケジュール作成が必要でした。

  以下のスケジュールはおおむね、どんなマイルストーンがあるかをほぼ網羅していますので「何をしなければいけないか」を示した表ともいえます。このスケジュールを見て、おそらく皆さんは「いつものシステム開発と変わらない」という感想をお持ちになると思います。そうです。「遠隔という特殊な状況下でいかに、“いつもどおり”の開発作業を行うか」が分散開発を成功させるための要因なのです。

表1 スケジュール
1カ月目 概要設計 画面設計書
画面遷移図
ユーティリティ候補の抽出
アーキテクチャ検討
フレームワーク検討
2カ月目 開発準備 アーキテクチャ決定
ユーティリティクラスの作成
フレームワーク構築
詳細設計
開発着手
3カ月目 詳細設計 得意先サイト開発
基幹連携仕様決定
基幹連携開発
4カ月目 得意先サイト開発 一般サイト開発
Web元請 結合テスト
基幹連携テスト
5カ月目 Web元請 結合テスト 納品ドキュメント作成
6カ月目 エンドユーザー 受け入れテスト  
7カ月目 リリース  

 ではいよいよ、「本案件の概要」で述べた機能を「分散開発体制」で、どのように「スケジュール」どおりに仕上げていったのか、そしてどんな手法を用いたのかを述べていきます。

       1|2|3 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ