「半年以下で金融基幹連携システムをJ2EEで構築」の事例レポートをお送りします。前回の最後でプロジェクトの実装フェーズに到達しました。後編である今回は、実装チームの運営方法から話を進めていきます。くのプロジェクトで定例会や朝会、夕会が開かれます。当初、このような例会をあえて行わず、そのことで何が起きるか様子を見ていたところ、意外に実装者から「仕事の終わりのメリハリが付きにくい」などの要望が出てきたため、行うようになりました。マネジメントの視点だけでなくメンバーの視点からもニーズがあるようです。プロジェクト・マネージャの一声で朝会だけを行うことに決まりましたが、このときにさまざまな葛藤(かっとう)があったのも事実です。朝会の方が、プロジェクトが締まるなどです。皆さんはどう思われますか?会の進め方はスタンドアップミーティング方式です。定例の時間を使って何時間もゆっくり話したい人はいません。15分をメドに行ったスタンドアップミーティングは良い効果があったと思います。プロジェクトの情報は全員にプロジェクト運用にはWikiを使いました。Wikiにはプロジェクトの情報を何でも載せました。私がプロジェクトを運営するときの方針の1つとして「無駄なことだと思っても皆に知らせておく」というものがあります。セキュリティに問題がない範囲でプロジェクトメンバー全体に情報を行き渡らせておくというのは、スムーズなプロジェクト運営を行ううえで非常に効果があります。ITアーキテクトやリーダーの一部はどうしても、「階層構造」としてのプロジェクト運営から離れられず、一部で問題が生じ始めました。「この件の担当は私なので私が知っていればよく、私と顧客で決めればいい」主義の台頭です。私の方針は、全員参加のメーリングリストを作り、常にCCに入れて、プロジェクトでどんな情報が行き来しているかを皆が把握できるようにしておくというものです。いくつかの意味があります。仕様などの情報を結局一番深く把握している実装者が常にチェックしていることその結果、仕様が変化し得るポイントやそのトリガを事前に知って用意することができる情報の共有が進み「あの人がいないと分からない」状況を最小限にできる自分にきちんと情報を与えられているというプロジェクト参加に対するモチベーションの問題プロジェクトの運営において、参加者のモチベーションの問題が大きいと考えています。モチベーションを大幅に下げることになります。実はもっと楽に業務の目的を達する改変の方法があったかもしれません。「どうして、こんなおかしな修正を徹夜でさせられているか分からない」という状況と「議論した結果、顧客の業務目標を達成するために必要と理解して、なんとか仕様を追加している」状況は大きく違うのです。モチベーションの高低を無視してプロジェクトの効率を議論できないのはご存じのとおりです。広告に関するお問い合わせメールマガジンSpecialインデックスRSSfacebooktwitter利用規約ITmediaはアイティメディア株式会社の登録商標です。