社内SEになりました

社内SEは本当に楽なのか?ユーザー系IT企業とSierとの違いは?これからIT企業への就職や転職を考えている人むけに、ユーザー系IT企業から社内SEに40代で転職した筆者がITエンジニアの仕事内容やプロジェクト管理のノウハウ等をご紹介。

システム運用(変更管理)

システム運用の変更管理の説明です。

変更管理の対象は基本的には構成管理の対象と同じですが、構成管理が対象としないものとして「人」の変更があります。PMBOK系のプロジェクト管理で体制の変更が変更管理の対象になるのと似ています。担当者の変更、役割の変更、プロセスや手順の変更などです。人を含めたIT資産の変更をする際、変更管理プロセスが発動します。

変更管理では変更の受付を行い、変更理由、変更方法、リスク、必要なリソース、実施者、他の変更との依存関係などから変更に対しての評価を行い、変更の承認(あるいは却下)を行います。

実際の変更自体は、リリース管理の対象となり、リリース後の評価時に変更管理にフィードバックされます。 

f:id:SystemEngineers:20210102202655p:plain

1.変更管理の目的

変更管理の主な目的は、以下になります。

①変更による障害発生時に備えて変更履歴を残す

②リスク判断やレビューをプロセス化することで変更による障害を最小限に抑える

③過去の変更を蓄積することで類似案件の対応を効率化する

変更管理の目的は、変更そのものを管理することではなく、変更によるシステムへの負の影響をコントロールすることです。

そして重要なことは、変更の承認の判断基準を明確にすることです。

2.構成管理の履歴との違い

変更管理では変更の履歴を残しますが、構成管理も変更の履歴を残します。

これは同じものでしょうか?

一つ一つの要素は同じものですが、管理の軸が異なります。

構成管理の履歴は「資産」の変更履歴です。それに対して変更管理の履歴は「案件」の履歴です。

f:id:SystemEngineers:20210103101523p:plain

例えば、年に1回動く機能で障害が発生したとします。該当機能について変更の有無を構成管理の履歴で調べたところ、半年前にプログラム改修が発生していたことが分かりました。構成管理では通常、同タイミングで変更をした他のプログラムも洗い出すことができますが、同タイミングで実施したサーバー構成の変更や手順書の変更といった種類の異なる資産の変更までは把握できないことが多いです。

そこで変更管理です。同タイミングで変更した全ての資産を管理しているので、改修の全体像を把握することができます。

変更管理を調べた結果、該当の案件ではWebAPサーバーをシングル構成から冗長構成に変えています。その際、WebAPサーバーで起動するバッチプログラムを冗長構成に対応できるように改修していたことが分かりました。

今回、障害が発生した機能は、そのWebAPサーバーで起動するバッチプログラムであることが判明したため、一次対応としては、バッチプログラムを戻し、サーバー構成もシングル構成に戻して再処理するという方法が考えられます。

3.変更管理の実態

変更管理は非常に重要ですが、運用部門の役割が小さく、開発部門が保守を担っているような組織の場合、独立した管理にしていない場合が多いです。

f:id:SystemEngineers:20210103104839p:plain

 

f:id:SystemEngineers:20210103104901p:plain

変更管理を独立させない管理が駄目なのかというと、そんなことはありません。

重要なことは、管理の目的を明確にして、それを達成できるプロセスにすることです。自分たちの身の丈に合わないプロセスにしても、プロセスをまわすことが目的になってしまい形骸化してしまいます。

変更管理の目的である

①変更による障害発生時に備えて変更履歴を残す

②リスク判断やレビューをプロセス化することで変更による障害を最小限に抑える

③過去の変更を蓄積することで類似案件の対応を効率化する

が達成できるのであれば、別の管理と一体になっても何の問題もありません。

【振り返り】

変更管理の説明は以上で終了となります。次回はリリース管理の説明をしていきたいと思います。

①インシデント管理
②問題管理
③構成管理
④変更管理
⑤リリース管理
⑥サービスデスク
⑦サービスレベル管理
⑧キャパシティ管理
⑨可用性管理
⑩ITサービス財務管理
⑪ITサービス継続性管理

NDA難航

NDA(秘密保持契約)に難航しています。

かれこれ2ヶ月くらい、自社の法務と先方の法務との間で伝書鳩になってます。

NDAって、そんなに重要なのでしょうか?

前職でも前々職でもNDAはさらっと締結していたので、こんなにNDAで難航したのは、はじめてです。

今回は特殊といえば特殊で、前任者がNDAせずに契約しちゃったので、尻拭いで事後でNDAの手続きをしているのですが、事後での締結用にカスタマイズしたNDAの条文について、なかなか双方の法務が納得しません。

直接、法務同士で話しをしてくれればいいのですが、2ヶ月も延々と間に入ってやり取りしていると、もうNDAいらないんじゃないか?と思えてきます。

たいした作業を委託しているわけでないし、お互い大企業同士だし、しかも秘密保持のの期間が1年だし・・・NDAが何らかの抑止力になるとは、とても思えません。

今週のお題「大人になったなと感じるとき」

はてなブログ今週のお題「大人になったなと感じるとき」

子供の頃は、大人というものが頑然と存在して、自分もいつかそうなると信じていました。

でも大人になったと思われる年齢になってみると、果たして自分は大人になったのか?と自信がありません。

自分の中の大人のイメージは、「バーカウンターで一人で飲む」です。

バーはもちろん、居酒屋でも定食屋でも一人で飲めず、しかもウイスキーやブランデーが苦手な自分は、もしかしたら大人でないのかも。

そもそも一人で飲んでいる人って、何を考えて飲んでいるのでしょうか。

たぶん私は大人になる前に、いきなり年寄りになってしまうんだろうなと思うと、ちょっと寂しいです。

f:id:SystemEngineers:20210109164759j:plain

再びの緊急事態宣言

1都3県に緊急事態宣言が発出され、再び引き蘢り生活に。

私はもともと引き蘢っていたのですが、周りも引き蘢りはじめ、予定していた物流会社の視察なども全てキャンセルになりました。

物流システムの要求定義やっているので、視察できないとスケジュール遅れます・・・

今日、名古屋や大阪の人たちとテレビ会議をやったところ、向こうは首都圏ほど緊迫感がない感じで、普通にオフィスに出勤してました。(個人の問題かもしれません)

コロナが落ち着いたら、物流会社の視察で全国行脚しようねと夢を語り合っていました。

システム運用(構成管理)

システム運用の構成管理の説明です。

構成管理の対象はハードウェアやネットワーク、ソフトウェア、ライセンス、契約情報、業務アプリケーション、設計書など広範囲に渡ります。真面目にやると結構大変です。

1.構成管理の目的

構成管理の主な目的は、以下になります。

①IT資産の可視化

②インシデント発生時に影響範囲を特定するために活用

③ネットワーク構成やシステムなどの変更時に、影響範囲を特定するために活用

④過去の変更履歴の把握

例えば、とあるOSのとあるバージョンで重大なセキュリティーホールが見つかった場合、どのサーバーのどのシステムに影響するのか?といったことを構成管理を行うことで、迅速に把握することができるようになります。

またDISKがクラッシュした場合、影響のあるシステムも迅速に把握することができます。

IPアドレスの重複も発生しなくなります。

ライセンスが切れて、システムが停止してしまい、慌ててライセンス更新するなんてこともなくなります。

構成管理をやると、いいことずくめですが・・・ 

2.構成管理は大変

構成管理の対象は膨大にあります。

構成管理という名称から整った情報の管理をイメージしますが、数も膨大なら種類も膨大、管理する項目もその種類ごとに異なり、一つの項目でも複数の情報があったりするという、実態の管理はかなりドロドロです。

f:id:SystemEngineers:20201231132113p:plain

構成管理とIT資産管理を分ける考え方もあります。

構成管理はあくまでも「構成」を管理し、シリアル番号などの「個々の機器」の管理はIT資産管理という考えです。

どちらの考えでも、管理することには変わりないので、重要なことは管理の目的です。

どんな目的で管理するのかが決まれば、自ずと管理する対象と管理方法が決まります。

3.構成管理の実態

構成管理は、きちんと管理していると非常に便利ですが、管理そのものに大変な負荷がかかります。管理する情報が多ければ、最新状態に保つために様々な変更プロセスを一元化する必要があるからです。

例えば、あるシステムに接続されているクライアントの情報が知りたいケースがあったとします。

PC接続だけかモバイル端末の接続があるのか、PCやモバイル端末のOSやブラウザーのバージョン、PCやモバイル端末の画面解像度、PCやモバイル端末の機種、PCやモバイル端末にインストールされているソフトウェア、接続するネットワーク、BYODの有無。いろいろな情報があります。

細かく管理すればするほど、PC1台購入した場合の構成管理への登録作業が膨大になっていきます。

そのためシステム一覧やサーバー一覧はあるけど、どのサーバーでどのシステムが稼働しているのか分からない、クライアント端末一覧はあるけど、個々のクライアント端末でどのシステムが利用されているのか分からない、といった状態が多いのが実態です。

4.悲しい先祖返り

構成管理とは別管理と考えられることが多いですが、開発部門での構成管理といえばソースコードや設計書のバージョン管理です。

そしてバージョン管理につきものなのがデグレードの一種である先祖返りです。

開発に携わる人であれば、誰でも一度は経験したことがあるのではないでしょうか。

本番日の異なる改修を並行して実施した場合に起きがちに思えますが、実際に多いのは一つの改修(一つのプロジェクト)での先祖返りです。

テスト中にバグが見つかって修正をしたはずが先祖返りしてしまった、設計書を修正したはずが先祖返りしてしまった、といったケースです。

過密なスケジュールの中で、複数人で同一ソースや設計書を修正した場合に、一番発生しやすいです。

そして一番悲しいのは運用保守フェーズに入って、ある改修をした後、バージョン管理ツールにチェックインが漏れていて、次の改修で先祖返りしてしまうケースです。

チェックインを忘れてしまった、チェックインがされているかのチェックが漏れていた(実際には形骸化していた)という非常に人間的な誰でも起こりうるミスは、実は対策の打ちようがありません。

高いツールを導入して、立派なプロセスを作っても、それを運用するのが生身の人間なので、必ずミスは発生します。それが発生しないのは、メンバー一人ひとりのモチベーションが高いからです。

管理者はリリースの度に、先祖返りが起きないことの奇跡に感謝をしています。

構成管理で一番重要なことは、プロセスやツールよりも、常に最新状態に保とうというメンバー一人ひとりのモチベーションです。

そのモチベーションが萎えるような膨大な情報の管理は、百害あって一利無し。身の丈にあった管理をすることが重要です。

【振り返り】

構成管理の説明は以上で終了となります。次回は変更管理の説明をしていきたいと思います。

①インシデント管理
②問題管理
③構成管理
④変更管理
⑤リリース管理
⑥サービスデスク
⑦サービスレベル管理
⑧キャパシティ管理
⑨可用性管理
⑩ITサービス財務管理
⑪ITサービス継続性管理 

仕事始め

どこにも出かけなかったせいか、あっという間に年末年始の休みが終わりました。

そして仕事納めの日に続いて、仕事始めの今日も打合せ何も無し。

12/29(火)の仕事納めから1週間、誰とも喋ってません・・・

仕事と休憩が捗ります。

もう一生、誰とも話しをしないで仕事したいです。

 

仕事納め

今日で仕事納めです。

小売の会社なので、元日以外は会社としての休みは無く、各自有給を使って休みを取っています。

本社の人は結構、長い休みを取る人が多く、システム部門も12/26(土)から1/3(日)まで9連休の人も半分くらいいます。

私は入社したばかりで有給が少ないので、今日まで働いていますが、コロナ禍の中、みんな9連休とって何してるんだろうと不思議に思います。

そんな感じで今日は人が少ないので打合せもなく、メールも来なくて、自分の仕事が捗りました。

来年も在宅勤務が続きますように。