一致団結？ 一蓮托生？
〜混成開発チームの悲喜こもごも
文：株式会社ビーブレイクシステムズ

鹿取裕樹

IT業界はゼネコンと構造が似ている

じり、開発側にも複数階層の発注者−ンドユーザーであり、そのグループ全と言われることがある。それは元請け受注者の関係が存在する複雑な状態と体に対して福利厚生サービスを提供すとその下に幾重にも連なる下請け会社なっている。

るシステムの構築が目的である（図1）。

からなる構造に由来する。エンドユー

今回は、こうした現場の実際をお伝サービスは、保養所や各種チケットのザーから受注して元請けとなるのは膨えしたい。

申し込み、携帯電話の貸し出しなどが大な数の企業のうちのほんの一握りで■あり、それらの利用料を給与から控除あり、そのほかはそれらの下請けとし■プロジェクトの概要
プロジェクトの概要するという機能を有する。このシステて技術者を派遣することが主な事業と■ムは、グループ十数社が使用すること今回の舞台となるプロジェクトの概なっているのだ。
このため、ほとんどのプロジェクトの現場は複数の企業の技術者が入り混要を紹介しておこう。
本プロジェクトは大手製造業者がエになっていた。
アプリケーションサーバ、DB サー
バともにOSはLinuxで、サーブレットコンテナには Tomcat、RDBMS にはOracleが採用された。また、フレームシステム概要

ワークとしてStrutsを用いている。このシステムに、全国のグループ企業の社員がイントラネット経由でWebブラウザによってアクセスする（図2）。

イントラネット

福利厚生システム

私がこのプロジェクトに参画したのは要件定義が終わり、実装に入る頃でグループ会社あった（図3）。
開発期間は6カ月の予定であったが、本社福利厚生サービスを提供

私が参画したのは開始後3 カ月が経った頃で、すでに 1カ月の遅れが出ていた。しかも仕様も確定されていないという状況であった。納期に間に合わせ

図1 参考事例のシステム概要

98Linux magazine February 2005

るためには設計／実装／テスト／デー

タ移行を計画では 4カ月だったところ

この時点で皆、先に待ち構えている

どでは元気なのだが、仕事中はずいぶを 3カ月で行う必要があり、大きな手であろう悲劇を予想はできていたもの

んおとなしい。技術的な話になると口戻り（仕様変更などによる作業のやりの、まだ楽観的に考えていた。

をつぐむ。

直し）が発生する危険性もあった。

■■プロジェクトの体制

彼は先輩らしき人といつも一緒にい■スキルの差スキルの差るのだが、その先輩とのある会話が耳に■入ってきた。
「よく『UML』って目にすユーザーのメンバー 5名、開発メンプロジェクトに参加してから 1週間るんですけど、それってどうやって参加バー20名の総勢25名の体制である。こほど経ち、現場にも慣れ、プロジェクできるんですか？」。戸惑う先輩。どうの中で私は 1つの機能の開発リーダー

トの状況がだんだんはっきり見えてくやら「ML＝メーリングリスト」というとして参画した（次ページ図4）。

るようになった。すると、1人の若い理解のようだ。私は心の中でつぶやいた。

■

メンバーの存在が気になるようになっ「それ、Unified Modeling Language でた。どうもようすがおかしい。昼食なすから。残念」
。

■出会い

出会い

■
火を噴きかけたプロジェクトのたいていがそうであるように、話を受けて本社から実際にプロジェクトに入るまでは急であった。金曜日に受注が決定し、アプリケーションサーバ

DBサーバ

Linux
TomcatApacheStrutsLinuxOracle

翌月曜日からプロジェクトに加わった。
まずはキックオフミーティングが行われた。ユーザー企業からは部長を始
イントラネットめとした情報システム部のメンバーが参加した。開発側は皆、元請け会社の社員という名目で参加した。名刺も元グループ会社請け会社のものが支給されている。開発チームの素性を知られないため、その場は開発チームのメンバーも元請け会社の立場を貫いたのだ。
顔を見回すと若いメンバーが多かっ

図2 参考事例のシステム構成図た。プロジェクトの状況は厳しいが、若さで乗り切っていけそうだ。
スケジュール

その夜、開発チームで飲み会が行わ6カ月間れた。若いメンバーが多いためすぐにみな打ち解けた。
私は自分の周りにいたメンバー達に

計画

要件定義

設計／実装／テスト／データ移行

本当の会社を聞いてみた。すると私の周りだけでも、元請けのほかに 3社が実績要件定義設計／実装／テスト／データ移行関わっていることがわかった。さらに以前からプロジェクトに参加していた筆者はここから参画

メンバーに聞いてみたところ、10社以上が関わっているとのことである。

図3 参考事例の開発スケジュール

February 2005 Linux magazine99

Development

あとで他のメンバーに聞いたところ、のメンバーの本当のスキルがわからな

A社は今回の案件における私の会社の彼とその先輩は、同じ会社から新人とい。そのため当初の計画のままでは、発注元であった。私はその旨をプロジ中堅のSEとのセットで派遣されている

このような無理が生じることがある。

ェクトマネージャーに伝え、自分が面進捗に応じてクラッシングやファス談に参加するのは立場上おかしいので彼らは私のチームにいたため、私がトトラッキング（「PMBOK」というプ避けたいと言った。しかし、プロジェ進捗を管理していた。やはり新人の進ロジェクト管理フレームワークの知識

クトマネージャーはそのような事情は

捗が遅れ気味である。どうしても、1エリアのひとつ「プロジェクトタイムおかまいなしで「話を一緒に聞いてもつ 1つの作業に時間がかかってしまうマネジメント」において進捗の遅れをらうだけでいいですから」とのことでのである。

回復するための手法として位置づけらある。とのことである。

たとえば、単体テストでは JUnit をれている）などのリカバリー対策をとプロジェクトマネージャーからA社用いていたのだが、まず JUnit の使いっていくことになる。の営業に事情を説明しておいてもらう方がわかるまでにほかのエンジニアの■ということで、私は面談に参加するこ何倍もの時間がかかっている。夜遅く■びみょ〜な立場
びみょ〜な立場とを承諾した。

まで頑張ってはいるのだが、いかんせ■そして面談となった。こちらはプロ

ある日プロジェクトマネージャーにジェクトマネージャーと私の 2 人で、始めのうちは先輩SEがサポートして呼ばれた。他のチームに開発者を追加

候補者側は候補者本人と A社の営業のいたのでそれほどでもなかったが、先することになり、その面談に同席して2人であった。

輩SEのほうの仕事が立て込んできて余ほしいとのことだった。本来であればまずは候補者が職務経歴書の説明を裕がなくなってくると、新人の遅れが新しいメンバーが加わるチームのリーする。入社2 年目でこれまでに経験し目立つようになった。

ダーが面談に参加すべきなのだが、スたプロジェクトは 2つ、経験した作業ケジュールが折り合わず、このようなはコーディングとテストが中心だった。

事態となった。

今回は概要設計や詳細設計のスキルがんスキルが足りない。

いつも私が帰る頃にも、人一倍憔悴した顔の彼がぽつんと残っていた。
複数の会社からの混成チームによる事前に職務経歴書が送られてきていプロジェクトの場合、計画段階では個々たので見てみると、候補者の所属する求められるとのことなので、厳しいだろう。
「鹿取さん、質問ありますか？」。プ
ロジェクトマネージャーから質問を振PMO（Project Management Office）
ユーザー代表開発代表られた。
そこで、これまでの経験につい突っ込んだ質問をした。やはりプロジェクトが求めているスキルは足りないようだ。私の質問で候補者のスキル不足がプロジェクトマネージャー

ユーザーリーダー際立った印象となってしまった。
「鹿取さん、どうですかねぇ」。またプロジェクトマネージャーが私に振ってきた。そんなこと聞かないでくださ

機能A機能B機能C

ユーザーメンバーい。約束が違います……。
営業的な事情とプロジェクトとで板ばさみとなった格好だが、この候補者筆者はここにリーダーとして参画
図4 参考事例の開発チーム体制

100

Linux magazine February 2005に参加してもらった結果、プロジェク
トに悪影響があれば、最終的には候補

者、A社、プロジェクトの三者が不幸

クトへの習熟度が上がるまでは、既存お客様の事業に変更があり、今回開発になるため、はっきりと言うことにしのメンバーと比較して生産性が低いこしたシステムは使われないことになりた。そうだ、これは正しい判断だ。間とになる。したがって、必然的に既存ました。

違いない。のメンバーの契約を延長するという方「ちょっと厳しいですね」。正しい判法を選ぶことになる。

私はもう一度メールを読み直した。

断だと思いながらも、営業の顔から目

しかし、メンバーは少しでも早くこシステムが使われなくなった事情が書を背けないわけにはいかなかった。の泥舟から脱出したいという気持ちでかれており、「皆に協力してもらったあり、自分の会社が許すのであれば契のに残念です。今後もご協力お願いし約の延長を断りたいと願っている。

ます」と結ばれていた。

結局この候補者はお断りすることになった。

プロジェクトマネージャーが契約延

すでに私は新しいプロジェクトに参■泥舟からの脱出
泥舟からの脱出長のために奔走し、ほとんどのメンバ加していて、そこでの業務に忙殺され■ーは契約を延長することになった。していたため、このプロジェクトの記憶実装フェーズも後半戦に入った頃、かし、一部のメンバーは契約延長を断が薄れつつあった。しかし、メールを大きな仕様変更が発生することになっった。そうしたメンバーは表情が晴れ受け取って当時のことを思い出し、こた。単体の機能だけでなく、全体に関やかに見える。心ならずも残ることにの結末を残念に思った。自分達が開発わる変更であった。この時点ですでになったメンバーには、どこかしら妬みしたシステムがユーザーの役に立たな各チームで遅れが出ており、この仕様のような感情も覗える。

いというのは、技術者としてとても残■変更によってカットオーバーが後ろに私はもちろんプロジェクトに残るこ念なことである。とになった。一度乗った泥舟に沈むまこのプロジェクトにはリーダーとしで付き添うという決意を持って……。て参加し、顧客との折衝やチームのマ各メンバーが毎日夜11時まで作業する■

ネジメントをしていたが、いくつもののは当たり前となっていた。この頃に■そして結末はそして結末は失敗をした。この経験を生かし、今のは、皆が泥舟に乗った気持ちになって■ユーザーには満足してもらえるシステ

ずれ込むのは決定的となった。
これまでも遅れを取り戻すために、いたはずである。私はリーダーというその後も毎日終電近くまでの作業が立場であるため、メンバーのやる気を続き、何とか納品までこぎつけた。最高めていく使命がある。しかし、今後終的には1カ月遅れでの納品となった。

も予想される仕様変更と疲弊により現その夜はメンバー全員での打ち上げ場に蔓延した絶望感を打ち消す力は、が行われた。苦労を共に乗り越えてき残念ながら私にはなかった。

ただけあり、一体感は非常に強いものカットオーバーがずれ込むことによがある。そして開放感も加わり、飲みり、プロジェクトとしては要員の調達会は非常に盛り上がった。プロジェクを検討する必要が出てくる。現在のメトが終わったときのこの開放感は何度ンバーの契約は当初のカットオーバー味わっても気持ちが良いものだ。皆こに合わせたものであるため、契約の延れまでの苦労をねぎらい、これからも長や外部からの新規要員の調達などを飲みに行こうなどと話している。

ムを完成させようと気持ちを新たにし、メールを閉じて私は業務に戻った。

Column
PMBOK
本文中に登場する PMBOK とは、プロジェクト管理の啓蒙活動を推進する非営利団体、PMI（Project ManagementInstitute）が策定した管理手法のフレームワークである。
開発の目的と範囲、スケジュール、コスこうしてプロジェクトは解散し、私ト、品質などの「知識エリア」と呼ばれる外部からの新規要員の調達の場合、は久しぶりに自社での勤務となった。

領域に分けてプロジェクトを捉え、それらを要員の選定やその要員へのプロジェク

2 カ月ほど経った頃、プロジェクトト要件や状況の説明といったコストがマネージャーからメールが来た。次の発生する。また、その要員のプロジェ一文が目に留まった。

行う必要があるのだ。

統合的に管理・実施していくためのガイドラインとなっている。
（編集部）

February 2005 Linux magazine101