ワタシが思う少数精鋭なプロジェクトチームをつくってみたら……

on


プロジェクトでアジャイルのscrumを採用しようとすれば、

  • チームの人数は7人±2がいい
  • メンバは出来る限り固定にする


とか、チーミングについてもいろいろと制約じみたことがあったりして、

「あれ、アジャイルってもっと自由なんじゃないの？」


なんて思っているようだったら、少しアジャイル関係の書籍やその界隈の先人のブログを見てみよう。高速なdeliverableを顧客に届けるためにエンジニアに求める要求もウォーターフォールと比べて高いレベルを要求する。


じゃあ、少人数のプロジェクトチームや高いレベルのエンジニアを要求するプロジェクトチームは“アジャイルだけの専売特許”なのだろうか。ウォーターフォールでシステム開発をするチームはそこそこのレベルのエンジニアでプロジェクトをキャリーしていればいいのだろうか。


いや、そんなことないよね。ウォーターフォールをシステム化初手法に採用するプロジェクトチームだって、それが少人数のチームだってレベルの高いエンジニアを要求するものだ、と思うんだ。


いや、ワタシの経験からすれば、少数精鋭のプロジェクトチームはどんなシステム開発手法を選択しようとも、担当するエリアの技術はマルチスキルなエンジニアを要求するし、要求するエンジニアのレベルはそのプロジェクトをキャリーするに“必要な”技術レベルのエンジニアを要求するものだ。


プロジェクトはキャリーできればいいってものじゃない
ある組織にいたころの話ですけどね。その組織はまだとてもSIプロジェクトの経験値が少なかったみたいた。その異質な空気を感じるにはそれほど時間は必要なかった。


自分とは直接関係のないプロジェクトのメンバのアサイン方法を尋ねてみたんだ。

「これから某プロジェクトをキャリーすることになりそうなので、ここでのメンバのアサイン方法はどんな風か教えてよ。」
「メンバの空きをマネージャに聞いて、空いている人を見つけて担当してもらうんだ。普通でしょ？」
「空いているかどうかを聞くんだ。じゃあ、誰がどんな技術をもっているかとか、どこまでできるとかどうやって把握するの？」
「必要都度、マネージャに聞くときに聞くよ。フェーズの作業を切り出して担当してもらうだけだし。」
「え？プロジェクト当初から必要なスキルに見合う要員計画を立てて、計画時から人を押さえないの？」
「しないね。なんでするの？」
「ちょっとまって。ねぇ。メンバはアルバイトみたいにアサインするの？」

「ねぇ、なんでできたものをメールでしか教えないの？」
「できたらメールで教えてって言われているから。」
「それ、確認してもらってまで、が仕事の範疇じゃないの？」
「いやー、作ってって言われたから。担当する工程だってフルアサインじゃないんだし。この工数の中でならここまでだし。」
「(まるでアルバイトみたいだな。)」

「ねぇ、スキルを伸ばしたいと思う？」
「そりゃそうだよね。」
「じゃあどうしたら伸ばせると思う？」
「仕事でアサインしてもらうのかなぁ。」
「どうしたらアサインされると思う？」
「仕事で経験したら、かな。」


これでは、エンジニアは育たないし、そうだとしか思えないだろうね。だって、学ぶ“機会”がないんだもの。システム開発手法だって、研修でウォーターフォールくらいは習ったかもしれないけれど、プロジェクトを頭からおしりまで、要件定義からリリースまで一気通貫でやってみて初めて分かることがあると思っているんだ。


だから、フェーズを都合の良いように時間の切り売りをされてはエンジニアがエンジニアとして“前後を考えて”作業をすることができないじゃないか。実績がなければアサインされないとか、どんな無理ゲーなんだよ。そう思った。


ワタシの思う正しいSIプロジェクトのチーミングを実現するためにしたこと
そのあと、ワタシがプロジェクトをキャリーするに当たって当時のマネージャに要求したことは一つ。あぁ、その前に、事前にまわりの経験者にリサーチはしましたよ。事前に情報を手に入れることは大事なことです。情報を確保する前哨戦からゲームは始まっているのです。

  • そのパッケージを適用したプロジェクトは初めてなのでキーパーソンはプロジェクト期間を一貫して確保すること


たったこれだけ。頑として「これは譲りません！」とアピールするわけです。これを約束しなければプロジェクトをキャリーしないもん、と。なんせ受注してしまっていましたからね。まるでゲーム理論で債務者の方が強い態度で要求するようなものですよ。あはは。


なぜ、一貫したメンバでキャリーしようとしたのか。アジャイルのチーミングで推奨されるような7人なんてピーク時で、でしたもの。通常は半分くらいでしたでしょうか。そんなメンバの少ないプロジェクトをキャリーするのにメンバがクルクルと入れ替わったりしたら、どうやってコントロールすればエレガントにプロジェクトをキャリーできるかなんて思いつきもできないですわ。


実際のプロジェクトチームの運営はもちろん、SIプロジェクトを一気通貫して“経験”させることで、

“このプロジェクト以後のプロジェクトをチーミングするときの人的資産を作っておきたい”


とも思っていたんです。そのプロジェクトは1回限りだけれど、ビジネスは1回でお仕舞ではないんですからね。ずっと続けるわけです。メンバは入れ替わる可能性があるけれど、同じメンバもいれてチーミングすることだってあるわけです。なら、やり方を覚えていてほしいと思うのは自然な帰結です。


勿論、メンバには「これしかできません。」なんて言わせません。少数なプロジェクトならではで、あれもこれもやってもらいます。

「これお願い。」
「それやったことないです。できません。」
「そうか。初めてか。それはいい経験ができるね。」
「ねぇ、ちょっと。これ知っているの誰だっけ？あ、あの人か。今何プロジェクトやっているだっけ？あれかー。」
「ワタシからあの人に話しをしておくので、あの人にこの日までに聞いてみて。」
「それで、聞いてきたことを教えてよ。どう進めるか一緒に考えよう。」


知らなければやってみればいいじゃない。エンジニアのレベルによってサポートも変えるよ。シニアなエンジニアならここまでやらないけどね。


あれ、少人数でマルチスキルなメンバとずっとチームを組むなんてアジャイルなscrumのチームと同じじゃないのかな。いや、確かに違いはいくつもあるけれど、エンジニアに要求していることの本質は変わらない、と思うんだ。


このやり方で他のプロジェクトの案件も見積もり時からメンバ編成を考えさせるんだ。兎に角、メンバを一気通貫でアサインすることを基本として。案件を受注出来たら、そのまま計画にスライド。ほかの案件との兼ね合いもあるから100%そのままとはいかないけれど、それでも基本を崩さない。


パターンを作って、次はエンジニアのレベル上げに。そうしてメンバアサインの組み合わせをちょっとずつ変えてチャレンジもさせる、そんなプロジェクトチームがいくつか出来上がっていったんだ。


言葉に惑わされてはいけない。やることをやっていれば、時代はついてくる。でもやることは奇抜なことじゃない。ごく当たり前のことだ。それで少数精鋭のチームは作れるんだ。