アクセスリストの設定パターン

アクセスリストの設定パターンをメモ。

【参考】
ACL - 標準ACL

ACL - 拡張ACL

access-list/CiscoIOS - ネットワーク入門サイト

ip access-list/CiscoIOS - ネットワーク入門サイト

ip access-group/CiscoIOS - ネットワーク入門サイト

access-class/CiscoIOS - ネットワーク入門サイト

標準アクセスリストを設定する - ネットワークエンジニアを目指して

拡張アクセスリストを設定する - ネットワークエンジニアを目指して

アクセスリストを設定する上での注意点 - ネットワークエンジニアを目指して

【間違いやすい箇所】
ACLはルータのパケットフィルタリングでよく使う。
特定のグローバルIPアドレスで穴を開けたポートからのみ通信を許可する、とか、社内サーバーで他ネットワークからの通信は拒否する、とか。

ACLはそのコマンドが正直ぱっと見で理解しづらい。
しかも、パケットフィルタリングは上から順にIF文＋Breakで実行されるので、じっくり考えないとミスしやすい。

標準ACLと拡張ACL、番号と名前の4パターンでよく間違える。
標準ACLの番号は1～99の2桁の数字、拡張ACLの数字は100～199の3桁。

ACLを設定するときは「ip access-list」でipが付く。
L3層なので、ipを付けると覚える。
一方、Telnet接続のACLでは、「access-group」でipはつけない。
L2層なので、ipを付けないと覚える。

標準ACLと拡張ACLを付ける場所は基本は決まっている。
標準ACLは送信元IPアドレスしか制御できないので、できるだけ遠いルータのIFの出口に設ける。
一方、拡張ACLは、フィルタリングできる項目が多いので、できるだけ近いルータのIFの入り口に設けて、パケットフィルタリングする。
ただし、複数のルートを持つルータがある場合、基本ルールと異なる場合があるので注意。

【コマンド】
(1)標準ACL＋番号付き
RouterB(config)#access-list 1 deny host 192.168.1.100
RouterB(config)#access-list 1 permit any
RouterB(config)#interface ethernet 1
RouterB(config-if)#ip access-group 1 out

(2)拡張ACL＋番号付き
RouterA(config)#access-list 100 deny tcp host 192.168.1.100 host 192.168.3.100 eq 80
RouterA(config)#access-list 100 permit ip any any
RouterA(config)#interface ethernet 0
RouterA(config-if)#ip access-group 100 in

(3)標準ACL＋名前付き
RouterA(config)#ip access-list standard pingACL
RouterA(config-std-nacl)#deny tcp 192.168.1.1 0.0.0.255
RouterA(config-std-nacl)#permit ip any
RouterA(config-std-nacl)#exit
RouterA(config)#interface ethernet 0
RouterA(config-if)#ip access-group pingACL out

(4)拡張ACL＋名前付き
RouterA(config)#ip access-list extended pingACL
RouterA(config-ext-nacl)#deny tcp 192.168.1.1 0.0.0.255 host 192.168.3.100 eq 80
RouterA(config-ext-nacl)#permit ip any any
RouterA(config-ext-nacl)#exit
RouterA(config)#interface ethernet 0
RouterA(config-if)#ip access-group pingACL in

(5)アクセスリストをVTYポートの「インバウンド方向」に適用する
RouterB(config)#access-list 1 deny host 192.168.1.100
RouterB(config)#access-list 1 permit any
RouterB(config)#line vty 0 4
RouterB(config-line)#access-class 1 in

PMBOKガイド第7版はアジャイルの観点へ大幅に内容が変わるらしい

PMBOKガイド第7版はアジャイルの観点へ大幅に内容が変わるらしい、という記事をメモ。
これが本当なら、昔のPMBOKで習得した知識は捨てて、新しいPMBOKで習得し直すくらいの激変と思う。

最新情報：PMBOKRGuide 第7 版 への変更について - JPSビジネスカレッジ

あきやま??さんはTwitterを使っています 「PMBOKの第7版が大幅に変更されるとTLで読んで、変更ポイントをググったら、プロセス重視からアジャイル的な方法へシフトしたということなのかな。よき。 https://t.co/aPO0o7siVG」 / Twitter

akipiiさんはTwitterを使っています 「PMBOKも10の知識エリアから8つのパフォーマンスドメインへ、成果物から価値へ変更されるのか。今までの知識は古くなるな。最新情報：PMBOKRGuide 第7 版 への変更について - JPSビジネスカレッジ https://t.co/Rq1ycVgO8i」 / Twitter

「PMBOKガイド 第7版への変更のポイント」を読むと、QCDのコントロールを基盤とした予測アプローチから、不確実性のもとで価値提供を重視したアプローチに変わるらしい。
気になる変更箇所は下記がある。

・これまでのようなプロセス重視ではなく、原理・原則（プロジェクト・マネジメント・プリンシプル）に基づいて再構成される。
・インプット・ツールと技法・アウトプットの記述がなくなり、大幅にコンパクトになる。
・成果物ではなく、価値（価値提供）に焦点が当てる。
・”10の知識エリア”が、”8つのパフォーマンスドメイン”に変わる
・”5つのプロセス群”が、”プロジェクトの提供における12の原則”に変わる

PMBOKといえば、5つのプロセス群、10個の知識エリアが有名だった。
それが全てなくなるらしい。どんな内容に変わるのか、結局本を読まないと分からない。

PMBOKといえば、有期限のあるプロジェクトのQCDをいかに守って、予実管理をベースに予測可能な状態へコントロールしていくPJ管理手法のイメージだった。
PMBOKの技法を読んで実践してみると、プロジェクト計画フェーズに感覚的に8割以上の労力を注いで緻密に計画して、そこから予実管理で差異分析しながらQCDを守っていく感じ。
だから、請負契約でソフトウェア開発を行う場合、PMBOKの手法は発注者のプロマネにはとても相性が良く、一連の知識体系が揃っていて役立っていたと思う。

しかし、コロナ禍の時代では、1年先、いや今ではオリンピック終了後の3ヶ月先の予測すら難しい。
いくらプロジェクト計画を緻密に作った所で、こんな時代ではすぐに現実に対応できなくなる。

だから、「第7版は、このような様々な変化に対応し、先を見越した、革新的かつ機敏な対応ができるような柔軟性を与えることを目的とし、プロジェクトに携わる人々が、予測的アプローチ、アジャイルアプローチ、適応的アプローチ、ハイブリッドアプローチなど、各プロジェクトに適したアプローチをより柔軟に選択できるようになります」という方向に変わるらしい。
PMBOKをまとめた人は本当にすごいと思う。
この記事だけでは当然全くわからないので、一度読み直してみたい。

特に直近1年間、自分が持っていた経験や知識があっという間に古くなっていると痛感する。
アジャイル開発もPMBOKも品質管理も、もちろん他の分野も急激に何かが変化している気がする。
この時代の変化に追随していくために、色々調べてみる。

(1) Yuji SakataさんはTwitterを使っています 「これ日本のPMの人、どうすんの的なところある」 / Twitter

(1) akipiiさんはTwitterを使っています 「@Bondra PMBOKから、今までのプロマネが習得したであろう、10個の知識エリア、5つのプロセス群が全てなくなります。PJ管理のバイブルの内容が一夜にしてガラリと変わってしまった感じなのですが、現場のプロマネはどうするのでしょう？？」 / Twitter

アジャイル開発で日本の品質技術をどこで活用すべきか #jasstkansai

JaSSTソフトウェアテストシンポジウム-JaSST'21 KansaiをOLで聞いている。
誉田さんの品質重視のアジャイル開発の講演がとても良かったので、ラフなメモ。

【参考】
JaSSTソフトウェアテストシンポジウム-JaSST'21 Kansai

akipiiさんはTwitterを使っています 「誉田さんの品質重視のアジャイル開発の講演は良かった。アジャイル開発の中で、日本の良さを活かせる箇所はあるしそこに特定して注力すべき、というメッセージを受け取った。日本はアジャイル開発が遅れているので、励まされる。 #jasstkansai」 / Twitter

【1】アジャイル開発が日本に浸透しない理由は、「多重下請け構造に慣れたおじさん技術者が多いのでそう簡単に変化しない」ことに尽きるのではないか。

akipiiさんはTwitterを使っています 「アジャイル開発は自己組織化を重視しすぎ、という意見は同感。日本の現場では「多重下請け構造に慣れたおじさん技術者」が多いのでそう簡単に変化しない。簡単なのは、人を入れ替えるしかないんじゃないかな。 #jasstkansai」 / Twitter

アジャイル開発のチームは、リーダーがおらず、全員が自律的に動く。
しかし、日本のSIは多重下請け構造が一般的なので、発注者、プロマネ、下請け開発者という階層構造が当たり前。
ソフトウェアの請負契約がそういう縦割りの組織文化をさらに助長させて、ソフトウェア開発に悪影響を与えている。

「DXは組織論である」からには、組織文化を変えるだけでなく、その組織文化を生み出す組織構造を壊さなければたぶん治らない。
実際は、年を取るほど新分野を勉強して成長するのが難しいので、人が育つのを1年も2年も待つのは難しい。
今の時代で、ビジネスはそこまで待てるのだろうか？？
人を入れ替えるしかないのかもしれない。

cobaltさんはTwitterを使っています 「新人だけで構成されたアジャイルチームが失敗するのは自明では？ 成熟したチームに育成目的で新人を入れる方が将来的に良いと思う。 #jasstkansai」 / Twitter

【2】アジャイル開発に日本の品質技術をどこで活用すべきか、について、本当によく考えられていると思った。

akipiiさんはTwitterを使っています 「品質重視のアジャイル開発の肝は、Doneの定義＝出荷判定とみなす点と思う。そうすれば、日本の品質技術を適用しやすいし、メトリクスによる定量化も可能になる。 #jasstkansai」 / Twitter

欧米発のアジャイル開発をそのまま取り入れても、たぶん日本ではうまく行かない。
アジャイル開発の肝は、マネジメント系プラクティスよりも技術系プラクティスをどこまで徹底させるか、にあると思う。
マネジメント系プラクティスはたぶん、日本人も理解しやすい。
しかし、実際にアジャイル開発の開発基盤がなければ、ソフトウェア開発で結果を出していくのは難しい。

誉田さんの講演では、Doneの定義＝出荷判定とみなすことで、従来の日本が誇る品質管理技術を活かせるようにした点に意義があると思う。
そうすれば、バグの原因分析、なぜなぜ分析、レビューの徹底、XDDPなどいろんな技術をアジャイル開発に適用しやすくなる。
品質をプロダクト品質、プロセス品質に分解し、日本の品質技術がどこに当てはめられるか、どのような効果が得られるか、を明示したのもわかりやすかった。

XPが生み出したTDD、CI、CD等の技術プラクティスに、日本の品質管理技術を組み合わせれば、日本の独自性も生み出せるだろう。

アジャイル開発で日本の品質技術を適用できれば、データによる定量化と統計的予測、統計的品質管理の技法を活用できる。
アジャイル開発に統計的品質管理を当てはめられたら、色んな知見が得られそう。

【3】しかし、アジャイル開発に統計的品質管理を安易に適用しても上手くは行かない。
理由は、アジャイル開発のメトリクスは相対値が多いので、定量的に比較しようがない。
また、アジャイル開発の文化として、メトリクスを自分たちチームの会話に使うので、メトリクスを第三者への説明に使う発想がないし、メトリクスが独り歩きして自分たちの行動を縛るのは嫌う。

akipiiさんはTwitterを使っています 「ストーリーポイントは自分たちのチームの会話に使うものです、と言う回答は思わず膝を叩いた。そう、自分たちのためであり、第三者への品質保証のためではない。 #jasstkansai」 / Twitter

この辺りは、昨今のSaaSみたいに、開発者がソフトウェア開発を行っている行動を自動的にログとして透過的に採取する仕組みを使えばいいと思う。
現代では、ビジネスや人の行動のログは、自動的に採取して、その大量データをAIで分析して活用する仕組みが当たり前だから。

akipiiさんはTwitterを使っています 「メトリクス収集はアジャイル開発で嫌われる問題点はあるが、Webログ採取みたいに、開発者が普通に会社で働いていれば自然に取れるようにすればいい。労働時間、工数は必ず取るし。 #jasstkansai」 / Twitter

【4】アジャイル開発を日本のチームが取り入れたとき、もっと技術系プラクティスを重視すべき、というメッセージは非常に重要と思う。
なぜなら、従来の開発者はテスト駆動開発とか継続的インテグレーションとか、割と使っていないからだ。
特にテスト自動化の技術が疎いように思う。

そして僕自身もこの辺の知識が古くなっていると痛感している。
テスト自動化の技術はここ10年でかなり深化して広がっていると思う。

テスト自動化だけでなく、テスト管理ツールや品質管理ツールも急激に進化して変わっている。
この辺りはもっと調査していく。

TestRailの感想: プログラマの思索

DXとは組織論である

DXとは組織論である、と思った。
適当なラフなメモ。

【参考】
最近読んだ本 - ブログ@kaorun55

（引用開始）
3月、4月くらいからいろいろ本を読み始めました。
主に人、組織、技術の実装あたりです。
最近はHoloLensの土台としてのDXの必要性を感じているのですが、DXは実際には組織論だと考えていて、自分の組織含めて組織の考え方について触れるようにしています。
（引用終了）

DXとは「1980年代の呪縛」を解き放つこと｜市谷 聡啓 (papanda)｜note

（引用開始）
あるミーティングで、何気ない流れの中である人が言った「DXとは組織を変えることだ」と。その言葉が特に何の違和感も、言い過ぎ感もなく、その場で受け止められて、皆の血肉となるよう消化されていく。凄い時代を迎えたと思った。
組織を変える。経営からマネジメント層、現場まで、気負いなくその言葉があげられる。もちろん突きあげられるような危機感とともに、その言葉が口にされる組織もある。いずれにしても、単なるフレーズではない。大いなる共通の目標となっている。
（引用終了）

kaorunさん、市谷さんのBlogをたまたま読んで、2人とも同じような意見「DXとは組織論である」を書かれていた。
2人ともすごい方だが、同じような問題意識を持っている点に興味を持った。
たぶん、今のコロナという時代では、心あるIT技術者は、DXの本質は何だろうか、と考えているのではないだろうか？

僕は、「DXとは組織論である」という意見は2つのコンテキストを持っていると考える。
1つは、ソフトウェア開発に向いた組織構造は何か？という問い。
もう一つは、ユーザ企業の情報システム部門が、社内の業務システムを一括コントロールするためにはどんな組織形態や運用制度が必要なのか？という問い。

前者は、逆コンウェイ戦略の観点の話になる。
つまり、アーキテクチャは組織に従う、というコンウェイの法則によって、ソフトウェアはどんどん複雑化して肥大化して手に負えなくなるのだから、それを逆手に取って、ソフトウェア・アーキテクチャを開発チームが制御できるように、アーキテクチャに合った組織構造を作ってしまえ、ということ。
最終的には、スクラムチームを作ることと同義。
それは、単なるソフトウェア開発チームだけでなく、全ての部署がスクラムチームになることと同義。

逆コンウェイ戦略のメモ～望ましいアーキテクチャを促進するためにチームと組織構造を進化させる: プログラマの思索

マイクロサービスアーキテクチャはなぜ最近になって注目されるのか～マイクロサービスは組織論の側面も持つ: プログラマの思索

しかし、従来の製造業のビジネスモデルに適した組織構造では、ソフトウェア開発に適した組織構造がとても作りにくいのだ。
そして、ソフトウェア開発に向いた組織文化は、従来のビジネスモデルに適した組織文化と全く異なるので、そのまま組織を作っても、組織文化をトップダウンで適用してもうまく行かない。
「文化は構造に従う」「アーキテクチャは組織に従う」経験則に縛られてしまう。

だから、ソフトウェア開発に向いた組織を作るには、出島を作ったり、関連子会社で別会社にするとか、そういう携帯にならざるを得ない。

文化は組織構造に従う: プログラマの思索

後者は、今の日本政府のデジタル庁で悪戦苦闘している問題点と同一と思う。
日本の大企業はどこも、皮を剥いで中身を見れば、事業部制組織という中小企業の連合体になっている。
だから、プロフィットセンターである事業部が利益に物を言わせて、自分たちの好きなように業務システムをどんどん社内に勝手に作った結果、数多くのメインフレームがまだたくさん稼働した状態で蛸壺となってしまって、コストセンターである情報システム部門はそれらを制御する権力もなく、社内のシステムが野放図になって、IT統制もできていない、みたいな感じ。

今まさに、もう一度、情報システム部門が全ての事業部から業務システムを取り上げて、決められた予算や今後の経営戦略に従って、システムの新規開発やリプレースのロードマップを計画し、セキュリティ面や個人情報保護、コンプライアンスも含めた観点で作り直そうとしている、みたいな感じ。
本来であれば、もっと以前から、メインフレームは撤廃して2025年の崖の問題はとうの昔に片付けて、オープンなアーキテクチャを元に、守りの業務システムよりも、ビジネスに直結するシステムを開発してどんどんビジネスを拡大させていく、みたいなイメージでやりたい。

しかし、デジタル庁の問題も同じく、今まさにそういうことを、地面0メートルの所から巨大なビルを作り出そうとしているわけだ。
たぶん、どこの日本企業も、レガシーなメインフレームの業務システム、あるいは、古すぎてセキュリティ上危ない業務Webシステムをたくさん抱えて、二進も三進も行かなくなっている。

僕は、DXとは、既存ビジネスを持つユーザ企業が、ソフトウェアを根幹としたビジネスモデルを構築して変革していくことと思っている。
そのためには、結局、古い数多くの社内システムを一括コントロールし、捨てるべきシステムは捨てて、システム保守に多額のコストを払うのではなく、売上拡大につながる新たなシステムへ投資できるように、経営判断を促す仕組みを作るべきだ。
そういうことが求められているのだろうと思う。

IPAがDXのパターン・ランゲージを公開している～新しい組織文化が新しい経営戦略を生み出す: プログラマの思索

「ソフトウェアが世界を飲み込む理由」「ソフトウエア、それが問題だ」の記事のメモ: プログラマの思索

デジタル庁が解くべき課題とITエンジニアの役割の勉強会の感想～CTOの役割とは何ですか？: プログラマの思索

デジタルトランスフォメーションとはソフトウェア企業になることを意味する: プログラマの思索

マイクロサービスアーキテクチャはなぜ最近になって注目されるのか～マイクロサービスは組織論の側面も持つ: プログラマの思索

ソフトウェアが世界を動かす時代: プログラマの思索

TestRailの感想

人類よ！これがテスト管理ツールだ！テスト管理ツール天下一武道会がついに開催！ - connpassを視聴してみて、最近のテスト管理ツールについて興味を持った。
ラフなメモ。

【参考】
人類よ！これがテスト管理ツールだ！テスト管理ツール天下一武道会がついに開催！ - connpass

テスト管理ツール TestRail | ソフトウェア品質保証 | テクマトリックス株式会社

そうだ TestRail を使ってみよう。 - Qiita

TestRail 入門 [TestRail Documentation]

10年前にTestLinkを一通りいじくり倒した経験があるので、テスト管理ツールの良し悪しは知っているつもり。
今回のイベントで、有償のテスト管理ツールのTestRailに興味を持った。

TestRailの良い点は、UIがとても使いやすいこと。
マニュアルがなくても、テストケースを作ったり、テスト結果のOKやNGを登録したり、サマリを見る、とか、直感的に操作できる。
テスト管理ツールはどれも、複雑な操作が割と多くて使いにくい。
だから、使いやすいUIはとても重要。

もう一つは、TestRailは外部接続APIが豊富なこと。
デモでは、TestRailsでAutomation機能を有効にした後、mablで自動テストを実行させて、その結果をTestRailに登録し、結果がNGならBacklogに起票して、その通知をSlackに流す一連の操作が、全て自動化されていた。
TestRailのREST APIを使って、Pythonスクリプトで操作したらしいが、こういう一連の自動テストの実行と結果の記録、バグチケットの起票、チャットへの通知はよくある利用シーンなので、とても面白い。

最近は、テスト自動化がかなり当たり前になってきた状況もあるので、ビジネスロジックのxUnitをJenkinsで定期実行して、その結果をTestRailに記録させる、とか、UIテストの自動化ツールmablを使う、とか、色んな利用シーンがある。
テストでは、バグチケットの起票、テスト結果の通知はできるだけリアルタイムに共有したいので、こういう一連の操作が自動化できる方が断然良い。

開発プロセスの改善という観点では、チケット管理システムの分野は既に当たり前になってきているが、テスト管理の部分はまだ未開拓の分野が多いように思う。
だからこそ、数多くの有償ツールが出回って、いろいろアピールしているのだろうと思う。
この辺りは、調べて見る価値はありそう。

なぜか2000年代にIT系の良い本が多いと感じる今日この頃

最近、Ciscoベースのネットワーク、組み込みソフトウェア開発・設計のためのモデリング、業務システムやERPを設計・分析するためのデータモデリングや業務フローの本を読み漁っている。
他にも、Matlab・Scilibのようなシミュレーション関係の本も探している。

たとえば、下記の本になる。

【1】「インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門 第2版」「インフラ/ネットワークエンジニアのためのネットワーク・デザインパターン 実務で使えるネットワーク構成の最適解27」は、オンプレのネットワーク設計の解説でピカイチだった。
インフラ担当者なら当たり前の知識なのだろうが、アプリ開発の経験しかない僕にとってはとても新鮮だった。
クラウドやInfrastructure as Codeが何を解決しようとしているのか、について、考えさせてくれた。

なお、この本は2010年代の本だが、ほとんどのCiscoルータ・スイッチの解説・コマンドリファレンス本は2000年代が多い。

【2】「組込みソフトウェア開発のための オブジェクト指向モデリング (組込みエンジニア教科書)」も良かった。
話題沸騰のポットを題材に、ハードウェアのポットを要件定義から、オブジェクト指向設計、C++のソースコードまで落としてくれる。
業務システム設計とは違う観点で、状態遷移図やパッケージ間の依存関係が非常に重要になってくる。
2006年頃の出版で絶版。

【3】「7つの要素で整理する業務プロセス (for Mutual Interest SERIES)」は、業務フロー図の演習本だ。ひたすら、7種類の業務フローのサンプルと解説をしてくれている。
内部統制が導入された頃に、ITに関係ない人が業務フローを使うことになった時に使われたのだろう。
2007年頃の出版で絶版。

【4】しかし、それらの本は2000年代に良い本が多く、2010年代はほとんど出版されていない。
オブジェクト指向モデリング、データモデリング、オンプレのネットワーク、シミュレーションなどの基本的な技術の解説本がほとんど出版されていない。
なぜなのだろうか？

おそらく、IT技術のトレンドが激しく変化してしまい、従来の設計や技術は基盤として埋め込まれて、見えなくなってしまうくらい、当たり前になってしまったからではないか。
実際、データモデリングやオブジェクト指向モデリングも、その概念や考え方は、20年前も10年前も変わらない。

しかし、SOEのWebシステムでも、枯れた業務システムであっても、データモデリングは必須だし、オブジェクト指向モデリングも知っていて当然だろうが、そういう技術を知らずにどっぷり最先端の技術にハマってしまう。
今となっては、最先端の技術から古い技術に遡るしか無いのだろうが、基本的な技術無しで取り組んでいる感じで、何か腑に落ちない時が多いと思う。

2000年代に良い本が多いのに、割と絶版になっていたりする。
すると、それらの本に含まれているノウハウや優れた説明は継承されることなく消えてしまう。

たぶん、ベースとなる技術はもはや当たり前であって、ベースの技術や基盤の上で、次々に新しいサービスをどんどん生み出していくのが普通になっている。
だから、逐一古い基礎的な技術を掘り返すのは手間がかかり過ぎるのかもしれない。

この辺りの理由は色々探りたい。
そして、その悪影響についても考えてみたい。

NATの設定パターン

NATの設定パターンをメモ。

【参考】
ip nat inside source - スタティックNATの設定

ip nat inside source list - ダイナミックNAT

Ciscoコンフィグ - PAT

NAT（スタティックNAT）　CCNA実機で学ぶ

NAT（ダイナミックNAT）　CCNA実機で学ぶ

NAT（PAT オーバーローディング）　CCNA実機で学ぶ

Cisco NAT/PATの設定と確認 | IPアドレッシング | ネットワークのおべんきょしませんか？

【間違いやすい箇所】
内部ローカルアドレス、内部グローバルアドレスの場所をよく間違える。
内部ローカルアドレスは、送信元のクライアントPC。
内部グローバルアドレスは、NATを動かすルータの外側のIF。

ip nat pool の使い方もよく間違える。
poolには、グローバルIPアドレスのリスト（開始アドレス～終了アドレス）を指定する。
グローバルIアドレスが１個だけならば、開始アドレスと終了アドレスは同一のIPアドレスになる。

標準ACLを使ったNATの設定もよく間違える。
標準ACLを使えば、送信元アドレスのpermit権限制御によって、内部ローカルアドレスの範囲を指定できる。

【コマンド】
(1)インターフェースに対するNATの設定を行う
* ethernet 0を「内部インターフェース」に指定
* serial 0を「外部インターフェース」に指定

Router(config)#interface ethernet 0
Router(config-if)#ip nat inside

Router(config)#interface serial 0
Router(config-if)#ip nat outside

(2)スタティックNATの設定を行う
* 内部ローカルアドレス「192.168.1.254」（変換対象のIPアドレス）
* 内部グローバルアドレス「10.100.100.100」（変換後のIPアドレス）

Router(config)#ip nat inside source static 192.168.1.254 10.100.100.100
⇒「ip nat inside source」まで同じ
⇒ip nat inside source static 内部ローカルアドレス　内部グローバルアドレス

(3)LAN内にある30台のPCを、プールアドレス（グローバルアドレス）を使用して、同時にインターネットへアクセス出来るようPATを設定する
* アドレスプールのプール名 は「test」
* プールの使用を許可するアクセスリストの番号は「1」
Router(config)#ip nat pool test 10.100.100.9 10.100.100.14 netmask 255.255.255.248
⇒poolには、グローバルIPアドレスのリスト（開始アドレス～終了アドレス）を指定する

Router(config)#access-list 1 permit 192.168.1.0 0.0.0.31
⇒標準ACLを設定する。
⇒標準ACLを使えば、送信元アドレスのpermit権限制御によって、内部ローカルアドレスの範囲を指定できる。
Router(config)#ip nat inside source list 1 pool test overload　
⇒ACLを設定するので、「list 1」になる
⇒「ip nat inside source」まで同じ。PATなので、最後にoverloadを付ける。

(4)NATテーブルの状態を確認する

show ip nat translations　

Pro Inside global Inside local Outside local Outside global
--- 10.100.100.100 192.168.1.1 --- ---
--- 10.100.100.101 192.168.1.2 --- 　　　 　 ---
--- 10.100.100.102 192.168.1.3 --- 　　　 　 ---

スタティックルートの設定パターン

ルータのスタティックルートの設定パターンをまとめておく。
初心者のラフなメモ書き。

【参考】
スタティックルーティングとは

フローティングスタティックルートとは、Ciscoコンフィグ設定：従来と現在の利用例

【１】スタティックルートの種類は、デフォルトルート、ホストルート、ネットワークルート、フローティングスタティックルートの４つ。
転送先アドレスの種類は、直接・再帰・完全の３つ。

一般に、ダイナミックルーティングでルータを設定する場合が多いだろう。
なぜなら、逐一手動で経路を考えて設定するのは面倒だから。

スタティックルートを設定するケースは、ISPに直接接続するルータが多いのだろう。
スタティックルートでデフォルトルートを設定し、さらにフローティングスタティックルートもバックアップルートとして登録するのだろう。

【２】たとえば、下記のスタティックルートがある。













R1でデフォルトルート＋再帰スタティックルート
ip route 0.0.0.0 0.0.0.0 192.168.2.2

PC2へホストルート＋再帰スタティックルート
ip route 192.168.3.11 255.255.255.255 192.168.2.2

PC2へNWルート＋再帰スタティックルート
ip route 192.168.3.0 255.255.255.0 192.168.2.2

PC2へNWルート＋直接スタティックルート
ip route 192.168.3.0 255.255.255.0 fa0/1

PC2へNWルート＋完全スタティックルート
ip route 192.168.3.0 255.255.255.0 fa0/1 192.168.2.2

PC2へフローティングスタティックルートの場合、AD値は２以上にする。
デフォルトのstatic routeは、AD値＝1 だから。
ip route 宛先IPアドレス　サブネットマスク 出力IF ネクストホップアドレス　AD値

【３】【図解】再帰的ルーティング(リカーシブスタティック)とその実装例 | SEの道標

（引用開始）
ルーティングの NextHop アドレスは基本的には自身の Connected ルートのセグメントの中から指定します。
ただし、NextHop を異なるセグメントにしても正しくルーティングされるケースがあります。
しかも、存在しない IP アドレスを NextHop にしていても正しくルーティングされることさえあります。
これは、再帰的ルーティングが動作しているためです。
（引用終了）

一般に、ネクストホップアドレスはルータの出力IFの相手先ルータの対向IFのIPアドレスを設定するものと思い込んでいた。
しかし、存在しないIPアドレスを指定しても、ルーティングテーブルにある別のIPアドレスであれば、再帰的に探してくれるらしい。
単純なネットワーク構造であれば問題ないだろうが、大規模で複雑なルーティングテーブルになっていると、ややこしくなりそう。

【４】ネットワーク設計を勉強していると、L2層のスイッチよりも、L3層のルータの方が機能もコマンドもプロトコルも多くてややこしい。
たぶん、長年の歴史を経て、古いプロトコルは使われなくなり、新しいプロトコルがどんどん提案されて実装されて、技術が積み重なってきたのだろう。
経路依存性のある複雑な歴史がたぶんあるのだろう。

ネットワークの根本的な目的「障害に強く高性能なネットワークを維持する」ために、どんな技術が必要とされているのか。
いろいろ調べてみる。

MATLABとPythonのリンク

MATLABについて調べてみたメモ。
MATLABすら触ったことがないのでラフなメモ。

数学を避けてきた社会人プログラマが機械学習の勉強を始める際の最短経路 - Qiita

【参考】
Octaveの概要とMatlabとの違い - 毛だるまの備忘録

これからはじめる人のためのMATLAB活用術 - 「設計・解析」(4) Simulinkは何をするツールなのか | TECH+

MATLABは数値計算用に特化したプログラミング言語で、Mathematicaみたいなイメージと思ってる。
MATLABのプログラムをSimulinkに連携して、CAEみたいに、制御工学や電気電子回路分野のモデルをシミュレーションさせるのが目的とイメージしている。

第1週目：Matlab の基本的な使用法_筑波大学

第2週目：Simulink の基本的な使用法_筑波大学

MATLABのオープンソース版にOctaveがある。
MATLABの代わりに、RやPythonを使う場合もある。
やはり今の時代ならば、Pythonで書くべきか？？

MATLABとPython、どっちが良いのでしょうか？ | アルゴリズム開発センター

MATLAB に慣れた人が Python を始めるときの１１の注意点

Pythonを使い始めて一か月の元matlab使いの感想 - グレーな道を進む

二年前　Ruby + MATLAB + R + Python 今 95％ Pythonな例: YATTSUKE BLOG

Python vs MATLAB - jtwp470’s blog

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

「組み込みソフトウェアでは対象物の状態遷移を記述できれば、制御が可能だ」という文言をネットで2箇所見つけた。
ラフなメモ。

組み込みソフトウェアのモデリングにおける根本問題とは何だろうか？
業務システムのモデリング、ネットワーク設計の根本問題とは異なる。

業務システムのモデリングでは、業務ロジックをいかにER図に落とし込めるか、という点に集約できると思う。
以前書いた。

業務ロジックをデータモデリングはどこまで表現できるか？: プログラマの思索

その考えから、ビジネスの一連の業務フローが表現されて、データのライフサイクルと使われる帳票が導出されて、最終的にERPになるイメージ。

一方、ネットワーク設計の根本問題は、ネットワークの品質をどのように保つか、という点に尽きると思う。

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

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

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

ネットワークの品質は、耐障害性の観点でのL2・L3の冗長化、セキュリティの観点でL2のスプーフィング対策・L3のパケットフィルタリング・認証、L4層以上のファイアーウォールやVPN、音声や動画やデータの通信品質を保つ観点のQoSなどの技術が使われている。
さらに、巨大で複雑なネットワーク構造を構成管理の配下に置くために、SDNやぜInfrastructure as Codeの技術が生まれた、というイメージ。
特に、昨今は、データモデリングやオブジェクト指向設計よりも、ネットワークの仮想化技術が熱いと思う。
その中にクラウドも含まれるわけだが。

では、組み込みソフトウェアのモデリングにおける根本問題とは何だろうか？

組み込みモデリング - MONOist

（引用開始）
組み込みシステム開発の世界には、大きく2つのモデル＜ソフトウェアのモデル＞と＜制御のモデル＞が存在する。
（引用終了）

組込みソフトウェア開発のための オブジェクト指向モデリング (組込みエンジニア教科書)にこんな感想があった。

（引用開始）
殿堂入りNO1レビュアー
kaizen
状態遷移が肝でしょうか。

2008年3月21日に日本でレビュー済み
対象物の状態遷移を記述できれば、制御が可能だという意味で、オブジェクト（対象）指向は有効なのだと思われます。
モデルを作る場合に、対象（オブジェクト）を記述していくのが王道なのだと思われます。
本当に必要な技術と、内容を確かめるために使う技術と、試験のための技術との詳細な説明があるとよいかもしれません。
（引用終了）

勝手な想像では、組み込みソフトウェア設計では、単純に部品をクラス図やブロック図に表現するよりも、そこから、抽象度を上げた対象物の状態遷移を見抜くことが重要ではないだろうか。
対象物の状態遷移を記述できれば、プログラムで実装可能であり、その制御プログラムで機械に作業を指示できる。

しかし、状態遷移は爆発しやすい、という根本問題は以前からある。
だから、状態が爆発的に増えてコントロールできなくなるために、レイヤーごとに分けたり、抽象度を上げ下げしたりして、ソフトウェアの複雑さを制御しようとしているのではないか。

この発想を元に、色々考えてみる。

RPAはデータモデリングを復活させるのか

RPAがノーコード開発とみなされることで、野良データを増やして、データを分散させてしまって破綻しそうな話がツイートで流れてた。
また、アクターが3人出てくる企業システム開発は、BtoCのWebシステム開発とは異なるよ、というデータモデリングの記事もあった。
ラフなメモ。

Web世代の皆さん、企業情報システムを見たことがありますか？ | 日経クロステック（xTECH）

失敗談ですが、非IT部門にノーコードツールを導入しても効果はなかったです。原因は、非IT部門の開発者にDBの概念がなくデータをどのように管理すべきか知らなかったから。画面を作っただけのアプリが乱立してデータは分散。結局エクセル使うのと何ら変わらなかったというオチです。

— ちょめ卍 (@chome2xx) May 31, 2021

弊社も同じですね。
やはりDBの概念がないとそれ意味あるの？Excelでよくない？と言われますね??
もっと言うと自分達の業務をノーコードでできる範囲に落とし込めないので、これスクラッチでよくねってなります。
結局多数のカスタマイズが発生し、予想の10倍以上の費用が発生してました??

— エンジニアK (@engineer_droid) May 31, 2021

そうなんですよね、ウッヒョ?開発おもしれー！って言いながらみんな勢いよく作るんですけど、データガバナンスなしの状態だと当然項目の重複が発生するし入力規則もバラバラでパーミッションもなし。結果価値のないデータが発生。システムの価値はデータなんですよね。

— ちょめ卍 (@chome2xx) May 31, 2021

Windows10でRPAが手軽に使えるようになって、ちょっとしたRPAブームかもしれない。
しかし、RPAをノーコード開発と捉えて、Excelを単に置き換えたようなシステムで作ると、破綻する。
データが正規化されていない、データが一元化されていない、などの問題が噴出するのは誰でも知っているが、データモデリングを知らなくても作れることで、よりその問題が大きくなったのかもしれない。

また、SoEのWebシステム開発だけで経験を積むと、バックエンドの業務も含めたより業務が複雑になる基幹システムまで目が向かなくなる。
昨今のコロナワクチン接種予約システムの件も連想させる。

データモデリング、あるいはオブジェクト指向モデリングも、最近はアジャイル界隈でも聞かなくなった。
10年以上前に終わった感じもある。
しかし、その有効性は今も変わらないのだろうと思う。

ビジネスモデルキャンバスで思考を発散させて、ピクト図で思考を収束させる

ビジネスモデルキャンバスで思考を発散させて、ピクト図で思考を収束させるという記事を読んで、なるほどと思った。
ラフなメモ書き。

【参考】
ビジネスモデルをデザインするスキル 「ビジネスモデル・キャンバス」と「ピクト図解」を身につけろ | 「ピクト図解」考案者が語る ビジネスモデルのつくり方｜DIAMOND ハーバード・ビジネス・レビュー

ビジネスモデルを「見える化」するピクト図解 「ビジネス３Ｗ１Ｈ」を意識してビジネスモデルを読み解け | 「ピクト図解」考案者が語る ビジネスモデルのつくり方｜DIAMOND ハーバード・ビジネス・レビュー

ビジネスモデルは「基本パターン」の組み合わせで考えよ ジレットとネスレの事例から学ぶ「消耗品モデル」 | 「ピクト図解」考案者が語る ビジネスモデルのつくり方｜DIAMOND ハーバード・ビジネス・レビュー

ビジネスモデルの「プロトタイプ」を量産せよ 実践！ビジネスモデルをデザインする（前半） | 「ピクト図解」考案者が語る ビジネスモデルのつくり方｜DIAMOND ハーバード・ビジネス・レビュー

「新結合」でビジネスモデル・イノベーションを起こせ 実践！ビジネスモデルをデザインする（後半） | 「ピクト図解」考案者が語る ビジネスモデルのつくり方｜DIAMOND ハーバード・ビジネス・レビュー

ビジネスモデルキャンパスの感想: プログラマの思索

ピクト図解を用いたビジネスモデルの書き方と事例 | Finch [フィンチ]

【1】企画フェーズの資料や提案資料を作成していると、ビジネスモデルをポンチ絵で描いたり、経営戦略に基づいたあるべき業務プロセスを描く必要が出てくる。
そんなときに、考えているアイデアを整理したり、アイデアを膨らませるためのテコ、基点となるような、何らかのフレームワークが欲しくなる。

【2】ビジネスモデルキャンバスやリーンキャンパスは、リーンスタートアップやプロダクト開発でよく例として出てくる。
しかし、実際に書いてみようとすると、そもそも枠内にアイデアが出てこなかったり、それぞれの要素の因果関係やロジックが作れなくて、手間取る時が多い。
また、キャンパスにたくさんの付箋やPostItを貼っても、何か分かった気がしない。
ビジネスというプロセスをモデル化できた気持ちにどうしてもなれなかった。

一方、ピクト図は、UMLで言うオブジェクト図、コラボレーション図に非常に良く似ている。
アクター同士の相互作用があって、その相互メッセージは、必ず情報のやり取り、お金のやり取りが発生する。
システムユースケース図に近いイメージ。

ビジネスモデルを「見える化」するピクト図解 「ビジネス３Ｗ１Ｈ」を意識してビジネスモデルを読み解け | 「ピクト図解」考案者が語る ビジネスモデルのつくり方｜DIAMOND ハーバード・ビジネス・レビューでは、ビジネスモデルキャンバスでは、思いついたアイデアを枠内にPostItをどんどん貼っていって思考を発散させる。
一方、ビジネスモデルキャンバスで抽出した要素は、ピクト図の相互メッセージに対応させたり、相互メッセージを発生させる要因として対応付けて、思考を収束させる。
つまり、ピクト図で、ビジネスモデルキャンバスの要素に因果関係やロジックを表現しているわけだ。

こういう考え方ができるならば、ビジネスモデルをビジネスモデルキャンバスとピクト図という2つのモデルで分析できて、それぞれの因果関係や意図をより明確に理解できるようになる。

ビジネスモデルキャンバスとピクト図を組み合わせることで、UMLのように、1つの分析対象を、複数のモデル技法で多面的に分析できるのはとても良い。
複数のモデルを描くだけで、整合性を取る作業を通じて、自然に多面的に考えるようになるからだ。

【3】最近、システム開発する前の企画フェーズやシステム提案の作業が多くなって、その資料に必要なモデル技法を探している。
ビジネスモデルキャンバスとピクト図はその一つの手段。

他にも興味を持っているのは、匠メソッド。
一部のアジャイル界隈では、SIがシステムを受注する前にシステム提案に使ったり、新たな事業を企画する時に使っているのは知っている。
なかなか触手に至らなかったけれど、価値から要求を導き、業務をAsIsとToBeを導こうとする点、デザイン思考のようなラフなモデルとBABOKライクに戦略要求から移行要求までロジカルに組み立てるモデルを組み合わせている点は、よく考えているように思える。

気づいたことがあればまた書く。

相関係数だけで判断することの危うさの例

相関係数だけで判断することの危うさの例をメモ。

相関係数だけで判断することは非常に危険というのは、以下の例がすごくわかりやすいです！
「アンスコムの例」と呼ばれる4つのデータセットがあります。
これ、4つとも平均、分散、相関係数がほぼ一致してるんですよね。
外れ値がいかに危険かもよくわかる。 https://t.co/yzZacrzH4Z pic.twitter.com/SU7ChrL13V

— fkubota ?? (@fkubota_) May 30, 2021

それはまだ序の口。 https://t.co/4A7D4GOaKR pic.twitter.com/6Y1QlGAgxg

— Ken McAlinn (@kenmcalinn) May 30, 2021

アンスコムの例 - Wikipedia

相関関係があれば、因果関係があるように錯覚してしまう危険は多い。

システム思考でも、因果ループ図を書く時、最初は2つの変数の時系列グラフから相関関係を見出し、そして、因果関係を抽出する。
売上が増えれば、利益も増える、みたいな感じ。

しかし、実際は相関関係があるからと言って、因果関係が成り立つとは限らない。

打合せの議論を因果ループ図で書き起こしてみると、そういう思い込みが割とある、と気づく。
つまり、バイアスを皆持っている。
バイアスは偏見かもしれないが、何らかの価値観が前提にあるから、ロジックが作られている。

そういう暗黙の因果関係を抽出する時、割と相関関係と因果関係をラフに同一視しているな、と気づく。

顧客が本当に欲しいものは何か？

顧客が本当に欲しいものは何か？というイメージが面白かったのでメモ。

システム開発の現実ってこんな感じ pic.twitter.com/i6hlEPRTXV

— 目白のメジェドさん@IT業界の御用聞き (@SamaMedjed) May 31, 2021

［姿勢編］理由無き要求は機能化してはいけない | 日経クロステック（xTECH）

現場は軽トラックで十分なのに、管理職や経営陣は重装備のトラックを要求してる。
しかし、予算は自転車並みなので、出来上がってくるのは人力車とか。
足りない機能は人力の運用でカバーするのが前提。
いかにも、現場が強い日本向けのシステムみたい。