アイテック公式ブログ

【クレームを回避するためにマネジャが最初にすべきこととは?】

2016年12月22日

 なんの疑問も抱かずに、システムの移行を終えた。ところがリリースと同時に使用者からのクレームが殺到。

 現行システムの使用者から、システム改善の要望は以前から出ていたが、「新システムにするときに直すから我慢して使って」「運用でカバーしておいて」といった、あいまいな回答をしてはぐらかしていたらしいのだ。

 新しいシステムに移行したのに全く変わっていないのであれば、使用者はもちろん怒りを感じるのではないだろうか。

<では、どのように仕事を受ければよかったのでしょうか?>

Ⅰ.システムの再構築について

 まず、メインフレームからオープンシステムへシステムを移行するシステム再構築の手法についてですが、以下の3通りの方法があります。リビルド(リメイク)リライトリホストの3通りで、それぞれ以下のような特徴を持っています。

1.リビルド(リメイク)

 システムをビジネスロジックのレベルから見直し、システムを根本的に作り変えてしまう方法です。リビルドであれば、新たな要望の取り込みや使わなくなった仕組み・システムの削除など、最適なシステムを構築することができますが、構築するための時間やコストが必要になります。利点は、作り直すのですから、新しい技術への柔軟な対応、運用コストの削減、新しい業務への柔軟な対応、業務の効率向上などに対応できることです。

2.リライト

 ビジネスロジックは維持したまま現行のシステムを廃止し、プログラムを別の言語で書き直す方法です。

 移行期間やコストはリビルドに次いで多く必要になりますが、新しい技術への柔軟な対応、運用コストの削減、新しい業務への柔軟な対応など、リビルドに次いで期待できる効果が多い方法です。

3.リホスト

 その名の通り、現行システム上のプログラムやデータには極力手を加えずに器だけを移行する方法です。互換のあるホストであれば、プログラムもそのままにして移行できますが、メインフレームからオープンシステムに移行する場合などは、通常リホストツールを用いて、プログラムなどを自動的に移行します。

 リビルドやリライトと比べて、比較的短期間でシステムを移行できるので、メインフレームを早急に撤廃する必要がある場合などに有効な方法です。

Ⅱ.仕様の確認について

 さて、問題の再構築プロジェクトですが、受注元から「仕様は現行通りでお願いします」と言われていたので、リホストの手法を用いて、有効なリホストツールを導入し、短期間で開発を終えました。

 現行システムのユーザビリティで、かなりのクレームが入っていたので、その改善を行うため、「仕様は現行通りでお願いします」では、間違った依頼をしていることになります。

 現行システムの過去のクレームを整理し、それを次期新システムに盛り込むか否かの判断をしなければならなかったのですが、それを怠ったため、間違った手法を選択したことになります。

Ⅲ.PMBOK第5版での教え

 PMBOK第5版から、知識エリアに「プロジェクト・ステークホルダー・マネジメント」が追加されています。第4版では、「プロジェクト・コミュニケーション・マネジメント」に記述されていたものが独立したので、全く記述されていなかったことではありませんが、その重要性が強調されています。

 記述されている内容は、下記のとおりです。

  • ステークホルダーを特定し
  • マネジメント計画を作成し
  • エンゲージメントをマネジメントし
  • エンゲージメントをコントロールする

 もう一つ、プロジェクトを開始するに当たり作成するのが「プロジェクト憲章作成(※1)」ですが、「プロジェクト憲章」のアウトプットは、以下の通りです。

  • 1.プロジェクトの目的または正当性
  • 2.測定可能なプロジェクト目標と関連する成功基準
  • 3.ハイレベルの要求事項
  • 4.前提条件と制約条件
  • 5.ハイレベルのプロジェクト記述と境界
  • 6.ハイレベルのリスク
  • 7.要約マイルストーン・スケジュール
  • 8.要求予算
  • 9.ステークホルダーの一覧
  • 10.プロジェクト承認要求事項
    (例:プロジェクトの成功を判断する事項、プロジェクトの成否を判断する人、プロジェクトの受入れの承認をする人)
  • 11.任命されたプロジェクトマネジャー、その責任と権限のレベル
  • 12.プロジェクト憲章を認可する、スポンサーあるいは他の人物の名前と地位

 以上のことを踏まえて、クレームを回避するためには、下記の3点を抑えておく必要がありました。

  • 1.で「今回のプロジェクトは、ハードウェアの保守期限が迫っているためのリホストである」ことを明確に謳う
  • 9.で「ステークスホルダとしてシステムの使用者」を含める
  • 12.でこのプロジェクト憲章を認可する人を決めて、認可されている

 では、なぜこの3点を抑えることができなかったのか?

 発注側は、事前に以下のようなリクエストを出す必要があったと考えられます。

  • 現状の正しい情報を引き出すために、「曖昧な回答ができないような詳細まで踏み込んだリクエスト」を出す。
  • 改善策の策定に動かすために、「改善の必要性を受け入れざるを得ないような事実を根拠とするリクエスト」を出す。
  • 策の有効性を高めるために、「改善策の因果関係のロジックを追求するリクエスト」を出す。
  •  発注側としては常に最悪の状況を想定して対策を打っておく必要があります。「発注側のプロジェクト管理」とは、「これはベンダの仕事だ」などと役割に拘泥することなく、「最良の結果を得るためにできること」を発注側自ら積極的に考えていくためのものです。そしてベンダに対する”詳細リクエスト”はその具体案です。リクエストの多くはベンダにしてみれば「言われなくてもやっています」というものかもしれません。しかしそこにあえて詳細な確認を入れていくことによって、プロジェクト目標の達成が確実なものになるでしょう。

     受注側としては、「本当にそれで良いのだろうか?」「実際に使用する人は、現行のシステムで満足しているのだろうか?」と疑う姿勢が必要でした。「関係者を集め、実際に使う人の意見を聞く機会を設けましょう。」などの提案を行い、再構築の方式を決定する前に「現システムの仕様通り」では、うまくいかないことが判明して、別の方式でやることもできました。

     この会社の情報システム部の名誉のためにここに記しておきますが、現行システムのハードウェアの保守期限が迫っており、ユーザ側の要望の取入れより、先に移行が必要であったという明確な理由はあったようです。

     近年は、アプリケーションオーナーを決め、システムの仕様(要件定義)の責任を持たせることもあります。誰の持ち物なのか、キーマンは誰なのかを明確にすれば、情報システム部は使用者からヒアリングして、取りまとめてITベンダに発注する必要はなくなります。ただし、だからと言って、情報システム部は、仕様の把握を怠ってはいけません。

    【25PDU取得可能!!】プロジェクトマネージャに必要なITプロジェクトの立ち上げから終結までの一連のプロセスをどのようにマネジメントしていくか学習するのにオススメコース!!

    【10PDU取得可能!!】プロジェクト推進に必要なリーダーシップを発揮するためのスキルを学ぶのにオススメコース!!

    【10PDU取得可能!!】プロジェクトマネージャがプロジェクト分析及び評価結果などの情報をいかに効率的に活用し,戦略の策定・見直しを行っていくか、戦略的マネジメントスキルを高めるのにオススメコース!!


    ※1:プロジェクト憲章
    プロジェクト活動をする上で、組織資源を適用する権限を持ち、プロジェクトマネージャーに与えるための文書作成のプロセスを表す。
    PMBOK引用・参考

    taga

    執筆者『多賀 康之(たが やすゆき)氏』プロフィール

    【豊富なシステム開発の実務経験と、人材育成のノウハウで、君のやる気を引き出す!】 ・独立系ソフトウェアベンダにてシステム開発、プロジェクトマネジャを経て、技術者・営業員の育成に従事。2011年に独立し、現在は、講師業、コンサルティング業に従事。
    ・保有資格は、特種情報処理技術者試験、ITコーディネータ、スキル標準ユーザーズ協会ITSS導入推進者認定、実践リスク・マネジメント研究会 リスク管理者認定、他多数。

アイテックブログをタグで検索