スモールプロジェクトで気を付けておきたいこと
数人でチームを組むようなサイズのプロジェクトの呼び方ってあるんでしょうかね。安直ですが「スモールプロジェクト」と呼部ことにしましょうか。このスモールプロジェクトは、所謂大規模プロジェクトと比較するとその違いがはっきりしてとても興味深いし、スモールプロジェクトのデメリットにおいてはマネージャがとても悩むところだと思います。
ワタシの大規模プロジェクトの経験とスモールプロジェクトの差異をぱっと思いつくことを上げると、
項番 | 期間 | 1つのチームの人数 | プロジェクト管理 | コミュニケーション | 人的資源活用 | 予想外のメンバ交代 | リスク発現に対する体力 |
スモールプロジェクト | 6ヶ月以内 | 3人±α | 必要最小限 | 早い | マルチスキル必要 | 致命的 | 絶望的 |
大規模プロジェクト | 1年以上 | 10人+α | 厳格 | 遅い | スキル不足でもカバーできる | 吸収できる | どうにでもなる |
こんな感じです。まぁ、ワタシの経験上に基づいていますからもしかするとかなり特殊だったり……しませんよねぇ。そう言った前提がありますけど、同じように今悩んでいる方のヒントになれば。
スモールプロジェクトのリスクには何があると思いますか。大規模プロジェクトに比較して、と言うリスクもあると思いますが、スモールプロジェクトだからこそ、のリスクもあると思います。さてどんなリスクがあるのでしょうか。
スモールプロジェクトの工期
ワタシがヤバいなーと思ったのはプロジェクト期間の短さ、です。6ヶ月よりも短い3ヶ月のプロジェクトだったりすと、製品トラブルが出来るともう致命的です。2ヶ月目の導入時に製品トラブルが起きてその原因がバグだったりすると製品ベンダとのやり取り、解析、緊急パッチが出るまでに1ヶ月でかたが付くなんてことはないのでその場合のプロジェクト期間に対するコスト計画が破たんするんですよね。もちろん、顧客だって導入後の計画に影響を受けるわけで。
ちなみに、極端なケースだと某ベンダだったりすると来年にでるかも、なんて平然と言われることもあるけど、幸いスモールプロジェクトではこのケースはなかったのは幸いでした。
スモールプロジェクトのエンジニア
なにせ少人数で運営するので予め計画が立てられていること以外の人的リソースの欠落は致命的です。例えば結婚なら、ある程度前からわかっているのでそれを前提とした人的引き当ての計画を作る考慮が出来ますが、2週間、1ヶ月のような期間が掛かる病気などが起きるとスモールプロジェクトの進捗に直撃するのです。
実際、スモールプロジェクトのプロジェクトマネージャが突然の病気になって2週間くらい入院したとき、「もしそうなったら困るから」とフォローしておいた結果、ワタシが繋ぎをして日々の実質的な運営はメンバ全員、と言っても数人なんですけど、でカバーし合うことをして乗り切ったことがあります。ワタシとしては無事復帰してくれたので笑顔で迎えられた方の気持ちでいっぱいでした。
スモールプロジェクトのスキル
エンジニアの技術領域が専門化され過ぎているとスモールプロジェクトでは、専門化され過ぎている結果、工程に必要な技術とレベルにより、担当エンジニアがとっかえひっかえになるのでとてもつらいです。
中にはいるんですよね、頑なにこれだけしかやらない、っていう人が。「ボクは○○が専門だから」ていう人が。今までどれだけ甘やかされていたのか。専門性は必要ですけど、その専門がなくなったらと考えて欲しいものです。
必然的にマルチスキルを求めるようになるのですが、技術スキルは勿論ですが、工程のマルチスキルがより重要になっていきます。プロジェクトの頭から終わりまで。この工程を一気通貫で出来るエンジニアが育たないととってもツライ。だから、若手も意識して、その若手の性格と特技を見つつアサイメントしていったものです。
逆に、大規模でないから故の、少人数だから少人数で頭から最後まで経験することが出来る方の価値観があるんですよね。その中でテーラリングした規律、標準化の上でのプロセスを回すということも必要だし、それをやらないとシステム開発の基礎を覚えないで育ってしまうし。またそうしたことをやるためにも作業のツール化を日々言い続けてチョットずつメリットを享受してもらいながら、カイゼンをまわす、と。
そうそう、少人数だからこそ毎日顔を合わせる人が少ないのでストレスには注意が必要です。