システム導入後の評価

あるサブシステムの運用を開始し、３ヶ月が経過しました。
戦略的な意図を持って開発したシステムです。

その導入後の状況について、企画・構築の中心メンバーから「失敗では？」との言葉が聴かれました。


そもそも、システム導入の成否を判断するためには、まず、評価指標とその状況を確認しなければなりません。

これは、システムそのものの評価指標と上位目的の状況に関する評価指標が必要になります。
ちなみに私は、この上位目的、言い方を変えますと戦略的な目的・目標の達成度、または達成に向けた先行指標の状況を把握することが大切で、システムそのものの評価指標（品質面の指標、利用頻度等の運用定着度など）の目標値は達成して当然であると考えています（納期やコスト面の目標は未達成となる場合もありますが。。。）。

まだ３ヶ月の経過期間であり、本格的な導入効果を得られる時期ではないのですが、
「失敗では？」という印象を持った場合においては（そもそも、そのような印象を持つ持たないに限らず）、先ずは、しっかりと評価指標とその状況を確認することが必要になります。

安易な印象で「失敗」と評価しますと、その評価が起因して、システムの利用に対してネガティブな雰囲気が醸成されてしまいます。
特に、利用者自身にとってのメリットが短期的には得られにくいシステムの場合は、なおさらです。

当初は評判が悪い？システムでも、１年後、２年後には、そのシステムがないと業務が回らない、という状況になるような経験してきています。
繰り返しですが、そのシステム化の上位目的・目標の達成に向けた状況で、評価する必要があります。


また、その「失敗」という評価や印象を持つこととなった場合、その原因として「運用の問題」として扱うことにも注意が必要です。

運用が定着しない理由は、「システム化の目的を伝える」などの動機づけの失敗、業務フローやルールの未徹底などの場合が多いですが、システムの品質や操作性が起因している場合もありますし、
また、設計上の前提とした業務ルールそのものが不適切であった場合もあり得ます。

よって、運用とシステムの両面から、原因と対策を丁寧に検討していく必要があります。


客観的な視点で評価すること、そして丁寧に原因の把握と対策を講じていこうとすることが、
システム導入の失敗を回避し、最終的に成功へ導く姿勢なのだと、私は思います。


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

　超上流工程におけるＢＡＢＯＫの有効性（その4）

　システム化の目的を伝える
　システム化の目的を伝える（その2）

　ロジカルシンキングの実践（その１）
　ロジカルシンキングの実践（その２）
　ロジカルシンキングの実践（その３）

ライセンス数の適用誤りと専門性

最近、初歩的なミスを犯してしまいました。

ミドルウェアなどのライセンス数不足に気付いたのです。

システム構成やハードウェア機器の変更に伴い、それらライセンス数を変更する必要性が生じる場合があります。
サーバー台数の変更、ＣＰＵ数の変更、ＣＰＵコア数の変更、サーバー仮想化の適用などなどです。

また、それらソフトウェア等のメーカーの方針変更により、ライセンス数のカウント等が変わる場合もあります。
曖昧だったものが、サーバー台数／ＣＰＵ数／ＣＰＵコア数によるカウントに変更されたり、また、同時接続の定義が変わったりする、などなどです。


その件については、皆様よくご存知のとおりかと思いますが、

実は私は、アプリケーションソフトの他は、それら必要ライセンス数の算出については、ほぼ見積もりを依頼するベンダーに任せているのが現状です。
基本的な条件を指定した上で、逆にベンダー等がそれらの算出に必要な条件を質問してきます。
その結果として、正しい数量で見積もりされ、正しい予算が作成されます。

しかし、ベンダーの算出の考え方では誤っている、という場合もあります。

これらは、今までの経験が乏しい、また専門ベンダーなのでカウント等を誤ることを想定していないためチェックが不足する、という原因により生じたものと分析しています。


まずは自分のチェック能力を反省しているところです。
そして、その対応策を検討し実施します。


もう一方、その数量を算出したベンダーについては、まずは反省を促したいと思います。
その際、「その条件は聴いていなかった」などなどのコメンが聴かれることと思います。

しかし、必要ライセンス数を算出する場合において、条件を確認する、または想定条件を提示する、ということは、最低限度の専門家（システム構築ベンダー）としての行動であり、それを実施しないことを反省しない、ということは許しがたいことだと、私は感じています。


繰り返しですが、先ずは自らを反省し、そしてベンダーにも反省を促す、その上で、更なる信頼関係を構築するための行動が成されれば、それらのミスはマイナスにはならないと、考えているところです。

リリースかリスケジューリングかの判断

突然ですが、

プロジェクト計画において、スケジュールを立てた後、一切、スケジュール変更が無かった、

という経験を豊富にしているＰＭ・ＰＬはいるのでしょうか？


残念ながら、私が受け持つプロジェクトは、今まで必ずスケジュール変更が発生します。


もともと厳しいスケジュールのものは、どうしても終盤で遅れの取り戻しが現実的にできない、という状況になってしまいますし、

また、ある程度の余裕を持った（予備をもった）スケジュールにしますと、構築ベンダーさんが油断？をし、遅れが発生してしまします。
正しい進捗報告と、その報告から状況をしっかり読み取れればよいのですが、なかなかうまく行きません。


その他、そもそもスケジュールは崩れるという前提で、十分に検討したスケジュールを立てる習慣がない構築ベンダーさんも中にはいます。
「最終的にエンドは合わせます」というスタイルなのですが、その合わせた結果としてリリースされるプログラム等は、けっして満足のいく品質ではない場合が多いように感じます。


更にリリース判定の時期になり、通常ではリリースできないという状況である場合、

・リリース後の対応とリスク対策を決定した上でリリースする。
・リスケジューリングする（リリースの延期）。

という判断をせざるを得ない状況になります。

これは、通常はあってはならないことかもしれませんが、現実的には良くある状況ではないでしょうか？


この判断には、本当に頭を悩ませます。

その判断の結果で、とても苦い経験をしたこともあります。
（しかし最終的には、そのタイミングでリリースしたことで、更に大きな問題の発生を止めることができました。）

本当に頭を悩ませますし、楽しい時間ではないのですが、

そのプロジェクトが終わった後、メンバーへ「ありがとう。あなたの○○のおかげでうまくいきました。」という言葉をかけることをモチベーションにして、何とか対応して行きたいと感じているところです。