問題管理の進め方(IVEさんの記事から考える)
どうもこんにちは。
本日は、趣向を変えて…いえ、遅々として進まぬ筆に気分を変えて、いつもの得意ジャンルから一本記事を思いつき書いております。
問題管理がしっかりと回っていれば、インシデントの発生を抑制し、サービスの品質は向上します。
— IT VALUE EXPERTS(IVE) ーITをもっと価値あるものにー (@ITVALUEEXPERTS) 2025年9月10日
一方で、問題管理に割ける工数は限られており、根本原因分析に手が回らない現場が多いのが実情です。
組織の成熟度や方針を踏まえ、問題管理へのアプローチを組織として決めることが大切です。#ITSM
問題管理に避ける時間は限界があり、どうしても進まないということが明記されています。さて、本当にそうでしょうか？さらに言えば、このポストにある「組織の成熟度や方針を踏まえ、問題管理へのアプローチを組織として決めることが大切です。」について、そもそも「アプローチを組織として決める」とは具体的に何なのでしょうか？それを今回深掘っていきたいと思います。
そもそもIT運用の現場って何をしていると思いますか？筆者もちゃんと数えた事ないなと思いこの記事を執筆するにあたって再整理しましたが、大きく分けて８種類ありました。
今回言われているのは、「問題管理」なのですが、この仕事「定期レポート」「変更承認」「調査依頼」「作業依頼(非定型)」の４つに跨って実施されます。この４つを行ったり来たりしながら問題管理をこなしていくという状態です。まぁそれなりに時間は必要ですよね。では、某Go○gle社を始めとした「20%の時間」なり何なりを設けてこの問題管理に注力する時間を作れば良いのでは？と思いますが、これもまた難しい。なぜなら、この８つの仕事のうち特に運用Tに向いている矢印つまり「問合せ」「調査依頼」「障害」「作業依頼(定型)」「作業依頼(非定型)」「アラート」の６つは、運用Tの都合に関係なく降ってきます。80％でこれら６つを処理するとしても世の中には限界がありますし、そもそも我らが日本人は(本来は)労働基準法を遵守せねばなりません。(真顔)
また、今回の思考実験においては、人員は一定確保されている事を前提とします。本来的にはもうちょっと自動化やセルフサービスも検討しなければいけないのですが・・・*1
さて。確かに問題管理の時間を捻出することにハードルはありそうです。では人員は足りていることを前提とした際、それでも問題管理に手が回らないということはありうるのか。
この記事はありうると言っています。「組織の成熟度や方針を踏まえ、問題管理へのアプローチを組織として決めることが大切です」と書いてあるように、組織の成熟度を高め、方針を定めないと問題管理は進まないのです。
なぜ進まないかと言えば、仮に人員が足りていたとしてもタスクの優先度が決まっていなければ(降って)来た順や簡単に終わらせられるものから着手してしまうからです。それを覆すための指標を提供するのが、SLOやSLAであり・・・結局ここに帰結するのですが(笑)、そこを定義する活動を行う組織が不在なのではないかと。
「問題管理が進まない」状態が発生する主たる要因は「運営不在」であるから起きるのではないかと考えます。(人員不足とは、その結果無駄に投入される人員のせいで起きているとすら思います)
筆者は過去何度も「経営」「運営」「運用」の３つの組織が必要であると述べてきています。この成熟度とは「運営」であろうと意思を持ってお伝えします。運営は経営や統治(governance)の方針に基づいて組織を管理 (Management)し、業務を制御(control)する組織です。
いくら運用の現場が優秀でスキルフルだったとしても、組織として管理されていなければ各自が自由に動いてしまい収拾がつかなくなりますし、業務が制御されていなければあっちこっちから依頼が増え、対応策は場当たり的になり変更も制御されず、例えば声の大きいユーザの言葉が優先される可能性もあります。運営がちゃんと機能していること。それにより時間を生み出すことは可能となるのです。
改めて、Xのポストを見てみましょう「組織の成熟度や方針を踏まえ、問題管理へのアプローチを組織として決めることが大切です」
組織の成熟度や方針を踏まえ＝「運営」が組織的に活動を行っているか
これが成り立つと仮定した場合、運営は何をすることが「問題管理へのアプローチを組織として決める」こととなるのでしょうか。
これは「今のコストでどこまでのサービスを行うことを決めるか」だと思います。別の言い方をすれば、「月間の処理可能件数の中でどこに重点を置くか」です。問題管理は４つの仕事を行き来して処理されると言いましたが、障害を起因とした根本対策の策定と実行には、次の図の５つのプラクティスが関与します。
これは、端的に言えば「同じことが原因となって発生する障害が起きないようにする活動」と言い換えて良いです。この５つのプラクティスを駆使し問題管理を実行する。そのためには、先の８つの仕事の分類のうち、何かを諦めるか、自動化するか、自分たち以外にアウトソースするかなどやり方ややる回数を変える必要があり、それぞれどうやって処理していくのかを現有戦力から判断をする、それが「問題管理へのアプローチを組織として決める」のかに通じると考えます。
もう少し例えで説明します。運用Tは、先の8つの仕事の矢印を月間で1,000回実施できると仮定します。
問題管理を１件実行するためには、最低でも42回矢印を実行する必要があり扱う問題が複雑であればあるほどその回数が増えるとします。
この前提が成り立つ場合、仮に比較的簡単な問題管理を５回実行した場合でも月間の総トランザクション数の21%を消費します79％で他の業務を行う必要が出てくる。この場合運営に求められるのは、79％をどこの矢印に振り向けるのかの意思決定です。
この意思決定の羅針盤になるのが「経営」組織と事業側の組織です。要するに今の事業側組織が何を優先しているか。そこを聞き出す。事業をどうしようとしていて、そのためにシステムに何を求めているのかを把握し、運用の動き方を調和させる。
ここも例えましょう。ある顧客組織が営業支援システムを利用していたとします。この顧客組織は事業の拡大を狙い、より多くの営業を採用しようとしているとします。この時、操作方法の問い合わせはめちゃくちゃ増えることが想定できますよね。その時、問題管理を動かす必要はあるでしょうか？答えはNoです。操作方法に関する問い合わせが増えるのであれば、問い合わせ対応にリソースを割いた方がよく、問題管理は一旦脇に置いておくという交渉は自然です。
では逆に。現在システムはよく停止し、ユーザから不満の声が上がっているとします。この状況下でも事業側は営業を増やそうとしているとします。この時、問題管理を動かすべきでしょうか？これは、YesにもNoにもなりうります。ユーザから不満の声が上がっている以上、問題管理を動かし、先に現在発生している問い合わせを削減する方が効果的かもしれません。一方、問題管理を動かさず、現行システムは塩漬けにして新システムの構築の一手に出るという手もありうります。ここは経営組織の判断になります。
つまり、「問題管理のアプローチを組織として決定する」とは、事業側組織の方向性とIT運用組織をどう発展させていくのかという命題を両方理解した上で組織として決定するということなのです。
さて、このポストの再掲です。
問題管理がしっかりと回っていれば、インシデントの発生を抑制し、サービスの品質は向上します。
— IT VALUE EXPERTS(IVE) ーITをもっと価値あるものにー (@ITVALUEEXPERTS) 2025年9月10日
一方で、問題管理に割ける工数は限られており、根本原因分析に手が回らない現場が多いのが実情です。
組織の成熟度や方針を踏まえ、問題管理へのアプローチを組織として決めることが大切です。#ITSM
改めてこのポストを読み砕くと下記の解釈になると考えます。
問題管理を推進するか否かは、「運営」組織が「経営」組織と事業側組織の戦略や戦術を確認しているかどうかを成熟度として定義し、今のコストでどこまでのサービスを行うことを決めるかにかかっているのだ。
*1:自動化やセルフサービスなど、運用チームとユーザはお互いに時間を大切に扱うための手段を講じて、余力を産むのは当然なのですが、今回の検討において、そもそもの絶対数が足りないというのは考慮の外にします。対策が人員を増やせ、しかなくなるので。。
生存報告と予告（IT投資の新たな評価視点、、、ちょっと大袈裟か？）
ご無沙汰しております。今年は何も更新できておらず申し訳ありません。
昨年末
「IT運用管理としてのサービスマネジメント」と「ITを使ったビジネスサービスとしてのサービスマネジメント」の2つある、と言うことです。例えるなら、ビジネスを支えるIT運用管理と、ビジネスそのものとしての役割が求められるITサービスマネジメントの2つに分けられると言う感じでしょうか。このブログは、この2つを混ぜこぜにして書いております。いつかここを言語化して明確に分離し説明できるようになりたいなと思っています。
と書きましたが、これが予想以上に難敵で。。
さらに、今年6月にですが、「ITシステム投資」というものの定義を変える時期に来ているのではないかと思い至りました。
実は、これは昨年末からの宿題の副産物として生まれた考え方でして。
「ビジネスとITは共にある」事を是とした場合にそもそもNPVや費用対効果といった従前の指標でITシステム投資を評価することは限界なのではないか。
また、そもそもとしてシステムという言葉すらも取っ払って「IT投資」と言われるものを評価する事そのものがもはやナンセンスなのではないかと。
そういう考えに至った次第です。
こういった事を踏まえ、もう少し文書を練らせて下さい。
ITIL®4 Practice Manager MSF(Monitor, Support and Fulfil)受験体験記
どうもこんにちは。年明け一発目は勉強体験記。
ITサービスマネジメントという非常にニッチでアレな業界の片隅でいろいろなお仕事をさせて頂いていますが、今回、その中のPractice Manager(以下、PM)の認定要件であるMonitor, Support and Fulfil (以下、MSF)という単元の授業を受けてきました。*1
今回お伝えしたいこととして、大きくは3つ、細かくすると8つになります。
というか、今回カミナリ落ちすぎて感電死状態です。
- ITIL4になって変更された点を知って衝撃。
- 問題管理とインシデント管理の考え方がガラッと変わった
これ、結構面白いです。どういうことかというと、問題管理プラクティス内の“リアクティブな問題管理プロセス”は、インシデント管理プラクティス内の各種活動の実施中に発動されることがある、ということなんです。
ITILv3では、一般的にインシデントとして発生した“サービスの計画外の停止”を可能な限り復旧させ、完了した後に問題管理プロセスに移行してそのインシデントの根本原因を深堀する、というのが当たり前でした。サービスの復旧を何よりも大事にして「原因は何なんだ」は終わった後に実施するという流れでした。
ITIL4においても、v3同様終わってから記録することもあるけれど、もう、広範囲にわたるんなら、さっさと問題としておけよ、というように変わっています。v3のプロセス風に言うと、インシデント管理と問題管理がパラレルで走ることがあるかもしれない、ということなんです。(カミナリ１つ目)
-
- プラクティスと名を変えた理由がやっとわかった
先ほどの話と被るのですが、プラクティスと名を変えた理由もやっと分かりました。
１つ目の話と同様、それぞれのプラクティスがパラレルにもシーケンシャルにも走り、それらを包括的に分類しガイドするのが４つの側面。継続的に改善するための“視点”としてのプリンシパルを７つの原則という形で定義した。
プロセスの場合、インプットがあり、その中で活動(タスク)があり、最終的にはアウトプットがある。そのアウトプットが後続の、すなわちシーケンシャルに走る後続のプロセスのインプットとなり・・・と続くのです。通常は。しかし、この変化の早いご時世、もはやそれは官僚的であるとして、縦横無尽に４つの側面でカテゴライズされた様々な“プラクティス”を駆使して臨むべし、ということで、XX管理プロセスから、XXプラクティスになった、というわけです。なので、今回から“機能”というカテゴリーが消え、サービスデスクすら、機能ではなくプラクティスとなりました。(カミナリ２つ目)
-
- サービスデスクにもプロセスできてた(カミナリ３つ目)
いや、もうこれ衝撃が過ぎました。完全に職人芸の域に等しく、機能として雑に放り込まれていたサービスデスクにプロセスができています。しかも、最近のロケーションフリーや、サービスデスク「機能」としてマルチにサービスを提供するという観点からか、「そもそもお前(電話/メール/アプローチしてきた相手)は、対象者なんだろうな？」を確認するというプロセスができるという面白さ。そしてもちろんこれが「自動化されている」、別の言い方をすれば、人間が会さないタイプのサービスデスク(Web I/F含む)も網羅している。もちろん、サービス要求管理プラクティスも当然パラレルにもシーケンシャルにも走るということの整合性は取れています。
筆者は、ITIL®4 MPT(Managing Professional Transition)経由でITIL® 4の世界に触れたのでここまで理解が及んでいませんでしたが、運用の現場寄りのSpecialistから入るとものすごく分かりやすいですね。
今回学んだ範囲にいわゆるモニタリングおよびイベント管理(旧イベント管理プロセス)がありました。そこも衝撃でした。なぜなら、簡単に言えば、「監視要件定義」「監視基本設計」が入ってるんですよ。これももう衝撃でした(カミナリ４つ目)*2
- 勉強・試験の話
- どのくらいの期間勉強したのかと、その前提
今回のお勉強ですが、講義3日(8h×3d=24h)と自学自習をデイリーで1時間(1h×３d=3h)そして、今回無茶したのですが、講義終了後翌日に受験しなければいけない状態だったので、当日の朝に模擬試験と復習で2時間。合計で29時間授業と勉強を行なっています。なお、この無茶、ITILv3 Expertとしての知識および過去からのITサービスマネジメントの実務経験があるという前提です。正直、ITIL4 Foundationから入った人は、この通りにやるのは無茶だと思います。
-
- 講義の内容
「インシデント管理」「問題管理」「サービスデスク」「モニタリングおよびイベント管理」「サービス要求管理」以上５プラクティスを座学形式で学びます。今回はオープン型*3でしたので、運用管理の経験者からサービス・オーナーに至るまで様々な方がいて非常に刺激を受けました。講義を確実に自分の経験として吸収するためには、必ず自らの経験に基づいた発言を行い、理解が合うか合わないかを講師と戦わせることです。
-
- 試験対策
試験対策としては、自らの経験に基づいた選択は選ばないこと。ITILの試験は毎回そうなのですが、「ITILの考え方に沿った理解をしているか」を必ず問います。したがって、ITILの考え方に沿うならこの選択肢だ、と思う回答を選ぶ必要があります。なので、それぞれの設問の意図を理解する必要があります。
つまり「この問題を出すことでITILの編者は何の理解を問うているのかな？」という感覚でそれぞれの問いに接すること。これが合格の近道です。例えば「インシデント管理プラクティスの目的を理解しているかを確認したいんだろうな」とか「サービスデスク管理プラクティスの成功要因の理解を確かめたいんだろうな」とか、その問いで何の理解を図ろうとしているのかを読み解いて回答すると合格に近づきます。
-
- 試験の状況
試験はITIL4の一般的な試験と同様、多肢選択法の試験です。ITILv3と異なり、傾斜配点はありません。つまり正答を選ばなければ０点。65％以上で合格となります。60問ありますので、39点以上をつければ合格。時間は90分です。
今回、筆者は78%(47正答/60問中)で、試験時間は63分/90分で完了しております。正直、ハイペースのまま試験を受けましたが、結構無茶でした。
- どんな人が受講するべきか
このMSFに関してで言えば、確実にシステム運用の現場の人は受講するべきと思います。システム運用の現場にあって、どのように改善するべきかの抽象的ではあるのですが「多分こういうことをすればいいんだろうな」ということはわかるナレッジになっています。したがって、いわゆる運用管理者（管理職）というより、その運用管理者の命を受けて実際の現場において設計したり改善したりする実務者の方がより適切であると思います。
とはいえ、管理職の方に有用ではないとも言えず。例えばチームメンバーを指導したりどう動いて欲しいかを説明する上で知っていて損はないと思います。
ITIL4の実務的な使い方がわかるSpecialistモジュールになっています。皆様、是非ご検討ください！
24年の締めくくりに生成AIを使ってみて考えたこと(2/2)
今回、ChatGPTを使って振り返ると言うことにチャレンジしましたが、特に今年の後半は、とにかくAIを様々なシーンで使ってました。
AIでたたき台を作ることに成功して以降、やり方もやる事もわかっているんだけど、実行するのは面倒だなぁと思うことはいったんAIにお願いしてみる、ということを続けています。とはいえ、なかなか使っていい素材がなかなか見当たらないんですよね。クライアントのデータは守秘義務などにより使っていいデータが限られますし。
なので、今回2024年の私のブログ記事を食わせてみるということにチャレンジしてみました。結果、正直予想以上に使えるなと思いました。
「AIが仕事を奪う」ということをいう人がいます。実際にそういうこともあると思います。例えば、声優さん。似た音声を構築し実際にしゃべらせるということができた、というニュースを拝見した記憶があります。と思ったらもう商用利用も進んでいて、団体としても色々動いているんですね。失礼しました。
(以下参照した記事)note.com
声優が呼び掛ける「NOMORE無断生成AI」 第1弾の動画と公式サイトを公開 「AIと良い意味で共存していく道を探らなければ」 - ITmedia AI＋
無断でデータを食わせて作る無断生成AIは論外として。
あえて申し上げるならば「AIは仕事を奪わない。奪うのはAIを使う人である」ということを明確に申し上げたいです。これには2つの意味があります。
- その仕事の意義、目的、手順、価値を知っているのは今その仕事を行っているあなたなので、奪うとしたらあなたご自身がAIを使うことであなたのお仕事を奪えるのです。という、AIを使おうよというエール。
- しごく当たり前の事に対する課題提起。別の言い方をすると、先ほどの声優さんの事例でいえば、その仕事をAIが奪うとしたら、AIが声優の仕事を奪うのではなく、AIを使いこなす監督やプロデューサー、ディレクターなんじゃないでしょうか？という問いかけ
特に2は、前提をお伝えしないとなんかハレーションしそうですね(苦笑)。
そもそも「声優」と言う職業が誰に何を提供しているのかと言う「構成要素」として抽象化して考えてみてください。
筆者としては、映画やアニメまたはドキュメンタリーなどにおける「音声による言語の提供と声の演技によって、制作者の意図する演出を確実に視聴者に伝える」という「各声優の持つ統合されたオペランド資源」と捉えることができると考えています。
突然S-D Logicな書き方になったので平易に言い換えると、声優という職業は「監督や原作者の意図を映像作品に声の力を使って視聴者へ伝えるための構成要素」と捉えることが可能です。
今までの映像作品において、声優は「替えのきかない統合されたオペランド資源」であり、監督の立場から見ると一つの映像作品を作るうえでのサービス提供者であるということです。
しかし、AIによって、「替えのきかない統合されたオペランド資源」が模倣することが可能になってしまった。(ただ、あくまで模倣なので、その場における即時即応が求められるような、例えばライブ性のある現場では使えないと思いますが)
監督や原作者に明確なイメージがあり、そこからぶれないという前提があり、AIを使いこなす監督や原作者であれば、自分以外のオペランド資源を活用せずとも、イメージを即時反映することが可能になるわけです。(逆説的に、監督や原作者の想像を超えるものを作れるかといわれるとできないだろうと思います)
なので、今後大勢の「人間」、別の言い方をすると数多くの「統合されたオペランド資源」が必要となるようなものは、いままでよりも高度に視聴者の想像を超えたものを提供することが求められ、逆に自身のイメージの発信や共有という点では、言語化やAIを使いこなす人で完結できる。
なんといいますか、AIを使いこなすことによって、下積みの経験や人生の深みみたいな経験を経ないとできなかったものが一定のクォリティであればできてしまう。この結果、一定のクオリティを愚直にこなして我が物にする経験をせずとも一定以上の成果物ができてしまうと言うことです。
半面、人生の深みを超えたものや人間同士が深く関与し複雑なものを作ろうとすると愚直にこなす経験をした人間がいないと作れない、ということになる。
ちょっとイメージ先行で申し訳ないのですが、いわば足し算と掛け算みたいな感じです。
AIを使い倒した価値＝原作者＋AI1＋AI2＋AI3・・・
人間同士が関与し合う価値＝原作者×監督×作画×音声×声優1×声優2・・・
このイメージです。
手軽な高品質を生産し続けるか、最高品質を狙って愚直に時間を過ごすか、みたいな極端な世界があるんじゃないかなと。どっちがいいのかということを議論したいのではなく、下積みをこなさないことによって何を得て何を失うかということを見極める時代がすぐそこなのではないか？という個人的なジレンマでもあります。
そういうジレンマを抱えつつも、まぁ、使いますけどね、AI。だって便利なんだもの(苦笑)こういうジレンマに悩んだり、新しい考察を深めるための時間を捻出する方が今の私には必要だなと思うので。
さて、今年の振り返りは以上です。
来年は、2つのサービスマネジメントの言語化、差別化、そしてより軽量化されたサービスマネジメントの実装、最後にサービス関係やS-D Logicというレンズを通してこの世のロジックのリストラクチャ（再構築）を目指して歩んでいこうと思います。
では、皆様、よいお年をお迎えください。
24年の締めくくりに生成AIを使ってみて考えたこと(1/2)
どうも、こんにちは。さて2024年の終わりにどんなことを書いてきたんだっけかなぁと今年の記事を振り返りました。
その結果、どうも生成AIとの向き合い方について一つ言語化できたので筆者としての考えを記したいと思います。なお、こっちの生成AIとの向き合い方については、次節で記載します。（この記事だけで3,000時超えているので）
早速、ChatGPT-4oに2024年の記事を読んでもらい要約してもらいました。
----AIの要約-----
このブログはITサービスマネジメントとアジャイル開発の理論を実生活や具体的な実務に応用する方法について詳細に述べています。運用設計の重要性、アジャイル開発のダイエットへの応用、ServiceNOWやITIL4を用いたITサービス管理、およびKPI/SLA/SLOの関係性などが中心テーマです。さらに、関連書籍のレビューや資格試験対策の体験談も豊富で、多岐にわたるトピックをカバーしています。
----AIの要約ここまで-----
いや、そう言う表面舐めた感が満載の言葉じゃないんだよなぁ。。まとめ過ぎ。聞き方間違えたかとそう言うまとめに至った理由を教えてくれと再度質問。
----AIが何を考えてこの要約に至ったのか----
- 運用設計とは何者かというお話（2024-12-21）
- 「運用設計の教科書【改訂新版】」を読んでの感想と推薦。
- ITサービスマネジメントでの運用設計の重要性を強調。
- アジャイル開発をダイエットに応用・分析（2024-12-15, 2024-12-14, 2024-12-08, 2024-12-07, 2024-12-01, 2024-11-30, 2024-11-24, 2024-11-23, 2024-11-17, 2024-11-16）
- ITSM実践編（2024-1年間）
- サービス評価、KPI/SLA/SLOの関係性を考える。
- ITILに基づいたサービスマネジメントの有効な実践方法やステップの解説。
- ITサービス管理関連（2024-10-26, 2024-10-27, 2024-12-01, 2024-12-08, 2024-12-21）
- ITIL4、ITサービスマネジメント、ServiceNOWなどの知識や経験談。
- ITサービスを効果的に管理し評価するための具体的なテクニックを提供。
- 各種読書感想文と試験対策（2024-10-30, 2024-10-31, 2024-11-04, 2024-11-09）
- 気づきや学びを得た書籍の紹介。
- ServiceNOW CSAの試験対策に関する体験記。
----AIからの回答ここまで----
おお、そうそうこう言うこと。なお、ここまで5分です。では、それぞれのテーマごとに振り返ってみましょう。
1.運用設計とは何者かというお話（2024-12-21）
前回おススメした「運用設計の教科書」のご紹介記事ですね。余談ですが、この記事をX(Twitter)で著者の方からご紹介いただき、ブログのアクセス数が通常の90倍(そもそもニッチな領域なので平均して2アクセスほどしかないのですが)に跳ね上がりました。
ただ、筆者としてもこの本を買ったとき(盛夏でした)はちょうどこの「運用設計」に悩んでいて、なかなか関係者と合意が取れない(役割分担が決まらない)中で一筋の光明となりました。
また、それとともに筆者の主領域である「ITサービスマネジメント」が運用における「運用管理」に過ぎないのだということに気が付かされたタイミングでもあります。別の言い方をすると、運用現場において「ITサービスマネジメント」は主要な構成要素の一つであって、中心ではない、と言うことに気が付かされました。その意味でもこの本を本当にお勧めしたいです。運用を俯瞰して眺める経験が足りていなかったのだと気が付かされます。
2.アジャイル開発をダイエットに応用・分析（2024-12-15, 2024-12-14, 2024-12-08, 2024-12-07, 2024-12-01, 2024-11-30, 2024-11-24, 2024-11-23, 2024-11-17, 2024-11-16）
ここは正直振り返りもくそもなく、結構書ききった感があります(笑)
なお、現在は63kgの前半まで落としていますが、まだ安定的に63kgにはなっていません。時々64kgにいたることがあります。
3.ITSM実践編（2024-1年間）
4.ITサービス管理関連（2024-10-26, 2024-10-27, 2024-12-01, 2024-12-08, 2024-12-21）
今年書いてきた中で一つ確信を持って気がついた点があります。それは、ITとビジネスは共にある時代にあって、「IT運用管理としてのサービスマネジメント」と「ITを使ったビジネスサービスとしてのサービスマネジメント」の2つある、と言うことです。例えるなら、ビジネスを支えるIT運用管理と、ビジネスそのものとしての役割が求められるITサービスマネジメントの2つに分けられると言う感じでしょうか。
このブログは、この2つを混ぜこぜにして書いております。いつかここを言語化して明確に分離し説明できるようになりたいなと思っています。*1
ITIL全般に言える話だと思うのですが、「IT運用管理としてのサービスマネジメント」という観点ではITIL4になってから余計理解が難しくなったのではないかと思っています。
これらプラクティスをちゃんと習得しようとしてITIL4の門戸を叩く人はIT運用管理を極めたい人が大半だと思うので「これってIT運用管理に関係ある？」と悩むんじゃないかなと。この概念の言語化、来年のテーマにします。
5.各種読書感想文と試験対策（2024-10-30, 2024-10-31, 2024-11-04, 2024-11-09）
こちらは3と4からさらに派生して生まれるものなので特に意見はないなぁ。
10/31のサービス評価のまとめ記事がなんでこの分類なんだろうと思ったら、桃太郎の話を引用していますね。まぁ、そこを突かれると確かに感想文、、、なのか？(笑)
まとめ方に難はありますが、ちゃんと読んでくれてますね。
11月4日のみんなの銀行の記事は東洋経済の記事の感想文ではありますね。10月30日の記事と11月9日の記事は何も学びを得たということは書いてないと思うんですが。ここは再度自分として何を書いたのかが要深掘りですね。
今年かいたこの大きく分けて5つを整理すると下記のようになります。
ITILを使うために「経営の何を読み解くか」や「運用の現場に対してどう伝えるか・可視化するか」に大きく割いた1年だったんだなーと思いますね。
締めくくりとして何を書いてきたのかをまとめてみました。
右側におそらく今年書いた記事に有用だろうと思っているナレッジや手法、フレームワーク、BOKを筆者の想像で記載しております。
今年の個人的なスマッシュヒットは、サービス管理におけるQCD(Quality、Cost、Deliverable)の定義や、相対評価によるSLAの立て方ですかね。テクニックとしてだいぶ使える発想だと思っています(自画自賛)。
では、次節。今回の振り返りを書くにあたって使ったように今後起こりうる生成AIとの向き合い方に参りましょう。
*1:ITILv3ぐらいからITSMには主に2種類あるんだろうなという気はしていたのですが、ITIL4ではそこを完全に一体化して説明し、かつそれに言及していないです。(理論としては同じこと管理するためそういう整理になっていると思われます。それそのものは当然だと思います。)
運用設計とは何者かというお話（読書感想文）
どうもこんにちわ。本日は、読書感想ぶ・・・いえ、ちょっと違うかな。おすすめ書籍の紹介です。
なお、この本、紙版を買って読んだ後、Kindle版を迷わず購入しました。
ちょっと横道にそれますが、筆者は技術書的なものは可能な限りKindleというか、電子書籍にします。
理由としてはシンプルで、該当ページを探すという手間が省けるからです。例えばKindleの場合、概ね目次をタップするとそのページに一発で飛べますし、その本の作りによっては全ページの一覧を出して目的のページを探すこともできます。小説や新書など頭からじっくり読みたいものは紙がいいのですが、常に持っておきたい（自分の脳みそのリソースの余裕を確保したい）ような情報の場合は、Kindle、電子書籍にしてパッと開く、そんな運用にしています。なので筆者は仕事する場に普通にiPadを持ち込みます。（もちろん許される環境であれば、ですが）
話を戻します。
この本の素晴らしいところは、「運用」という言葉をITに関わる人員が明確に同じ理解に立てるように定義している点です。システム開発やシステム運用の現場では、そもそも「運用」という言葉で指しているものが誰一人として一致していないということが多々あります。
御多分に洩れず、筆者も「運用」というと、サービスマネジメントのことだけを指して説明していることが多かった気がします。
この本においては、運用を3つで成り立っていると定義しています。「(事業の)業務運用」「基盤運用」「運用管理」。この定義は筆者の頭に雷が落ちましたような衝撃でした。この筆者の目線がITの人間ではなく、”システムを使う側”の目線に立っている事もすごい事だと思いました。
よくあるのですが、我々IT屋が言う「業務」は、自分たちがシステムに対して操作し作業することを業務ということが多いです。確かにIT目線であれば我々の行う作業も業務なのですが、本来的に業務とは以下のようなもののはずです(下記図参照)
しかし、この本は、本来の業務、つまり、事業の目的に沿った作業を業務と定義し、それを支える要素として3つあるのだと定義している。そしてそれを「運用設計の範囲」という章でかなりしっかりと説明されている。これは本当に教科書だと思いました。今のご時世、クラウド型サービスとして、PaaSやSaaSになり、こういった定義を明確にせずともシステムを作るだけだったりはできるのですが、作る前にこういったことを明確にしたものって今までなかったように思います。なんというか、我流・・・のままみんなきているような、と。
この本、非常におすすめです。ITにおいてシステム開発や運用の現場に入る方は、一度電子版を購入し、困った時の羅針盤として活用されることをお勧めします。
アジャイル開発をダイエットに応用・分析してみたら、意外と示唆に富んでいた件 -延長戦 その三 Agile式ダイエットを通して得た食事の注意、運動の注意
さて、本当の本当に最後。ここは、筆者がこのAgile式ダイエットを続けてきた中で、食事や運動で気を付けているテクニックをお伝えします。多分、これが一番知りたい人多いかもしれませんが、一つお断りをします。本テクニックは、あくまで、40代の身長169cm男性が、自分の体重や体脂肪を適正に維持するために編み出したものです。性別、年齢、身長、基礎消費カロリー、筋肉量等で効果が同じになるかどうかは保証しかねます。
なんとか年内に間に合ったぞー！
- 食事編
もう身もふたもないんですけど、正直、バランスのいい食事と適度な運動以外に近道はありません。しかし、あえて標語的に書くなら、下記になります。
主菜(肉や魚など)の優先順位は、白身（鮭含む）>鶏胸肉>青魚>鶏肉＞豚肉>牛
魚は鮭が良いです。少し塩分はありますが許容範囲内です。ビタミン類もバランスがいい（ちょっとEが多いかな。問題ない量ですけど）オススメはAmazonで売られている冷凍の切り落とし。
大量にある上に一度計測してみたら大きい物で概ね70g〜80g、小さい物で40g程度になっていて100g程度を食べるにしても使い勝手がいいです。gあたりの単価も安めですし。青魚に比べ脂質が低いのもポイントが高い。
野菜は正直、「いろどり」を考えなくてもいいかなと思いますが、とにかく量を食べまくりましょう、特に葉物野菜ですね。根菜は煮炊きが面倒なので葉物の方がいいかな。足は早いし若干高価というネックはありますが。切るのが面倒だったら、カット野菜を生、またはレンチン。ドレッシングの油が気になるならポン酢。この時期（冬）ですし、鍋物に最後はオートミールなんかいいかもしれませんね。
根菜類は薄切りしてレンチンでもいいですが、出汁パックを使って煮るもありですね。時短＆安全を考えるなら、電気圧力鍋なども利用を考えてください。別のことができるため、電気圧力鍋はお勧めです。
タンパク質や脂質をエネルギーに変えるビタミンは肉に多く含まれ、炭水化物をエネルギーに変えるビタミンは、炭水化物に多い。なので結局バランスよく食べることを前提として、「食ったら動く」を心がける。動く時間の少ない夕飯は量を控える。腹が減ったら、野菜を摂る。
が、食物繊維の摂り過ぎは良くありません。高確率で便秘になります。おおよそ30gぐらいまで。40g超えると摂り過ぎになります。。３食のボリュームのバランスは、朝飯>昼飯>夕飯の順番。ガッツリ食べたければ、野菜大量が必須。肉等の主菜は控えめ。バイキング（ビュッフェ）スタイルは、まずサラダ。野菜で腹を膨らませてから、主菜や主食。
炭水化物は茶色いのが優先。（田舎そば、玄米、古代米、雑穀）おかわり無料は見てはいけない。我々はもう10代ではないのだよ……。。特盛、大盛を頼むのは実験（要諦の13です）開始の合図。
コンビニでサラダチキンを買うなら、ウィダーinマルチビタミンはセット。
外食を必ず一回（仕事場でのランチ含む）するならば、もう朝と夕は脂質を摂らないぐらいの感覚で食事を選ぶ。外食1回で一日の脂質は半分超えることが多い。
家で脂質の多い部位（牛、豚、皮を含む鶏肉、青魚）を食べる予定なら、もう昼はサラダチキンと大きめのおにぎり1つ、マルチビタミンの名前があるゼリー飲料でOK。これで平気で300kcal超える。脂質は少なくなるけれど、朝と夕でカバーできる。
完全にコントロールしたければ、家族とは別にして飯を作る。家族と同じものを食べようと思わない。家族に作ってもらうのは甘えと心得る。
果物は嗜好品。あったほうがいいがなくてもいい。心の栄養と思おう。果物を摂ると特に糖質が……
主菜の調理法は、自宅での揚げるは避ける。炒めるよりも、焼く。
何よりもグリルなどで焼いて脂を落とす調理法を心がける。揚げ物が食べたければ作らず、惣菜を買う。その惣菜はグリルやトースターで油を落とす。
とにかく普通に食べるだけで脂質は取れる。減らすぐらいの心持ちでちょうどいい。
見た目の量としては、野菜5、肉や魚3、ご飯もの2ぐらいのイメージを心がけましょう。これは定量的（グラムなど）なものではなくて、見た目の話です。食卓やお皿を占める面積と思ってもらえればいいかと。
- 運動編
歩くのは8000歩以上。(日常生活に加え、5km程度歩くと在宅勤務でも担保できる)
8000歩以上でも体調維持に限定的な効果がある程度。（METs強度が低すぎる）ダイエットに効果はないが心身の維持には役立つという程度です。というか、倍（16,000歩）歩いても、ダイエットには意味がありません。痩せたければ、走る！しかし、いきなり走ると足を壊す。走るなら3km→5km→8km→10kmと2〜4週サイクルで徐々に伸ばす。ランニングマシーンは飽きるし、ボディメイクが目的でない限り、トレーニングマシーンは不要。（健康的になりたいだけならジムは不要）
水中活動(水泳・水中ウォーキング)は本当におススメ。汗をかくぐらいの気持ちで泳ぐ。ただし、運動計測自動化をできるように、ウェアラブル端末持込可の施設を探す。（最近は専用カバーをつければ持込可能な施設、なんなら市民プールも最近はあります）*1
-
雨の日の走る・歩くなどの行為は有無を言わさずサボる。足の違和感は即休む。安全と健康第一。
シューズは店員さんにちゃんと相談。足が入るとか、今までのサイズだからで買わない。ちゃんと測ってもらって、どんな足の形でどのメーカーが合うのかを聞いて買う。段違いで歩きやすい。
こんなところでしょうか。ぜひ参考にして下さい。
