J.S.Bach 無伴奏チェロ組曲第1番「プレリュード」のレッスン その1


仕事の関係でちょっとだけお休みしていた、りきひさみねこ先生のヴィオラのレッスンを4月の末から本格的に再開し、7月末に行う発表会の曲目をどうするか話したところ、とんとん拍子でJ.S.Bachの無伴奏チェロ組曲第1番「プレリュード」を頑張ってみましょうかというお話になり、今日が実際に譜面を見ながらの初めてのレッスンでした。

最初はスラー無しでものすごくゆっくり音をとっていくところから開始です。録音を聴きながら譜面は眺めていたんですけれども、実際に弾いてみると指回りが結構大変なことに気づきました。普段は2の指でとっていたようなところを3の指でとったり、4の指でとっていたところをあえて開放限で弾いたり。正直頭がこんがらかりそうになりながらも、まずは全体の1/4までの音とりが完了。

先生曰く、前半と後半とでは前半の方が圧倒的に弾きやすいので、まずは前半をスラー無しでちゃんとさらっていき、全体をさらい終えたところで弾けないところをピックアップして重点的にレッスンしていきましょうとのこと。はい、承知しました。

この曲はJ.S.Bachの弦を使う曲の中でも好きなもののひとつなので、ゆっくりでもいいのでできるだけ丁寧に弾きたいなと考えています。目標にしているテンポは藤原真理さんの演奏している、割とゆったりしたものです。

可能であればこのテンポに近づけていきたいのですが、果たしてここまで近づけることができるかどうか。自分にとっては技術的にも自らかなりハードルを上げてしまった感がありますが、できる限りしっかりと弾くことができるように頑張っていきたいと思います。

ちなみにこの曲、先生によると原版はスラーがなくて、カザルスがスラー付きにしたとかなんとか。あとは1箇所だけ音の解釈(Hで弾くかBで弾くか)が異なるところがあるらしいです。初めて知りました。勉強になります。

レッスンの記録は自分自身の振り返りを含めて、発表会当日まで書き綴っていきます。

カテゴリー: Private | タグ: , , | コメントする

TerraformのtfstateファイルをTerraform Cloud上でお手軽に管理する方法


はじめに

IaC環境のひとつ、Terraformでコード管理しようとするとき、一般的にはバックエンドで生成される状態を管理するファイルである terraform.tfstate ファイルを、AWSではS3バケット上に格納することが多いですが、複数の環境のステートファイルをS3バケットで管理しようとするとなかなか煩雑になることが多々あるので、それを少し改良しようと、試しにTerraform Cloudで管理をしてみることにしました。

Terraform Cloudは、HashiCorp社が提供するTerraform向けのSaaS型のホスティングサービスで、本来はTerraformを組織の中で共同で利用するためのリポジトリを提供してくれたり、使いこなすことができれば、例えばGitHub上で管理しているTerraformのコードのプルリクエストがマージされた際に、GitHub Actionsのように、変更されたリソースの記述を環境上に反映してくれたりといったCI/CD的な機能を提供してくれたりと結構便利な機能が搭載されているのですが、そこまでのコントロールが必要でなくても、例えばステートファイルだけを管理することも可能です。

今回は、本当のスモールスタートで、ステートファイルだけをTerraform Cloud上に管理するところだけをスコープにしています。

設定手順

HashiCorp Cloud PlatformアカウントとOrganizationの作成

まずはHashiCorp Cloud Platformアカウントをトップページから作成してアカウントを取得後、Organizationの設定を行います。無料のプランであれば、5人まで組織の中にアカウントを紐づけることが可能です。

参考:

Projectとworkspaceの作成

Terraform Cloudは、Organizationの下に複数のProjectをぶら下げることができ、さらにその下に実際のステートファイルを管理するworkspaceを作成していくことができます。Terraform Cloudに作成したアカウントでログインすると、Projects & workspacesという画面に遷移するので、まずは右上の[New]ボタンをクリックしてProjectを作成します。

Projectの作成が完了したら、同じく[New]ボタンをクリックしてworkspaceを作成します。今回はコードの管理はGitHub上で行い、ローカルのターミナル環境を利用してTerraformの操作を行うので、Create a new Workspaceの画面上では[CLI-driven workflow]を選択します。すると次の画面でWorkspaceの名前と、Projectとの紐付けを行う画面に遷移するので、workspace名を入力して、先ほど作成したProjectを選択し、一旦[Create workspace]ボタンをクリックします。これでworkspaceまでが作成できています。

workspaceの設定

workspaceの設定まで完了したら、左ペインの[Settings]をクリックしてExecution Modeを”Local”に、Remote state sharingを”Share with all workspaces in this organization”に変更します。Execution Modeを”Remote”にすると、Terraformの実行に関する操作がすべてTerraform Cloud上にある仮想マシン上で実行されます。今回はステートファイルだけをTerraform Cloud上で管理したいため、”Local”に設定して、[Save settings]ボタンをクリックします。

Terraform側の設定

Terraform Cloudと連携できるようにするために、Terraformの実行環境を設定している .tf ファイルを以下のように記述します。(敢えてバックエンドをS3に設定していた時の設定をコメントアウトして残しています)

# ===============================================================================
# Terraform
# ===============================================================================
terraform {
  required_version = "1.4.6"
  #  backend "s3" {
  #    bucket = "terraform-bucket"
  #    key    = "terraform.tfstate"
  #    region = "ap-northeast-1"
  #  }

  cloud {
    organization = "vlayusuke"
    hostname     = "app.terraform.io"

    workspaces {
      name = "vlayusuke-poc-infrastructure-develop"
    }
  }

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "4.65.0"
    }
  }
}

実際に動かしてみる

Terraformを実行するときには、ターミナル上でまず最初に terraform login してTerraform Cloudにログインします。このときにトークンの発行を求められるので、 yes を入力するとWebブラウザに遷移してトークン発行画面が表示されます。

トークンを発行したらターミナルコマンドに貼り付けるとTerraform Cloudのログイン画面に遷移するので、あとは普通に terraform init して terraform plan して terraform apply することで、ステートファイルをTerraform Cloud上に保持しながらTerraformの操作を実行することが可能になります。

そしてステートファイルは以下のようにTerraform Cloud上に保持されます。

今後進めたいこと

これで、バックエンドに terraform.tfstate ファイルを管理することなく、Terraformを用いた環境の構築と構成管理を進めていくことが可能になりました。

とはいえTerraform Cloudではまだまだ色々なことができそうなので、効率的に環境構築と構成管理をできるように、Terraform Cloudの機能を色々と試していきたいと思います。

カテゴリー: Work | タグ: | コメントする

MacBook Air (M2,2022)を購入して6か月経過


先代のMacBook Air (M1, 2020)は、ディスプレイの修理をしながらも快適に使用していたのですが、会社の上司がMacBook Air (M2, 2022)を購入して楽しそうに作業していたのを見て、これはやっぱり自分も買い替えるしかない! と勝手に思ってしまい、半年前につい買い替えをしてしまいました。自分の中ではMacに関する減価償却は3年と考えていて3年おきに買い替えをしていたのですが、異例の速さです。買ってしまったものは仕方がないのでもう使い倒すしかないですね。

ちなみに以下のスペックのモデルを購入しました。

  • 8Core CPU
  • 8Core GPU
  • 16GB Memory
  • 512GB SSD

メモリは例によってデフォルト8GBのところを16GBに拡張しています。

期待通りのパフォーマンス

そんなわけで半年間使ってみてのインプレッションなのですが、パフォーマンスに関しては期待通りですね。普段使いだけではなく一部開発にも使用しているので、時たまDockerを立ち上げたりしているのですが、メモリを食いがちのDockerを立ち上げても他のアプリケーションの動作には影響しませんし、コードを書く際には同時にVisual Studio Codeを立ち上げているのですが、同時使用していても全く苦になりません。

それでいてMacBook Air (Mi, 2020)の重量よりもさらに軽い1.24kgまで軽くなっているので、どこにでも持っていきたい派の自分としては可搬性がさらに向上して嬉しい限りです。個人的に寂しいなと思っているのは、ディスプレイが大きくなったことで、”MacBook Air”のロゴがなくなってしまったことくらいですが、最近はそれも気にならなくなってきました。

ディスプレイのノッチに関しては、これはもう慣れですね。ちょうどメニューバーにかぶさるようにしてノッチが存在しているので、メニューバーに表示させているアプリケーションが一部見えなくなってしまっているのですが、そこは妥協点と言えば妥協点かもしれません。

今度こそは5年使えるかも

AppleCare+ for Macのラインナップの中にサブスクリプションプランが加わったのも大きいですね。これまで3年間隔で買い替えていたのは、買い切り型のAppleCareの期限が3年だったからというのもあったのですが、サブスクリプションプランであれば3年以上経過した場合でも保証が継続するので、ビンテージにならない限りは保証が効くというところが個人的にはかなり嬉しいところです。

これからもApple Siliconのチップは進化を続けるのでしょうけれども、相当な仕様変更がない限りは、今度こそはバッテリーの使用頻度を工夫しながらも5年くらい使っても期待通りのパフォーマンスは出続けてくれるのではないかなと思います。

カテゴリー: Private, Work | タグ: , , | コメントする

山形交響楽団 第307回定期演奏会


山形交響楽団が、飯森範親さんの指揮で久しぶりにブルックナーの交響曲第7番を演奏するというので、山形新幹線に飛び乗って山形まで聴きに行ってきました。

本当に素晴らしい演奏を聴くと、感想を書くために何か言葉を紡ぎ出そうとしても、それが全て野暮になってしまうのではないかというほど、素晴らしい演奏でした。

芳醇な弦の響きと重厚感のある管楽器の響きが一体になって、まるで山形テルサホール全体が、ひとつの大きなオルガンのようになったのではないかという感覚を覚えてしまったほどでした。

その質感と音の世界が、いつまでも耳の奥に残ってなかなか抜けることができません。

会心の演奏だったと思います。この忙しい日々の中で素晴らしい音楽を聴くことができることがどれだけ素晴らしいことなのかということを、今もって改めて痛感させられました。そして自分なりに継続して音楽に触れていきたいと思わせてくれる演奏会でした。

飯森範親さんと山形交響楽団の皆さんに感謝です。

カテゴリー: Private | タグ: , , | コメントする

AWS認定ソリューションアーキテクト アソシエイト(AWS SAA-C03)に合格しての感想(C01からの再認定編)


これまで、AWS認定ソリューションアーキテクト プロフェッショナル(AWS SAP-C01)AWS認定DevOpsエンジニア プロフェッショナル(AWS DOP-C01)に合格してきたので、本来は再認定の日までにこの2つの試験を再受験すればいいのですが、AWS認定ソリューションアーキテクト アソシエイトのバージョンがC03まで上がっているということや、ここ最近サーバレスやコンテナのようなモダンアプリケーションを構築するお仕事に関わることが多くなってきたので、それらの経験で得た知識がどこまで付いているのかを効果測定するためにも、受けてみることにしました。

結果は777点で合格。上位資格に受かっていることを考えると、本当は800点以上のスコアを叩き出したかったのですが、出題範囲や分野が前回受けた内容と異なることを考えると、これはこれで納得のいくスコアなのかなぁと思います。

ついでに再認定扱いになったので2024年7月までだった再認定までの猶予期間も2026年2月まで延長させることができました。まずは一安心です。

どのようにして勉強したのか

今回この試験を受けるにあたって何をどのようにして勉強したのかというと、実はほとんど試験対策のような勉強の仕方はしてきませんでした。なぜかというと、前述の通り、前回の受験からの実務経験が本当に身についているかどうかの効果測定が目的だったからです。この試験を受けること自体が完全に手段化していました。なので試験ガイドの内容を確認した程度で、他に試験勉強をしたというのがなかったのです。これまでの経験と知識全てで勝負したという感じで。

強いて勉強らしいことをしたとすれば、「AWSで実現するモダンアプリケーション入門(落水恭介 吉田慶章著/技術評論社)」を3周くらい読みました。この本はAWSが提唱するモダンアプリケーションという考え方に沿って、既存のモノリシックなAWSの構成をいかにして改善させることができるかという考え方について、事例を交えながらわかりやすく書いてくれている良書だと思いますし、試験で出題される分野にかなり近いところを題材として採用しています。自分にとってはこれで十分だったかなと思っています。

ここでは具体的にどのような問題が出たのかについては、行動規範に抵触する可能性があるので言及はしません。ただ強いていうのであれば、だいぶ出題範囲が広くなっているのと同時に、モダンな方向にシフトしているなぁ、という感想は持ちました。

現時点で市販されているAWS SAA向けの試験参考書でC03のバージョンに対応しているのはごく僅かなので、初めてAWS SAAを受ける人にとっては結構大変かもしれませんが、座学だけではなく、実際にハンズオンをして試してみた方が理解は早いかもしれません。実務と紐づいてこその資格なので、手を動かしてみるほうが周り道に見えて実は近道なんじゃないかなと思います。

アソシエイト試験はその内容から、プロフェッショナル試験とは違った難しさがあるのですが、それは相変わらずでしたね。特に初めて挑戦する人は、十分に準備期間を設けてチャレンジしてみるほうがいいのかなと思います。

カテゴリー: AWS | タグ: | コメントする

PritunlとAmazon DocumentDBを使用したVPNの仕組みを構築しようとして失敗した話


はじめに

社内のVPNの仕組みも社員数が増えてくるにつれてそれなりに管理がしやすいような方がいいよね、ということで、仕組み自体を更改するにあたり、VPNサーバを簡単に構築 & 管理することのできるPritunlと、ここが一番肝心なのですが、どうせならPritunlが使用するデータソースをAWS上で構築したいよねということで、Amazon DocumentDBを使用しようという話になり、ちょっとPoCをしてみましたというのがこの記事の趣旨になります。

まぁ最終的にはPritunlのデータソースとしてAmazon DocumentDBが使えない! という結論に至ったのですが、その理由は後述します。

構成

ざっくりと構成図書くとこんな感じになります。他にも社内のルータとかが登場するのですが、それは流石に出せないので、あくまでもVPNサーバとAmazon DocumentDBの関係性だけを記述しています。

Amazon DocumentDBの前段には、Public Subnetにルータとしての機能を持つEC2インスタンスを構築します。可用性はあまり求められないのでシングルAZ(AZ-a)にしていますが、Amazon DocumentDB側でサブネットグループの構築が必須となるため、AZ-cを空っぽの状態で構成しています。

VPS上に構築するVPNサーバは、今回はUbuntu 22.04 LTSを使用しています。

EC2インスタンスからAmazon DocumentDBへの接続確認

構築したEC2インスタンスにmongoDBをインストールして、内部的にAmazon DocumentDBへ接続が可能かどうかを確認します。当然のことながら、EC2インスタンスにはAmazon DocumentDBに対する接続を許可するIAMロールの設定をして、Amazon DocumentDBに対してはインバウンドでEC2インスタンスからのtcp/27017の通信を許可するSecurity Groupのインバウンドルールを設定しています。

まずはEC2インスタンスにmongoDBをインストール。

sudo echo -e "[mongodb-org-6.0] \nname=MongoDB Repository\nbaseurl=https://repo.mongodb.org/yum/amazon/2/mongodb-org/6.0/aarch64/\ngpgcheck=1 \nenabled=1 \ngpgkey=https://www.mongodb.org/static/pgp/server-6.0.asc" | sudo tee /etc/yum.repos.d/mongodb-org-6.0.repo
sudo yum install -y mongodb-org -y

これが完了したら、Amazon DocumentDBに接続するための証明書を取得してきます。

wget https://s3.amazonaws.com/rds-downloads/rds-combined-ca-bundle.pem

そして、以下のコマンドで接続確認を実行します。

sudo mongosh --tls --host <cluster name>.cluster-<cluster identifier>.ap-northeast-1.docdb.amazonaws.com:27017 --tlsCAFile rds-combined-ca-bundle.pem --username <username> --password <password>

実行後、以下のように出力されれば接続は成功です。

Current Mongosh Log ID: <Log ID>
Connecting to: mongosh://<credentials>@<cluster name>.cluster-<cluster identifier>.ap-northeast.docdb.amazonaws.com:27017/?directConnection=true&tls=true&tlsCAFile=rds-combined-ca-bundle.pem&appName=mongosh+1.6.2
Using MongoDB: 4.0.0
Using Mongosh: 1.6.2

(snip...)

rs0 [direct : primary] test>

VPNサーバの構築

AWS側の構築と設定が完了したら、次にVPS上のVPNサーバを構築していきます。

まずはAWS CLIのインストールから。

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

次にPritunlをインストールしていきます。

# まずは既存でインストールされているパッケージを最新バージョンに更新
sudo apt update && sudo apt upgrade

# PritunlとMongoDBをインストール
sudo apt update && sudo apt install pritunl mongodb-org

# インストールしたPritunlとMongoDBを起動
sudo systemctl start pritunl mongod
sudo systemctl enable pritunl mongod

ここまで終われば、あとはPritunlとローカルのMongoDBの起動状態を確認すればOKです。

Pritunlの設定

Pritunlを初期セットアップするためには、セットアップキーの取得が必要なため、以下のコマンドを実行します。

sudo pritunl setup-key

実行すると16進数のセットアップキーが表示されるので、それを控えておきます。

次に、https://<VPNサーバのIP Address>/setup をブラウザで開き、表示されたダイアログにセットアップキーを入力します。

[Save]ボタンを入力すると、管理者のユーザ名とパスワードを作成しろというダイアログが表示されるので、コンソールに戻り、以下のコマンドを実行して管理者のユーザ名とパスワードを作成します。

sudo pritunl default-password

ここで出力されたユーザ名とパスワードを控えておきます。

もしもVPNサーバのローカルに構築されたMongoDBを使用してPritunlを使用する場合は、ここで構築は完了なのですが、ここで、一旦VPNサーバからDocumentDBに接続が可能かどうかを、EC2インスタンスから接続確認した時と同じ手順で接続を確認します。

sudo mongosh --tls --host <cluster name>.cluster-<cluster identifier>.ap-northeast-1.docdb.amazonaws.com:27017 --tlsCAFile rds-combined-ca-bundle.pem --username <username> --password <password> --tlsAllowInvalidHostnames

ここまでは普通に成功するはずです。

PritunlのデータソースとしてAmazon DocumentDBが使えないことが発覚

ここで、/etc/mongod.confのデータベース接続文字列を修正して、Amazon DocumentDBを向くように設定したのですが、ここでInternal Server Errorが発生。/var/log/pritunl.logに以下のような大量のエラーが吐かれます。

[undefined][2023-01-20 09:38:17,828][INFO] Starting setup server
[undefined][2023-01-20 09:38:18,153][INFO] Generating setup server ssl cert
[undefined][2023-01-20 09:38:22,654][ERROR] Pritunl setup failed
Traceback (most recent call last):
  File "/usr/lib/pritunl/lib/python3.10/site-packages/pritunl/setup/__init__.py", line 43, in setup_all
    setup_mongo()
  File "/usr/lib/pritunl/lib/python3.10/site-packages/pritunl/setup/mongo.py", line 446, in setup_mongo
    mongo.secondary_database.create_collection(
  File "/usr/lib/pritunl/lib/python3.10/site-packages/pymongo/database.py", line 425, in create_collection
    return Collection(self, name, True, codec_options,
  File "/usr/lib/pritunl/lib/python3.10/site-packages/pymongo/collection.py", line 187, in __init__
    self.__create(kwargs, collation, session)
  File "/usr/lib/pritunl/lib/python3.10/site-packages/pymongo/collection.py", line 264, in __create
    self._command(
  File "/usr/lib/pritunl/lib/python3.10/site-packages/pymongo/collection.py", line 238, in _command
    return sock_info.command(
  File "/usr/lib/pritunl/lib/python3.10/site-packages/pymongo/pool.py", line 710, in command
    return command(self, dbname, spec, secondary_ok,
  File "/usr/lib/pritunl/lib/python3.10/site-packages/pymongo/network.py", line 161, in command
    helpers._check_command_response(
  File "/usr/lib/pritunl/lib/python3.10/site-packages/pymongo/helpers.py", line 167, in _check_command_response
    raise OperationFailure(errmsg, code, response, max_wire_version)
pymongo.errors.OperationFailure: Feature not supported: capped:true, full error: {'ok': 0.0, 'code': 303, 'errmsg': 'Feature not sup
ported: capped:true', 'operationTime': Timestamp(1674175102, 1)}
[undefined][2023-01-20 09:38:22,658][INFO] Stopping server

該当するコードを調べてみたのですが、Pritunl側では、セットアップ時のmongoDBに対する設定として、上限付きコレクションが Trueになっているのですが、Amazon DocumentDBの仕様ではFalseになっており、変更不可であるため、セットアップそのものができない状態になってしまっているのでした。万事休す。

というわけで、PoCはここで泣く泣く終了になってしまいました。この辺のPoCに関してはなかなかまとまったドキュメントがないので、ここに至るまでに結構時間を溶かしてしまいました。Pritunl側のUpdateを待つか、Amazon DocumentDB側で上限付きコレクションの設定がサポートされるかどうか、今はちょっと待ちの状態ですね。

ただ、どちらかがサポートされれば、AWSのリソースで効率的にVPNサーバの管理ができるようになるかもしれません。

カテゴリー: AWS, Work | タグ: , , | コメントする

2022年のフライトログとBronzeステイタス継続


はじめに

去年からANA Bronzeのステイタスに到達したのですが、今年もそれを継続すべく、まぁ飛行機にはよく乗りました。多分年間7往復したのは初めてなんじゃないかなと思います。

というわけで簡単なフライトログをば。

フライトログ

  • 2022/1/15 NH245 HND → FUK (B788 / JA802A)
  • 2022/1/16 NH258 FUK → HND (B788 / JA831A)
  • 2022/2/25 NH243 HND → FUK (B788 / JA838A)
  • 2022/2/26 NH256 FUK → HND (B788 / JA831A)
  • 2022/6/17 NH019 HND → ITM (B788 / JA840A)
  • 2022/6/19 NH024 ITM → HND (B788 / JA815A)
  • 2022/7/9 NH677 HND → HIJ (A321 / JA139A)
  • 2022/7/9 NH684 HIJ → HND (A321 / JA151A)
  • 2022/10/17 NH055 HND → CTS (B763 / JA608A / 鬼滅弐号機)
  • 2022/10/19 NH070 CTS → HND (B788 / JA810A)
  • 2022/11/12 NH395 HND → SYO (B738 / JA63AN)
  • 2022/11/12 NH400 SYO → HND (B738 / JA72AN)
  • 2022/12/3 NH245 HND → FUK (B772 / JA745A / 鬼滅参号機)
  • 2022/12/4 NH252 FUK → HND (B788 / JA818A)

相変わらずB788には乗っていますね。もうすでにANAの主力機になっているので幹線に搭乗しようとすると大概にしてB788に当たりますが、好きな飛行機なので全然問題ありません。まさかのまさかだったのが、3機就航している「鬼滅の刃」コラボ機に期せずして2機登場してしまったこと。ラッキーと言えばラッキーなのかもしれませんが、あの機内アナウンスはちょっと恥ずかしいですね。でも個人的には楽しめたのでよしとします。

そういうわけで2年目のANA Bronzeステータスに突入

そんな感じで乗りまくったので、年末には今回もANA Bronzeのステータスを獲得することができました。2年目になるので来年はマイルの積算率が上がりますね。欲を言えばDiamondまでいきたいところですが、そこを目指そうとすると海外に行くことも視野にいればければいけないので、ご時世柄このままBronzeを継続していければいいのかなと思っています。あまり欲は出しません。

なんやかんや言っても飛行機の旅は大好きなので、来年も無理のない範囲で乗りまくる所存であります。

カテゴリー: Private | タグ: | コメントする

PSY・Sとわたし – “Wondering Up and Down”


きっかけ

PSY・Sの元ボーカルで、現在はジャズヴォーカリストとして活躍しているCHAKAさんのこんなツイートを読んだんですよね。

色々考えるきっかけになったCHAKAさんのツイート

もちろんファン的には一体どんな批評を読んだんだろう、というのが気になったりもしたのですが、その批評に左右されることなく、これからも高みを目指していこうとしている決意表明をしているCHAKAさんの力強い言葉に、すごいなと思ったのでした。PSY・Sは全盛期が自分の多感な高校生という時代と同期しているので、それだけに思い入れがあって、色々と考えてしまったわけです。

あれやこれや

PSY・Sというアーティスト名を聴いて、あ、あの人かとわかる人は、おそらく同世代ですね。1985年にデビューし、1996年に解散した、ヴォーカルのCHAKA(安則まみ)さんと楽曲全般の演奏を担当する松浦雅也さんからなるユニットです。

その当時最先端の技術を駆使をして、先進的かつポップな世界観を全面に出した楽曲をいくつも発表してくれて、そのオリジナリティにはワクワクしたものです。昔話ですけれどもね。もう解散して25年以上が経過しているのか。今でもかなりのヘビーローテーションで聴く続けているんですけれども。

PSY・Sを知ったきっかけは高校の先輩がカセットデッキで部活の時間に流していたのをきいたところからだと思います。オリジナリティあふれる楽曲と、なんといってもCHAKAさんのまっすぐなハイトーンボイスが突き刺さったんですよね。あの歌声はそんじょそこらじゃ忘れられません。

その頃の音楽シーン、正直ヒットチャートは全く追いかけていなかったですね。むしろ、多数創刊されていたFM雑誌からアーティスト情報を知ったり、いま(当時)渋谷系という音楽が一部で流行っていて、それを試しに聴いてみよう、という感じで、FM放送を媒介としてさまざまなジャンルの音楽に触れられる機会がいま以上に幅広かった気がします。

で、その中でなんでPSY・Sなのかって、一つ一つの楽曲が粒が際立っているというか、ポップなんだけれどもただのポップでは済まされない、良い意味での「変てこりんさ」があったところなんですよね。それでいて聴き飽きることが全くないんです。耳障りの良さだけではなくて、少し角が立っているところが。そこにCHAKAさんの力強い歌声が乗ってきて、不思議な化学反応が起きていたなと。CHAKAさんの歌声もまっすぐさが半端なくて、思わず聴き入ってしまう魅力があったのです。

解散の理由は正直覚えていないなぁ。ただかなりショックではありました。CHAKAさんの立場と松浦さんの立場、それぞれに何かしらの思うところがあったのではないかと思うんですが、あの二人だからこそできた音楽がそこにあって、新作の中でどんな世界観を披露してくれるかが本当に楽しみだったので。

一番好きな曲

これはこのBlogを吹っ飛ばす前の記事でも書いたのですが、“Wondering Up and Down 〜水のマージナル〜”が本当に好きで、今でもずっと繰り返し聴いています。自動的に自分の子供時代を思い起こさせてくれるような抒情的なメロディライン。ベースラインが同じなのにメロディとサビとで全く違う表情を見せてくれるところ。目を瞑ればその景色がすぐに想像できるような優しい歌詞。そしてその世界をクリアに歌ってくれるCHAKAさんの歌声。

歌詞は水にまつわる様々な情景をシーンごとに切り替えていく構成になっているんですけれども、それがメロディと組み合わさった時の化学反応が半端ないというか。具体的にこうとかまでは書けないのがなかなか悔しいんですけれども、こういう初夏の風景があると本当に素敵だよなということを思い起こさせてくれるような感じです。

またあれやこれや

サブスク時代が前世の今の時期、歌い出しのインパクトや貴キャスさがとにかく優先されるようになってきてしまったような気がしますが、PSY・Sの音楽の世界はその真逆をいくように、じっくり聞けば聴くほどその世界観がふわっと広がっていく印象を受けます。その広がりが本当に素晴らしいんですよね。それはCHAKAさんの歌声がどうだからとか、松浦さんの作曲が素晴らしいからとかではなくて、それらが融合しているからこその魅力なんだと思います。

多分、”Wondering Up and Down 〜水のマージナル〜”は、ずっとずっと聴き続けているんだろうなと思います。音楽が与えてくれる多幸感が得られる限りは。あの歌声になんと心を癒されたことか。

カテゴリー: Private | タグ: , | コメントする

コミュニケーションコストと手間暇について僕自身がいま考えていること


はじめに

この記事は #Backlog アドベントカレンダー2022 by #JBUG の12/18分の記事として執筆しています。

コミュニケーションコストとは?

現在勤めている会社は渋谷にオフィスがあり、この記事を書いている直近ではだいたい50%くらいの社員がリモートワークをしています。僕もそのうちのひとりで、オフィスに出社するのは1週間から2週間に1回くらい。その他は主に自宅で仕事をしています。コアタイム制ですが、多くの社員の勤務開始時間は割と遅めな感じな一方で、朝早めの時間から勤務を開始しているメンバーもいます。

そういう環境の中で、ほとんどオフィスに出社しているメンバーの人からちょくちょく「リモートワークだとコミュニケーションコストがかかるから」という言葉を耳にすることがあります。具体的な例としては、オフィスに出社していればちょっとした相談事でもその人の席まで行って話をすればすぐに解決できることが、リモートワークだとタイムラグややり取りに関する時間的なコストが発生して、解決に至るまでのスピードが遅くなる、といったところが代表的でしょうか。そこにコストがかかることに課題を感じているようです。

いや、仰っていることはよくわかるんですよ。確かにオフィスの中をとことこ歩いていって相談相手と対面で話すことの方が、時間的なロスは少ないし、相手の表情を見ながら話すことができるので、解決までの道のりは、もしかしたら早いかもしれません。

だがしかし待てよ、「コニュニケーションコスト」って果たしてそういうものなのかしら? というところに個人的には疑問を感じてしまいます。

コミュニケーションにかける手間暇についての僕の思うところ

上記に関する「コミュニケーションコスト」というのを時間的な価値だけにフォーカスするのであれば、確かにそれはスピード感を持って意思決定をする上ではみんなが同じ場にいて同期的に話を進めていけばいいかもしれません。その方が手間暇は全然かかりませんし。

ただ、「コミュニケーションコスト」は、逆に手間暇というか、ちょっとした工夫を使いながらかけるべきでもあると僕は思うのです。

ここでは例としてBacklogとSlackを挙げてみましょう。

Backlogを通じたコミュニケーションに対してかける手間暇

この記事を読んでいる皆さんの中には何かしらのチケット管理ツールを使用してプロジェクトを進めている方が比較的多いのではないかと思います。僕の会社でもBacklogを使ってプロジェクト管理を行なっています。なんですけれども、Backlogの機能を十分に使いこなせていないなと思ってしまう事例が少なくないのです。ひとつひとつの起票された課題(親課題や子課題を含めて)に対して、それがなんのために起票されているのかという意味合いを持たせていないケースが散見されるのです。結果としてどういうことが起こるかというと、後から見返したときに「このBacklogの課題って何のために起票されたんだっけ?」という「コミュニケーションコスト」が発生してしまうわけです。これはあまり建設的なコストではないですよね。

もちろん、Backlogにはこれが鉄板というルールブック的なものはないわけですけれども、起票された課題に対して意味合いを持たせ、その課題が結果としてとのような状態になったかを育てていった方が、ツールを使っていく上での価値がダントツに上がるわけです。少なくとも、課題の本文やコメントに、

  • なぜこの課題を起票したのか (= 課題が示している目的を明確にする)
  • どういう状況になっていればその課題はクローズできるのか (= 課題の完了条件を明確にする)
  • 課題のステータスを変える時には、その理由 (= 完了に向けて具体的にどのようなアクションをとっているのかを明確にする)

これらが書かれていれば、課題に対する活動の履歴がはっきり残るため、「この課題って何だっけ?」状態は確実にクリアできると思っています。逆に言えば、「コニュニケーションコスト」を軽減するための材料を、少し手間暇をかけることで用意することができるわけです。これは明らかに建設的な手間暇であると考えることができると思うのです。

Slackを通じたコニュニケーションに対してかける手間暇

同じように、日常の仕事の中での課題の共有や調整などを、Slackのようなチャットツールでやり取りしている例も多いのかなと思います。

SlackはBacklogのようなストック型のツールではなく、フロー型のツールとも言えます。フロー型である以上は、短いスレッドで完結させる方が良いに越したことはないのですが、必ずしもその通りにならないことが往々にしてあるのは皆さんもよく経験されているのではないかと思います。その原因として考えられるのが、やはり書き込まれている最低限の情報が網羅されているか、なのかなと考えています。網羅すべき情報は、Backlogの場合とほぼ同じで、

  • そのスレッドを通じて共有したいことや質問したいことは何か (= 目的を明確にする)
  • 情報共有の場合、伝えたい相手に対して何を理解してもらいたいか (= 完了条件を明確にする)
  • 質問の場合、結果としていつまでにどんな情報が欲しいのか (=完了条件を明確にする)

これらが書かれているだけでも、情報を伝えたい相手に対して余計な「コニュニケーションコスト」を発生させることなく、建設的に物事を進めたり、調整したりすることができるわけです。そのための手間暇としても建設的なのではないかなと思います。

時間的なコストを削減するためにも手間暇を少しかけよう

ここでは2つの例を書いてみましたが、「コミュニケーションコスト」というのは、単純に時間だけで評価できるものではなく、その人の持っている情報がどれだけ多くの人に対して正しく共有できるかというのも重要な評価軸なのではないかと思います。オフィスにいて、ちょっと誰かと相談すれば、2者間では情報の共有がすんなりいくかもしれませんが、そこで得られた情報を多くの人に共有できるかと言えば、実は共有できなかったりしますよね。その結果、「これって何だっけ?」「確かこういうことだった気がする」というようなやりとりに発展して逆に時間的なコストをかけてしまうことになることもあったりするわけで。

それを補完するのがプロジェクト管理ツールやコミュニケーションツールの役割であるわけで、そこに少しだけ手間暇をかけてあげることで、有益な情報共有の手段として育てていくことができるのだと思います。そして育てることによって、いつかプロジェクトや会社の事業にとっても大きな資産となり得ます。

非同期的なコミュニケーションが主流になっていく中で、まずはほんの少しだけでもいいので、手間暇をかけてみませんか? その一歩を踏み出すだけでも、案外「コミュニケーションコスト」の罠から抜け出すことができるかもしれませんよ。

カテゴリー: Work | タグ: , , , | コメントする

MacBook Air M2にHomebrewをインストールする方法 (macOS Ventura版)


はじめに

2022/10/12にMacBook Air M2を購入しまして、その後あまり何も考えずにmacOS Ventura 13.0にアップデートしてしまってのですが、セキュリティ周りの仕様が変わったせいなのか、こんな感じでHomebrewがインストールできない事態に。

% /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
==> Checking for `sudo` access (which may request your password)...
Password:
==> This script will install:
/usr/local/bin/brew
/usr/local/share/doc/homebrew
/usr/local/share/man/man1/brew.1
/usr/local/share/zsh/site-functions/_brew
/usr/local/etc/bash_completion.d/brew
/usr/local/Homebrew
==> HOMEBREW_BREW_GIT_REMOTE is set to a non-default URL:
/opt/homebrew will be used as the Homebrew/brew Git remote.
==> HOMEBREW_CORE_GIT_REMOTE is set to a non-default URL:
/opt/homebrew will be used as the Homebrew/homebrew-core Git remote.

Press RETURN/ENTER to continue or any other key to abort:
==> /usr/bin/sudo /usr/sbin/chown -R vlayusuke:admin /usr/local/Homebrew
==> Downloading and installing Homebrew...
fatal: '/opt/homebrew' does not appear to be a git repository
fatal: Could not read from remote repository.

macOSの場合、いつの頃からかHomebrewがインストールされるデフォルトのディレクトリが /opt/homebrew に変わったのは知っていたんですけれども、それがGitのrepositoryではないってどういうこと? と思って悪戦苦闘していたんですが、なんとか解決したのでそのメモです。

TerminalをRosettaで起動させるようにする

  • ターミナル.appをFinderから選択
  • ⌘ + iするか、Finderの[ファイル]-[情報を見る]でターミナル.appの情報を表示
  • 「Rosettaを使用して開く」にチェックを入れる

Apple SiliconのMacでも、Intel プロセッサ搭載 Macとの互換性を保たせるためにこれはどうしても必要な設定になります。まずここでApple SiliconのMacBook Air M2でCLIを使うための最低限の準備をします。

Homebrewのリポジトリ設定をリセットする

元々MacBook Air M2のデータは代々引き継がれてきたMacBook Air Intel 2018のものを使用していたので、Homebrewのリポジトリ設定がおかしくなっていたかもしれないので、GitHubのHomebrewに関する同じ現象のディスカッションを参考に以下のコマンドを実行。

% unset HOMEBREW_BREW_GIT_REMOTE HOMEBREW_CORE_GIT_REMOTE

すると、これまでの苦労が何事もなかったかのようにHomebrewのインストールを、公式に書かれているような

% /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

を使用してインストールすることができました。やれやれ。

ちなみにこれ、macOS Venturaにしたからこのようになっているというわけではなくて、Apple Silicon搭載のMac共通で、Homebrewを使用するために実行しておく必要があるおまじないみたいですね。

何はともあれ、開発をしていくにあたって必要なHomebrewが使えるようになり一安心したのでした。

カテゴリー: Private, Work | タグ: , , | コメントする