さわらブログ

さわら(@xhiroga)の技術ブログ

感想 - ク・ジョンイン「秘密を語る時間」 - 一人の社会人として性被害に向き合うには

本屋さんでふと気になって手に取った漫画で、どちらかといえば薄く、数十分で読める漫画です。
ですが、本当に一生かけて向き合いたい本になりました。すでに5回近く読み、3時間以上この本について考えています。

f:id:hiroga_cc:20211123232257j:plain
ク・ジョンイン「秘密を語る時間」 - 表紙

初めに言ってしまうと、5歳のときに性被害に遭った女の子の話です。友人が、あるいは自分の娘が、将来またはすでに、公園や学校やその他の状況で性被害に遭っているかもしれない。そうした社会に対して、責任ある態度を取るにはどうしたらいいか?考えるヒントになる本でした。

読んでほしいので内容は書きません。
主人公のウンソ(韓国の話ですが、それが読書中に気になることはありません)が、後から涙が出てきたり、孤独を感じたり、友人の働きかけに嬉しく思ったり、産婦人科の先生が本当にいい人であったり、母親が戸惑ったりを、ハラハラ・ドキドキしながら読みました。

何らかの被害に遭った人に寄り添うとき、同じ経験のない自分では力不足ではないだろうか?といつも考えていました。
でも、相手の感じた戸惑い・悔しさ・いらだち・復讐・諦め・孤独の一つづつに共感することはできそうです。この「秘密を語る時間」で主人公ウンソの気持ちに共感できたので、今後の人生でそうした局面にあったとしても、相手の中のつらい気持ちに向き合えそうです。

f:id:hiroga_cc:20211123232203j:plain
ク・ジョンイン「秘密を語る時間」 - ページ28


「秘密を語る時間」を読んで考えたのは、性被害に遭った方に対しては、「あなたは悪くない」...私の言葉で言い換えるなら、「あなたが許していないことを、あなた同様私も許さない」「一人で何だったかを考えてきた時間の不安や悲しさが、いま私も同様に悲しい」...という共感が、もしかしたら本当に生き死にを分かつかもしれない、ということです。
例えば突然ろれつが回らなくなった人がいたら、救急車を呼ばなければ脳梗塞で後遺症が残ってしまうように。

なぜ共感かといえば、性被害と戦う(公にするかどうかに関わらず、自分の中で)のはものすごく準備がいりそうだからです。

まず、被害が何だったのかを整理するのが大変だと思います。そもそも私を粗末に扱う人間がいる、ということを確信するのが大変です。さらに、なんとなく気持ち悪いのなんとなくを言語化するのも難しいと思います(幼少期からの性教育は、こういう非常事態のための語彙を育む意味もあるんだと気づきました)。
そうした自分自身の戸惑いを言葉にするのも大変なはずです(そこまで考えて、性犯罪は時効を無くすべきでは、と思い至りました)。

でも、そうした考えを確固たるものにしないと、反論にさえ値しないような意見(気にするようなこと?など)を跳ね除けるパワーや、誤った論理(嫌って言わなかったのはなぜ?など)に時間切れで負けないための論理を培えないと思います。

次に、なぜ生き死にを分かつかもしれないと思ったか。
主人公ウンソが答えが出ない中悩んだように、被害者があなたに相談しているとき、理解してくれるかもしれないが10%、理解しないにしろ誰にも言わないであろうが60%として、誰かに言われてしまったら悲しいが一般的に見て自分が悪いわけでもないし、最悪死ねばいいや、が30%、くらいで、本当に死が選択肢にあるかもしれないと考えたからです。

個人の意見ですが、自分が人間として、嫌と思うことを聞き入れてもらえないというのは、要するに人間扱いしませんという宣言だと思ってます。そうした扱いを突きつけられた状態で過ごすのは本当に辛いです(この辺は会社でパワハラを受けたときのことを思いながら書いていますが、違うかもしれません)

その上、主人公ウンソがそうであったように、相談すべきかどうか、何度も何度も最悪のケースを想像しながら考えたはずで、あなたが相談を受けたらもう次はないかもしれないからです。

したがって、責任のある社会人としてできることは、誰かに相談された時に「あなたは悪くない」と言い切るための準備をすることなのでは、と思いました(救急救命講習を受けるのと同じように)。


私は性教育や性被害の専門家でもないし、他の人に比べて特段多くの時間を費やして考えてきたわけでもありません。
なので、性被害に遭った方に共感するためには、もしかしたら他に定番の何かがあるのかもしれないです。

だとしても、責任ある生き方をしたいと考えており、かつ考えるきっかけを探している、漫画を普段から読む私にとっては、この本が出会うべき本でした。

この本が届くべき人に届くことを切に願います。

※この記事によるアフィリエイトの収益を上回る額を、然るべき活動に寄付します。

Ansibleでbecomeを有効にすると、Escalation succeededと表示されるが処理が進まない → sudoのパスワードかユーザーが誤っているか、ControlMasterを有効化で解決

TL;DR

  • Ansibleはsudoのユーザーとして、デフォルトで root を使用する。変更したい場合は ansible_become_user オプションを指定すること
  • ssh_args = -F ssh_config を有効化している場合、同時に -C -o ControlMaster=auto -o ControlPersist=60s -o ControlPath=~/.ansible/cp/ansible-ssh-%h-%p-%r も設定しないとsudo時のパスワードの受け渡しが失敗するようだ

Detail

実際のエラーです。Escalation succeeded というのも紛らわしいですよね...

Escalation succeeded
  5416 1637070979.58389: stderr chunk (state=3):
>>>debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
<<<
  5416 1637070979.58397: stderr chunk (state=3):
>>>debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
<<<
  5416 1637070979.58965: stdout chunk (state=3):
>>>[sudo via ansible, key=knnjbjweeaqhattpcizhggtvpermhceb] password:<<<

修正後の ansible.cfg の抜粋です。

[ssh_connection]
ssh_args = -F ssh_config -C -o ControlMaster=auto -o ControlPersist=60s -o ControlPath=~/.ansible/cp/ansible-ssh-%h-%p-%r

Reference

別の問題ですが、ssh_args 指定時のオプションに着目していたのでヒントになりました。

serverfault.com

書評 - More Effective Agile

More Effective Agileを読んで学んだこと・考えたことをまとめました。

TL;DR

スクラム開発は、関係者がプロジェクトを通じてスクラム開発自体に習熟することを織り込んだフレームワークである。
会社としてアジャイルスクラム開発に舵を切ることは前提として、適切なインプットを与えてチームを高速に学習させるのが良さそうだ。

前提

私が働いているjustInCaseでは、2021年のはじめ頃からスクラム開発を採用しています。 それまでは営業(社長)が企画した商品を開発者が期限までに作るのが会社の風景でしたが、最近は変わってきました。

この本は、私が最初のスクラム開発プロジェクトに参加するに当たって読んだ本です。

実践できていること

  • 会社としてアジャイルに取り組んでいる。つまり、プロダクトの営業担当者が営業部門でなく、プロダクト開発チームの中にいる
    • フィードバックのループが高速になる。例えば、「この機能がほしいんだけど、3週間後までに出来る?」といえる。
  • スプリントとスプリントの合間の時間を作っている。
  • ストーリーポイントを設定している
    • 初めは相対的な値というのがよく分からなかったが、要するにチケットのレベル・HPのようなものと納得している。
    • やはり基準はほしい。たとえは、「ストーリーポイント1は、往復無しでPullRequestのレビューが終わるレベル」のような。
      • PullRequestのレビューも開発者の熟達に従って簡単になっていくはずなので、これも不適切かも
    • だいたい2週間くらい運用していると慣れるが、「何が基準なんですか?」とは新メンバーによく言われる。
  • 本には記載がないが、スクラム開発立ち上げ初期のスプリントは1週間がよい。PDCAを早く回せる。

実践できていないこと

  • チケットをバーティカルに分割するのにいまだに慣れない
  • 開発者がPO/PdMを兼ねない
    • ユーザーストーリーを適切なチケットの単位に変換するには、どうしてもデータ構造まで気が配れないと難しいのでは?と思ってしまう。
      • 開発者出身のPO/PdMなら解決する。
    • 「POはああ言っているけど、バックログのリファインメントの時に直せばいいか」というのは自分の中に心配事を持ち続けることになるという点でも適切ではない
  • プロダクトリファインメントの運営
    • スプリントプランニングでやってしまっている
    • ユーザーストーリーの洗い出しはどこまでで、リファインメントではどこから、という線引が出来ると良さそうだ
      • 多分、エンジニアがデータ構造を鑑みてアドバイスする必要が出てきたらリファインメント。

まとめ

実践できていないことも多々あるが、チームとして開発方法の共通言語があるのは心強い。スクラム開発に習熟していきたい。

書評 - インフラエンジニアの教科書

インフラエンジニアの教科書を読んで学んだこと、考えたことをまとめました。

インフラエンジニアの教科書

インフラエンジニアの教科書

  • 作者:佐野裕
  • シーアンドアール研究所
Amazon

TL;DR

ハードウェアやデータセンターの選定の基礎知識がまとまっており、オンプレ入門に良い本です。

動機

一人暮らしを始めたので、自宅ネットワーク環境を整備できるようになった。
この機会に物理ネットワーク・物理マシンに詳しくなりたいと思い、オンプレの先輩の勧めで購入。

学んだこと

メモリやCPU、ルーターなどの選定基準が学べた。 自宅サーバーのメモリ選定では拡張性(16GBを2枚にするか32GBを1枚にするか)の考え方が役に立ちそう。もっとも、メモリは2枚セットで販売していることが多いようで、新品だと16GBx2 or 32GBx2の2択になったが。

UTMの選定については詳しくなかったので、有識者やインターネット場の情報を参考にしたい。
セキュリティ機能をルーターに求めるかどうかは新しい視点だった(しかし、ご家庭では一緒で良さそうだ)

考えたこと

物理マシンについては、やって覚えようと思って購入してしまった。構成管理について考えすぎて全然先に進めていないが、今年中には自作PCで一通りの開発が出来るようにしていきたい。
調べたらSteam:PC Building Simulatorというゲームもあるようで、自分のマシンの構成を記録するのにいいかも?

ネットワークは特に急いでいないので、メルカリでUTMを探していきたいな。

この本を読んだ後に周囲のインフラエンジニアと話すと、オンプレ環境が少し身近に感じて面白かった。

AWS SSOでは Customize AWS Console Header Setting は使えない

TL;DR

  • Customize AWS Console Header Setting は アカウント名を後方一致で判定している
  • AWS SSOでのログイン時にアカウントメニューボタンに表示される文言は Permission / ユーザー名

したがって、アカウント名では判定できない。

凡例

アカウント名にユーザー名を hiroga を指定すると、実際にヘッダーの色がカスタマイズされる

f:id:hiroga_cc:20211012100930p:plain
Color changed by AWS SSO

書評: デジタルアイデンティティー 経営者が知らないサイバービジネスの核心

崎村さんのデジタルアイデンティティーを読みました。

OAuthとOIDCを触っている程度のエンジニアとしては、知らない用語が多くあって勉強になった... というか、勉強すべきことがたくさんあると思わされました。

(勉強になった、は用語をググったりこの本を3周くらいして初めて言えることですね)

まだ1周目を通しただけで書評とはおこがましいですが、感想を書き留めます。

アイデンティティーのライフサイクル管理にISO標準がある

アイデンティティーの状態遷移を表すISO標準があることを知りませんでした。

NRIの方が解説しているQiitaの記事があるので、仕様そのものに関してはそちらを参照ください(公式のリンクもそちらに)

qiita.com

いちエンジニアとしては、(変数の命名が楽になって良いな、なんたってISOからパクればいいもんな)と思うばかりです。

ところで、ユーザーのアイデンティティに関するライフサイクルといえば、私が知っているのはCognito UserPoolのライフサイクルでした。 docs.aws.amazon.com

見比べて思うのは、Cognitoのライフサイクル...ドキュメントの用語を借りれば「アカウントの確認プロセス」は、以下の点が異なるように見えました。

  1. ISOにおける「確立済み」に当たる状態が、「Registered」「Reset Required」「Force Change Password」で3種類ある
  2. 停止と保管が「Disabled」でまとめられている

1番目についてはCognitoに再考の余地があると思う一方(だってパスワード以外のログイン手段をサポートしづらくないか)、2番目については逆にCognitoがスッキリ・ISOが冗長に思われます。
有識者の方の意見も聞いてみたいところです。

幸福追求権から導かれるプライバシー

後半の章で気になった箇所です。いちエンジニアとしては、後半の章は経営者を諌める時に持ち出す文章だなと思って読みました。

プライバシーの解釈が面白くて、私の言葉で要約すると「相手によって違う自分を見せられる」権利なのだそうです。
何かを隠すのではなく、見せたいものを見せる、という肯定形の文章で表現されるのが、なんか良いなと思いました。

一昔前のYahoo知恵袋では、いちアカウントに対して複数のニックネームを持てたと記憶しているのですが、まさに「見せたい自分を見せる」機能だなと思います。
廃止されちゃいましたけど。笑

chiebukuro.yahoo.co.jp

あとはTwitterで投稿ごとに鍵かけらないかな、と思うことがありますが、それもプライバシーの権利に立脚してると思うと正当性がある感じがして強い気持ちで主張できますね。

その他

OIDC, OAuth, FAPIについても要件定義フェーズに相当するような用語が並べられており、学習に良いなと思っています。

まとめ

いちエンジニアとしてアイデンティティー...つまり認証とプライバシー・セキュリティに関する機能を考える上で、根拠を教えてくれる本でした。
それらについて考える必要があるとき、また読み返そうと思います。

1PasswordのChrome拡張は新しい方を使おう

TL;DR

1Passwordには2種類のChrome拡張があります。

新しい方

chrome.google.com

古い方

chrome.google.com

新しい方がChromeとの統合が優れていて、サクサク動くし、Desktop版がなくても動きます。しかも古い方は1Password 8 からは非対応になります。まだ古い方を使っている人は更新しましょう。

詳細

サポートコミュニティでも質問がある通り、2つのChrome拡張が存在します。

1password.community

新しい方はかつて 1Password X と呼ばれており、デスクトップ版との連携がないバージョンです。

webrandum.net

上記のブログでは 1Password (つまり古い方)を推奨しています。Dropboxで同期をしていたり、指紋認証でロック解除したい場合は必須ですね。
にもかかわらず、私が 1Password X (新しい方)を推奨するのは以下の理由からです。

Chromeとの統合が優れている

1Password XChromeのパスワード保存機能を上書きできます。

f:id:hiroga_cc:20210816094128p:plain
Save passwordの管理

特に会社でVaultを管理している時に便利で、保存先をChromeにしないことでパスワードが勝手に1Passwordに保存されるようになります。
この機能は、2021-08-16時点では Bitwardenにもありませんでした。便利。

サクサク動く

ロック解除までのスピードが、指紋認証がないことを計算に入れても段違いに早いです。
デスクトップ連携版では、そもそも拡張が機動しないことも多々ありました。

Desktop版がなくても動く

1Passwordのデスクトップ版がなくても動きます。業務で使っている場合、チームメンバーがインストールするアプリが減って楽ですね。

まとめ

新しい方の 1Password拡張アプリ(旧称 1Password X)への入れ替えがオススメです。

chrome.google.com