システムの「作り逃げ」を許すな

システムの「作り逃げ」を許すな、運用保守を担う技術者の時間が奪われる 沢渡 あまね (2020/03/25)

今に始まった問題ではないだろう。
昔大手ITベンダは、この問題を悪用してベンダロックオンしていたのだから。
一時期、一円入札が問題になった。システム開発を破格の低額で落札する大手ITベンダは多かった。
そして、長期間の保守費で元を取り、「作り逃げ」をちらつかせてリプレースの選考も有利に進める。
その結果、ITベンダはたくさんのIT土方を抱えたITゼネコンになったのが、今の日本のIT業界だ。

つい最近、開発中のとあるシステムで、メールを取得しなければならなくなった。
一部の機能のためにメールサーバーを立てるのは大変だから、運用担当は、Exchangeのメールボックに開発中のアプリでアクセスすれば良いと安易に考えていたようだ。

ところが、ExchageはBASIC認証ではアクセスできなくなっているから、OAuthで認証するコードを書かなければならなくなった。
サンプルは沢山あるからそんなに負担ではないけれど。

OAuthで使うクライアントシークレットはAzureADから取得するのだが、最長2年の期限付きだから、定期的に更新しなければならない。
更新は難しくはない。

クライアントシークレットの期限が切れると、当然だけどメールボックスにアクセスできなくなる。

このシステムの運用がはじまって、メールが取得できなくなった時には、システムの運用者、システムの開発者、M365の管理者が協力しなければ解決できないだろう。
構築に携わった人達がいる間は、運用できるけれど、いなくなったら障害が発生する可能性は高い。

経験では運用前に懸念があることは、必ず発生する。しかも、忘れた頃に。

M365の管理者なので、Exchangeを使わないことを主張したのだが、運用開始を優先する声に押切られてしまった。
クラアンとシークレットの有効期限など覚えていられない。PowerAutomateで通知することはできるけれど、システム開発者の知らないところで動いているPowerAutomに依存するのはいかがなものか。

「ほぼ一人情シス」だから、引き継ぎは結構なリスクなのだが．．．

技術者は、とりあえず稼働すれば後は関係ないという、易きに流されない良心が必要だと思う。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【ほぼ1人情シス】