「AWSではじめるデータレイク」を読んだ

「AWS ではじめるデータレイク」を読んだ。 この本は、タイトルにもある通りデータレイクの説明を AWS の製品を軸にして語られている。 本の中身は 3 部構成になっていて、1 部で理論を、2,3 部でハンズオンが語られている。

今回ハンズオンは手を付けておらず、1 部の理論について読んだ。 その中で参考になった場所についてまとめておく。

目次

1. データレイクの概念と知識
   1. データレイクの構築
   2. データレイクの活用
   3. データレイクの運用
   4. データレイクのセキュリティ
2. データレイクの実践（基礎編）
   1. ハンズオンの概要 - ビジネスデータのデータレイク
   2. デートを可視化する
   3. サーバレスSQLによるデータ分析
   4. データを変換する
   5. データを分析する（データウェアハウス）
3. データレイクの実践（応用編）
   1. システムの概要 - ログデータのデータレイク
   2. ログを集める
   3. ログの保管とカタログ化
   4. ログを加工する
   5. ログを分析する

1 章 データレイクの構築

まずはデータレイクの全体像から入り、それを AWS の製品でどう実現するかが語られていた。 その後はもう一度、データの収集、データの保存、データの変換といった詳細部分に話が移っていた。

少し気になった部分があり、まとめの以下の文章になる。

データレイクには「収集」「保存」「変換」「分析」の 4 つのコンポーネントがあります。

と書いてあった。 自分は「データレイクはデータの保管庫」という印象を持っており、他の 3 つの機能も含んでいる表現に違和感があった。 現時点でどちらが正しいかはわからないが、このように表現する人もいることを意識し、認識確認を怠らないように努めたい。

2 章 データレイクの活用

1 章はデータを使う前の段階までの工程の話だった。 2 章はデータを「誰が」「どのツールを使って」「どのようにデータを利用するか」について重きをおいて話が進んでいる。

• BI
• SQL によるアドホック/探索的な分析
• データウェアハウスによる複雑/定常的な SQL
• Python/R による応用的な分析

ここでも AWS の製品の名前と具体的な使い方が上がっていて、わかりやすい。 データウェアハウスとデータマートの切り分け方やストリーミングデータの分析方法など、少し突っ込んだ部分にも触れられていてよかった。

3 章 データレイクの運用

1,2 章に関しては事前知識が合ったので、サラッと読んだ。そして、この本で一番知りたかった部分が、3 章と 4 章になる。 1 章の部分でも表現した「データレイクはデータの保管庫」という意識が自分にはあったが、実際に運用していくとイメージが沸かなかった。 もちろん、何でもかんでもデータいれることが悪いのはわかる。しかし、実際にどういう基準で運用していけば良いのかというのがわからなかった。

データレイクの「正常」を定義する として、次のようなものが挙げられていた。

• 応答時間が規定値に収まっているか
• データの転送量が想定の範囲内であるか
• 利用する PaaS の値段が想定の範囲内に収まっているか

他にもいくつか例が挙げられているが、導入段階でも上記のものを算出するためのどのようなデータが必要か、確認するのに役立ちそうだと思った。 障害が起きたときのために、度のサービスレイヤに対して監視をおこなわなければいけないのか確認したり、マネージドサービスであっても冗長化をどこまで考えなければいけないのかといった気づきを与えてくれた。

クラウド自体も障害を起こすことがあるので、データに関しても扱い方のレベルを変えると言った対策が必要であると感じた。 例えば、常にアクセスできなければいけないデータなのか、消失させていはいけないデータなのかといった部分の確認になる。

最後に、使われていないデータを確認するため、データカタログを使ってアクセス履歴を取得したり、加工の変遷をたどったりすることも重要と語られていた。 「クラウドで大容量のデータレイクなんだからいいのでは？」と思ったが、アーカイブや重複分の削除をおこなうことで、利用料を削減できるので塵も積もれば山となる理論に近いなと思った。

4 章 データレイクのセキュリティ

3 章と同じで、とても読みたかった章である。

最初にある

セキュリティというと、「どういった対策があるか」ということから考えがちですが、そうではなく、「どういった状況で誰から何を守りたいのか」という脅威の想定を最初に考えるべきです

という文章がとても気に入った。 実務の中でも「セキュリティ対策はどんなことをしなければいけないかな」と言った漠然とする質問から、果てしないリスクの可能性を探しに行くことがある。 しかし、自分ごととして捉えるような、自分たちの場合だとどうなのか具体的な状況を想定することでとても建設的な議論がおこなえるように感じた。 これはセキュリティ対策以外でも、今後使っていこうと思った。

早速具体的なデータレイクの運用を想定し、「通信経路」「暗号化」「権限管理と統制の手法」について述べられている。 安全にするため暗号化しましょうという話だけでなく、暗号化の処理で発生するオーバーヘッドについても考慮しようと言ったことも書かれている。 また、ソフトウェアを使った場合のライセンス料などにも目を向けようと言ったことも書かれていて、こういう部分を無視しない姿勢に好感が持てた。

アクセス権限の部分に関しても、利便性とリスクは比例関係にあるので、バランスが大切になると言った話がされていた。 ガードレールのようなものと意識するとわかりやすいと例が示されていて、自分も誰かに説明するときは使わせていただこうと思ったぐらいだ。

まとめ

「AWS ではじめるデータレイク」はデータ分析基盤の構築や運用を検討している人にはとても参考になる本だった。 4 章分だけで 130 ページ近くになり、データレイクを学びたい人にとっても有用であるが、AWS での構築を検討している人には残り半分のハンズオンも参考になり価格以上の価値を見いだせると思う。 自分は普段 AWS を使っていないことと、個人利用の無料枠を使い切ってしまっているので、割愛したが時間とお金に余裕がある時に手を付けてみようと思う。

Data Engineering Study #4「データ分析基盤の障害対応事例LT祭り」 を視聴した

Data Engineering Study #4「データ分析基盤の障害対応事例 LT 祭り」に視聴者として参加させてもらった。 自分は普段、 Azure を使ったデータ分析基盤の導入支援をおこなっている。 そのため、各コンポーネントの簡単な知見などは知っているが、運用面や障害対応の知見がないため非常に楽しみにしていた。

今回のブログは自分用のメモと資料のまとめとして書き留めておく。

Data Engineering Study #4「データ分析基盤の障害対応事例 LT 祭り」

forkwell.connpass.com

アーカイブはこちら

正確な意思決定を阻む問題障害との向き合い方

発表者は @syou6162さんです。

（仕事の打ち合わせで視聴できずアーカイブ待ちです…） （ブログ投稿直前にアーカイブに気がついたので、後で編集）

正確な意思決定を阻む 問題・障害との向き合い方 from syou6162

www.slideshare.net

データ分析基盤の障害を未然に防ぐためのチェックリスト

発表者は @sotaron さんです。

コンポーネント毎にチェックポイントがあってわかりやすかった。

（見直したかったけど、資料が見つかりませんでした…）

IoT デバイスデータ収集の難しい点

発表者は@fetarodc さんです。

• IoT デバイスのデータ収集はスキルセットがぜんぜん違う
• IoT はエンジニアの総合格闘技
  • エンジニア成り立ての時、ラズパイでなにか作ってみようとしたけど、全然うまくいかなかったことを思い出した。
• ネットワークは切れることがある。
• ログは見ることが出来ない
  • このあたり、Maker Faire 東京で、会場に持っていったときに動かなくなったのは思い出だ…。

ラズベリーパイのデータを OSS を組み合わせて可視化しようとしたが、断念したことを思い出した。 いつか手を付けてみよう。

IoTデバイスデータ収集の難しい点 from Tetsutaro Watanabe

www.slideshare.net

障害、解決、その先に

発表者は@sista05 さんです。

4 つの事例が出てきた上に、Twitter 上での議論が非常に活発になって面白かった。 総論に出てきた「マネージドサービスに任せるほうがいい」「構成は簡単に、保守はしやすいように」ということは非常に共感した。

docs.google.com

障害はチャンスだ！障害を前向きに捉える

発表者は@nii_yan さんです。

• モブプロ/ペアプロになり、他の人のコマンドを見られる。
  • Q&A に出てきたが、モブプロと言うより、二次災害を防ぐためにダブルチェックを兼ねての知見共有の意味合いがある
• 知らないシステムでも仕様を知れる。

• ポストモーテム

  • 障害の事後検証報告書の意味
  • 障害復旧へ携わった本人以外に、組織も成長できる。

• 障害対応しているときにモブプロしている余裕がある？

• 障害対応しているときに別の障害を起こしてしまう可能性がある。ダブルチェックをするような感覚でモブプロをしている。

speakerdeck.com

バッチとストリーミング それぞれの障害に立ち向かう

発表者は@syu_cream さんです。

自分はデータ処理基盤の「導入支援」はおこなっていて、バッチレイヤとスピードレイヤをラムダアーキテクチャとしてお客様に紹介する機会はあった。 しかし、運用面での知見がないので、分けたあとでの実務面で発生しうる問題を把握できておらず大変参考になった。

speakerdeck.com

まとめ

普段からデータ分析基盤を運用している方々の知見が聞けてよかった。 やはりこの手の勉強会は OSS だったり Azure 以外のクラウドベンダーの話が多かった。 自分自身の話の幅を広げるためにも他のコンポーネントも少しは理解しようと思った。

今回のテーマは障害についてだった。 障害対応した際の話はなかなか表に出てこなかったり、発表する機会もなかったりする。 なので、発表の中の話の言葉を借りると、この LT 祭りをポストモーテムのような役割として四半期に 1 回ぐらいのペースでおこなうと良いのではないかと思った。

Twitter のハッシュタグが流れる速さもちょうどよくて、そちらからも情報収集ができ刺激を受けることが出来た。

余談

オンラインイベントに参加したときのレポートは「視聴した」にしたほうが良いのかと思って、タイトルを変えてみた。

じぶん Release Notes 0.30.06

10 月 1 日〜31 日の間の出来事がリリースされました。

10 月の感想

9 月から一転して、10 月はリフレッシュと自分を見つめ直す月になりました。 リフレッシュに関しては旅行に行きました。行った場所については下記です。

• 宮城（松島）・福島（蔵王）
• 北海道（札幌）
• 大阪・京都・静岡

社会的に少し落ち着いてきたといいつつ、まだまだ怖い部分もあります。 そのため、移動手段を車にしたり、日帰りにしたりと少し工夫をしました。

自分見つめ直すに関しては、いろいろな人と話す機会を設けました。 これは自分から動いた時もありますし、相手から声をかけてもらえた時もあります。 単純に気分が落ちていたところで話聞いてもらえるだけでも嬉しかったのに、わざわざ DM やらメッセージやらいただくケースもあって最高に嬉しかったです。

中でも話題として多かったのは今後のキャリアについて考える話でした。 常日頃から漠然と「今後どうしていこうかなぁ」とは考えていましたが、毎回の結論も漠然と「技術力を身に付けなきゃなぁ」となっていました。 それが、多くの人と話している中で「（ユーザに貢献したいので、多様な実現手段として）技術力を身に着けなきゃなぁ」と思っていることが自分の中ではっきりしました。 これは自分の中でとても大きな体験でした。

自分の中で「技術力を身につける」と言う目標を立てたときは、「ギークになりたいわけではないけど…」少ししっくりこない場面はありました。 もちろん、新しいことを学ぶことは常に楽しいですし、技術を深くことを学びたくないわけではありません。 しかし、何のために学ぶのかを考えたときに、本当にやりたいことかモヤモヤしていました。

何の為学ぶのかがはっきりしましたが、もちろんこれが正解かわかりません。 しかし、今自分が向くべきベクトルをはっきりさせることができました。 これからはそれに合わせてインプットとアウトプットを変えていきたいと思います。

技術・開発関連

• Power BI ドキュメント修正 プルリクエスト
  • https://github.com/MicrosoftDocs/powerbi-docs.ja-jp/pull/35

イベント

• Effective Python 輪読会
  • 8 章
  • 9 章
  • 10 章
• レガシーコードからの脱却輪読会

読んだ本

• 仕事に追われない仕事術 マニャーナの法則 完全版
• 人は話し方が 9 割
• 超雑談力 人づきあいがラクになる 誰とでも信頼関係が築ける
• 伝わる[図・グラフ・表]のデザインテクニック

ブログ

リリースノートを除き、次のエントリを書きました。

yoshitaku-jp.hatenablog.com

yoshitaku-jp.hatenablog.com

PV 数

3475 でした。

GitHub Actionsを手動で実行する

GitHub Actions が手動での実行に対応していたので試した。 以前 Firebase Hosting にデプロイするとき、 GitHub Actions は使ったことがあった。しかし、そのときには手動実行はなかった。 ブログによると 2020/07 に手動実行への対応をしていたようだ。

github.blog

今回は既存のワークフローに手動実行を取り込むのではなく、新しいワークフローを作成し確認していく。

使い方

テンプレートから GitHub Actions を作成する

GitHub のリポジトリに移動し、「Actions」をクリックする。次に「New workflow」をクリックする。

2020/10/20 現在はデフォルトの画面が次のようになっている。今回は HelloWorld が出力される「Simple workflow」を使用する。「Set up this workflow」をクリックする。

「Simple workflow」の内容が書いてある、「blank.yml」ファイルを作成する画面になる。まずは設定値を付けないと手動実行ができないことを確認する。このまま「Start commit」をクリックする。コミットメッセージを入力する画面が表示されるので、そのまま「Commit new file」をクリックする。

「GitHub Actions」の実行ファイルを配置するディレクトリに「blank.yml」が作成されている。

「Actions」タブを開いてみる。「blank.yml」を作成したタイミングで「GitHub Actions」が動いていることが確認できる。また、現時点では手動実行ができる画面は見当たらない。

手動実行の設定をおこなう

ここから手動実行の設定をおこなっていく。まずは、作成した「blank.yml」をブラウザ上から編集するため移動する。右端に存在するエンピツマークをクリックし、編集モードに移行する。

手動設定を追記する。キャプチャの画像はエディターを拡大したものになる。12 行目 13 行目に追記している。追記したら「Start commit」をクリックする。コミットメッセージを入力する画面が表示されるので、そのまま「Commit change」をクリックする。

# This is a basic workflow to help you get started with Actions

name: CI

# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the main branch
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
+  workflow_dispatch:
+    branches: [ main ]

再び「Actions」タブに移動する。先ほどとは違い、画面上に手動実行できるボタンが表示されている。 「Run workflow」をクリックすると、吹き出しが表示され、緑色の「Run workflow」をクリックすると「GitHub Actions」が実行できる。 今回は吹き出しの中に、ブランチの選択と緑色の「Run workflow」しか表示されていないが、手動実行する際に入力値を送る設定をいれると用途の幅が広がる。

画面での差分確認

おわりに

今回はGitHub Actionsを手動で実行する方法を確認した。 すぐに設定して使うことができるが、まだまだ知らない人も多そうなので参考になれば！

気軽にモックデータを作ろう / Mockarooを使ってみた

モック用データが欲しいときに見つけたのが「Mockaroo」だ。「Mockaroo」はブラウザ上で欲しいデータの形式を入力すると、ランダムなデータを指定した数だけ生成してくれるWebサービスだ。ライブラリなどをインストールする必要ないというところが嬉しい。今回は簡単に「Mockaroo」の紹介をする。

mockaroo.com

基本的な使い方

使い方はとてもシンプルだ。画面に欲しいデータの「列名」「タイプ」を指定して「Download Data」ボタンをクリックするだけで完了する。

「Preview」ボタンを押すとダウンロードする前にデータを確認することも出来る。

タブを「CSV」に変更すると表示が切り替わる。ここからコピーアンドペーストすることも出来た。

Options

列に指定できる項目を見ていく。「Options」にはblankとfxの文字が並んでいる。 blankは言葉の通り空白を意味していて、生成するデータの中から指定したパーセントの分だけ空白データを作成することができる。この機能を使うことで、虫食い状態のデータを作り、汚いデータを想定することも出来る。 fxは生成するデータを加工出来る。少し使い方を覚える必要はあるが、例に載っているものを見てもらうとエンジニアには馴染みのある形が多く、そこまで難しくないように感じられる。

次の画面は「fx」ボタンをクリックしたときの画面だ。

今回はfirst_nameをupper状態にし、ip_addressを90%空白状態にしデータを作ってみる。

「Options」で指定したとおり、dirst_nameは大文字になっていて、ip_addressは空白が多くなっている。

フォーマット

CSV以外にも出力する形は豊富に選べる。

• CSV
• JSON
• Tab-Delimited
• SQL
• Cassandra CQL
• Firebase
• Custom
• Excel
• XML
• DBUnit XML

今回は使う機会も多い「JSON」と「SQL」について掘り下げる。

JSON

CSVで使った形式をベースにしてJSONに組み替えた。

idとemailはそのままだが、nameを新たに追加しJSON Arrayとした。name配下にfirst_nameとlast_nameを入れたかったので、2つのField Nameの前に「name.」を追加した。これだけでJSONデータも生成できる。 first_nameとlast_nameは1組だけ得られればいいので、nameのmin elementsとmax elementsは1とした。この数字を増やすとfirst_nameとlast_nameのセットが複数生成されることになる。

SQL

CSVの形に少し戻し、SQLをみていく。この状態で、Previewボタンを押すだけだが、insert文が入った形にしてくれる。

include create tableをチェックするとcreate tableまで作ってくれる。これを流すだけでテーブル作成からデータの挿入まで終わるので便利だ。

おわりに

今回は「Mockaroo」について見てきた。お遊びの開発をしていてもテスト用のデータを用意することがとてもめんどくさかったので、「Mockaroo」を見つけることが出来てとても嬉しい。課金をおこなうと1000件以上のデータ作成だったり、作成のスピードが上がったりする。しかし、ひとつ上のプランでも年$50するので個人で使う分にはFreeプランで良さそう。参考になれば！

じぶん Release Notes 0.30.05

9月1日〜30日の間の出来事がリリースされました。

9月の感想

なかなかインプットとアウトプットができない日々が続いていて大変でした。 残り3ヶ月巻き返したいです。

技術・開発関連

• 特にありません

イベント

• 特にありません

読んだ本

• 特にありません。

ブログ

リリースノートを除き、次のエントリを書きました。

yoshitaku-jp.hatenablog.com

yoshitaku-jp.hatenablog.com

yoshitaku-jp.hatenablog.com

yoshitaku-jp.hatenablog.com

PV数

3526でした。

9月の目標結果

• 毎週ブロクを書く
• 1週1冊本を読む ブログは仕事の進め方の本を読み、感想を書きました。 本を読むの目標は分量に左右されるので今後見直しが必要ですね。

ReactとExpressをHerokuにpushする

Hasuraが最近盛り上がっており興味を持ったため、久々にHerokuを立ち上げた。また、JavaScriptのフレームワークとしてはVue.jsを触ることが多かったが、TypeScriptとの相性や情報量の多さがReactのほうが多いと感じたのでReactを触ってみることにした。

今回は、Hasuraを使う前段としてReactとExpressをHerokuにpushする手順を書いておく。

ディレクトリ作成

まずは作業ディレクトリを作成する。

mkdir sandbox
cd sandbox
yarn init -y

Expressを作成する

Expressをインストールする

yarn add express

sandbox/index.jsを作成し次のコードを記述する

const express = require('express');
const path = require('path');

const app = express();

app.use(express.static(path.join(__dirname, 'client/build')));

app.get('*', (req, res) => {
  res.sendFile(path.join(__dirname+'/client/build/index.html'));
});

const port = process.env.PORT || 5000;
app.listen(port);

sandbox/package.jsonにscriptsを記述する。Heroku上でindex.jsを実行するコードである。

"scripts": {
    "start": "node index.js"
}

一回Herokuへプッシュする。この段階ではアクセスしても、「Not Found」が表示される。

Reactを作成する

まずは、Reactを使えるようにインストールする。

yarn global add create-react-app

次に sandbox にて次のコードを実行する。実行することでsandbox/clientの配下にReactの資材が配置される。

create-react-app client

Heroku用の設定

sandbox/package.jsに次のコードを追記する。heroku-postbuildはビルドするコマンドを記述している。heroku-postbuildはbuildと区別され、heroku上だけで動かしたいコマンドを記述する

"scripts": {
    "start": "node index.js",
    "heroku-postbuild": "cd client && yarn && yarn run build"
  }

ここまでの変更をHerokuにプッシュすると、Reactの画面が表示される

自分の情報管理をNotionに移行した

以前タスク管理に関する技術同人誌を読んだ。その中で、「（タスクを）１か所に保管する」ということが語られていて、振り返りや情報管理も１か所にまとめたほうがいいなと感じていた。

yoshitaku-jp.hatenablog.com

移行する前は、自分のメモは「Google Keep」、タスクの管理は「Trello」、情報ストックは「Pocket」を使っていて、これも一つにまとめたいと感じていた。これらのアプリの利点は、ブラウザやスマホのアプリ、タブレットからもアクセスが可能だったところで自分はとても気に入っていた。同期の速度も問題なかった。しかし今思うと、やはりアプリが統一されていないというところで使い勝手が違う点が不満であることも感じていたかもしれない。

そこで今回、メモとしても、Todo管理としても、情報のストックとしても、1つのアプリで使えるNotionに移行した。 まだまだ使い始めなので完全な感想は述べられないが、Todo管理として次のような画面であったり、

こちらは今後やりたいこととしてテーブル表示も簡単にできる。

表示の雰囲気と左のペインを見てもらうとわかるが、これらは同じアプリの中で表示されている。また、ディレクトリ構造のようにもなっており、ファイル感覚でとても使いやすい。テーブル表示は「want to」ファイルに「Default view」の中身を表示するようになっており、中身の入れ替えもとても簡単になっている。

まとめ

現時点では、まだ使い始めなので簡単な感想になったが、高機能で使い慣れると強力なツールになると感じている。現在は無料プランなのだが、ファイルをアップロードする制限が5MBのためとても少ない。今後学習のキャプチャ画像を載せたりしたいので、月額$5を払って有料プランにする予定でいる。簡単なテキストレベルの共有なら無料プランでも大丈夫なので使ってみてもらいたい。

タスクをコントロールしよう / 成長するタスク管理の原則 を読んだ

IT業界にいると実感するが様々なことが日々新しくなっていき、その度に自身の知識のアップデートも必要になっていく。業界の知識は取り入れているが、広く仕事のことになるとあまり知識を取り入れず来てしまったように思う。タスク管理やプロジェクトのマネジメントについて、自分の課題に感じていたため技術書典で販売されていた「成長するタスク管理の原則」を手に取った。基本的なことばかりだったかもしれないが、自分を見つめ直すいい機会になり、参考になった。気になった部分をメモする。

成長するタスク管理の原則 とは

これは技術書典9で発売された書籍だ。本書は70ページほどで収まっており、「タスク管理の原則」について半分、筆者の実例について半分ほどの分量で構成されている。自分はPDFを購入した。iPadで見る分には、文字が小さいなど特に困らなかった。

語られていること

本書自体の分量もそこまで多くなく、語りすぎると中身を全てを語ってしまいそうになるので気をつけたい。自分が「見直さなければ」と気をつけた点がいくつかあるのでまとめる。

1か所に保管する

「1か所に保管する」は、やらなければいけないとメモしたタスク管理の場所を1箇所にまとめようと言う話だ。基本的な話で恥ずかしいが自分はできていなかった。プライベートでのタスクと仕事のタスクとして、仮に2箇所になることはしょうがないとしても、自分の場合は次のような場所に散乱していた。

• ロディアのメモ帳
• 仕事用PCのメモ帳アプリ
• Trello
• Google Keep
• （後で調べようとして）ブラウザのタブ

これは最適なツールに出会えず試行錯誤してきた結果でもあるのだが、思い出せる範囲でも5つあるので実際にはまだまだ保存されている場所はあるように思う。またメモ帳として作成したファイルの場所も散乱しており、どの内容がどこにあるのか毎回探している気がする。こんなことを繰り返していると、素晴らしいソリューションを作ってきた先人たちに申し訳ない気持ちがしてくる。

今後は「すぐ書ける」「同期される」ことを重視して1か所にまとめたいと思う。これは忘れないためでもある。

リズムを作る

これは計画を立て、実行し、振り返るという章だった。一番苦手な部分でもある。計画を立てるのもそこまで得意ではない上に、割り込みタスクも「重要かつ緊急で対応するリスト」に入れてしまっていた。優先順位付けが出来ていないわけである。

これは個人のタスクでもそうだが、飲み会などが入ったりするとポンポン入れてしまい、週でやりたかったタスクを放置してしまうことが多かった。個人のタスクなので誰にも迷惑をかけていないのだが、最終的には未来の自分に迷惑をかけている気がしたのでこれからは注意したい。

仕事に置いては割り込みタスクがどれほど重要なものなのか確認、優先順位の交渉をしっかりおこなっていこうと思う。

自分なりのストレス発散法

ここ最近は仕事でつまづくことが多く、とても難しい時間が続いている。ストレスの根本的な解決にはならないが、和らげる目的として別のアクティビティをして紛らわせるのが効果的だったりする。人生の中でここまでうまくいかない経験をしたことがあまりなく非常に難しい時間が続いているが、そんな時こそ「そのタイミングをどう乗り越えたか」記録しておくことにする。

身体を動かす

まずは身体を動かすことで、自分はストレスを和らげられることがわかった。この身体を動かすことは汗をかくことが求められる。なのでストレッチや軽い筋トレなどはあまり効果がなかった。散歩も効果がある方ではあったが、ゆっくりあるていてる中で思考がストレスの原因から離れないので、軽度に煮詰まった時にやるのがよさそうだということがわかった。

前置きが長くなったが自分はランニングとフットサルがストレス発散法として機能していることがわかった。距離はあまり関係がなく、とりあえず汗をかけば良さそうだった。フットサルは単純に好きで楽しいのでいい。散歩の逆説になるが、どちらも運動している間に考え事をしている余裕がないので、頭の中からストレスを意識外に置けるため有効に感じている。

銭湯やサウナに行く

これは身体を動かさないストレス発散法になる。これらの良いところはデジタルデバイスを持ち込めないところにある。この文章もスマートフォンで書いているが、現代の世の中ではデジタルデバイスを手放す瞬間がほとんどない。あるとすれば寝ている時とお風呂に入っている時だろう。ただ自宅のお風呂も気をつければ持ち込め、映画を楽しんだりできる。しかし公共の施設に行けばそんなことはできないので、意識的にデジタルデバイスを遠ざけることができる。誰かとコミュニケーションを取るにも、調べ物をするにもデジタルデバイスが必要だが、それがない環境ではやれることがほとんどなくなる。挙げ句の果てに、（これは個人の感想だが）気持ちの良いお風呂やサウナに入っている時にストレスの原因について考えるような野暮なことをする気持ちは湧いてこなくなる。まずはその時を楽しみたい気持ちが勝るのだ。

まとめ

とりあえず現時点で自分に効果のあるストレス発散法を書いた。もちろんストレスの根本原因を対処するのが一番良かったりするが、今後もいろいろ試してストレス発散できる手段を増やしていきたい。ひとまず来週からは身体を動かし、疲れたらサウナに入りつつ仕事をする。