設計の落としどころ （後編）〜J2EE金融基幹システムの構築現場から〜：開発現場の天国と地獄（6）（1/3 ページ）

　前回から引き続き、プロジェクト5 「半年以下で金融基幹連携システムをJ2EEで構築」の事例レポートをお送りします。前回の最後でプロジェクトの実装フェーズに到達しました。後編である今回は、実装チームの運営方法から話を進めていきます。（＠IT編集部）

[佐藤大輔，オープントーン]

大人数の実装チームを効率よく動かすための運営手法

定例会

　多くのプロジェクトで定例会や朝会、夕会が開かれます。当初、このような例会をあえて行わず、そのことで何が起きるか様子を見ていたところ、意外に実装者から「仕事の終わりのメリハリが付きにくい」などの要望が出てきたため、行うようになりました。マネジメントの視点だけでなくメンバーの視点からもニーズがあるようです。

　プロジェクト・マネージャの一声で朝会だけを行うことに決まりましたが、このときにさまざまな葛藤（かっとう）があったのも事実です。その理由は、

• 夕会の方が1日の動きを報告しやすい
• （朝が苦手）心の声
• 朝会の方が、プロジェクトが締まる

などです。皆さんはどう思われますか？

　会の進め方はスタンドアップミーティング方式です。定例の時間を使って何時間もゆっくり話したい人はいません。15分をメドに行ったスタンドアップミーティングは良い効果があったと思います。

プロジェクトの情報は全員に

　プロジェクト運用にはWikiを使いました。Wikiにはプロジェクトの情報を何でも載せました。私がプロジェクトを運営するときの方針の1つとして「無駄なことだと思っても皆に知らせておく」というものがあります。セキュリティに問題がない範囲でプロジェクトメンバー全体に情報を行き渡らせておくというのは、スムーズなプロジェクト運営を行ううえで非常に効果があります。

　しかし、やはりITアーキテクトやリーダーの一部はどうしても、「階層構造」としてのプロジェクト運営から離れられず、一部で問題が生じ始めました。「この件の担当は私なので私が知っていればよく、私と顧客で決めればいい」主義の台頭です。

　私の方針は、全員参加のメーリングリストを作り、常にCCに入れて、プロジェクトでどんな情報が行き来しているかを皆が把握できるようにしておくというものです。いくつかの意味があります。

• 仕様などの情報を結局一番深く把握している実装者が常にチェックしていること
• その結果、仕様が変化し得るポイントやそのトリガを事前に知って用意することができる
• 情報の共有が進み「あの人がいないと分からない」状況を最小限にできる
• 自分にきちんと情報を与えられているというプロジェクト参加に対するモチベーションの問題

　プロジェクトの運営において、参加者のモチベーションの問題が大きいと考えています。何の情報も相談もなく、ある日突然「納得のいかない仕様」を押し付けられることは、実装者、詳細設計者のモチベーションを大幅に下げることになります。あるいは、実はもっと楽に業務の目的を達する改変の方法があったかもしれません。

　「どうして、こんなおかしな修正を徹夜でさせられているか分からない」という状況と「議論した結果、顧客の業務目標を達成するために必要と理解して、なんとか仕様を追加している」状況は大きく違うのです。モチベーションの高低を無視してプロジェクトの効率を議論できないのはご存じのとおりです。