システム開発の仕事をしています。いわゆるIT系です。
新卒でこの仕事をし始めてはや15年。
わたくしは悪名高い客先常駐タイプの働き方をさせられていて、とある案件が終わればまた新しい現場に行ってその案件に携わり……といった、スキルが蓄積されない使い捨てのような仕事をしています。そろそろもう別の仕事がしたい。
いくつかの現場を切り抜けてきましたが、IT系なのにワリとどの現場も驚くほどアナログです。
- メールを送ってもメールを送ったことを電話しないと気づいてくれない
- そもそもプロジェクト内のコミュニケーション手段が電話とメール
- 会議室にネットワークがないので会議資料は印刷する
- そのくせペーパーレス奨励
- インターネットにつなげられない
- インターネットにつなげられてもクラウドにファイルを配置してはいけない
- そのくせAWS(Amazon Web Service)でシステム構築するのが主流
だんだんアナログというか矛盾の指摘になってきていますが、まあとにかくシステム開発業界はIT革命前夜です。
すでにリリース済みシステムの本番環境に対して変更を加える際、責任を分散させるために顧客の承認が必要となります。
承認を得るためには、開発担当者がシステムに変更を加える目的や理由などを電子書類に記載し、ワークフローを発行します。通例、上長や顧客が内容を確認し承認のうえシステム運営部が本番環境へのログインIDやパスワードを発行する段取りとなります。
大規模システムだったり金融系のシステムであれば、この流れは一般的かと思います。というか、顧客承認を得ないで本番環境に変更を加えることができるシステムをわたくしは知りません。
ところが、とある大規模システムでは、本番環境に対して変更を加える際に、以下の活動が必要でした。あえて「活動」と書きます。
- システム変更の概要をワークフローに記入・発行する(当然ながらセル結合済みのEXCEL方眼紙)
- ワークフローを印刷してエレベーターに乗りフロアを移動する
- 変更内容を対面で顧客に説明し押印いただく
- あと、ついでみたいな感じでワークフロー上でも承認いただく
- 押印済みの書面を持ってエレベーターに乗りフロアを移動する
- サーバー室で押印済みの書面をシステム運営部に提出し本番環境へのログインIDを発行いただく
- あと、ついでみたいな感じでワークフロー上でも完了済みにしてもらう
- システム変更作業を開始する
ワークフローを印刷した紙を持ってエレベーターで移動しているとき「なんなのこれ……」と毎回思いましたが、ワークフローが顧客やシステム運営部の承認待ちになることを防ぐことを目的としているそうです。
まあとにかくシステム開発業界はIT革命前夜です。
「明けない夜はない」と言いますが、15年くらいずっと夜が続いているんですよね。
