ITシステム導入よもやま話バックナンバー

こんにちは！近藤です！

今回は、

前回の「２４時間保守はつらい！」
の続きで、

開発部隊と保守部隊を分けている

会社の例を書きます！

私の経験したシステム会社の中には、

開発部隊と保守部隊を分けている

会社もありました。

大手だと結構多いのではないで

しょうか。

保守部隊は、

設計段階では、
設計レビューに、

テスト段階は、
統合テストあたりから
参加、

その後、保守部隊独自の
テストも行います。

そして、
保守部隊がOKを出さないと、
納品できない。

保守部隊独自のテストで不具合が
発見されると、
不具合1件につき7倍返し！！

開発部隊は1件につき7件の不具合
を探し出し、
その不具合を解消しないと、
納品できません。

（テスト不足と判断するわけです！
結構、仕様か不具合かで鬩ぎ合い
があったりもしました。。

また、

なかなか不具合が見つからず苦労

することもあれば、、

たまに、

保守部隊に
納品物（プログラム）を渡した翌日には、
すでに、いくつも不具合が見つか
っていた、、、
なんてこともありました。。（＾.＾）

そして、

保守部隊がそのまま保守へ移行する。

設計レビューに参加し、テスト段階から

システム開発に参加することで、

保守移管がスムーズに運んでいましたね。

開発側は保守の負担が軽くなるため、

新規案件の開発に集中できます。

また、他にもこんなメリットがあり

ました。

保守部隊は、さまざまな案件の設計

レビューに参加するため、

会社の設計パターンを把握、

設計の統一化や、

「このパターンならあの案件に
　あった！」

「これなら、あの人が詳しい」

などリソースの共有化にも貢献できて

いました。

また、不具合パターンを蓄積するこ

とになるため、

設計段階での不具合潰し、また、

全体的な品質の向上にもつながって

いましたね。

そう！

保守部隊が

ナレッジマネジメントの中心の

ようになっていました。

また、

納期短縮、コストカットするために、

開発を外注に委託して、

保守部隊のみ自社でおこなう

プロジェクトもありました。

このような開発管理システムを構築

するのも手ですが、

やはり、この保守部隊をつくる

ときに必要になるのが「カネ！」。。。

保守料を確保しなければいけません。

保守料は結構軽くみられがちです

が組織の収支を圧迫します、

案件を取るのに必死で忘れがち

ですが、間違えると長い目でみて

大赤字！！

となる場合も多いようです。

営業は、受注時の成績で報酬評価が

きまるため、どうしても甘くなりが

ち、

「システムが不具合を作りこむから

保守が必要なんだ！」

と逆切れする営業マンもいましたね。

オープンシステムがよくわかって

いないのかもしれません。

年に数回のトラブルコールであった

としても、顧客の業務運用によって

は３６５日の保守が必要な場合も

あります。

ITシステム導入プロジェクトには

長期的視野（保守まで考えた）

で考慮したシステム開発管理、

保守料、保守体制が必要！

そうでないと、保守業務が会社の

収益を圧迫することもあるんですよ！

■■　編集後記

本号も最後まで読んでいただきありがとう
ございます。

感謝です！

ヤクルトが初のファイナルＳ進出!!

ヤクルトファンのみなさん！

おめでとうございます！

「セＣＳ１Ｓ第３戦、
ヤクルト３‐１巨人」

でヤクルトが勝利！！

ヤクルトが２勝１敗で
ファイナルステージ（ＦＳ）
に進出です！

中日とどっちが抜けるか。。

私は、ソフトバンクホークス
ファンですが、

こちらは、毎度の、、

秋の風物詩にならなきゃいい
のですがね。。。

■■　携帯サイト

CR北斗の拳 百裂アプリダウンロードはこちら
CR北斗の拳 剛掌(ごうしょう）アプリダウンロードはこちら!サミーモバイルサイトで！
パチスロろくでなしBLUESアプリダウンロードはこちら！サミーモバイルサイトで！

 
　今号も、最後までお読みいただき、どうもありがとうございました。
 
発行者メールアドレス⇒fujihiro_syscon@yahoo.co.jp
バックナンバーブログ⇒http://itohanasibkno.side-story.net/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━