
開発現場の天国と地獄 第6回 page1 page2 page3
設計の落としどころ (後編)
〜J2EE金融基幹システムの構築現場から〜
オープントーン
佐藤 大輔
2005/11/2
前回から引き続き、プロジェクト5 「半年以下で金融基幹連携システムをJ2EEで構築」の事例レポートをお送りします。前回の最後でプロジェクトの実装フェーズに到達しました。後編である今回は、実装チームの運営方法から話を進めていきます。(@IT編集部)
◆ 大人数の実装チームを効率よく動かすための運営手法
◎ 定例会
多くのプロジェクトで定例会や朝会、夕会が開かれます。当初、このような例会をあえて行わず、そのことで何が起きるか様子を見ていたところ、意外に実装者から「仕事の終わりのメリハリが付きにくい」などの要望が出てきたため、行うようになりました。マネジメントの視点だけでなくメンバーの視点からもニーズがあるようです。
プロジェクト・マネージャの一声で朝会だけを行うことに決まりましたが、このときにさまざまな葛藤(かっとう)があったのも事実です。その理由は、
- 夕会の方が1日の動きを報告しやすい
- (朝が苦手)心の声
- 朝会の方が、プロジェクトが締まる
などです。皆さんはどう思われますか?
会の進め方はスタンドアップミーティング方式です。定例の時間を使って何時間もゆっくり話したい人はいません。15分をメドに行ったスタンドアップミーティングは良い効果があったと思います。
◎ プロジェクトの情報は全員に
- - PR -
しかし、やはりITアーキテクトやリーダーの一部はどうしても、「階層構造」としてのプロジェクト運営から離れられず、一部で問題が生じ始めました。「この件の担当は私なので私が知っていればよく、私と顧客で決めればいい」主義の台頭です。
私の方針は、全員参加のメーリングリストを作り、常にCCに入れて、プロジェクトでどんな情報が行き来しているかを皆が把握できるようにしておくというものです。いくつかの意味があります。
- 仕様などの情報を結局一番深く把握している実装者が常にチェックしていること
- その結果、仕様が変化し得るポイントやそのトリガを事前に知って用意することができる
- 情報の共有が進み「あの人がいないと分からない」状況を最小限にできる
- 自分にきちんと情報を与えられているというプロジェクト参加に対するモチベーションの問題
プロジェクトの運営において、参加者のモチベーションの問題が大きいと考えています。何の情報も相談もなく、ある日突然「納得のいかない仕様」を押し付けられることは、実装者、詳細設計者のモチベーションを大幅に下げることになります。あるいは、実はもっと楽に業務の目的を達する改変の方法があったかもしれません。
「どうして、こんなおかしな修正を徹夜でさせられているか分からない」という状況と「議論した結果、顧客の業務目標を達成するために必要と理解して、なんとか仕様を追加している」状況は大きく違うのです。モチベーションの高低を無視してプロジェクトの効率を議論できないのはご存じのとおりです。
|
1/3 |
|
INDEX |
||
| 開発現場の天国と地獄 |
||
| Page1 ◆ 大人数の実装チームを効率よく動かすための運営手法 |
||
| Page2 ◆ 層割と機能割 |
||
| Page3 ◆ 実際のプロジェクトの流れ |
||
| IT Architect 連載記事一覧 |
開発現場の天国と地獄
実際の開発プロジェクトを詳細に分析し、ソフトウェア開発プロジェクトを成功に導く要因あるいは失敗に陥る原因を探ります
- 第1回 “ 完璧な設計 ”がプロジェクトを失敗に導く!?
- 第2回 真のボトルネックは“ 顧客 ”なのか!?
- 第3回 ベテランならホントに安心なのか?
- 第4回 そして、システムはお蔵入りとなった
- 第5回 設計の落としどころ (前編)
- 第6回 設計の落としどころ(後編) 実装組のオペレーション
ホワイトペーパー(TechTargetジャパン)
|
|

