2017年05月28日

会社で言いたいことあるなら言った方がいいよ

会社で不満を抱えてストレス溜めてるってアホらしくない?

不満でイライラしながら仕事しても集中出来ないし、せっかくの華金は飲み屋で愚痴大会を開催して、何も生産してないよね。

だったら言いたいこと言った方が良いよ。死なんから。
言えない会社なら辞めたら?そんな会社風通し悪くて先無いよ。

言いたいこと言った方が良い理由は、まずはあなたの精神衛生を守るためね。

イライラは本当に良くないよ。シワ増えるし、酒タバコの量増えるし。寝付きも悪くなる。
寝不足は健康を害する諸悪の根源やで。

そしてもちろん状況改善のためね。
あなたが言うことによって、みんながうすうす気づいてるけど表に出てない問題とか、そもそも誰も気づいていなかった問題とかが明らかになる。

ただし言うときは、必ず今の状況を整理して、対応策を用意しておくこと。

理由は、そうしないとただの文句、愚痴になるだけ。
あいつ文句言ってるだけやん、と評価されてしまうよ。

今の状況はこう、理想はこう、そのギャップを埋めるためにはこうしたら良い、という流れね。

あなたが正社員なら最強やで。言いたいこと言ってクビになることないから。

まあ正社員じゃなくても、言ってることが正当なら干されること無いやろ。

言いたいこと言って伸び伸び生きていこう。
タグ:生き方
posted by Yamato Sakai at 07:00 | Comment(0) | TrackBack(0) | 仕事のこと | このブログの読者になる | 更新情報をチェックする
2017年05月25日

システム運用設計について(2-4) 運用管理アーキテクチャ 変更管理、ライブラリ管理、リリース管理

前回記事(システム運用設計について(2-3) システム運用アーキテクチャ 問題管理、構成管理)に引き続き、システム運用設計アーキテクチャのうち、変更管理、リリース管理、ライブラリ管理について記述していくことにする。

it_operational_architecture.png

お馴染みの上図で言うところの「5.変更管理」「7.ライブラリ管理」「8.リリース管理」に当たる部分である。

この3つの運用管理業務であるが、上図では赤い点線で囲っている。
なぜかというと、これらは密接に絡んでいるというか、リリース管理とライブラリ管理は変更管理の一部であるとも言えるからだ。

では順を追って説明して行こう。

変更管理とは

変更管理とは、運用しているシステムに対する全ての変更要求について、その妥当性を検証した上で変更実施を管理するとともに、変更内容を構成管理へ反映する、というのが一連の業務である。

システムに対する変更要求とは、主に
  • 障害管理から問題管理へエスカレーションされた事象で、問題の恒久的解決のためにシステムの変更を要求するもの
  • セキュリティインシデント発生を恒久的に予防するために、システムに対して変更を要求するもの
  • ビジネス上の要件により、システムに対して変更を要求するもの
これら3つを起因とするものがある。

これらを起因としたシステムへの変更要求を受け付けたあと、その変更要求が妥当なのかどうかを費用やスケジュール、システムへの影響やビジネスへの影響などを含めて検証する。
一般的には変更管理委員会のような組織体や会議体を編成して、関係者間において協議をすることが多い。

そしてシステムに対する変更が問題無いと判断されれば、変更を実施する。

変更の実施はシステムのインフラであったり、アプリケーションプログラムであったり、これらの変更に伴う設計書などのドキュメントも含まれる。
変更の実施作業そのものについては、次項の「リリース管理」において行うことが一般的である。

変更が実施されたらその内容を構成管理へ送り、最新情報を提供して変更管理業務は完了である。

リリース管理とは

リリース管理とは、変更管理においてシステムに対する変更が承認された場合において、実際の変更作業を管理する業務である。

システムの変更作業実施において、その準備が周到に行われているかどうかの確認をするために、リリース判定会議といった会議体を編成し、妥当性を協議することが一般的である。

このリリース判定会議において、
  • システム変更の理由
  • システムに対する影響
  • ビジネスに対する影響
  • ユーザーへの告知
  • 変更実施作業の詳細内容やスケジュール
  • リリース資材に不足がないか
  • 変更作業失敗時のリカバリー作業内容の妥当性
といった項目を確認し、安全かつ正確なシステムに対する変更をはかる。

なおシステムインフラの変更やアプリケーションプログラムの変更が伴う場合は、リリース判定会議までにシステムテストまで行っておくことが必要である。

またこれらの変更によりアプリケーションプログラムや仕様書等の修正が必要な場合は、次項で解説するライブラリ管理により最新版の資材払い出しを受ける。

そしてシステム変更のためのリリース準備が整ったところで、リリース作業を行う。

ライブラリ管理とは

ライブラリ管理とは、システムに関するドキュメントやアプリケーションプログラムのソース等について、最新版のファイル群と変更履歴(過去版のファイル群)を管理する業務である。

一般的には版管理が行えるツールを用いて、過去から現在の最新版に至る全てのバージョンのファイルを保持しておく。

過去分のファイルを保持する理由としては、例えばシステム変更によりリリースした最新版のアプリケーションプログラムに、万が一バグがあり元に戻さなければならない場合に、過去バージョンのソースを取得して再配置出来るようにするためである。

また、過去の変更箇所を誰がいつ行ったのかの履歴を保持しておくことにより、システム監査が入った際にすぐさま情報提供できるようにしておく、という目的もある。

そしてシステムに対する変更要求があった際に、最新版のソースやドキュメントを間違いなく払い出すことにより、デグレードを防ぐという目的も当然ある。

何よりシステムのドキュメントやソースは重要な資産であるため、ライブラリ管理しているデータを適切にバックアップする必要があることは言うまでもない。


システム運用設計関連の記事一覧はこちらからどうぞ。
posted by Yamato Sakai at 07:00 | Comment(0) | TrackBack(0) | 仕事のこと | このブログの読者になる | 更新情報をチェックする
2017年05月23日

ITフリーランスが上位商流の常駐案件に参画するヒント2つ

私は現在フリーランスでIT関連の仕事を客先常駐でしている。
理由はとにかく効率的に金を稼いで、将来のためのタネ銭を作るためだ。
それまでの期間限定である。

まあフリーランスなのでどんな仕事をしてもいいのだが、今のところ自力で商品を作る財力も足りないし、個人で出来ることもしれている。
だから技術さえ持っていれば金が稼げる常駐仕事を敢えてしているのだ。

一応客先常駐にもポリシーを持っていて、事業会社に直接常駐出来る案件か、プライムベンダー(元請け)に直接常駐出来る案件に限っている。

IT業界は多段階下請け構造で、大規模な案件になると下請けや孫請け業者に発注して製造させるのが今も一般的だ。
下請けだとシステムの企画や進捗のコントロールが出来ないし、なによりピンはねにより単価が下がってしまう。

従ってより高単価で契約できる事業会社か、もしくはプライムベンダーのみの案件を紹介してくれる業者と契約をしている。

で、こういった業者は結構な数があるのだが、色々契約やら登録やらしてみて分かったことがある。
それは本当に事業会社やプライムベンダーとの取引が多く、たくさんに案件を紹介してくれる業者と、登録したにも関わらずほとんど案件の紹介がない業者があることだ。

具体的な業者名は出さないが、上位商流の常駐案件に参画するためのヒントと、案件の紹介がない業者の見分け方についていくつかヒントがあるので紹介しよう。

1.案件紹介業者は大手に限る

フリーランスへの案件紹介業者は多くあるが、大手の業者だとまあ間違いないだろう。

上場している業者だと、大手事業会社やプライムベンダーと直接取引をしていることが多いため、上位商流で仕事が出来る。

募集している仕事も上流行程がほとんどで、コンサルをはじめとしてPM、PMOといったプロジェクトの管理・推進の仕事が多く単価も高い。

またプロジェクトの立ち上げフェーズから参画することも多いため、比較的企画的な要素が求められることが多い。

個人で仕事をしているとなかなか大規模案件の企画段階から入ることは難しいが、大手の案件紹介業者を経由すると個人ではなかなか受注が難しい案件にも参画出来るのだ。

2.サイトに案件情報がない、または更新がない業者は要注意

ほぼ全ての案件紹介業者は自社サイトを持っている。
で、サイトに現在募集中の案件情報なんかを掲載している。

ここで注意したいのが、募集中の案件情報が更新されていなかったり、そもそも案件情報がない業者だ。
業者の中には、登録したにも関わらずその後1件も案件の紹介がない所があるのだ。

登録するときに氏名や住所、持っているスキルといった個人情報を渡すのだが、個人情報を集めることだけが目的なのか、と疑ってしまう業者が時々ある。

このような業者に共通する特徴として、サイトに案件情報が掲載されていなかったり、サイトの案件情報が更新されていないことが多いのだ。

案件の紹介がほとんど無いことについては、本当にマッチする案件が1件もない可能性も無きにしもあらずだが、そもそも持っている案件や取引の数が少なすぎて話にならない、ということだろう。


以上がフリーランスで上位商流の常駐案件に参画するヒントである。
posted by Yamato Sakai at 07:00 | Comment(0) | TrackBack(0) | 仕事のこと | このブログの読者になる | 更新情報をチェックする
2017年05月08日

スマホだけで仕事をするための3ツール紹介

私はパソコンを持っていない。
しかしビジネス上の知り合いと連絡を取ったり、資料を作ったり、ブログを書いたりと、デジタル的にやらないといけない仕事がある。

で、仕方がないのでスマホで全部できるのか試してみた。
結果、パソコンでやっていた作業はほぼ全て、まあ何とかできるか、ということが分かった。

ちなみに、使っているスマホはXperia Z3 Compact(Android)である。
小さくて手になじみやすく、非常に気に入っている。
しかし画面が小さいので、細かい文書を扱うときは横に向けたり拡大したりしないといけないのが難点である。

ではパソコンでやっていた仕事をスマホでやる場合に、私が使っているものを紹介する。


1.文字入力


LINEをやったり、短文のメールを書いたりする分にはフリック入力で十分なのだが、長い文章を書く場合は親指がしんどい。
やはりキーボードで入力するのが一番、ということでBluetoothキーボードを使っている。


カバンに入れてもかさばらないサイズである。入力時のキーストロークもまあまあ快適だ。
充電するのがウザいので、単4電池で稼働するものをチョイスした。


2.WordとかExcelとかのOffice文書


出来ればプレーンテキストでやりとりしたいのだが、ビジネス文書はWordやExcelで作ったものがやはり多い。
仕方がないので、Android版のOfficeアプリ(WordとExcel)をインストールして使っている。
Windows版は有償なのだが、Android版は無償で使える。


Microsoft謹製のOneDrive(クラウドストレージ)との相性も良く、クラウドの文書を直接編集できる。
ただし、Android版のOfficeはアプリサイズが比較的大きい。
単品で50MB以上あるため、スマホ本体のストレージが結構圧迫される。

Android版のOfficeアプリが出る前に使っていたOfficeSuiteは、Word、Excel、PowerPoint互換アプリがセットでだいたい30MBくらいである。
従って、Android版のWord、Excel、PowerPoint全部入れると、200MB近くストレージ容量を食うことになる。


使い心地なのだが、パソコン版に比べると圧倒的に使いにくい。
なにせ画面が小さいため、リボンを表示させると文書領域というかメイン部分が半分以上見えなくなる。
文書の編集に使うには、非常にストレスフルである。
従って、文書の編集はパソコンかタブレットを使う方が作業効率が圧倒的に高い。

画面が小さいことによる編集のしにくさは、OfficeSuiteでも同様である。


3.印刷


データでやりとりすることがほとんどなので、紙に印刷することがほとんどない。だからプリンターは処分した。
それでも、たまに印刷しなければならない局面がある。

近くにコンビニがあれば、コンビニプリントというサービスを使うことができる。
これが結構便利なのだ。


box(クラウドストレージ)アプリをインストールして使用する。

印刷したい文書をboxの印刷用フォルダへアップロードする。
すると間もなくユーザー番号という文字列が記載されたメールが届く。
コンビニへ行き、マルチプリンター機にユーザー番号を入力すると印刷できる。

モノクロだと1枚20円、カラーだと確か1枚60円だったと思う。
ほとんど使わないプリンターのインクトナー代を比較すると、必要な時に必要な枚数分の料金で印刷できるので、非常にコスパが高い。


以上が、私がスマホで仕事をするときに使っているツールだ。
タグ:便利情報
posted by Yamato Sakai at 07:00 | Comment(0) | TrackBack(0) | 仕事のこと | このブログの読者になる | 更新情報をチェックする
2017年04月20日

システム運用設計について(2-3) システム運用アーキテクチャ 問題管理、構成管理

さて、前回(システム運用設計について(2-2) システム運用アーキテクチャ インシデント管理・障害管理・セキュリティ管理)に引き続き、今回は下図の赤枠のうち、「4.問題管理」と「6.構成管理」について記述することにする。

it_operational_architecture.png

「5.変更管理」、「7.ライブラリ管理」、「8.リリース管理」について、これら3つの管理業務は密接に絡んでいるため、次回以降にまとめて記述する。

では、順を追って記述する。


4.問題管理

問題管理は、システムを運用するにあたり発生した問題について、恒久的な解決をするための業務である。

システムを運用するにあたり発生する問題とは、障害管理からエスカレーションされてきたものと、業務上の要件から発生するものや、システム運用上発生するものがある。

そして、問題の解決については、すでに発生した問題を事後的に解決するリアクティブ対応と、将来発生する可能性のある問題を事前に解決するプロアクティブ対応がある。

リアクティブ対応の例を挙げる。
例えば、障害が発生し、迅速な回復のために暫定的な対応を行ったとする。

しかし、そのまま放置すれば同じ障害が発生する恐れがある場合は、恒久的な対応を行い同じ障害が発生する恐れを取り除く、というものだ。

プロアクティブ対応の例を挙げる。
例えば、業務で使用しているサーバーの動作が遅くなったとしよう。遅くても正常に使えているのであれば、障害ではない。

しかし、これ以上遅くならないように、何らか障害が発生するまえにサーバーのスケールアップをする等の対応を行う、というものだ。


6.構成管理

構成管理とは、現在運用されているシステムの構成を管理する業務である。

例えば
・サーバーのハードウェア構成
・サーバーOS・ミドルウェアのバージョンやパラメーター
・ネットワーク機器の設定内容
・アプリケーションのバージョン
・クライアントOSのバージョンやパラメーター
など、運用しているシステムの現在の構成がどのようになっているかの情報を、一元的に管理するのである。

そして、運用しているシステムの構成が変更された場合は、直ちに情報を最新に書き換えて管理していく。

なぜ構成管理をする必要があるのだろうか。
例えば、サーバーOSのセキュリティパッチがリリースされたとしよう。

セキュリティパッチは、適用しない場合のリスクが重大な場合、迅速な適用が望まれる。

運用しているサーバーが、セキュリティパッチの適用対象かどうか、現在の構成を適切に管理していない場合は迅速な判断ができない。

従って、システムを安全に運用するためにも、適切な構成管理をする必要があるのだ。


では、次回以降で「5.変更管理」、「7.ライブラリ管理」、「8.リリース管理」について記述することにする。

システム運用設計関連の記事一覧はこちらからどうぞ。
posted by Yamato Sakai at 07:00 | Comment(0) | TrackBack(0) | 仕事のこと | このブログの読者になる | 更新情報をチェックする
2017年04月17日

システム運用設計について(2-2) システム運用アーキテクチャ インシデント管理・障害管理・セキュリティ管理

今回は、前回で説明したシステム運用設計アーキテクチャのうち、下図赤枠部分について論じて行くこととする。

it_operational_architecture.png


この赤枠部分の各運用業務は、システムのサービスレベルを維持、向上するための業務である。
要するに、日々のシステム運用の安定性を担保し、システムの品質を向上させるために必要な運用業務である。

では今回は、「1.インシデント管理」、「2.障害管理(障害回復)」、「3.セキュリティ管理」について記述する。


1.インシデント管理

まず、インシデントの説明をしよう。
よく、インシデントと障害は同じものと捉えがちだが、両者は異なるものである。

インシデントとは、システムの利用者が期待通りのことが出来ず、困っている状態のことである。
例えば、利用者がパソコンを使っていて、どこかのホームページを見ようとしたが見られない、としよう。
この場合、利用者は期待通りホームページを見られず困っている。
困っているだけなので、まだインシデントの状態であり、障害とはならない。

インシデントの原因を調べた結果、ブラウザに入力したURLが間違えていた場合、利用者に正しいURLを入力するよう依頼すれば、インシデントとして解決だ。

しかし、ルーターが故障していたとか、LANケーブルが切れていた、といった場合、このインシデントを解決するためには、取り除かなければならない問題が発生する。
このように、インシデントを解決するために、何らか取り除かなければならないことがある状態を障害という。

従って、インシデント管理とは、何らか困っている事象について管理をすることである。
そして、困っている状態の原因を調査し、解決するための切り分けを行い、障害と判断された場合に「2.障害管理」へとエスカレーションするための業務なのである。

インシデントは、利用者からの問い合わせやクレームなどにより発覚する場合と、システムに障害監視の仕組みを入れていた場合に上がってくるものがある。
両者とも、インシデントが障害なのかどうかの切り分けを、運用担当者により行う必要がある。
迅速な切り分けのためにも、切り分け表を整備する等の設計も必要である。


2.障害管理(障害回復)

障害管理とは、「1.インシデント管理」において、障害とされた事象についての管理を行う業務である。
管理については、障害そのものの対応状況を管理することと、ステークホルダーへの連絡や周知の管理をすることの両方が含まれる。

まず、障害そのものの対応状況の管理について記述する。
何よりも最優先すべきは、発生した障害によりシステムの稼働が停止または制限されている場合に、障害から回復させることを第一目的とすることである。
従って、運用設計においては、予想がつく障害の回復手順は整備しておく必要がある。

そして障害は、既知の障害と、未知の障害に分類される。
既知の障害とは、障害からの回復手順が判明している障害のことであり、未知の障害とは、回復手順が判明していない障害のことである。

既知の障害が発生した場合は、必要に応じてステークホルダーへの連絡や周知を行い、同時に回復手順により障害の回復を試みる必要がある。

また、未知の障害が発生した場合は、ステークホルダーへの連絡や周知に加え、保守部門への連絡を行い、調査や対応方法の確立の依頼をする。
障害の重大度によっては、緊急対策本部等を設置し、障害対応専門のチームを結成したほうがいい場合もある。
そして、一旦は暫定対応として、障害からの迅速な回復を試みる。
障害からの回復が完了すれば、「4.問題管理」へエスカレーションし、恒久的な対応策の検討、対応手順の確立を行う。

次に、ステークホルダーへの連絡や周知について記述する。
利用者にとって、システムが期待通りに動作しなければ、業務への影響が出てしまう。
従って、障害を検知した場合は、いち早く利用者へ周知する必要がある。

システムによりけりだが、例としては、まずは初報として、障害が発生していることを周知する。
その後、定期的に、障害からの回復状況と回復見込みを周知する。
最終的に障害から回復すれば、終報として回復が完了したことを周知する。
といった、利用者とのコミュニケーションが重要になる。


3.セキュリティ管理

セキュリティ管理とは、システムの安全性を確保するための技術的な対策と、何らかセキュリティインシデントが発生した場合の対応のことである。

まず、システムの安全性を確保するための技術的な対策について記述する。
システムの安全性を脅かす要素としては、外部からの脅威と、内部からの脅威に分けられる。

外部からの脅威とは、ハッカーによる攻撃や、災害などによる物理的な損害を受ける可能性のことである。
従って、攻撃から守るためのハードウェア・ミドルウェア・アプリケーション・ネットワーク各々のレベルでの対策を行う必要がある。
システムの予算やミッションクリティカル度合に応じて、対策を設計する必要がある。

内部からの脅威とは、利用者や保守担当者、運用担当者などのステークホルダーによる不正使用で損害を受ける可能性のことである。
従って、適切な権限管理や利用制限、いつ・誰が・どこから・何をしたか、といったログを残すことが必要である。

次に、セキュリティインシデントが発生した場合の対応について記述する。
セキュリティインシデントとは、外部から、もしくは内部からの脅威が実際に発生した状態である。
例えば、不正アクセスがなされ、システムで保持している情報が漏えいした場合が該当する。

セキュリティインシデントが発生した場合、それがシステムの障害によるものであれば、障害そのものは「2.障害管理」で管理する。
しかし、情報漏えいが発生した、といった場合は、漏えいしたことによる対応(調査や記者会見など)が必要になることがあるため、障害とは分けて専門のチームを設けて対応した方が良いだろう。
システムや運営会社の規模によっては、CSIRT(Computer Security Incident Response Team)の設置や、CISO(Chief Information Security Officer)の設置を検討した方が良い場合もある。


「4.問題管理」以降については、次回以降に記述する。

システム運用設計関連の記事一覧はこちらからどうぞ。
posted by Yamato Sakai at 07:00 | Comment(0) | TrackBack(0) | 仕事のこと | このブログの読者になる | 更新情報をチェックする
2017年03月15日

交渉を有利に進める方法について

交渉力とは。

巷では、相手を丸め込むだとか、説得の方法だとか、色々方法論がある。
まあ交渉の手段としては、あっても良いだろう。
しかし、いくら相手を丸め込もうが、説得を試みようが、相手と合意に至らなければ、交渉は決裂である。

交渉は何のためにするのか。それは自分の利益を最大化するためだ。だから妥協は交渉とは言わない。

では、どうすれば交渉で自分の利益を最大化することが出来るのだろうか。
それは、切り札というか、選択肢をどれだけ多く持っているか、ということと、
仮に交渉が決裂したとしても、自分が困らないかどうか、この二点に限る。

まず、選択肢をどれだけ多く持っているか、だが、多く持っている方が有利である、ということだ。
例えば、取引先を選ぶときに、沢山の業者から合い見積りをした方が、一社だけから見積りを取るよりも選択の幅が広がる。
沢山の見積りから一番有利なのを選んで、ここがダメなら2位、3位と順序付けて選べば良い。

次に、交渉が決裂しても、自分が困らないかどうか、であるが
これは上述した選択肢の多さとも関連する。
今の交渉が決裂しても、他を選べば良い、という状態にすべし、ということだ。

大学受験でも、就職活動でも、取引先選定でも、恋愛相手でも、複数から選べる状態にしておくと、もしダメになったとしても次に行けば良い、という余裕ができる。
そして、余裕があると、冷静に物事を判断できるようになる、ということだ。

最悪なのは、自分の選択肢が一つしかなく、おまけに決裂したら自分が困るという状態だ。
相手に足元を見られ、合意出来なければ自分が困ってしまう場合、不利な条件で合意せざるを得なくなる。

だから、喋りを上手くするとか、説得の会話術を学ぶとか、うわべの努力をするくらいなら、選択肢を複数持つことと、決裂しても自分が困らない状況を作る方が、極めて交渉力が上がり、自分の利益を最大化できる、ということだ。
posted by Yamato Sakai at 07:00 | Comment(0) | TrackBack(0) | 仕事のこと | このブログの読者になる | 更新情報をチェックする
2017年03月03日

破産手続きした後のこと

さて、筆者は会社を潰し、破産手続きをしている。
破産手続きをした後どうなるのか、筆者の経験や感じたことをかいつまんで書こう。

まず、破産手続きが開始され、免責が決定するとどうなるのか。
持っている資産は破産管財人に没収され、債権者に分配される。だからプラスの資産は無くなる。
そしてマイナスの負債も当然無くなる。
ただ、それだけ。

詰まるところ、色々あったのがゼロになった。
リセットされたのだ。人生、経済面についてはリセットできるのだ。

出来ないことは、信用情報に乗っかるような取引だけ。
借金しなければ、充分に生きていける。
クレジットカードも当然使えないが、ほぼ全ての決済でデビットカードが使えるので問題なし。

会社を潰す決断をしてから、とにかく物欲が無くなった。
所有することの無駄さを感じるようになった。
必要なものは必要な時に借りれば良い。
守るものは財布(稼いだ現金)とスマホ(からアクセスするクラウドストレージ)だけ。
持ち物がシンプルになった。

そして、破産手続きしたことは、自分がその事実を伝えた人以外知らない。
官報に掲載されるが、毎日官報を読んでる人が身近にいることはない(と思う)。
隣の人も、友人も、現在の取引先も、言わなければ知るすべがない。
戸籍にも載らないし、住民票にも載らない。
(破産者名簿というのに載ったかも知れないが、見れたとしても役所のごく限られた人だけで、免責決定が下りれば抹消される。)

だからリスタートして、正々堂々と生きていけば良い。
あまりにも身軽すぎて清々しい。

というのが破産手続きから免責決定した後のこと。
全然大したことないでしょ。

もっと詳しい事実については、またの機会に。
タグ:会社経営
posted by Yamato Sakai at 07:00 | Comment(0) | TrackBack(0) | 仕事のこと | このブログの読者になる | 更新情報をチェックする
2017年02月27日

システム運用設計について(2-1) システム運用アーキテクチャ

さて、前回の「システム運用とは」では、システムの運用と保守は明確に異なる業務であるが、しかし密接に関連する業務でもあることを説明した。
今回は運用設計の全貌がどうなっているのか、そのアーキテクチャについて論じることとする。

ところで、運用設計を行うに当たり、必ずといって良いほど「ITIL」というキーワードが出てくる。
「Information Technology Infrastructure Library」の略称である。

これは、ITサービスを適切に管理するために、ITサービスの品質向上やコスト削減をするための成功事例を集めたフレームワークで、イギリスで提唱されたものである。

と、教科書的な説明をすると難しくなるが、詰まるところITサービスの品質向上とは、イコールシステムオーナーのビジネスを品質向上させることと、ビジネス運営のコストを削減することに直結するわけである。
この二つの目的を達成するために、どのようにしてシステム運用設計をすれば良いのか、という設計標準である、ということだ。

しかし、ITILは運用設計の標準ではあるが、必ずしもすべて準拠させる必要はない。運用しようとしているシステムの規模や、ミッションクリティカル度合いに応じて、必要な部分だけ設計をしなければならないのは言うまでもない。
あまりにガチガチに設計してしまうと、設計通りに運用を回すことが出来なくなり、絵に書いた餅になってしまう。

では、まず下図をご覧いただこう。

it_operational_architecture.png

これが、ITILで定義されている、運用設計のアーキテクチャである。

まず、一番上にある、利用者(ユーザー)だが、ITサービスを最終的に受ける立場のことである。
いわゆるエンドユーザーだ。
そして、業務部門(プロバイダー)は、利用者に対してビジネスとしてのサービス提供を行う立場のことである。
それから、点線で囲った部分が、サービス提供者(サプライヤー)で、ITサービスの提供を行う立場のことである。

利用者と業務部門は、コンシューマー向けサービスであった場合は、利用者がコンシューマー、業務部門がビジネス部隊というか、事業部門にあたる。
また、企業内向けシステムであった場合、利用者と業務部門は同じ立場となる。

そして、サービス提供者は、いわゆるシステム部門にあたる。
システム運用設計とは、システム部門が、サービス提供者としてITサービスの品質向上とITコスト削減を達成するための設計ということになる。

では、次回以降で、上図点線部分についての説明を行っていくこととする。

システム運用設計関連の記事一覧はこちらからどうぞ。
posted by Yamato Sakai at 07:00 | Comment(0) | TrackBack(0) | 仕事のこと | このブログの読者になる | 更新情報をチェックする
2017年02月16日

システム運用設計について(1) システム運用とは

前回(システム運用設計について(1) トピック連載目次)では、システム運用設計についてこれから論じるトピックについて述べた。
今回は、「1.システム運用とは」にあたるトピックについて論じることにする。

システムの運用関連の話をする際、よく「運用保守」とか「保守運用」と言われることがある。
まず最初に、明確に定義しておかないことがある。それは、「運用」と「保守」は、それぞれ密接に関連しながらも、全く別の業務であることだ。

では、「運用」とは何であるか。それはあらかじめ決まった手順に則り、日々のシステム運行が安全かつ安定して実施されることを守るために、定型的な作業を行う業務である、ということである。
定型的とは、運用手順書を見てその通りにやれば、誰がやっても同じ結果になる、ということである。
要するに、運用業務とは、その業務を実施する人間の判断が入る余地がない業務のことである。

対して「保守」とは、システムを維持するために、あーだこーだと検証や調査したうえで、どのように対応すべきなのか判断をすることである。
システムに何らか障害が発生した場合や、システムの改善を行う際に調査をしたり仕様変更を検討し、実装方式を確立することが保守業務である。

そして、先ほど論じた、運用と保守が密接に関連しているというのは、例えば保守作業によりシステムへの変更が必要な場合は、検証や調査を行った上で、変更手順を確立してから運用業務へ回す、ということがなされるためである。
したがって、運用も保守も、システムを維持、改善していくために必要な業務であるが、そのための役割は全く異なるのである。

では、運用設計とは何を設計するものなのか。
それは先ほど論じたとおり、誰がやっても同じ結果となるよう、システムの運行に必要なアルゴリズムを設計することに他ならない。
次回以降で、その必要なアルゴリズムとは何なのかを明らかにしていく予定だ。

システム運用設計関連の記事一覧はこちらからどうぞ。
posted by Yamato Sakai at 07:00 | Comment(0) | TrackBack(0) | 仕事のこと | このブログの読者になる | 更新情報をチェックする
※当ブログでは、ご質問、ご相談など、どんなお問い合わせでも受け付けています。 こちらの問い合わせフォームより、お問い合わせ下さい。 お問い合わせに関しては、当ブログ管理者だけが全て読んでおり、情報漏洩等無いよう厳重に管理しております。 -