やっと担当していたプロジェクトが終了し一段落したのですが、久しぶりに大規模なプロジェクトに関わってその中で感じた気をつけたいことや学んだことをまとめてみたいと思います。
エンジニアとしてではなくプロジェクトマネージャとして携わったので、プロジェクト遂行や運営よりの話が中心となっています。
一日の遅れぐらいいいかという感覚で陥るワナ
プロジェクトの規模が大きくなると、スタート時にはそれから行われる膨大なタスクにめまいがしたりもするのですが、比較的期間が長いということもあり、時間の使い方が大雑把になりがちになったりします。
火を噴くプロジェクトのよくありがちなパターンとして、帳尻をあとで合わせようとして無理がたたるというものはありますが、やはり最初から全力投球していると体が持たないこともあったり、そもそもプロジェクトの最初は要件やら体制やらがあまり安定しない時期だったりもしますので、比較的スローにスタートを切るというパターンが多いのではないでしょうか。
この辺を後で帳尻を合わせられるとか、まだ曖昧な部分が多いから今本格的に始めるのはスケジュールの手戻りになったり品質に影響が、ということで一日一日を遅らせていくということがあります。
しかし、その一日の遅れがプロジェクト全体で大きく影響を与えてきたりもします。
自分にとって一日の遅れぐらいいいや、という感覚は他人から見てもそうであって、その間に挟む関係者が多くなればなるほど、自分が遅らせた一日というのが数週間の遅れをもたらしたりもします。
特に物を買ったり、人を手配するといった決裁承認であったり、設計作業をしてそれをプログラマに理解してもらうというような作業は多くの人が絡んだりもするため、その一日の遅れが思わぬ遅れを引きを起すということになったりもします。
自分にとって都合をあわせる一日の遅れは、他人にとってもまた同じ感覚で遅れていくということを覚えておいた方がよいかもしれません。
スタートまでに予想以上にかかる時間
同じく時間感覚的なものですが、プロジェクト内で何かをスタートするまでには自分が予想していたものよりも多くの時間がかかることがあります。
プロジェクトの開始までに必要な資料を作ったり関係者にネゴをとったり、開発を始めるまでに開発環境を整備したり、新米エンジニアが参画する場合はその教育にも多くの時間がとられます。
この資料が、この物がそろえばすぐにタスクが開始されるというわけでもなく、承認が必要だったりセットアップが必要だったりと、その前準備をうまく行っていないと、スケジュール上の開始期限がきてもそこから準備を始めるというようなことになったりして、思わぬ工数を取られる結果となるわけです。
しかし、あまりその準備期間というのはスケジュール表に反映されてなかったりもします。
あたかも、その開始期限から求めている100%のパフォーマンスでタスクが進行していくかのように思っていると、大きな落とし穴となるかもしれません。
最初から全ての環境がそろっていたり、参画するメンバーが全てベテランなメンバーということはほとんど無いでしょう。
それぞれのタスクをうまくスタートを切れるように、体制やタスク管理をコントロールしておく必要があります。
リソースを均一化しておくことが大事
多くの人が関わってくるプロジェクトではそれぞれに与えられる役割も細分化されてきます。
しかし、タスクには前後関係があり、そのタスクを担当する人たちもまた仕事に順序が生まれてきます。
そこで、担当者が時間をもてあますことが無いように仕事をうまく分配し、リソースを均一化するようにタスク管理したり、役割を分配することも大事になってきます。
設計工程が終わらないと開発が始められないというように、上流工程を担当するエンジニアの数が少なくなっていれば設計中にプログラマは時間をもてあますことになったりもしますし、テスト工程ではシステムが完成しないと開始できないため、テスターは成果物を待つ時間が長くなるでしょう。
役割を複数に分けたり、タスクを並行して動かすことでそのタスクのボトルネックを取り払う工夫が必要になってきますし、体制面でもそういった事態を避けるためにバランスの取れた配置が必要になってきます。
ウォーターフォール型で進めるプロジェクトは圧倒的に上流工程がボトルネックになりますから、その品質によって下流工程の出来が変わってきます。
下流工程の問題は、上流工程ですでに問題が内在していることが多く、そこに多くの時間が割けなかったり体制面で上流工程のタスク量が多くなってパンクしているというような状態は避けなくてはなりません。
せっかく与えられたリソースですから役割の階層構造にも注目し、その中でうまくやりくり出来るための戦略を考慮しておく必要があります。
話すことに時間を割く
異なる立場の人が多く参画するプロジェクトでは、それぞれの思惑が発生します。
顧客を始め、開発チームを取り仕切るメンバーや保守・運用に携わるメンバーもいたりします。
そしてそれぞれの立場に沿った意見を押し通そうとしますので、多くのすれ違いが生じることがあります。
それを無視して自分の意見だけを押し通してプロジェクトを進めようとすると、メンバー間の亀裂が生まれたりその方面で問題が勃発して想定外の対応に迫られることにもなったりします。
これを解決するためには、それぞれの担当者と話すことに多くの時間を割かなくてはなりません。
メールだけでは細部のニュアンスが汲み取れなかったり、情報量が圧倒的に不足したりもします。
定例会議の場や、個別に担当者を呼び寄せて双方が納得するまで話し合いをしておく必要があるでしょう。
これは非常に面倒で気を使う作業にはなりますが、プロジェクトを円滑に進めるためには一番大事なことかもしれません。
そして、プロマネの立場としてはどこかのレイヤの意見に偏るということなく、それぞれの意見を集約した上で納得してもらえる答え（もしくは引き下がってもらえるための納得できる材料）を用意しなくてはなりません。
タスクの進捗や課題だけに気を取られて、会議の話題がそれだけに集中するのではなく、それぞれの立場の意見というものをしっかり集約して問題解決を図る必要が出てきます。
燃えつきを防止する
若干今の自分がそんな感じではあったりするのですが、規模が大きくなればなるほどこの兆候は顕著にでてきたりします。
開放感からか、しばらく仕事が手に付かなかったり緊張感をもてなくなったりもします。
まぁ、プロジェクトも無事に終わったんだからしばらくはいいんじゃないの、って意見もあるかもしれませんがプロジェクト自体は完了してからがスタートという意味もあったりするわけで、そのような状態だとその後運用フェーズで支障をきたす可能性もあります。
あまりにプロジェクト期間中の仕事がきつかった場合、その落差が激しくなるためこのような状態のメンバーが多く出てくるかもしれません。
やはり、納期が厳しいとは言えある一定の余裕を持ってプロジェクトは着地を迎えたいものです。
その余裕が運用開始後にスムーズな運営に繋がるでしょうし、メンバーの能力やモチベーションへ大きく左右してきます。
プロジェクトを完了させるということだけに注目せず、その後の長い運用フェーズにも目を向けてプロジェクトを遂行していく必要があると感じます。