「WBS作りました！」と自信満々に言って、いざ進めると遅延が発生し、WBSを引き直してもまた遅延して、この繰り返しで、進捗報告会で毎回叱られる。良く見る光景です。
プロジェクト開始前に作るプロジェクト計画書。これには、プロジェクトの目的、推進体制、スケジュール、進め方、リスク、収支、品質管理基準など盛り沢山に記載します。この計画書のコンテンツの中で最も重要なものが何か、スパっと答えられる人はプロジェクトマネージャーの資質がある人だと思います。どれも重要だとか、立場や場面によって違うとか、そのような答えが多いですが、一番重要なのはスケジュールです。スケジュールは、体制の要素も、収支の観点も、進め方やリスク、ステークホルダーも全て考慮された結果として出来あがるものだからです。
先の見えない仕事を手探りで進めることと違い、システム開発の、特に設計以降のモノ作りの工程は、どれだけ想定できるか、緻密に考えられるかが肝です。
問題を引き起こす、遅延を繰り返す理由は、スケジュールが緻密に作られていないことに尽きます。タスクに漏れがあるから、無理があるから、考慮が足りていないから問題が起こるのです。進捗管理、リスク管理、課題対応プロセスも必要ですが、そもそも遅延させない、課題を発生させない、リスクを吸収できるように十分に考え抜かれたスケジュールを作成することが、プロジェクトを円滑に進めるためには重要です。
そこで今回は、スケジュールについての考えをお伝えします。
進捗管理が出来ない原因
プロジェクト支援で参画した時に、スケジュールを見るだけで遅延の原因がわかることがあります。それは、スケジュールが1種類しかない場合です。全てのタスク管理をWBSで行い、月次のマネジメント報告もWBSでしている。
WBSはメッシュが細かいため、中長期的な見通しやタスク間の依存関係を確認するのには向いていません。WBSだけで進捗管理を行おうとすると、木を見て森を見ず状態となり管理不能になります。逆に、粗いスケジュールだけで各担当者のタスク管理を行っている場合は、緻密な管理が出来ません。
進捗管理が出来ない原因は、管理の単位と範囲を両立して一つのスケジュールで管理しようとしていることにあります。
WBSは、限定した範囲、例えば各チームのスケジュールや基本設計など一つの工程のスケジュールとして活用するべきです。一方、月次レベルのスケジュールは、導入までの見通しを示すのにマネジメント報告などで活用します。このように管理したい内容に合わせてスケジュールを使い分けることが大切です。使い分けると言っても、全く別物を作成するのではなく、メッシュを細かくした層を重ねるイメージです。
スケジュールの種類
どのようなプロジェクトでも、スケジュールは必ず作成すると思いますが、何種類作ってますか？
大雑把なスケジュールだけで管理は出来ませんが、WBSだけでも困難です。プロジェクトの規模にもよりますが、4種類、最低でも3種類のスケジュールを作成することをお薦めしています。ひと昔前には、Microsoft Projectが会社標準の管理ツールになって、MSProject一つで全てを管理していた時代もありましたが、難易度が高いうえに複雑化して分かりにくいため、個人的には早々に放棄しました。いまだに会社標準のスケジュールだけに頼って管理不能に陥っているプロジェクトを良く見ます。何事も、一元化して複雑になるよりも、シンプルな形で切り出した方が分かりやすいのです。
大規模プロジェクトの場合、数年にわたる導入計画は普通です。海外展開や拠点展開、金融や通信の基幹系では一つのシステムで数年を要するプロジェクトも普通にあります。このような数年に渡るプロジェクトでは、全ての導入・展開が終わるまでの計画として大日程を作成します。
1年未満のプロジェクトであれば、中日程以下の3種類のスケジュールがあれば十分です。管理の単位と報告の頻度を合わせることがポイントです。
・大日程
期間：2年以上
単位：四半期～1年
報告レベル：経営層/ステコミ
・中日程
期間：1年
単位：1ヶ月
報告レベル：プロジェクト責任者/月次報告
・概要スケジュール
期間：3ヶ月
単位：1週
報告レベル：開発PM・クライアント担当者/週次報告
・WBS
期間：1～3ヶ月
単位：1日
報告レベル：チーム内/朝会
それぞれのスケジュールの単位を果物で例えてみました。（イラスト参照）
・大日程：フルーツ盛り合わせの単位
・中日程：フルーツの単位
・概要スケジュール：フルーツの１房単位
・WBS：1粒単位
スケジュールのイメージ
何のためにスケジュールはあるのか？
そもそもスケジュールは、何のために作成するのでしょうか。ほとんどの人が「進捗管理のため」と答えられると思いますが、この理解が間違っていることが多いです。
進捗管理は、文字通り、計画に対する進み具合を管理することです。
よくある間違いが、何をやったか、やったことの管理と、予定の確認に使っていること。正しくは、現時点でスケジュール通りに進めているかと今後も計画通り進めていけそうかの見通しの２つを管理するのが、進捗管理です。
スケジュールの中で最も細かいWBSは、この2つを管理するための諸元データとなります。WBS上のひとつのタスクの遅れが、どのタスクに影響するかWBS上で把握し、その結果、全体スケジュールにどのように波及するかを、メッシュの荒い概要スケジュールや中日程を使って表現し、見える化することで、マネジメントにも分かりやすい進捗管理ができるのです。
WBSは、進捗管理のエビデンスとなるため非常に重要です。プロジェクトの成否は緻密なWBSが握っているため、数百～千行以上になることも普通ですが、大変でもプロジェクトマネージャーがWBS作成を行うべきです。
※ちなみに、昨日、某プロジェクトのWBS（356行）作りました。
遅延しないWBSを作成する８ステップ
開発スケジュールは、見積もった総工数をエンジニアの人数で割って作れるものではありませんし、クライアントが希望する納期までの期間で割って作れるものでもありません。
このように雑に作ったスケジュールでは、遅延や炎上に繋がってしまいます。そうならないためには、面倒でも大変でも時間がなくても、必ず緻密なWBSを作成するべきです。さすがに1年先までを作ることは無理ですが、出来るだけ細かいメッシュで作成していくことが望ましいです。
Step１．タスクの洗い出し
まずはタスクの洗い出しが重要です。ここで必要なタスクを漏らすと計画として成立しなくなってしまいます。タスクの洗い出しの簡単の方法は、４ステップとレビューで考えることです。
４ステップは、計画・準備・実行・承認です。計画は、工程や領域に一つで、準備・実行・承認は成果物毎に３つ１セットと考えることが基本です。例えば、基本設計工程であれば、計画は、基本設計計画書作成、準備は要件理解と論点抽出、実行は基本設計書作成、承認は設計書承認で、準備・実行・承認のタスクは成果物毎に必要です。
レビュータスクは、品質管理プロセスに定義されたレビュー階層に基づき、計画・準備・実行の各タスクに追加します。さらにレビュー時の指摘を反映するタスクも追加します。例えば、レビューがピアレビュー、リーダーレビュー、クライアントレビューと3回あれば、レビュータスクと指摘反映タスクが3つずつ合計６つのタスクが追加されます。これで、おおよそのタスクは洗い出せます。
Step２．工数の割り当て
１で洗い出したタスクへ工数を割り当てます。厳密には担当者によって工数は変わりますが、この時点では、実施日や担当者を考えずにいったん工数だけ割り当てます。ここで割り当てる工数の見積りが甘いと、タイトなスケジュールで苦しむことになります。
見積り手法は、いろいろあり、大手SIerであれば、独自の見積りツールを持っていたり、作業によって基準値が決まっていたりしますが、ツールや基準値がなければ、経験に基づくことになるので、少しでも精度を上げるために、複数の上級エンジニアや経験豊富な方に見てもらいましょう。
この時、一つのタスクは5人日以内にすることです。6人日以上になるようなタスクがあれば、タスクを分割します。ドラフト作成と最終化に分けたり、中間レビューを間に入れるようにしても良いです。タスク分割に合わせてレビュータスクも当然追加します。
Step３．エンジニアの割り当て
１で洗い出したタスクに担当するエンジニアを割り当てます。タスクに求められる技術からスキルセットを見てエンジニアを割り当てます。要員が確定していない場合は、TBDでも構いません。レビュータスクが対面レビューの場合にはレビューワーとレビュイーの両方が必要となるため、ここでタスク分割します。このタイミングで担当者に合わせて工数を微調整しましょう。
Step４．作業日のセット
３で調整したタスクの工数を作業日に割り当てていきます。ここで作業日に工数をセットすると、各エンジニアの1日の稼働が計算されます。1人日(８時間)を超えてしまうようであれば、作業日をずらすかエンジニアの割り当てを変えるしかありません。またエンジニアはその日暮らしではないので、稼働が割り当たらない日があってはなりません。この調整を行うと、必要なエンジニアの人数と各工程の終了タイミングが決まります。納期を早めたい場合は、当然、エンジニアを増やす等の対応が必要となります。
Step５．エンジニア推移(傾斜)を均す
４まで終わると、エンジニア数の推移がわかります。エンジニア数の傾斜グラフは、リスク判断に役立ちます。工程の切り替えタイミングは特に注意が必要で、例えば、要件定義を5人で実施して、翌月からの設計者が20人必要となると、急に15～20人のSEが増加することになります。20人のSE全員が設計の実作業に当たったら、レビュー者がいなくなってしまうので、レビューのできるリーダー的SEを先行して要件定義終盤からアサインする等の対応が必要となります。
各工程が非連動に行われる場合もあるので、一概に正解はありませんが、なるべく傾斜はなだらかな方がリスクは低いです。
Step６．新規参画者の引継ぎ期間とリスクバッファを設ける
５．エンジニア推移を考えた結果、新規参画者が入る場合には、引継ぎのタスクを追加で入れるべきです。新参者が参加した当日からバリバリ実務をこなせるはずはありません。
入館申請やアカウント取得など事務手続きも必要ですし、プロジェクト概要や前工程の成果物の読み込み、環境準備のタスクも必ず必要です。実務の作業を行うタイミングより最低でも1週間程度前に参加するように計画するべきです。
Step７．バッファタスクを盛り込む
最後は、バッファです。
バッファには、いくつかあり、工数バッファ、費用バッファ、期間バッファがありますが、WBS上は、期間バッファと工数バッファの両面からバッファタスクを入れておくと管理がしやすいです。
Step８．タスクを括る
最後にタスクを括りましょう。この括りの単位が、概要スケジュールや中日程として表現されるため非常に重要です。タスクを括ることで、WBSで管理しているタスクが遅延したら、概要スケジュール上のどのタスクに影響するかがわかり、全体への波及が分かりやすくなります。また、体制上のチームと括りを連動させることも大切で、チームリーダーやサブチームリードの責任範囲が明確になります。
まとめ
遅延を繰り返すプロジェクトは、スケジュールに原因があります。雑であったり、無理があったり、粗かったり、細かすぎたり、依存関係がなかったり。
プロジェクト管理の要素は、沢山あります。PMBOKにも多岐に渡って複雑に書かれており、いかにシステム開発のプロジェクト管理が大変かを示したいかのような内容です。進捗管理、課題管理、リスク管理、変更管理、これらは、事が起こった時に対処するルールを規定したものです。逆に言うと、事を発生させなければ、このルールの出番すらないということです。遅延させない、課題を出さない、リスクを顕在化させない、完全になくすことは不可能ですが、減らすことは出来ます。そのために、必要なのが、緻密なスケジュールです。
進捗管理の最小単位となるWBSは、規模によっては数千行となることもありますが、緻密に計画されたスケジュールがプロジェクト推進の基準となるため、経験値が高く、全責任を担うプロジェクトマネージャーが作成すべきです。この時点で大変だと言っていたら、計画通りの推進は絶対に出来ません。
効率的なシステム開発や、あらゆる技術を利用したDX化はアタラキシアディーエックス株式会社までご相談ください！
