プロジェクトの成功と失敗をわける大きな要因はスケジュールのひきかたにあると確信しています。
いままで数十の小規模から大規模のプロジェクトを経験してきましたが、すべてのプロジェクトで共通して言えるのが、いかにスケジュールが大切かということです。
計画の立て方次第で、結果が変わってしまいます。逆に言うと、上手に計画をたけることさえできたら、プロジェクトは成功する可能性が高まるということです。
僕は、プロジェクトのスケジュールを書いてもらうときはいつも「スケジュールには魂をこめろ」と言い続けてきました。
スケジュールに魂をこめるとは？
今回、その内容について、できる限りお伝えしていこうと思っています。
プロジェクト計画立案のコツ
プロジェクト計画（スケジュール）立案のコツ
・ゴール（スコープ）を明確にする
・推進体制と役割を明確にする
・ゴールまでのタスクとタスクをつなぐ
・次のタスクの前に必要なものは前のタスクとして用意する
・未定のものがあっても必要なものはタスク化する
・設定したスケジュールでやり切れる自信がある
細かいことは、内容を説明する際に後述しますが、この６つのポイントは非常に重要です。確実に抑えてください。
今回の内容は、システム開発のスケジュールを意識して書きますが、システム開発以外でも、プロジェクトとして、根本の部分は同じだと思っています。
ゴール（スコープ）を明確にする
納期、品質、コスト（プロジェクト規模）と実施内容をまず具体的に把握するところから始めてください。
スケジュールはそこからスタートします。
明確にきまっていないものは一定の前提をおいてください。
前提すらおけないものがある場合については、先にそれを決めるプロジェクトを実施するように働きかけるか、後ほど説明しますが、未定のものを決めるタスクをおくかです。
何にしても、プロジェクトの概要（小規模なら具体的な内容まで）と納期をしっかりと頭に描きます。
推進体制と役割を明確にする
今回は見積もりのやり方については、述べませんが、スコープにあわせてプロジェクトの規模を把握してください。
タイミングによっては、簡単な概算の規模感でもかまいません。
おおよそのスコープと規模がわかれば、そのプロジェクトに必要な人数が割り出せます。
少人数（５人前後まで）であれば、自分が推進リーダになって、そのままピラミッド構造にしてもいいですが、それを超えるような場合には、プロジェクトの中でチーム分割して、チームに役割を定義する必要がでてきます。
プロジェクトの体制づくりは、一つの組織をつくるということにつながります。
アジャイル開発の場合には、ゴールに向かって何サイクル程度まわしながら進めていくかを考えます。
大規模プロジェクトでアジャイルを実施するには、日本のように開発ベンダーなどに一括で発注する場合には契約などの課題もありますが、今回はスケジュールの話なので割愛します。
ゴールまでのタスクとタスクをつなぐ
プロジェクトのゴール、体制を頭にいれながら、今回のプロジェクトとして必要なタスクを考えていきます。
まずはとにかくスケジュールを引いてみます。
要件検討→設計→プログラミング→結合テスト→システムテスト→ユーザテスト→リリース
ここまでなら、１度でも開発をやったことがあれば書けるかもしれません。
また、プロジェクトの特性に応じて必要なタスクは入れてください。
プロジェクトは生きています。プロジェクトによって不要なタスクもあれば必要なタスクも発生します。
例えば、外部のシステムとの連携が多数あるプロジェクトであれば、そのタスクを忘れずにいれるとかです。
他のプロジェクトや会社の標準的なタスク一覧もあるものの、本当に必要なタスクはプロジェクトを推進しているメンバー、まさにあなたからしか出てこないものです。
あわせて、納期とプロジェクトの概算からムリがないかは腹落ちしておいてください。
極端なたとえですが、１０億のプロジェクトを今から立ち上げて１か月後、といわれたら通常のシステム開発のプロジェクトであれば、まず無理ですよね。
規模と期間で無理がないか、やりきれるかを自分の会社や自分の実力からまずは仮に推定しておきます。
次のタスクの前に必要なものは前のタスクとして用意する
前後のタスクをつなぐときに重要になるのは、ここの考え方になります。
タスク開始の前にはそのタスクを円滑にはじめるための条件があります。
例えば、設計タスク前には
・設計標準（複数人で開発なので、これがないとバラバラになる）
・共通部品の設計書（インターフェース）
・外部連携するシステムとのインターフェース
などなど、大/中日程レベルで重要なことが数多くあります。
同じことは、すべての局面でいえることです。
もう一例出せば、例えば結合テスト前には
・結合用のテスト環境
・結合テスト用のシナリオ、テストデータ
・結合テストの合格基準
・性能テストを実施するのであれば、そのケースとデータ、テストシナリオ
・複数環境があるのであれば、環境の管理基準
プロジェクトの結合テストの定義にもよりますが、上記のようなものは普通に必要になります。
それも、結合テストにはいってから準備するのでは間に合いません。
次の局面の前に準備が終わっていることが重要になります。
タスクの実施イメージを具体的に頭に思い描いて、その時に必要なものがタスク開始前までに準備できるように、事前タスクをひいてそこにメンバーを割り当てることは必須です。
いわれてみれば当たり前でも、メインタスクを機械的にひいたりすると、つい抜けてしまうことが多くなります。
意志を込めて、確かにタスクをつなげて次のタスクが実行できること、それをひとつずつ納得しながらタスクに落としていくことが、スケジュールをひくということです。
未定のものがあっても必要なものはタスク化する
タスクを引く中でプロジェクトの後半にならないと決まらないことは多々あります。
例えば、運用のテストをどこまでやるかとか、そもそもシステムの運用で障害の監視は誰にお願いするかだとか、すべて未定とかざらにあったりします。
それでも、仮でもいいのでスケジュールには落としてください。
重要なのは、あるタイミングで決めなければいけないことがスケジュール上わかることです。
その上で課題管理で決めるべき人にボールをもってもらう、進捗報告で決めるべき人に決めることを依頼する等を実施してください。
もし、明確にする役割が自分自身で、今のところまだできていないだけならば、自分に対するフォローのためにもタスク化は漏らさず記載しておくべきです。
ここまでで、スケジュールは未定も含めてある程度完成しました。
スケジュールには魂をこめろ
設定したスケジュールでやり切れる自信がある
最後に、自分自身に問いかけてください。
「このスケジュールで責任もってやれるだろうか？」
「やれる！」
と納得して答えられるまで、何度でもスケジュールを書き直してください。
条件を変える必要があれば、上司やお客様、自分自身と調整です。
そして、納得したら、あとは最後まで責任もってやりきる！
その先にはプロジェクトの成功が待っています。
今回の話が腹に落ちれば、かなりのプロジェクトがまわせるようになると、今までの指導経験から確信しています。
それもあって、タイトルは多少大袈裟ですが、タイトルでは究極のコツとつけてみました。
※自分の文章力で伝えきるのは難しく、まだまだうまく書けていないのですが、多少でも伝わったら幸いに思っています。
プロジェクトの悩み事は
これまでの自分の経験やノウハウをもとに、プロジェクトのコンサル、ご支援/ＰＭＯ、プロジェクトマネージャの育成などを実施しております。
本記事をお読みいただき興味の湧いた方、支援ご希望がある方など、遠慮なく下記よりご連絡いただけると幸いです。
