システムを引き継ぐ-「水もれ甲介」にならないために

スポンサーリンク

弊社のお仕事は、ここ数年、新規に作る、というよりは、作り直す、あるいは引き継ぐ、というお仕事が比較的多いです。

例えば「会社が大きくなってきて、顧客に提供しているWebアプリケーションもでかくなってきた。が、開発に十分な社内リソースを確保する事が出来ないので、今後は企画や営業に特化したい。ので、御社に知恵袋兼開発を丸投げしたい」とか、「担当者が辞めてしまい、内製に限界を感じているので、御社で何とかならないですか」というのがそれに該当します。もっとクリティカルな事例だと「理由はいろいろあるが、とにかくすげー困っているので、今すぐ何とかしてくれ」というものもありました。こうなってくると、ほとんど駆け込み寺状態です。

で、この様な案件の場合、途中からシステムを引き継ぐ事になりますので、開発のレベルで言うと、それなりの場数やスキルが要求されます。0から作り直すのが一番シンプルですが、工期や予算の都合で、今のシステムをだましだまし運用していかなければならない場合もありますし、むしろその方が少なくありません。となると、それだけ践んできた場数や経験、スキルが要求されてきます。

それだけお客さんに信頼されているという事なのかな、とは思っていますし、また困っているお客さんを助ける、という点でとても意気に感じるお仕事なのですが、結構難しいお仕事であることも事実です。

何しろ中のソースを全部見渡してから着手する時間的余裕が無い事も多く、このため、「あちらを直したらこちらがおかしくなる」という事がまま起きます。あっちの穴をふさいだら、こっちの穴から水が噴き出す、というまさに水もれ甲介の最終回の様な状態です(これわかる人は年代がわかる・・・)。

その際に、お客さんにお話をしているのは「我々はお客さんのために、ベストを尽くしますが、何しろ人様のソースですし、時間があまりないので、全てを見渡してから着手する事は出来ません。このため、バグを直したら、別のバグが出る、という事が出てしまうかも知れませんが、それはご容赦ください」という仕切りを入れてから、作業に取りかかるようにしています。そういう仕切りをきちんと入れないと、単に開発現場へのプレッシャーがたかくなってしまうからです。

バグを出したくて出すエンジニアはいません。責任を現場になすりつけるのではなく、現場と共に考え、進める事が大事だと思っています。まあ、当たり前の事ですよね。

コメント

タイトルとURLをコピーしました