« 2021年4月 | トップページ | 2021年6月 »

2021年5月

2021/05/30

PlantUMLの手書き風ダイアグラムスタイル

PlantUMLの手書き風ダイアグラムスタイルという機能があったのでメモ。

Draft with handwritten diagram

(引用開始)
手書き風ダイアグラムスタイル
ダイアグラムが作成途中であることを強調するために、手書き風のダイアグラムを出力することができます。
skinparamでhandwrittenをtrueに設定します。

@startuml
skinparam handwritten true
Alice -> Bob : hello
note right: Not validated yet
@enduml
(引用終了)

平鍋さんから、モデルは手書きのようなイメージにしたい、と聞いた。
モデルの内容はロジカルであっても、伝えるときには、手書きの筆跡で感情に訴えるようにしたい、と。
なるほど、そんな考え方もあるのか、と思った。

PlantUMLには、そういう手書き風スタイルがあると聞いた。
そういう機能がastahにも入れたい、と。

確かに、人に伝えるときには、因果関係のロジックだけでなく、熱気や気持ちも伝えたい。
そういうパッションも伝えたい時に、使うといいかもしれない。

| | コメント (0)

2021/05/25

astahとPlantUMLを行き来できるastah* PlantUML Pluginが面白い

astahとPlantUMLを行き来できるastah* PlantUML Pluginが公開された。
この機能は、色んなアイデアを生み出すと思う。

【参考】
astah* PlantUML Plugin | モデルを相互変換できるプラグイン

astah* PlantUML Plugin | astah in 5 min

シンプルなテキストファイルで UML が書ける、オープンソースのツール

Visual Studio Code で UML を描こう! - Qiita

PlantUML使い方メモ - Qiita

PlantUML Pluginでは、astahのクラス図、シーケンス図をPlantUMLのソースコードにリバースしてくれて表示してくれる。
また、PlantUMLのソースコードを元に、PlantUMLのビューを見せてくれるだけでなく、astahのクラス図やシーケンス図も作成してくれる。
つまり、PlantUMLのソースコードとastahのモデルを行ったり来たりすることができる。

このPlantUML Pluginの利用シーンは、色んな使い方が考えられるだろう。

astahで描いたクラス図やシーケンス図などのモデルは構成管理が難しかった。
バイナリファルでGitで管理しても、差分情報が分からないからバックアップ代わりくらいの機能しかない。

しかし、いったんPlantUMLのソースコードでテキスト化してしまえば、Gitの履歴管理で、モデルがどのように変遷していったのか、モデルの差分情報を詳しく見ることができる。
これが最大の利点だろう。

他にも、PlantUMLのプレビューでは割とアイコンがしょぼいので、astahで綺麗に表示してくれるのはありがたい。

PlantUMLは、UML以外にもガントチャート、アーキテクチャ図、マインドマップ、WBS図(作業分解図)、ER図、ネットワーク図なども描けるので、それらもastahで実現できたとしたら、すごいだろうなと思う。
実際は無理だろうが。

正直な所、あっと思うような利用シーンがまだ思いつかないが、色んな可能性を秘めていると思う。

| | コメント (0)

SDNアーキテクチャの本質は巨大な仮想L3スイッチを実現したことではないか

SDNアーキテクチャの例として、Cisco SD-AccessとかCisco ACIがある。
単純に、ネットワーク設計を3階層のレイヤモデルで実現したことに過ぎないだろう、と思っていた。
しかし、UdemyのCCNA講座を見て、自分の理解が浅いことに気づいた。
ラフなメモ。

【参考】

新CCNA(200-301)完全未経験からの合格講座(上) | Udemy

新CCNA(200-301)完全未経験からの合格講座(下) | Udemy

新CCNA(200-301)完全未経験からの合格講座(コンプリート版) | Udemy

SDNアーキテクチャの本質は巨大な仮想L3スイッチを実現したことではないか。

たとえば、「インフラ/ネットワークエンジニアのためのネットワーク・デザインパターン 実務で使えるネットワーク構成の最適解27」を読むと、オンプレでスイッチやルータを駆使してネットワーク設計する時、L2ループになりやすいので、STPを取り入れて、ループ構造にせず、ツリー構造になるようなトポロジーを作る話がたくさん出てくる。
実際、パケットはTTLがあるから、無駄なパケットも時間が経てば消える。
しかし、L2レイヤーのフレームはTTLがないから、延々と流れ続けて、帯域を圧迫して、最終的にはルータやスイッチに負荷をかけてしまう。

だから、3階層モデルとして、コア層・ディストリビューション層・アクセス層にレイヤ化し、ルータやスイッチを配置する。
その構造は、ツリー構造なので、L2ループは発生しない。
しかし、エンドポイント同士の通信では、ツリー構造を辿って最上部のルータを経由するから、経路が長くなるし、無駄な冗長化設計になっている。

一方、SDNアーキテクチャでは、インフラストラクチャ層で、SpineスイッチとLeafスイッチでファブリック構造をなす。
ファブリック構造にしたのは単に冗長化のためだけだろう、と理解していたが、理解が浅かった。

実際は、エンドポイント同士の通信は、ファブリック構造になっているので、Leaf→Spine→Leafのルートだけで通信できるので、経路は短い。

しかし、エンドポイントのサブネットが異なると、たとえサーバーを仮想環境にしても、IPアドレスがそのまま使えないから、リソースのやり取りは面倒になる。
そこで、VXLANを導入すれば、L3ネットワーク上に仮想L2ネットワークを構築することができる。
つまり、異なるセグメントであっても、同じL2ネットワークにあたかもいるように仮想化されるので、サーバーのリソースをやり取りできるようになる。

「L3ネットワーク上に仮想L2ネットワークを構築する」というイメージは、巨大な仮想L3スイッチと同じだ。
つまり、ファブリック構造の中で、Leafスイッチは仮想L3スイッチのアクセスポート、Spineスイッチ仮想はL3スイッチのSVIとみなせば、ファブリック構造を持つインフラストラクチャ層全体を巨大な仮想L3スイッチとみなせるわけだ。

これが意味するのは、数多くのスイッチやルータの集合体を一つのオブジェクトに仮想化することで、一つの仮想的なL3スイッチや仮想ルータ、仮想スイッチとしてソフトウェア的に実現できること。
そう思えば、エンドポイントの端末から見れば、仮想スイッチのアクセスポートや仮想ルータのインターフェイスに単につないでいるだけ、とみなせるわけだ。

最近、インフラ基盤の仮想化の話が熱い。
では、仮想化の対象はどこに焦点を当てているのか?

一つは、物理的なネットワーク機器。ルータ、スイッチ、ファイアーウォールとか。
もう一つは、物理的なLAN、WANなどのネットワーク。

つまり、SDNアーキテクチャが巨大な仮想L3スイッチを実現したことは、物理的なLAN構造を仮想化したことと同じ。

同様に、MPLSとかVPNなどのトンネリングプロトコルは、物理的なWAN構造を仮想化して、一つの巨大な仮想ルータで実現したのと同じように思える。
実際、サイト間でVPNやMPLSを仮想的なL3層のプロトコルでつないで、パケットを安全に通信するわけだが、その機能は、ルータ内で、入力IFから受信したパケットをカプセル化して出力IFへ転送して送信するのと同じだから。

Dockerでも、複数のVMの通信を束ねる仮想スイッチが実現されていた。

そんなことを考えると、昨今のコンピューティングパワーが強大になったことで、物理的なネットワーク機器だけでなく、ネットワークそのものの仮想化できるレベルになり、ソフトウェアで制御しやすくなってきた背景があるのだろう。

仮想化によって、レイヤ化されたネットワーク設計では、各層を丸めて、仮想ルータや仮想L3スイッチ、仮想L2スイッチにみなせるようになった。
つまり、仮想化により、より抽象化した一つのネットワーク機器として擬似的に扱えるレベルになったわけだ。
たぶんそこがネットワーク技術の大きな技術進化なのだろう。

この辺りは奥が深いと思うので、思考を深める。

【追記】
VXLANによって、L2 over L3が実現されたイメージは、下記の記事が参考になる。

コラム - クラウド時代のオープンソース実践活用 | 第64回 いまさら聞けない? VXLANの仕組みとVTEPの役割|CTC教育サービス 研修/トレーニング

コラム - クラウド時代のオープンソース実践活用 | 第65回 Flannelが実現するKubernetesの仮想ネットワーク|CTC教育サービス 研修/トレーニング

Cisco ACI とは何なのか(1) 「ACIをシンプルにL2/L3スイッチとして考えてみる」

コラム - クラウド時代のオープンソース実践活用 | 第64回 いまさら聞けない? VXLANの仕組みとVTEPの役割|CTC教育サービス 研修/トレーニングでは、「図1 VXLANによるオーバーレイネットワーク」が分かりやすい。
東京、大阪、福岡の3拠点のサーバーがルーターで相互接続されていて、別々のサブネットに配置されていても、VXLAN対応スイッチによって、あたかも仮想的に、各サーバーは、L2スイッチで直結されたかのように、同一サブネット(この例では「10.1.0.0/16」)のIPアドレス(例:東京:10.1.1.0, 大阪:10.1.2.0、福岡:10.1.3.0)で通信が可能になる。

コラム - クラウド時代のオープンソース実践活用 | 第65回 Flannelが実現するKubernetesの仮想ネットワーク|CTC教育サービス 研修/トレーニングによれば、VXLANによる仮想ネットワーク、すなわち、「L2 over L3」のオーバーレイネットワークを実現する仕組みは、既に、実は、現在のLinuxカーネルには、すでにVXLANの機能が組み込まれていて、「Flannel」として実現されているとのこと。

つまり、VXLANは、データセンター向けの特別な技術ではなく、既に当たり前の技術になっている。

| | コメント (0)

2021/05/22

第20回東京Redmine勉強会の感想 #redmineT

本日の第20回東京Redmine勉強会の感想をメモ。
Redmineを思いもつかない利用シーンで使われる事例ばかりで、久しぶりに刺激を受けた。

【参考】
第20回勉強会 - redmine.tokyo

【オンライン開催】第20回redmine.tokyo勉強会 - connpass

2021/5/22 第20回勉強会 - redmine.tokyo #redmineT - Togetter

【1】@g_maedaさんの講演で、Redmineは細かな機能改善だけでなく、セキュリティ強化にも注力している印象を持った。
たとえば、2要素認証、通知メールのドメインの制限など。
OSSとはいえ、セキュリティホールがあると企業の基幹業務では使えないが、Redmineは世のトレンドの追随して、セキュリティのパッチもいち早く当てて対応しているのは信頼が持てる。

akipiiさんはTwitterを使っています 「二要素認証がVer4.2で機能追加された。Redmineを外部インターネットに公開する時は、このコロナ時代でDX時代では、もう必須の機能ですね。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「チケット更新メール通知機能の制限強化。セキュリティ面の強化は、Redmineをエンタープライズ面で利用するために必須。ISMSの観点でも必須。 #redmineT」 / Twitter

また、メール送受信のEndToEndでデータを暗号化通信するMIMEプラグインを使った事例もあった。
つまり、SMTPやPOP3という、今となっては相当古いプロトコルであっても、暗号化通信で機能強化することで、Redmineの通知メールを安全に取り扱うこともできる。

akipiiさんはTwitterを使っています 「Redmineの最新バージョンの2要素認証、メールドメインの制限、に加えて、MIMEプラグインでメールの暗号化でセキュリティ強化に貢献できた、と。 #redmineT」 / Twitter

UIの使いやすさも重要だが、セキュリティ機能の強化でユーザが安全に使える安心感をもたらすことも重要だから。

【2】Backlog x Redmine対談では、プロジェクトマネージャに必要とされる能力や役割が、コロナ時代やリモートワークによって急激に変化した印象を持った。

akipiiさんはTwitterを使っています 「プロジェクトマネジメントという言葉が嫌なのは、元請けSIのマネージャと下請けプログラマの開発者、みたいな役割が固定されてしまう響きがあるから。どうしても契約上の力関係がより強固になり、自発性を生み出さない、心理的安全性を生み出さない雰囲気がある。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「チケット駆動の開発スタイルでは、マネージャの指示によるマイクロマネジメントは正直やりにくい。細かい作業が膨大になってチケット保守はマネージャ1人では回らないから。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「結局、担当者にチケット保守を権限移譲して回す方針でないと、チケットは腐りやすい。マネージャ、開発者の役割は関係なく、チーム一体でチケットを消していくゲームにする。それがチケット駆動開発と思います。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「MoreEffectiveAgileに出てくる「開発チームをブラックボックスとして扱う」「マネージャはチームのInputとOutputだけを管理して作業の中身はマイクロマネジメントしない」やり方はチケット駆動開発に活かせると思います。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT マネージャも担当者もリーダー経験があると、マネージャはチーム管理が本当にやりやすくなると思います。リーダーの苦労が分かるので、先取りして準備段取りしてくれる。」 / Twitter

akipiiさんはTwitterを使っています 「ヌーラボでは、データを整備して意思決定しようとする環境を整備しようとしています。エビデンスベースドな意思決定は企業も政府も求められますね。チケット管理ツールはそのデータ基盤を与えてくれると思う。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「そうそう、門屋さんが言うように「自分がやったことがない技術を使ったシステム開発をマネジメントをする必要がある」。だからPJ管理力に要求される能力は非常に難しくなってきたと思う。特に複数ベンダーに開発委託する案件のマネージャは本当に大変。 #redmineT」 / Twitter

【3】もう一つは、チケット管理に至った結果までの道のりが、各発表者ごとに全く違っていたことも興味深かった。

たとえば、Googleスプレッドシートの情報をRedmineに集約する。
たとえば、チャットや描画ツールでラフな議論をした内容をタスクや課題としてBacklogに落とし込む。
たとえば、工場の現場でExcelのタスク管理をExcelライクなUIにお化粧してRedmineに載せる。
たとえば、全社のワークフローシステムは既にあるが、一つの事業部内の事務処理フローはRedmineに一元化して、全ての申請承認フローを載せた。

たとえば、コロナ感染サイトをRedmineで作った。
たとえば、人や店の地理情報をGoogleMapのAPIを使ってチケット情報に載せた、とか。
たとえば、RPAを使って、テストケースをRedmineに書いて、テストを実行し、テスト結果をExcelに吐き出して、それをチケットに添付して、チケットを更新する一連の作業を自動化する、とか。

とにかくいろんな発想、モチベーションを元に、チケット管理ツールを使いこなそうとしている。

akipiiさんはTwitterを使っています 「#redmineT 今日の勉強会で面白かったのは、Redmineがテーマなのに、Redmineという言葉の同音異義語が多かったこと。工場もあれば、事務の人も使うし、コロナ情報サイトでも使うし、チケット管理に至るまでの道のりも違うのに、参加者同士で話が通じ合うのもすごい。」 / Twitter

akipiiさんはTwitterを使っています 「ヌーラボでは、チャットのTypeTalkや描画ツールCaCooなどを使っている。何となくこんなのはどうなの?という話や雑談に近い話はBacklogだけでは吸い上げられない。そこでこんなイメージを絵にしたり、オンライン会議したり、色んなツールを駆使してる。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「ヌーラボでは、モヤモヤしたテーマや話を見える化した後でBacklogのチケットに書いて、管理しやすくする。門屋さんの場ではGoogleスプレッドで何でも書いてしまうのでRedmineに情報を集約しようとする。チケット管理ツールに行き着く道が違うのが面白いね。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「情報の乱雑度合い、散在度合いを下げるために、チケットに集約してエントロピーを下げようとする。その道程は、アイデア発散→課題に収束のパターンもあれば、あちこちのデータを集約、のパターンもある。#redmineT」 / Twitter

akipiiさんはTwitterを使っています 「全社WFの社内システムはあるが、組織内のWFシステムはないのでExcel管理になってしまう。そこでRedmineで組織内WFを構築して上手くいった。あるある。これいいですね! #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「都道府県=PJ、感染者=チケットに割当。Redmineの機能にフィットギャップ分析してる。ViewCustominze、MessageCustomize、Tagsなどのプラグインでチケット一覧の見た目をかなりカスタマイズしている。 #redmineT」 / Twitter

あさこさんはTwitterを使っています 「データを可視化するときに、頭の中でDBが動いてた次元構造化をされたんだろうな・・・めちゃくちゃセンスのよさと頭の良さを感じる・・・DBの知識かなり深い方なんじゃないだろうか・・・ #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「RPAでテストして、テスト結果をExcelに書いて、チケットに添付して、チケットを更新する一連の動作を、RPAで実現した事例。RPAはWindows10でも簡単に使えるので色々試せそう。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Shelperのイメージは、チケットにテストケースを書いたら、チケットの更新時に、RPAがキックされて、シナリオ通りにテストされてテスト結果をExcelに残し、それをチケットに添付する一連の動作が自動化された、わけか。Redmine+RPAでテスト自動化ツールになるイメージかな。 #redmineT」 / Twitter


【4】だから、「なぜ、Redmineを使おうと思ったのか?」という理由を講演者に聞きたくなる。

昌。さんはTwitterを使っています 「#redmineT だからなぜこれをRedmineでやろうと思うのw」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT Redmineは、改革者を、何にでも解決できそうなツールに惑わせるのです。理由はないのですw」 / Twitter

y503Unavailable@Redmine Kindle本出版unofficialcookingさんはTwitterを使っています 「@aj15_aj15 そこにRedmineがあるから #redmineT +そこにRedmineTokyo勉強会があるから」 / Twitter


【5】Redmineがもたらす組織面の効果は、はっきりとあると思う。
たとえば、Redmine利用者がシステムの機能やUIに目が肥えてしまい、社内のシステム保守担当者に厳しく要求する場合も増えた、という話もあった。

akipiiさんはTwitterを使っています 「Redmineを利用する事務の社員がシステムを見る目が厳しくなって、他システムへの八つ当たりが大きくなった笑 これは良い副作用?効果?ですね。 #redmineT」 / Twitter

たとえば、工場の現場ではベテランが経験を元にノウハウを伝承するが、若手はツールにすぐに慣れるので、逆に若手からベテランにRedmineの使い方を教え合う、という相互作用が生まれた、とか。

たとえば、Redmineの予実管理の機能を使って、見積もり能力を鍛えることができるよ、というメッセージ、とか。

yukiaさんはTwitterを使っています 「工数の予定と実績の管理をチームがしてる時点で、 そのチームは本当にすげぇと思う。 それがボトムアップ発なら、もう奇跡なんじゃないかとすら思う。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT 工場などの製造業では、工数管理は非常にシビアなので、予定工数と実績工数の管理は、作業管理と同じくらい重要でした。デメリットは、工数管理の間接作業の工数が割と多すぎて非効率な場面もあることですね。」 / Twitter

【6】グループディスカッションで話をしながら、プロジェクトマネージャに必要な能力は何だろうか?と考えていた。
僕は、一つは見積もり能力、もう一つはリスク対応力、と考えている。

akipiiさんはTwitterを使っています 「見積もりスキルのギプスとしてのRedmine。マネージャの能力の大半は「見積もり」能力と思っている。 #redmineT」 / Twitter

僕の数少ない経験上、プロジェクトマネージャの仕事の大半は計画づくりだ。
実際、PMBOKでもプロジェクト計画フェーズだけで、PMBOK本の半分を占めている。
スクラムやアジャイル開発でも、緻密で精細な計画で確定した計画ではないが、チームの開発の羅針盤としての計画は必ず作る。

その計画づくりに必要な能力は、見積もり力とリスク対応力。
これくらいの作業工数がかかる、これくらいの開発規模になる、という予測がなければ計画は作れない。
もちろん、要件定義前の企画フェーズでは、見積もりの精度は低いが、見積もりに必要な要素を探し出そうとすることで、システムのあるべき姿を描いていく。
最初は見当外れに近い仮説かもしれないが、イテレーションを経るごとに、段々と骨格が定まっていき、あるべき姿は明確化されていくので、見積もり精度も後になるほど高くなる。
アジャイル開発では、検査と適応により、フィードバックを重視するので、ソフトウェア開発にも学習による経験曲線効果を活かすことがきると思う。

また、プロジェクトのリスクがどこにあるのか、をいち早く検知することも大事。
マネージャは船の船頭みたいなもので、プロジェクトは一度動き出すと統制を取るのは難しいが、何とか、前進方向を保とうとする。
岩場にぶつかったり、天候異変で思わぬ方向に行きそうになったり、予測しきれない場面もがあるが、そういう場面をあらかじめリスクとしてイメージできるようにしたい。
リスクを全て洗い出すことは難しいが、リスクを拾っていき、そのリスクを自身で保持するのか、別の人に転嫁するのか、リスクの事後対応策や予防策を準備するのか、をイメージしながら、進めていく。

とはいえ、実際は難しいとは思う。
特に、内製開発チームのように、全てのリソースがマネージャの手の内にあればコントロールしやすいが、ステークホルダーが多く、複数ベンダーに開発を委託している案件であれば、複雑なパズルを解くような感覚になる。

【7】Redmineの面白さは、Redmineというツールがたくさんの可能性を秘めているだけでなく、Redmineを使って問題解決する人たちがこういうコミュニティに集まって議論できること。
コロナ感染サイトのように、Redmineをこんな所に使う発想、なんて誰が予想できただろうか?

実際にサイト運営者の方にお話を聞いたら、すごい悲壮感を持っているわけでもなく、なにか作ってみたかった、という気持ちから実現された、とのこと。
仕事はソフトウェア開発に直接関係しないのです、と謙遜されていたが、PythonのPandasでデータをパースしたり、Python-Remdine APIでRedmineにデータを取り込んだり、5種類以上のプラグインを駆使してUIをカスタマイズしたり、本当にいろんな技術を試されているのは、すごい。

自分が持っているアイデアやモチベーションを元に、即座にアイデアを実現できるツールの一つとして、Redmineがある。
僕自身も改めて、モチベーションをもらった感じ。


| | コメント (0)

2021/05/17

デジタル庁が解くべき課題とITエンジニアの役割の勉強会の感想~CTOの役割とは何ですか?

GaaS Study #1 ー平井大臣に聞く、デジタル庁が解くべき課題とITエンジニアの役割 - connpassにオンラインで聞いていた。

平井大臣のインタビューは、初めてまともに聞いたけど、Moving Agile, Scaling Fastという言葉がまさか政治家から聞けるとは思ってなかった。
デジタル庁への意気込みはかなり本気だ、と理解した。
ラフなメモ。

【1】デジタル庁のトップである大臣にはキレがあって、デジタル庁に来て欲しいエンジニアは、100年に1度の変革の時に運命を感じた人です、という言葉には驚いた。

平井大臣いわく。
デジタル庁がなぜ必要なのか。
今の行き詰まった日本に危機感を持っている。
日本の課題は、生産性を上げる、成長力を再生する、社会課題を解決すること。
これら課題を解決するために、デジタル庁が必要と考えた。

霞が関で一番の問題は、縦割り行政。
仕事のやり方として、コミュニケーションが悪い。
省庁のシステムもバラバラで、つながっていない。
フラットなコミュニケーションもできていない。

ベースレジストリーとして国民にサービスする時に、IDは必須。
システムはサプライサイドの観点で作られていた。
eTax、マイナポータルみたいに、どれも使いづらい。
思考停止するのではなく、利用者観点で、UI/UX重視でアーキテクチャを見直したい。
あらゆるシステムを作り直していく。
デジタル庁が国や自治体のシステムに物申し、最終的には、システムを作るな、という勧告権も発揮することもある。
データを繋がる状態にして、データ連携するデザインを設計していく。
国は年間8千億円もIT予算があるのに、ほとんどが維持費用ばかり。
日本の民間もDXにもできていないが、日本は政府が主導して、DXを推進していく。

インタビューの回答は本当によく考えられている
システム開発を中止する勧告権は、スクラムの言うSprint Cancelみたいなように感じたから、よく考えられている。
日本の社会問題の解決手段にITを用いる、という発言からその強い意志は感じた。

たぶん、僕は、世の中のテレビとかSNSに汚染されて、政府のデジタル化に悲観的になっていたのかもしれない。
デジタル庁の人員はわずか500名。
そのうち、他省庁の役人400人で、民間から100人だけ。
でも、これから変えていく、と。
デジタル庁ができることによって、霞が関そのものも、変革が必要だ、と感じているのだろう。

【2】後半の経産省若手と民間CTOのディスカッションもとても興味深かった。
その中で、最も耳に残った言葉は、経産省の女性が発言した「CTOの役割って何でしょうか?」という言葉だった。
端的に言えば、霞が関におけるデジタル化の問題点は、全てこの言葉に集約されている、と思う。

経産省の女性が発言した背景はたくさんある。
霞が関でも、今までのやり方では駄目だ、と理解している人も多い。

霞が関の役人はITの専門家ではないから、アプリ1つも作れないし、システムの要件定義もできないから、システムの発注はベンダーに丸投げせざるを得ない。
そこに問題があるのは分かっている。
だから、デジタル庁を準備している我々役人も、ITスタートアップ企業のエンジニアと触れることで、世の中の流れであるアジャイル開発、SaaSのような開発スタイルに変えていかないといけない、と分かってきている。
ITの専門家でないから、民間のエンジニアに色々教わりながら、また政府の中身も説明しながら、地道に進めている。

しかし、デジタル庁が今後何を目指すのか、というBig Pictureは、我々役人もわからない。
どのようにBig Pictureを描いていくのか、誰がそういうBig Pictureを描いていくのか、分からない、と。

エンジニアの人も言っていたが、それがまさにCTOの役割。
広木さんは、CTOとは、技術と経営の橋渡しをする人と言ってたし、CTOとは、システムのアーキテクチャに合わせてソフトウェア開発の組織をデザインする人、とも言っていた。

キーワードは、いくつかある。
一つは、コンウェイの法則。
アーキテクチャは組織に従う。
たぶん、政府の組織ががんじがらめで硬い構造なので、アーキテクチャは縦割り組織で分断されてしまい、システムも柔軟性がなく、タコツボみたいになっているわけだ。
よって、政府主導のソフトウェア開発へ変えていくには、アーキテクチャを定めて、そのアーキテクチャに合うような組織体制を作っていくべきだろう。
議論の中では、大手ベンダーだけでなく、ITスタートアップ、オープンソースコミュニティとも連携したい、という発言があったが、その辺りも上手くリソースを利用すべきなのだろう。

組織文化を変えていきたい、と経産省の若手の人は言っていた。
その人は、とてもよく考えられている、と思う。
しかし、僕は、「文化は組織構造に従う」とも思っている。

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

大規模スクラム Large-Scale Scrum(LeSS)」には、「文化は組織構造に従う」というメッセージが語られている。
良い組織構造に人がいれば、自然に良い組織文化を生み出す。
つまり、組織における人の立ち振舞や言動は、その組織の構造というシステムが生み出したのであって、個人に原因があるわけではない。
たぶん、縦割り組織が、組織の中の人たちの行動を硬直化させるような組織文化を生み出している。
だから、組織文化を変えていくには、少しずつであっても、組織構造を変えていくしか無いだろう。

他のキーワードは、スクラムだろう。
政府の関係者はITの専門家ではない。
結局、システムの発注を政府がコントロールするには、政府側にプロジェクトマネージャのような役割がいる。
そして、プロダクトオーナーのような役割や内製開発のチームが最終的に必要になる。
政府のシステムはリリースしたらおしまいではなく、日本人の1.2億人がお客様であり利用者なのだから、リリースした後にフィードバックをもらいながら、少しずつでも改善していく、という開発スタイルに変えていくべき。

そんな事を思うと、デジタル庁にはCTOの役割の人がたぶん今は欠落しているのかもしれない。
だから、CTOを担うべき人を民間のエンジニアから募集しているわけだ。
実際、デジタル庁のジョブディスクリプションを見ると、職種が非常によく考えられていると感じた。

デジタル庁で応募中のアイデンティティアーキテクトは昔のDAと同じ役割か?: プログラマの思索

経産省の女性からも、エンジニアが働きやすい職場環境はどんなものなのか、教えて欲しい、という発言もあった。
エンジニアから聞いたら、高性能なPCは分かったが、まさか、座り心地の良い椅子が必要、とは思っても見なかった、と。
だから、他にもそういう話があるなら、知らせて欲しい、と。

デジタル庁がやるべき仕事はあまりにもたくさんありすぎて、たくさんの課題も山積している。
しかし、エンジニア観点で見れば、今の日本の諸問題の解決には、ITエンジニアの活躍が鍵を握っていると感じた。

実際、台湾では超優秀なIT大臣が就任以来、社会の雰囲気を一変させた。
同様なことは日本でも可能なはず。

ソフトウェアの政治的影響力とは何だろうか: プログラマの思索

みんなのPython勉強会#65の感想~社会変革の鍵はIT技術者にあるのかもしれない: プログラマの思索

ITエンジニアが、社会変革の鍵を持っているわけだ。

| | コメント (0)

2021/05/16

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

「インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門」を読んでる。
インフラエンジニア向けの良本だ。
ラフなメモ。

【インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門 第2版】感想を書く - 私がハッカーになるまで

「インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門」を読んでみたけどかなりいい本! - S氏はたまにblogを更新してます

【最前線で活躍中!】NVSのエンジニア社員がおすすめする技術書|ネットビジョンシステムズ公式ブログ

「インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門」の内容は、スイッチのVLAN設計、ルータのIP設計からファイアーウォール、SNMPなどの管理、セキュリティ、可用性まで幅広い。
最初は、Ciscoのスイッチやルータを知らなかったので、内容が頭に入らなかったが、一通りの用語を知った後で読んで、ようやく、この本の良さが分かってきた。

STPはスイッチの冗長化、というイメージがあったが、むしろL2ループを防ぐための技術として扱う、という発想はなかった。
サブネッティングはテトリスみたい、パズルみたいに決まります、とか、面白い。

ルーティング方式は、VLANを小さく作ってエッジルーティングよりも、VLANを大きく作ってセンタールーティングの形が主流というのは知らなかった。
VLANで細かくブロードキャストドメインを分割すべきかなと思っていた。

ファイアーウォールが持つステートフルインスペクションと、ルータ・L3スイッチが持つパケットフィルタリングは、混同していたかもしれない。
ファイアーウォールは最新の機器ほど、セキュリティ機能だけでなく、NATやVPN、シグネチャー、WAFとかたくさんの機能が追加されまくっているので、あまり深く考えてなかった。

ネットワーク設計で重要なのが、セキュリティ設計と冗長化設計だろう。
セキュリティ設計なら、スイッチのポートセキュリティ、Dynamic ARP Inspection、BPDUガード、ルータのアクセスリストとか、冗長化設計なら、RSTP、OSPF、EIGRP、HSRP、スイッチのリンクアグリゲーション、とか。
これらの技術を組み合わせて、いくつかのパターンでネットワーク構造を決めるわけだ。

管理設計のNTP、SNMP、Syslog、CDPも復習として参考になった。
NTPの重要性は、トラブルシューティングで分かる。

バックアップ設計では、スイッチ、ルータ、ファイアーウォール、Big-IPの設定ファイルを定期的にバックアップする。
SSHでTFTPサーバーに定期的にバックアップするのだろう。
この作業はネットワーク機器ごとに管理するのは面倒なので、Ansibleで事前に設定してプッシュするとか、SDNで一括管理するような手法が好まれるのだろう。
最終的には、クラウドになれば、Kubernetesで統一的に管理されるのだろう。

著者のみやたひろしさんのネットワーク本は他に「インフラ/ネットワークエンジニアのためのネットワーク・デザインパターン 実務で使えるネットワーク構成の最適解27」「パケットキャプチャの教科書」「サーバ負荷分散入門」は一通りざっくり読んでみたが、どれもいい。

パケットキャプチャツール「Wireshark」はまだ使いこなせていないので、「パケットキャプチャの教科書」はじっくりと読んでみたいと思う。

| | コメント (0)

2021/05/14

日本人の弱点は忖度しすぎること、理論化できないことではないか

4月末と今夜、平鍋さんがアジャイル開発について語る勉強会を聞いた。
日本人の弱点は忖度しすぎること、理論化できないことではないか、という気づきをラフなメモ書き。

【参考】
今こそ必要な実践知リーダーシップとスクラム - connpass

BPStudy#164?アジャイル開発とスクラムの今を語ろう - connpass

【1】野中先生の肉声を初めて聞いた。
86歳らしいので、平成上皇と同い年らしい。
すごくハキハキした口調で、英語の論文にも慣れているのだろうか、知的バトル、とか、割と英単語が出た。

スクラムを生んだジェフがすごいのは、ベトナム戦争で偵察機の経験があったこと。
その経験をベースに、スクラムを生んだ。
ソフトウェア開発の手法は幾多数多あるが、それを理論化できたのはジェフがフィロソフィーを持っていたから。

野中先生の論文でも、スクラムでも、共感ありきで始まる。
欧米の哲学は、デカルト以来、コギト、我思う故に我あり、から始まるが、そうではなく、共感をベースにした。
だから、上手くいく。

一方、日本人は、元々共感力があるので、スクラムをやるのにもっと共感を重視しようとすると、忖度しすぎてしまう。
忖度するのではなく、もっと知的バトルをすべきだ、と。

僕らの頃は、ジャパン・アズ・ナンバーワンと言われていたが、DXの流れに乗れず、今はその面影もない。
だから、またジャパン・アズ・ナンバーワンを目指してほしい、と。

【2】日本人の弱点は忖度しすぎること、理論化できないことではないか、という考えを思い巡らすと、今まで読んできた本のいろんなフレーズを思い出してくる。

【3】「採用基準」「生産性」はマッキンゼーの元コンサルが、日本人や日本の組織に足りない要素2つを書いている。
それは、日本人には問題解決リーダーシップの能力が足りないこと、問題解決の生産性の意識が低いこと、の2つ。

リーダーシップ経験のない日本人が多すぎるから、評論家ばかりで、実際の問題を泥臭く解決していこうとする能力も意識も低い。
リーダーシップとは、自分の意見を持ち、周囲を巻き込んで、リスクを取って、問題を解決していく。
しかし、リーダーシップを発揮する日本人は、出る杭は叩かれる、ばかりに思われるので、たぶん自然に忖度してしまう。

また、生産性をコストダウンの事ばかり考えすぎる。
日本人が得意なプロセス改善の手法は、コスト低減による付加価値を上げる手法の一つに過ぎない。
生産性=付加価値/コストで考えるならば、コスト低減よりも、付加価値を圧倒的に増やす方がはるかに生産性は上がるはず。
しかし、日本人サラリーマンは斜陽産業でコスト低減ばかり経験しているので、ホワイトカラーが付加価値を上げるために、今までの手法を捨てて、全く新たなアイデアや手法を採用して、リスクを取っていく、という発想も能力もない。

【4】「経済数学の直観的方法 マクロ経済学編」では、世界の経済戦争の重心が、製造業の競争力強化から、世界全体の資金の流れを上手く誘導して流す方向に変わってしまった。
しかし、日本は、製造業があまりにも成功したので、マクロ経済学における動的均衡理論を取り入れる機会を逸してしまった。
そして、世界中の中央銀行がインフレターゲット政策を運用し始めた頃、慌てて、動的均衡理論を学習しようとしたが、従来のケインズ経済学とは異なり、解析力学をベースとした高度な数学理論を使うので、とても学習しづらい。

ちょうど、欧米では、これを学んだ人たちが政治経済の中枢に占めているのに、日本では学習し損なった世代がブランクになり、そのギャップを埋めることが難しい状況らしい。

かつて、日本では、ケインズ理論に従って、政府の公共政策による景気浮揚策は良いことだ、という理解が、割と世間の人たちも認識が共有されていた。
ちょうど、その頃は、日本の製造業が無敵の時代だった。
しかし、コンピュータやITが直近の四半世紀でまたたく間に普及して、ITなしでは生活もビジネスも経済も成り立たなくなった。
経済学の主導権もケインズ理論から動的均衡理論に代わったが、日本は追いつけていない。
さらに、世界中の資金を自国に誘導するように、情報や経済理論を整備して発信していく、というやり方に日本は乗り遅れてしまった。
「ミクロでマクロを制する」という発想は、日本人は弱いらしい。

【追記】
平鍋さんが「先生へお礼のメッセージを送ろう」とtwitter 上で平鍋がよびかけ、集まったコメントが公開された。

野中郁次郎先生へのみなさんからの手紙

自分のコメントも掲載されていて恥ずかしい。
今一度読み直すと、日本人には共感力よりも、知的バトル、知的コンバットが必要なのだろう。
つまり、対立することを恐れず、もっと知的論争をすべきであり、お互いにもっと衝突して、その後で握手する事が大事なのだろう。
知的論争に忖度は無駄。


| | コメント (0)

2021/05/08

『オブジェクト指向でなぜつくるのか』第3版が出版された

『オブジェクト指向でなぜつくるのか』第3版が出版されたのでメモ。

【参考】
『オブジェクト指向でなぜつくるのか』第3版

オブジェクト指向でなぜつくるのか 第3版|日経の本 日経BP

「オブジェクト指向でなぜつくるのか」は良い本だ: プログラマの思索

「オブジェクト指向でなぜつくるのか」は良い本だ: プログラマの思索では、第2版を改めて読み直してみた。
オブジェクト指向プログラミングがヒープ領域を使っていることから、UMLによる汎用の整理術、XPに至るまでのアジャイル開発、そしてパターン言語まで幅広い。
こういう一大ストーリーでまとめているのはすごいと思う。

僕が思うに、オブジェクト指向の考え方をアジャイル開発、特にスクラムに適用している所が一番興味はある。
たとえば、「More Effective Agile “ソフトウェアリーダー”になるための28の道標」では、「スクラムチームはブラックボックスとして扱うべきだ」という主張が何度も使われている。
つまり、スクラムチームはInputとOutputだけ管理すればよく、プロジェクトマネージャはマイクロマネジメントする必要はないし、マイクロマネジメントすべきでない、という主張が一貫して流れている。
これもオブジェクト指向のカプセル化がわかっていれば、とても腑に落ちる。

More Effective Agileは良い本だ: プログラマの思索

「オブジェクト指向でなぜつくるのか」本はずっと読まれ続けてほしいと思う。

| | コメント (0)

astah*の因果ループプラグインがいいね

astah*の因果ループプラグインを教えてもらったのでメモ。
使ってみるとなかなか良いです。

【参考】
snytng/inga astah*の因果ループプラグイン

思考力と注意力のトレードオフを因果ループ図で描いてみた: プログラマの思索

因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける: プログラマの思索

astah*の因果ループプラグインのメリットは、因果ループ図からロジックをリバースしてくれること。
要因Xが増えれば、要因Yが増えるのか、要因Yが減るのか、表示してくれる。
ロジックを見直す時に役立ちそう。

【1】教員希望者が減っているニュースを見て、その背景にあるロジックを書いてみた。

教員の過酷な労働実態相次ぐ投稿でオンライン上の報告会開催 | 教育 | NHKニュース

小学校教員倍率、過去最低2.7倍 質の確保急務: 日本経済新聞

Photo_20210508114201

ニュースでは、下記のロジックが読み取れる。

「教師希望者」が増えれば、「教師の質」が増える: 1 (自己強化=1, バランス=0)
→「教師の質」が増えれば、「モンスターペアレント」が減る: 1 (自己強化=1, バランス=0)
→「モンスターペアレント」が減れば、「教師の作業負荷」が減る: 1 (自己強化=1, バランス=0)
→「教師の作業負荷」が減れば、「教師希望者」が増える: 1 (自己強化=1, バランス=0)

そこで、教師希望者を増やすために、教師増加キャンペーンを実施したわけだが、本当に効果があるのか?
レバレッジポイントはそこなのか?
他の要因を増減させるような施策の方が優先ではないか?

他にも隠れたロジックがないか?
色々考えが思いつく。

astah*の因果ループプラグインの他の機能では、下部欄の因果関係をクリックすると、因果ループ図の線にフォーカスしてくれる。
ただし、Same(+)は実線、Opposite(ー)は破線なので注意。

| | コメント (1)

2021/05/07

Dockerは仮想スイッチと仮想イメージの両方を持つ

下記の記事で、Dockerは仮想スイッチと仮想イメージの両方を持つと理解した。
自分の気づきをメモ。
間違っていたら後で直す。

【参考】
【連載】世界一わかりみが深いコンテナ & Docker入門 ? その5:Dockerのネットワークってどうなってるの? ? | SIOS Tech. Lab

僕は、DockerとVMの違いが分かってなかった。
VMWareのソフトでVMの仮想NICをいじったり、VMSphereで複数のVMを再起動する、とかしていたけれど、何か腑に落ちなかった。
なるほど、dockerでは、CentOSの2つのVMを構築するだけでなく、仮想スイッチまで作ってくれるわけだ。

# docker run -it -d --name test01 centos:centos7
# docker run -it -d --name test02 centos:centos7

この仮想スイッチは、L3スイッチに似ている。
IPアドレスを持つし、デフォルトゲートウェイも持つ。
そうでなければ、VMから外部ネットワークへ通信できない。

では、なぜDockerは仮想スイッチが必要なのか?
理由は、おそらく、仮想スイッチを経由して、VMや他のNW機器とパケット転送やイーサネットフレーム転送を制御する必要があるから。
イメージ的には、Dockerの仮想スイッチに、PCとコンソールケーブルで接続して、PCから仮想スイッチにログインして、VLANやSTP、OSPFなどを設定できるようにしたいのだろう。
つまり、Dockerの仮想スイッチは、ネットワーク制御の入り口に当たるわけだ。

また、Linuxをいじっている時に、iptables をよくわからずに操作していたが、NAT機能のことだったのね。
すると、Linuxそのものをルータとして機能させていたわけだ。

Dockerが仮想スイッチを操作できるならば、Dockerを動かすOSそのものをNAT機能を持つルータにしてしまえば、Webシステムの冗長化やブルーグリーン・デプロイメントも楽に制御できるはず。
こういう技術がない頃は、手作業でロードバランサーの向き先を変えて、2つのWebサーバーに順に本番モジュールをリリースしていたが、いつも冷や汗をかいていたのを思い出した。

Dockerで仮想スイッチやVMも一括設定できるなら、どの環境にも簡単に移植できるようになるはず。
さらには、クラウドの種類、AWS、Azureに依存しないように構築できるはず。
Infrastructure as codeは、移植性を透明的にする方向に進化しているわけだ。

| | コメント (0)

リーンスタートアップ系の本のリンク

リーンスタートアップ系の本をリンクしておく。
後で自分が読むために。

【参考】
リーンスタートアップ系の本を読むならこの順番|篠キチ|note

リーンスタートアップのシリーズ本を振り返る (2018). Lean Startup Update! 2018… | by Taka Umada | Medium

リーンスタートアップの本を6冊借りて読んだ。
まだ、読んでピンときていない。
たぶん、自分でWebサービスやSaaSを経営者の観点で運用した経験がないからかもしれない。

リーンスタートアップといえば、リーンキャンパス。
リーンキャンパスも、自分が考えたビジネスモデルを仮説検証する道具として扱うので、そういう経験がなければピンとこないのだろう。
ビジネスが腑に落ちた時にまた読み直す。

| | コメント (0)

« 2021年4月 | トップページ | 2021年6月 »