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層のルータの方が機能もコマンドもプロトコルも多くてややこしい。
たぶん、長年の歴史を経て、古いプロトコルは使われなくなり、新しいプロトコルがどんどん提案されて実装されて、技術が積み重なってきたのだろう。
経路依存性のある複雑な歴史がたぶんあるのだろう。

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