第166回:例会報告
例会部会 中前 正: 11月号
日頃、プロジェクトマネジメントに携わっておられる皆様、いかがお過ごしでしょうか。今回は、9月に開催された第166回例会についてレポートいたします。
【データ】
開催日時: |
2012年9月28日(金) 19:00~20:30 |
テーマ: |
「正しいITプロジェクトを創るための構想・企画とBA(ビジネスアナリシス)」 |
講師: |
株式会社アイ・ティ・イノベーション(取締役 兼 専務執行役員) 能登原伸二氏 |
今回は、株式会社ジャパンエナジー(現:JX日鉱日石エネルギー)で長年、情報システムの企画から運用まで幅広い業務に携わり、現在はITプロジェクトにおける管理支援コンサルティングを手掛けている能登原伸二様(以下、講師)をお招きし、BA(ビジネスアナリシス)の理論を活かしたITプロジェクトの構想と企画の方法についてお話しいただきました。
■ プロジェクト失敗の要因、IT構想・企画を取り巻く現状
冒頭で、ITプロジェクトで陥りやすい失敗と、その要因について説明されました。情報システム開発の難しさとして、
|
人手に依存
工業製品と比べて、人手で作る割合が高く、スキルや経験、モチベーションなどによって生産性が左右される |
|
要求機能が変動
成果物が「モノ」ではなく「機能」であるため、全体像が見えにくい。またビジネス環境の変化により、要求されている機能が開発途中で大きく変動する |
|
品質測定が困難
中間成果物が設計書やプログラムであるため、品質を把握することが難しく、開発の終盤になってようやくシステムの不良が発覚することがある |
という例をあげ、さらに、プロジェクト失敗の主たる要因について、「企画・要件定義に起因することが大きい」というアンケートデータが紹介されました。
次に、プロジェクトの超上流工程である「構想・企画」の場面において、その現状を分析しました。ビジネスを取り巻く環境の変化がめざましい昨今、それに現場が振り回されることが多くなっています。そんな状況下では、短期的で合理化指向による問題解決法よりも、ビジョンや戦略を明確にした、一貫性ある課題達成が重要であること、および、そこにはある程度、トップダウンによるアプローチが必要と、講師は説きます。
■ BABOKの概要
BABOKは、International Institute of Business(IIBA)に参加しているビジネスアナリストが、知恵を出し合って策定した知識体系であり、グローバルスタンダードの地位を確立しています。ビジネスアナリシスを行うために必要な6つの「知識エリア」と、「基礎コンピテンシ」で全体が構成されています。
|
知識エリア |
|
・ |
ビジネスアナリシスの計画とモニタリング |
|
・ |
引き出し |
|
・ |
要求のマネジメントとコミュニケーション |
|
・ |
エンタープライズアナリシス |
|
・ |
要求アナリシス |
|
・ |
ソリューションのアセスメントと妥当性検証 |
|
基礎コンピテンシ |
さらに、BABOKの重要概念として、以下の3点が挙げられました。
① |
Elicitation(引き出し)
ステークホルダーのニーズを明確にし、文書化すること。ただし、ニーズはステークホルダーが明言するとは限らない。真の“要求”を見つけ出すには、「聞く(ヒアリング)」姿勢よりも、「訊く(インタビュー)」姿勢が重要である |
② |
Requirement(要求)
BABOKで定義している“要求”とは、目標達成や問題解決のために必要な、能力(Capability)や条件(Condition)をさす。「ああしたい」「こうしたい」「これもしたい」といった要求(Demand)をそのまま聞くことではない |
③ |
Solution(ソリューション)
現在の姿(As Is)を分析し、あるべき姿(To Be)を実現するために必要な変革を考え、実施することがソリューションである。「ソフトウェア」「Webサービス」「運用教育」「アウトソーシング」などのコンポーネントに分類される |
■ IT構想・企画とは
ITプロジェクトにおける「構想・企画」の目的は、ビジネス戦略の達成に貢献する業務と、情報システムの姿を明確にし、実現シナリオを策定することにあります。手順としては、何のために(Why)、どのような業務・システムを(What)、どのように実現するか(How)、の3つの切り口で段階的に検討し、最終的に企画書としてまとめます。
「構想・企画」の場面でBABOKを適用することのメリットとしては、業務内容や改革規模によって変化する環境下において、「標準」が必要な事柄を抜け漏れることなくおさえるのに有効であること、また、関係者間でBABOKの知識を共有することで認識相違などの問題が解消され、共通の認識を持って協力し合いながら、真のメリットのある改革が実現できることを挙げられました。
後半は、上記3つの切り口について、詳しい説明がなされました。以下、ポイントを紹介します。
■ 要求のとりまとめ(Why)フェーズ
ボトムアップ、トップダウンの両面から、現状の姿を分析し、あるべき姿を明確にするフェーズです。以下のステップを踏みます。
1.1 |
ビジネスの方向性を理解する |
1.2 |
現行の業務・システムを把握する |
1.3 |
業務・システムの要求を概括する |
まずはSWOT分析、戦略マップ、CSF階層図などのツールを用いたり、上層部インタビューを行ったりして、組織上位の戦略やビジネスをとりまく環境を確認します。次に、現行業務プロセスの流れやシステムに関する課題を、既存資料やインタビューによって引き出し、問題点一覧としてまとめます。
さらに、こうして上がってきた要求を、体系化していきます。体系化は、以下の4つのステップで実行します。
Ⅰ. |
現在の状況や問題課題を、全社と関係部門ごとに記述する |
Ⅱ. |
どのような状況になればいいのか、望ましい状態をそれぞれ記述する |
Ⅲ. |
現状からあるべき姿に至るまでに必要となる能力や条件は何かを考え、要求を洗い出す |
Ⅳ. |
要求間のつながりを考察する |
■ 業務・システムの概要定義(What)フェーズ
今後の業務の概要、必要となる役割や組織、情報システムの構造、現状からの移行を検討し、その実現性や効果を確認します。以下のようなステップを踏みます。
2.1 |
ハイレベルな業務プロセスと概念データのモデルを作成する |
2.2 |
業務運用の体制を定義する |
2.3 |
技術的なアーキテクチャを定義する |
2.4 |
移行を検討する |
2.5 |
ソリューション効果を評価する |
アーキテクチャを検討する際は、選択案を複数作成し、各々の評価の上で選択する、また、個々の構成要素のバージョンアップのサイクルや保守性などを考慮することが重要とのことです。
■ 実現シナリオの策定(How)フェーズ
ゴールの実現に向けて検討すべきことを具体化して、プロジェクトの成功確率を高めます。ステップは以下の2つです。
3.1 |
実現のシナリオを策定する |
3.2 |
企画の承認を得る |
シナリオ策定の場面では、プロジェクト方針を決定し、スケジュールや体制案、リスク対応策などを作成すると同時に、投資対効果を確認することも重要な行程です。概算コストを算出し、効果を算出し、投資回収期間を試算します。
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
以上、早足ですが、構想・企画でのBABOK活用について、講義の概要を紹介してきました。最後に、講師が挙げた「常に思っていること」に、私も強く同感しましたのでこれらを紹介し、結びとします。
|
計画を作り、思いを語り、プロジェクトが成功するとメンバーに思わせる |
|
当たり前のことを当たり前に行う |
|
素直な心で物事を見て、役に立つと思ったことを積極的に取り入れる(あの手この手で対応する) |
|
与えられた役割を、機会だと思う |
|