データー移行のリハーサルと移行判定

翌月に、データー移行を控えてます。
今回は、テーブル定義等が新たになる新システムへの移行であり、たいへん神経を使います。


小規模な地域のシステムベンダーさんは、今までの経験からの自信であったり、また人的リソース面などから、移行計画が甘くなる場合があります。
しかし、それにあわせることなく、しっかりと計画を出していただき、必要な作業は実施いただくことが重要です。


特に移行リハーサルと移行判定について、実施計画が甘い場合が多いです。

リハーサル（これは通し検証を含みます）の計画自体が無い場合があります。

また、全てのデーターについて、移行判定をデーター件数のみで実施しようとしている場合があります。


システムの性質や規模等にもよりますが、これらは、たいへん危険です。


また、リハーサルの結果、移行判定の結果は、必ずお客様へ報告・説明する必要がります。

それらを含めた計画化が、データー移行に伴うリスクを軽減してくれます。


＜関連記事＞
　データ移行は慎重な対応を
　システム切り替えは慎重な対応を

　超上流工程からシステム運用テストまでにおける考慮事項

プロジェクトマネージャーとプロジェクトリーダー

プロジェクト全体に責任を負う立場として、次の２つがあげられると思います。

・プロジェクトマネージャー（ＰＭ）
・プロジェクトリーダー（ＰＬ）

それらを皆さんは、どのように整理されているでしょうか？


私は、一般的な整理とは異なるかもしれませんが、

・ＰＭは、プロジェクトの全アウトプットのＱＣＤに対して、プロジェクトオーナーへ全責任を負い、
・ＰＬは、プロジェクトの一部のアウトプットのＱＣＤに対して、ＰＭとＰＬへ責任を負う、

というように、先ずは考えています。


また、ＰＭが複数プロジェクトに参画していたり、また、大幅な稼働を割けない場合には、その直下に全体の推進責任を負うＰＬを立てることも多くあるかと思います。

その場合のＰＭとＰＬについては、

・ＰＭは、プロジェクトの全アウトプットとＱＣＤに対して、プロジェクトオーナーへ全責任を負い、
・ＰＬは、そのために必要な業務をＰＭから委任される、
・またチームリーダーは、プロジェクトの一部のアウトプットのＱＣＤに対して、ＰＭとＰＬへ責任を負う、

というように整理をしています。


私が外部コンサルタントとして参画する場合における組織設計では、後者を基本にした組織設計にした場合が多いです。

理由は、
プロジェクトの推進者として期待される方の組織内の公式な役職自体が、それほど高くはない場合が多く、
よって、プロジェクトの責任者には、組織全体に一定の公式な（大きな）間影響力を持つ方に担っていただくことで、
プロジェクト組織内外の力関係のバランスや推進力が最適化できる、と考えられるケースが多かったからです。

その他、自分がＰＬとして参画する場合には、後者の立場となり、プロジェクト全体の推進責任を負います。

基本設計フェーズにおける注意事項など（その2）

あるプロジェクトで、基本設計フェーズが間もなく終了します。

以前、「基本設計フェーズにおける注意事項など」という記事で、
私は、基本設計フェーズで「ユーザ部門にしっかりと関与していただくこと」が、成功要因の一つであると記載しました。

さて今回は、構築ベンダーとの関係における注意事項について、私の考えを記載します。


一口に「基本設計」と言っても、構築ベンダーによってドキュメントの範囲や詳細度が異なります。
よって、要求定義書やプロジェクト計画書に「基本設計書」と記載しても、その認識は大きく乖離する場合が多いです。

私は少なくとも、基本設計フェーズの成果物を列挙した上で、構築ベンダーと摺り合せをします。
列挙する場合、概ね、基本的なものとしては以下のような構成になります。

　　・システム構成図
　　・データーフロー概要図
　　・画面一覧
　　・画面遷移図
　　・画面仕様書
　　・帳票一覧
　　・帳票仕様書
　　・バッチ処理一覧
　　・バッチ処理仕様書
　　・テーブル一覧
　　・移行計画
　　・総合テスト計画
　　・バックアップ計画

スクラッチ開発とパッケージ活用、またプロジェクト規模や外部システム連携の有無などで増減がありますが、
それら成果物ごとに構築ベンダーが認識する成果物のレベルを確認し、調整をかけます。

そもそもは契約段階で一旦打合せをしますが、担当ＳＥによっても解釈が異なる場合もあるため、基本設計フェーズ開始前に、必ず再度の認識合わせを行います。


「基本設計＝外部設計」と認識し、単なる「一覧（画面／帳票）」と「イメージ（画面／帳票）」のみを基本設計書の構成要素と考える構築ベンダーもいます。

それらは、エンドユーザーと直接契約する小規模ベンダーに多いように感じます。
「つくりながら考える」というスタイルで、良い点もあるのですが、後半の認識相違やモレが多数発生するケースも多いです。


それらは極端な例ですが、
私がコンサルタントまたは元請側のＰＬとして参画する場合、情報システム部門が無いか、または情報システム部門の人数が数人の企業であり、「基本設計」とは何かについてピンとこない場合が多いです。

よって、初歩的ではありますが、
「要求事項」を「どのように実現するか」についての「認識合わせ」をすることが、基本設計フェーズの目的であり、
その基本事項を再認識することで上流工程の品質が一定レベルで維持できると、私は考えています。


＜関連記事＞
　超上流工程からシステム運用テストまでにおける考慮事項
　基本設計フェーズにおける注意事項など

協力会社を信頼する

最近、私がよく感じることは、私は比較的、他者よりも協力会社を信頼する度合いが高いようです。

定量化できるものではないのですが、
・ギリギリの判断が求められる際、協力会社の意見と能力をあまり疑わない。
・協力会社が犯したミスについては、その協力会社を選定しマネジメントしている自分の責任と感じる度合いが強い。
・トラブルが発生した場合、協力会社は必ず解決に向けてベストを尽くしてくれると思っている。
という意識が比較的強いようです。


よって、「甘い！」と遠まわしに言われる場合があります。
双方の立場には強弱があり、それの立場が崩れて失敗する、という考えのようです。


しかし、私は、例えばある問題を解決する場合、まずはその問題を解決することが重要であり、そのためには協力会社に能力を１００％発揮してもらうことが大切だと思っています。

そして、その問題がなぜ発生したかについては、協力会社に原因がある場合が多いですが、それが原因の全てではなく、やはり協力会社をコントロールする立場の自分自信に原因が見つかる場合も多いのです。


よって、協力会社に問題の原因と責任を全て押し付け、厳しく糾弾することは、私は好みませんし、間違っていると思います。
（過去には相当に品の悪い言葉、つまり暴言を協力会社に向かってはいたこともありましたが。。。）

また、そのように原因の全てが協力会社であるような対応をするＰＬ／ＰＭは、逆に協力会社が対応してくれた変更や追加への対応についても、「当然である」「うまくねじ込んでやった」という思いを持っている場合が多いように感じています。
このような、協力会社が仕様の「グレーゾーン」に誠実に対応してくれた場合は、私は感謝すべきであると思うのです。


まとまりのない記事になってしまいましたが、
（協力会社との役割分担が契約・計画に記述され、且つ、認識合わせがなされていることは大前提ですが。）

協力会社は「協働」の相手であり、「強弱」の関係ではなく、よって双方の「信頼」がないと成功は無い、と私は思っています。
そのような思いでプロジェクトをマネジメントしていけば、さまざまな問題発生時に協力会社がベストを尽くして要求以上の成果
を上げてくれることを、私は信じています。

プロジェクト計画とプロジェクト運営ルール

システム構築プロジェクトにおきましては、必ずプロジェクト計画が必要になると、私は考えています。

その際、システム化企画や要求定義という「超上流工程」の場合と、要件定義・基本設計以降の工程とは、内容は大きく変わります。
プロジェクトの成果物、実施内容が異なりますし、スケジュールや体制等への考慮事項も変わってきます。

現在、その「超上流工程」を終えて、システム構築フェーズが開始されるプロジェクトが控えています。


システム構築フェーズにおきましては、システム開発規模にもよりますが、私は基本的に、計画書と運営ルールを統合して作成します。

理由は、プロジェクト運営ルールは「コミュニケーション・ルール」を確定し文書化することがポイントであると私は考えており、
それはすなわち、プジェクト計画の「コミュニケーション計画」の具体化と概ね一致すると感じているからです。

以上から、ある規模レベルまでのプロジェクトであれば、プロジェクト計画書の中にコミュニケーション・ルールを包含することで、実質的には、プロジェクト運営に必要な基本事項が整理できると、考えています。


なお、最後にもっとも大切なことは、それを関係者としっかり共有することです。
もちろん、その関係者には、お客様のプロジェクト責任者やプロジェクト・リーダーを含みます。
キックオフ会議やキックオフミーティングという公式な打ち合わせの場で、最終の認識合わせ・情報共有を図ることをお勧めします。

この認識合わせや情報共有をお客様と実施しない場合、その計画やルールを文書化する意義は、全て失われると言っても過言ではないと、私は思っています。


＜関連記事＞
　超上流工程からシステム運用テストまでにおける考慮事項

　プロジェクトのキックオフ会議
　プロジェクトのキックオフ会議（その２）