若手と一緒にやっているプロジェクトの要求定義。
４月末で終了する予定が、今日、延期することでユーザー部門とあっさり合意となりました。
延期の理由は、若手が兼任している別プロジェクトが炎上してきて、しばらくそちらに注力するため。
限られたリソースの中で、優先順位をつけて進めていく中での延期の判断ですが、ちょっとあっさりし過ぎ。
別プロジェクトが炎上していると言っても、残業ゼロで対応できているレベル。
要求定義が延びるということは、当然、システム対応後の効果を得られるのも先送りになるわけで、まずは最初に決めたスケジュールを守るために努力をするべきなのではと思うのですが、残業しないということがスケジュール遵守よりも優先されています。
大企業は、どこもこんな雰囲気なのでしょうか？
やってダメならスケジュール延ばすような雰囲気で若手を育てて、この先が心配です。
花粉症デビューしたのは、忘れもしない2001年3月でした。
ECサイトの再構築プロジェクトが炎上していて、本番直前まで不眠不休でバグ潰しをしていたせいで、2月の休みはたったの2日。それ以外の日は毎日9時頃に出社して、会社を出るのは深夜1時頃の繰り返し。
今の時代だったら、完全にアウトな働き方でした。
それでも頑張った甲斐があって、なんとか3月に無事に本番稼働を迎えることができました。
たっぷり休みが溜まっていたので、自然に癒してもらおうと思い、連休をとって岐阜へ。
到着すると、目で見えるくらいのスギ花粉。本当にところどころ黄色くなっているくらい花粉がいっぱい。そして目が痒くなり、鼻水が清流のように下に流れ出しました。
それ以来、毎年、岐阜を逆恨みしています。
古臭いうちの会社も、ついにフリーアドレスになりました。
そのため、自席の荷物を片付けるために出社。
入社してまだ２年も経っていないので、荷物はほとんどないので楽でしたが、いまいちフリーアドレスになった感じがしません。
何故なら・・・
フリーアドレスにした理由が、人が増えて席が足りなくなったから。つまり他の部署はフリーアドレスではなく、システム部門のあるフロアーの２島だけがフリーアドレスです。
しかも、自主フリーアドレスなので、机は引き出し付きのままで、その引き出しは自分のものを入れられないので空の状態。つまり無駄に席が狭い。
さらに極め付けは、フリーアドレスには必須の自分用のポスト兼ロッカーがない！
郵便物は一つの席を郵便物席にして、各自、自分の郵便がないかをチェック。紙の配布物をどうやって配布するかは要検討。
準委任契約のベンダーさんが客先で仕事をするときに、空いている席を借りるような、そんなオシャレ感ゼロのフリーアドレスです。
システム運用のサービスレベル管理の説明です。
サービスレベル管理は、SLAを管理するプロセスです。
サービス品質を維持するための活動のことを指すこともあれば、SLAの立案や合意も含めることもあります。
SLAを守るためには、モニタリングの仕組みなどが必要となり、その仕組みの導入は開発プロジェクトの中で行われるので、システム運用としてはSLAの立案や合意を含めない方が自然かなと思います。
１．SLAとは
そもそもSLAとは何でしょうか？
SLAは、Service Level Agreementの略で、提供するITサービスの可用性や性能などの品質について保証する項目と水準を定めたものです。
規定される項目は原則として、定量的に計測可能なものとなります。
似たようなもので、SLOがあります。
SLOは、Service Level Objectiveの略で、SLAが保証なのに対して、SLOは目標です。SLAには達成できなかった際のペナルティがあるのに対して、SLOにはペナルティはありません。
SLAで取り決めた内容を達成するために、サービス提供者側が設定する目標で、SLOの目標はSLAで設定したものよりも厳しくなることが一般的です。たとえば月間稼働率がSLAで99.95％を保証するのであれば、SLOでは99.99％を目標にします。
SLOは目標なので、SLAにない項目もSLOで目標とすることも多いです。
クラウドなどのサービス提供型ではなく、受託開発の場合には、SLAを交さず、SLOとして発注者と合意するに留めるプロジェクトが多いです。
２．SLAやSLOで設定する項目
SLAにしてもSLOにしても、定量的に測定できる項目が対象となります。基本的には、非機能要件で合意した項目の中で、定量的に測定できるものがSLAやSLOとなります。
このように、意外とSLAやSLOに設定できる項目って少ないのが分かります。
コンピューターなのに、定量的にその状態を捉えられないのが、システムの難しさです。
３．サービスレベル管理
SLAやSLOで定めた項目を維持するために必要な活動がサービスレベル管理です。
各項目が達成できているかモニタリングし、サービス品質の維持を阻害するインシデントを事前に除去したり、発生時に速やかに対応できるように準備を整える活動です。
評価する指標だけをモニタリングするのではなく、その指標を落とす原因となるものもモニタリングをします。
例えば性能です。
レスポンスを測定するだけでなく、レスポンスを低下させる要因も測定や監視をします。
ユーザー数が増えていないか？大量にリソースを消費する機能がないか？アクセスが急増するようなイベントがないか？
サービスレベル管理のモニタリングの大半は、キャパシティ管理と同じものになります。
【振り返り】
サービスレベル管理の説明は以上で終了となります。次回はキャパシティ管理の説明をしていきたいと思います。
①インシデント管理
②問題管理
③構成管理
④変更管理
⑤リリース管理
⑥サービスデスク
⑦サービスレベル管理
⑧キャパシティ管理
⑨可用性管理
⑩ITサービス財務管理
⑪ITサービス継続性管理
歩くのが遅くなりました。
コロナ禍の在宅勤務で、家に引きこもるようになったのが原因です。
外に出ても自転車に乗ることが多いので、多分、一日の歩数は２００歩くらい。
今まで歩いていて人に抜かされることなんてなかったのに、月に数回の会社への通勤中、ガンガン抜かされ、「ここは大阪か？（失礼）」と感じてしまいます。
そして不思議と感じるのが優越感。
単に身体が衰えて、歩く速度が遅くなっているだけなのに、まるで自分がゆとりのある人間になったように思えてくるのが、不思議なところです。
