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

• #プロジェクトマネージャー

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

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

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

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

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

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

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

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

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

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

ニーズをまとめるスキル

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

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

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

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

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

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

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

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

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

アーキテクトスキル

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

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

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

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

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

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

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

1. ソフトウェアによる回避策

   • 最大同時ユーザ数、最大同時起動数、同時並行処理数をソフトウェア的に制限する。
   • 多大な負荷を掛ける可能性のある機能に制限をつける。単純な例としては、自由検索を制限して検索条件を絞るなど。
   • トランザクションの機能や大きさを制限し、データベース負荷を軽減する。
   • 1回の検索結果の件数、データ量を制限して、ネットワーク、サーバへの負荷を軽減する。

2. ハードウェアによる回避策

   • ネットワーク、サーバ、ディスクなどのハードウェアリソースの負荷分散を図る。
   • ネットワーク、サーバなどのハードウェアリソースを増強する。

3. 人による回避策

   • 運用上の制限を設け、システムに過剰な負荷が掛からないようにする。

運用面のスキル

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

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

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

ドキュメントスキル

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

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

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

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

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

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