こんにちは。倉内です。
開発プロジェクトの失敗話はあとを絶ちませんが、誰も最初から「よーし、炎上させちゃうぞ！」と思っているわけではなく、進行中にだんだん予想（見積もり）から外れていき結果的に破綻するというパターンが多いです。
特に受託開発は顧客の予算とスケジュールはおおよそ決まっており、その中でいかにうまくやるかにかかっているので、問題が発生し想定外の工数やコストがかかるとデスマーチへまっしぐらになるリスクがあります。
開発プロジェクトは、開発規模やスケジュール、要件などが案件ごとに異なり、成功事例とまったく同じことをしても必ず成功するとは限らないのが難しいですよね…。
また、たとえ過去に似ているプロジェクトがあったとしても参画するメンバー（のスキルや経験値）が違う場合は思い通りにいかないことも多々あります。
ただしプロジェクトマネジメントが適切になされていたら炎上を最小限に抑えられたはずというケースも存在します。
そこで今回は、失敗事例から「どうマネジメントしていたら炎上を回避（軽減）できたのか？」を考えながらプロジェクトマネジメントについて学んでいきたいと思います。
プロジェクトでマネジメントするもの
本題に入る前に少し基本の基本をおさらいしておきます。
プロジェクトでマネジメントしなければならないのは、品質（Quality）・費用（Cost）・納期（Delivery）の3つです。これらの頭文字を取ってQCDと呼びます。
QCDはトレードオフの関係と言われていて、短期間で納品もしくはリリースしたい（納期最優先）なら費用は高くなります、医療に関わるシステムなど不具合が許されない（品質最優先）場合は開発・テストの期間は長めに取ります、といったように調整が必要です。
しかし…受託開発の案件で考えてみると…
図のとおり関係各所（ステークホルダー）とどう合意を取るか、すなわちQCDをどう定めるかは非常に難しい問題です。
発注者側からは「短期間で安く高品質なシステムを作ってほしい」と求められるかもしれませんが、常に現実的かどうかを考える必要があることを念頭に置いておきましょう。
なお、もしここまででよく分からない用語があった場合は「情報処理入門 マネジメント編01：プロジェクトマネジメントを知ろう」で詳しく説明していますのでぜひごらんください。
失敗事例から考えるプロジェクトマネジメント
現実にはプロジェクトは複合的な条件で破綻していくので一概には言えないのですが、よく問題になる事例を少し単純化して見てみましょう。
事例1：品質管理を怠った結果の対応工数増加
とあるシステム開発プロジェクトで、プロジェクトメンバーの頑張りでなんとか期日通りに完成し、お客さまの本番運用を想定した試験が開始されたが――…
PM「顧客受け取り試験で不具合が多すぎて、メイン機能すらまともに動かないとお客さまが怒り狂っている……」
上司「いったいどんなテストをしたんだ！ 報告しろ！」
PM「えっ どんなって…。ちゃんとやりましたよ！」
上司「お客さまからクレームが入った。全部やり直しだ！ ただし納期変更はなし！ 追加人員もなし！」
PM「ぇええええ」
これは品質管理（クオリティマネジメント）を適切におこなっていなかったために発生した問題です。
クオリティマネジメントでは、仕様に定められた機能や性能を実現できるようプロジェクトを管理します。詳しくは「01:プロジェクトの品質を管理しよう」で学ぶことができます。
システムはテストによって品質が担保されますが、開発規模やテスト工程に応じたテスト実施項目（チェックリスト件数）の消化状況、バグ密度などを管理する必要があります。それらの管理を怠るとテストを実施したことが示せませんし、テストが適切だったかの判断もできません。
また、品質が目標に届かず品質向上のためにテストのやり直し、もしくは追加テストを実施することもあります。イメージとしては、納期には間に合わせたし機能も全部実装したけど、突貫工事のため不具合多発…という感じでしょうか。
こうなると見込んでいなかったテスト工数がかかりますし、摘出した不具合を修正する工数もかかります。結局無理なスケジュールでやり遂げてもあとでこうなってしまったら意味がないですよね。
もちろん「テスト項目さえ消化したら品質は問題なし！」というわけではないのがシステム開発の難しいところなのですが、少なくとも単体試験の段階から、必要なテスト・不具合摘出をやっておけば取り返しのつかない事態は防げます。
摘出した不具合の管理は「バグ管理票（B票）」や「信頼度成長曲線（バグ曲線）」でおこなうのが一般的です。
事例2：スコープの明確化を怠った結果の利益損失
競合他社が複数いるコンペ形式のシステム開発案件で、見事受注を勝ち取ったとあるシステム会社だったが――…
顧客「この金額で全要件を満たしていたのは君のところだけだよ。期待してるよ！」
PM「ありがとうございます！ がんばります！」
～プロジェクト開始してしばらく～
SE「これお客さまからサーバーとPC購入費込みの予算だって言われたんですけど…本当ですか」
PM「えぇええ そりゃ安いはずだわ…」
SE「あと、お客さん側でやるって言ってた他システムとの連携バッチ、うちがやるはずって言い張ってますけど…」
PM「えっ！？ とりあえず人追加してして対応するしかないか……ダメだ…利益どころか大赤字だ！」
これはスコープの定義が甘かったことと、ずさんな予算管理が招いた結果と言えます。
コストは開発だけに発生するのではありません。この事例のようにサーバなど物品購入の費用がプロジェクト費用に含まれる場合もありますし、間接部門の費用、調達費用、元請けの会社がいる場合はマージン、そしてもちろん自社の利益も……すべてを盛り込んで見積額を提示する必要があります。
詳しくは「02:プロジェクトの予算と実績を把握しよう」で説明しています。
この例は極端ですが、実際スコープが曖昧なままプロジェクトが進行し、どちらが担当するべき作業項目かあとになって揉めるということはあります。そしてたいていシステム会社が涙をのみます…。
特にお客さまにとっては当たり前と思っていることが、業務理解が浅いSEが担当した場合にスコープから漏れている場合がありますので注意が必要です。（具体的には他システムとのデータ連携部分や、帳票の出力機能など）
スコープの明確化はプロジェクトマネジメントにおいて非常に重要な作業です。詳しくは前のレッスンの「04:プロジェクトの範囲を明確にしよう」で説明していますので合わせてごらんください。
事例3：ずさんなスケジュール管理による遅延
システム開発案件を受注し、要件定義・設計工程はスケジュール通りに進行、問題なく開発工程に取り掛かったはずだったが――…
PM「ちゃんと実装工数見積もってスケジュール引いたのに遅れてるじゃないか…」
開発担当1「この機能、あっちの機能が完成しないと着手できないんですよ」
PM「えっ、2人で並行してやるスケジュールにしてるのに！」
開発担当1「まあバッファでなんとか……あれ！？ このスケジュールバッファ0！？」
PM「だって類似案件でもっと短期間でできてたし…」
開発担当2「すみません、この機能のところ担当者入ってないんですけど」
PM「あっ、手の空いた人にお願いしようと思ってたんだった…今から着手じゃ間に合わん……」
スケジュール管理は基本中の基本ですが、計画したどおりに進めるというのはシステム開発プロジェクトにおいて難易度が高いミッションです。
最初はほんの少しの遅れだと思い放置して、のちのち取り返しがつかなくなる…なんていうことはよくあります。スケジュールについては「03:プロジェクトのスケジュールを管理しよう」で学習できます。
受託案件では、多くの場合納期厳守のためスケジュールを作成するのはとても重要度が高い作業です。
WBSによって、「どんな機能を開発する必要があるか」「担当者」「開始・終了日」を明確化していればこんな事態は防げますが、見落としがちなのが機能実装の前後関係です。B機能はA機能が完了してから…といった依存関係をしっかり把握する必要があります。
もちろんPM自身の開発経験が豊富で、システムもよく理解している場合はいいのですが、大規模案件になってくると把握できない部分も出てきます。
ここではよく使われているスケジュール管理の手法についてご紹介します。
- WBSからガントチャートを作る
ガントチャートを使うと、作業スケジュールの依存関係を視覚的につかみやすくなり、進捗管理がしやすくなります。
一方でメンテナンスの工数がかかったり、スケジュールに大きな影響がある作業を見つけにくかったり…という欠点もあります。
Excelでマクロ組んで使ったり、専用のWebアプリを会社が買ってたりいろいろですが無償で利用できるツールもあるので試してみてください。
ちなみにWBSの作り方については、前のレッスンの「05:WBSをつくってみよう」で紹介しています。
- PERT図でスケジュール分析をする
PERT図はアローダイヤグラムとも言います。PERT図ではプロジェクト全体を完了させるのに必要な最小時間（クリティカルパス）を算出することができます。
システム開発のプロジェクトでは、ひとつの作業の遅れがあとの作業にも影響して遅延が大きくなることがしばしば発生するため、プロジェクト全体を把握しつつ各工程の状態（「絶対に遅れてはならない作業は？」など）も把握するにはPERT図が役に立ちます。
（参考）かんたん！大型プロジェクトをPERTで把握する知見 - pixiv inside
また、情報処理技術者試験ではPERT図に関する問題はよく出題されるため受験を予定されている方はしっかり理解しておきましょう。
（参考）過去問題：平成29年春期問51 アローダイアグラム｜基本情報技術者試験.com
まとめ
失敗事例をもとにプロジェクトマネジメントで押さえておくべきところやよく使われている手法などをお伝えしてきました。
現実にはPMの役割は本当に多岐にわたっていて、経験や勘に頼らざるを得ない場面もあります。ただ、今回お伝えした内容はプロジェクトマネジメントの基本ばかりなので、これからPMやPLを任される可能性のある方は知っておいて損はありません。
また、見積もりやスケジュール作成などは機械的にやる部分もありますが、結局手を動かすのは人なので、計画通りに進めるのが得意な人・苦手な人、詰まったところをサッと相談してくれる人・なかなかできない人などいろいろなメンバーを束ねる力も必要になってきます。
全部PMが面倒見ましょうとは言いませんが、QCDの管理に加えて、そういった部分のマネジメントというか気遣い的なところもプロジェクトの円滑な進行には欠かせないのかもしれないな…と思います。
プロジェクトマネジメントは大変ですがやりがいがありますし、エンジニア（SE）のキャリアパスとしては目指す人も多いと思うので基本知識を頭に入れて経験を積んでいきましょう。
paizaラーニングでは、今後も「情報処理入門マネジメント編」のレッスンを追加していきますのでご期待ください！
「paizaラーニング」では、未経験者でもブラウザさえあれば、今すぐプログラミングの基礎が動画で学べるレッスンを多数公開しております。
そして、paizaでは、Webサービス開発企業などで求められるコーディング力や、テストケースを想定する力などが問われるプログラミングスキルチェック問題も提供しています。
スキルチェックに挑戦した人は、その結果によってS・A・B・C・D・Eの6段階のランクを取得できます。必要なスキルランクを取得すれば、書類選考なしで企業の求人に応募することも可能です。「自分のプログラミングスキルを客観的に知りたい」「スキルを使って転職したい」という方は、ぜひチャレンジしてみてください。
