前回は，レイムダック化（弱体化）するシステムと，SIベンダーのSEとの関わりを見るために，SEのあり方をその「生きがい論」から検討してみた。その結果，SEのモチベーションを上げるには「顧客から感謝される」ことが重要な要素であり，SEの「システム責任能力」が必要なことが分かってきた。
今回は，SEの「システム責任能力」を検討しながら，SEとシステムのレイムダック化との関わりを見ていこう。
軽視されやすい「運用・保守」フェーズ
SEがシステムを構築するときの大きな流れは，「お客からの要求聴取（BPRによる業務改革もあり得る）」，「要件定義」，「設計（外部設計，内部設計）」，「プログラミング」，「テスト（単体・結合・統合・運用）」，「システム納入」，「運用・保守」となる。しかし，プロジェクトの環境はもちろん，ビジネス環境が激しく変わるので，この流れはスムーズには行かない。その間発生する様々な問題の解決も求められる。
従って，環境変化への対応も含めて，これらのフェーズのいずれかに手抜きや欠陥があると，システムはやがてレイムダック化する可能性を持つ。特に「設計」までの段階で欠陥があると，その可能性は大きくなる。
それぞれのフェーズの重要性は関係者によってよく認識され，よく議論されている。だが「運用・保守」については，軽視されやすい傾向がある。そのため，ここがSEの「システム責任能力」のポイントと言える。SEの多くは「運用・保守は自分の責任外」という認識を持ちやすい。
システムのどこまで責任を持つかについては，SEとユーザーの間ではしばしば衝突が起きる。売り手という立場にあるSEにとって，ユーザーへの不満は多い。例えば，トラブルの原因がバグのせいか仕様変更のせいか不明確なまま，手直しさせられることがある。また，見積もり時点でシステムを「作るだけ」と言っていたユーザーが，システムの本稼働後に手直しや保守が発生すると，「無料でやれ」と要求する場合もある。
ただ，SEの「システム責任能力」という観点から見ると，システムを導入しただけではSEはその目的を達成した，ということにはならない。それだけではSEのモチベーションにつながる「お客から感謝される」ことにはならない。納期を守り，運用を開始するのはもちろん，軌道に乗せた後もシステムの機能を維持し続けなければならない。品質はもちろん守る，問題の解決にも対応しなければならない。そして，保守にも関わらなければならない。ここに，レイムダック化するシステムに関わるべきSEの責任がある。では，具体的にはどのように責任を持つべきだろうか。
運用・保守しやすいシステムの構築はSEの双肩にかかる
「運用・保守」に費用が掛かるなら，見積書にきちんと盛り込む。もしユーザーの予算に限りがあるなら，予算内でできる範囲と，是非やらなければならない範囲とを十分に説明し，費用の差額がいくらになるかをユーザーに明確に説明すべきだ。それを怠り，後で「やってくれ」「できない」，「約束が違う」「約束していない」などと言い争っても何も生まれない。「説明責任」は，ほかならぬSE自身にある。SEの「システム責任」は，ここから始まる。
いよいよシステムが完成した後，SEはシステムが安定して稼働することを見届けなければならない。安定して稼働させるための運用管理の実務は通常，ユーザー側が担当する。また保守には，日常・定期・緊急の保守，それにシステム変更時の保守があり，ユーザーとSIベンダーとが分担する。契約に記載されていなければ，「運用・保守」は厳密な意味でSEの仕事とは言えない。まして，そのフェーズにおける「問題解決」は，SEの責任外だろう。
しかし，システムを構築する段階，つまり企画・設計の時点で，運用や保守のポイント，運用や保守のやりやすさを考慮しておくとあとあと助かる。その意味で，運用・保守しやすいシステムを構築できるかどうかは，SEの双肩にかかっている。システムの完成後，「運用・保守」のための十分なドキュメント／ノウハウをユーザーに引き継ぐこともSEの責任である。それが，運用後の問題発生，ひいてはシステムのレイムダック化を抑えることになる。
さらに，プロジェクト推進中の問題は，それがたとえ経営陣・情報システム部門・ユーザー部門などユーザー企業側の責任によるものであっても，SEは自分の責任という気概を持って対処しなければならない。何故なら，先に示した「要求聴取」から始まるシステム構築の大きな流れから考えても，SEがすべてに責任を持つつもりでプロジェクトを推進しなければならないからである。
ましてや「運用・保守」が契約の中に含まれるとすれば，SEは本稼働後にシステムが着実に軌道に乗ることを見届けなければならない。ここでSEは，レイムダック化しつつある，あるいはレイムダック化したシステムに関わることになる。もしレイムダック化の可能性や事実があれば，SEとして，ただちに手を打たなければならない。業務改革・要件定義に不適切な部分はなかったか，ユーザー企業はトップから担当部門に至るまで決められたことを確実に実行しているか，などをチェックする。その上で，問題点を明らかにしてユーザー企業に提示し，ユーザー企業の意識を高めながら一緒に解決に当たらなければならない。
最後に，ある中堅SEがしみじみ言っていた，筆者の印象に残る台詞を引用する。
いわく「私は営業ではないが，完了したプロジェクトのお客と個人的に時々接触するように心がけています。特にプロジェクト中に親しくなったユーザー部門の人を尋ねたり電話をしたりして，その後のシステムの状況を聞きます。システムが有効に稼働していなかったり，ほとんど死んだりしていると聞いた場合は悲しくなりますが，再生を願ってできるだけアドバイスをします。何よりも，自分が次のプロジェクトに役立つ情報を得られます」と。
→増岡 直二郎バックナンバー一覧へ |
■増岡 直二郎 (ますおか なおじろう)【略歴】 小樽商科大学卒業後，日立製作所・八木アンテナなどの幹部を歴任。事業企画から製造，情報システム，営業など幅広く経験。現在は，nao IT研究所代表として経営指導・執筆・大学非常勤講師・講演などで活躍中。 【主な著書】 『IT導入は企業を危うくする』，『迫りくる受難時代を勝ち抜くSEの条件』（いずれも洋泉社） 【連絡先】 nao-it@keh.biglobe.ne.jp |
