@kyanny's blog

My thoughts, my life. Views/opinions are my own.

2024 J3 第7節 ⚽️奈良クラブ🆚ツエーゲン金沢 #zweigen

3-3 で引き分け。先制するも追いつかれ、突き放し、また追いつかれ、今度は逆転され、しかし後半アディショナルタイムに追いつくという手に汗握る展開。乱打戦だったが、なんとか勝ち点 1 をもぎ取った。

金沢駅前のアイリッシュパブ ZOWIE で観戦。キックオフ間近に到着したらすでにけっこう入っていて空いてるテーブルは残り少なかった。ここは 225BAR と比べるとだいぶ小さい店でプロジェクターもなかったが、チャージなしでドリンク一杯からで OK なのでリーズナブルだった。顔見知り同士のお客さんも多く、アットホームな雰囲気だった。ツエーゲンの試合を観にきたわけではなさそうな外国人観光客がほんとにフラッと立ち寄って一杯飲んで去っていった。パブ文化みたいなものを感じた。

今日は奈良がゲームをしっかり組み立てて鋭い攻撃をみせ、一方の金沢はロングボールやカウンターからチャンスを逃さず決めに行く形。言うなれば奈良が格上のサッカーをし、金沢が格下のサッカーをした試合だった。それでも金沢が先制して二度もリードしたのだからわからないものだ。前節の相模原戦でしっかり組み立てるサッカーで勝ち、今節もスタメンをほぼ変えずに臨んだのでてっきり同じやり方をするのかと思ったらガラッと違ったので驚いた。

今日は MF 梶浦が大車輪の活躍だった。1 得点 2 アシストで 3 得点すべてに絡んだ。2 アシストはいずれも個の強さを見せたし、コーナーキックからダイレクトに決めたシュートは位置どりもコースも見事だった。1 点目は梶浦のクロスが奈良の選手に当たってコースが変わり、それで中央にいた奈良の DF が体勢を崩されたのもあって奈良にとってはアンラッキーだったが、その前に梶浦が後ろからのパスを空中でトラップして前に落としながら相手選手を抜いてスピードを落とさず右サイドに切り込んでいったプレーは素晴らしかった。

守りもスリーバックは開幕三試合とは比較にならないほど安定感が出てきた。後ろからの組み立ても危なっかしさが減ってきたし、2 点目の起点になった DF 畑尾のロングフィードなどのオプションも精度が増して怖さが出てきた。ただ、今節は右サイドを徹底的に攻められ、結果的にそこを崩され続けた。DF 櫻井が攻撃的で積極的に前に上がって攻めるぶん、その裏をやられた。3 失点すべてが右サイドからのクロスに合わせられる形。ミス起因ではなく、シンプルに相手が上手く、崩された。ただ、金沢の 2 点目は櫻井が右サイドの高い位置で受けてインターセプトされたこぼれ球を梶浦が詰めて拾って前に切り込んでクロスという流れで、櫻井の攻め上がりからの得点だったわけで、良さは出ていたし結果にも繋がった。攻撃的な右サイドは金沢のストロングポイントでもあり、ウィークポイントでもあるといえる。

大谷・土信田も決めるべきシーンで決めて、FW としてきっちり仕事をした。大谷はゴール前フリーで、あれを外したら戦犯扱いもやむなしという感じではあったが。土信田が初得点後にゴール裏の金沢サポに駆け寄って頭をくしゃくしゃにされてるシーンは良かった。攻撃といえば櫻井がカウンターで相手キーパーと一対一というシーンがあったが、あそこはパスではなくシュートで勝負して欲しかった。3 点目の梶浦が素晴らしかった件はもう書いたが、毛利のコーナーキックも素晴らしかった。後半遅くからの出場でほぼあのワンプレーくらいしか仕事をするチャンスがなかったと思うが、そこで期待に応える本番強さを見せた。アディショナルタイムが 6〜7 分と長かったのも追う金沢に幸いしたが、最後まで諦めずに執念で泥臭くプレーしたからこその勝ち点 1 だった。

今日も金沢サポの応援は DAZN 越しに大きく聞こえていた。梶浦のインタビューで応援に注文がついたとかいう話を SNS で見かけたが、ゴースタでおれも似たようなヤジっぽい声援を聞いたことがあるので、まあ言いたくなるサポーターの気持ちもわかるし、それを快く思わないサポーターの気持ちもわかる。サッカーの応援は良くも悪くも統率が取れているものだという共通認識が出来上がりつつあるので、ヤジっぽいのは浮くよなあという印象。

試合後のインタビューで梶浦は「勝てる試合だった」と言っていて、確かに先制もしたし金沢がリードする展開ではあったが、内容的には互角、むしろ奈良のほうが良かったくらいで、決してイージーな相手ではなかったと思う。これが金沢の現状だということを忘れずに、次節に臨んで欲しい。第 8 節はホームで松本山雅戦。松本サポが 3,000 人以上来るらしい。果たして金沢のファン・サポーターは人数で勝ることができるのか。次はゴースタ初のゴール裏で観戦予定。

Bizmates Program: Level 4 Rank D Lesson 11: A Matter of Safety

初めての女性トレーナーと。My Bizmates のおすすめに出てきて、「とても几帳面な教師で細かく間違いを直してくれます。厳しく聞こえるかもしれませんが〜」と書いてあったので、最近そういうタイプとあまりやってないなと思いチャレンジすることに。レッスン回数四万?五万?を超えるキャリアみたいだけど今まで一度も見かけたことなかったな。時間帯とかが全然合わなかったのか、予約がいつも埋まってるタイプなのか。

こちらから聞く前に「私は元気です。あなたは?」今日はちょっと仕事で感情労働だなあと感じることがあったので愚痴を聞いてもらったり。This case is emotionally demanding to handle / = this case is emotionally draining to handle その他の表現

  • It is very tempting to say
  • They feel entitled. = They feel privileged

そういう経験は自分を成長(成熟)させてくれる、Put it down to experience .

Lesson 11 の冒頭から。words & phrases、「二つ選んで自分のセンテンスで使ってください」これを、ミス 15 点の「二つを一つの文に」と勘違いして、だいぶ難しいなあと悩んでたら「どの二つを選びますか?」と助け舟、これとこれを使うつもりなんだけどどうやって繋げたらいいか・・というと「ノーノー、繋げる必要はないですよ」あそっか、ということで Blackberry was a popular cellphone but now it's antiquated. 「perfect」と言ってもらえたかな、ところで Blackberry って知ってますか?「聞いたことありますよ」よかった、知らなかったら何のこっちゃだよなあと思ってました。

もう一つは don't give your team mate a hard time by expressing disagreement impolitely ここから、日本社会では根回しが重要で、という話が長く続いた。根回しってなんていうんだろう、と思ってたら CLOSED-DOOR meetings とか make an under-the-table agreement とかの表現を教えてもらった。まあニュアンスとしてはそういうことだよね。

  • There is a closed-door meeting prior to the actual meeting
  • This sort of behavior is unacceptable in a meeting

若い頃は根回しとかは正々堂々としてなくて良くないことだと(dishonest - underhanded)思ってたけど、前に勤めてた会社でマネージャーとして他のマネージャーと色々微妙な問題を色々妥協しながら解決して物事を前に進めなきゃいけないという状況で、根回しの重要性を学んだよ。という話をしたら、This kind of thing is a necessary evil とピッタリの表現を。そうそう、まさに必要悪って言いたかったんだけど、そのまんまでよかったのか。

ここでレッスン終了、次はなぜか TRY からと言われたけど、See を一切読んでないし中身と関係ある話もしてないので、次のレッスンで See からやりますと申し出ないと。この人は割と落ち着いた雰囲気で、確かに直しは口頭でもチャットでも多いけど、そこまで神経質で面倒臭いという印象ではなかったなあ。話の流れを切らずに自然に訂正や別表現の提案をしてくる感じ。喋るスピードはいい感じに早く、英語も結構綺麗な印象。

Bizmates Program: Level 4 Rank D Lesson 10: Review: Gender Culture

マージナルオペレーションのキャラクターと同じ名前の人、つまりミスマジオペと二回目のレッスン。今日も全力で cheerful な感じ。「また予約してくれて嬉しいわ、今日はどんな日だった?」いい気分です、花粉症の季節なんだけど今日は鼻の調子が良いので。花粉症の話から、体調悪いときは自分の判断で長めに休憩したり仕事を切り上げたりできるフレキシブルさが今の会社の文化だという話をしたり。

Lesson 9 のレビューから。リーダーシップ。このレッスンのとき話したのと同じ、リーダーシップのスキルとかリーダーとしての素質は性別は全く関係ないが、リーダーシップが効果的かどうかを考える上ではフォロワーの属性も考慮する必要がある。若い女性リーダーが年配の男性が多いチームを率いるような状況では、年配の男性の反応は厳しいものや懐疑的なものになるだろう。それは、自分より年上の男性上司ばかりだったとかの個人的な経験や、若いこと、女性であることなどへの偏見バイアスに基づいている。リーダーは素質と資格があるからなったのだし、みんないずれそれを理解して受け入れるだろうけど、最初はリーダーにとって難しい状況かもしれない。これが、大企業の役員だった年配の男性がリーダーになる、という話なら、きっともっとすんなり受け入れる人が多いだろう。そういうのはやっぱり起こりうるよね、と。

patriarchal = relating to or characteristic of a system of society or government controlled by men 男性上位の、という言葉を教えてもらった。

二つ目の質問、あなたが考える効果的なリーダーシップスタイルとは。以前勤めてた会社で 50 人の部署を任されていたとき、大事にしてたのは透明性。特に、言えないことの伝え方。人事に関わることとか、全員に共有できない情報というのはある。そういうのは、知らないと誤魔化したり、質問に答えないというのと、知ってるけど事情があって言えないのだというのでは、情報を伝えないという点では同じだけど、全然違う。そういうところをちゃんとやるように気をつけていた。「あなたのアプローチは discernment - judgment と言えるのかもね」みたいなことを言われた。

残り五分切ってたが Activity 2 へ。これはまたふわっとした質問で・・これまで学んだ観点に関連して、性別に起因するあなたの経験が職業人生に影響したことは?みたいな質問。時間も少なめだったし話しながら考える感じだったが、男性であることによって仕事上で不利益を感じたことはない。学生時代、運動が苦手だったので、自分は良い印象を持たれてない、人気者ではないという自覚があった。学生時代は運動ができる男子が人気者だったから。男性であることによる辛い経験ってのは、それくらいしかない。でもこれまでいた職場では、女性が男性と全く平等に扱われていたとは言わないけど、でも女性も相応の敬意を払われていたと思う。セクハラとかパワハラとか見聞きしたこともなかった。自分のこれまでの職場が良い環境ばかりで恵まれていただけかも。だから、この性差の話を考えるときに思い浮かぶことが二つあって、一つは「自分は性別によって何か不利益だったりした経験はないし、不公平が行われている現場を見聞きした経験もないなあ」、もう一つは「それは自分が男性であるがゆえにあらかじめ優遇されていて恩恵を受けているから、世の中にある不公平に気づいてないだけなのでは」という二つ。

ここまででレッスン終了、無事に Lesson 10 が終わって、次は Lesson 11 から。今回もこの人は早口でよくしゃべった。

getsentry/action-github-app-token の注意点

GitHub App の installation access token 発行に必要な処理をカプセル化している action-github-app-token という便利なアクションが Marketplace で配布されているが、GitHub App を複数のアカウントにインストールしている場合にハマることがある。

ハマった状況: テスト用の GitHub App に repo contents read/write permission を付与して、自分のユーザーアカウントと organization アカウントにインストール済みの状態で、以下のようなワークフローを実行すると、checkout-user-private-repo ジョブが常に失敗する(Not Found というエラー)。不思議なのは、このワークフローを開発していた当初はこのジョブは成功していて、checkout-org-private-repo ジョブを追加したりと開発を進める過程でいつの間にか失敗するようになった。失敗し始めてからは、checkout-org-private-repo ジョブをコメントアウトしても依然として失敗し続ける。

jobs:
  checkout-user-private-repo:
    runs-on: ubuntu-latest
    steps:
      - name: my-app-install token
        id: my-app
        uses: getsentry/action-github-app-token@v3
        with:
          app_id: ${{ vars.APP_ID }}
          private_key: ${{ secrets.APP_PRIVATE_KEY }}
      - name: Checkout private repo
        uses: actions/checkout@v4
        with:
          repository: ${{ github.event.inputs.repo }}
          token: ${{ steps.my-app.outputs.token }}

  checkout-org-private-repo:
    runs-on: ubuntu-latest
    steps:
      - name: my-app-install token
        id: my-app
        uses: getsentry/action-github-app-token@v3
        with:
          app_id: ${{ vars.APP_ID }}
          private_key: ${{ secrets.APP_PRIVATE_KEY }}
      - name: Checkout private repo
        uses: actions/checkout@v4
        with:
          repository: ${{ github.event.inputs.org_repo }}
          token: ${{ steps.my-app.outputs.token }}

この謎の挙動は action-github-app-token アクションの実装に起因している。具体的にはたぶんここ。GitHub App の installation のリストを取得して、そのリストの先頭の installation id を使うようになっている。つまり、どの installation に対する installation access token を発行するかは、installation のリストの並び順に依存する。

なぜ先ほどのジョブが途中から失敗するようになったのか、これで説明がつく。この GitHub App を、まず最初に自分のユーザーアカウントにインストールした。その時点では installations[0] はユーザーアカウントへの installation だったので、ユーザーアカウントのリポジトリにアクセスできる installation access token が発行され、ジョブはうまく動いていた。次にこの GitHub App を organization アカウントにインストールした。この時点で installation[0] は organization への installation に変わったため、発行される installation access token は organization のリポジトリにはアクセスできるがユーザーアカウントのリポジトリにはアクセスできなくなった。ワークフローを編集しても installation のリストの順番は変わらないので、ジョブはずっと失敗し続けた。

試しに organization への installation を suspend してワークフローを再実行すると、This installation has been suspended という非常にわかりやすいエラーメッセージが表示された。organization への installation を削除してワークフローを再実行すると、無事に checkout-user-private-repo ジョブが成功した。

getsentry/action-github-app-token は GitHub App のトークンを発行するアクションの中でポピュラーなものの一つで、一番人気の GitHub App token や GitHub 謹製の Create GitHub App Token と比べて使い方が簡単なので気に入っていたが、簡単なぶん細かい制御が効かないという落とし穴があり、今回見事にハマった次第。

そもそも一つの GitHub App を複数のアカウントにインストールして使い回すこと自体がバッドプラクティスなのかも、と書こうとして、いやいや GitHub App ってそういう使い方をするためのものでしょ?と思い直した。これはやっぱり実装が雑、もといシンプルな用途のためのアクションなので、その辺を理解して使うべきということだな。

UPDATE:

やはりというか、すでに同様の問題が報告されていた。

で、scope というパラメータでインストールしたアカウントを指定すれば、installation[0] 決め打ちではなく正しい installation を参照するようになるので、この問題を回避できるとのこと。ソースを読み直すと確かにそういう実装になっていた。

インストールしたスコープがリポジトリ単位の場合にまだバグがあるが、プルリクエストが何年もマージされていない。

つい最近も同じハマり方をした人がいて修正のプルリクエストを送っていた。なんか見覚えあるアイコン・ユーザー名だなと思ったら同僚だった(普段直接の絡みはないが)。

昔から何をやるにも要領が悪くて、他人がどのくらいテキパキやってるのか知らないけどたぶん人の何倍も時間と労力を費やさないと同じだけの成果を出せなかった。趣味の勉強みたいな分野は特にそうで、だからこそいまだにろくな成果も挙げられていないわけだが、ここ数年は仕事の後や休日にそういった活動にエネルギーを費やすことが非常に難しくなってきて、ただでさえその気になって行動に移せる機会が貴重なのに、要領の悪さが状況を悪化させて、実に細々とした考え得るありとあらゆる罠やつまづきに遭遇してガンガンエネルギーを消耗させられ、一晩の可処分時間では本来やりたかったことをほとんどまったく実現できなかった、というようなことが何度も起こっている。何度も起こればそれで一年分くらいの機会をドブに捨てていることになり、ため息しか出ない。