サービスレベルマネジメント

平成28年春季　問56．　サービスレベルマネジメント

問題文「ITサービスマネジメントにおけるサービスレベル管理の説明はどれか。」

解答群
ア．　あらかじめ定めた間隔で、サービス目標に照らしてサービスの傾向及びパフォーマンスを監視する。
イ．　計画が発動された場合の可用性の目標、平常業務の状態に復帰するための取り組みなどを含めた計画を作成し、導入し、維持する。
ウ．　サービスの品質を阻害する事象に対して、合意したサービス目標及び時間枠内に回復させる。
エ．　予算に照らして、費用を監視及び報告し、財務予測をレビューし、費用を管理する。

午後問題のカテゴリにもなっているので、重点的にITIL関連の問題を調査しているがかなり内容が多いので網羅するのは時間がかかってしまう。

まず、ITILのサービスマネジメント等で検索をかけてわかったことは、この分野は今とても業界で注目されている分野みたいでコンサルティング会社などが紹介記事を書いていることが多いみたいだ。

いくつか見た中で詳細は営業上の理由からか、はぐらかしているように思えるものの概要をつかめる読み物としては以下のサイトが良いように感じた。

まずニュートンコンサルティングさんの「用語集」、英国発と謳っているので、ITILのおひざ元とも言える会社さんである。

次に、FL.OPSさんの「クラウド関連ブログ」より「ITIL」。こちらは誤字が多くて閉口してしまうが、通して読むとかなり全体像がつかみやすくなっているように思える。

ここで、FL.OPSさんのサイトを通して読んでみて「ん？変だな？」と思ったのが、可用性管理などに関してはサービスデリバリという項目で述べられていて、インシデント管理とは別で扱われていることだった。

そこで、さらにサービスデリバリ、そしてサービスサポートを調べてみて、ようやく概要をつかめるに至った。

改めてびっくりさせられたのは、Wikipediaさんが一番まとまっていたということである。
「サービスデリバリ」と「サービスサポート」はそれぞれのリンクを見ていただくとわかると思う。

まとめると、サービスデリバリはおもに中長期的なITサービスの計画及び改善手法について述べられていて、サービスサポートはITサービス運営の日々の運用手法について述べられているということだ。それと、それぞれが赤本、青本と呼ばれているそうな。

サービスデリバリを構成するプロセスは5つで、「サービスデリバリプロセス群」と呼ばれ、それぞれサービスレベル管理、ITサービス財務管理、可用性管理、ITサービス継続性管理、そしてキャパシティ管理とに分類されている。中長期的な計画と改善手法という分類に当てはめて、改めて名前だけ見てみても意味するところが理解しやすい。

さらにサービスサポートは5つのプロセスと1つの機能で構成されていて、それぞれインシデント管理、問題管理、構成管理、変更管理、リリース管理、そして機能としてのサービスデスクとなる。これも日々のサポートの運営手法として考えると名前もかなりしっくりくる気がする。

一番混同して理解されてしまいそうなのは、サービスデリバリとサービスサポートを構成する要素、特に構成管理とサービスデリバリプロセス群がそれぞれ密接に結び付くだろうということで、考えれば当たり前なのだが日々の構成管理をしっかりしているからこそ可用性管理やITサービス継続性管理といった計画が立てられるというところだと思う。

実際にサービスサポートの中の機能であるサービスデスクとして今は日々働いているのだが、日々の生活の中で聞く用語がそれぞれ日々行っている作業の中で理解されているためにそれこそ「何が何だか意味が分からない」ように思っていたが、ITILが提唱していることはそれほど難しいことではなく、おそらくは

ビジネスを継続・発展させていくために存在するITサービスを中長期的及び短期的なタイムスパンでとらえた上で、それぞれのプロセスの中で行うべきこと、そしてそれぞれのプロセスがどのように関連付けられるべきかについて述べている

のだと理解した。

ここで、これほどクリアにまとめることのできる概念が色々な場面で難しく解説されているのは多分、コンサルティング会社が儲けるためという意味と、それ以上にこの概念を継続して実践することの難しさから来ているのだと考えた。

まず、おそらくはサービスデリバリとサービスサポートを実践していくうえで一番のカギを握っているのはサービスサポートのプロセスの内、構成管理だと思う。構成アイテム（Configuration Item）と呼ばれるIT資産には、おそらく多くの場合管理がしやすいサーバやネットワーク機器が一番登録されやすいと思われ、これに関するインシデント管理や変更管理は技術的な難易度はかなり高いもののITILの手法を取り入れた会社であればどこでも行えているのではないかと推測できる。

代わりに、構成要素の中で末端に位置するPCやプリンタ、それぞれに利用されているアプリケーションなどについては末端に行くほど管理はないがしろにされ、それが故に可用性管理やITサービス財務管理、キャパシティ管理を机上の空論にさせてしまうきらいがあるのではないだろうか。

では、それら一つ一つの構成要素（Configuration Item）を管理、つまり構成管理する主体はどこになるかというと、ITILで謳われているところのサービスデスクという機能、つまり人間が行うことになるわけだが、このサービスデスクという機能はSPOC（Single Point of Contact）と同時に呼ばれ、全ての問い合わせを一手に引き受けながらインシデント管理などの記録やハードウェア障害対応も同時に行うべき部署になっている。

つまり、サービスデスクという機能はITILが謳っているITサービスの根幹を担っており、全ての窓口でありITサービスの末端（一番数の多いPCなど）にあるCI（構成要素）の管理主体であるわけである。

まとめてしまうとかなり簡単に聞こえるこの仕事は、世の中のクラウド化が進むにつれてサーバやアプリケーションの管理は単価の安い海外に移行しているために英語などの共通言語でのやり取りができることが必須になり、さらに問い合わせの総合窓口であるがゆえにPCのハードウェアからOS、利用されている基幹システムを含めたアプリケーションで起こっているインシデントの問い合わせ先を即座に判断し、時に主体となってトラブルシューティングを行いながらインシデントの場合は解決に至った経緯をアナウンスしつつ、恒久的な解決策のための変更管理において時にはユーザとのコミュニケーション窓口となりながら、合間を縫って末端の機器のメンテナンスや交換対応に追われる日々を送らなければならなくなっている。

では、サービスデスクになんでもできるスーパーマンを雇うか？と言われると多くの企業は英語が喋れてちょっと技術力があるぐらいの使い捨て要員を雇っているのが現実で、かと言ってビジネスの要望に応えて行うアプリケーションの変更が多くまともに資料も作成せずにリリースしたら「後は窓口はサービスデスクで」と言ったおざなりな対応を行っているのが現実ではないだろうか。

ITILのサービスマネジメントを成功させるカギであり、土台となる構成管理とサービスデスクという部分に関して、ほとんどの場合クローズアップされることもなく日々が進んでいると思われるが、この点を解決するのは非常に難しいのではないかと推測する。

何故なら、上に述べたような毎日を永久に継続していけるような人間になれば、他でもっと良いお金を出してくれるところに行ってしまうからである。そして、それが人材の枯渇を生み出し、最終的に土台を支える人間をとっかえひっかえしながら日々の要請に応えるだけの毎日を繰り返す悪循環を迎えることになると思われる。

ここまで愚痴に近いことを述べてきて、じゃあどうやれば成功するのか？という点について末端で働くサービスデスクとして思うのは、「Knowledge base」の構築と維持、そして人の教育に尽きるのではないかということだ。

かつて武田信玄は「人は城、人は石垣、人は堀」と言っていると言われているが、まさに末端の兵隊であるサービスデスクを強力な兵隊に仕立て上げる（最初から雇うのはコスト的にまず無理である）ことにこそ、成功のカギがあるのではないかと偉そうに言ってみる。

ここで問題にさかのぼって改めて解答群を見つめてみると、解答は当たり前のようにア．であることがわかった。
この分野について初めての人は用語がいっぱいで分かりにくいと思うが、中長期的な計画と改善の手法が「サービスデリバリ」であり、日々のサービスの継続・維持が「サービスサポート」であることを念頭に置いて、再度それぞれのプロセスの用語を見つめ返してもらうとわかりやすいのではないかと思う。

トレーニング日誌 2017/4/2～

一連の記事で行っている実験のまとめはこちらのページ、生活実験：トレーニングを参照ください。

ざっくりまとめると忙しい中で一日30分と週1回のウェイトトレーニング、食事制限で体脂肪を落とせるのか？という実験をやっています。

2017/4/2

体重：73.5kg

体脂肪率：20.7%
基礎代謝量：1622kcal

肉体年齢：38歳

シックスパックトレーナー　Lv.15

※毎日とさして変わらない生活をしているにも関わらず体重が大きく減っている。体脂肪率も同様に昨日から大きく変わっているように思える。
今日は妙に目覚めが良く、且つ仕事でいらいらしていることで二度寝もできなかったため日中の活動時間が長かったという可能性も否定できない。
せっかくしばらくの間断酒するので、日々の体重の増減を細かく見ていきたいと思う。

2017/4/3

体重：73.4kg

体脂肪率：20.7%
基礎代謝量：1618kcal

肉体年齢：38歳

フレンチプレス（10kg）　x20

ワンハンドローイング(10kg)　x15

ダンベルカール（10kg）　x15
ダンベルランジ（左右：10kg） x10x左右（10秒ルール開始）

サイドレイズ＋デッドリフト（10kg）　x10
トライセプスエクステンション（10kg）　x10

大胸筋アイソメトリック　x2

※毎日風呂で腹をマッサージして、何らかのトレーニングをして・・・を繰り返しているが、段々体が慣れてきたのかそれほど苦にはならなくなってきた。
食事もたまに甘いものが欲しくなるがそこまでの飢餓感も無い。
こないだ受けた体脂肪率の測定でも適正体重は68.5kgとあったので、この調子で酒を抜いてトレーニングを続けると意外と早い段階で適正体重まで落とせるのではないかと期待している。
後は睡眠を可能な限り8時間取れるようにしたい。感触的に睡眠時間が短いと体重が落ちるのも時間がかかるような気がしている。

サービスレベル管理

平成28年春季　問55．　サービスレベル管理

問題文「ITILにおけるサービスデスクを配置する方法の一つである”フォロー・ザ・サン”の説明はどれか。」

解答群
ア．　インターネット技術を利用して、単一のサービスデスクであるかのようにして運用する。
イ．　スタッフを物理的に一か所に集約し、複数のサービスデスクを単一の場所に統合する。
ウ．地理的に分散した二つ以上のサービスデスクを組み合わせて、24時間体制でサービスを提供する。　
エ．　夜間帯にサービスデスクで受け付けたインシデントを昼間帯のシフトリーダがフォローする。

実際自分が行っている業務がそのままの内容なのだが、行っていることの教育すら受けたことがないのは笑えてしまう。これを機にある程度内容について理解したいと思う。

ニュートン・コンサルティングさんの「サービスデスク」の項目にざっくりとした内容については記述されている。

ローカルサービスデスク：　ユーザと同じ場所か、物理的に近い場所に存在する。
中央サービスデスク：　サービスデスクを一か所で運営する形態
バーチャルサービスデスク：　ネット利用で、分散していてもあたかも一か所でサービスを提供しているかのように見せる形態
フォロー・ザ・サン：　2か所以上のサービスデスクを組み合わせて24時間対応を行う形態

解答群のエ．についてもフォロー・ザ・サンを解説しているように見えるが、24時間体制であることを謳っていないため、ウ．がより適切だとのこと。
この辺はひっかかる可能性があるため注意が必要だと思う。

午後問題の対策にと思って抜粋して内容を見てみたものの、内容についてしっかりと網羅するためには午前問題の用語の範囲では足りないことに気がついた。
まずは抜粋した午前問題を終わらせつつ、午後問題を読み解きながら用語などを網羅していければと方針転換することにした。

不定期身体測定 実験中：20170401

12月末から続けている実験で一日30分のトレーニングと食事制限で体脂肪が落ちるかを検証している。
12月末時点からどのくらい変化しているかを確認するために、比較の数値は実験開始直前のものを採用する。

2016/12/29　⇒　2017/4/1
胸囲：　106.0　⇒　110.0
上腕伸展囲：　31.6　⇒　36.5
上腕屈曲囲：　36.5　⇒　39.5
前腕周径：　30　⇒　30
胴囲：　92　⇒　83
大腿周径：　54.3　⇒　55.0
※数値だけだと前回から胸囲と上腕が1cmだけ太くなっている。前々回と前回で変わりがなかったと記憶しているので、ジムに行き始めたのが効果を発揮しているのか。。。

2016/12/29時点

↓
2017/4/1時点


かなり接写になってしまったが、体全体が大きくなっているのはわかる。
肩周りが盛り上がっているのが開始当初から比較すると明らかにわかる程度だ。

2016/12/29時点

↓
2017/4/1時点


こちらもかなりの接写になってしまったが、腹回りがかなりすっきりしているのがわかる。
腹筋の割れ目もかなりわかりやすくなってきた。

体脂肪率はそこまで大きく変わっていないので焦り気味だが、確かに体形は大きく変化しつつあると言える。
ここから春になると温度も上がり、汗もかきやすくなると思うので少しずつだが体脂肪率も減ってくれるのではないかと期待している。
が、他の記事にも書いた通り、応用情報の試験が2週間と迫ってきているのでそれまでの間禁酒してどのくらい飲酒が影響しているかの経過を見てみたいと思う。
4月の終わりには父の三回忌で実家に帰るので少し太るかもしれないが、そこから7月の間に追い込みをかけていこうと考えている。
必要に応じて食事量を大幅に削減してボクサーに近い減量を試みる可能性も否定できないが、一生に一度ぐらいはそんなこともあってよいのではないかとも思う。

トレーニング日誌 2017/3/31～

一連の記事で行っている実験のまとめはこちらのページ、生活実験：トレーニングを参照ください。

ざっくりまとめると忙しい中で一日30分と週1回のウェイトトレーニング、食事制限で体脂肪を落とせるのか？という実験をやっています。

2017/3/31

体重：74.0kg

体脂肪率：20.7%
基礎代謝量：1635kcal

肉体年齢：38歳

シックスパックトレーナー　Lv.15

※試験も近くなってきたので、今日酒を飲んで試験が終わるまで酒を断とうと考えた。
飲酒翌日の体重はそれほど大きくないものの、2・3日ぐらいのスパンで影響があるように思えてきたからだ。
摂取カロリーが強度1.3を大きく下回っている食事をしているのにも関わらず体重が落ちてこないのは筋肉量の増加も可能性はあるが、やはり飲酒前後のカロリーが影響しているように思えてならない。
2週間程度の断酒で影響はわかりそうなので、しばらく様子を見てみたいと思う。

2017/4/1

体重：74.2kg

体脂肪率：21.4%
基礎代謝量：1624kcal

肉体年齢：39歳

フレンチプレス（10kg）　x20

ワンハンドローイング(10kg)　x15

ダンベルカール（10kg）　x15
ダンベルランジ（左右：10kg） x10x左右（10秒ルール無）

サイドレイズ＋デッドリフト（10kg）　x10
トライセプスエクステンション（10kg）　x10

大胸筋アイソメトリック　x2

※下半身トレーニングを取り入れるためにダンベルランジを取り入れてみた。今回は10秒ルールを使わず、普通に行って様子を見る。
そこまで大きな負荷はないものの、現時点で全種目するのに30分ギリギリである。試験も近くなってきており、時間に限界を感じ始めているものの途中でやめるわけにはいかない。
7月にはウニ採りが待っているのだっ( ﾟДﾟ)

SOAP、CORBA、DCOM、SIP

平成28年秋季　問35．　SOAP、CORBA、DCOM、SIP

問題文「ほかのコンピュータ上にあるデータやサービスを呼び出すためのプロトコルで、メッセージ記述がXMLのヘッダとボディで構成されているものはどれか。」

解答群
ア．　CORBA
イ．　DCOM
ウ．　SIP
エ．　SOAP

この問題もまずもって全くわからない。まあ、記憶に残るように勉強しているわけなので、少しずつ調べてみようと思う。

まず、CORBAはCommon Object Request  Broker Architectureの略だそうで、いくつかサイトを見たもののそもそも実際にプログラムを書くような人でないと完全な理解はできそうになさそうである。

その中で、「達人プログラマーを目指して」さんの「CORBA関連のJava技術について」の中でおそらく現場のプログラマさんが感じている率直な感想を書いていたので参考にしてみた。

「インターフェースを決めておけば言語によらずにサービスを実装できるということから、信頼できる枯れたCORBAの実装が利用できるのであれば、必ずしもWebサービスなどに置き換えるよりもよいというケースも一応存在すると思います。」

CORBAの基本的な概念としてはプログラムコードをカプセル化することで色々な他のプログラムから呼び出せるようにした規格なのだそうで、色々な言語（C、C++、JavaはもとよりPythonまで）からカプセル化されたプログラムを呼び出して使うことができるようにするらしい。

ここまで書くとなんだか古いプログラムもカプセル化してしまえばすごく便利なように聞こえるが、インターネットが普及してブラウザから色々なサービスの提供を受けられるようになった今、あえてこの技術を選択しなくてもいいのでは？みたいなことらしい。

一例としては富士通さんの「CORBA概要」というPDFファイルがあって、これを見ると細かなところは置いておいても何となく理解できたような気になれる。この例ではCOBOLをCORBAを利用して連携できるようにするということが書かれているが、COBOLなどの古い言語を新しい言語から呼び出したりするのに実用的なんだと理解した。

クラウドや仮想化技術にしても、いかに古い技術を活かすかという観点から考えると営業的な意味合いでどうやって古くなったIT資産を転用し、お金に変えるか（営業する側からみた視点だが・・・）という意味でひねり出されたアイディアとも言えると思うので、そのようなアイディアで昔作られたものなんだろうな、ぐらいでよさそうである。

では次にDCOMは、Weblio辞書さんの「DCOM」にざっくり書かれていて、簡単に言うとCOMという技術をネットワーク越しに使えるようにした技術だということだ。ちなみに「Distributed Component Object Model」の略だそうだ。
COMというのはWindowsを利用しているとそこかしこにちらほら出てくる用語だが、調べてみてもいまいちピンとはこなかった。が、まあMicrosoftが開発したソフトウェア基盤の一種だということで納めて置いた方がよさそうだ。何しろこの辺の技術は掘り下げるとどこまでも深くなっていく。

ということで適当にウェブサイトを閲覧していたところ、DCOMに関して面白そうな記事を見つけた。

「Geekなぺーじ」さんの「DCOM（分散COM）を無効にする」というページである。ここを見るとWindows XPの時代からあった技術らしく、上に書いたようにWindows環境にあるCOMをネットワーク越しに使えるというこの便利機能が、ウィルスの踏み台にされることもあり、Windows Updateが行われていないマシンだと「インターネットに接続しているだけで」感染させられてしまうらしい。

どこにいっても便利な技術っていうのはなんらかの落とし穴を持っているらしい。。。

次に進みたい。SIPは「Session Initiation Protocol」の略で、探すと「戦略的イノベーション創造プログラム」とか言う他の言葉まで出てくるのでWikipediaさん情報のみから読み解くと「Session Initiation Protocol」に書かれている通りオーディオなどの通信を制御するH.323というプロトコルに代わるセッション制御プロトコルなのだそうだが、現在はインターネット上の会議など、電話やチャット、テレビ電話などによく使われている双方向通信を行うもののようだ。

ざっくり概要だけ見ると、サーバとクライアント間の通信のように主従関係のようなものが持ちにくい通信、つまり電話などのやり取りの中で通信を行う双方がサーバとクライアントの両方の役割を担えるような仕組みということだそうだ。

あまり面白くもないのであまり掘り下げずにさっさと次に行こう。最後にSOAPについて調べて今日も終わりにしたい。もう疲れてきてソープと聞くだけで大人なサービスしか思い浮かばない。

＠ITさんの「SOAP(Simple Object Access Protocol)」というページの記述をまとめると、ネットワーク経由でオブジェクト間の通信を行うプロトコルでXMLを使っているのが特徴ということだ。

「エンベロープ」「ヘッダ」「ボディ」の領域で構成されていて、ファイアウォールで通過しにくい組織間の環境を超えて通信するのに役立つと書かれているのは非常に有益な方法のように聞こえる。

そして、最重要な項目としては「W3C」の宣言でSOAPは何かの略ではなくなり、固有名詞であるということになったということである。何故最重要か？という点だが、これを知っている技術者たちは一様に大人なサービスのSOAPとの二つの固有名詞であると心の底では絶対に思っていると断言できるからだ。

モルダー、あなた疲れてるのよ。と言われそうなので今日はここまでにしたい。

トレーニング日誌 2017/3/28～

一連の記事で行っている実験のまとめはこちらのページ、生活実験：トレーニングを参照ください。

ざっくりまとめると忙しい中で一日30分と週1回のウェイトトレーニング、食事制限で体脂肪を落とせるのか？という実験をやっています。

2017/3/28

体重：74.4kg

体脂肪率：21.4%
基礎代謝量：1630kcal

肉体年齢：39歳

シックスパックトレーナー　Lv.15

※体重の下降が止まり、安定してきているように見える。これが筋肉が増えて体脂肪が減っているのであれば良いが、体脂肪がほぼ一定している事実から考えるとあまり望みはないのだろうか。。。

2017/3/29

体重：73.1kg

体脂肪率：18.7%
基礎代謝量：1653kcal

肉体年齢：34歳

ベンチプレス　（70kg）x10　（60kg）x10　（55kg）x10x2　（50kg）x10x2
チンニング（61kg）x10　（54kg）x10　（47kg）x10x2　（40kg）x10x2
ダンベルショルダープレス（18kg）x10　（16kg）x6　（14kg）x6　（12kg）x6
サイドレイズ（14kg）x10　（12kg）x10　（10kg）x10x2　（8kg）x10x2
ワンハンドローイング（18kg）x10　（16kg）x10x2　（14kg）x10x3　（12kg）x10x3
ダンベルカール（14kg）x6 （12kg）x6　（10kg）x6　（8kg）x6

デッドリフト左右各(37kg)x10x3

※昨日はいつもは休み前日に酒を飲むのだが、我慢してウェイトトレーニングに行った。前回行った時に体脂肪含めた測定をしてくれるサービスがあるが、トレーニング後はあまり正確な値にならないと言われたためで今回計測してみようと思っていたからである。

窓口で数百円払って計測時間は大体5分かからない程度、手で電極を握って計測する形である。

結果は以下のようである。
体重：74.2kg
体脂肪：　21.5%
BMI：　26.0kg/m2

さらに部位別の筋肉量が調べられるようで
右腕：　3.69kg
左腕：　3.51kg
体幹：　27.6kg
右脚：　8.44kg
左足：　8.36kg
となっている。

わかりにくいのだが、腕と体幹は体重から見た筋肉発達程度という項目でいずれも115%を超えているようで、脚に関しては100%ちょっとと言ったところらしい。

測ってくれた人は何かにびっくりしていたらしいが、何がびっくりさせていたのかは不明だ。ただ、筋肉量がどうやら多いらしいのだけはわかった。

で、せっかく5分のために結構な金額払ったので、体脂肪率を落とす簡単な方法を聞いてみた。
それは2点あって、1点目は大腿筋を鍛えて有酸素運動をすること、2点目は腹回りの脂肪については直接的な刺激が一番効くということだ。

腹回りの直接的な刺激？と聞き返したところ、女性のエステのように直接もみほぐすことが腹回りの脂肪を分解するには一番効果的とのこと。なるほど。。。エステにもそれなりの実証効果があるんだな・・・と感心した。

1点目の大腿筋を鍛えて有酸素運動というのはある程度想像がつく。大腿筋は体の中では一番大きい筋肉になるので、そこを鍛えてから有酸素運動、特にランニングやサイクリングマシンなどは脂肪燃焼に効果が大きいだろう。

ということで前からも考えていたのだが、デッドリフトという項目を今回から加えてみた。デッドリフトについてはダンベルトレーニングでサイドレイズ＋デッドリフトと書いているので聞き覚えがあるかもしれないが、実際に俺がダンベルトレーニングでやっているのは適当に名前をつけているものなので、本当のデッドリフトではない。

しかも、俺がデッドリフトと言っているのは、ラグビーをやっていた頃の監督に教えてもらったもので少し一般的に言われるものと少し違う。実を言うと、一般的なデッドリフトを今日の今まで知らなかった。

俺が今まで考えていたデッドリフトはバーベルのバーをまたいで行うものだ。姿勢の維持が異常に難しい（左右の姿勢が変わるため、一般的に言われるデッドリフトでも言われる腰にかかる負荷をしっかりと腰で支えるのが難しくなる）が、効果はこのトレーニングを行った1年上の先輩の背筋力が200kgを優に超えていたことで分かる。

たった50kg、左右10回x3セットを半年しただけ（ほぼ毎日）でそれである。効果は計り知れない。

しかし、今日トレーニングをした感じだと2時間（ジムの1回券の時間）では有効な有酸素運動は難しそうである。ウェイトトレーニングに1時間10分ぐらい費やしてしまうので有酸素運動に割ける時間は30分か40分ぐらいである。

さらに普段のダンベルトレーニングに大腿筋トレーニングを取り入れるのはなかなか難しそうでもある。色々と課題があるが、一番は・・・

最近になって体重の減少が止まってしまっているのが気になっていたが、色々と見てみたところやはりアルコール摂取が体脂肪と体重に影響を与えているように思えてきた。

確かに摂取カロリーと直接的な関係を1日スパンで見るとそれほど認めにくいが摂取カロリーの平均値で見た場合、2500kcalを平均して摂取しているように見え、確かに短期スパンでは影響がないように見えるものの、摂取カロリーは長期的に影響があるようにも見えるからだ。

ただ、酒と美味しいと思えるものを断てるほど俺の精神状態は日常的にはそれほど良好とは言えないので、別の方法を考えた。

休みの日の夕食はそのままにして、日中はそれほどストレスも飢餓感も感じないので「紅葉饅頭」でギリギリ空腹にならないところを攻めてみようということだ。

そこで、今日の晩飯はこれである。



その代わり、今日の日中口にしたのは紅葉饅頭4個である。これで二日間で摂取するカロリーをかなり抑えられる　⇒　酒を飲んでも無問題　という解決方法である。

最後に測定してくれたトレーナーの人に「トレーニングの目的は何かあるのですか？」と聞かれたので、「ウニ採りでケツが浮くから」と答えるとなんとも言えない笑顔が帰ってきた。

ちなみに今日の体重測定は入浴後なのであまり参考にならない。