ＷＢＳはプロジェクト計画のポイント（その２）

日経ＳＹＳＴＥＭＳ（発行：日経ＢＰ社）１月号の特集１「ＷＢＳの作り方」は、
たいへん参考になる記事でした。

以前、本ブログ内の「ＷＢＳはプロジェクト計画のポイント」という記事において、
私が考える　ＷＢＳ（Work Breakdown Structure）の重要性　と　作成時のポイント　を紹介しました。

日経ＳＹＳＴＥＭＳ（発行：日経ＢＰ社）１月号（以下、同誌）の特集１「ＷＢＳの作り方」（以下、同記事）
において、それにプラスされる、また深堀されるような、たいへん有用な考え方が多数紹介されていました。
以下、参考になった考え方を整理しつつ、私の考え方を補足説明しておこうと思います。


１．プロジェクト進捗段階における段階的なＷＰの詳細化
同誌の本記事において、
「例えば、提案時、プロジェクト開始時、工程開始時といったタイミングでＷＢＳをチェックし、だんだんと詳細化している」
ことの重要性が記載されています。

私もその考え方に賛成です。

私は、システム提案依頼書の発行時に添付するＷＢＳ　また　プロジェクト開始時のマスタースケジュールのベースとなるＷＢＳ　において、
各工程のＷＢＳ（詳細計画）は各工程の責任者が作成することを明確化するために、
その詳細計画作成をＷＰ（Works Package：作業の最小単位）の一つとして定義し記載するようにしています。


２．成果物とプロセスに着目
同誌の本記事において、「成果物とプロセスに着目する」こと、
そして「プロセスと成果物をマッピングする」ことの重要性が紹介されています。

私もその考え方に賛成なのですが、
上記１．に関連し、少し注意して記事を解釈することが必要だと思います。

例えば「操作マニュアルの作成」などのドキュメント類の作成について考えてみます。

私は前記の　システム提案依頼書の発行時に添付するＷＢＳ　また　プロジェクト開始時のＷＢＳにおいては、
各種ドキュメントが網羅すべき内容は記載しますが、その内容ごと（目次レベルごと）にＷＰは分割しません。
このＷＰの分割と役割分担は、その工程における責任者が、自身の責任において、ＷＢＳ詳細化（詳細計画作成）時に実施するようにしています。　


３．役割分担が明確化されるまで分割
同誌の本記事において、「役割分担が明確になるまで細かくする」ことの重要性が紹介されています。
特に、例えば、担当欄がユーザ企業と構築ベンダーというケースにおいて、
「担当の欄には「△」をつけず、どちらか一方の責任が明確になるまで作業を分解」することの有用性について記載されています。

これは、非常に大切な視点である一方、私にとっては少し悩ましいことでもあります。
（いつも、役割分担の表記に苦慮しています。）

今までの記載内容にも関連するのですが、
私自身が作成する　システム提案依頼書の発行時に添付するＷＢＳ　また　プロジェクト開始時のＷＢＳにおいては、ＷＰの粒度の関係から、
どうしても、複数の組織（自社、顧客、構築ベンダ）が役割を担うように記述されるＷＰが発生してしまいます。

これを回避したいと思っているのですが、スンナリとは行きません。
どうも、そのようなＷＰは、ユーザ企業（または構築ベンダー）も役割を担うべきＷＰであることを認識していただきたい、というケースに発生するようです。
よって、ＷＢＳ詳細化（工程ごとの詳細計画作成）時に、その曖昧さを排除するよう、詳細計画をチェックいています。


ちなみに私は、「プロセス」の視点でＷＢＳを作成し、最終成果物が網羅されているかをチェックします。
また、実は、「プロセス」の視点で検討する際、そのプロセスへのインプットとアウトプットを定義することにもなります。
よって、中間成果物の漏れも少なくなるように感じています。

この視点は、システム構築プロジェクトの他のプロジェクト計画作成時においても応用できます。


その他、
日経ＳＹＳＴＥＭＳ（発行：日経ＢＰ社）の記事は、参考になるものが増えてきているように感じます。
一方、日記コンピュータ（発行：日経ＢＰ社）の記事は、少し志向が変わってきたかな？と感じているところです。

システム構築プロジェクトの成功要因

最近、あるシステム構築プロジェクトが終了しました。
このプロジェクトは、超上流工程は私がＰＬ、構築フェーズが他者がＰＬを実施しました。
よって、最近の私の出番はほとんど無い状況だったのですが、構築フェーズの中心メンバーが本当にがんばってくれました。


そのプロジェクトについては、以下の観点から「成功」という評価をしたい、と私は思っています。

１．システム化目的の達成に手ごたえが感じられていること
具体的な内容は言えませんが、お客様からは、そのような評価を頂きました。
これは、成功と評価するための大切な条件だと思っています。

２．ＱＣＤが守られたこと
特にＱの定量的な評価は未実施なのですが、
以下３．の状況も踏まえた上でのＱ、そしてＣ（予算）、Ｄ（納期）とも、要求や計画をほぼ満足できました。
一部の追加要求によりスコープ変更は多少発生しましたが、関係者の合意の上で予算追加等もスムーズに行え、特に大きな問題もなく対応できました。

３．関係者の満足度が高いこと
これも定量的評価は実施していません。
しかし、顧客サイド、構築サイドとも、今回のプロジェクトへの満足度は非常に高いようです。
特に顧客サイドからは、
①システム移行時に混乱が無かったこと、②納期が守られたこと、③システム化目的の達成の手ごたえが感じられること、
などについて高く評価いただいている様子です。


この成功の要因について、私個人としては、次の事項をあげたいと思います。

Ａ．顧客の協力姿勢
今回は、要件定義・基本設計・総合テスト・運用テストなど、
顧客に注力していただきたい工程において、役割分担どおりの対応を実施していただきました。
これは、キックオフミーティング等において、役割分担に関する合意形成が十分にできたこともありますが、
やはり、顧客サイドＰＬの「約束を守る」という「誠実さ」の存在が大きかったように感じています。

Ｂ．開発ベンダーの協力姿勢
開発ベンダーもプロジェクト成功に向けて、高い意欲で取り組んでくれました。
これは、ベンダー選定時に考慮したポイントでもあった事項です。
ただし、その事前評価は難しいです。今回はその評価が正しかった（当った）、ということになります。

Ｃ．プロジェクト計画とルールの徹底
ＰＬの性格も影響しているのですが、今回はプロジェクト計画の大きな変更は発生しませんでした。
計画そのものが良かった点もあるのですが、その計画および運営ルールをＰＬが徹底したことが良かったのではないか、と感じています。
なお、計画を遵守することが目的化してはいけません。
しかし、安易な妥協は「習慣化」してしまう恐れがありますので、計画変更にはやはり注意が必要です。

Ｄ．超上流工程の実施
今回は、情報化企画からシステム調達までを顧客とともに実施するフェーズを設けました。
これにより、システム化目的、要求事項、システム選定基準が顧客と共有化でき、構築フェーズにおける大きなブレが回避されたと感じています。


なお、成功プロジェクトであっても、当然、反省点も多々あります。
それらも含め、プロジェクトの完全終結に向けた会議を実施し、成功要因と反省点を抽出の上、他プロジェクトに活かして行きたいと思います。

システム切り替えは慎重な対応を

前回、データ移行について私が考えるポイントなど を記載しました。

今回は、それに関連し、システムの運用切り替えについて記載します。
以下は、中規模以下のシステムで、特に情報システム部門の人員が少ない中堅・中小企業を想定しています。

少しわかり辛い「切り替え」という表現をしていますが、私は、現行システムから新システムへ運用を切り替える際は、必要に応じて段階的な切り替えをしたいと考えています。

例えば、エンド・ユーザ・ニーズに合わせ、木目細やかに製造された業務システムをパッケージ・ベースに変更する場合などは、特に慎重に対応すべきだと考えます。

過去は逆に、段階的な切り替えは難しいと考えていました。
特に、ＥＲＰなどのパッケージソフトウェアを用いて新業務システムを導入する際などは、データ移行回数や現行システムとのインタフェースのコスト面などから、所謂ビックバン的な導入しか現実的な選択肢はないと考えていました。

しかし、業務・操作教育、並行運用テスト、導入後の支援体制などについて、一括での切り替えでは対応しきれないと判断される場合、何らか段階的な切り替えを実施する必要があると思います。

当然だと思われるかもしれません。
一方、それは慎重すぎると思われるかもしれません。

実際のところ、上流工程のみでは、利用ユーザとの「認識の不一致」や仕様の「理解不足」などを全て防ぎきれないと思われます。
また、全ユーザに十分な業務・操作教育を実施することは難しいと思いますし、完全な並行運用テストを一斉に実施できない場合もあるでしょう。
その他、信頼性や可能性などの面においても、負荷テストで品質を１００％保証できるとは言い切れませんし、十分な負荷テストができない場合も多々あります。

事実、リリース直前までプログラム修正を実施するケースも多いと思いますし、リリース後にバグ対応やＤＢチューニング等を実施することも普通に発生していると思います。

以上から、「本番利用が始まってから始めてわかるトラブル」も発生し得ると考える方が現実的であると思います。

そこで、全面的な混乱やトラブルの発生を防止するために、段階的な切り替えという選択肢も必要になります。
これは、データ移行、システム導入後の支援体制、運用テストの実施方法・実施期間などと総合的に検討し、結果として選択される手段になると思います。

機能別の切り替え、拠点別の切り替え、そしてその混在などです。


さて以上については、スムーズな運用切り替えを下流工程で対応することの重要性のみを言っているわけではありません。

それらの切り替え方法については、「超上流工程」での「要求定義」の段階において顧客と検討し、「非機能要求」の一つとして定義することが重要であると言いたいのです。
そして、それら定義された内容は、ＲＦＰに記載します。
その上で、各ベンダーの提案を受け、要求内容を顧客と相談しながら調整していきます。
各ベンダーも経験豊富ですので、いろいろな提案が出てきます。

ただし、各ベンダーに一から提案を求めることはお勧めしません。
顧客により良いシステム切り替え方法を十分に検討していただき、それに対して工数・コストが必要であること、また妥協しなければならない事項があること等を認識して頂くことが大切だと思うからです。

また、既存システムにインタフェース対応が必要となる場合、早めに既存ベンダーから見積書を提出して頂くことと、どのような場合であっても協力していただくことを約束していただくことををお勧めします。
これは、新システムの構築ベンダーを決定する前が良いでしょう。


今まで記載しましたことは、データ移行についての記事などと同じことを述べています。
重複しますが、それは、「超上流工程」での「要求定義」段階において、データ移行やシステム切り替え、操作教育、導入時・導入後の支援体制などを「非機能要求」の一部として定義することの重要性についてです。
特に中堅・中小企業など、情報システム部門の人員が少ない場合には、十分な意識づけが必要であると考えます。

ちなみに、「非機能要求」については本当に範囲が広く、また奥が深いと思います。
これらについては、別の機会にコメントを記載したいと思います。

データ移行は慎重な対応を

前回までの記事で、システム運用テストについて や、操作研修について などについて、私の考え方をご紹介したことがあります。
今後はそれらに関連し、データ移行やシステムの運用切り替え等に関する、言わばシステムの移行に関する私の考えを、少し整理してみようと思います。

今回は、データ移行についてです。

私は、データ移行は大変なテーマ・作業であると認識しています。
小規模システムで且つ全く新規のシステムである場合などは、顧客が独力で対応できると思います。
しかし、中規模以上であったり、その上、何らかのシステムの刷新などの場合には、構築ベンダーにデータ移行を支援して頂く必要性が高くなります。特に、情報システム担当が兼務であるとか、システム規模の割には人員数が少ない場合などは、構築ベンダーによる支援は必須になると思います。

データ移行について構築ベンダーからの支援を検討する際、先ず明確にしておくべきと思われるのは、①移行対象データの範囲、②データ変換作業の実施者、③操作研修向けも含めたデータ移行実施回数、についてだと思っています。
以上について、私は要求定義における「非機能要求」で定義し、ＲＦＰで明記するようにしています。


①の「移行対象データの範囲」は、可能な範囲での特定になります。
要求定義段階と要件定義段階では、精度が異なりますが、
（要求定義と要件定義の違いに関する私の考え方 は、過去の記事 をご参照下さい）
マスター系データ、トランザクション系データ、残高系やサマリー系のデータに分類し、各データを明記します。
それらの元テーブルを特定することが、顧客にとって重要な作業になります。

ちなみに、トランザクション系データの移行については、新システムの構築ベンダーと既存システムのベンダーが異なる場合、対応して頂けないことも多いかと思います。
その可能性があることを理解した上で、移行に関する対応方法を決めていく必要があります。

私がご支援する場合、いずれにしましても、トランザクション系データの移行が必要だと思われた場合（例えば、現システムに存在する過去データについて、新システム導入後の業務でも参照する回数が非常に多い場合など）、先ずは非機能要求として定義します。
その上で、各ベンダーの提案を受け、要求内容を顧客と相談しながら調整していきます。


②の「データ変換作業の実施者」についても同じで、先ずは非機能要求として定義します。
データ変換は、顧客自身か、もしくは新システムのベンダーでしか実施は難しいと思います。
顧客自身でその対応ができない場合、新システムベンダーに実施を要求することになります。

ただし、これも新システムの構築ベンダーと既存システムのベンダーが異なる場合、対応して頂けないことも多く存在します。
特に、トランザクション系データについては多いです。

また、提案時や要件定義時では変換作業の実施について合意した場合であっても、基本設計段階や詳細設計段階において「データ変換は難しい」という判断になる場合もあります。移行リハーサルを含めたテスト段階でも有り得ます。
そのような事象も有り得る、という認識のもと、顧客とコンサルタントはあらかじめ対策（業務面・運用面での対応策など）を検討しておくことが必要だと思っています。

いずれにしても、一旦は顧客と相談した結果を非機能要求の一つとして定義し、各ベンダーの提案を受けてから調整していきます。


③の「データ移行実施回数」についても同じです。非機能要求で定義します。
特に、操作研修用のデータ準備について、移行テストの時期との関連などを分析し、独自で準備するか、移行テストの結果データを用いるかなどを決めます。
また、システムの切り替え回数も検討し、データ移行回数に考慮する必要があります。
それらを考慮しながら、データ移行の実施回数を一旦は明確化します。
その条件にて、各ベンダーに提案していただき、これも内容調整をしていきます。


その他、現行システムからのデータ抽出についても注意が必要です。
これは、顧客もしくは既存ベンダーの他は、責任を持った対応が難しいと思います。
顧客自身で対応が難しい場合、早めに既存ベンダーから見積書を提出して頂くことと、どのような場合であっても協力していただくことを約束していただくことををお勧めします。
これは、新システムの構築ベンダーを決定する前が良いでしょう。


以上のように、データ移行については、いろいろ慎重に対応する必要があると思います。
それらに関するポイントをＲＦＰやプロジェクト計画にしっかりと盛り込み、且つ、移行計画で詳細に検討していくことが大切だと思っています。
よって、それらに関する工数・コストへの理解が必要になります。

顧客側の責任範囲が広くて重要であることや、顧客が思っている以上に構築ベンダー側の支援工数がかかる場合が多いことなどを、顧客自身に十分に認識して頂く必要があります。
また、構築ベンダー側の計画や工数見積もりが甘くないかなどについて、十分にチェックすることも大切です。

以上が、私のコンサルティングサービスにおいて、データ移行面で重視しているポイントになります。

ＷＢＳはプロジェクト計画のポイント

前回の記事 の「操作研修」の関連で、「ＷＢＳ」について少し触れました。
今回は、その「ＷＢＳ」について、私の考え方を記載してみたいと思います。

「ＷＢＳ（Work Breakdown Structure）」は、プロジェクト計画において、作業を分割する手法です。
このＷＢＳから、役割分担やスケジュールが作成されます。よって、作成されたＷＢＳは、プロジェクト計画の骨子であり重要な前提条件であると、私は考えています。

分割された作業の最小作業単位（WP：Works Package）の目安は、３ヶ月、１ヶ月、１週間と、いろいろな考え方があるようです。
私は「明確な成果物または中間成果物を生成する作業」というレベルを最小単位にすべきである、と考えています。

例えば、前回の記事の関連で考えますと、「操作マニュアルの作成」は、１つの最小作業単位（ＷＰ）の候補であると言えます。
しかし、もう１ランク詳細にしてみますと、「詳細計画の作成」「操作マニュアルの作成〔レビュー前〕」「操作マニュアルのレビュー（成果物はレビュー記録）」「操作マニュアルの作成〔レビュー後〕」という作業分割も有り得るかと思います。

違和感のある方もいらっしゃるかもしれませんが、私は、後者の細かいレベルのＷＢＳを用いています。
ただし、プロジェクトの規模や性質（経験の有無など）などによっては、詳細化は難しいかもしれません。
その場合は、一定レベルまでで分割を終えて、その分割された個々の作業として、「詳細計画の作成（詳細計画を立てる作業）」を盛り込んでおくと安心です。

尚、各ＩＣＴベンダーは、おそらく標準ＷＢＳを持っていると思います。それをプロジェクト毎にカスタマイズしたり、また過去の類似プロジェクトのＷＢＳを修正して利用していると思います。
コンサルタントの立場としても、詳細化された標準ＷＢＳを一度作成し、見直ししていくサイクルが確立できればベストだと思います。そのＷＢＳを用いて、プロジェクト計画の考慮漏れなどを防ぐことができます。
その各作業（ＷＰ）について、プロジェクト規模別で「実施は必須」か「実施は任意」かを決めておくことも良いでしょう。

また、標準ＷＢＳには、ユーザ側が実施すべき作業も盛り込んでおくと、更に効果的かと思います。
例えば、「取引先への説明資料作成」「取引先との説明会実施」「運用マニュアル作成」「ユーザ向け説明会の実施」などです。
お客様よりも、コンサルタントやベンダーの方が、システムの構築・導入・移行に関する経験が豊富ですので、その経験知を最大限に提供すべきだと、私は思います。
ただし、システム構築を請け負ったＩＣＴベンダーにとっては、「お客様側の作業の目配りまで行うのは難しいし、また、そこまでの責任は負えない」という考え方もあると思います。
私もいろいろ悩んだのですが、あるコンサルタントから「全体のプロジェクト計画はユーザ責任であるべきなので、その支援は別契約または請負範囲とは別作業と位置付け、準委任による支援作業としてコストを見積もっておくべき」との意見を頂きました。以降、その意見を参考にしながら実務をしています。ただし、現在はコンサルタントやアドバイザーとして構築フェーズに関わっていますので、悩む機会が無い状況です。

その他、この「ＷＢＳ」については、雑誌やプロジェクトに関する図書など、いろいろ読みましたが、その中で最も参考になった図書をご紹介します（図書の名前は、”ズバリ”です。）

実務で役立つWBS入門 (プロジェクトマネジメントマガジン) Gregory T. Haugan 翔泳社 このアイテムの詳細を見る

以上、関連情報も含め、「ＷＢＳ」の私なりのポイントをご紹介しました。
違和感がある方もいらっしゃるかもしれませんが、一つの意見・考え方としてご理解いただきたいと思います。