MinIOを触ってみた

MinIOなるものを見つけて、興味を持ったのでちょっとだけ触ってみた。 といっても今日は起動を試して見るだけ。 MinIOは何回かに分けて取り上げようかなと思う。

MinIOとは？

簡単に言うと、goで実装されたオブジェクトストレージ。 クラウドネイティブな利用を想定して開発されたようだ。 S3と互換性があり、SDKからも利用できるらしい。

min.io

dockerで触ってみる

クイックスタートガイドはこちら。

MinIO | The MinIO Quickstart Guide

色んな方法があるっぽい。 Macならhomebrewでインストールできたり、Linuxなら実行ファイルをwgetで入手してchmod +xするだけだったり。

今回はdockerを使ってみる。

起動

docker runを実行するだけでいいらしい。

 ❯ docker run --name minio_container -p 9000:9000 minio/minio server /data
Unable to find image 'minio/minio:latest' locally
latest: Pulling from minio/minio
a6b97b4963f5: Pull complete
13948a011eec: Pull complete
d48558b57ac3: Pull complete
fdf2c2f8d59c: Pull complete
a5f9b75d1f38: Pull complete
7cff61c3c0cd: Pull complete
bf88f6a73948: Pull complete
Digest: sha256:84a74cd1db07afdc0a399cc9882af4dcc1dbc39636133e818daf76b4e3da469b
Status: Downloaded newer image for minio/minio:latest
Endpoint: http://172.17.0.2:9000  http://127.0.0.1:9000

Browser Access:
   http://172.17.0.2:9000  http://127.0.0.1:9000

Object API (Amazon S3 compatible):
   Go:         https://docs.min.io/docs/golang-client-quickstart-guide
   Java:       https://docs.min.io/docs/java-client-quickstart-guide
   Python:     https://docs.min.io/docs/python-client-quickstart-guide
   JavaScript: https://docs.min.io/docs/javascript-client-quickstart-guide
   .NET:       https://docs.min.io/docs/dotnet-client-quickstart-guide
Detected default credentials 'minioadmin:minioadmin', please change the credentials immediately using 'MINIO_ROOT_USER' and 'MINIO_ROOT_PASSWORD'

これだけで使えるようになる。 ログに出ている通り http://127.0.0.1:9000がブラウザアクセス先、クレデンシャルはデフォルトでminioadmin:minioadminが設定される。

ちなみにdocker runするときに -e "MINIO_ACCESS_KEY=foo" -e "MINIO_SECRET_KEY=bar"と指定すれば、クレデンシャルを指定して起動することができる。 今回は省略。

ブラウザでアクセスしてみる

http://127.0.0.1:9000 にブラウザアクセスするとこんな画面が表示される。

デフォルトのクレデンシャルminioadmin:minioadminでログイン。

バケットを作成

画面の右下の+よりCreate Bucketを選択。

sample-bucketを作成してみる。

バケットが作成された。

キーをアップロード

Create BucketのうえにUpload fileがあるのでそこからアップロード。

アップロードされた。

awsのCLIで触ってみる

クレデンシャルをexportして、endpoint-urlにhttp:/127.0.0.1.9000/を指定すればOK。

$ export AWS_ACCESS_KEY_ID=minioadmin
$ export AWS_SECRET_ACCESS_KEY=minioadmin
$ aws --endpoint-url http://127.0.0.1:9000/ s3 ls s3://sample-bucket/
2021-02-17 23:22:52          0 sample-key

Webコンソールでアップロードしたキーを参照できた。

最後に

まだ詳しいことはよくわかってないけど、面白そうなので今後も触ってブログネタにしようかな。 例えば、S3のAPIをプロダクション環境で使っているとして、その開発環境ではS3の代わりにMinIOをさっと立ち上げて検証する。というような使い方ができそう。

duコマンドで肥大化しているファイルが見つからない時はlsofコマンドを使うと良い

2週間くらい前の話になりますが、ウチのサービスで起きたオンコール対応についてネタにします。

ディスク使用率が増加してアラートが飛んできた

見ての通り/の使用率が90%に到達。

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3       273G  232G   27G  90% /

...

どのディレクトリが使用率の大半を占めてるのか調べるために、/直下の各ディレクトリごとの使用量を du -shで確認。 しかし、表示された各容量を合計しても明らかに Used 232Gに達していなかった。 ちなみに一番大きかったのは /var/log。

$ sudo du -sh /var/log
96G     /var/log

なんでこんなことが起きているのかというと、この記事が参考になった。

du で見つからない巨大ファイルは lsof で見つけるの術 - HsbtDiary(2013-07-24)

lsof コマンドを使うことで、ファイルシステム上は削除されているが、プロセスが掴みっぱなしになっているケースがあるらしい。 というわけで調べてみたら見事にヒット。 /var/log/app/application.log.1 というログファイルをunicornプロセスが掴みっぱなしだった。 ちなみにlsofで確認できた /var/log/app/application.log.1 というファイルは lsコマンドでは表示されない。

$ sudo lsof | grep deleted | sort -k 7 -nr | head
ruby      13460     <user>    7w      REG                8,3 127222634114    8519684 /var/log/app/application.log.1 (deleted)
ruby      11623     <user>    7w      REG                8,3 127222632772    8519684 /var/log/app/application.log.1 (deleted)
ruby      11620     <user>    7w      REG                8,3 127222632251    8519684 /var/log/app/application.log.1 (deleted)
ruby      11617     <user>    7w      REG                8,3 127222631864    8519684 /var/log/app/application.log.1 (deleted)
ruby      11615     <user>    7w      REG                8,3 127222631122    8519684 /var/log/app/application.log.1 (deleted)
ruby      11612     <user>    7w      REG                8,3 127222630172    8519684 /var/log/app/application.log.1 (deleted)
ruby      11608     <user>    7w      REG                8,3 127222629663    8519684 /var/log/app/application.log.1 (deleted)
ruby      11602     <user>    7w      REG                8,3 127222629403    8519684 /var/log/app/application.log.1 (deleted)
ruby      11600     <user>    7w      REG                8,3 127222629403    8519684 /var/log/app/application.log.1 (deleted)
ruby      11596     <user>    7w      REG                8,3 127222629301    8519684 /var/log/app/application.log.1 (deleted)

何が起きてるの？

Linux上で見えるファイル(ディレクトリエントリ)はinodeを参照しており、プロセスがファイルを掴むときも同様にinodeを参照している。

何らかの原因でディレクトリエントリは消えたけど、プロセスがファイルを掴みっぱなしな状態になって deleted なログファイルを掴んだプロセスが残り続けていた。そんでそのプロセスが参照先のブロックへログの書き込みを継続していたと。これがls上はファイルが見えないのにディスク使用量がどんどん増えていった現象の正体。

ちなみにログローテーションをきっかけにこの現象が発生したと思われる。

サンプルコードでこの現象を再現する

このコードを実行すると、deletedな/tmp/test.logのファイルサイズ増えていく様子がわかる。

#!/usr/bin/ruby

io = File.open("/tmp/test.log", "w")

warn "# unlink /tmp/test.log"
File.unlink("/tmp/test.log")

loop do
  warn "# file usage"
  puts `lsof -c ruby | grep deleted`
  warn "# write 1MB data"
  io.write( "@" * 1024 * 1024 )
  io.sync
  sleep 1
end

# unlink /tmp/test.log
# file usage
ruby    3987 <user>    7w   REG    8,1        0  67149903 /tmp/test.log (deleted)
# write 1MB data
# file usage
ruby    3987 <user>     7w   REG    8,1  1048576  67149903 /tmp/test.log (deleted)
# write 1MB data
# file usage
ruby    3987 <user>     7w   REG    8,1  2097152  67149903 /tmp/test.log (deleted)
# write 1MB data
# file usage
ruby    3987 <user>     7w   REG    8,1  3145728  67149903 /tmp/test.log (deleted)
# write 1MB data
# file usage
ruby    3987 <user>     7w   REG    8,1  4194304  67149903 /tmp/test.log (deleted)

...

対処：unicornにシグナル USR1を送る

https://yhbt.net/unicorn/SIGNALS.html が参考になった。

Master Process

...

USR1 - reopen all logs owned by the master and all workers See Unicorn::Util.reopen_logs for what is considered a log.

...

Worker Processes

...

Note: as of unicorn 4.8, the master uses a pipe to signal workers instead of kill(2) for most cases. Using signals still (and works and remains supported for external tools/libraries), however.

USR1 - Reopen all logs owned by the worker process. See Unicorn::Util.reopen_logs for what is considered a log. Log files are not reopened until it is done processing the current request, so multiple log lines for one request (as done by Rails) will not be split across multiple logs.

要するに、unicornプロセスはシグナル USR1 を受け取ると、masterプロセス/workerプロセスが掴んでいるログファイルを開き直してくれる。 具体的にはこんな感じでシグナルを送ればOK。

$ sudo kill -USR1 $(cat /path/to/pids/unicorn.pid)

使用量が一気に減った

これで解消 🎉

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3       273G  114G  146G  44% /

...

deletedなプロセスも綺麗に無くなった。

$ sudo lsof | grep deleted
$

Godanキーボードをお試し中

スマホで日本語入力をするとき、多くの人はフリック入力を使っていると思います。 ですが私は、最近までQWERTYを使っていました。 フリックを使おうとも考えたのですが、どうにも手が慣れず。。。ずっとQWERTYを使ってきました。 日本語入力の場合、慣れればフリック入力のほうが良いとは思うのですが。 私のスマホは画面が大きいので両手で操作することが多く、そのせいでかえって慣れなかったのかもしれません。

ただ、ずっとQWERTYにしがみついていると他の入力方式に手を伸ばせなくなってしまうので、何かしらは覚えないとなぁと思う今日この頃（別にQWERTYが悪いわけではないんですけどね 😓 ）。 最近、 godanキーボード というものを発見しました。

support.google.com

こんな配列です

左の列に母音、中央・右の列に「かさたなはまやらわ」の子音が並んだ配列です。 濁音・半濁音を入力したい場合は子音のキーでフリック入力すればOKです。 （"ぱ"を入力したい場合は、"H"で左にフリックして"A"）

iPhoneの場合はgboardというアプリを入れればOK

iPhoneユーザの場合は、gboardというアプリをインストールすればGodanキーボードを利用できます。

Gboard - Google キーボード

• Google LLC
• ユーティリティ
• 無料
• 

apps.apple.com

godanキーボードを使う場合は

1. iPhoneの設定で 一般 > キーボード > キーボード にGboardを追加する
2. Gboardのアプリを開いて 言語 > インストール済の言語 > 日本語 Godan を選ぶ

と設定すればOKです。

Godanキーボード練習中

まだ使い始めたばかりで慣れないので、依然QWERTYで入力したほうが早い状態です。 ですが、ローマ字入力でありながら日本語の直感に近い配列なので、慣れると扱いやすくなるのではないかと思います。

というわけで根気よく練習を続けたいと思います。

systemdな環境ではmysqld_safeではなくsystemdの環境変数を用いるらしい

CentOS7環境にmysqlを導入しmysqld_safeを使おうと思ったら

[root@mysql-server ~]# mysqld_safe
-bash: mysqld_safe: コマンドが見つかりません

とでました。

MySQL :: MySQL 5.7 Reference Manual :: 2.5.10 Managing MySQL Server with systemd より

Note

On platforms for which systemd support for MySQL is installed, scripts such as mysqld_safe and the System V initialization script are unnecessary and are not installed. For example, mysqld_safe can handle server restarts, but systemd provides the same capability, and does so in a manner consistent with management of other services rather than by using an application-specific program.

Because systemd has the capability of managing multiple MySQL instances on platforms for which systemd support for MySQL is installed, mysqld_multi and mysqld_multi.server are unnecessary and are not installed.

どうやらsystemdな環境ではmysqld_safeはインストールされないようです。

同リンクの Configuring systemd for MySQLにやり方が書いてありました。

systemdの環境変数を利用する

systemdを使う環境ではmysqld_safeではなく、systemdの環境変数を用いるようです。 具体的には systemctl set-environment MYSQLD_OPTS="--skip-grant-tables" を実行してmysqldを再起動すればOK。

[root@mysql-server ~]# systemctl set-environment MYSQLD_OPTS="--skip-grant-tables"
[root@mysql-server ~]# systemctl restart mysqld
[root@mysql-server ~]# systemctl status mysqld
● mysqld.service - MySQL Server
   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
   Active: active (running) since 木 2020-12-03 18:19:18 JST; 6s ago
     Docs: man:mysqld(8)
           http://dev.mysql.com/doc/refman/en/using-systemd.html
  Process: 14706 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid $MYSQLD_OPTS (code=exited, status=0/SUCCESS)
  Process: 14684 ExecStartPre=/usr/bin/mysqld_pre_systemd (code=exited, status=0/SUCCESS)
 Main PID: 14710 (mysqld)
   CGroup: /system.slice/mysqld.service
           └─14710 /usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid --skip-grant-tables
12月 03 18:19:17 mysql-server systemd[1]: Stopped MySQL Server.
12月 03 18:19:17 mysql-server systemd[1]: Starting MySQL Server...
12月 03 18:19:18 mysql-server systemd[1]: Started MySQL Server.

こんなふうに --skip-grant-tablesと付きます。

Main PID: 14710 (mysqld)
   CGroup: /system.slice/mysqld.service
           └─14710 /usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid --skip-grant-tables

あとは mysql -u root などでログインできます。

戻し方

systemctl unset-environment MYSQLD_OPTSと実行してmysqldを再起動すればOKです。

[root@mysql-server ~]# systemctl unset-environment MYSQLD_OPTS
[root@mysql-server ~]# systemctl restart mysqld
[root@mysql-server ~]# systemctl status mysqld
● mysqld.service - MySQL Server
   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
   Active: active (running) since 木 2020-12-03 18:20:23 JST; 1s ago
     Docs: man:mysqld(8)
           http://dev.mysql.com/doc/refman/en/using-systemd.html
  Process: 14903 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid $MYSQLD_OPTS (code=exited, status=0/SUCCESS)
  Process: 14880 ExecStartPre=/usr/bin/mysqld_pre_systemd (code=exited, status=0/SUCCESS)
 Main PID: 14906 (mysqld)
   CGroup: /system.slice/mysqld.service
           └─14906 /usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid
12月 03 18:20:21 mysql-server systemd[1]: Stopped MySQL Server.
12月 03 18:20:21 mysql-server systemd[1]: Starting MySQL Server...
12月 03 18:20:23 mysql-server systemd[1]: Started MySQL Server.
[root@mysql-server ~]#

Rasberry Pi 4って意外と熱を持つなぁと思った話

Rasberry Pi 4を購入しました

最近ふと何か作ってみようかなと思いラズパイを勢いで購入しました。 購入したのはこちら。 初めてラズパイを触るのでスターターキットが無難かな思って選びました。

Pi4 B 8GB スターター キット V2 オンライン教材付 [RASST48STA0321]

実際に買ったものがこちら。 ヒートシンクとかケースは本キットに付属しています。

セットアップしていたら熱を持っているのが気になった

OS入れて諸々セットアップしていたら気になることがありました。 ラズパイを触ってみると思いのほか熱を持ってるなぁと。 ぐぐってみると、同じことを気にしている人が結構いるようです。 というわけで実際どれくらい熱を持つのか調べてみました。

計測方法

• 電源投入後20分間の温度上昇の推移を計測する
  • vcgencmd measure_tempコマンドを利用した検証用コードで計測する
  • 詳しくは後述
• CPUに負荷をかけない場合/かける場合それぞれの温度変化を計測する
  • CPUに負荷をかけるときは stress-ng --cpu 4 -qをバックグラウンドで実行してCPU使用率を100%にする

vcgencmdコマンドについて

ラズパイでは、vcgencmdコマンドを使うことでCPUの温度や動作クロックを見ることができます。

実行例）

pi@raspberrypi:~ $ vcgencmd measure_temp
temp=38.0'C

vcgencmdコマンドを使うことで、他にも出来ることがありますがここでは割愛します。 詳しく知りたい人は以下のドキュメントを読んでみてください。

www.raspberrypi.org

検証用コード

なんとなくpythonで書いてみました。 60秒毎に vcgencmd measure_tempを実行してcpu温度を出力します。

import subprocess
import time

def main():
  while True:
    date = time.ctime()
    cpu_temp = run_vcgencmd(['vcgencmd', 'measure_temp'])
    cpu_temp = run_vcgencmd(['vcgencmd', 'measure_temp'])
    print( "{}, temp:{}'C".format(date, cpu_temp) )
    time.sleep(60)

def run_vcgencmd(command):
  proc = subprocess.run(command, stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True)
  result = proc.stdout.split("=")[1].replace("'C\n","")
  return result

if __name__ == '__main__':
    main()

コードを実行すると以下のような結果が出力されます。

$ python3 raspi_cpu.py
Sat Oct 17 15:03:59 2020, temp:36.0'C
Sat Oct 17 15:04:59 2020, temp:37.0'C
Sat Oct 17 15:05:59 2020, temp:39.0'C

...

測定結果

負荷をかけない場合は、計測開始直後は 36.0℃で20分経過すると48℃まで上昇しました。 計測開始から15分程度で47℃〜48℃あたりで落ち着きます。

負荷をかける場合は、20分後に74℃とかなりの温度まで上昇しました。 20分経過時点でも温度上昇し続けていたので、長時間動かすと80℃まで上がるのではないでしょうか。 サーマルスロットリング機能が80℃で動くらしいので、これ以上負荷をかけるのはやめておきます（ちょっと怖い💦）。

さいごに

長時間CPUが忙しくなるようなプログラムはラズパイ4では避けたほうが良いでしょう。 また、そうでない場合でもケースに触れると熱を持ってることがわかるレベルなので、気になる人は冷却性に優れたケースに変えたりcpuファンを導入するなりしましょう。 いずれにせよ、熱対策はしっかりしたほうが良さそうです。

.terraform-versionを使ってterraformのバージョンをリポジトリごとに管理する話

私の会社ではいろんなサービスでterraformを使っていますが、サービスごとにバージョンがばらばらで0.11だったり0.13だったりします。 サービスごとにterraformのリポジトリが別れているので都度tfenv useで切り替える必要がありますが、だんだん面倒になってきました。 なので、.terraform-versionを使ってみることにしました。 （理想を言えば全部最新にすべきですがいったん置いといて 💦 ）

https://github.com/tfutils/tfenv#terraform-version-file

terraformのコードを管理するリポジトリ直下に.terraform-versionを配置して、使用したいバージョンを書けばOKです。

.terraform-versionを使わない場合

tfenv useで指定済のバージョンが使われます。

$ tfenv list
* 0.13.3 (set by /usr/local/Cellar/tfenv/2.0.0/version)
  0.13.2
  0.12.29
  0.11.14

0.13.3にする場合

.terraform-versionに0.13.3と書けばOKです。 tfenv listを実行してみると、0.13.3になっておりset byと書かれている部分を見ると、.terraform-versionによって使うバージョンが選ばれていることがわかります。

$ cat .terraform-version
0.13.3

$ tfenv list
* 0.13.3 (set by /path/to/repository/.terraform-version)
  0.13.2
  0.12.29
  0.11.14

0.11.14にする場合

意図的に古いバージョンを使いたい場合も同様にすればOKです。

$ cat .terraform-version
0.11.14

$ tfenv list
  0.13.3
  0.13.2
  0.12.29
* 0.11.14 (set by /path/to/repository/.terraform-version)

マイナーバージョンを指定しない場合

マイナーバージョンの指定がない場合はこんな書き方もできます。 例えば以下のように書くと、インストール済かつ0.13系なものから最新のバージョンが選択されます。

$ cat .terraform-version
latest:^0.13

$ tfenv list
* 0.13.3 (set by /path/to/repository/.terraform-version)
  0.13.2
  0.12.29
  0.11.14

手元の環境で未インストールなバージョンを指定する場合

該当のバージョンがない場合、terraform initなどを実行するときに自動でインストールされます。 これはTFENV_AUTO_INSTALLという環境変数がデフォルトでtrueになっていることが関係しているようです。

https://github.com/tfutils/tfenv#tfenv_auto_install

手元の環境であえて0.13.3を削除して、0.13.2をセットしておきます。

$ tfenv list
* 0.13.2 (set by /path/to/repository/.terraform-version)
  0.12.29
  0.11.14

0.13.3を指定します。

$ cat .terraform-version
0.13.3

terraform initを実行すると、0.13.3のインストールも実行されます。

$ terraform init
version '0.13.3' is not installed (set by /path/to/repository/.terraform-version). Installing now as TFENV_AUTO_INSTALL==true
Installing Terraform v0.13.3
Downloading release tarball from https://releases.hashicorp.com/terraform/0.13.3/terraform_0.13.3_darwin_amd64.zip
################################################################################################################################ 100.0%
Downloading SHA hash file from https://releases.hashicorp.com/terraform/0.13.3/terraform_0.13.3_SHA256SUMS
No keybase install found, skipping OpenPGP signature verification
Archive:  tfenv_download.3jTzo2/terraform_0.13.3_darwin_amd64.zip
  inflating: /usr/local/Cellar/tfenv/2.0.0/versions/0.13.3/terraform
Installation of terraform v0.13.3 successful. To make this your default version, run 'tfenv use 0.13.3'
Initializing modules...
Initializing the backend...
Initializing provider plugins...
- Using previously-installed terraform-providers/openstack v1.21.1
- terraform.io/builtin/terraform is built in to Terraform
- Using previously-installed hashicorp/template v2.1.2
The following providers do not have any version constraints in configuration,
so the latest version was installed.
To prevent automatic upgrades to new major versions that may contain breaking
changes, we recommend adding version constraints in a required_providers block
in your configuration, with the constraint strings suggested below.
* hashicorp/template: version = "~> 2.1.2"
Terraform has been successfully initialized!
You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.
If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

0.13.3がインストール＆セットされました。

$ tfenv list
* 0.13.3 (set by /path/to/repository/.terraform-version)
  0.13.2
  0.12.29
  0.11.14

頭の中身を言語化することで「考える」ことがはじまるという話

仕事をしていると、話し合いの場面、文章を書く場面、ある課題の解決策を練る場面、などなど考えたり言葉を発したりする場面が多々あります（仕事以外でもあるけど）。 こういったことに対して、筋道を立てて考えたり話たりする手法が存在しています。 ロジカルシンキングが典型例ですね。 ロジカルシンキングは非常に大事で、相手を納得させたり、より的確な解決策を導くための強力な武器になります。 ですが、ロジカルシンキングに限らず、なにか考えるためにはある大前提を満たす必要があると私は思っています。 それはタイトル通り「頭の中身を言語化すること」です。

考えるとはアウトプットすること

会社の先輩からこんなことを教わりました。

考えるとはアウトプットすることである

アウトプットしていないのであればそれは考えているのではなく、ただ悩んでいるだけなのだと思います。 人は脳の中身を覗くことなんてできません。 仮に「私は考えている」と主張しても、具体的にどう考えているのか第三者から見えないとその主張には説得力がありません。 第三者に見える形にすることで初めて「私は考えている」と主張できると私は考えています。

タイトルの「言語化」も先輩のいうアウトプット(=考える)の手段の一つだと私は考えています。 言語化して文章や言葉にすることで、第三者から見ても「この人なりに考えがあるのだな」と見える形で納得させられますしね。

「ひたすら書き出す」ことで頭の中身を言語化する

私がなにか考えるときは、頭の中によぎっていることを一字一句そのまま文章に書き出すことをやっています。 ポイントは、結果・結論だけでなく、そこに至るまでの過程や考え始めたきっかけも全部書き出すことです。 「Aかな〜でも〇〇もあるからBもすてがたいな〜」と思ったら、そのとおりに文字にします。 また「こんなこと誰でも考えるよなぁ。当たり前なことだよなぁ。」と思いたくなるような内容も書き出します。 書き出している間は、論理立て考える必要はありません。 ダラダラとした長ったらしい文章になってよいです。 考えを全部書きだして、最後に論理立てを見直せばいいのですから。

私の会社ではslackというチャットツールでコミュニケーションを取っているのですが、ただ会話するだけでなく自分の考えを整理するツールとしても役立ちます。 私の場合、考えるときは"○○について考えるスレ"みたいなスレッドを立てて、そこに自分の頭の中にあることを可能な限り殴り書いています。

書き出すことで考えを深めることもできる

頭の中を何かがよぎるだけでは、おかしい点があっても自分自身はそれに気づくことはできないものです。 それを言語化して読み返すことで、自分の考えを第三者視点で俯瞰できるようになります。

また、本記事の最初に触れたロジカルシンキングについても、書き出して言語化することではじめて実践できるようになると考えています。 5W1H、演繹法、帰納法、色んな方法がありますが、いずれもまず文字に起こさないと活用できませんからね。

さいごに

勉強になる本を紹介します。

www.amazon.co.jp

「内なる言葉で思考を深め、外に向かう言葉に変換する」ことの重要さが述べられています。 「内なる言葉」とは頭の中で無意識に発している言葉を指しており、「外に向かう言葉」とは第三者に話す言葉を指しています。 この記事で書いたことも、「内なる言葉」を自分自身で見える形にして思考を深めるアクションになっていると思います。 この本を参考に「考える」ことについて綴った記事・ブログも色々出ているので、探してみてください。