頑張らないように頑張る。

努力と怠惰の狭間

今日を生きるために漫才を取り入れてみる。

最近、生きた心地がしない毎日を過ごしている。

仕事において特にそう感じる事があり、呆れや哀しみや憤りを感じながら終業時間を迎える日々。


こういった日々がどうしたら楽しくなるかは永遠の課題だが、今回は一日を「漫才」と捉えてみる事にする。




一日の始まりは、つかみから始まる。


つかみには、客イジりや相方イジり、小ボケや定番ボケなど多種多様に存在する。
「こういう雰囲気の芸人なんだな」という自己紹介と共に、「ここからネタが始まるぞ」という空気を作るために、非常に重要な役割を担う。

出社したら、まず初めにスタンドアップミーティングを行う。
出社直後の緊張状態をアイスブレイクできると共に、「今日も一日がんばるぞい」という空気を作る。




そして、漫才は本題に入る。


現代の漫才においては「しゃべくり漫才」と「コント漫才」に分けられる。
しゃべくり漫才」は、マイクの前に立ったまま会話をベースに話を進行させていくスタイル。
一方「コント漫才」は、マイクから離れて舞台上を大きく使いながら展開していくスタイル。

どちらにしても基本的なスタイルは、ボケが主観的に話を膨らませていき、ツッコミが客観的に指摘や訂正を入れるというものである。
基本スタイルを応用して、ボケとツッコミが入れ替わったり、どちらもボケてみたり、ツッコミのワードセンスによりボケを増大させたりなどの技術が用いられる。

仕事においても、チームや個人によってスタイルは様々存在し、それぞれが独自の技術を用いながら業務を遂行する。


基本から逸脱していたり、スタイルがいびつであったり、独特な技術を使っている人は、芸人にも会社員にも少なからず存在する。

多くの笑いを生めるのであれば受け入れられるし、速くて確実な成果物を生めるのであれば受け入れられる。

大して笑いも取れていないし舞台袖に芸人も集まっていないと、成長を見込んで舞台袖で指摘せざるを得ないし、
遅かったり低品質な成果物ばかり生んでいると、業務効率を懸念して指摘せざるを得ない。




最後は、オチを作って終わる。


ボケがオチを発した後、ツッコミは「あんたとはやってられんわ」「いい加減にしろ」「もうええわ」「やめさせてもらうわ」などでツッコみを入れ、漫才が終了する。
これらのツッコミには愛があり、本当にやってられなかったり、いい加減にしてほしいとは思っていない。
本気でやってられないと思ったら、それはもう解散を意味する。

仕事においても不満が増大する事がある。
その不満も「この会社/先輩/後輩/上司/部下とはやってられんわ」と思いながら退勤できるくらいであれば、まだ十分会社に属する価値はある。
本気でやってられないと思ったら、それはもう転職や退職を意味する。





漫才できているうちが華。



おもしろい事したいですね。


ワイ記法で「オレオレ証明書」についてまとめてみた。

登場人物

  • ストーリーテラー:全体を進行しながら、証明書などの説明をしてくれる。
  • わい      :主人公。何も知らないバカ息子。
  • 親父      :主人公の親。よく分からない事を噛み砕いて教えてくれる。
  • Webサーバ  :主人公の取引先。
  • ハンバーグ師匠 :オレオレ言ってる人(登場しない)


プロローグ

わい    「なあ」
Webサーバ「なに?」
わい    「君と取引をしたいんや」
Webサーバ「ええで」
わい    「けど、あんた信頼ならんな」
Webサーバ「何てこと言うんや、悲しいわ」
わい    「あんたがどこの馬の骨か分からんから、身分証明してくれや」
Webサーバ「ほなサーバ証明書見せたるで」
わい    「・・・この証明書は誰に発行してもらったんや?」


ここで世界は2つに分岐する・・・・・。


▼1つ目の世界

Webサーバ「中間認証局から得たものやで」
わい    「ほなその中間認証局は誰に認証してもらってるんや?」
Webサーバ「ルート認証機関に決まっとるがな」
わい    「せやな、疑って悪かったわ」
Webサーバ「せやで、ほな、取引させてもらいましょか」
わい    「よろしく頼むわ」


▼2つ目の世界

Webサーバ「オレがオレ自身で発行したんやで」
わい    「は?」
Webサーバ「だから、オレが発行して、オレが保持して、オレが提示してるんや」
わい    「ちょっと何言ってるのか分からないです」
Webサーバ「まあ細かい事は言わんと、昔からの仲やないか」
わい    「せやな、正規なところから証明されてなくても、お前はお前やもんな」
Webサーバ「せやで、ほな、取引させてもらいましょか」
わい    「よろしく頼むわ」


そもそも、証明書とは?

インターネット上で用いられる証明書は「電子証明書」と言われ、大きく2つに分けられる。(本稿ではサーバ証明書について主に説明する)

クライアント証明書

クライアント証明書は、ユーザが正規の利用者である事を認証するために用いられる。
クライアント証明書は、サービス提供者に発行してもらいUSBやメールなどで配布される事もあれば、ユーザ自身でサービス提供元に対して発行要求をする事もある。

サーバ証明書

サーバ証明書は、「実在性証明(サーバが正規の提供者である事)」「暗号化(サーバとの通信規約)」の2つの役割のために用いられる。
サーバ証明書は、認証局に発行してもらう必要があり、サービス提供者自身でサーバにインストールする必要がある。


親父「つまり、運転免許証はクライアント証明書やな。警察署に認証認可もらって、免許証を発行してもらう事で、正規の運転者として認められるわけや。」
わい「なるほど」
親父「一方で、飲食店とかの営業許可証はサーバ証明書やな。保健所から認証認可もらって、店舗に貼り出す事で、顧客は安心してサービスの提供を受けられるわけや。」
わい「なるほど」


※NOTE※
以下に記載されているように、他にも証明書の種類はありますが、ここでは説明を割愛します。


そもそも、認証局とは?

わい「なんで、何で警察署は信頼できるんや?」
親父「そりゃ、裏には警察庁がおるからな」
わい「なんで、何で保健所は信頼できるんや?」
親父「それも、裏に厚生労働省がおるからな」
わい「なんで、厚生労働省警察庁は信頼できるんや?」
親父「それが、国のトップやし、そこが崩れたらお終いやろ」
わい「せやな」


警察署や保健所は「中間認証局」に相当し、
警察庁厚生労働省は「ルート認証局」に相当する。


どのサイトが、どの中間認証局から発行を受け、その中間証明書はどのルート証明書から発行を受けているかは、以下の手順で確認できる。


ちなみに、Qiitaの場合は以下となっている。(2022/07/20時点)

  • Starfield Class 2 Certification Authority
    • Starfield Services Root Certification Authority - G2


わい「入れ子になってる事で、トラストチェーンが構築されるわけやな」
親父「そういう事や」
わい「けど、映画とかドラマやと、不法に免許証発行して身分の偽証してる事とかあるやん、あいつら何なん?」
親父「ああいう奴らが”オレオレ証明書”とか言い始めるねん」


オレオレ証明書”とは一体何なのか?

サーバ証明書には、「暗号化」「実在性証明」の2つの役割があると前述した。

暗号化

オレオレ証明書では、「暗号化」については難なく行う事ができる。
「暗号化」とは、SSL(Secure Socket Layer)による暗号化通信を行うという意味がある。
SSLはただのプロトコル(規約)であるため、規約さえ守っていれば暗号化通信は成立する。

実在性証明

しかし、「実在性証明」については担保する事ができない。
「実在性証明」については、第三者機関により担保してもらわなければ成立しない。
オレオレ証明書のように自己署名した証明書は、第三者機関により担保してもらう事ができず、正当な通信相手であるかが判断できない。


親父「映画とかドラマで偽造免許作ってる場合でも、ちゃんと安全運転はできているんだし、安全運転できてるならその免許証は正当であると判断してしまう事はあるやろ」
わい「せやな」
親父「だけど、いくら安全運転だからといって、それが偽造した免許で、警察署の許可を得てないと分かったら、途端に信頼性が破綻するやろ」
わい「せやな」
親父「だから、オレオレ証明書というのはあかんのや」
わい「なるほど」


※NOTE※
運転免許証の偽造は違法です。
「有印公文書偽造罪」「偽造公文書行使罪」「公文書偽造罪」などに該当するため、法は犯さないようにしましょう。


オレオレ証明書”を使っていいタイミングはある?

わい「調べてみたら、サーバ証明書を得るには、年間5万~10万円くらいかかるらしいやん」
親父「せやな」
わい「だけどさ、システム構築する上で、本番運用前に開発環境でSSL通信の疎通確認したいやん」
親父「せやな」
わい「そういう時はどうすればええんや?開発環境なのに証明書買わんとあかんのか?」
親父「そういう時はオレオレ証明書でもええねん」
わい「え?」
親父「私有地なら無免許でも運転してええって聞いた事あるやろ?」
わい「ある」
親父「それと一緒で、開発環境は外部に晒されてない環境だから、別に自己署名で通信したって誰にも迷惑かからんやろ」
わい「なるほど」
親父「逆に、そのまま本番環境に適用はしちゃいけんで」
わい「外部に晒されてるし、『お前はどこの認証を受けてるんや?』って聞かれた時に答えれんもんな」
親父「そういう事や」


※NOTE※
私有地だと無免許運転してもいいというのは語弊です。ここでは例示として用いただけです。
アウトなケースもあるので、道路交通法はきちんと守りましょう。


オレオレ証明書”や”不正な証明書”を検知する方法は?(PKIについて)

わい「オレオレ証明書がダメなのは分かったわ」
親父「良かった」
わい「けど、正当な認証局から証明書を得てても、更新漏れで失効してたり、規約違反で停止されてる事もあるやんか」
親父「運転免許証とか営業許可証にも、有効期限や適用範囲というのがあるからな」
わい「そういう不正な証明書はどう検知すればいいんや?」
親父「それは、『PKI』によって担保されるんや」

PKI(Public Key Infrastructure、公開鍵基盤、公開鍵暗号基盤


細かい説明については、以下を参照の事。


公開鍵基盤上には「CRL(Certificate Revocation List)」という証明者失効リストが存在し、以下に該当するものが列挙されている。

  • 有効期限内であるにも関わらず、以下のような事由により、失効ないし停止した電子証明書のシリアル番号
    • 秘密鍵の漏えい
    • 秘密鍵の紛失
    • 文書偽造
    • 証明書の被発行者の規則違反 など


PKIに準拠していない場合、ブラウザは「この接続ではプライバシーが保護されません」などの警告を表示する。Google Chromeの場合は以下の通り。


サーバ証明書のインストール方法

オレオレ証明書であっても、正当な認証局から得た証明書であっても、サーバにインストールしない事には始まらない。


という事で、以下を参考にインストールを行う。


エピローグ

わい    「気軽に君と取引したいとか言ってゴメンな」
Webサーバ「分かってくれたらええんやで」
わい    「ほな改めて、君はどこからの認証を受けてるん?」
Webサーバ「それは・・・・・」
ブラウザ  「(この接続ではプライバシーが保護されません)」
わい    「▂▅▇█▓▒░('ω')░▒▓█▇▅▂うわああああ」


余談

元々Qiitaに挙げてたんだけど、キチガイにコメントで絡まれて不快な思いをしたので、Qiitaの記事は消してこちらに再掲。

一昔前(今でもあるけど)、teratailという日本版StackOverflowのようなサイトがあって、とても便利だったものの説教ジジイが増えてしまったせいでユーザが離れていったのを思い出した。

Qiitaもユーザの質が低下してきてるし、その内Zennに取って代わられるんだろうな。


※NOTE※
teratailやQiita、Zennなどのサービスには、ガイドラインやポリシーなどが設けられています。
ガイドラインやポリシーに違反しないように配慮しながら、投稿やコメントを楽しみましょう。


参考サイト

『ソフトウェアアーキテクチャの基礎―エンジニアリングに基づく体系的アプローチ』を読んだのでまとめた。

⚙️はじめに

掲題の通り、『ソフトウェアアーキテクチャの基礎―エンジニアリングに基づく体系的アプローチ』を読み終えたので、まとめておく。

www.oreilly.co.jp


本書は以下の章立てで構成されている。


本ブログでは上記の章立て通りにはまとめず、以下の粒度でまとめる事とする。



⚙️本書に出てくるアンチパターンと回避方法

象牙の塔アーキテクトアンチパターン

  • 発生:開発チームの意見や懸念を無視して、上から目線で何をすべきかを指示しているだけのアーキテクト
  • 回避:開発チームとコミュニケーションを取り、協働してアーキテクチャ決定を下す

汎用アーキテクチャアンチパターン

  • 発生:すべてのアーキテクチャ特性をサポートしようとして、システム全体が複雑になる
  • 回避:設計をシンプルに保つ。最も重要な特性3つを顧客に決めてもらう。

巨大な泥団子アンチパターン

  • 発生:認識できるアーキテクチャ構造が不在の状態。循環依存状態であったり、スパゲッティ状態であったり、パッチワーク状態であったり、とにかく悲惨。
  • 回避:リファクタリング

暗黙のアーキテクチャアンチパターン

偶発的アーキテクチャアンチパターン

アーキテクチャシンクホールアンチパターン

  • 発生:「レイヤードアーキテクチャ」において、各レイヤー内でビジネスロジックが実行されず、リクエストがパススルーされてレイヤー間を移動してしまう
  • 回避:80対20ルールに従う。すべてのレイヤーを開放レイヤーにする。

資産防御アンチパターン

  • 発生:選択誤りの恐れによる、選択や決定の放棄や先延ばし
  • 回避:最終責任時点まで決定を下さない。決定が実現できるように開発チームをサポートする。

グラウンドホッグデーアンチパターン

  • 発生:決定が下された理由の周知不足。
  • 回避:ビジネス価値を付加して、周知・共有する。

メール駆動アーキテクチャアンチパターン

  • 発生:メンバーは決定を失念・忘却してしまう。
  • 回避:本当に関心のある人にだけ決定を伝える。メールではなくWikiにする。

アーティファクトへの不合理な愛着アンチパターン

  • 発生:アーキテクトが自分が作ったものに過度に執着してしまう。
  • 回避:UML、C4、ArchiMateなどを用いて手早く作る。

クッキー型アンチパターン

  • 発生:プレゼンテーション作成者が、スライドを余計な装飾で埋め尽くそうとする
  • 回避:1つのスライドで全てを表現しようとせず、複数のスライドに分けてアイディアを表現する

蜂の巣にされた死体アンチパターン

  • 発生:スライドがプレゼンテーション発表者のメモでしかない状態
  • 回避:プレゼントは「視覚」「聴覚」の2つの情報チャンネルがあるので、うまく使い分ける



⚙️アーキテクチャの概観

ソフトウェアアーキテクチャの法則


ソフトウェアアーキテクチャのモジュール性とコンポーネント

モジュール性

ソフトウェアアーキテクチャに関する言説の95%は「モジュール性」の利点を称賛するために費やされる。

「モジュール性」を計測するには、以下3つのメトリクスがある。

凝集度
  • 尺度としては、以下7段階がある
    • 機能的凝集
    • 逐次的凝集
    • 通信的凝集
    • 手続き的凝集
    • 時間的凝集
    • 論理的凝集
    • 偶発的凝集
  • 計測方法としては、以下のようなものがある
    • CKメトリクス
    • LCOM
結合度
  • 種類としては、以下2つがある
  • 計測方法としては、以下のようなものがある
    • 抽象度     =抽象的なアーティファクト/(抽象的なアーティファクト+具体的なアーティファクト
    • 不安定度    =遠心性結合/(遠心性結合+求心性結合)
    • 主系列からの距離=|抽象度+不安程度-1|
      • 主系列からの距離が、主系列の右上だと、抽象度が高いので使いづらい
      • 主系列からの距離が、主系列の左下だと、抽象度が低いので変更に弱くメンテナンスしづらい
コナーセンス
  • 種類としては、以下2つがある
  • 性質としては、以下3つがある
    • 強さ
    • 位置
    • 度合

コンポーネント

コンポーネント」とは、モジュールが物理的にパッケージ化されたものであり、アーキテクチャの基本構成要素。


コンポーネントの粒度は、以下のトレードオフを持つ。

  • 細か過ぎる:コンポーネント間でたくさんのやりとりが必要になり、一貫性やトランザクションなどの管理が困難になる
  • 粗過ぎる :内部結合度合いが高くなり、デプロイ容易性やテスト容易性の確保が困難になったり、モジュール性に関連した負の副作用をもたらす


コンポーネントの発見には、以下などがある

  • アクター/アクションアプローチ
  • ワークフローアプローチ
  • イベントストリーミング


ソフトウェアアーキテクチャの構成要素

ソフトウェアアーキテクチャは、以下4つから構成される。

構造

システムで使われているアーキテクチャスタイルの種類(詳細は次章で記載)であり、以下のようなものがある。


モノリシックアーキテクチャでは「ACIDトランザクション」が採用される事が多い。

  • A(Atomicity)
  • C(Consistency)
  • I(Isolation)
  • D(Durability)


分散アーキテクチャでは「BASEトランザクション」が採用される事が多い。

  • BA(Basically Available)
  • S (Soft state)
  • E (Eventual consistency)


分散アーキテクチャはモノリシックアーキテクチャよりも強力だが、以下8つの誤信を注意する必要がある。

  • ネットワークは信頼できる
  • レイテンシーがゼロ
  • 帯域幅は無限
  • ネットワークは安全
  • トポロジーは決して変化しない
  • 管理者は一人だけ
  • 転送コストはゼロ
  • ネットワークは均一


上記8つの誤信の他にも、分散アーキテクチャは、以下について注意する必要がある。

アーキテクチャ特性

システムがサポートしなければならない「イリティ(-ility)」であり、以下のようなものがある。

  • 可用性
  • 信頼性
  • テスト容易性
  • スケーラビリティ
  • セキュリティ
  • アジリティ
  • 耐障害性
  • 弾力性
  • 回復性
  • パフォーマンス
  • デプロイ容易性
  • 学習容易性 など


アーキテクチャ特性とは、以下3つを満たすものをいう。

  • ドメインに依らない、設計に関する考慮事項を明らかにするもの
  • 設計の構造的な側面に影響を与えるもの
  • アプリケーションの成功に不可欠ないし重要なもの


アーキテクチャ特性を全乗せした「汎用アーキテクチャアンチパターン」にならないようにする。

  • 常にトレードオフを意識する
  • 最も重要な特性3つを顧客に決めてもらう


アーキテクチャ特性は、以下の特徴を持つ「アーキテクチャ量子」で定め、スコープを絞って考える。

  • 独立してデプロイ可能
  • 高度な機能的凝集性
  • 同期的なコナーセンス


アーキテクチャ特性を【明確】にするには、「アーキテクチャ・カタ」を用いてみるとよい。

  • アーキテクチャ・カタ」には、明確にするのに必要な「関心事」「要件」「暗黙的なドメイン知識」が含まれる
  • 要件定義には、"明示的な特性"は記載されているものの、"暗黙的な特性"は記載されていないため、カタを用いて明確にする


アーキテクチャ特性を【計測】するには、以下の客観的指標を用いる。

  • 運用面の計測  :パフォーマンスなど
  • 構造面の計測  :循環複雑度など
  • プロセス面の計測:テスト容易性など


アーキテクチャ特性を【統制】するには、以下を用いる。


アーキテクチャ特性を【検証】するには、以下のような適応度関数を用いる。


例として、可用性については「9」を意識して設定する。

  • システム全体としてはファイブナイン(99.999%)である必要がない事もあるので、分割統治も考える。

アーキテクチャ決定

システムを構築する際のルール(ガイドラインではない)であり、以下のような例がある。

  • <例>レイヤードアーキテクチャの場合
    • ビジネス層とサービス層は、永続化層に直接アクセスできる
    • プレゼンテーション層は、永続化層に直接アクセスできない
    • サービス層は、開放レイヤとする
    • サービス層意外は、閉鎖レイヤとする など


アーキテクチャ決定については、以下のようなアンチパターンが段階的に発生する事がある。

  1. 資産防御アンチパターン
  2. グラウンドホッグデーアンチパターン
  3. メール駆動アーキテクチャアンチパターン


アーキテクチャ決定を文書化するには、「アーキテクチャデシジョンロード(ADR)」を用いるとよい。

設計指針

システム構築する際のガイドライン(ルールではない)であり、以下のような例がある。

  • <例>マイクロサービスアーキテクチャの場合
    • サービス間の非同期メッセージングを可能な限り活用し、パフォーマンスを向上させる
    • (ルールとして堅く決める事が難しい指針を示すのが目的)



⚙️ソフトウェアアーキテクチャのスタイル

前述した4つの構成要素のうち「構造」について、以下に詳しく記載する。


モノリシックアーキテクチャ

レイヤードアーキテクチャ

  • 別称
  • 構成要素
    • レイヤの種類
      • プレゼンテーション層
      • ビジネス層
      • 永続化層
      • DB層
    • レイヤの分類
      • 開放レイヤ:追加に強いが変更に弱い
      • 閉鎖レイヤ:追加に弱いが変更に強い
  • 特徴
    • コンウェイの法則が働く組織で採用されがち
    • 各レイヤの作業は抽象化されており、各レイヤで役割と責務を持つ
    • 小規模でシンプルなアプリケーションやWebサイトには向いている

パイプラインアーキテクチャ

  • 別称
  • 構成要素
    • パイプ
      • 一方向かつポイントツーポイント
    • フィルター
      • ステートレスでシングルタスク
      • 「プロデューサ」「トランスフォーマ」「テスタ」「コンシューマ」から構成される
  • 特徴
    • Linuxのパイプラインが代表的
    • 拡張性に優れている

マイクロカーネルアーキテクチャ


分散アーキテクチャ

サービスベースアーキテクチャ

  • 別称
    • なし
  • 構成要素
    • ユーザインターフェース
    • リモートサービス
    • データベース
      • 物理的にはモノリスであってもOK
      • 論理的に分割しておくと変更に対応しやすくなる
  • 特徴
    • 柔軟性が高く、実用的で、ドメインによって分割されるアーキテクチャ
    • サービスの粒度は、以下のトレードオフを持つ
      • 細かくなるにつれて、「オーケストレーション」と「コレオグラフィ」にまつわる問題が出てくる
      • 粗くなるにつれて、完全性や一貫性は向上するものの、テスト容易性などが欠如する可能性がある

イベント駆動アーキテクチャ

  • 別称
    • なし
  • トポロジ(構成要素とは違う)
    • ブローカー
      • 分離され独立していてシンプルなため拡張性が高い
      • 単一障害点が発生しやすく、非同期処理なのでどこで問題が発生しているか分かりづらい
    • メディエーター
      • ワークフローに関する知識と制御を持ち、単一障害点も解消できる
      • 結合度が高いため複雑になりがち
  • 特徴
    • 非同期には「リクエスト・リプライ」「ファイア・フォーゲット」があるが、いくつかの問題を抱える
      • エラー処理:解決方法は、ワークフローの委譲
      • データロス:解決方法は、メッセージング技術やACID特性
    • 非同期処理だけでなく、必要に応じて同期処理も検討すべき

スペースベースアーキテクチャ

  • 別称
    • なし
  • 構成要素
    • 処理ユニット
    • 仮想ミドルウェア
      • メッセージンググリッド
      • データグリッド
      • 処理グリッド など
    • データポンプ
      • 処理ユニットとDBの仲介役
    • データリーダ・データライタ
      • データアクセス層ではなく、データ抽象層を採用
  • 特徴
    • 名前の由来は「タプルスペース(複数の並列プロセッサが共有メモリを介して通信する技術)」
    • ハイブリットなシステム構成が作りやすい

オーケストレーション駆動サービス指向アーキテクチャ

  • 「分離」と「再利用」によって効率化を図るつもりが、一つの変更が全てのサービスに影響を及ぼすという、非効率を生み出してしまっている
  • (「再利用」により「結合」が発生し、結合度が上がってしまうという負のトレードオフ

マイクロサービスアーキテクチャ

  • 別称
    • なし
  • 構成要素
    • 粒度を細かくし過ぎないように、以下からサービスの分離を考える
    • フロントエンドは、以下のどちらを採用してもよい
    • 分離したサービスごとに「サイドカー」を設ける
      • 「サービスメッシュ」する事で運用面の関心事を解決する
  • 特徴
    • ドメイン駆動型設計(DDD)の考え方に影響を受けている
    • 高度な分離のために、再利用よりも複製を選んでいる
    • 境界づけられたコンテキストの論理的概念を、物理的にモデル化している
    • マイクロサービスアーキテクチャの通信は、プロトコルを意識した異種間相互運用性を利用する
    • サービスを跨いだトランザクションは作らない
      • もし作るなら「サーガパターン」を用いるとよいが、そもそも作るべきではない



⚙️アーキテクトについて


アーキテクトにキャリアパスがないと言われている所以

ソフトウェアアーキテクトに明確なキャリアパスがない理由は、以下の4つ。

  • ソフトウェアアーキテクチャ自体の定義が業界でよく定まっていない
  • ソフトウェアアーキテクトの役割が非常に広範囲にわたり、拡大を続けている
  • ソフトウェア開発エコシステムが急速に進化しているために、ソフトウェアアーキテクチャが常に変化する対象になっている
  • ソフトウェアアーキテクチャについての資料の大半が、単なる歴史的経緯になってしまっている


アーキテクトに期待する事

アーキテクトは、以下である必要がある。

  • プログマティック
  • ビジョナリー


また、「アーキテクトらしく考える」ために必要な事は、以下の通り。

  • アーキテクチャと設計の違いを理解する
    • 違いなんてものは存在しないので、チームの壁を取っ払って、コラボする
    • (違いを決めてしまうと分業してしまい、最も重要な"コラボレーション"が失われるため、敢えて違いを設けないという意味)
  • 広範的な技術知識を持つ
    • 開発者は深さ、アーキテクトは広さ
    • (ここを履き違えると、機能不全に陥る)
  • トレードオフの理解・分析・調整する
    • トレードオフは、Google検索では見つけられないし、正解も不正解もない
    • (時と場合によるので、その場その場に応じて順応する必要がある)
  • ビジネスドライバーを理解する


つまり、アーキテクトに期待する事は、以下8つ。

  • アーキテクチャ決定を下す
  • アーキテクチャを継続的に分析する
  • 最新のトレンドを把握し続ける
  • 決定の順守を徹底する
  • 多様なものに触れ、経験している
  • 事業ドメインの知識を持っている
  • 対人スキルを持っている
  • 政治を理解し、かじ取りする


アーキテクトのパーソナリティ


アーキテクトのパーソナリティは、以下3タイプに分類される。

  • コントロールフリークアーキテクト:きつめ。開発チームに制約を与え過ぎてしまい混乱を招く。
  • アームチェアアーキテクト:ゆるめ。開発チームに作業が集中してベロシティと生産性が低下する。
  • 効果的なアーキテクト:ちょうどいい。エラスティックリーダーシップを取れる。


アーキテクトが、どの程度コントロールフリークで、どの程度アームチェアであるべきかは、以下により変動する。

  • チームの親しさ(親しければ緩くていいし、組立てのチームならキツめでいい)
  • チームのサイズ(小さければ緩くていいし、大きければ多少の制約は必要)
  • 全体的な経験(シニアが多ければ緩くていいし、ジュニアが多ければ制約やメンタリングが必要)
  • プロジェクトの複雑さ(シンプルなら緩くていいし、複雑なら統制が必要)
  • プロジェクトの期間(短ければ緩くていいし、長ければ統制が必要)


アーキテクトが意識すべき事

アーキテクト自身がボトルネックにならず、かつ現場感が保てるように、以下の方法を取る

  • PoCを頻繁に行う
  • ストーリーを引き受ける
  • イテレーション内でバグ修正に取組む
  • 日常業務を自動化する


「本質的な複雑さ」は仕方ないが、「偶発的な複雑さ」を生まないように、以下の4Cを行う

  • Communication(コミュニケーション)
  • Collaboration(協調性)
  • Clarity(明瞭さ)
  • Conciseness(簡潔さ)

https://www.oreilly.co.jp/books/images/picture_large978-4-87311-982-3.jpeg

日本史を「時代・首都・幕府・登場人物」の4軸でまとめてみた。

はじめに

以前、知識労働について調べてる時に、以下の疑問が沸いてきた。

  • 日本史には豪族とか貴族とか出てくるけど、そもそも天皇とか藤原氏って誰なんだ?
  • 平城京とか平安京とかあるけど、あれってそもそも何なんだ?
  • 都と幕府って何が違うんだ?


調べて分かったのが、ざっくりとこんな感じ。


という事で『時代・首都・幕府』に『登場人物』を加えた4軸でまとめてみた。



■■■首都も幕府もなかった時代(~694年)■■■


旧石器時代(首都:なし/幕府:なし)


農民「おらっ!石で武器とか食器とか作ったんで!おらっ!」


縄文時代(首都:なし/幕府:なし)


農民「移動生活面倒だし、定住生活しようぜ(村誕生)」
農民「みんな同じような土器作ってて分からんくなるから、俺の土器には模様つけとくわ」


弥生時代(首都:なし/幕府:なし)


神武天皇「九州から東征してきたで!ここ奈良を本拠地とする!(天皇誕生)」


できる農民    「稲作始めるで!効率良く作るし、高床式倉庫も作るで!(貧富の差が発生)」
できない農民   「稲作始めるで!うわ、めっちゃ難しいやん、、、(貧富の差が発生)」
野蛮な農民(=豪族)「俺の土地は俺の土地、お前の土地も俺の土地(貧富の差→身分の差。国誕生。)」


卑弥呼「豪族たちよ、私に従いなさい」
中国 「日本には女性が従えてる国があるんやな。興味深いから執筆しとこ(魏志倭人伝)」


古墳時代(首都:なし/幕府:なし)


大和・吉備・筑紫・出雲「四人揃って、四大王権!」
ヤマト王権      「偉い人が死んだ!死を弔うためにデカい墓を作ろう!」


飛鳥時代(首都:なし/幕府:なし)


物部氏     「仏教が百済から伝わってきた!仏教など要らぬ!神道大事!」
蘇我氏     「多文化認めなあかんで!仏教いるやろ!」
物部氏 VS 蘇我氏「そんなに言うなら対決じゃい!(丁未の乱)」


蘇我馬子崇峻天皇のやつ、気に食わんから殺したろ」
崇峻天皇「ギャー」
蘇我馬子「ついでに天皇任命したろ」
推古天皇「どうも、日本初の女天皇です」
聖徳太子「己の身分が分かりやすいように、色で判別できるようにしようで(冠位十二階)」


蘇我蝦夷 「息子よ。馬子も推古天皇聖徳太子も死んだし、俺らが政治握れると思わないか?」
蘇我入鹿 「父者よ。俺もそう思うわ」
中大兄皇子蘇我氏怖いから、入鹿の家を放火したろ」
中臣鎌足 「蘇我氏怖いから、蝦夷の家を放火したろ」(中臣鎌足藤原氏の始祖。藤原鎌足ともいう。)


天智天皇       「天皇に即位しました、中大兄皇子です。弟に王位継承しようと思いm...やっぱり息子にしようかn...ポックリ」
大友皇子(息子)    「息子である僕の方が王位継承すべきでしょ」
大海人皇子(弟)    「いや、元々弟の俺に王位継承するって言ってたんやぞ」
大友皇子 VS 大海人皇子「そんなに言うなら対決じゃい!(壬申の乱)」



■■■首都が作られる時代(694年~1185年)■■■


飛鳥時代(首都:藤原京/幕府:なし)


天武天皇天皇に即位しました、大海人皇子です。
     本拠地を奈良県橿原市・明日香村の周辺とし、名を藤原京とします」
持統天皇天武天皇が計画した藤原京を、僕が実現させました」
文武天皇「唐に倣って法律作ってみたよ。(大宝律令)」


奈良時代(首都:平城京/幕府:なし)


元明天皇「息子の文武天皇が死んだ...母ちゃん悲しいよ...
     息子の作った法律で新しい政治を行っていくために、本拠地を奈良県奈良市大和郡山市の周辺に移し、名を平城京とします。
     租・庸・調で徴税し、国・郡・里で土地を管理します」


聖武天皇「最近内乱が多くて怖いよぉ...怖いから逃げるために恭仁宮波宮、紫香楽宮と転々にするよ...けどやっぱり平城京に戻るよ...」


桓武天皇「最近仏教中心の考え方の寺院が影響力持ってきてて面倒だから、奈良から京都に遷都したいなぁ。
     平城京は地理的にも川とかないし、川が流れてる場所がいいなぁ。」


奈良時代(首都:長岡京/幕府:なし)


桓武天皇「本拠地を京都府乙訓郡の周辺に移し、名を長岡京とします。」
桓武天皇「・・・え、遷都の責任者が暗殺された?怖っ」
桓武天皇「・・・え、近親者が続々と不幸に見舞われるんだが?怖っ」
桓武天皇「・・・え、自然災害も発生するんだが?怖っ」
桓武天皇「・・・これ何かの祟り?怖いね?新しい都を探さなきゃね?」


平安時代(首都:平安京/幕府:なし)


桓武天皇  「長岡京は断念して、本拠地を京都府愛宕郡葛野郡の周辺に移し、名を平安京とします。」
坂上田村麻呂桓武天皇の名を受けて、蝦夷征服したったわ(初代征夷大将軍)」


桓武天皇「息子よ、近親婚で自滅した天武皇統のようにならないようにせんとな」
嵯峨天皇「父者よ、それは本当にそう」


平氏  「桓武天皇から姓を受けたぜ(武士の誕生)」
源氏  「嵯峨天皇から姓を受けたぜ(武士の誕生)」


嵯峨天皇「それにしても冬嗣よ、あんたの采配すごいな。」
藤原冬嗣「あざす」
藤原良房「父者(冬嗣)のおかげで皇族と関係を持てるようになったので、皇族以外で初の摂関になったで(摂関政治の始まり)」


平将門  「用心棒ばっかりやってられるか!俺は力あるんや!(承平の乱平将門の乱)」
藤原純友 「用心棒に頼ってられるか!俺も暴れ回ったるで!(天慶の乱藤原純友の乱)」
後三条天皇「摂関に政治任せてたら荒れるから摂関政治終わりな。代わりに院政開始な。(院政)」


鳥羽天皇       「ポックリ」
後白河天皇      「おい、鳥羽天皇の後継者はわしじゃ!」
崇徳上皇       「いや、鳥羽天皇の後継者はわしじゃ!」
後白河天皇 VS 崇徳上皇「そんなに言うなら対決じゃい!(保元の乱)」


後白河天皇   「勝ったぜ」
信西      「おい、後白河天皇の側近はわしじゃ」
藤原信頼    「いや、後白河天皇の側近はわしじゃ」
信西 VS 藤原信頼「そんなに言うなら対決じゃい!(平治の乱)」


平清盛   「後白河天皇のやつ、気に食わんから幽閉したろ」
以仁王   「お父さんが幽閉された。院政も封じ込められてるし、マジで腹立つ」
平氏 VS 源氏「源平合戦じゃい!(一ノ谷の戦い)」
平氏 VS 源氏「源平合戦じゃい!(屋島の戦い)」
平氏 VS 源氏「源平合戦じゃい!(壇ノ浦の戦い)」



■■■幕府ができた時代(1185年~1867年)■■■


鎌倉時代(首都:平安京/幕府:鎌倉幕府


源頼朝  「壇ノ浦の戦い平氏滅亡させたったぞ。守護・地頭の任免権くれや。」
後白河法皇「ええで」
源頼朝  「ほな本拠地の鎌倉に幕府作るで。武家政権の誕生や。
      幕府はみんなに御恩するから、何かあったら奉公してな。」


後鳥羽上皇 「何か、やっぱり武家に政権握られるの嫌やな」
北条政子  「みなさん。御恩と奉公です。今が奉公の時です」
朝廷 VS 幕府「対決じゃい!(承久の乱)」


モンゴル兵「侵略してやるー、うわー、やられたー(元寇)」
武家   「奉公のわりに御恩が少なくね?幕府大丈夫か・・・?」


後嵯峨天皇「次の天皇、どっちの子供にするか決めなきゃなー...ポックリ」
幕府   「亀山天皇(大覚寺統)と後深草天皇(持明院統)が10年ごとに皇位交代って事で(両統迭立)」
公家   「朝廷の扱い雑じゃね?もっとちゃんと考えろよ?幕府大丈夫か・・・?」


後醍醐天皇     「武家からも公家からも不満が上がってる。これは倒幕するべきなのでは。(正中の変元弘の乱)」
後醍醐天皇     「倒幕できてしまった。これからは天皇が政治する事にするわ(建武の新政)」
足利尊氏      「北条氏を討伐してくるから、征夷大将軍にならしてくれや」
後醍醐天皇     「それはあかん」
足利尊氏      「なんでやねん、武家に厳し過ぎんねん、ふざけんなや」
後醍醐天皇足利尊氏「対決じゃい!(建武の乱)」


室町時代(首都:平安京/幕府:室町幕府


光明天皇「あんたが征夷大将軍や」
足利尊氏「やったぜ、長い道のりだったぜ。ほな、京都に室町幕府作るで。」
光明天皇「俺らは北朝やけどな、後醍醐のやつが南朝作りよったんや」
足利尊氏「ほないつか統一せんとあかんわな」


足利義満「三代将軍やで!南北朝を統一したったわ!」
足利義満「三代将軍やで!隠居するために金閣寺作ったったわ!」
足利義満「三代将軍やで!一休さんとトンチ合戦したったわ!」


足利義政「八代将軍やで。子供できんかったし、弟に政権譲るわ」
足利義政「八代将軍やで。子供できてもうたわ、やっぱ息子に政権握らせようかな」
足利義政「八代将軍やで。後継者決めるの面倒臭いから、自分らで勝手に決めてもらってええで」
足利義視(弟) 「おい、俺やろ」
足利義尚(息子)「いや、俺やろ」
義視 VS 義尚  「対決じゃい!(応仁の乱)」


農民「今なら幕府倒せるのでは?(一揆の始まり)」
守護「今なら幕府倒せるのでは?(下剋上の始まり)」


ポルトガル「お届け物でーす(鉄砲伝来)」
スペイン 「お届け物でーす(キリスト教伝来)」


今川義元「信長の父親が死んだらしい。信長は戦歴少ないし軍事力も少ないし勝てるやろ。攻め入ったれ。」
織田信長今川義元、討ち取ったりー(桶狭間の戦い)」


足利義昭「13代将軍が倒されたから、幕府復興手伝ってくれんじゃろうか」
織田信長「ええで」


足利義昭「やっぱり信長の言いなりになるの嫌だから、信玄さん助けて」
武田信玄「ええで」
織田信長「武田軍が攻め入ってきた、家康さん手伝ってくれ」
徳川家康「ええで」
武田軍 VS 信長・家康軍「対決じゃい!(三方ヶ原の戦い)」


足利義昭「武田軍が勝ったけど、まだ信長生きてんのかい。槇島城に立てこもっておこう」
織田信長「何じゃあいつ、恩を仇で返しやがって、マジでふざけんなし(槇島城の戦い)」
幕府  「幕府の将軍が死んじゃったので、室町幕府はこれにて終了でーす」


安土桃山時代(首都:平安京/幕府:なし)


明智光秀織田信長、討ち取ったりー(本能寺の変)」
豊臣秀吉明智光秀、討ち取ったりー(山崎の戦い)」


豊臣秀吉      「ポックリ」
五大老徳川家康) 「(どうする・・・?)」
五大老毛利輝元) 「(どうする・・・?)」
五大老前田利家) 「(どうする・・・?)」
五大老宇喜多秀家)「(どうする・・・?)」
五大老小早川隆景)「(どうする・・・?)」


前田利家「ポックリ」
石田三成「前田さん、後は僕に任せてください」


東軍    「徳川!」
西軍    「石田!毛利!宇喜多!小早川!」
東軍 VS 西軍「いざ・・・勝負!!!(関ヶ原の戦い)」


▼江戸時代(首都:平安京/幕府:江戸幕府


後陽成天皇「あんたが征夷大将軍や」
徳川家康 「あざーす。ほな、江戸に江戸幕府作るで。
      これからは幕府も朝廷も対等な(禁中並公家諸法度)」


幕府  「財源が米から金に変わった。みんな米を作らなくなった。困った。」
徳川吉宗享保の改革で飢饉脱出!(失敗)」
松平定信寛政の改革で飢饉脱出!(失敗)」
水野忠邦天保の改革で飢饉脱出!(失敗)」


ロシア 「通商しようや」
イギリス「通商しようや」
アメリカ「通商しようや」
幕府  「嫌だ!(異国船打払令。漂流者を助けてくれたのに砲撃したりしてた)」


イギリス VS 清「アヘン戦争じゃ、おら」
幕府     「イギリスの方が小さいのに、清に勝ったらしい...怖い...(イギリス船に物資を提供)」


ペリー「開国してや」
幕府 「黒船だ...黒いしデカい...怖い...(アメリカ船に物資を提供)」


幕府  「朝廷さん、藩さん、どうしたらいいかな」
朝廷・藩「は?今まで意見求めて来なかったのに、急に求めてくんなや」


井伊直弼「怖いから日米和親条約とか日米修好通商条約に調印したよ」
一橋派 「は、ふざけんなし」
幕府  「うるせえ(安政の大獄で反対派を罰する)」
水戸藩 「は、ふざけんなし(桜田門外の変井伊直弼を罰する)」


薩摩藩「幕府は朝廷とあるべきでしょ(公武合体派)」
長州藩「幕府なくていいし、天皇中心で外国打ちのめそうや(尊王攘夷派)」
土佐藩「朝廷に仕えるという意味では同じなんだし軍事協力しようや(薩長同盟)」


幕府「討幕怖いので、政権を朝廷に返します(=大政奉還)」



■■■幕府が崩壊した後の時代(1867年~)■■■

以前まとめた以下のエントリーを参照。(まとめるのに疲れてしまった)

tanakanata7190.hatenablog.jp



最後に

学生時代に学んだはずなのに、改めて学び直すと、新しい発見がたくさんあった。

権力や武力は持ってしまうと争いに発展してしまうのは今でも変わらないし、歴史から学べる事はたくさんあるわね・・・。

(※なお、この記事は今後も都度調べて、都度更新していく予定。)

「心理的安全性」を高めるために、テレビ番組のMCを真似てみる。

心理的安全性とは

1999年にハーバード大学の組織行動学者であるエイミー・エドモンドソンが「Psychological Safety and Learning Behavior in Work Teams」という論文を発表した。


2016年にGoogleのリサーチチームが「心理的安全性を高めると、チームのパフォーマンスと創造性が向上する」という事を発見・発表した。


心理的安全性」という言葉が世に出るようになってから間もなくしてコロナ禍となり、今までとは異なるコミュニケーション体系を取る事を余儀なくされ、必然的に概念が広まっていった。


論文のINTRODUCTIONを読んだので要約してみた

昨今はVUCAな時代である。

  • Volatility : 変動性
  • Uncertainty : 不確実性
  • Complexity : 複雑性
  • Ambiguity : 曖昧性


VUCAな時代を生き抜くには、以下のような行動が必要となってくる。

  • 質問する
  • 助けを求める
  • 実証されていない行動を試す
  • フィードバックを求める


しかし、上記の行動には、以下のような不安要素を抱えるリスクが介在している。

  • Ignorant : 無知だと思われる不安
  • Incompetent : 無能だと思われる不安
  • Negative : 否定的だと思われる不安
  • Disruptive : 破壊的だと思われる不安


組織では多かれ少なかれ評価が行われており、評価の脅威によって上記の不安要素を更に深刻化させている。
そのため、リスクを回避して評価を受けるために、上記の行動を起こさないという選択が取られてしまう。


上記のリスクを冒すのに適した職場環境である事を認識する指標として「心理的安全性」という言葉を用いている。
心理的安全性が高く、リスクを冒せる職場では、以下のようなことはないと信じられている。

  • 自分が間違いを犯しても、他の人がそのことで罰を与えたり、自分を低く評価したりすることはない
  • ヘルプや情報、フィードバックを求めても、他の人が恨んだり罰したりすることはない


結果的に、上記のようなリスクを取る自信を育み、それによって学習から得られる関連した利益を得ることができる。


心理的安全性を高めるために

GoogleのreWorkでは、以下のように記載されている。

  1. 仕事を実行の機会ではなく学習の機会と捉える。
  2. 自分が間違うということを認める。
  3. 好奇心を形にし、積極的に質問する。

「効果的なチームとは何か」を知る - re:Work


リクルートMSでは、以下のように記載されている。

  1. 心理的安全性を体験できる仕組みをつくる
  2. 特定の人に偏らず発言できるようにする
  3. 何のために発言するのか共通した価値観を持つ
  4. アサーティブ・コミュニケーションを心掛ける
  5. 飲み会や食事会を実施する

心理的安全性とは - 人材育成・研修・マネジメント用語集 - Recruit Management Solutions


その他のサイトでも大概同じような事が書かれている。


テレビ番組のMCを真似てみる

MC(Master of Ceremony)とは、司会者であり進行役である。

番組の流れを把握し、テーマごとに区切って、ゲストやひな壇芸人からトークを引き出す。


アメトーーク』や『踊るさんま御殿』などを例に挙げると分かりやすいだろう。

一つのトークテーマをゲストやひな壇芸人に満遍なく振る。
話が盛り上がったら掘り下げたり他の人に振ってみたり、
話が脱線しそうになったら道筋を戻したり、
話が尽きたらトークテーマを変えたりなど、全体のファシリテートを行っている。


MCが全員の表情を見ながら、誰が話したそうにしているか、発言量が特定の人に偏ってないか、まだ話してない人はいないかなどを把握しながら、全員で番組を作り上げる。


無知だと思われても、無能だと思われても、否定的だと思われても、破壊的だと思われても、必ずMCが拾って適切な着地点を見つける。
そのためにはひな壇のガヤ芸人を使う事だってあるし、MCを補助するために裏回しが存在したりもしている。


仕事でも同じようにすればよい。

会議のファシリテーターである議長が全体を把握し、全員の表情や声色を見ながら会議を回していく。
発言してない人には名指しで振ってみたり、意見に偏りが出ないように反対意見を募ってみたり、話が盛り上がらなかったらトークテーマを変えてみたり。
自信がないのであれば、事前に参加者にネゴっておいて、裏回ししてもらうという手段も取れる。


テレビはオワコンだとか言われる事もあるが、テレビから学べる事はまだまだたくさんある。

知識労働における労働とは?

😶労働の分類

まず、労働は「肉体労働」「知識労働」の2種類に分けられる。


肉体労働は「ブルーカラー」とも呼ばれ、製造業・建設業・鉱業・農業・林業・漁業などの業種を指す。
知識労働は「ホワイトカラー」とも呼ばれ、事務職や管理職などを指す。

(「ブルーカラーは業種なのに、ホワイトカラーは職種なのか」という疑問を持った人もいるだろうが、僕も同じ疑問を持ったので、ここでは深掘りしない事にする)


歴史<日本史編>

元々人間は狩猟や農耕で生活していた。
狩猟や農耕が上手い人は重宝されて権力を得た。
権力によって土地を獲得して管理していき豪族が誕生した。
豪族の権力が拡大したため、貴族が豪族を制した。
貴族が法を作り、法の下で土地が分配され、法の下で納税が課せられた。


土地を耕し、農作物を生産し、年貢として納めている農民は、「肉体労働」であるといえる。
一方、土地の管理や、生産性向上の指示、それによる対価を得る貴族は、「知識労働」であるといえる。


歴史<哲学史編>

以前、哲学の歴史についてまとめたが、改めて引用して記載する。

tanakanata7190.hatenablog.jp


西洋哲学は、奴隷制度により下級市民に肉体労働させていたため、高級市民は暇になり、あれこれ思考を働かせるようになった。
東洋哲学は、カースト制度により下級市民に肉体労働させていたため、司祭などは暇になり、あれこれ思考を働かせるようになった。

この思考があらゆる考えのきっかけになり、哲学として産声を上げた。


日本史とは若干異なるが、概ね似たような感じで「肉体労働」と「知識労働」が分けられている。


😶どちらが優位とか劣位とかそういう話ではない

知識労働」という言葉のせいで語弊が生まれそうだが、知識労働者の中にも馬鹿は存在する。

まともに管理ができなくて、逆に生産性を下げてしまう人もいれば、 職権乱用によって富を得ようとして、逆にクーデターを起こされてしまう人もいる。


「肉体労働」も言葉のせいで語弊が生まれそうだが、知者も数多く存在する。

作業効率を上げたり、ムリムダムラを省いて、生産性を向上する人もいれば、 過酷な労働条件に異を唱えて、労働組合を作ったりクーデターを起こす人もいる。


😶「知識」と「馬鹿」と「ビジネス」の三角関係

「知識」は「ビジネス」の役に立つ。 生産性向上や販路拡大のために知識を生かして、効率的に利益を得る事ができる。

しかし、「知識」は「馬鹿」には通じない。 馬の耳に念仏だし、馬鹿に付ける薬はないし、馬鹿は「ビジネス」を扱う事ができない。


知識は馬鹿に通じないし、
馬鹿はビジネスを扱えないし、
ビジネスは知識に抗えない。


ビジネスを成功に導き、人間関係を豊かにしていくためには、この三角関係が非常に重要になってくる。


😶知識労働における労働とは?

肉体労働に比べて知識労働というのは、成果に即時性がないし、成果の効果測定も難しい。

あらゆる情報をインプットし、あらゆる可能性を検証し、最終的に実践して、初めて効果が得られる。 その効果も良いか悪いかは少し時間が経ってみないと分からない事もあるし、再現性のある効果なのかも不明である。


アウトプットするのが仕事というのは当たり前だが、インプットするのも仕事だし、考える事も仕事と言われると、一体どこまでが仕事なのだろう。


タバコ休憩も仕事?
ネットサーフィンも仕事?
読書も仕事?

通勤時間中に仕事の事を考えてるのも仕事?
休日に仕事の事を考えてるのも仕事?


これらを全て「仕事」として全部認めてたら訳が分からなくなる。 だから、ある程度縛るために法律や就業規則があるのだろう。



・・・と、経営者側の立場で考えてみたけど、「知識労働」の概念ってめちゃめちゃ難しいな。

ジェンダーフリーの自由と不自由

ジェンダーフリー」は、本当に「フリー」なのか

昨今「ジェンダーフリー」について議論される事が多くなった。


「男女差別」という言葉にはネガティブな印象を感じるが、
ジェンダーフリー」という言葉にはポジティブな印象を感じる。

ポジティブな印象があるからこそ、政府や企業は「ジェンダーフリー」という言葉を使用しているのだと思う。


しかし、本当に「ジェンダーフリー」はポジティブなのか。
そして、本当に「フリー(自由)」なのか。


ジェンダーフリー」と「アンコンシャスバイアス」

例えば、IT業界が「ジェンダーフリーを掲げて採用活動します!」と言い始めるとする。

ジェンダーフリーを掲げて性差なく募集しても男性しか来ないし、
ジェンダーフリーを掲げて女性だけ募集しても批判しか来ない。


例えば、コスメ業界が「ジェンダーフリーを掲げて採用活動します!」と言い始めるとする。

ジェンダーフリーを掲げて性差なく募集しても女性しか来ないし、
ジェンダーフリーを掲げて男性だけ募集しても批判しか来ない。


これには、個人個人が普遍的に持っている「アンコンシャスバイアス」が関係している。

「アンコンシャスバイアス」による無意識的な偏見を自分に向けてしまっているため、
女性自身は「IT業界で働けるかな・・・。」と不安になり、
男性自身は「コスメ業界で働けるかな・・・。」と不安になる。


つまるところ、「ジェンダーフリー」として暗黙的に掲げられている性の対象者(上例の場合、IT業界だと女性、コスメ業界だと男性)が殻にこもってるだけのように感じる。


つまるところ、「ジェンダーフリー」という言葉にポジティブな印象を感じる事ができないように思える。


義務教育で習いましたよね?

ジェンダーフリー」なんて言葉はどうでもよい。


義務教育で「職業選択の自由」「男女平等参画社会」と習ったのだから、個々で好きに働けばよい。

好きに働けばよいのに働かないなら、それは社会ではなく個人の問題。


日本はアメリカじゃないけど、日本だって自由の国なんだから、自由に働けばいい。


自由と不自由

自由過ぎて不自由さを感じるなら、不自由さを少し設けてあげればいい。


例えば「多角的な視点・視座・視野を取り入れるため、男女5名ずつ募集します」みたいに縛ればよい。

そうすれば参加障壁が格段に下がるので、結果的に同程度の人数が集まる。


わざわざ「ジェンダーフリー」なんて言葉を使わない方が、実現したい事を実現できる事も多い。


神様からお言葉を頂戴しています

”言葉”なんてものは、人間が作り上げた概念でしかないし、

”性別”なんてものは、神様が気まぐれで与えたものでしかないし、

更に高次元では性別なんて関係ないので、

あまり「ジェンダーフリー」という言葉に囚われずに生きるとよいと思います。

「哲学」について改めてまとめた。

3年前、ベスト新書から出版されている「使う哲学」を読んでまとめて、ブログを書いた。

tanakanata7190.hatenablog.jp

その後も哲学について勉強したり考えたりする事が多かったので、改めて勉強し直してまとめてみた。


😶哲学とは

知を愛するという意味の「愛知」を分野・学問。
英語では「philosophy(フィロソフィー)」という。


😶分類

大きく分けると、「西洋哲学」「東洋哲学」に分類される。

前者は「イスラム哲学」「ヨーロッパ哲学」に分類され、
後者は「インド哲学」「中国哲学」「日本哲学」に分類される。


😶西洋哲学と東洋哲学の違い

最初は、どちらも暇人によって作り出された。

西洋哲学は、奴隷制度により下級市民に肉体労働させていたため、高級市民は暇になり、あれこれ思考を働かせるようになった。
東洋哲学は、カースト制度により下級市民に肉体労働させていたため、司祭などは暇になり、あれこれ思考を働かせるようになった。

この思考があらゆる考えのきっかけになり、哲学として産声を上げた。


西洋哲学は、"議論"から"真理"へ辿り着こうとする。
東洋哲学は、"真理"から"議論"へ発展する。

なので、
西洋哲学は、プラトンが「理想主義」を掲げてるのに弟子アリストテレスは「現実主義」を掲げたり、「イギリス経験論」が生まれたかと思えば「ドイツ観念論」が生まれて、議論が発展して真理に近付こうとする。
東洋哲学は、釈迦が仏陀となり、仏陀こそ真理となり、「仏陀はこう考えてたんだ!」という感じで真理をベースとして議論が発展する。


😶世紀別:西洋哲学の主義の軌跡

■紀元前6世紀~:根源主義【radicalism(ラディカリズム)】

▼説明

(「根源主義」なんて言葉はないけど、他と比較するために分かりやすい表現方法として採用した。ゴメン。)

▼主な人物


■紀元前5世紀~:相対主義【relativism(レラティビズム)】

▼説明(Wikipedia

相対主義は、経験事象に対する見方が、その他の経験事象に対する見方との相対的関係すなわち依存関係においてしか客観的にはありえない、という考え方である。
相対主義 - Wikipedia

▼概要

万物の根源は何だって話をしている中で、ソフィスト=賢い人が誕生。 (あれこれ考える人が出てきたというだけの話)

ソフィストは教えと引き換えに金銭を受け取っていた。 (現代でいう教師のような存在)

▼主な人物


■紀元前4世紀~:主知主義【intellectualism(インテレクチュアリズム)】

▼説明(Wikipedia

主知主義とは、人間の精神(魂)を「知性・理性(理知)」「意志・気概」「感情・欲望」に三分割する見方[1]の中で、知性・理性の働きを(意志や感情よりも)重視する哲学・神学・心理学・文学上の立場のこと。知性主義とも言う。
主知主義 - Wikipedia

▼概要

ソフィストが唱える相対主義は、観点を変えさえすれば、どのような異なる解釈判断も可能であった。 つまり詭弁であり、普遍的な思想とは言えないのであった。

そこで、ソクラテスが登場し「勇気とは?」「正義とは?」と、ソフィストを問い質す。 すると、ソフィストは答える事ができず、たじろいだ。 これに感銘を受けた若者たちが「新たなソフィストだ!」として、ソクラテスが誕生した。

▼主な人物


■紀元前4世紀~:理想主義【idealism(アイディアリズム)】

▼説明(Wikipedia

哲学において観念論もしくはイデアリスムとは、さまざまな意味があるが、認識の妥当性に関する説の一つで、事物の存在と在り方は当の事物についてのidea(イデア、観念)によって規定される、という考え方などを指す。
観念論 - Wikipedia

▼概要

ソクラテスの弟子として、プラトンが誕生。

プラトンは「ソクラテスは哲学者で、ソフィストは知者」と明確に区別した。

▼主な人物


■紀元前3世紀~:現実主義【realism(リアリズム)】

▼説明(Wikipedia

現実主義とは、無政府状態の国際関係を国益と勢力均衡の観点から分析する国際政治学の主要な理論を言う。
現実主義 - Wikipedia

▼概要

プラトンの弟子として、アリストテレスが誕生。

アリストテレスプラトンイデア論には反対し、現実の方に本質があるとした。

▼主な人物


■紀元前3世紀~:ギリシャ主義【hellenism(ヘレニズム)】

▼説明(Wikipedia

ヘレニズムまたはギリシア主義、ギリシャ主義とは、ギリシア人(ヘレネス)の神話的祖先「ヘレーン」に由来する語。その用法は様々である。
ヘレニズム - Wikipedia

▼概要

アレクサンドロスの死亡以降の時代。

その昔、「ギリシア文化」と「オリエント文化」が存在した。 アレクサンドロスが東方遠征した事により、文化が融合して「ヘレニズム文化」が誕生した。

「ヘレニズム文化」の配下では、以下3つの流派が存在した。 ちなみに、この思想は長く続き、次に出てくる「イギリス経験論」まで続く。

▼主な人物(というか流派)

  • ストア派  「苦痛であっても、善行はしましょう」
  • エピクロス派「苦痛は回避しましょう」
  • 懐疑派   「確定的なものは何もない」


■16世紀~:経験主義【empiricism(エムピリシズム)】

▼説明(Wikipedia

経験論、あるいは、経験主義とは、人間の全ての知識は我々の経験に由来する、とする哲学上または心理学上の立場である。
経験論 - Wikipedia

▼概要

提唱者はフランシス・ベーコン

後述する合理主義は演繹法なのに対し、経験主義は帰納法

▼主な人物


■17世紀~:合理主義【rationalism(ラショナリズム)】

▼説明(Wikipedia

合理主義哲学は、17-18世紀の近代哲学・認識論における一派。大陸合理主義、大陸合理論とも呼ばれる。
合理主義哲学 - Wikipedia

▼概要

提唱者はルネ・デカルト。 経験主義に対する立場として誕生。

経験主義は帰納法なのに対し、合理主義は演繹法

▼主な人物


■20世紀半ば~:実存主義【existentialism(エクステンシャリズム)】

▼説明(Wikipedia

実存主義とは、人間の実存を哲学の中心におく思想的立場。あるいは本質存在に対する現実存在の優位を説く思想。
実存主義 - Wikipedia

▼主な人物


■20世紀半ば~:本質主義【essentialism(エッセンシャリズム)】

▼説明(Wikipedia

本質主義とは、本質(事物の変化しない核心部分)を自立的な実体、客体的な実在物であるとみなした上で、個別の事物は必ずその本質を有し、それによってその内実を規定されている、という考えをいう。
本質主義 - Wikipedia

▼主な人物

  • エトムント・フッサール  「エポケー」「間主観性
  • モーリス・メルロ・ポンティ「身体を中心にして人間を捉える」


■20世紀半ば~:構造主義【structuralism(ストラクチャリズム)】

▼説明(Wikipedia

構造主義とは、狭義には1960年代に登場し主にフランスで発展していった20世紀の現代思想のひとつである。
構造主義 - Wikipedia

▼主な人物


■20世紀後半~:ポスト構造主義【post-structuralism(ポスト・ストラクチャリズム)】

▼説明(Wikipedia

ポスト構造主義は1960年後半から1970年後半頃までにフランスで誕生した思想運動の総称である。
ポスト構造主義 - Wikipedia

▼主な人物



参考サイト

tanakanata7190.hatenablog.jp

note.com

www.nekopajamas.net

genzi1013.hatenablog.com

「システム運用アンチパターン」を読んだのでまとめた。

オライリー社から出版されている「システム運用アンチパターン―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション―」を読んだのでまとめた。

www.oreilly.co.jp



📖前提

1章ではアンチパターンについては語られず、DevOpsについて語られている。

1章:DepOpsを構成するもの

DevOpsを支える4つの柱「CAMS」

  • Culture(文化)
  • Automation(自動化)
  • Metrics(メトリクス)
  • Sharing(共有)

DevOpsでは、CAMSによって、以下のゴールを目指す。

  • チーム間コラボレーションの強化
  • 不必要なゲートや作業受渡しの削減
  • 開発チームがシステムを所有するために必要なツールと権限の提供
  • 再現性のある予測可能なプロセスの構築
  • アプリケーションの本番環境に対する責任の共有

DevOpsムーブメントの重要な点は、以下2つ。

  • 文化的な問題に正面から取組んでいる事
  • 人間の労力の浪費によるコストに焦点を当てている事



📖アンチパターン紹介

アンチパターンの説明は2章以降で語られる。
「章タイトル=アンチパターン名」なので、それぞれについて見ていく。


2章:パターナリスト症候群

信頼の欠如によりパターナリスト症候群が発症し、過剰なまでのゲートキーパータスクが生まれる。

ゲートキーパータスクは、以下のような問題を発生させる。

  • システム全体の変更を遅らせる
  • 余分なコミュニケーションが増える
  • ヒューマンエラーでデプロイができなくなる など

以下の手順で、パターナリスト症候群を解消する。

  1. チームを編成
  2. プロセスを自動化するメリットを議論
  3. アプローチの概要を作る
    • 承認プロセス
    • ロギングプロセス
    • 通知プロセス
    • エラー処理
  4. 上層部に伝える
  5. 実行する

※重要なのは、何の価値も生み出していないプロセスを自動化する事(全部が全部自動化したいわけではない。必要な手作業も存在する。)


3章:盲目状態での運用

開発者は、
自分のコードが本番環境でどう動作しているのか理解する必要がある。
(「開発環境で動いてるんだから、アプリには問題ない」と責任転嫁しない)

運用者は、
プロダクトを理解する必要がある。
(「機能や挙動はアプリの範疇であり、インフラには関係ない」と責任転嫁しない)

お互いにお互いのせいにせず、見える化するために「メトリクス」と「ログ」を整える。

メトリクスは、以下の通り。

  • スループット:どのくらいの頻度で処理してる?
  • エラー率  :どのくらいの頻度で失敗してる?
  • レイテンシ :完了するまでどれくらいかかる?

ログは、以下の通り。

  • DEBUG
  • INFO
  • WARN
  • ERROR
  • FATAL


4章:情報ではなくデータ

「データ」は、整理されていない生の事実。
「情報」 は、データに構造や文脈を与えたもの。

「データ」を「情報」に昇華させるため、以下を行う。

  1. 構造化するためにウィジェットを作る(折れ線、棒、ゲージなど)
  2. 文脈を与える(色付け、閾値、時間比較など)
  3. 優先度をつけて配置する(緊急度、重要度など)
  4. 命名する(対象のウィジェット=情報を見つけやすいように)


5章:最後の味付けとしての品質

継続的デプロイ・継続的デリバリをするため、以下を行う。

  1. デプロイパイプラインを作る
  2. 自動テストを行う

「DevOps」ではなく「DevSecOps」の観点だと、デプロイパイプライン上で以下も行う。

  • セキュリティスキャン
  • セキュリティテスト

テストインフラは、運用チームが管理・所有する。
(本番環境で何が動いているかを把握すべきは運用チーム。
 そのためのテストコードやテストスイートを提供しているのが開発チーム。)


6章:アラート疲れ

頻繁に多くのアラートに晒される事で、アラートに鈍感になっていく症状。
(システム的にも、メンタル的にも、従業員満足度的にも、危険な症状。)

これを解消するためには、オンコールローテーションを導入する。

  • 4~8人のチームで、1週間ごとに交代する
  • オンコールを担当するスタッフには、担当する週はオンコールサポートプロジェクトに専念させる(他業務は他スタッフに任せる)
  • スタッフとして、プライマリ・セカンダリ・マネージャを配置する
  • スタッフには補償を設ける(金銭?休暇?在宅勤務?)
  • SLOを定義する(確認までの時間、開始までの時間、解決までの時間)
  • アラート発生時は、"解決"ではなく"トリアージ"にフォーカスするのも大切
  • いつ・誰が・どんなアラートを受けて対応しているかを追跡する

なお、「良いアラート」とは、以下の通り。

  • 行動可能である
  • イムリーである
  • 適切に優先順位付けされている


7章:空の道具箱

「自動化しましょう」という話を長ったらしく書いてるだけなので、ここでの説明は割愛。

図7-5は重要なので、これについては書籍で確認してください。 (完全な自動化ではなく、ユーザの確認や入力が必要なケースも存在するため)


8章:業務時間外のデプロイ

リリースプロセスが遅いと、以下のような悪影響を及ぼす。

  • リリースの詰め込み
  • 大急ぎの機能
  • 重厚な変更管理プロセス など

デプロイは日常的に行う必要があるが、以下のような問題も抱えている。

  • 本番環境とST環境の構成を同じにできない
  • 並列実効性や想定外のユーザ実行など不確定要素も多い など

デプロイが遅れたり失敗したりすると、フィードバックループの悪循環が起きる。(図8-2)

デプロイを頻繁に行う事で恐怖心を払拭するため、以下を行う。

デプロイは、以下のレイヤで考える。

  • 機能デプロイ
    • 機能フラグを設けるとよい
  • フリートデプロイ
    • ブルーグリーンデプロイやローリングデプロイを行う
  • アーティファクトデプロイ
    • OSのパッケージ管理システムを使う
  • データベースデプロイ
    • ALTERやCRUDやバージョニングなどのルール決めをしておく


9章:せっかくのインシデントを無駄にする

懲罰や非難の文化があると、インシデントが発生した時に、責任のなすりつけ合いが発生し、透明性が欠如していく。

問題は「個人」ではなく「システム」にあるので、システムに焦点を当てた上で、以下を行う。

インシデント発生時は、

  1. 24時間ルール(*1)を厳守した上で、
  2. ポストモーテム(*2)を実施し、
  3. 文書作成(*3)も行う。

*1: 記憶が薄れないうちに。感情やエネルギーが冷めないうちに。
*2: 「アフターアクションレポート」「インシデントレポート」「レトロスペクティブ」とも言う。
*3: 発生事象/直接原因/一時処置/根本原因/影響範囲/恒久処置をまとめる。


10章:情報のため込み:ブレントだけが知っている

情報のため込みは、ゲートキーパーの行動が適切か評価されていない事で生じる。

  • ため込みが、意図的でない場合は、本人に自覚させる必要がある
  • ため込みが、意図的な場合は、吐き出させる必要がある
  • ため込みが、文書化の軽視により発生している場合は、吐き出させる必要がある
  • ため込みが、不適切なアクセス制限によって発生している場合は、権限を見直す必要がある

ナレッジの共有には、以下を行う。

  • ナレッジストアの構築
  • チャットツールの導入 など

ナレッジを根付かせるには、以下を行う。

  • ランチ&ラーン
  • ライトニングトーク
  • 外部イベント参加 など


11章:命じられた文化

ピーター・ドラッガー『企業文化は戦略に勝る』

文化には、以下3つの要素がある。

  • 文化的価値観
  • 文化的習慣
  • 信念

文化を根付かせるには、以下を行う。

  • 上記3要素と体現してくれる「文化チーフ」を探す
  • 「社会的習慣」「プロセス的習慣」からアプローチする


12章:多すぎる尺度

アイゼンハワーの意思決定マトリクスに従い、「緊急度×重要度」を定めて、タスク管理する。



😶最後に

個人的な感想だが、章立てが分かりづらかった。

どこがアンチパターンで、どこが事例紹介で、どこが解法なのか、、、というのが章立てとして体系的にまとまっておらず、頭の中で整理しながら読まないといけなかったので、辞書的に読み直すのは困難そうだなと感じた。


あと、本書のターゲットユーザが分からなかった。

アンチパターンを求めている人には11個しかないので少なく感じる。初学者にはボリュームが多いし業務にも寄り過ぎている。感覚的には業界歴2,3年の人が読む感じ・・・??


という余談。

https://www.oreilly.co.jp/books/images/picture_large978-4-87311-984-7.jpeg

最近、心がしんどい。

しんどい理由は分からない

  • 担当しているバグまみれのレガシーシステムに予算がつかずに、放置せざるを得ない状況だからだろうか。
  • そのシステムの運用にムリムダムラが多過ぎたり体系的だったりせず属人化しているのに、それに対して弊社の誰も何とも思ってないからだろうか。
  • 開発ベンダと反りが合わず、そのベンダと関わりたくないと思っているのに、ベンダロックインしているせいで関わらざるを得ないという状況だからだろうか。
  • いずれフリーランスになったり起業する事に対して、プレッシャーが重くのしかかっているせいだろうか。
  • 自分のせいとはいえ歯を折ったからだろうか。
  • 今年の夏は暑くなるとニュースで見かけたからだろうか。
  • 最近お酒をあまり飲んでいないからだろうか。
  • こんな不安定な性格の僕に妻を巻き込んでよいのかと考えているからだろうか。

明確な理由は分からないが、全ての要因が悪い相乗効果を起こしている気がしてならない。


できてない事が多過ぎる

  • アプリの個人開発も、改修すべき事は分かっているのにできてない。
  • そのアプリで使っているデータも、毎週チェックしてデータ更新すべきなのにできてない。
  • そのアプリを宣伝するためのSNSも、決めた曜日にポストすればいいだけなのにできてない。
  • ジムに行って身体の維持をしようとしてたけど、あれやこれやと考えてしまって全然身体が動かないので行けてない。
  • 仕事においても、次にすべき事は頭の中で考えられているけど、「自分が気付いて実践しても、気付かない人がいる限り全て自分がやらなきゃいけないので面倒。」と考えてしまってできてない。
  • 掃除も洗濯も気付いた時にやればいいのにできてないし、料理も気分転換や健康のためにやればいいのにできてない。

できてないというか、やる気力がない。頭では分かってるのに、身体が動かない。


逆に、何ができている?

  • 出社日には定時に出社できている。
  • タスク管理もできているし、期日よりずっと前に完遂させている。
  • 会議があれば発言や提案もするし、気になる点は聞けている。
  • 起業のためにすべき事を調査して、事業計画書を作ったり、コンテンツ一覧を作ったり、コンテンツを作ったりもできている。

...ここまでつらつら書き連ねていて分かった事が、一つだけある。


何の価値も提供できていない自分

まずは、できている事を見てみてみよう。

特に何か価値を見出せているわけではない。
起業のための調査や資料作りはまだ何の価値にもなってないのは明白。
タスク管理やタスク完遂、会議での発言や提案は価値に繋がっているように見えるが、この組織で2年間働いてきてその価値を感じれた事が一度も無い。
自分に影響力がないだけかもしれないが、エコーチェンバーかつフィルターバブルが蔓延している組織において、声が届かないのは大きなストレスとなる。


次に、できてない事を見てみよう。

何か価値を見出そうとしている事は分かる。
僕が作っているアプリに価値があるという自負はしているし、身体的な健康は精神的な健康に繋がる事も分かっているし、組織の価値を底上げしようとしているし、家事も積極的に行おうとしている。


最後に、各要因の悪い相乗効果を見てみよう。

様々な要因で精神的に思い詰めている事が分かる。
しかも、そのどれもが他人に相談すれば解決しそうな問題ではある。
つまり、誰にも相談する事ができず、フラストレーションが溜まりまくっているのが根本原因な気がする。


しかし、僕には友達がいない。

知り合いと酒でも飲みながら話をしたいが、コロナのせいで気軽に呼び出せない。
最も近くに居る妻も、ポジティブな話は聞いてくれるが、ネガティブな話は聞いてくれない。


自己憐憫』『悲劇のヒロイン』

心理学的には『自己憐憫』といったり、世間一般では『悲劇のヒロイン』といったりする類いなんだとは思っている。


一昔前に流行った『承認欲求』とはまた違う感覚であり、「認められたい」という感情はこれっぽっちもないが、「報われないな」という感情はある。
かといって『自己否定感』が強いかといえば強くはなく、『自己肯定感』の方が強い方である。
『自己肯定感』が強いからこそ、現実とのギャップに苛まれて、「報われない」と自己完結しているんだろうと思う。


この症状を自覚しているからこそ、あまり感情を外に出さないようにしている。
その代わりに、最も近くに居る妻には迷惑をかけているとは思うが・・・。


「報われる」とは?

『大器晩成』という言葉があるように、今はエネルギーを溜めている時期で、良き時に放出され、その時に報われるのかもしれない。 はたまた、死ぬまで報われる事はないのかもしれない。


やはり、本ブログで何度も取り上げているが、ジャンポール・サルトルの遺した以下の言葉が胸に刺さる。

「実存は本質に先立つ」
「私は絶望に抵抗しながら、希望と共に死ぬだろう」


人間は、実存主義で生きていくためのノウハウを得る必要がある。