連載
» 2008年05月15日 12時00分 公開

やる気を引き出すプロジェクト管理(4):不足しているのはスキル? それともプロセス? (2/2)

[安達裕哉,トーマツ イノベーション]
前のページへ 1|2       

精度向上の具体的な施策

 A社とB社の事例では、A社は「標準化」(および「経験者のレビューを受ける」)に重点を置いた対策が、B社の場合は「個人の知識・経験の向上」を中心にした対策が有効であると述べました。

 では、具体的にはそれぞれどのような施策が打てるのでしょうか?

見積もりマニュアルの策定

 A社は属人的な業務を改善し、精度向上を図るために、以下の業務の標準化を推進することにしました。

  1. 見積もり業務
  2. 要件定義業務

 まずは、上記それぞれの業務マニュアルを作成・運用することで、業務の精度向上と社員への周知徹底を図ることにしました。

 以下に、見積もりマニュアルの目次の一例を挙げます。

  見積もりマニュアル
目的 正確な見積もり作成、社員への周知の徹底、プロジェクト管理者のための教育テキスト
外部への
開示
しない
ページ数 20ページ程度
目次
イメージ

 (ア) 見積もりのタイミング
    1. 各タイミングの見積もりの目的
    2. 入手すべき資料

 (イ) 見積もりの書式

 (ウ) WBSの作成

 (エ) 見積もり手順

 (オ) 見積もり手法
    1. 一括請負
       (1) 規模の見積もり方法
       (2) 工数の見積もり方法
       (3) バッファの取り方
    2. 準委任
       (1) 規模の見積もり方法
       (2) 工数の見積もり方法
       (3) バッファの取り方

 (カ) 再見積もりタイミング

 (キ) 過去の経験からのアドバイス事項
     1. 失敗事例
     2. 成功事例

 (ク) 付録(FP法、COCOMO、経験予測)

 
備考    

 A社ではこれまで、見積もり業務は営業マンが個人の経験を頼りに行っていましたが、精度向上のために一部ファンクションポイント法(FP法)を採用しました。しかし、ファンクションポイント法だけでは見積もりの現実的な妥当性を判断することができないため、経験的手法での見積もり結果と突き合わせることで最終的な精度向上を図りました。

 また、見積もりの根拠となる情報を顧客からヒアリングする際のインタビュー項目も併せて標準化しました。そして、定期的に見積もりと実際に要した工数・金額の対比を行うことで、継続的に精度の向上を行います。

 一般的に、見積もりの精度を向上させるためには、以下の手順を踏みます。

  1. インタビューで要件をしっかり聞く
  2. インタビューの結果を基に工数・金額の見積もりを作成
  3. 実際に要した工数・金額を把握
  4. 見積もりと実際を対比
  5. 見積もりと実際に差異が生じた場合、その原因を分析
  6. 上記1から5の繰り返しにより、標準工数・金額を設定

 こうした手順を標準化し、継続して繰り返し実施することにより、見積もり業務の精度向上を図ることができます。

要件定義書の標準化

 A社では従来、要件定義書はプロジェクトマネージャがおのおの独自のフォーマットを用いて作成していました。しかし、社内勉強会を開催してさまざまなフォーマットを共有化することにより、要件定義書の標準版を作成することができました。

 以下は、標準化した要件定義書の目次の一例です。

  要件定義書
目的 モレの少ない要件定義、社員への周知の徹底、プロジェクトマネージャのための教育テキスト
外部への
開示
する
ページ数 40ページ程度
目次
イメージ

 (ア) 背景

 (イ) 現状分析
    1. 現状業務
    2. 現状の課題
    3. システム化の方針・目標
    4. システム構築後の業務フォロー

 (ウ) 機能要件
    1. システム概念図
    2. システム化対象業務一覧
       (1) 今回対象とする業務
       (2) 次フェイズで対象とする業務
    3. システムの機能一覧
       (1) システム画面一覧
       (2) システム出力帳票一覧
       (3) アクセス管理機能
       (4) システムメンテナンス機能
    4. システム運用ケース
       (1) A業務
          画面遷移図
          メニュー構成
          画面サンプル
       (2) B業務
       (3) C業務
    5. データベース構成
       (2) ER図
       (3) テーブル構成詳細

 (エ) 非機能要件
    1. 業務量の想定
       (1) ユーザー数
       (2) 稼働時間
    2. 性能要件
       (1) 応答
       (2) キャパシティ
    3. 可用性要件
       (1) 障害発生時対応
       (2) バックアップ/リストア
    4. 機密性要件
       (1) 想定されるリスク
       (2) セキュリティ対策
    5. ハードウェア構成
    6. ソフトウェア構成
    7. ネットワーク構成
          テスト
          システム評価


 (オ) プロジェクト体制
    1. プロジェクト体制図
    2. 責任と分担
    3. マスタ・スケジュール
       (1) 定例会議
       (2) 中間報告会
       (3) 議事録の作成
       (4) 課題管理と質問への回答
       (5) 変更管理
          変更管理手順
       (6) 構成管理
          構成管理DB
          登録手順
       (7) リリース管理
          テストリリース
          本リリース
       (8) 仕様の凍結
       (9) 完了報告会と検収
          テスト
          システム評価
          ユーザー評価
       (10) 納品物一覧
          文書管理手順
          文書体系
    4. 作業環境
       (1) 開発環境
       (2) 開発場所
       (3) データコンバート
    5. 導入教育
    6. その他付帯作業



















備考    

 A社では、このように要件定義書の標準化を全社レベルで行った結果、要件定義に起因するトラブルが半分程度にまで減少しました。

人材育成計画を作成

 一方のB社ではA社と異なり、ほぼすべての業務がすでに標準化されていました。B社の抱える問題はA社とは逆に、個人の知識・経験が不足しているところにありました。そこで、人材の育成計画を作成することにしました。

 B社では最初に、「自社のシステムエンジニアにどのような能力を身に付けてほしいか」を示すために、外部の専門家を招いて「人材能力モデル」(「スキルマップ」と呼ぶこともある)を作成しました。以下の図をご覧ください(図5)

ALT 図5 システムエンジニアの人材能力モデル(出所: トーマツ イノベーション)

 最も基礎的な力である「熱意」や「基本的な考え方」から、最上位の「プロジェクトマネジメント能力」までを体系的に挙げていますが、この中で精度を向上させるために最も効果的な教育は「業務知識」「業界知識」の習得です。これらの知識を身に付けることで、ヒアリング時の「ヌケ・モレ」を相当数減らすことができます。一般的に、経験を積むほど仕事の精度が高まるのは、この知識の習得によるものが大きいといえるでしょう。

 では、効果的に「業務知識」「業界知識」を習得するにはどうすればいいのでしょうか? 最も一般的なのは実務で経験を積むことですが、知識の偏りが発生するなど、効率の悪い側面もあります。

 知識は、「体系」を学んでから実務を行うことで、より効果的に吸収することができます。

 下の図をご覧ください(図6)。業務アプリケーションの要件定義を行う際に必須となる「伝票起票から決算書作成まで」の業務知識が1枚の図にまとめてあります。

ALT 図6 伝票起票から決算書作成までの業務フロー(出所: トーマツ イノベーション)クリック >> 拡大

 顧客の業務を把握するに当たり、個々の業務に対する理解を深めることはもちろん重要ですが、上のフロー図のように業務全体の流れを体系的につかんでおくこともとても大事です。問題領域の全体像を頭に入れておくだけで、現場でのヒアリングの精度は格段に上がります。

 このような知識の体系は、経験だけで得た断片的な知識だけではなかなか形成されません。会社として勉強会などを開催し、社員に対して体系的な学習の機会を提供することが重要です。

 さらに勉強会の効果を高めたい場合には、「ペーパーテスト」を行うことをお勧めします。「いまさらペーパーテスト?」と思われる方もいらっしゃるかと思いますが、勉強会の集中力アップと、習熟度の判定、競争意識の醸成には非常に効果的です。「今日はテストがあります」と勉強会が始まる前に一言いうだけで、学習効果は倍増します。

 ここで一例として、経理業務の基本知識に関するテスト事例を以下に示します。いずれも、業務アプリケーションの要件定義では必須の知識です。

[問題1]
 次の勘定科目と勘定科目の意味、決算書上の取り扱いとが一致する組み合わせを3つ選定して記号で回答してください。
  勘定科目 勘定科目の意味 決算書上の取り扱い
A 長期借入金 出資者が払い込んだ金額を処理する勘定科目 固定負債
B 通信費 郵送費、切手代、電話代など通信に関する費用 営業外費用
C 支払利息 銀行などからの借入金に対する利息を支払ったときに使われる勘定科目 営業外費用
D 受取手形 売掛金の回収時に、現金、小切手に換えて約束手形を受け取ったときに使用される勘定 固定資産
E 法定福利費 会社が負担すべき社会保険料、労働保険料 販売費および一般管理費
F 買掛金 商品や原材料の仕入れなど本来の営業取引に基づいて発生した債務 流動負債
G 接待交際費 得意先の接待、仕入れ先そのほかの事業に関係がある者に対する接待、供応、慰安、贈答。これらに類する行為によって支出した費用 特別損失


[問題2]
 次の勘定科目と勘定科目の意味、決算書上の取り扱いとが一致するように組み合わせてください。

 【勘定科目】
   1. 売上割引、2. 売上返品、3. 売上値引、4. 売上割戻

 【勘定科目の意味、決算書上の取り扱い】
  勘定科目の意味 決算書上の取り扱い
A 一定期間に多額または多量の取引をした得意先に対して、一定金額を戻す(ボリュームディスカウント)。 売上高のマイナス
B 商品の品質不良、破損などの理由で、販売先からの売上代金の減額要求に対応する。 売上高のマイナス
C 回収条件の変更による金利相当の費用支払い。例えば、支払期日より前に代金が支払われる場合や、手形で支払われるはずだった売掛金が現金で回収できる場合に代金を安くすること。 営業外費用に計上
D 販売した商品が戻ってくる。 売上高のマイナス


 いかがだったでしょうか? 一見こうした知識は、プロジェクトマネジメントとは関係がないようにも思えるかもしれません。しかし、要件定義やWBS・スケジュールの精度を向上させるためには、こうした地道な努力によって業務知識や業界知識を吸収していくことが非常に効果的なのです。

筆者プロフィール

安達 裕哉(あだち ゆうや)

トーマツ イノベーション株式会社 シニアマネージャ

筑波大学大学院環境科学研究科修了後、大手コンサルティング会社を経てトーマツ イノベーション株式会社に入社。現在、主としてIT業界を対象にプロジェクトマネジメント、人事・教育制度構築などのコンサルティングに従事する。そのほかにもCOBIT、ITサービスマネジメント、情報セキュリティにおいても専門領域を持ち、コンサルティングをはじめとして、企業内研修・セミナー活動を積極的に行う。


前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ