イベントレポート2014.11.29
中央省庁CIO補佐官に学ぶプロジェクト・マネジメント
11/19(水)に「中央省庁CIO補佐官に学ぶプロジェクト・マネジメント」をテーマにしたBOHRミーティングを開催しました。
本セミナーでは、数々の国家プロジェクトにおいてITシステム開発を支援してきた座間敏如様をお招きし、プロジェクト・マネジメントの知識や手法についてお話しいただきました。
プロジェクト・マネジメント概論
システム開発手法の変遷
プロジェクトを円滑に進めるための手法であるプロジェクト･マネジメントが、近年改めて注目されています。まずはプロジェクト･マネジメントがなぜ現在再び求められているのかについて、システム開発手法の変遷の観点からお話しいただきました。
「従来のシステム開発は大規模なシステムを一つのベンダー(※1)が開発するものが多くありました。しかし、システムの互換性や、保守管理ができるのはシステムを開発したベンダーしかないといった問題が生じていました。
その後、大規模システムを特定ベンダーに依存して長く使うのではなく、短期間で複数のプログラムやサブシステムを開発し、それらを組み合わせてひとつのシステムを作り上げることが、一般的になりました。
ビジネスニーズの変化に応じ、システム開発手法の主流も変遷を遂げています。代表的な開発手法として、ウォーターフォール型とアジャイル型があります。
ウォーターフォール型は主に大規模システムの開発に用いられるものです。システムで何をしたいのかという要件定義から始まり、設計、開発、試験、導入という一方向に流れるプロセスにより開発を行います。
一方、アジャイル型というのは主に中小規模システム開発で用いられている手法です。ユーザーに要件を確認しながら、設計と開発を繰り返す反復型プロセスを指します。システム開発を行う際はそれぞれのメリットデメリットを理解した上で、各手法を使い分けることが大切です」
※1 ベンダー...製品の開発事業者、または販売事業者のこと
アジャイル型が開発の主流に
「ウォーターフォール型は要件定義が不十分だった場合、出戻りが発生し、その影響が非常に大きくなってしまったり、ビジネス環境の変化に適応できないといった問題が生じます。また、ユーザーにとっては使ってみないと仕様の妥当性の判断ができないといったことも大きな問題ですね。
この点、アジャイル型は発注者と受注者でやりとりしながら開発を行うので、即座に修正を行うことができます。ただし、最初に全体の設計を固めない手法であるが故に、プロジェクト管理がしにくいという難点があります。もしプロジェクト管理を誤ると、コストの超過、期間の遅延、仕様の縮小の可能性が生じてしまったり、いわゆるエンジニアがオレ流で開発する非標準化状態が生まれてしまう危険性が出てきてしまいます。
アジャイル型の開発手法が主流になるとともに、先ほど述べたような問題点が露呈してきた経緯があり、プロジェクト･マネジメントのスキルのニーズが高まってきました」
プロジェクト・マネジメントの難しさ
開発プロジェクトを牽引する立場になったとき、プロジェクトのリーダーはどういったことに気をつければよいのでしょうか。
「スケジュールを守ろうとすると、品質を下げるか、コストを上げるかということになります。コストを下げるためには、品質を下げなければなりません。スケジュールが長くなればコストがかさみます。プロジェクト・マネジメントの仕事はQuality(品質)、Delivery(期間)、Cost(費用)のバランスをとることです。
昔、プロジェクト管理は「勘」と「経験」と「度胸」だと言われたことがあります。しかし、一人の人間が把握できる情報には限界があり、業務がグローバル化、長期化、複雑化している状況では、これまでのプロジェクト管理の手法は通用しなくなりました。また、現代ではプロジェクトの可視化が求められるようになったため、スケジュール、コスト、品質の要求が厳しくなりました」
プロジェクトの定義
そもそもプロジェクトとはいったい何を指しているのでしょうか。
「社内で行う日常業務はプロジェクトではありません。プロジェクトとは明確な目標を達成するために実施される期限のある業務を指します。例えば、特定の期限までに特定の建築を行う、製品を開発する、システムを構築するなどがプロジェクトですね。
プロジェクト管理は難しいように感じられますが、皆さんは日々無意識に実践しています。例えば料理です。料理をする際は、様々なタスク(作業)がありますよね。料理はタスクの積み重ねでできますが、そこには様々な準備が必要であり、手順や作業内容が正しくなければ問題が生じます。料理にかかる時間や料理に必要な手法は何か、細かなタスクに分割して全体を考えなければなりません。まさにこれはプロジェクト・マネジメントの一例です」
代表的なプロジェクト・マネジメントの管理手法
「代表的なプロジェクト・マネジメントの手法として、アメリカで主流のPMBOK(Project Management Body of Knowledge)があります。他にはイギリスで使われているPRINCE2というのもあります。日本だとP2Mというのがありますが、これはPMBOKとほぼ同じです。そこで、本日はPMBOKに基づくプロジェクト・マネジメントの手法についてお話しします」
プロジェクト・マネジメント実践
PMBOKに基づくプロジェクト・マネジメント
「PMBOKとは、プロジェクトマネジメントに関する手法や知識を体系立ててまとめたものです。1987年にアメリカの非営利団体PMI(Project Management Institute)が制定し、現在は国際標準として普及しています。
PMBOKは9つの知識エリアで構成されていますが、本日はその中から、スコープ管理、スケジュール管理、コスト管理、リスク管理について、お話したいと思います(※2)」
※2 他には、統合管理、品質管理、人的資源管理、コミュニケーション管理、調達管理がある
スコープ管理
「スコープ(※3)管理とは、成果物として何を作るのかということと、成果物を作るために何の作業が必要なのかを管理することです。例えば、家を建てるとき、最初に発注者と受注者で話し合いますが、どんな作業をしてどういう家を建てるかというスコープの決定を誤ると、できあがった家が発注者が求めているものと異なる場合があります。
※3 スコープ...そのプロジェクトが提供する成果物や、それを創出するために必要な作業
Quality,Delivery,Costに加えて、発注者の満足度や期待値を考慮しなければいけません。スコープの決定に関しては、現実の組織では改革派対対抗勢力、思いつき対現実主義と分裂することがありますが、常に実現可能性を念頭においてスコープを話し合うことが重要です」
スケジュール管理
「スケジュールを作る際は、WBS(Work Breakdown Structure)を作成し、工数を見積もってからガントチャート(※4)を作成します。WBSとはプロジェクトを、タスク(作業)レベルに分解した構成図です。ツリー構造で記載されることが一般的です。タスクを漏らさず書き出すことが重要です。
※4 ガントチャート...縦軸に作業内容、横軸に日付を並べ、各作業の開始・終了日などをまとめて横型の棒グラフで表したスケジュール表
タスクを作った後に、ネットワークダイアグラム(※5)を作成し、全体の流れと所要時間を把握することも有効です。相関関係のあるものに日付を書くことにより、最終的な段階の日付がわかります。
※5 ネットワークダイアグラム...プロジェクトのタスクの依存関係を図で表したもの
ガントチャートを作成する際は、まずはタスクを全部書き出しましょう。きれいに書く必要はありません。前後関係や重複も気にしないでください。こうすることにより、「想定外の事態」の発生を防ぎ、作業内容をメンバー全員に共有することができます。
次に大まかな作業グループで集約します。こうすることにより、全体の作業と個別の作業の関係性を理解することができます。ポストイットにタスクを書き出し、円で囲んでグループ分けするやり方もよくやります。定常的、異質なタスクは何かを把握することも大切です。その後、タスクにIDを付与します。ポイントはカテゴリー番号と個別番号を組み合わせることです。こうすると、タスク管理っぽくなります(笑)。
次に工数を見積もります。まずは各タスクの作業量を洗い出しましょう。このときに、付加的な作業(環境作成や報告書策など)も含めてください。そして、工数を時間数に(日数等)に置き換えます。そして、タスク相互の関係を整理します。各工程の前後関係や依存関係を洗い出すことも重要です。何が並行にできるタスクなのかをここで確認します。
その後、カレンダーに反映し、これまでのタスク・工数を、純粋に落とし込みます。このときに前後・依存関係を意識してください。全体スケジュールはカテゴリーレベルで大まかに作成し、カテゴリー内のスケジュールは個別タスクで積み上げていきましょう。そしてガントチャート化し、全体像を確認します。前後・依存関係のあるタスク間の関係を調整します。
最後にタスクを調整します。前後・依存関係のあるタスク間の矛盾だったり、特定の日に負荷が過度に集中していたりすると調整します。大切なことは正しく実態を反映したスケジュールを作成することです。最初から納期ありきで作成するのではなく、最終調整までは必要な工数・期間を記載することがポイントです。
その他の注意点としては、タスクの担当者や工数(コスト)を明確にすること、経営層やユーザーに理解できるWBSにすることなどが挙げられます。また、一度決まったスケジュールを勝手に(頻繁に)変えてはいけません。必ず影響分析等を行い、ステークホルダーに周知の上で実施してください」
コスト管理
次にコスト管理についてお話し頂きました。
「プロジェクトは基本的にコスト超過に陥りやすいです。また、プロジェクトの進行に問題が発生すると、回復するのはほぼ不可能です。スケジュールや品質を回復するためにはリソース(人や金)を投入しなければいけません。また、コスト超過が見えていても、中断することは難しいこともよくあります。最近だと、コスト管理の問題に対策するために、EVM(EARNED VALUE MANAGEMNT)なども活用する動きがありますが、政府ではインセンティブの問題があるため、十分に活用できているとはいえません」
リスク管理
最後に、リスク管理についてお話し頂き、本セミナーを締めくくりました。
「リスク管理では、リスクを特定してコントロールすることが重要です。日本の情報システム開発のリスクとしては次のことが考えられます。例えば、ユーザー要件による過剰な作り込みが多い、要件変更が多い、ベンダーの提案力不足などです。これらはコストの高騰や運用の困難を招きます。
IT業界の抱えるリスクとしては、人月主義や小規模な研究投資、高い人件費などが挙げられます。海外では売上や利益の3分の1を研究投資している企業も多いです。また、海外ではイノベーションを重視しているにも関わらず、日本は人月主義(制作や開発における工数や仕事量を「人数×月(時間)」で表すこと)でとにかく人を導入できるビジネスに傾注しています。日本は品質基準が高く俗人的ですが、海外ではグローバルへの展開を前提とした戦略をとっています。グローバル化によって、日本のベンダーが抱えるリスクが顕在化してきました。
最後にリスク管理の留意点についてお話しします。まずは、リスクの明確化を恐れないでください。日本ではリスクについて発言すると、後ろ向きだと言って批判されることがありますが、リスクは悪ではありません。いかにコントロールし、極小化する事が重要です。リスク管理を行う際はリスクの大きさ(影響度)を検討し、外的リスク、内的リスクに分類し、リスクに対応できるかどうかも分類しましょう。また、押さえていただきたいことは、チャレンジしなくても常にリスクは存在します。すべてのリスクを避けることは不可能だということを前提に、リスク管理を行いましょう」
座間 敏如 様
内閣官房 政府CIO補佐官（総括）、財務省 情報化統括責任者（CIO）補佐官、預金保険機構 CIO補佐役、総務省 行政管理局技術顧問、東京大学公共政策大学院 公共政策 実務家教員、株式会社 社会情報システム研究所 代表取締役
経歴
1970年愛知県生まれ。名古屋市立大学経済学部卒。1993年日本電信電話株式会社（NTT）入社。情報システム本部、マルチメディア推進本部、NTTコミュニケーションズ（株）を経て2002年退職。KPMGコンサルティング㈱（現PWC）、ガートナージャパン（株）を経て、2011年より(株) 社会情報システム研究所代表取締役
2003年に財務省CIO補佐官、2006年に内閣官房IT担当室電子政府推進管理（GPMO）補佐官、総務省行政管理局技術顧問に就任
2011年より東京大学公共政策大学院実務家教員を務める。2012年に内閣官房に設置された政府CIOの補佐官を拝命
ご自身のキャリアプランを相談したい方へ無料体験レッスン開催中
インターネット・アカデミーでは、毎日無料体験レッスンを開催しています。授業の体験をしていただくのはもちろん、お一人おひとりにニーズにぴったりのコースや学び方を選ぶお手伝いをします。ぜひお気軽にお越しください。