「新規案件」とは

既存のシステムを改修したり運用するのに比べて、制約を受ける量が少なくダイナミックな挑戦ができるので、始まる時はちょっと気分が高揚するもの。

直前のプロジェクトに1年以上拘束されて「もうこの仕事飽きたよ……」とか「早く別のプロジェクトに逃げたい……」とか感じて鬱々としていた人にとっては、より心が躍る存在として感じられるもの。

プロジェクトを開始する前は、アレをやろう、コレをやろうと、さまざまな夢を心の中に描いてしまったりするもの。

でも、実際に始まってみると、「お金」とか「時間」とか「人間関係」とか「会社同士の力関係」などの生々しい要素によって、「絶対、こうしたほうがいいのになぁ」といったボヤキと共にはかなくも崩れ去ることになるもの。

既存のプログラムの改修や運用に比べると、想定しなければいけない工程が多かったり、関係者間での意識合わせも困難な為、「漏れ」とか、「想定外」とか「認識違い」といった、一発でエンジニアを病院送りにできるような可能性を秘めた事象を発生させることも多いもの。

それなのに、新規案件を1つこなした後、数週間も経つと、「また新しい案件をやりたいなぁ」と思ってしまったりするこの気持ちは、「知的探究心」とか「冒険心」という言葉でくくられるべきものなのか、それとも「○ゾ」という一言で表すべきものなのか、評価が分かれるもの。

「予算」とは

年度の初めに割り振られるもの。
もしくは案件ごとに割り振られるもの。
ちょっと気を許すとあっという間に膨れ上がってしまうもの。

金額は膨れ上がっていくのに、なぜか要件はどんどん削られていくという不思議な反比例が、プロジェクト終盤に見受けられるもの。

予定どおりに行かないのが世の中だということを証明してくれるもの。

大き目の案件だと、ちょっとした不注意で自分の給料10年分の大赤字とか平気で出せてしまうもの。

というように、予算とは非常に危険な性質を持つものである。ものすごく大きなバックが付いていて、無尽蔵にお金が沸いてくる案件（ごくまれに存在するらしい……）でなければ、注意して取り扱わなければいけない。

予算が想定外に膨らんでしまう大きな原因は、工程の洗い出しの甘さや、人員のスキル不足等の「開発側の問題」と、要件の途中追加の頻発や、話をするたびにお客さんの言うことが変わっていき、いつの間にか当初話していた内容とは似ても似つかない仕様になっていたなどの、「要求面の問題」が挙げられる。

開発メンバーのスキルはすぐにはどうにもならないので、みんなボチボチ勉強していきましょうってことで置いておいて、顧客の要求の揺れを解決するには、相手が心の中で思っていることを洗いざらい引き出すような巧みなコミュニケーションスキルと、時には顧客自身が気づいてすらいない（でも、後から必ず出てくる）ような要望を経験則や業務知識、それから時にはシックスセンスを駆使して感知するなどの人智を超えた荒業で把握する能力が必要になる。

また、コミュニケーションやシックスセンスに自信がない場合は、とりあえず適当に出した想定値の2倍で予算を組んでおいたり、向こうがOKって言ってくれそうなギリギリの値段を見積もりもしないで要求するという、システム開発の予算の組み方としては最もポピュラーな手法「どんぶり勘定」を使用すると良いと言われている。

「スケジュール」とは

プロジェクトを開始する前に、納期はいつで、このころまでには開発環境を用意して、この日までに実装を完了して結合試験を開始しよう、といった大枠を立てておくもの。

その後、実作業に入ったら徐々に工程を細分化して立てていくもの。

作業が進めば進むほど、当初の想定に入ってなかった工程が増えて、当初のスケジュールが無力化していくもの。

「納期はここって決まってるから、それまでにいい感じに作ってくれない？」と言って他社から投げつけられるような、工数も決まってないのに納期だけが決まってる案件に対して、「じゃあ、開発はここまで、試験はここまででやらなくちゃいけないんだろうなぁ。なんていうか、絶対無理な気がするけど、ここまでには終わらないといけないんだなぁ」といった形で、受動的に線を引かされたようなものも立派なスケジュールである。

予算や工数と同じように、スケジュールについても開発初期の段階で正確に洗い出すのは難しい。そのため、ある程度の余白期間を見積もったうえで、各工程に対してこの期日を過ぎたら危険というデッドラインを設けておくと良いと言われている。

無茶な納期を強要された場合を除いて、基本的にデッドラインを過ぎるような状態に陥ってはいけないのだが、何らかの不運か過失によってそこを超過してしまった時には、当初のスケジュールを達成することを諦めてリスケするか、責任者が人間らしい生活をすることを諦めて会社泊り込み生活を始めるか、いっそのことプロジェクト自体を諦めるなどの対応を取る必要がある。

「設計が遅れている」とは

大きな会社のシステムを作っていると、非常によく見られる現象。

実際に行われている業務を調査したり、部署ごとの要望を取り入れたりといった作業をしていると、大抵予想していたよりも長く期間がかかってしまったりするもの。

そして、設計が遅れたからといって、製造のスケジュールが後ろにズレるかというと、そんなわけにもいかず、どんどん後ろのスケジュールが厳しくなっていくという現象も非常によくある。

設計が終わる見込みのタイミングですでに開発するエンジニアを集めてしまっていた場合は、設計が終わるまでエンジニアたちを「やることがないけど、どうしよう」という状況に置き、無駄に予算を消費しながら遊ばせてしまうというのもよくある現象。

そういった状況に置かれるのは、エンジニア的には遊んでいるだけで給料が入るのだから、良い話なのではと思われるかもしれないが、実際にその立場に立つと、何もせずに８時間を過ごすのが思いのほか大変だということを思い知ったりする。

設計に１年近くかけて、製造は３カ月程度しか取らないような、やたら設計期間が長い開発現場もたまに目にするが、１年前に行った設計では現状と乖離（かいり）してしまっていないか、心配になることもある。

「製造が遅れている」とは

どんな開発現場でも発生することがある現象。

まだその開発を行うエンジニアが誰なのか、どれだけの能力がある人間がやるのかも分からない段階でスケジュールを引いた場合などは、製造にどれだけ日数がかかるか正確に分かるはずがないので、発生するのも仕方ないかと思われるもの。

ごくまれに、アサインしたエンジニアが製造するだけの能力を持っておらず、いつまで待っても製造が終わらないといった現象も見かける。

「リスケ」とは

当初に決められていた「○日までにこの作業を完了させる」という予定を後ろに遅らせること。
リスケジュールの略。

進捗が遅れている時だけでなく、日程を前倒しで消化してしまった場合にもリスケは発生するように思われるかもしれないが、せっかくできた余裕をむざむざ手放すなんてことを好んで行う人は少ないせいか、スケジュールを予定よりも前にリスケするという現象は見られることが少ない。

進捗に余裕がある場合は正直にそのことを周囲に伝えてリスケを促すよりも、「オンスケのフリをする」とかここぞとばかりに病欠するという技を使用して、余裕を持って作業を進めることが開発者の取る正しい行動だと言われている（筆者の周りでは）。

リスケは通常リリース日を遅らせることによって進捗の遅れをカバーするが、時としてリリース日は変えずにテスト期間が短縮されていたという危険なリスケ方法が取られることもある。 このリスケ方法はもちろん、大きなリスクを伴うこと請け合いのあまりオススメできない手法である。

「増員」とは

開発要因を増やすこと。

普通に考えると、人を増やせば増やしただけ開発のスピードは上がりそうなものだが、残念なことに、ことシステム開発においては一概に人を増やせばいいというものではないようだ。

特にプロジェクトの中盤を過ぎた段階で

「今のままだと間に合わないんですけど」
「じゃ、とりあえず人を増やすか」

といった安易なやり取りによって増員を行った場合は、なぜか人が増えれば増えるほど仕事が忙しくなるといった、逆転現象が発生する。

筆者の実体験では、新しく入った人が開発現場にいる誰よりも高いスキルを持ったスーパーな人だった場合においてのみ、唐突の増員が進捗を早める効果を持ったことがある。

しかし、それ以外のケースでは周囲の負担が増えるだけの結果に終わり、増員として来た側にとっても、その人を迎えた側にとってもお互いに辛い経験としてだけ胸に刻まれることとなった。

もちろんプロジェクトの序盤に適正な数の人員を補充するという話であればまだ効果もある場合が多いが、終盤に差し掛かった段階でうっかり増員の話が決まってしまった場合は、これから来る人が全ての問題の解を持ってきてくれるスーパーな人であることをただ祈ることしか開発者側にはできない。

なぜそんな逆転現象が起きるかについては……　えーと……　なんでだっけ？

まぁ、「人月の神話」にでも聞いてやってください。