パニックＳＥの蒙昧人生

PDCAのP

だめなプロジェクトをPDCAから観てみる。

計画（Plan）に様々なリスクを想定しているか？

それもあるがよくあるパターンが、Plan → Do まではやるけど、Check がない。

従って、Action もない。。

失敗原因の７〜８割が、それなんじゃないかなぁ。

その理由は・・・

忙しいから！

サボってはいけない部分をサボっていると、後でツケがやってくる。

そのツケを対応しているので、他のプロジェクトをサボる。

これまで後悔するパターンは、ほとんどがそんな感じ。

サボってはいけないことを決めて、忙しくてもチェックポイントの仕事はサボらないようにしないと、いつまで立っても負のスパイラルは止まらない。。

そこで気がつく。やはりPlanが悪かった。。

Planning時点で、モニタリング計画がないからそうなる。

モニタリングした時に、順調でなかったらどうするかの計画も必要。

計画書に、以下を入れよう。

・想定されるリスクとその対策

・モニタリング計画（サボってはいけないチェックポイントと、順調でなかった場合の対策方法）

リスクは少しでも早く気づいたほうが、対策（Action）を立てられる場合が多い。

だからと言ってしょっちゅうプロジェクトを点検していると、

・うるさいと嫌われる。

・自分の目標とする仕事がはかどらない。

別のリスクが持ち上がってくる。

結局自分に過度な負担をかけることになる。

プロジェクトリーダーが頼りになると任せておいて良いのだが、そうでもないと自分の出番。

自分で自ら推進しているとうまくいく自信があるのだが、人に任せるとなると途端に不安が増える。

やはり幹部の人材育成が鍵なのか？

と、くるくると限りなく混沌の世界。。

「あわてず、あせらず、あきらめず」の精神で、

出来るところから粘り強く進めるしかない。。まずは計画書を見直そう。

今日のブログは全く出来損ないって感じ（沈）

システム開発の失敗原因

　みずほ銀行のシステム移行が始まったようです。

３度目の正直と行くのでしょうか。

　　　　　システム開発の失敗原因

　※ いろいろ考えられるので書き足しながら整理していきます。

《そもそもな理由》

・営業が実現不可能な仕事を採ってきた。

　　ろくな分析もしないで受けてしまった。

・計画段階でマスター入力や現システムからの移行計画等がすっぽり抜け落ちている。

《外的な理由》

・客先がいい加減。考えが浅い。協力しない。

　　客先担当者が、だめな人に交代した。

　　事前の話や仕様に対して、いい加減に扱っている。

　　開発途中になっても仕様がころころ変わる。

・客先担当者は実は現場を知らない。

　　客先が大きな企業だと、そのパターンがあり得る。

　　　　完成間近になって、この仕様ではだめなことがわかる事多し。

・客先内で要求が統一してない。

　　よくあるのが、経営陣と管理担当者の方向性の違い。

　　担当者一任していたのが、完成間近になって違うと要求してくる。

《内的な理由》

能力的問題

・プロジェクトマネージャの能力不足。

　　そもそも計画がいい加減。リスク管理もない。

　　開発進捗をしっかり見ていない。進捗報告を鵜呑みにしている。ほったらかし。

・開発メンバーが能力不足。

　　予想以上に能力不足。

　　使えない開発方法を選んでしまった。

　　　　　実績のないパッケージツールやフレームワーク等、雑誌やカタログで選んでしまって失敗するパターン。

　　試験工程を疎かにしているので、総合試験フェーズから進まなくなる。

　　途中でリーダーなりキーマンが交代した。

・その結果

　　無理して進めているうちにみんな倒れていく。。

製造工場の業務改善活動

現在製造工場の業務改善活動に没頭状態。。
顧客の社長が本気モードで燃えています。
投資額も、統合的な生産管理システムを新規で開発できるほどの予算です。
やりがいがあるので一緒に燃えている自分がいます（熱）

こうなった経緯にも運命的なものを感じる。

まず、自分がある経緯で尊敬しているITコンサル先生と一緒に仕事する機会があった。
社長に紹介したら、直ぐに気に入ってコンサル契約を結んだ。
その時点で自分は、その渦の中心人物の一人のポジションになった。

別件で、その客先でキーマンが退職して、製造計画が混乱した。
つまり、これまではスーパーなキーマンによる属人的な運用がされていたって事です。

この件で、混乱したのも影響して、客先に対して失敗をした。納期と品質。
自分から見ると、それほど大した事のないようにみえるけど、日本の工場は完璧な品質管理と間違いのない納期を求められている。
今回は客先の顧客であるメーカーさんが、業務指導に乗り込んできた。本気モードで是正命令的な指導。
どうも、そのメーカーさんも、現在イノベーションの最中のよう。

そんなこんなで、このコンサルさんと社長を中心として業務改善活動は、トップギアで突張している状況。
お二人とも能力が高く、人としても尊敬しているし、ウマの合う人物なので、私もやりがいがあるってことです。
これまでの生産管理システムノウハウの集大成の気持ちで向かっています。

幹部社員さん達は、もう混乱でカオス状態に近い（笑）
最初は分析したり、やることを決めたいなので割りと良いのですが、２〜３カ月経って、宿題が進まなくなってくる。。
自分も同じ（笑）

ここで、凄腕コンサルさんがどういう進め方をするかも、ちょっと楽しみ。
きっと通常でない方法を持っているのような気がしている。

SLA【 Service Level Agreement 】サービス品質保証

SLAとは、サービスを提供する事業者が契約者に対し、どの程度の品質を保証するかを明示したもの。

なんだか判りませんね。

色々とありますが、ここではITシステム導入後のサービスについて考える。

ITシステムの開発を請け負った場合、システム導入して終わりではない。
それだけでは、当初の目的である業務の効率化が達成されるわけではない。
うまく使えるようになって、初めて成功となる。

ユーザーは当たり前のように使い方を訊いてくる。
おとなしいユーザーは黙って頑張って使えるようになるように努力するが、わがままにしょっちゅう訊いてくるユーザーもいる。

品質の良し悪しにもよる。
プログラムの不具合（バグ）があるかもしれないし、説明書がわかりづらいかもしれない。もしかしたら説明書に嘘が書いてあるかもしれない。

まず、バグがある場合や、説明書に嘘が書いてある場合は、受け取らなければ良い。
つまり検収の結果、不合格として、品質が改善されるまで修正を要請する。

しかし、いろんな機能が詰まっている為、すべて試験するわけにもいかない。
そこは、契約時に品質保証の条項を入れて、６ヵ月とか１年とかの瑕疵（かし）責任を負うようにする。
家を建てた時と同じ。

さらに「使い方が判らない」とか、「操作性をもうちょっとだけ直して欲しい」とかの場合に、どこまでやるかの保証が、SLAとなる。
なにも決めないと、ユーザーから強要されて、請負側は多大なダメージを受ける場合がある。
業者によっては、ぶちきれてなにもしなくなるケースもある。
うちはお人好しなので、翻弄されてへとへとになるケース（泣）

周りの同業者に聞くと、大概は品質保証とサービス保証は、３ヶ月間は何でも対応するケースが多いようです。
SLAについては、特に決めていない場合が多い。
うちも特に決めてはいない。常識の範囲で対応していた。でもその「常識」は、発注側の「常識」とピタリ一致することはあまりないです。何と言っても金払った方は有利。

但し、当初決めた以上の機能を追加する要請が多大な場合は、別途見積りの上合意が取れればやらせて貰う。

SLAを調べると、決めるべきことは、以下になるそうな。
・対象サービス（範囲）
・サービスレベル目標
・役割・責任 -- これにはユーザーの責任も含まれる。

どうしてもグレーゾーンはあるにしても、以上の３要素は明文化しておくことが大事そうだ。

うちの場合、だいたい１年から２年くらいまででは、バグはもちろん無償保証しているし、要望も出来るだけ対応している。
あとは、保守料次第ってところです。

IT業界では、保守料もかなり曖昧模糊で、きっちり決めておかないとトラブルになります。

顧客不満足は勉強代

最近知り合った依頼会社の社長に、これまでのシステムについて感想を尋ねました。
過去に色んなシステムを入れて利用してます。

その社長が云うことには、

　「これまでシステム導入するたびに、結局勉強だった」

つまり、期待よりも満足が行かなくて、高く付いた分は次のシステム導入のための勉強代だった。
との意味です。

人のよい社長です。恨んだり、怒って恫喝したり、支払を遅らせていじわるしそうに無いです。
悪いことがあると、自分を改める方向で考えるタイプみたいです。

そう聞くと、「これまで払った勉強代を回収させてあげなければ！」と言いう気になります。