心理的安全性は日本企業では実現しにくいかもしれない

「心理的安全性」という概念は、まだ、日本人には早すぎる。 | Books&Appsという記事がとても参考になったのでメモ。

【参考】
「心理的安全性」という概念は、まだ、日本人には早すぎる。 | Books&Apps

Masanori Kusunoki / 楠 正憲さんはTwitterを使っています 「日本で個人主義が根付いてないというのは、漱石の昔から言い古されてきた話題ではあるけれども、だから日本人には早すぎるなんて緩いことをいってると、いよいよオワコンに / “「心理的安全性」という概念は、まだ、日本人には早すぎる。 | Books&Apps” https://t.co/NPzz4gkmFs」 / Twitter

akipiiさんはTwitterを使っています 「良い記事。心理的安全性は人間関係のリスクを取っても率直に言える組織風土を指す。いまもいじめがはびこる日本では根付かないかもしれない。「心理的安全性」という概念は、まだ、日本人には早すぎる。 https://t.co/9Em4UXSWCe」 / Twitter

僕は心理的安全性という概念をきちんと理解できていなかったと思う。
「心理的安全性」という概念は、まだ、日本人には早すぎる。 | Books&Appsの通り「ハーバードビジネススクール教授、エイミー・C・エドモンドソンは、「心理的安全性」の定義を「対人関係のリスクをとっても安全だと信じられる職場環境」としている」ならば、対人関係を気にせず率直に意見を述べられる組織風土や組織文化を指すわけだ。

そういう心理的安全性の定義を踏まえると、特に日本の企業や学校では、心理的安全性はとても実現しづらい。
同調圧力、集団主義的傾向、権力者への従順さなどが日本人という個人を脅かすから。

日本人は、相手と話す時に彼との序列順位をいつも気にしている。
日本人は、年功序列、多重下請け構造という目に見えない社会構造をいつも気にしている。
気にしなければ、生活できない人が多いから。

でも、ソフトウェアを中核としたビジネスモデルで発展させていくには、優秀な人材を集めて、彼らが率直に意見をぶつけて、知的バトルの中から、規模の経済を打ち倒すアイデアや方策を生み出さねばならない。
だから、心理的安全性という組織文化は非常に重要なのだ。
「心理的安全性の低い組織には、賢く、有能な人間は集まらない。パフォーマンスが著しく落ちるからだ。」
たぶんそういうところが従来の既存企業には欠落しているのだろう。

とはいえ、特にIT人材は日本人だけでは今後不足していくので、早晩、海外のIT技術者を日本企業も取り込んでいかないといけなくなる。
そんな状況で、心理的安全性を自ら実践していけるのか？

昭和や平成初期の時代の雰囲気から抜け出せない人を外すしか解決できないのでは、と思ったりもする。

値オブジェクトの設計がオブジェクト指向モデリングの最初の登山口

先日7/14に開催された｢アジャイル開発におけるモデリング活用実践セミナー｣のオンライン動画を見ていて、興味深かった。
羽生田さん、増田さん、原田さん達の会話が面白かった。
気になった発言をラフなメモ。
自分の感想も混じっていて、全くロジカルでない。

【参考】
｢アジャイル開発におけるモデリング活用実践セミナー｣（2021.07.14開催） - UMTP 特定非営利活動法人UMLモデリング推進協議会

ドメイン駆動設計が好きで、ベンチャー企業のWebサービスの開発で使っている

最近は、基幹系システムのリプレースでドメイン駆動設計を使いたい、という話も多く来ている
すごく難しいけど、やりがいもあるし面白い

オブジェクト指向モデリングのワークショップでモデルを書こうとすると、みんな、フレームワークが前提でモデルを書いてしまう
ドメインの外側ばかり話している
肝心のドメインをプログラミングしようとすると、意外に誰も書けない
まずは値オブジェクトから始めよう
みんな、値オブジェクトでプログラミングできない
増田さんのオブジェクト指向モデリング本「現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法」は、値オブジェクトから書こうとしているのでお勧め

intやStringのデータ型だけではトランザクションスクリプトみたいに書いてしまう
値オブジェクトが大事
オブジェクト指向では、Immutableな値オブジェクトから始まる
関数的プログラミングとも相性がいい
ドメインに特化してプログラムを書こうとすると、必ず値オブジェクトから始まる
値オブジェクトの設計がオブジェクト指向モデリングの最初の登山口

エンティティを重視するとデータモデリングになってしまう
手続き型プログラミングで、でかいエンティティを書いて、長いトランザクションスクリプトを書くと失敗する
書いていて怖い
データモデリングとオブジェクト指向モデリングは違うと考えた方がいい

エリック・エヴァンスのDDD本「エリック・エヴァンスのドメイン駆動設計」に出てくる例では、OODBを使っていた
昔はデータのストアはOODBでいい、という感じだった
OODBでは性能が出ないので廃れた

業務の複雑さに関するデータのモデリングは、データモデリングの方が一日の長がある

1990年代にモデリングが盛んだったのに、現代ではモデリングが廃れたのは、モデリングが伝承されなかったからではない
むしろ、現代的な課題に対して、長年知られていたモデリング手法のこの部分は今も使えるが、この部分は今は使えない、という交通整理された本がほしいね

2010年代にピアソン本が絶版されたので古いオブジェクト指向モデリング本が手に入らなくなり、エリック・エヴァンスのDDD本「エリック・エヴァンスのドメイン駆動設計」だけが唯一残った
そのために、オブジェクト指向モデリングの歴史に断絶がある

メソッドは3個まで
それができない人は、クラス化、カプセル化が分かってない
入出力処理は手続き型になりやすい

顧客との対話では、UMLを普通に使う
ただし、アクティビティ図、コンテキスト図、データフロー図を使う場合が多い
システム要件に落とす時は、UMLをガンガン使う

要件定義でモックを作るときはHTMLを使う
最近はいい感じですぐにモックデザインが作れる
実データを画面で見せた方が早い

プロダクトオーナーとの対話では、RDRA2.0を使って話する時が多い
システム設計では、UMLを使っている
図を書くのが目的ではなく、会話や意思決定のために使っている

DDDのエンティティはミュータブル？イミュータブル？
Webならイミュータブルが普通でしょ
setter, getterと無関係なモデルにしている
イミュータブルが普通
エンティティに状態は持たせない
void実行でなく、新しい状態のオブジェクト、エンティティを別で返す
Webならイミュータブルが普通
エンティティの状態をSetして変更すると、バグが出そう
イミュータブルだからFreezeしているのでCloneする必要もない

アジャイル開発プロセスとモデリング作業の事例は？

モデリングでも、概念モデルのレベルでプログラミングを書く
合わせてDFDやER図を書く
事業分野の可視化はシステムで書きにくいので、シナリオ、バリューチェーンを書く
バリューチェーンで、どこのプロセスに差別化要素があるか、強みがあるか、を分析する
ビジネスを理解するモデリングとシステムとして動かすプロトタイプの2つを行き来している

増田さんのドメインモデルのサンプルが分かりやすい
パッケージ図でクラス図を分割して、HTMLで一覧にしている
さらに、ユースケースのシナリオからパッケージ図、クラス図まで一気通貫でHTMLにしている
軽量で明快なモデリング
ビジネスモデルとDFD・ER図をつなぎつつ、パッケージ図・クラス図で方にしてHTMLで見せている
増田さんのクラス図は値オブジェクトが中心
取引日、貸し出しも全てクラスになっている
増田さんにとって、モデル駆動とはドキュメント駆動のイメージ
ソースコードとモデルを行き来していて、モデルが自然にドキュメントになっている

Scrumで開発する時に、ユーザーストーリーマッピングを使う場合が多い
このメソッドを実装する時、このメソッドはこの要件から来ていて、この要件はユーザーストーリーマッピングのこの部分に対応する、と辿れる

【感想】
エリック・エヴァンスのドメイン駆動設計や現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法を読むと、ドメインのソースコードが値オブジェクトになっている場合が多い。
その理由は、ドメインをプログラミングに注力しているから、と見ると分かりやすい気はする。
オブジェクト指向でプログラムを書くと、状態を持たせるエンティティが頻出して、バグが出やすい箇所はたいていその部分であり、デバッグしないと追跡できない場合が多いのを思い出した。

IPアドレッシングの計算方法

IPアドレスの計算方法について、理解したことをメモ。
自分のためのラフなメモ。

【参考】

③サブネットマスクとプレフィックス長の2つを覚える ? ランスルネット

④サブネット化したときのホストアドレスと2進数 ? ランスルネット

IPアドレス サブネットマスク・プレフィックス長 早見表 ? ランスルネット

①サブネット化 のメリットの理解 ? ランスルネット

IPアドレッシングを基本から復習しましょ！ その16 | ネットワークのおべんきょしませんか？

社内のネットワーク設計でもオンプレ環境でもAWSのVPCのサブネット分割でも、IPアドレスやネットワークアドレス、CIDERの計算は必要。
IPアドレスを計算するには、サブネット早見表を覚えることと同じ。

【サブネットマスク早見表】
1の個数 ﾋﾞｯﾄﾊﾟﾀｰﾝ SubnetMask 【区切り位＝NWアドレスの倍数】 サブネット個数
1 10000000 128 128 2
2 11000000 192 64 4
3 11100000 224 32 8
4 11110000 240 16 16
5 11111000 248 8 32
6 11111100 252 4 64
7 11111110 254 2 128
8 11111111 255 1 256

サブネットマスク早見表の覚え方はコツがある。
1bitの個数＝8－0bitの個数　⇒255－2^(0bitの個数)＝Subnetmask　から計算すればいい。

例：Subnetmask＝255.255.255.240　⇒255-240＝15=2^4-1　⇒8-4＝4　⇒/24+/4＝/28
例：/27＝24＋3　⇒1bitが3個　⇒0bitが5個　⇒255-31＝224　⇒Subnetmask＝255.255.255.224

たとえば下記の例題みたいな感じ。

【例題】
192.168.1.0のネットワークアドレスを255.255.255.192でサブネッティングすると、IPアドレスの範囲は何か？

255-192=63　⇒63=2^6-1　⇒NWアドレス＝64の倍数
サブネットのネットワークアドレスは、第4クオテットが64の倍数になる
サブネットは4個出来上がる
192.168.1.0
192.168.1.64
192.168.1.128
192.168.1.192
⇒ ブロードキャストアドレスは、ネットワークアドレス－1になる。
192.168.1.63
192.168.1.127
192.168.1.191
192.168.1.255
⇒ IPアドレスの範囲は、ネットワークアドレス＋1～ブロードキャストアドレス－1になる。
192.168.1.1 ～ 192.168.1.62
192.168.1.65 ～ 192.168.1.126
192.168.1.129 ～ 192.168.1.190
192.168.1.193 ～ 192.168.1.254

【例題】
172.16.0.0のネットワークアドレスを/19のサブネットマスクでサブネッティングしたとき、サブネットのネットワークアドレスは？
IPアドレスの範囲は？

/19=/16+/3
⇒8-3=5
⇒NWアドレス＝2^5=32の倍数
⇒ ネットワークアドレスは、第3クオテットが0も含めた32の倍数になる
サブネットは8個できあがる
172.16.0.0
172.16.32.0
172.16.64.0
172.16.96.0
172.16.128.0
172.16.160.0
172.16.192.0
172.16.224.0
⇒ 最初のサブネット172.16.0.0のブロードキャストアドレスは、172.16.32.0－1　より、
172.16.32.0 - 0.0.0.1 = 172.16.31.255
⇒ 最初のサブネットのIPアドレスは、ネットワークアドレス＋1～ブロードキャストアドレス－1　より、
172.16.0.1～172.16.31.254
他も同様。

「インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門」の通り、IPアドレッシングは要件さえケマれば、計算方法は決まっているので、テトリスみたいに決まる。

インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門はインフラエンジニア向けの良本だ: プログラマの思索

Ciscoコマンドで理解したこともリンクしておく。
Linuxコマンドと別物で全く異なるので、理解に時間がかかった。

アクセスリストの設定パターン: プログラマの思索

NATの設定パターン: プログラマの思索

スタティックルートの設定パターン: プログラマの思索

Ciscoのshowコマンド一覧: プログラマの思索

プログラマが「何をやっているか分からない」「何が分からないか分からない」状態から脱出する記事がとても良い

プログラマが「何をやっているか分からない」「何が分からないか分からない」状態から脱出する記事がとても良いのでメモ。

【参考】
(1) 出来るプログラマーやエンジニアの方でも「何をやっているか分からない」「何が分からないか分からない」状態に陥りますか？その時は、どの様にして対処・解決しますか？に対するYuki Sonodaさんの回答 - Quora

RubyコミッタのYuki Yugui Sonodaさん (@yugui)もこんな問題意識を持たれていたらしい。

(引用開始)
私は出来るエンジニアじゃないせいか、何かちょっと経験の浅い分野のことをやると「何をやっているか分からない」「何が分からないか分からない」状態に陥ります。
それで、Stack Overflowで調べたコード片をコピペして動かすことがあります。
最近はGradleのビルドスクリプトの書き方が本当に何も分からなくてStack Overflowに世話になりました。
(引用終了)

Yuki Yugui Sonodaさん (@yugui)の回答なので、本当によく考えられている。
こんな手順を踏む。

チュートリアルやGetting Startedのような案内文書があれば、写経して動かしてみる
→先ほど体験したつまずきや未知の用語を手がかりとしながら概念を理解する
→良い実例を読むとともに利用できる資源を網羅する
→実際にやってみて経験を積む

僕も、Pythonのデータ分析、機械学習＆深層学習、ソフトウェア統計分析、Ciscoネットワークなどを初めて勉強した時、同じような手順を踏んでいたのを思い出した。

上記の手順をもう少し深堀りして考えてみると、野中郁次郎先生のSECIモデルを連想させる。
あるいは、コルブの経験学習理論を連想させる。
この辺りも考えてみたい。

SECIモデルは知識の再利用モデル、または、実践知を生み出すモデルだ: プログラマの思索

「経験学習」とは？学習プロセスや促進させるためのポイントなどご紹介 | BizHint（ビズヒント）- クラウド活用と生産性向上の専門サイト

【公開】XP祭り関西2014講演資料「KPTによるプロセス改善～あなたはPDCAを回したことがありますか？」 #xpjugkansai: プログラマの思索

規模の経済から個人の能力重視へビジネスモデルが変化している

製造業からソフトウェアのビジネスモデル変換の鍵に、規模の経済から個人の能力重視の観点があるツイートを見つけて、なるほどと思った。

akipiiさんはTwitterを使っています 「すごく参考になる。規模の経済から個人の能力重視への変化」 / Twitter

r.ishibashiさんはTwitterを使っています 「この例えは良いな。 https://t.co/xLQjAuij1m https://t.co/17u8ZF9jgM」 / Twitter

(引用開始)
"シスコはスキルがスケール（規模）に勝った唯一の例だと考えていたが、そうではないのだ、と。シスコがうまく活かしているのは、一企業、一産業の枠を超えた大きなうねりなのである。 　従来コンピュータや通信機器の分野で成功するには、数十億ドル規模の大型プロジェクトで大量のエンジニアをとりまとめ、さらに大量の労働者を管理して複雑な電子機器を製造することが必要だった。それをやれる能力が備わっていたから、 ＩＢＭや ＡＴ＆ Ｔは繁栄し、日本は技術集約型の成功を収めることができたのである。だが一九九六年の時点では、成功のカギを握るのはソフトウェアになっていた。そしてソフトウェアなら、大企業でなくても、頭の良い連中が何人かそろえば書き上げることができる。規模の経済から個人のスキルへ──これが、大きな変化のうねりだった。戦争の主流が、正規軍の衝突からゲリラ戦に移ったようなものである。"
― from "良い戦略、悪い戦略 (日本経済新聞出版)"
(引用終了)

以前読んだ記事で、スクラムは組織の仕組みで駆動するのではなく、メンバー個人の能力を重視して、個人のパフォーマンスで駆動しようとする内容を思い出した。

アジャイル開発とウォーターフォール型開発の違いについて再考: プログラマの思索

アジャイルとウォーターフォールは文化や価値観のレベルで異なるという話 - たなかこういちの開発ノート

ソフトウェアビジネスが主流になる以前は、設備やリソースなどの資本を集約することで、規模の経済を実現し、コスト削減メリットを活用するのが戦略の基本だった。
一方、ソフトウェアビジネスでは、人月の経験則の通り、プロジェクトメンバーが増えるほど生産性は限界逓減する。
つまり、少ない優秀なメンバーでソフトウェア開発をやり抜く方が生産性が圧倒的に高い。
そのやり方を実現した方法の一つがアジャイル開発であり、スクラムである、と捉えた方が、より真実に近づける気がする。

ブルーカラー労働者主体、事務処理主体のホワイトカラー主体の社会では、設備や人員を大量にかき集めて規模の経済で圧倒する戦略がビジネスモデルの基本だった。
一方、専門技術職のホワイトカラー主体の社会では、メンバー個人の能力をいかに活用できるか、が鍵を握るし、そのための労働環境づくりが大事になってくる、というストーリー。

規模の経済については以前、色々考えていた。
今でも事業を発展させていくと、必ず規模の経済に即した経営戦略を取らざるを得なくなるが、一方でソフトウェアビジネスを生業にする場合は、スクラムのような個のスキルで駆動する開発スタイルを取り入れるべきという考え方も持っておきたい。

ビジネスの基本戦略には規模の経済があるのではないか: プログラマの思索

規模の経済と経験曲線効果のメモ: プログラマの思索

ソフトウェアの複雑性は本質的な性質であって偶有的なものではない: プログラマの思索