保守できなくなり、塩漬けにしたままのオープンシステム—。いま“オープンレガシー”が情報システム部門を苦しめている。
…
1990年代から2000年代の初め、オープンシステムは「早く安く作れる」「新しい技術が使える」「1社のベンダーに縛られない」といった輝きを放ち、“自由”の象徴だった。このメリットを追って、多くの企業がメインフレームからオープンシステムへと開発の軸足を移した。
だが今、その輝きは色あせ、輝きの裏に隠れていたデメリットが情報システム部門に重くのしかかっている。「早く安く作れる」というメリットは「作りすぎて保守できない」というデメリットに裏返された。「新しい技術が使える」というメリットの裏には「選んだ製品が廃れる」というデメリットが、「1社のベンダーに縛られない」の裏には「組み合わせの制約で更改しにくい」というデメリットが存在した。
…
メリットを追い続けてとにかく作り続けた結果、振り返ればオープンシステムはレガシーとなって企業を苦しめている。しかし、開発コストとスピードを考えるとメインフレーム時代には戻るのは現実的ではない。
同記事は、「オープンレガシーを救う七つの鍵」をこの様に挙げています。
運用を立て直す (ISMS、ITILを導入する等)
保守切れソフトを更改する
標準化で範囲を狭める
技術マップを持つ
陳腐化させない努力を続ける
仮想化は一時避難所と考える
所有か利用か、スタンスを明確にする
この中で出来ていないとすれば最優先すべきは、「3. 標準化で範囲を狭める」でしょう。
このご時勢ですしIT投資は抑制気味でしょうから、オープンレガシーがどんどん増えていく状態ではないかもしれませんが、ハードウェアやミドルウェアのリース契約更新、耐用年数、保守期限など、ハードウェアやOSやミドルウェアのマイグレーションは定期的にやってくるでしょう。
これ以上増やさない為にも、情報システム、特にハードウェア、OS、ミドルウェア、インターコネクト（ネットワーク）などのインフラストラクチャ部分の「社内標準化」と、情報システム部門による稟議フローへの積極的介入が必要です。
何より、最適化するチャンスでもあります。
モノによっては、SaaSに移行した方がええやん、と言うモノも結構あるでしょう。
特にコモディティ化が顕著なモノは沢山あるでしょう。
例えばDNS、メールサーバ、勤怠管理、グループウェア、等など。
運用系の人は、世の中の技術トレンドをよくウォッチして、積極的に経営層に具申していかなければいけません。
そのためには、まずなんでもオンプレミスでやりたとか言うこだわりは捨てましょう。
あと、レイヤの違う人と話をするスキル、プレゼンテーションをするスキルを身につけないといけません。
最初はなかなか判って貰えないでしょうけど、場数も必要でしょう。
相手に理解してもらうには、辛抱強く訴え続ける事も必要かもしれません。頑張りましょう。
それにしても、どうも「システム運用」系の人々は地位が低い事が多い。
アプリケーションを作る開発系の人々は元より、運用系にも開発系にもどちらにも生息するインフラストラクチャを設計・構築する構築系の人々よりも、一段下の扱いを受ける事が多いです。
原因は色々あるんだけど、運用系は「売り」に直結して無い事で経営層から軽視され、「技術スキルと単価」から相対的に開発系と構築系から下に見られがちです。（あくまで一般論です）
あと、職責上どうしても「安全側」に偏った考え・発言が多いのも運用系の特徴です。それが仕事の一部だから当たり前だけど、嫌われ者役にならざるを得なかったりします。
運用上見つかった不具合を報告するのも仕事なので (ITIL的に言うと RFC、Request For Changeですね)、これまた喜ばれる事は少ないです。開発者の方々、フィードバックをくれる運用系の人にはちゃんと感謝しましょう。
不具合の対処といえば、原因究明できれば治ったも同然なんですが、それが一番難しいんです。
オープン系のシステム、特にオープンソースを多用していると、何が起こっているかを正しく知る事はあまり重要でないというか、難しいんです。それよか怪しい所を交換してみようとか、そういう運用になる事が多いです。Googleのハードウェアに対する考え方がそうですね。
で、原因がアプリケーションだと判明した時、それを直そうと思っても最新のソースコードどこにあるねんとか、ビルド環境ってどうやったけとか、その言語はもう使える人いませんよとか、ドキュメントないですけど直したとして他との影響が無いかどうやってテストすりゃええねんとか、ステージング環境なにそれとか、なんかガッカリな状態だったりする訳ですよ。
結論として「運用対処の方が安くつくよね」と言う事が結構あります。
それはそれで良いんですけど、運用系の人はちょっとだけ傷つきます。
私もその台詞良く言いますごめんなさい。
運用系側の視点に立つと、開発・構築系の方々の担当するフェーズ（企画、設計、開発、実装、試験）での短納期でやっつけちゃったね的な事とか、コスト制約とか、大人の事情とかでの、ムリのしわ寄せ出てるでしょう的なシステムが大半な訳です。ぶっちゃけた話。
何色々ケチってクライアントや上の言いなりになってテキトーにつくってやがんだこのやろうドキュメント出せやとか、本音では思ったりする事もしばしばなんですよ。
それでも運用系の方々の大半は、開発系の方々を技術的にリスペクトしているんです。自分には出来ない事が出来るから。開発系が良いモノを作ってくれた時なんか、我が事の様に喜ぶもんです。
どうです。愛おしい気持ちにさえなってきませんか。
逆に開発系の方々は運用系の仕事が出来るか？と言えば、オペレーションはある程度は出来ちゃうんです。良くも悪くもドキュメンテーションが運用管理の基本だから。
開発系の方々は、なんとか頑張って研修制度とかを設けて3ヶ月位やってみたらえーんですよ。マジで。運用フェーズの経験が無い開発者の方は特に。
なぜなら、運用フェーズがイメージ出来ない人には保守性の高い成果物なんて作れないからです。さもなくば座禅組んでTCOについて72時間位考えて見てください。