このエントリーをはてなブックマークに追加LINEで送る

序文

ハッピィ・エンジニアリング表紙

 「見えないものは管理できない」と言われる。システム開発におけるプロジェクトマネジメントというのは、この格言に対する挑戦だともいえる。

 

 建築物と違ってソフトウェアには形がない。したがって、システムができあがって実際に利用される段階になるまで関係者に「見える」形が現れない。機能という無形の完成物を目標とするところにシステム開発の難しさがある。

 

 「見える化」の重要性が叫ばれる今、システム開発プロジェクトはもっとも「見える化」が遅れている分野ではなかろうか。

 

 1980年代後半から2000年にかけて、金融機関を中心に大規模なシステム開発プロジェクトが進められた。私には当時も今もプロジェクトマネジメントの水準に大きな変わりはないように思える。当時から本書に書かれているマネジメント手法の多くは、すでにプロジェクトマネージャの「常識」として十分に浸透していたし、プロジェクトマネージャはこれらの「常識」を活用しようと最大限努力したと思えるからである。しかし、これらの大規模プロジェクトは程度の差こそあれおおむね成功裏に終了し、一方で現在はプロジェクトマネジメントが破たんしているという。いったい何が原因なのか?

 

 技術が進歩し、システム開発のスピードアップが要求されるようになってきたこともひとつの要因であろうが、むしろ判断に必要となる情報と能力の所在が変化してきたことのほうが重要な要素のように思える。

 

 メインフレーム中心の時代は、業務要件だけが判断に必要な情報であったといえる。概要設計・基本設計・詳細設計と続く設計活動の中で業務要件を詳細化し、実装方法(特に異常時の処理)に関してのさまざまな判断が行われる。業務要件実装の判断さえ行えば、それを実現するための技術や方法は限定されており、それ以外の大きな判断は必要ないという時代である。

 

 本書で出てくる「丸投げ」構造というのは、実はこの実装方法判断を下位組織(本書では一次下請け、二次下請け)に権限を委譲する構造と見ることができる。権限委譲の構造であるがゆえに、上位組織である元請けのSIベンダと下請けの会社の間には当然の主従関係が存在する。

 

 この構造が、本書で指摘するさまざまな問題(主人と奴隷の関係、不自然な癒着関係など)を生むことになる。だが、それ以上に問題なのはオープンシステム化・インターネット化した現代のシステム開発では業務要件だけが判断に必要な情報ではなくなったことにより、単なる権限委譲の構造では適切な判断ができなくなったということだ。さまざまな新しい技術や製品が提供され、それを採用するのかしないのか、採用するとしてどのような使い方をすればよいのか、など業務要件以外の判断要素が多くなってきている。いや、むしろこのような情報こそがプロジェクトの成否を決める重要な鍵となっていることも多い。

 

 これらの情報を持っていて適切な判断ができるのは、上位組織にいる元請けSIベンダではない。特定分野に優れたITベンチャー企業などのほうがはるかに豊富な情報と経験を持っている場合が多い。能力が高く情報量も多い者(元請けSIベンダ)が、能力が低く情報量も少ない者(下請け)に、判断に必要な情報を与えたうえで一部の判断権限を委譲するという、これまでの構造が破たんしているのだ。

 

 判断に必要な(重要)情報と能力が偏在化してきたということこそが、現代のシステム開発のプロジェクトマネジメントを難しくしている大きな要因であろう。システム開発に必要な情報と能力がこれまでのマネジメント構造では「見え」なくなってきている。

 

 システム開発は目に見えない対象物を扱うために、どうしても人間関係的側面が重要だ。しかし、上述したように業務要件を中心とする判断権限委譲という人間関係によるマネジメントが、現代では通用しづらくなってきている。これからのプロジェクトマネジメントは多彩なスキルを持った参加者がそれぞれの能力を生かし、協業してシステムを作り上げていく構造、すなわち建設業型の下請け構造ではない、ハリウッド型の新しいプロジェクトマネジメント構造が求められているのではなかろうか。

 

 プロジェクトマネジメント構造の大きな変革期である今、プロジェクトマネジメントのあるべき姿に迫ろうとする本書は、絶好のタイミングで発表されたといえるだろう。

 

 著者の吉田氏とは、これまで多くのシステム開発プロジェクトを乗り越えてきた。採用する技術や規模もさまざまであり、非常に難易度の高いプロジェクトでも苦楽を共にしてきた仲間である。

 

 一緒に仕事をするつど思うことだが、吉田氏の真理探究に対するひたむきな態度と、現実をふまえた解決案を提示する能力の高さにいつも感銘を受けてきた。本書でも吉田氏の能力が随所に表れている。

 

 本書は理想像を追求しながらも、現実の問題にも丹念に目を向ける。現実の問題がなぜ発生しているのかについての洞察なくしては、正しい解決策など生まれようがないからだ。読者は現在発生している問題の本質を掘り起こすことで、教科書で叫ばれている各種手法がなぜ必要なのかが理解できるはずだ。

 

 プロジェクトマネジメントが極めて人間的な活動である以上、同じ問題意識を持ち、目的を共有する仲間が増えることが理想への近道である。本書が多くの読者に読まれることで、新しいプロジェクトマネジメント構造を探求し、実践する同志が誕生することを期待する。

 

株式会社ドリーム・アーツ

取締役営業統括本部長 吉村厚司

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

序文 ハッピィ・エンジニアリング関連ページ

序章 明るい未来に向かって
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
第1章 初めに
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
第2章 呪われた運命からの脱却
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
第3章 プロジェクトの登場人物
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
第4章 ITガバナンス
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
第5章 コミュニケーション
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
第6章 標準化
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
第7章 要件定義
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
第8章 プロジェクトマネジメント
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
第9章 プロジェクト計画
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
第10章 スケジューリングと進捗管理
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
第11章 リスク管理
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
第12章 品質管理
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
第13章 変更管理
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
第14章 火消し
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
謝辞
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング