SIerだけがプロジェクトをやっているわけじゃない。

IT業界のSIerとして日々プロジェクトに参加していると、ともすればプロジェクト＝SIerのシステム開発プロジェクト、という気分になってしまうが、それは大きな間違いだ。プロジェクトの定義は、PMOBOKによれば、『プロジェクトとは、独自の製品、サービス、所産を創造するために実施される有期性の業務である。』なのだから、業界など問わない。むしろ、IT業界以外のプロジェクト規模の方が、圧倒的に歴史は古いし、規模も大きい。

特に、軍事、建設、エンジニアリング業界などは、『プロジェクト・マネジメントの大先輩』というべき存在で、古来からさまざまなプロジェクト・マネジメントに対して試行錯誤して来た業界であり、結果として近代プロジェクト・マネジメントにおけるセオリーの多くが、これらの業界のノウハウを元に構築されている。

システム開発と建築のアナロジーは昔からよく取り上げられ、最近はその違いに着目されることが多い。だいたいの場合、その論調は建築とシステム開発は違うところが大きいので、そのノウハウを流用するのは間違いだ、という方向で語られる。そこでやり玉に挙げられるのが、人月管理や、ウォーターフォール型開発だ。

確かにそれは一理あるところもあるのだが、最近思うのは『システム開発は、他とは違うんだ！』という論調に引っ張られ過ぎて、歴史のある（先にさんざん苦労している）業界のノウハウを学ぶ人が非常に少なくなってきている気がする（その割に、海外で流行ったXPやSCRUMなどのアジャイル開発プロセスを、違いを検討せず、喜々として取り入れるのはおかしな話だ）。

違いを自分の頭で検討しながらも、他業界のノウハウを学ぶことは、一つの方向性に凝り固まった頭をクリアにする意味でも、気づかなかった知見を再発見する意味でも、非常に意義があると思う。『愚者は経験に学び、賢者は歴史に学ぶ』と言うように、他業界の経験＝歴史から、多くを学びたい。

プラントエンジニアリング業界に、プロジェクト・マネジメントを学ぶ。

ここで紹介するのは、プラントエンジニアリング業界で、御三家と呼ばれている日揮株式会社 の佐藤知一氏だ。佐藤氏は、日揮で大規模プロジェクトマネージャーとして活躍し、著書や講演、ブログ等でその様々なノウハウを公開している。

佐藤氏のブログ：『タイム・コンサルタントの日誌から』

プラントエンジニアリングとは、要は石油プラントや工場などの建設プロジェクト・マネジメントに特化した会社で、純粋プロジェクトマネジメント集団とも言える。クライアントも建設業者も別にいながら、そのプラント建設の『プロジェクト・マネジメント』を担う。

プロジェクトの規模は、IT業界と一桁二桁は優にちがう。100億円規模で、小規模プロジェクトといったところだろう。佐藤氏は、そんなプロジェクトを取り仕切りながら、SIのプロジェクトマネジメントも行い、エンジ業界とSI業界のプロジェクト・マネジメントに対する考え方の違いなどを指摘されている。

ほぼ10年近くにわたりブログに記事を掲載されているので、そのノウハウの蓄積は膨大だ。自分がこれまで拝読させて頂いた中で、特にSI業界のプロジェクトに役に立つと思われる記事をピックアップしてみた。

工程管理について

超入門・工程管理
超入門・工程管理（２）　オフィスワークの工程管理はなぜ難しいか
超入門・工程管理（３）　スケジュールを実行可能にするための『７つの処方箋』

計画を立てた上で、それを着実にこなしていく『工程管理』＝スケジュール管理。これが上手く行けばプロジェクトはほぼ成功したも同然だが、大抵計画とかけ離れた状態になって、修正に修正を重ねた計画からは当初の目的もあやふやになっている・・・。失敗プロジェクトに良くある状態だが、これを避けるための『工程管理』とはどうあるべきかを、工程管理とは、“実行可能な計画を作って、それを守ること” であるという1点に立脚し、その具体的なノウハウが書かれたエントリ。

特に（２）でオフィスワークの工程管理がなぜ難しいのか、というポイントに着目しており、これは正しくSIerの工程管理の難しさを表している。SIerの全ての作業はオフィスワークだからだ。

佐藤氏は、記事中で以下のように原因を分析する。

そして、こうしたオフィスワーク主体の工程では、たとえスケジュール計画を立てても、その実行可能性を簡単に保証できない、という問題が生じます。計画上の納期は3ヶ月後です、といっても、技術も営業も（そして顧客も）疑心暗鬼でいるのです。そこで、どうしても確認・連絡・調整のやりとりが多くなる。そうするとコミュニケーションに手間をとられて、なおさら遅れていく。悪循環ですね。このように、計画の実行可能性を検証することが困難になる理由は、大きく４つあると私は考えています。まず第１に、オフィスワークのスケジュールは計数管理に乗せにくい、という問題があります。次に、受注設計生産では、外部のプロセスの比率が高い、という事情があります。第３の理由は、オフィスワークでは手戻りによるやり直し（リワーク）のリスクが無視できない、という点です。そして、第４は、そもそも工程が複数の部門をまたいで遂行されるため、全体像や責任の所在がわかりにくいことです。

超入門・工程管理（２）　オフィスワークの工程管理はなぜ難しいか

これらの根本的な原因に対し、佐藤氏は7つの処方箋を提案する。クリティカル・チェーン的なマネジメントの要素や、マイルストーンとフォアキャスト（Forecast Date：見込み日）管理に着目する点など、現実的な対案が非常に役に立つ。

プロジェクト・マネジメントのハードスキルについて

佐藤氏は、一貫してプロジェクト・マネジメントに対するハードスキル（近代的なマネジメント技術）の重要性を主張されており、リーダーシップなどの『ソフト・スキル』偏重の風潮に疑問を投げかけている。

お勧め: プロジェクト・マネジメントにリーダーシップ論は要らない

では、その具体的なハードスキルとして重要なポイントは？という点に関しても、非常に有益な記事を掲載されている。

お勧め: ＷＢＳのつくり方

WBSはマスターを作成し、プロジェクト間での共通言語とすることが最重要であるという点に基づいたWBS入門。

マイルストーンは中点で測れ

計画が立てられず、いつまで経っても９０％進捗のタスクをいかに管理し、計画を立てられるようにしていくかのノウハウ。

アーンドバリュー分析の落とし穴

EVMSが万能ではない理由を説明する。タスクのプライオリティに差がある以上、クリティカルパスの進捗が定量的に分からず、全体を均してしまうSPIやCPIは、本質を見誤る可能性があると警鐘を鳴らす。

お勧め: Excelで工程表を書いてはいけない

かなり物議を醸したエントリ。論点は明確で、

2. クリティカルパスをリアルに追えない
3. 選考作業が遅れた場合の影響範囲がわかりにくい
4. スコープの追加や、WBSの変更に対応した修正が面倒

という3点を問題に挙げている。当然これらをクリアしないとExcelは『ロジック無き絵』に過ぎなくなってしまい、プロジェクト・マネジメントに使えるものではない、というのが佐藤氏の主張だ。

この問題はSIerの計画とスケジュール管理考えるときに、もっとも大きなポイントだろう。議論のポイントは、『果たしてSIerのプロジェクトでクリティカルパスを管理することが可能なのか？』という点だ。

SIerのプロジェクト・マネジメントを進化させる上で避けては通れないポイントなので、また別エントリで詳しく考察したい。

タイム・マネジメントの心得　～あなたを多忙から開放する10の方法～

WEBのIT雑誌である、EngineerMindに掲載された、個人レベルでのパーソナル・タイム・マネジメントならびに数人のグループレベルでのスケジューリングの技法をやさしく解説した記事。プロジェクト・マネジメントのハードスキルを易しく解説した連載。

お勧め: PM2008レポート：大規模プロジェクトを成功に導く見取り図のつくり方

大規模SIプロジェクトを担うマネージャー必見の記事。Project Management Conference 2008 (PM2008) にて佐藤氏が講演された内容。エンジニアリング業界とSI業界のプロジェクトの比較に始まり、共通する点でどのようなマネジメントが必要なのかが語られている。

成果物に対するID付け、WBSのマスターこそが秘伝であること、予定と実績だけでなく、フォアキャスト（見込み日）の管理がいかに重要であるかなどが、図解でわかりやすく説明されている。

プロジェクト・マネジメントのありように対して

プロジェクトの根源的なところに立ち戻って、プロジェクト・マネジメントに関する諸処の問題はどうして発生するか？を考えるエントリ群。プロジェクトマネージャーになったばかりの人より、プロジェクトをこなして中堅になった時に、立ち戻って読み直したい記事ばかり。

課題、ペイン、そしてソリューション
課題、ペイン、そしてソリューション（２）　ＩＴ産業の中核問題とは

クライアントのペイン（痛み）から、ソリューション（解決策）に通じる道を説明する中で、IT企業が陥っているワナに言及する。

『「要求分析」という最も知的に価値のある部分ではなく、「システム実装」という力仕事の部分で儲けようとする、歪んだビジネスモデル』

という指摘は仰るとおり。

マネジメント、はじめの一歩

マネジメントとはなにか、をドラマ形式で学ぶ。先生の説明が面白い。

「いいかね、マネジメントとは自分で球を投げたり打ったりすることじゃない。監督はピッチャーより速い球を投げられるか？　ちがう。マネジメントとは、“人にやってもらうよう仕向けること”なのだ。だから、チーフ・デザイナーは、自分でエスキースを描いている間は、全然マネジメントなんかしてないことになる。なのに、ちょっと経験年数がたったからといって何の訓練も与えずにデザイナーを課長に任命して、それでマネジメントができると思っている。人を動かすすべを何か学んだのか？　プレイイング・マネージャーしか知らない企業が日本には多すぎるのだよ。だからみな変化に弱いのだ。」

マネジメント、はじめの一歩

お勧め: マネジメントと管理はどこが違うか
お勧め: プロジェクト・マネジメントとはどういう仕事か

自分も、プロジェクト・マネジメントを、『プロジェクト管理』と同等に語るのに強い違和感を持つ。
実際のプロジェクト・マネジメントの組織は、

• マネジメント
• コントロール
• アドミニストレーション

の3つに分けられて、それぞれミッションの違う特殊スキルである、ということを明確に述べている。
PMOチームに配属されて、いったい何をするべきなのかと混乱しがちな若手にお勧めのエントリ。

目標、計画、ターゲット
目標、計画、ターゲット（２）－計画の二重帳簿はなぜ発生するか
目標、計画、ターゲット（３）－共通言語をつくろう

プロジェクト開始前に、必ず読みたいエントリ。
このエントリの中では、それぞれ目標、計画、ターゲットがどういう定義のもので、どういう役割を果たすかという説明がなされている。プロジェクトの開始段階で最も明確にし、『プロジェクト計画書』に記述するべき内容だが、とかく曖昧なままにされがちだ。この3つのエントリを読むことで、それらがいかに大切でかつ全く別のものなのか、ということがはっきりと分かる。

あなたのプロジェクトにおける『使命（ゴール）』と『目的』と『目標』を明確に区別して語ることができるだろうか？それがまず、プロジェクト・マネジメントの第一歩となる。