ＩＴ業界受注構造

言わずと知れたＩＴ業界の一般的な受注構造図です。一般的に、エンドユーザーから直接案件を受注している元請会社が顧客管理、要件定義、プロジェクト管理を行い、開発以降フェーズがパート名企業（いわゆる2次請企業、３次請企業）が行っているのが現状です。お客様（エンドユーザー）から貰う賃金に関しても、上流工程の元請が多く、下流工程になるにつれて少なくなっていきます。

業務システム開発プロセスと成果物

プロジェクト計画から運用まで、業務システム開発プロセスと各フェーズにおける成果物の一般的なフロー図をご紹介します。

特徴としては、業務要件定義など上流工程においては、クライアント人数が多いですが、開発フェーズになるにつれて、システム人数が徐々に増えていきます。

開発が終了し、データ移行、本番運用になるにつれて、システム人数は減っていき、実際そのシステムを使用しているクライアント人数（オペレーター等）が増えていくことになります。

そしてまた、業務プロセスの修正や追加案件等でプロジェクト計画～要件定義のサイクルが始まっていきます。

皆さんは、どのフェーズでどのように業務に携わっていますか？

各フェーズにおける成果物の一般的なフロー図。↓クリックするとおおきくなります。

IT LEADERの為の今更聞けない『工事進行基準』

アクシスコンサルティング提供するとてもユニークな特集ページです。単なるＩＴ業界情報、企業情報、案件情報にとらわれない、皆様が気になる情報、知りたいけど中々知れない情報を定期的にお届けします。これは必見です！

IT業界でも2009年4月以降の会計年度から適用される「工事進行基準」。

これからIT LEADERを目指す人であれば、知っておいた方が良いと思います。

という事で３分でわかる工事進行基準の基礎です。

一般的には製品の出荷や納品、検収の時点で売上を計上しているとおもいます。しかし、建物の建設やシステム開発などサービスや物品の提供にある程度時間がかかる契約（工事契約といいます）では、「工事完成基準」と「工事進行基準」のどちらかの売上計上基準が採用されます。

簡単に違いを言えば

• 工事完成基準 ・・・ 工事が完成したら一括して売上計上する
• 工事進行基準 ・・・ 工事のできた分だけ少しずつ売上計上する

です。

例えば、上記の様なプロジェクトがあったとします。それぞれの基準に合わせると

工事完成基準

2008年11月　0円計上
2009年03月　0円計上
2009年10月　１億円計上

工事進行基準

2008年11月　0円計上
2009年03月　4000万円計上
2009年10月　6000万円計上

となります。簡単ですね。

しかし、この基準を適用する為の条件があります。

「『工事収益総額』『工事原価総額』『決算日における工事進捗度』を信頼性をもって見積もること」

簡単に言えば、事前にシステム全体の総売上、総コストが正確に見積もられていて、進捗が正確に把握できることとなります。

つまり事前にFP法などの手法を駆使して事前に正確なコスト計算が必須となるのです。またプロジェクト中の仕様変更にともなう進捗率の修正の対応も大切です。

よってFP法など各種管理手法はより重視されそうです。今後のキャリアアップのために、勉強しておくと良いかもしれません。

プロジェクトリーダー・プロジェクトマネージャーの必要性とは

アクシスコンサルティング提供するとてもユニークな特集ページです。単なるＩＴ業界情報、企業情報、案件情報にとらわれない、皆様が気になる情報、知りたいけど中々知れない情報を定期的にお届けします。これは必見です！

現在、500人月以上の大規模プロジェクトでは、5割近くで工期遅れが発生し、その約3割近くの企業がシステムの品質に不満を持っています。

（社）日本情報システム・ユーザー協会調べ

よって、当然のことながらシステム開発におけるプロジェクトマネジメントはますます重要視されてきています。

プロジェクトマネジメントにおける一般的な問題点としては・・・・

• 納期が守れない
• 品質が低い
• プロジェクト予算がオーバーとなり赤字になる
• 顧客満足度が低い
• メンバーが疲れきってしまう

などがあげられます。

それでは、納期を守る、高い品質を出す、黒字化する、顧客満足度をあげる、メンバーのモチベーションをあげるにはどうすればいいのでしょうか？

そもそもプロジェクトマネジメントとは何でしょうか・・・？

定義は様々で、例えばPMBOK（※１）では、プロジェクトを遂行する際に、スコープ(プロジェクトの目的と範囲)、時間、コスト、品質、人的資源、コミュニケーション、リスク、調達、統合マネジメントの9つの観点(「知識エリア」と呼ばれている)でマネジメントを行なう必要があるとしています。

ISO１０００６（国際標準化機構）では、プロジェクトの目標を達成するために、プロジェクトの全側面を計画し、組織し、監視し、マネジメントし及び報告すること、並びにプロジェクトに参画する人々全員への動機付けを行うことと提唱しています。

世界で最も有名な経営学者のＰ．Ｆ．ドラッガーは『マネジメントの目的は成果を出すことである。つまり、プロジェクトマネジメントの目的はプロジェクトで成果を出すことである』、とうたっています。

システム開発会社や事業会社による、プロジェクトマネジメントに共通するポイントとしては、『プロジェクトにおいて成果を定め、実行計画を立て、その成果を達成するために進捗マネジメント、リスクマネジメントをすること』があげられています。

• 成果（目標、目的、要件等）の設定
• 実行計画（作業分解、作業フローとスケジュール、作業割り当て）
• 進捗マネジメント（作業を予定通り実行する）
• リスクマネジメント（トラブルの発見・解決をする）

とはいえ、やはりプロジェクトマネジメントは難しいですよね。

それは、なぜか・・・

• 成果が決まらない（要件が変わったり、膨らむため）
• 実行計画にもれがある（すべての必要な作業を洗い出せないため）
• 作業が予定通り進まない（メンバーがおもったとおりに動いてくれないため）
• リスクマネジメントができない（プロジェクトの中身が見えないため）

これに関しては、プロジェクトを受注する側だけの責任ではなく、発注する側からの反省点としても、

• 仕様の定義が不十分である
• 要求仕様を明確に提示しない

などをあげており、システム開発のトラブルの原因の多くは要件定義に起因していると考えられています。

システムを開発にはお客様との協力は不可欠であり、改めて、上流工程（現状分析、要件定義等々）を慎重に行うことが成果を達成するためのプロジェクトマネジメントに繋がるのだと思います。

尚、ＩＴ企業の現場の方とお話をすると、主に以下の様なリーダー像を耳にします。

• 業務・技術など何かしらに強い自信がある。
• 部下に謝ることが出来る。
• 指示だけでなく、自分でも動くことが出来る。
• リスクマネジメントがしっかりしている。
• 判断・決断が的確で、早い。
• 顧客に言いなりでなく、顧客も巻き込んでプロジェクトをマネジメントできる。
• 自分で仕事を抱えない。
• 説明が上手。

また、大手Ｓｉｅｒでご活躍中の現役のプロジェクトマネージャーの方は、

『リーダーとは単なるマネジメント者ではなく、辛いところに自ら入って切開いていき、チームのあるべき方向性をメンバーに示していくことだと思います。

また、メンバーとは出来る限り距離を置かないようにし、親子ほど年齢が離れた新卒の社員に対しても話しやすい雰囲気作りを意識し、常に社内を歩き回り、定期的な意見交換をしています。』と仰っていました。

皆さんにとっての理想のプロジェクトリーダー・プロジェクトマネージャー像とは何でしょうか？