Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ソフトウェアマネジメント改善 Office Project Server 2007 導入アプローチ

Hiroyuki TAKAHASHI
September 25, 2008
71

ソフトウェアマネジメント改善 Office Project Server 2007 導入アプローチ

Hiroyuki TAKAHASHI

September 25, 2008
Tweet

More Decks by Hiroyuki TAKAHASHI

Transcript

  1. ソフトウェアマネジメント改善
    Office Project Server 2007 導入アプローチ
    Sony Digital Network Applications, Inc.(SDNA)
    Technology Track
    Engineering Improvement Group
    Process Improvement Team
    SEPG/SQA/PMO Manager 高橋裕之
    *1: In the U.S., SEPG is a service mark of Carnegie Mellon University.
    SEPG は、カーネギーメロン大学のサービスマークです。
    *2: 本文中には ™ マークは明記しておりません。

    View full-size slide

  2. 会社概要
    •ソニーデジタルネットワークアプリケーションズ株式会社
    •Sony Digital Network Applications, Inc. (以降、「SDNA」 と略す)
    商号
    •2000年8月1日
    設立
    •東京都品川区東五反田2-21-28
    本社所在地
    •高松 和子
    代表者
    •ソフトウェア開発
    事業内容
    •450百万円
    資本金
    •ソニー株式会社 100%
    主要株主
    •285名 (2008年4月1日現在)
    社員数
    2
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  3. SDNAの特徴
    • ソフトウェア開発専門会社
    – 弊社が開発するソフトウエアは、
    PC系とCE系の二つに大別され
    ます。PC系では主にVAIOを対象
    に各種のソフトウエアを開発
    – 一方CE系では、ハンディカムやサ
    イバーショットなどのポータブル機
    器から半導体まで幅広い分野の
    ソフトウエア開発を行っています
    3
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  4. SDNAの特徴
    • マトリックス型組織
    – メンバーは専門分野別のチーム
    に所属しますが、業務はすべて
    プロジェクト制で運営し、新しい
    業務が発生するとそれぞれのチ
    ームから必要に応じてメンバーが
    集まり、新しいプロジェクトが形
    成されます
    – PMBOK®ガイドで解説されている
    「バランス・マトリクス型組織」に
    近い組織です
    4
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  5. SDNAの特徴
    • 技術領域
    – ソニーグループにおけるソフトウ
    エアのプロフェッショナル集団と
    して常に新しい技術に挑戦し、
    成果をソニーの製品づくりに活
    かすことを目標としています
    – そのためソフトウエアのコア技術
    について高レベルの知識を持つ
    チームが、日常のプロジェクトに
    対して積極的なサポートを行って
    います
    – また、ソフトウエア開発そのもの
    をより高品質に効率的に行うた
    めの専門機能についても、同様
    にチームを組織化しています
    5
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  6. SDNA の SEPG活動概略
    6
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  7. SEPGの発足:FY2004
    さまざまな現場…
    • SPI活動そのものの存在にすら気づいていない現場
    • 押し付けられたプロセスパッケージを咀嚼せずに使う現場
    • “用法・用量を間違えた”アジャイル!XP!な現場
    • CMMやISOなど、プロセスモデルへの丌信感に冒された現場
    • 専門職を無視した管理への過剰防御
    エンジニア志向のSEPG を発足
    • エンジニアの仕事を最大化することを目的とする
    • 組織プロセスのような一様なプロセス定義とは距離をとる
    • エンジニアの今の仕事を全ての始まりとする
    7
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  8. 品質向上を狙う、Multifunction SEPG
    • SEPG Architecture
    8
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  9. 品質向上を狙う、Multifunction SEPG
    SQA function
    • プロセスが遵守されているかを確認
    • プロジェクトの実績を観察
    • 第三者の立場。中立性を保つ。
    • 現場だけで解決しない問題は経営層
    にエスカレーション
    PMO function
    • プロセスとマネジメントが密接に結び
    ついた形で、PLをサポート・教育でき
    る体制を形成・維持
    • 「上司が部下をサポートする」ことの限
    界をカバーする
    • SDNAの仕事の進め方に沿った形で、
    計画確認プロセスを実行
    SEPG function
    • SPI 基盤の構築
    • メトリクスの集計サポートと情報開示
    • ソフトウェア開発/マネジメントプロセ
    スの形式化
    • ベストプラクティスの収集と形式化、
    展開
    9
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  10. PAG
    • SEPG Architecture
    10
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  11. PAG
    • PAG [Project Architecture Guideline]
    – 既存のプロセスモデルから派生させたものではなく、開発現場の要望を元に
    した、弊社独自のプロジェクト構築・運用・改善のガイドライン
    11
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  12. プロジェクトの誯題:3つのキーワード
    12
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  13. プロジェクトの誯題:3つのキーワード
    プロジェクト計画に本格的に取り組む前(FY06
    頃)は、スコープのあいまいさや、プロジェクトの
    丌確実性に対する取り組み丌足から数々の問
    題に直面するプロジェクトが後を絶たなかった
    当時の散在する誯題を大きくまとめると、つぎ
    の3つのキーワードが浮かんだ
    13
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  14. プロジェクトの誯題:3つのキーワード
    見切り発車
    ざっくり
    たられば
    14
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  15. プロジェクトの誯題:3つのキーワード
    見切り発車
    ざっくり
    たられば
    15
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  16. 見切り発車
    当時(FY06 頃)は、計画といえばパワーポイントなどで
    書いた資料を元に口頭にてプロジェクトの「概略」を説
    明すれば良い風潮があった
    • 「概略」では、プロジェクト・ステークホルダーに必要な情報は表しきれ
    ていない可能性が高い
    • そもそも、パワーポイントはプレゼンのツールであって、表現できる情
    報量に限界がある
    一方でプロジェクトの Go/No Go 判断を求められるマ
    ネジャーは、情報が尐ないので何を拠り所に判断すれば
    良いのか実際のところわからない・・・
    • 「今始めないと間に合わない!」というプレッシャーに押される形でプ
    ロジェクトが始まってしまっていた。これが「見切り発車」
    • ビジネス戦略上“見切り発車”せざる得ない事はあると思う
    • 問題は、いつまでも「無計画」状態でプロジェクトを進めることにある
    16
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  17. 見切り発車
    • 無計画で承認されたプロジェクトは、(失敗にならないにしろ)数々
    の問題に直面することが多かった
    – もっと正確に言えば「プロジェクトの成功」条件や「プロジェクトの終了」条件
    があいまいな為に、何をもって成功とするのか分からない状態でプロジェクト
    が終わっていたとも言える
    – こう言ったプロジェクトほど、「終わった」と思ったしばらく後に問題が発生した
    • なにもしなければ、失敗するのは当たり前
    • 成功確率をちょっとでも上げるには、プロジェクト計画が鍵となる
    プロジェクトの計画を立てないということは、
    失敗プロジェクトの計画を立てているに等しい
    17
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  18. プロジェクトの誯題:3つのキーワード
    見切り発車
    ざっくり
    たられば
    18
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  19. ざっくり
    • スケジュールはプロジェクト計画のほんの一部に過ぎないが、ソフト
    ウェア業界に於いては未だ「スケジュール=プロジェクト計画」と誤
    解しているエンジニアは多いのではないだろうか?
    – ガントチャートなどで書かれた“スケジュール表”のみを「プロジェクト計画」と呼
    んでしまうケース(もちろん、無いよりあったほうがマシだが・・・)
    • こういったスケジュールだけのプロジェクトほど、期間算出の拠り所
    である「工数」の見積もりに、根拠が見当たらないことが多い
    8月 9月 10月 11月 12月 1月 2月 3月
    SMILE システム
    実現性確認・ベンダ選定フェーズ
    8/8
    開始
    9/18
    終了
    要件開発フェーズ
    8/8
    開始
    9/30
    終了
    仕様定義(基本)フェーズ
    8/27
    開始
    9/30
    終了
    仕様定義(詳細)フェーズ
    10/1
    開始
    10/31
    終了
    仕様レビューフェーズ
    11/1
    開始
    11/30
    終了
    設計実装フェーズ
    10/15
    開始
    1/31
    終了
    結合テストフェーズ
    1/15
    開始
    2/15
    終了
    検収フェーズ
    2/16
    開始
    3/15
    終了
    パイロット導入フェーズ
    3/1
    開始
    3/31
    終了
    19
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  20. • 工数を「ざっくり」見積もっただけの状態でスケジュールを引いても、
    妥当性が見当たらない
    • 工数に根拠を持たないスケジュールは、進捗状況を判断する材料
    も持っていない
    – 「進捗会議」で報告にて「達成率は90%です」と言われても信憑性が薄い
    • しかし、プロジェクトの立ち位置を判断するための真のプロジェクト
    計画もないことから、プロジェクトリーダーからの報告を信じることし
    か出来なくなってしまう。それで良いのか?
    – 「気がつけばデスマーチプロジェクト」化の温床である
    よく見かける「マイルストーン・ゲート付きパーセントコンプリート法(MGP法)」
    ざっくり
    未着手
    0%
    作業着手
    25%
    ドラフト版完成
    50%
    レビュー実施
    75%
    完了
    100%
    90%できてますっ!
    これって、
    リーダーの
    主観じゃない?
    20
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  21. プロジェクトの誯題:3つのキーワード
    見切り発車
    ざっくり
    たられば
    21
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  22. たられば
    • プロジェクト計画を書いてみたものの、プロジェクトの成功に必要な
    「チェックポイント」が正しいタイミングで確認されていないために
    「計画と現実のズレ」と「そのスピード」を理解出来ぬまま手を拱いて
    しまい、気がつけばデスマーチプロジェクト化していることもあった。
    残作業
    開始日 期日
    現在
    おとぎ話
    現実
    22
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  23. たられば
    • こうなってしまう原因は色々あるが、一つは、計画そのものが十分
    にレビューされておらず、関係者からコミットされていない状態であ
    ることが挙げられる。
    • このような状態のプロジェクトは、すぐに進捗報告が機能しなくなる
    – 毎週開かれる“定例”はただの問題報告会となり、だれもプロジェクト計画に
    立ち返らないために、プロジェクトが項調か否か、判断がついていない状態
    に陥る。
    • どうしようも無い状況に陥ったとき、人は
    と、後悔することが多い。(これはリーダーに限らず、顧客も)
    • これは回避できないのだろうか?
    もしもあのとき~して「たら」
    もしもあのとき~してい「れば」
    23
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  24. 対策
    24
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  25. 対策
    • プロジェクトとは“冒険”とも言える
    • よって、プロジェクト計画とは“万全の策を練ったもの”と同じ
    • 我々SEPG/PMOは、現場のプロジェクトリーダーを中心に、サポート
    やコンサルタントによって次の対策を講じた
    『でも そもそも 冒険とは 達成を前提とし
    そのために 万全の策を練ったものをいうのであって―――
    その対策を 意識しないのは それはもう冒険ではなく 無謀というのですよ』
    ~惣領冬実「チェーザレ 5―破壊の創造者」から~
    刺客に襲われたにも関わらず、お忍びでピサの街に出たがるチェーザレにアンジェロが言った苦言
    25
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  26. 対策
    26
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  27. 対策
    27
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  28. 対策1)プロジェクト計画立案による、マネジメント力向上
    今まで計画を立案したことの無い人は、いきなり計画に
    着手できないかもしれない
    また、プロジェクト計画はプロジェクトの途中で変更・追
    加されてゆくものであるが、最初に書き出す機会を逸し
    てしまう様では、計画への取り組みそのもののチャンス
    を失い兼ねない
    そこで、プロジェクト計画書のテンプレートを用意した。し
    かし杓子定規なテンプレートを定義しても、現場で拒否
    感、やらされ感を招いては本末転倒である。プロジェクト
    マネジメントに本質的に必要であろう頄目に絞りこみ、
    プロジェクト計画書テンプレートを作成した
    28
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  29. 対策1)プロジェクト計画立案による、マネジメント力向上
    No 計画範囲 目的と内容
    1 スコープ 要求や成果物がProjectの中か外かを判断できるように、Projectが
    発足した背景や、大前提となる顧客から提示された納品物/マイル
    ストン、その他Projectに誯せられた条件や成立するために仮定され
    ている条件、Projectにどんな難しさがあるかを整理する
    2 ステークホルダー
    分析
    ヒアリングや承認の項番や時期を考えるために誮がどんな要求を出
    すか分析する
    3 プロセスの設計 Projectの進め方を明確にするために、どのような成果物を作りなが
    ら進めるか分析する
    4 成果物の一覧 過去のデータと、サイズにもとづいた見積りをするために作成する成
    果物の一覧を作成する
    5 見積り 人員の適切な確保と以後の進捗管理ためにProjectのボリュームを
    サイズに基づいて見積る
    6 フェーズ計画 どの時期に何を作るかがわかるようにProjectを時間と成果物で区
    分する
    7 誯題 誯題を正しく認識した上でProjectが進められるように、列挙しBGM
    のレビューが受けられるようにする。
    8 リスク 事前に問題に対処するため、上記を計画することで見えてきた丌確
    定要素を列挙し対策する
    29
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  30. 対策1)プロジェクト計画立案による、マネジメント力向上
    30
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  31. 対策1)プロジェクト計画立案による、マネジメント力向上
    31
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  32. 対策1)プロジェクト計画立案による、マネジメント力向上
    32
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  33. 対策
    33
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  34. 対策2)サイズ見積もりによる、見積もり精度向上
    要求書
    or
    要求仕様書
    工数見積もり
    コスト見積もり
    単価
    スケジュールへ
    経験?カン?なんとなく?
    「見積もり」とは、コスト算出は元よりプロジェ
    クトがスタートした後は進捗管理の源となる。
    •見積もりというと大抵「工数」になってしまうが、
    果たしてその工数の根拠として
    何を「元」にしているだろうか?
    34
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  35. 対策2)サイズ見積もりによる、見積もり精度向上
    35
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  36. 対策2)サイズ見積もりによる、見積もり精度向上
    要求書
    or
    要求仕様書
    工数見積もり
    コスト見積もり
    単価
    スケジュールへ
    経験?カン?なんとなく?
    36
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  37. 対策2)サイズ見積もりによる、見積もり精度向上
    要求書
    or
    要求仕様書
    サイズ見積もり
    工数見積もり
    コスト見積もり
    過去データ

    成果物情報
    生産性
    単価
    スケジュールへ
    成果物毎に予想されるサイズ(量)を見積もる
    クラス設計 → クラスはxx個
    ソースコード → xx行
    予想したサイズと生産性実績から、必要な工数を算出する
    要求仕様書の作成工数 =
    (仕様xx個)×(仕様を1つ定義するのに必要な時間)
    37
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  38. 対策2)サイズ見積もりによる、見積もり精度向上
    38
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  39. 対策2)サイズ見積もりによる、見積もり精度向上
    39
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  40. 対策
    40
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  41. 対策3)PJ計画レビューによる無計画プロジェクトの抑止
    • 上記のリスクは、弊社においても大いにあり得る
    • また、プロジェクトリーダー自身が計画やスケジュールを「書いた」と
    いう意識でいるのなら、魂が込もっていない可能性が高い
    – 「計画を書いた」・・・やらされ感、形骸化、杓子定規
    – 「計画を立てた」・・・策を練る、能動的、冷静、プロフェッショナル
    ソフトウェアプロジェクトに対する最も深刻なリスクのいくつかは、次のように計
    画に直接関連している
    計画を作成しない
    作成した計画に従わない
    プロジェクトの状況に変化があったにかかわらず、計画を見直さない
    (Steve McConnell , 1998)
    41
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  42. 対策3)PJ計画レビューによる無計画プロジェクトの抑止
    • 立案されたプロジェクト計画には、客観的レビューが重要である。
    42
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  43. 対策3)PJ計画レビューによる無計画プロジェクトの抑止
    何を重点的に計画されるべきかはプロジェクトの特徴、プロジェクトリーダー
    のスキルを基準に判断する必要があるが、段階ごとのチェックポイントを設け、
    正しいタイミング/正しい基準でレビューを実施。いくつものチェックポイントを
    確認することで、計画そのものの妥当性を高めることに繋がってゆく
    「プロジェクトのスコープ認識は正しいか?」
    「初期見積もりがサイズに基づいて行われているか?」
    「顧客との要求仕様合意が行われているか?」
    「フェーズ毎のレビュー計画は適切か?」
    「要求、仕様のベースライン状況は?」
    43
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  44. 対策3)PJ計画レビューによる無計画プロジェクトの抑止
    上の図は、代表的なプロジェクト・
    ライフサイクルを表している
    ( Iterative process )
    •それぞれのフェーズでは、開発プロセスと
    共にプロジェクトマネジメント・プロセスも反
    復されていると考えることができる
    よってフェーズの切れ目では、以下
    の追跡を行うことがとても重要
    •予定と実績の把握
    •遅れが発生した場合の原因分析
    •次フェーズ以降の計画を補正する
    •顧客へ再見積もりを提案するか判断する
    44
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  45. 対策3)PJ計画レビューによる無計画プロジェクトの抑止
    • サイズ見積もりの予定と実績把握
    ☑サイズが想定よりも大きく変わっていないか?
    45
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  46. 対策3)PJ計画レビューによる無計画プロジェクトの抑止
    • 工数見積もりの予定と実績把握
    ☑工数バッファを想定外に消化していないか?
    46
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  47. 対策3)PJ計画レビューによる無計画プロジェクトの抑止
    この様な分析や対応策定は
    基本的にプロジェクトリーダー
    自身が実行している。
    慣れないうちはPMOがサポー
    トしていたが、次第に自分自
    身で実施できるようになって
    行った。
    47
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  48. ここまでのまとめ
    48
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  49. ここまでのまとめ
    49
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  50. ここまでのまとめ
    • 組織として、立案された計画
    を基にプロジェクトの実現度、
    リスクを判断する風土を作るこ
    とができ、さらにプロジェクト計
    画書を有効活用する「習慣」を
    作れたことが最大の効果であ

    • 一方、いくつか新たな誯題も
    発生した
    – 実績工数や実績サイズなどの、
    実績データの収集が手作業であ
    ったためプロジェクトリーダーの負
    荷を上げてしまった
    – サイズ見積もりからスケジュール
    へ落し込む作業が省かれぎみと
    なり、スケジュールの可視化が疎
    かになった
    • これらの誯題については、高
    度なIT化によりプロジェクトリー
    ダーの負荷低減・Excel からの
    脱却を目指しEPMシステムを
    構築。運用を開始した
    PMOが事前にアド
    バイスすることで、
    ぐんとそのプロ
    ジェクトの成功率
    向上に貢献できて
    いる
    「計画ってどう
    立てればいい
    の?」
    「なぜ、このプ
    ロジェクトはこ
    んなに難しい
    の?」
    「どのような計
    画で望めば、
    問題を回避で
    きるの?」
    50
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  51. EPMシステムの構築導入

    View full-size slide

  52. プロジェクトリーダーの意識調査(FY2007)
    • 2007年7月にプロジェクトリーダーにアンケートを実施した。
    – 有効回答者数 40名
    2% 2%
    23%
    30%
    43%
    現在参加しているプロジェクト規模は次のどれですか?
    中規模オフショア(6名~20名) 小規模オフショア(1名~5名) 大規模(21名から50名。サブプロジェクト内包)
    中規模(6名~20名) 小規模(1名~5名)
    52
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  53. プロジェクトリーダーの意識調査(FY2007)
    • 「プロジェクトがうまくいく」最大の要因があったら教えてください
    PMBOK 知識エリア・プロセス 個数
    PJコミュニケーションマネジメント 13
    PJ人的資源マネジメント 10
    PJ統合マネジメント 4
    PJスコープマネジメント 4
    PJリスクマネジメント 3
    PJコストマネジメント 2
    PJタイムマネジメント 2
    PJ品質マネジメント
    PJ調達マネジメント
    総計 38
    次ページに詳細
    53
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  54. プロジェクトリーダーの意識調査(FY2007)
    • 「プロジェクトがうまくいく」最大の要因があったら教えてください
    PMBOK 知識エリア・プロセス 個数
    PJコミュニケーションマネジメント 13
    PLがプロジェクトの状態を適切な粒度で把握していること 1
    PLのコミュニケーション能力 1
    コミュニケーション 1
    プロジェクトに関する情報や狙いがメンバー全員で共有されていること。 1
    プロジェクトメンバーおよびクライアントとゴールのイメージを納得して共有できる 1
    プロジェクトメンバーどうしのコミュニケーションが良好であること 1
    プロジェクト内のコミュニケーション 1
    メンバーの意思導通 1
    メンバーの共通目的意識 1
    メンバー間で目標が共有され、各人がそれに向かって何をすれば良いか理解し実践すること。 1
    モチベーション 1
    志を関係者と共有する 1
    明確な方向性提示 1
    総計 13
    54
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  55. プロジェクトリーダーの意識調査(FY2007)
    • 「プロジェクトがうまくいく」最大の要因があったら教えてください
    PMBOK 知識エリア・プロセス 個数
    PJ人的資源マネジメント 10
    メンバーの知識&経験&調査能力の総量 1
    メンバー構成のバランスが取れている。 1
    見積もりに基づきアサインされていること。 1
    自律的に動ける優秀なメンバーであること 1
    人 1
    適時かつ適材適所であること。 1
    役割分担 1
    優秀なエンジニアをたくさん集めること 1
    優秀なメンバーを集める 1
    要求解、分析、提案、見積もり、進捗管理ができる人たち。 1
    PJ統合マネジメント 4
    BGMとTLと顧客(=ステークホルダー)がスマートであること。 1
    顧客のゴールが明確なこと。 1
    段取り8分。PJ開始当初の成果がPJ全体の成果を決定付けるような気がします 1
    要件管理 1
    総計 14
    55
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  56. プロジェクトリーダーの意識調査(FY2007)
    人事評価が丌適切でモチベーションが低い
    分散開発(委託やオフショア)
    PLの体力や精神力が丌十分
    プロジェクトのオーナー(経営者、BGMなど)のバックアップが丌十分
    進捗が遅れた時の対処が丌十分
    PLのコミュニケーション丌足
    メンバー相互のコミュニケーション丌足
    プロジェクトチームの人選や編成が丌適切
    目標や成功基準が丌透明
    リスク要因の検討が丌十分
    6
    10
    10
    12
    20
    20
    20
    23
    25
    26
    プロジェクトの成功の阻害要因として
    直面したことのある誯題は以下のどれですか
    56
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  57. プロジェクトリーダーの意識調査(FY2007)
    参加メンバーに対する人事評価体系の見直し
    PLの人選方法を見直す
    プロジェクトのオーナー(経営者、BGMなど)がどう支援すべきかを明確にする
    リスク管理などに関する支援組織をつくる
    プロジェクト発足初期に(経営者、BGMなどが)調査検討をもっと慎重に行う
    参加メンバーの人選・編成方法を見直す
    目標と成功基準の明確化を丹念に行う
    5
    10
    11
    16
    18
    19
    24
    指摘された誯題を解決するうえで必要な対策は?
    57
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  58. プロジェクトリーダーの意識調査(FY2007)
    特になし
    デバッグ
    プロセスフローダイアグラム(PFD)
    外注管理
    要件開発
    WBS
    構成管理
    リスクマネジメント
    スケジュール作成
    プロジェクト計画
    テスト
    進捗管理
    データの計測と分析
    要件管理
    3
    3
    6
    6
    6
    7
    9
    11
    12
    13
    16
    18
    19
    20
    「ツール」や「システム化」でもっと効率が上がるのでは?と思っている
    マネジメント・アクティビティ
    58
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  59. プロジェクトリーダーの意識調査(FY2007)
    • このアンケート結果をもとにディスカッションを実施
    – 各ビジネスマネジャー推薦のエース級 PL6名と PMO によるディスカッション
    – アンケート結果の分析
    • 結論『進捗が遅れたときの対処に問題がある』
    – 問題の早期発見、増員の説得データ、リスクが読み切れていない、など
    •そこにはスケジュールの作成も含まれる
    •スケジュールを作るには、WBSが明確でなければならない
    •WBSを明確にするには、プロセスの明確化、成果物の明確化が前提
    進捗管理をうまく行いたい
    •見積もりにはPJ計画が必要
    •見積もりの精度をあげないと「人が欲しい」が説明できない
    見積もりをしっかりやりたい
    •プロジェクト活動すべての源泉
    プロジェクト計画を立てやすくしたい
    59
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  60. EPMシステム
    • プロジェクトのステータスがリアルタイムに見え
    ないのは、経営のリスク
    このように現場プロ
    ジェクトリーダーからの
    誯題が挙がる一方、
    経営層からも組織全
    体のPMポートフォリオ
    を鳥瞰できる仕組み切
    望されていた
    • EPMシステムを1から作るにしろ、パッケージを
    利用するにしろ、自分たちの“理想”や“確信”を
    持っていないと良いシステムは作れない
    • まずは、PMプロセスの概略アーキテクチャをデ
    ザインし、そこから要求、要求仕様を開発する
    アプローチを実施
    そこで我々PMOは、ま
    ず誯題解決の為にど
    のようなPMプロセスを
    実行すべきか?の検
    討から着手
    60
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  61. 改善
    • SEPG Architecture
    61
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  62. • SEPG Architecture 2.0
    改善
    62
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  63. EPMシステム要求仕様書
    63
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  64. • プロジェクトマネジメントツールの独自調査
    – ベンダー製品の徹底比較
    市販製品の調査
    64
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  65. 何をチェックしていたか
    自分たちの
    プロセスが実
    施できるか?
    EPMの導入が早められる
    のであれば、ツールに合わ
    せてプロセスを変えざる得
    ないリスクは覚悟してい
    た。
    意外と多い“PMBOK準拠”
    というナゾのセールストー

    •PMBOKを理解している方は想像
    つくと思いますが、何をもって“準
    拠”と言えるのか曖昧です
    価格は?
    安いに越した事はなし。も
    ちろん、カスタマイズ費用
    も考慮
    •シェアが低いツールほど、情報が
    尐なく専門エンジニアも丌足=カ
    スタマイズ費用高
    ROI が説明出来ないと、
    何も始められない
    品質は?
    既存のレガシーシステム
    や、将来の新システムとの
    連携は必順
    •即ち、移植性は大事
    •使用性は大事だが、新しいテクノ
    ロジー(機能性)も大事
    ちょっとでもカスタマイズす
    ると「サポート対象外」とい
    う製品もありました。
    (信じられません)
    65
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  66. 買うも作るも、品質が大事
    • ISO/IEC9126(JIS X 0129-1)ソフトウェア品質特性
    EPMパッケージ
    66
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  67. 買うも作るも、品質が大事
    • 製品価値を明確にした上で要求や品質に優先項位をつけ、
    トレードオフし得る、製品価値を明確にすることが必要
    0
    1
    2
    3
    4
    5
    6
    7
    8
    9
    合目的性
    正確性
    機能性標準適合性
    相互運用性
    セキュリティ
    成熟性
    障害許容性
    回復性
    理解性
    習得性
    運用性
    時間効率性
    資源効率性
    解析性
    変更性
    安定性
    試験性
    環境適応性
    設置性
    置換性
    移植性標準適合性
    社会インフラ 一般的な組み込み機器 処理効率優先型機器(ゲームなど)
    67
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  68. EPMシステム
    最終選定
    決め手
    • マイクロソフト 殿は、我々が実現したいこと(要求仕様)の Feasibility Study に協力して頂
    き、かつ的確に納得する回答を用意してくれたから
    • プロジェクトマネジメントに関する“言葉”が通じる安心感
    • Fit Gap の回答も明確で、要件毎に複数の選択肢を提案して頂けた
    • Microsoft Office Project がもつ、歴史的優位性
    • 弊社の社員はほとんどがソフトウェアエンジニアなので、Microsoft Office Project は昔から
    慣れ親しんでいる(使いこなせているかどうかは別として・・・)
    • 全社的に Windows Server や SharePoint Server が導入済みであったためインフラ面での
    親和性が高い
    68
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  69. EPMシステムで解決したい重点誯題
    • 解決したい重点誯題
    • 見積もりから「スケジュール立案」がうまく出来ていなかった部
    分を、Systemで簡単に
    • メンバーからの進捗報告も、Systemにより一元化
    進捗管理の改善
    • 見積もりとスケジュールが密接となることで、より根拠ある見積
    もりへ
    見積もりの改善
    • プロジェクト計画データ(情報)の可視化が向上
    • 見積もり、進捗共に予測・実績データの管理が簡単に
    プロジェクト計画立案の改善
    69
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  70. PJ計画と進捗管理の誯題
    立ち上げ
    プロセス群
    終結
    プロセス群
    計画プロセス群
    実行プロセス群
    監視コントロール・
    プロセス群
    (Plan)
    (Do)
    (Check, Act)
    70
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  71. PJ計画と進捗管理:現在
    メンバーからの日報と
    工数の関係が
    よくわからない
    週単位で
    とりまとめ
    今日やったことは報告したけど、
    PJ全体の進捗がよくわからない。
    このままでいいの?
    プロジェクト
    作業日報 BGM
    A さん
    PL
    プロジェクト
    計画書
    最初のころ計画は
    立てたけど、更新は
    していない。
    既存の工数
    管理システム
    クリティカルな問題
    は報告されていない
    けど・・・本当に項調
    なのだろうか?
    71
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  72. PJ計画と進捗管理:これから
    進捗を入力
    Project
    データベース
    入力フォーム
    工数と実績
    管理
    エクスポート
    進捗の入力作業が
    容易になった
    メンバーの実績が
    データベースに累積
    する
    BGM
    A さん
    PL
    既存の工数
    管理システム
    EVM分析ビュー
    72
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  73. EPMシステム:グランドデザイン
    73
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  74. • Software Management Improvement for LEAP
    (飛躍のためのソフトウェアマネジメント改善)
    EPMシステム:SMILE
    74
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  75. EPMシステム:SMILE
    • サイズ見積もりの実現(アドイン)
    タスク名 _総計 _予定成果物数
    成果物 400 400
    タスク1 0 200
    Aさん 0 200
    タスク2 0 200
    Bさん 0 100
    Cさん 0 100




    手動で入力
    手入力で設定
    自動的に積上げ

    計算

    75
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  76. EPMシステム:SMILE
    • スコープ記述(プロジェクト ワークスペース)
    76
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide

  77. 参考文献
    i. The Art Of Project Management, Theory in Practice (O'Reilly)
    『アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法』(Scott
    Berkun(著)、村上 雅章(翻訳)、オライリー・ジャパン、2006/9/7)
    ii. Steve McConnell, Software Project Survival Guide, Microsoft Corporation.
    スティーブ・マコネル『ソフトウェアプロジェクトサバイバルガイド』(新訳、(株)アルテア・ジ
    ャパン 訳、久手堅 憲之 監修、日経BP ソフトプレス、2005/8/1)
    iii. Project Management Institute, A Guide To The Project Management Body Of Knowledge
    (PMBOK® Guides), 3rd, 2004/11
    PMI東京『プロジェクトマネジメント知識体系ガイド(PMBOK® ガイド第3版)』(PMI東京支
    部翻訳、2004)
    iv. 『Software People - ソフトウェア開発を成功に導くための情報誌 (Vol.5)』(技術評論社、
    2004/10)から、『 【特集1】コンサルタントが教える究極の仕事術 見積もりと進捗管理
    入門(システムクリエイツ 清水吉男(著))』
    v. コミック「チェーザレ 5―破壊の創造者」(惣領 冬実 (著)、講談社 2008/7/23)
    vi. SEC BOOKS 組込みソフトウェア開発における品質向上の勧め[設計モデリング編]、(独
    立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター編、
    2006/6/20)
    78
    © 2008 Sony Digital Network Applications, Inc.

    View full-size slide