プロジェクトマネージャ (6/11) | IT業界職種研究 | IT転職 エージェント リーベル


IT転職 リーベル ホーム > IT業界職種研究 > プロジェクトマネージャ

プロジェクトマネージャ | IT業界職種研究

プロジェクトマネージャ project manager

竹政 昭利 株式会社オージス総研

大手外資系企業にてプロジェクトマネージャとして活躍中。製造、金融、物流等、数多くの大規模システム開発プロジェクトの経験を持つ。

第2章:プロジェクトマネージャに必要なスキル

第1回 プロジェクトで必要とされるスキル

ここからは、PMを志望している人達向けに、PMとして要求されるスキルにはどんなものがあるか、そして、スキルアップしていくにはどうすれば良いか、についてお話します。

PMには、マネジメントスキル、リーダシップ、ニーズをまとめるスキル、アーキテクトスキルなど多様なスキルが要求されます。しかし実際には、プロジェクトの規模や性格やPMの立場によって、あるいは顧客企業の性格(端的に云えばお客様の性格)によってPMに要求されるスキルは違ってきます。

プロジェクトの規模が小さいと、PMは技術系のリーダやアプリケーションの開発リーダを兼ねることがあり、業務知識や技術知識が要求され、業務アプリケーションの仕様詰めに自ら率先して参加しなければならないこともあります。反対にプロジェクトの規模が大きくなると、PMは複数のサブチームから構成されるプロジェクトチームを取りまとめる役割を担うことになり、直接的な技術力よりもチームを率いるリーダシップが求められます。

プロジェクトの規模がもっと大きくなれば、実質的な作業や個々の判断や進捗報告までもサブリーダに任せ、顧客の上位マネジメントとのコミュニケーションが主な仕事となります。

従って、大規模プロジェクトのPMをやってきた経験が小規模プロジェクトで通用するとは限りませんし、その逆もまた真です。

プロジェクトを進めるスキル

PMにはいろんなスキルが要求されますが、最も重要なのは、プロジェクトを計画し、かつプロジェクトの進行を阻害する要因を解決して推進して行く能力です。

イメージ

既に説明したようにプロジェクトとは何か新しいものを造り出すために実施される、新しい一連の作業ですので、要件分析、基本設計、詳細設計、プログラム作成、システムテストなどの各工程が初めからきっちり定義されているわけではありません。既成の製品の場合には、製造工程がきっちり決められていて工程を進めれば製品が完成しますが、プロジェクトの場合は工程そのものを新しく計画して実施しなければならないため、事情が全く違います。

例えば、既に「第1章 PMの仕事 (3)スケジュールを立てる」に述べたように、要件分析フェーズでは業務要件の記述だけしていればいいわけではなく、必ず実現性を吟味し、次の工程のことや全工程のことを考えなければなりません。

プロジェクトが失敗する理由の一つは、前の工程で検討議論すべき事柄を、「詳細に突っ込むと議論が沸騰して時間が無くなる」、「実現方法などの細かいことは、後の工程でやればよい」といった理由で放置し、後の工程を担当する人に振ってしまうことです。後の工程になればなるほど時間が無くなって来ますので、後工程の担当者は前工程からの未解決の問題をこなすことに忙殺されてプロジェクトが進まない、ということになりがちです。

ニーズをまとめるスキル

PMやプロジェクトチームは、ユーザニーズをいかに聴き出して、どの範囲をどのようにシステム化するかを決めて、プロジェクトを方向付けなければなりません。必ずしもPM自身が直接ユーザニーズをまとめる必要はありませんが、このような上流工程についてはPM自身にもスキルがないとプロジェクトのコントロールができません。

以下に、ユーザニーズをまとめる一般的な作業項目を挙げますが、一般的な業務フローや状態遷移図、及びDFD、ER、UMLなどの知識が不可欠です。

なお、ユーザニーズをまとめる場合には「木を見て、森を見ず」にならないように大局的な目を持つ必要がありますし、逆に細部のニーズが全体に及ぶ大事に発展することもあるので注意が必要です。

業務フローをまとめシステムの入出力をまとめる

エンドユーザ、データ管理者、システム管理者などの登場人物(アクタ)、入力(画面)、出力(画面や帳票)、当該システム、及び関連システムを横に並べて、その間の関係(指示、データの流れ)を図化し、ユーザの持つイメージを引き出します。このような図は以前から一般的に業務フロー(図)という名称で作られていましたが、現在ではUMLのユースケース図、シーケンス図、アクティビティ図がよく使われています。さらにコラボレーション図などで詳しくシステム仕様を分析することで、システムの必要な機能、ネック、リスクなどが明らかになります。

具体的な画面、帳票でユーザとイメージ合わせをする

ユーザにはDFD、UMLやER図に慣れていない人もいますので、画面や帳票で具体的にイメージ合わせをする必要があります。特にバックグラウンドやキャリアが全く違う人と打ち合わせをする場合には、お互い誤解が発生しやすいので注意深い確認が必要です。

エンティティを抽出し、データモデルを定義する

データの中から重要なエンティティを洗い出し、そのエンティティをユニークに指し示すコードと属性を明らかにします。さらにエンティティ間の関係をER図(またはエンティティクラス図)に表してまとめて行きます。

アーキテクトスキル

イメージ

「第1章 PMの仕事 費用、技術のマネージメント」にも記述しましたが、以前と違ってシステムは複雑化しており、システム構築は単にプログラム作成ではありません。システムを構築するためには、論理的な構造と物理的な構造を把握し、指示やデータの流れがどのようになるのか、どのようにするかを検討、設計して、リスクを把握して防止するというように、システムのアーキテクチャをきちんとコントロールしなければなりません。

そのため、PMにはアーキテクト的なスキルが必要で、システムの機能、パフォーマンス、コストの3つの観点からチェックし、アーキテクチャがおかしな方向に行かないようにコントロールしなければなりません。

特にシステムのパフォーマンスには留意する必要があります。以前、2フェーズコミットを多用してパフォーマンスが出せず、捨てられてしまったシステムがありました。あとでよく考えてみると、2フェーズコミットは必須ではなかった、ということでした。幾ら機能が豊富でもパフォーマンスがユーザの許容範囲にないと、実際の業務で使えないものになってプロジェクトは失敗に終わってしまいます。

PMはこんなことにならないように、機能、構造、負荷の観点でメンバーやミドルウェアのコンサルタントと討議を重ねて最適解を導き出す必要があります。

具体的には下記のような処理パターン別に、アプリケーションプログラムがネットワーク、サーバのCPU、メモリ、ディスク、データベースなどにどのように負荷を掛かるかを予測します。

  1. 会話型処理・・・画面等を介してユーザからの要求を処理する会話型処理。
  2. 会話型遅延処理・・・会話型処理によって起動される帳票作成などの遅延処理
  3. バッチ処理・・・時刻やイベントの発生によって起動される処理

パフォーマンスネックが予想されるのであれば、下記のような対策を講じる必要があります。

  1. ソフトウェアによる回避策
    • 最大同時ユーザ数、最大同時起動数、同時並行処理数をソフトウェア的に制限する。
    • 多大な負荷を掛ける可能性のある機能に制限をつける。単純な例としては、自由検索を制限して検索条件を絞るなど。
    • トランザクションの機能や大きさを制限し、データベース負荷を軽減する。
    • 1回の検索結果の件数、データ量を制限して、ネットワーク、サーバへの負荷を軽減する。
  2. ハードウェアによる回避策
    • ネットワーク、サーバ、ディスクなどのハードウェアリソースの負荷分散を図る。
    • ネットワーク、サーバなどのハードウェアリソースを増強する。
  3. 人による回避策
    • 運用上の制限を設け、システムに過剰な負荷が掛からないようにする。
運用面のスキル

システムは正常に運用されて「ナンボ」のものですから運用面の機能整備は重要です。最低限、下記の方式、手順、機能などについて明確化しておく必要があります。

  1. 運用手順(日次、週次、月次、年次で行うべきこと)
  2. システムの停止、起動手順
  3. 障害監視方式
  4. OS、プログラム、ファイル、データベースなどのバックアップ・リストア方式
  5. 障害発生時のフェイルオーバ手順、復旧時のフェイルバック手順
  6. プログラムライブラリの更新方式
  7. バッチジョブ管理
  8. セキュリティ管理(ユーザ管理、データ管理、パスワード管理など)
  9. システム時刻管理、カレンダファイル管理

一般的に言ってアプリケーションの仕様詰めや開発が優先され、運用面の整備は後回しになりがちです。そうなるとアプリケーションは完成したけれど、結局は運用できないということになりかねません。PMはアプリケーション側面の進捗と同時に、運用基盤側面の進捗にも注意する必要があります。

ドキュメントスキル

プロジェクトで作成する主なドキュメントは以下のように4つに分類できます。それぞれの文書について標準的な目次、内容を抑えておけば、新たなプロジェクトにも応用が効きます。PMは、特に「プロジェクト管理文書」について、書くべき内容、形式などを把握しておく必要があります。なお、必ずしもこれらの文書すべてを作る必要はなく、小さめのプロジェクトでは特にプロジェクト管理文書を簡略化します。また、勿論、以下の文書以外にも様々な文書があります。

  1. プロジェクト管理文書
  2. 進捗報告文書
  3. 成果物開発管理文書
  4. 成果物関連文書

プロジェクト管理文書には、以下のようなものがあります。

ドキュメント 内容
スコープ定義書 成果物の変更手順などについて記載します。
スコープ変更管理書 プロジェクト体制を1ページの図に表します。
プロジェクト体制図 メンバーと役割を表にします。
役割分担表 メンバーと役割を表にします。
人員計画表 必要なマンパワーを時系列で表します。
スケジュール表 主なイベント、マイルストーン、主な作業の開始と終了を表します。
作業項目表(WBS) 作業項目ごとの開始日、終了日、及び進捗度合いを記録します。
進捗管理表 主なイベント、マイルストーン、主な作業の開始と終了を表します。
コスト管理表 コスト計画、実績を時系列で管理します。
リスク管理計画書 予想されるリスクとその対応策について計画します。
変更要求書 成果物の仕様変更要求を記録し、さらにその回答も記録する書類です。
変更管理表 変更要求書を一覧表形式にまとめます。
コミュニケーション計画書 情報(進捗報告、障害報告、仕様変更など)を関係者間でどう共有するかについて計画します。

進捗報告文書には、以下のようなものがあります。

ドキュメント 内容
進捗報告書 実績、予定、問題点などについてまとめた報告書です。
懸案事項一覧 仕様、性能、スケジュール、資源など様々な問題、課題について内容、解決状況について記載します。
障害管理表 システムテストで発生した障害について一覧表で管理します。
障害票 システムテストで発生した障害について1件ごとに記録します。

成果物開発管理文書には、以下のようなものがあります。

ドキュメント 内容
開発標準 アプリケーションアーキテクチャの定義、DBアクセス規約、コーディング規約を決めます。
ディレクトリ定義 開発環境、実行環境のディレクトリ(セキュリティ設定情報を含む)を定義します。
ユーザ定義 OSユーザ、ミドルウェアユーザ(セキュリティ設定情報を含む)を定義します。
共有資源管理 環境変数、TCP/IPポート番号など、共有の資源を管理します。

成果物関連文書には、以下のようなものがあります。

ドキュメント 内容
要件定義書 業務フロー、画面、帳票などの要求仕様をまとめます。
基本設計書 要件定義書を受けて、どうシステム化するか、どう実現するかを記載します。
画面の動作、キーの扱い、帳票の形式など標準化することが重要です。
データベース設計書 論理エンティティの設計、及び物理エンティティの設計を行います。
詳細設計書 基本設計書を受けて、システムを個々のプログラムに分解します。
プログラム設計書 個々のプログラムについて設計します。
単体テスト項目表 個々のプログラムのテスト項目を洗い出します。
システムテスト計画書 システムテストの計画を記載します。一般的には、以下のようなテストが考えられます。
  • テストシナリオを作っての機能テスト、サイクルテスト、ロングランテス
  • 運用機能テスト
  • 障害対応・復旧テスト
  • パフォーマンステスト、ラッシュテスト
システムテスト項目表 システムテストの項目表で、テスト手順も表します。
システムテスト結果報告書 システムテストの結果を記載します。
運用設計書 運用全般の設計(例えば、構成設計、バックアップ・リストア設計など)を行います。
環境設計書、設定書 システムのネットワーク、ハードウェア、ソフトウェア環境について記載します。
特に運用管理者に必要な知識となります。
構成管理表 プログラムライブラリの構成を管理します。
操作マニュアル エンドユーザ、オペレータ向けに操作方法を記載します
運用マニュアル システムの運用管理者向けのオペレーションマニュアルです。

プロジェクトマネージャへの転職をお考えの方へ

IT業界出身のコンサルタントが、
あなたの転職活動をフルサポートいたします。

転職支援サービス
に申し込む無料

このページのトップへ