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

「心理的安全性」という概念は、まだ、日本人には早すぎる。 | 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 "良い戦略、悪い戦略 (日本経済新聞出版)"
(引用終了)

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

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

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

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

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

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

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

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

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

組込ソフトウェア開発のための3部作「構造化モデリング」「オブジェクト指向モデリング」「リバースモデリング」を読んでいて楽しい

組込ソフトウェア開発のための3部作「構造化モデリング」「オブジェクト指向モデリング」「リバースモデリング」を読んでいて、面白いのでメモ。
10年以上も前にかおるんさんは既に読破されているので参考にしている。

【参考】
読了・組み込みソフトウェア開発のためのオブジェクト指向モデリング - ブログ@kaorun55

読了・組込みソフトウェア開発のための 構造化モデリング - ブログ@kaorun55

【1】上記のブログでは、「組み込みとしては、やはりこちら（構造化）の方がしっくりくる。なんとなくオブジェクト指向の方は無理をしている気がしてならない。」という感想がある。
「オブジェクト指向モデリング」よりも「構造化モデリング」の方がしっくり来るらしい。

一方、僕は、構造化設計の技法は、データフローダイアグラムとかSTS分割のような古い技法に違和感があって、むしろ、オブジェクト指向設計の方針でクラス図、シーケンス図、状態遷移図からモデルを作り出す方がしっくり来る。
だから、「構造化モデリング」よりも、「オブジェクト指向モデリング」の方が、読みやすく感じた。
なぜなら、オブジェクトで考える方がレイヤ化設計、状態遷移図などのモデルを自然に組み立てられる気がするから。

【2】たとえば、組込みSW開発の経験はゼロだが、組込みSWのモデルをユーザ視点の業務ロジック層と、物理法則やセンサーから検知した情報の制御を含む制御層の2つに大きく分けてモデルを組み立てる方針の場合、オブジェクト指向設計の方がパッケージでソフトェアを分割してレイヤ化しやすい利点があると思う。

以前、astah関西で、高井さんがSysMLを使う利点として、熱力学など自然科学の専門家、自動車や家電機器などの業務の専門家、ハードウェアの専門家、そして組込みSWを開発するプログラマの4種類の人達が、SysMLを通じてコミュニケーションできるようになった、という話もあった。

第2回astah関西の感想　#astahkansai: プログラマの思索

また、状態遷移図とは、一つのオブジェクトに着目してその状態が遷移した過程を表すので、クラス図で洗い出したオブジェクトから自然に状態遷移図で考えるように仕向けられる。

組み込みソフトウェアの根本問題～対象物の状態遷移を記述できれば、制御が可能だ: プログラマの思索

【3】興味深いのは、組込みSW開発の要件定義で重要な成果物として、ユーザ視点のユースケース分析だけでなく、イベントリストも挙げられている点だ。
たとえば、「構造化モデリング」「オブジェクト指向モデリング」の例では、電気ポットのソフトウェア要件定義で、ユーザがお湯を沸かすときのイベントだけでなく、ポットの水位やポットのお湯の温度の変化がトリガーとなるイベントも洗い出されている。
考えてみれば当たり前だが、アクターとして、ポットの購入者という利用者だけでなく、ポットという機械を構成するセンサー部品（水位の検知、温度の検知）もアクターになるわけだ。
つまり、組込みSW開発では、アクターの種類が多いので、コンテキスト図を最初に描くのが割と重要と気づいた。

【4】もう一つの「リバースモデリング」は読みかけだが、よくある事例な気がして、興味深く読んでる。
レガシーな業務システムと同じく、組み込みソフトウェアもレガシーになると、設計書はなくなっていて、動くソースコードが仕様そのものになっている。
しかし、数千行、数万行、数十万行のソースコードから本来の設計思想を汲み取って開発するのは至難の業だ。
たとえば、工場の生産ラインとか、長年使われている機械部品とか、そういう例があるのだろう。

「リバースモデリング」では、レガシーと化したソースコードからリバースして、モデルを抽出し、本来のあるべきモデルを描き出し、そこから仕様変更や改修を手がけていく、というストーリー。
なかなかうまく行かないだろうが、色んな技法を駆使して、リバースしたモデルを洗練させていくのは面白い。
今なら、XDDPと組合せてやるだろうか？

【5】残念なことに、組込ソフトウェア開発のための3部作「構造化モデリング」「オブジェクト指向モデリング」「リバースモデリング」は、「構造化モデリング」以外は絶版になっている。
3部作全てが復刊されるといいなと思う。

テストカバレッジの目標値はどれくらいの値が良いのか

テストカバレッジの現状について記事を漁ったので、リンクをメモしておく。

【参考】
Google Testing Blog: Code Coverage Best Practices

テスト駆動開発で品質は上がるのか。Googleの事例などを参考に考察。 - サックルMAGAZINE

Ericssonの『ユニットテストカバレッジの神話』を読んでみる - ソフトウェアの品質を学びまくる2.0

コードカバレッジでのブランチカバレッジとデシジョンカバレッジは何が違う？｜Tsuyoshi Yumoto｜note

ホワイトボックステストの必須知識！　コードカバレッジをご紹介！ | Qbook

カバレッジ(網羅率)分析とは | ソフトウェアの検証の種類 | テクマトリックス株式会社

カバレッジ - MATLAB & Simulink

過信は禁物！コードカバレッジの種類と落とし穴 | Qbook

グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？ － Publickey

テストカバレッジ100%を追求しても品質は高くならない理由と推奨されるカバレッジの目標値について - Qiita

Martin Fowler氏のテストカバレッジ

Analyzing statement coverage at Google

テスト自動化は品質向上に直接的に役立つ。
特に、既存機能への回帰テストでは重要な役割を果たす。

Redmineでは、テストカバレッジの一覧が下記で公開されている。
全てのソースが100％ではないが、いつでも回帰テストを実行できるからこそ、高品質を維持できて、10年以上も世界中の開発者に利用されてきたのだと思う。

Redmine code coverage

では、テストカバレッジの目標値はどれくらいの値が良いのか？
ほどほどによい目標値はどれくらいなのか？

GoogleTestBlogではこんな説明がある。

・Googleでは、60％を「許容可能」、75％を「推奨」、90％を「例示的」という一般的なガイドラインを提供しています。
・90％のコードカバレッジから95％に到達する方法に執着するべきではありません。
・プロジェクト全体で90％を超える目標は価値がない可能性が高いですが、コミットごとのカバレッジ目標である99％は妥当であり、90％は適切な下限しきい値です。

Analyzing statement coverage at Googleによると、
「C0（命令網羅, Statement Coverage) 目標値　85%+」らしい。

Martin Fowler氏のテストカバレッジによると、
「カバレッジ（C0？、C1？）の目標値　85% - 99%」らしい。

テストカバレッジ100%を追求しても品質は高くならない理由と推奨されるカバレッジの目標値について - Qiitaでは「クリティカルなコードではない限り、カバレッジ（C0 / C1）の目標値は 85%程度 に設定すべきである。」とあった。

85％程度が一つの閾値のようだが、定理や法則のようにどこでも使えるものではない。

テストカバレッジの目標値は高ければ良いわけでもない。
しょせん単体テストレベルなので、元々の機能設計のミス、要件漏れは発覚できない。
C2のコンディションカバレッジでは、禁則になる組み合わせも多いから、意味ある組合せだけを特定して、大量の組合せのパスをテストするのは、工数の割に無駄も多い。

今なら、テストカバレッジの目標値を指定したら、AIでテストコードを生成して、実際に回帰テストを実行して、目標値以上になるように実現してくれるのではないか、と勝手に夢想している。

AIを活用した次世代テスト自動化ソリューション「mabl」の 販売パートナーシップ契約締結のお知らせQA活動を効率化、サービスやプロダクトの品質向上を推進｜ニュース｜ソフトウェアテスト・第三者検証のベリサーブ

マッキンゼーの報告書「2030 日本デジタル改革」が手厳しい

マッキンゼーの報告書「2030 日本デジタル改革」が手厳しいと感じたのでラフなメモ。
【参考】
2030年に向けた日本のデジタル改革 | McKinsey
ホームページ | Digital Japan 2030
2030 日本デジタル改革～デジタル競争力と生産性を向上させるための大胆な一手
ソフトウェアの政治的影響力とは何だろうか: プログラマの思索
みんなのPython勉強会#65の感想～社会変革の鍵はIT技術者にあるのかもしれない: プログラマの思索
デジタル庁が解くべき課題とITエンジニアの役割の勉強会の感想～CTOの役割とは何ですか？: プログラマの思索
プログラマとスクラムが社会実装を変えていく　#Findy_GovTech: プログラマの思索
デジタル庁が解くべき課題とITエンジニアの役割の勉強会の感想～CTOの役割とは何ですか？: プログラマの思索
【1】2030 日本デジタル改革～デジタル競争力と生産性を向上させるための大胆な一手によれば、日本と世界の対比は下記になる。
日本　→　世界
デジタル競争力 27位　→　米国:1位
デジタル人材割合 1%　→　米国:3%
ソフトウェア関連プログラムを開講する大学の数 29 →　米国　117
行政: デジタル行政アプリを使用する市民の割合 7.5% →　エストニア：99%
スマートシティランキング - IMD 79位 (東京) → シンガポール：1位
モバイルバンキング浸透度 6.9%　→　中国35.2%
ITコストに占めるクラウド割合 3%　→　米国10%
時価総額のスタートアップ割合 1%　→　米国31%
ユニコーンの数5社　→　米国320社
（引用開始）
日本にとってデジタル化はもはや選択肢ではなく、必須である。最新の動向を見ると、日本のデジタル競争力が低下しているため、日本が世界第三位の経済的地位を維持することは不可能になるだろう。
2020年のIMD 世界デジタル競争力指数によると、日本の世界ランクは27位で、2015年と比べて4つ順位を落としている( 図表2)。
アジア経済において、日本のデジタル競争力は、シンガポール、香港、韓国、台湾、中国、マレーシアに次いで7位にランク付けされている。
他の国々は、デジタル化をいち早く推進するために懸命に取り組んできた。
香港はここ5年間で14位から5位に、韓国は18位から8位に、中国は33位から16位に、それぞれ世界ランキングを上昇させている。
（引用終了）
日本でもITを強化すべきだ、という議論は20年以上前からずっと言われてきた。
しかし、なぜ世界と比較すると、日本の地位は低いのだろうか？
ITコミュニティに参加している限り、日本のIT技術者も危機感を感じているし、実際に色々行動している人も多い。
ソフトウェアに関係する企業、従事者もそんなに少なくないはずだ。
この原因は知りたい。

CCNAの感想

CCNA（Cisco Certified Network Associate）を取得したので感想をラフなメモ。
ネットワーク初心者のメモなので後で直す。

【参考】
CCNAイージス：CCNA（200-301）Web教科書

記憶術で覚えるTCP/IP⑦アプリケーション層プロトコル ? ランスルネット

シスコIOSコマンド一覧 | IT SKILL MAP

Ciscoルータ/Catalystコマンド一覧 - ネットワーク入門サイト

Cisco Packet Tracer でネットワーク構築実践 #1 | matsublog

GNS3の設定方法、操作方法の解説

Cisco IOS images for Dynamips - GNS3

L2 Switching Simulation - GNS3

【1】Ciscoコマンドをどこまで身につけられるかが鍵

ERP導入や業務システム開発、RedmineやJenkinsなどの開発環境構築の経験はあるから、CiscoコマンドもLinuxコマンドと似たようなものだろう、と思っていたが間違っていた。
ルータやスイッチへ投入するCiscoコマンドは、データリンク層、ネットワーク層のプロトコルを制御するために、数多くのコマンドがあり、オプションがある。

スイッチなら、VLAN、VTP、DTP、STP、RSTP、PVST、PortSecurity、etherChannel、音声VLAN、CDPなど。
ルータなら、IPアドレッシング、カプセル化、OSPF、RIP、FIGRP、スタティックルート、フローティングスタティックルート、デフォルトルート、ネットワークルート、HSRP、ACL、NAT、DHCP、ARP、ICMP、NTPなど。
他にも、AAA、Radius、SNMP、Syslog、DNS、SDN、SD-Access、無線LAN、IPv6、QoSなど。

Ciscoルータ/Catalystコマンド一覧のリンク: プログラマの思索

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

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

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

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

ネットワーク学習のためのチートシートのリンク: プログラマの思索

この広大な範囲がネットワーク初級者レベルなので、CCNP、CCIEのレベルの高さはすごすぎ。
これを暗記だけで乗り切れる人は相当すごいなと思う。

勉強が難しいのは、ルータやスイッチの環境を構築するのが難しい点にあると思う。
Ciscoルータやスイッチをメルカリなどで購入して自宅に構築するのは正直手間がかかり過ぎる。
今なら、シミュレータやエミュレータがあるので、それらを使って慣れた方が早いと思う。
Linux上にWebサーバー構築と同様に、自分でルータやスイッチをつないで、実際に通信してみなければ、どこに落とし穴があるかわからない。

ITの技術や知識はツールの習得と表裏一体である: プログラマの思索

実際に体験したが、ネットワーク・トポロジーのサンプルがないと、初心者にはきつい。
適当なトポロジーでは、pingすら通らない。
個人的には、「GNS3によるネットワーク演習ガイド ――CCENT/CCNA/CCNPに役立つラボの構築と実践」のサンプルが一番役立った。
スイッチはSTPぐらいだが、ルータはOSPFからMPLS、IPSecまで一通り試すことができて、こんな通信をやっているのか、と気付きがあった。

一方、Ciscoコマンドを操れるようになれれば、ルーティングやスイッチングで何が問題で対処しようとしているのか、が分かってくると思う。
実際、ルータやスイッチの設定では、高速で安定した通信を確保するためにルートの冗長性を確保したり、セキュリティを確保するためにIPアドレッシングやVLANで制御する作業が多い。

そして、CCNPレベルの内容を見ると、ルーティングやスイッチングの細かな設定を網羅すること、そしてVPN網など通信事業者側の観点のネットワーク技術が要求されるみたい。
OSPF、EIGRPの設定を深いレベルまで問われるみたい。

【2】ネットワークの根本問題とは何か？

2つある。
ネットワークの品質を保つための技術は何か、そして、セキュリティを確保するための技術はなにか、の2つ。
以前色々考えていた。

なぜInfrastructure as Codeが必要なのか？: プログラマの思索

ネットワークの根本問題は何か～昨今のIT技術と時代の変化についての考察: プログラマの思索

最近の傾向では、ネットワークの仮想化、そして、VPNとゼロトラストセキュリティなどのセキュリティの2つが熱いように思う。

ネットワークの仮想化では、ルータやスイッチというL2層、L3層の機能をソフトウェアで仮想化できる点が重要と思う。
たとえば、2階層モデルや3階層モデルのネットワーク設計の話では、アクセス層とディストリビューション層の通信をファブリックにつなぐが、それは、巨大なL3スイッチやVLANルーティングを仮想化しているのと同じだと思う。

Dockerは仮想スイッチと仮想イメージの両方を持つ: プログラマの思索

SDNアーキテクチャの本質は巨大な仮想L３スイッチを実現したことではないか: プログラマの思索

また、単にクラウドの普及だけでなく、たとえば楽天モバイルのような事例もある。
通信事業者の携帯基地局というハードウェア設備そのものをソフトウェアで仮想化することで、低コストで設置をスピーディに行えるなどのメリットもあるのだろう。

楽天モバイルの「完全仮想化」は実現すると何が変わるのか（佐野正弘） - Engadget 日本版

楽天モバイルの仮想化の取り組みについて（総務省）

ネットワークの設備などは枯れた技術のように思っていたが、5Gの件もあるし、まだまだ技術発展の途上にある。
ネットワーク技術にもムーアの法則を適用できれば、全く新たな利用シーンが生まれて、そこから新たなビジネスも生まれてくるのだろう。

もう一つは、いかにセキュアな通信を担保するのか、という問題。
従来は、ブラックリストポリシーのように、ルータでALCでパケットフィルタリング、ファイアーウォールやWAFでパケット制御みたいなやり方が多かったが、SaaSがこれだけ普及すると、企業の業務は社内の自前システムだけでは足りない。
しかも、クラウド上に業務システムが全て乗っているならば、クラウド上のデータやシステムはセキュアかもしれないが、クライアント端末からSaaSまでの通信がセキュアでなければ無意味になってくる。

ゼロトラストネットワークはまだ無勉強だが、たぶんその辺りの問題意識から生まれているのではないか、と想像している。

【追記】
CCNA合格体験記を書いてみた。
おめでとう♪合格体験記～やっと合格