#初めに
情報系の大学院を卒業後、大手金融のシス子に入社して4年と少し経ちました。成長したことや苦労したこと、世間でよく言うSIerの問題点についても少しづつわかってきたのでまとめを書いてみます。
#今までの経歴
・親会社が大手金融のシス子に入社
・社内WEB基盤システムの運用担当に配属される。
・WEB画面開発の助っ人として半年ほど開発・テスターを行う
・バッチ処理を行うシステムのPM補助兼プログラマになる←今ここ
#なぜSIerに入社したか
情報系の大学院を卒業したので、ITという専門業界に入ろうと考えました。コミュ障だったが、技術スキルに自信があったので、技術力を生かせる仕事がしたいと思っていました。
#入社後のギャップ
最初に配属されたのは、WEB基盤の運用担当でした。「ITなら開発でしょ」と思って、運用なんて知らない私はこれが第一のギャップでした。
配属されたのは、社内オープン系で最大のシステムでした。いわゆるRailsやSpringのような社内WEBフレームワークの一種だと思いますが、ハードや一般的でない機能まで包括しており、どのような方針で設計しているのかさっぱりわかりませんでした。
「わかんなかったら聞けよ」という声が聞こえてきますが、先輩が知っているのは細い機能だけ。後になって分かったことですが、難しい部分（設計レベルから）は外部会社に丸投げしており、プロパ社員にはノウハウがないようでした。
じゃあ、どんな仕事をするのといえば、開発担当の要望に合わせて、DBのチューニングだの、パロメータの変更だの仕事が押し付けられて、言ってしまえば雑用係です。
「そのくらい自分でやれよ」と言いたいところですが、「重要な基幹システムを扱っているので、それを操作するの人を制限するため」が理由のようです。当時は、重要な役割を任されている反面、マニュアルに沿った単純作業で、スキルが全く身につかないことに焦りを感じておりました。
#仕事への不満と不信
以下に列挙します。感情的なところもありますがご了承ください。
・開発担当からの情報連携がない
ないと言ったら「文字通り」ないです。定例確認で初めて新しい機能が追加されたことを初めて知ることは当たり前。お客様からクレームが入って、新規リリースがあったことを初めて知ることもよくあります。
これではまともな仕事になりません。
またまた、「わかんなかったら聞けよ」が聞こえてきますが、密室でどのような談合がなされているかをどのように聞けばいいのでしょう。「ここにいない人手を挙げて」というくらいナンセンスな話だと思っています。
そもそも、聞けばちゃんと説明するのでしょうか。自分だけが知っていればいいみたいな感じで話を進め、「お前には関係ない」みたいなことを言いながら、もったいぶって説明しない人には、聞くほどの信用がありません。
上部から「運用に文句を言われないように開発進捗を隠せ」と指示が出ていたことを、後になって知りました。
・マニュアルが整備されていない
運用はマニュアルに沿って定例作業を行う仕事です。しかし、世の中マニュアル通りにいかないことは小学生でも知っています。
私が思うにマニュアルは武器です。時間がたてばさび付いて使い物にならなくなります。
そういった原因は、開発によるシステム変更ですが、それが連携されません。（というか、どのようなマニュアルが存在しているか把握していないです。）
運用はどのような開発をしているか把握していないため、すれ違いが起こります。では、運用はどのように運用するのかというと、つまるところは「勘」です。なんて恐ろしい。
#では、どうしたらいいか
どうにもならないと感じました。運用にいる限り。
運用効率化という話もありますが、それは、原則、運用設計によるもので開発によって行われるべきものです。結局、開発が取りこぼした仕事をのしりぬぐいしているだけす。細かい改善のみで、枠を超えれば「出る杭は打たれます」。
偉くなれば、運用設計に口出しすることもできるかもですが、私には無理でした。
#異動しよう
チャンスが訪れたのは3年目。画面開発、つまり、私を使っている側の担当で助っ人に呼ばれることがありました。
この担当、Qiitaでは笑われてしまうような、Excelぺたぺた、CVSでリポジトリ管理しているところでしたが、それでも、今までの仕事に比べよほど専門的な仕事をしているように感じました。
その流れで、社内バッチ処理システムの開発に配属され、晴れて運用からおさらばすることができました。不満がないわけではないですが、運用は「不条理な」苦労が多かった。。
#開発としての運用への向き合い方
配属ガチャによりますが、運用になるべきでなかった。もちろん向き不向きがありますが、最新技術を学びたい人には向きません。
私は運用はエンジニアではなくむしろユーザの一部だと思っています。運用はシステムを「使う」人であり、「作る」人ではありません。その意味ではエンジニアでないです。
その意味で、原則、上流工程から運用要件を要件定義に組み込み、機能として運用設計を行うべきだと思っております。
一方で、現実には開発で実装しきれないこともあり、それを運用が人力で解決していることも理解しております。
なんとも結論しにくいですが、開発としては、状況を説明をするといった最低限の礼儀は守りたいところです。それもせずに、「運用もエンジニアの仲間」といったような、甘えた仲間意識は殺意がわくのでやめましょう。
運用が下流工程であることは事実なので、手取り足取りが必要です。知らないことは知らないことを知ってください。とにかく情報がないです。
臨機応変に対応することは当たり前ではないです。なぜならそれは、根本的には、開発担当の不備だからです。それを対応してくれた運用担当を加点評価してください。
お互い責任感を持って仕事をしたいものですね。運用の人を見かけたら、「今日もご苦労様」といった心持でお願いします。
#結局、何がわかったのか
運用設計は開発の一部なので、開発が責任を持ちましょうということ