なぜInfrastructure as Codeが必要なのか？

最近ようやく、Ciscoのスイッチやルータの使い方が分かってきた。
GNS3上のルータやスイッチをCiscoコマンドで設定したり、動かしているうちに、ネットワーク技術の奥深さや難しさが何となく見えてきた気がする。
以下はラフなメモ書き。
間違いがあれば後で直す。

そもそも、ネットワーク技術の根本問題は何なのか？
根本には、ネットワークは動いていて当たり前という高品質が前提の上で、コスト、高性能、冗長性、セキュリティというパラメータのトレードオフがあると考える。

コスト＝F（高い品質、高い性能、冗長性、セキュリティ）という複雑な方程式から、最小コストとなるパラメータの組み合わせを探そうとしている。

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

ネットワーク技術の必要性が高まっている: プログラマの思索

ネットワークは動いて当たり前であり、通信できなくなると、即座に業務が止まってしまう。
ルータやスイッチを設定してみて分かったのは、設定が複雑すぎる。
数十、数百のスイッチ、ルータの設定が１つでも間違えば、ネットワークは動かなくなる。
ネットワークの素人では無理。

たとえば、中小企業で100人以下で、バックボーンエリア1個だけで済むようなルーティングのOSPF構造の経験があっても、エリアIDが2個、3個と増えて、ルータが数百台になってしまうと、相当に難しいと思う。
ネスペ・支援士塾 - connpassで講師や参加者の話を聞くと、普通のエンジニアでは、エリアIDが1個だけのルーティングしか経験がない人が多い感じ。

たとえば、冗長性を実現することで、どこかで配線が切れても、代替のルートで通信を継続できる。
いわゆる耐障害性につながる。
冗長性は、スイッチではSTPで実現するか、PAgPで実現するか、色々ある。
しかし、L2層ではフレームのTTLが無いので、下手なNW設計では、L2ループが発生してしまい、通信帯域を消費して、通信速度が落ちてしまう場合がある。
「インフラ/ネットワークエンジニアのためのネットワーク・デザインパターン 実務で使えるネットワーク構成の最適解27」を読むと、STPで冗長性を確保するトレードオフとして性能悪化してしまう症状に対して、どんなネットワーク設計をすべきか、をすごく丁寧に説明してくれている。
他にも、デフォルトゲートウェイとなるサーバーの冗長性をHSRPで実現したり、floating static routeでバックアップのdefault routeを設定したり、色々ある。

たとえば、ネットワーク設計ではセキュリティが非常に重要だ。
データリンク層のスイッチのレベルでは、スイッチに不正接続があればPortSecurityを使ってポートそのものをシャットダウンできる。
VLANで営業部、経理部などの組織単位でサブネッティングできる。
ネットワーク層のルータのレベルでは、ACL、NAT、RADIUSサーバー認証などでパケットフィルタリングできる。
また、SNMPで常時監視、Syslogにネットワーク機器のログを残したりできる。

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

GNS3の情報のまとめ: プログラマの思索

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

では、最近、なぜInfrastructure as Codeが必要なのか？

上記のように、たくさんのスイッチ、ルータ、ワイヤレスLANコントローラ、DNSサーバー、NTPサーバー、DHCPサーバー、SNMPサーバーなどのネットワーク機器を個別に1つずつ設定するのは非常に大変すぎる。
数百台、それ以上のネットワーク機器のstartup-configを一つずつ手作業でセットアップするのは、現実的でない。
1つでも設定が間違えば、L2ループが発生して通信帯域を圧迫して性能を落としたり、通信経路そのものが遮断されてしまって代替経路が動かない、とか、色々起こってしまう。

「インフラ/ネットワークエンジニアのためのネットワーク・デザインパターン 実務で使えるネットワーク構成の最適解27」で印象に残った話は、ユーザはスイッチの空きポートがあると何を差し込んでもいいと勘違いしていて、そこに量販店で買ったブロードバンドルーターを接続して、付属したDHCPサーバーが動いてしまい、フロア全体の通信を落としてしまった、実は新人の私でした、という話があった。

だから、それらネットワーク機器を一括設定、管理するような機能、つまり、SDNが必要になる。
そのSDNを仮想化したアーキテクチャとして、Infrastructure as Codeがあるわけだ。

僕は、Infrastructure as CodeをApahceのhttpd.confなどをGitで構成管理するぐらいの程度で考えていたが、たぶん全く違う。
そういうアプリケーション層ではなく、データリンク層、ネットワーク層のレベルでネットワーク機器を構成管理して、Infrastructure as Codeを実現しようとしているのだろう。

SDNコントローラで制御できるならば、管理画面からREST API、NetConf、SSH、Telnetで一括操作できる。
以前なら、ChefやPuppetが紹介されていたが、今はAnsibleが一般的なのだろう。
なにせ、SSHやNetConfが使えるし、エージェントレスだし、Playbookを書いてPushするだけでいい。

すると、Infrastructure as Codeによって、ネットワーク設計の仕様が一連のプログラムないし設定ファイルというテキストで管理できる。
テキストであれば、Gitで履歴管理できるから、設定ファイルのUndo、ReDoも簡単だ。

そして、ネットワークの仮想化、ソフトウェア化によって、クラウド環境が一般的になった今では、そういうネットワーク設計仕様のテキストは、kubernetesで可搬性を持つようになる。
kubernetesがもっと進化すれば、AWSやGoogleCloud、Azureというクラウド環境にも依存しない設定ファイルとして使えるようになるはずだ。
そうすれば、ネットワーク設計を抽象的に設計できれば、その設計構造をkubernetesで書くだけで、どのインフラ環境でも、どのクラウド環境でも動作できるようになるはず。
つまり、6つの品質特性のうち、移植性を完全に実現できるはず。

ネットワーク設計であれ、Windows7やWindowsServerの廃棄対応であれ、ソフトウェアの移植性は従来からずっと問題だった。
Infrastructure as Codeという考え方はそれを解決する一つの技術と捉えられるのだろう、と思う。

Excel駆動でWBSやガントチャートが作れない人はどこに原因があるのか？ #redmine

Excel駆動でWBSやガントチャートが作れない人は割といる。
ExcelからガントチャートやWBS管理を作ろうとしているが、その品質が悪い。
Excelで出来上がったガントチャートやWBS一覧の完成形を見せつけられているので、Excelで作ろうとするが、上手く完成できない。

若手のプロジェクトリーダーでもガントチャートに穴がある時があるし、いつもタスクのこなしが遅い人はそもそも全てのタスクを洗い出せていない。
だから、進捗管理をやろうとしても、何が遅れてやばいのか、どこに課題があるのか、を一つずつ解決できていない。
最初から全てExcel上で、PJ計画の作業をするのがそもそも間違っている、と思う。

では、どこに原因があるのか？

１つの観点として、そういう人たちは、PERT図を描いた経験がないのだろうと思う。
つまり、タスクの全体の構造が見えていない。
タスク同士の因果関係、タスク同士の依存関係が見えていない。

たとえば、ガントチャートを作る前にタスクをExcelで洗い出すだろう。
しかし、Excelで縦列に並べたタスクを見ても、その先行・後続の関係や優先度はそれぞれ違う。
それらをつなげて一つのガントチャートを作った、という経験がないようだ。

進捗管理の基本はクリティカルパスをきちんと管理することだ。
クリティカルパスとなるような重要なタスクさえ抑えれば、他のタスクはクリティカルパスから追跡できる。
そういう考え方をしていないリーダーがいた。

つまり、Excel上で、タスク一覧をこねくり回しても何も進まない。

では、どうやると治療できるのか？
一つの案では、連関図法のように、タスクを付箋紙で全て書き出して、グルーピングして、先行・後続でつなげていく、という作業を何度か経験すればいい。

そうすれば、タスクをグルーピングして依存関係を考えるうちに、このタスクも必要だから付け足そう、このタスクは他のグループにまとめたほうがいい、とか、これらのタスクは並行で稼働させたらメンバーを有効活用できる、とか、色々気づくはず。
あるいは、インフラ担当のメンバーが１人しかいないので、彼のタスクは全てクリティカルタスクになってしまう、とか、担当者のタスクが溢れている、とか分かれば、早めにメンバー確保するとか、色々対策を打つはず。
そういう試行錯誤が重要だ。

結局、付箋紙で洗い出してタスクの先行後続、依存関係を考えている、ということは、PERT図を描いているのと同じ。

具体的な案として、Redmineのチケットで全てのタスクを一括登録して、それらチケットをつなげてPERT図でを作り、先行後続の関係をガントチャート上で編集して、ガントチャートを作る。
あるいは、リリース日の単位でチケットをグルーピングしてロードマップを作る。
そういう作業をやってみれば、実際に気づきが多いはず。

Redmineのガントチャート標準機能では、ガントチャートの編集はできないが、LycheeGantChartを使えば、先行・後続関係を付けたり、ガントバーを移動したりできる。

Redmine Lychee Enterpriseシリーズの解剖part1～Redmineの本来あるべきガントチャート機能 Lychee Gantt Chart: プログラマの思索

Redmine Lychee Enterpriseシリーズの解剖part2～RedmineでEVMを実現 Lychee EVM: プログラマの思索

RedmineをMSProcjetっぽく使う事例: プログラマの思索

Redmineを使わないならば、OSSのMSProjectクローンであるProjectLibreを使えばいいだろう。
Excelでタスク一覧を作っておき、ガントチャート画面で先行・後続関係を付けられる。

OSSのMSProjectクローンProjectLibreの使い方: プログラマの思索

OSSのMSProjectクローンProjectLibre: プログラマの思索

実際は、ガントチャートの保守は非常に面倒だ。
単に、タスクの先行後続をつなげればいい、だけの話ではない。

たとえば、１人日は８時間しかないのに、１人の作業が１日１５時間働くような作業を組んだガントチャートになりがちだ。
だから、リソースヒストグラム画面で行き来しながら、作業負荷を考えて、タスクの分担を調整する。
いわゆる山崩しだ。

たとえば、ガントチャートを作るとPERT図という別のビューで見れるので、TOCの合流バッファの考え方を適用して、合流バッファには余裕をもたせることで、クリティカルチェーン上にゆとりをもたせて納期を厳守する。

たぶん、こういうガントチャートの管理手法は、メーカーの生産計画の手法と相性がいいので、本来はもっと自動化されるべきだろう。
しかし、ソフトウェア開発は、ハード製品を大量生産するケースとは全く違うので、PJ計画時に立てたガントチャートは、あくまでもイメージに過ぎず、たくさんの課題や障害が発生する都度、解決して、何とかリリースにこぎつける、みたいなパターンが多いはず。

だから、Excelのガントチャートが完成形に見えたとしても、所詮それは幻想に過ぎない。
そういう計画作業で得られた知見、試行錯誤して考えているうちに気づいたリスク、という方が大事だと考える。

次回の東京Redmine勉強会のパネルディスカッション「Excel中毒者のためにRedmineワクチンを施してみた」ではそんな話をする予定。
是非、参考にして欲しい。

第20回勉強会 - redmine.tokyo

SQLは画面や帳票のインターフェイス層に相当する

下記の記事で、データモデリングではSQLは画面や帳票のインターフェイス層に相当する、という点に気づいた。
ラフなメモ書き。

【参考】
顧客も技術者も不幸になる人海戦術に終止符を、実データで設計を吟味せよ | 日経クロステック（xTECH）

杉本啓さんはTwitterを使っています 「これを読むと、データ中心アプローチの人々がサロゲートキーを嫌う理由がよくわかるよね。サロゲートキーを使ったDBでは、ユーザーがこんな風に気軽にデータをいじれない。 サロゲートキーは、ユーザーを「データベース＝帳簿」から隔離して、技術的な存在にしまう。」 / Twitter

【1】僕はSQLは好きだ。
下手にExcelでデータをこねくり回すくらいなら、RDBに入れたデータをSQLで自由自在に抽出したり集計する方が楽だから。
一方、データモデラーではSQLは重視しない点にちょっと違和感があった。
しかし、上記の記事で、SQLは画面や帳票のユーザインタフェースに相当する事に気づいて納得した。

実際、正規化されたテーブルがあれば、欲しいデータはSQLで取ればいい。
その欲しいデータは、画面にあらわれているデータであり、帳票として印刷されるデータそのものだから。

よって、モデラーが業務の制約条件を上手くテーブル設計に反映しておけば、ユーザはSQLで好きなようにデータを抽出できるはず。

一方、訓練された設計者であれば、ER図を眺めれば、そこから業務フローや帳票、画面をイメージできるだろうが、外部設計フェーズで画面設計や帳票設計に注力してしまい、DB設計は単にデータベース定義書を作るだけ、という考えでいると、複雑なシステムになってしまい、失敗しやすいのだろう。

【2】サロゲートキーで統一されたテーブルでは、Webシステムは作りやすい。
Railsが典型的な例。
URLとメソッド、テーブルが1対1に関連付けられるので、URLベースで設計すれば、そのままプログラミングできる。

一方、DOAでモデル駆動開発を推進したい時、サロゲートキー中心のデータモデルでは、テーブル間の関係が判別しにくい。
テーブルを結合したり、入力データの制約がすぐに見えないからだ。
よって、業務を知るユーザがSQLを駆使して、テーブルを結合して、欲しい帳票を得る手法が取りづらくなる。
だから、データモデリング主導の開発では、サロゲートキーは廃止して、明示的にテーブル間の関数従属性を可視化できるようにしておきたい欲望がある。

【3】業務フローからテーブル設計するのはPOA。
本来のデータモデリングでは、AsIsの業務で手元にある帳票からER図を洗い出せる。
これは「楽々ERDレッスン」と同じ考え方。
やはり、既存の帳票はデータモデルの源泉になるから。

他方、あるべきデータモデルから、業務フローや画面構成を想像することはできるか？
これができれば、業務の要件定義がやりやすくなる。
これをやるには、個人的には、T字型ERの手法がやりやすいと思っている。
なぜなら、リソースやイベントのテーブル同士のリレーションシップは一定の法則で決定づけられる、という方針なので、初心者には使いやすいから。

「データモデリング入門－astah*を使って、TMの手法を使う－」はとても良いモデリング資料: プログラマの思索

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

候補キーと2次識別子に関する概念: プログラマの思索

リソース数がビジネスの可能性に関係する理由: プログラマの思索

2次識別子を使ったデータモデリング: プログラマの思索

テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA

@t_wadaさんがテスト駆動開発のライブコーディングをやっていて、歩きながら聞いていた。
@t_wadaさんがブツブツつぶやいてくれているので、画面を見なくても、聞くだけで想像できる。
まるで、テスト駆動開発のラジオドラマみたいな感じだ。

Developer eXperience Day CTO/VPoE Conference 2021 - connpass

akipiiさんはTwitterを使っています 「#dxd2021 #streamA @t_wada さんのライブコーディングを歩きながら聞いていて、低い声質が良いし、テスト駆動のコメントや呟きがDJみたいて聞きやすい。バグ修正とリファクタリングは分けましょうね、とか、独り言みたいな呟きが自分事でリアルに感じる」 / Twitter

@t_wadaさんの呟きで面白かった点を記録しておく。

テストプログラムを書いていると、バグ修正とリファクタリングが混じってしまう時がある。
お勧めは、バグ修正だけに注力するか、リファクタリングだけに注力するか、モードを意識的に切り替えること。
思い通りの動きにならない時に、バグ修正とリファクタリングが入り交じるのはお勧めしない。

テストプログラムを書いていくと、テストプログラムがドキュメントそのものになる。
すると、状況の下に機能を置くか、機能の下に状況ごとに書いていくか、どちらかの方針がある。
どちらも正しい。

テストプログラムの観点では、状況の下に機能を書く方が、書きやすい。
状況はグローバル変数として共通化されるので、ソースコードは短くなるので保守性は高くなる。
しかし、機能が直感的に分からないから可読性は低くなる。

一方、機能の下に状況ごとにツリー構造にロジックを書いていくと、テスト仕様書のようになるので読みやすい。
機能のツリー構造は、業務システムアプリとかWebアプリのメニューみたいなものだから、どこに機能があるのか探しやすい。
しかし、状況があちこちに散らばるので、重複したソースコードが多くなり、保守性は下がる。

つまり、テストプログラムの可読性と保守性はトレードオフになる。
どちらが正しい、というわけではない。
テストプログラムを書く人の永遠の問題。

そこで、このトレードオフを緩和するために、パラメトライズド・テストプログラミングのテクニックがある。
つまり、テストメソッドやテストプログラムをパラメータで増やすやり方がある。
これにより、テストプログラムを機能別に書いたとしても、状況をパラメータとして増やすことができて、テストプログラムの可読性を保持するとともに、保守性も高める。

テスト駆動開発がXPで出てきてからもう20年も経つ。
改めて聞いて、色々気づきがあってよかった。

プロジェクトのリスクはコストの増減で管理する

「プロジェクトのリスクはコストの増減で管理する」のであり、「コスト管理と課題管理は同じではない」。

【参考】
コストマネジメント（コストコントロール体系） | イノベーションマネジメント株式会社

プロジェクトリーダーのレベルではなく、事業部長や複数プロジェクトを取りまとめる組織の長の観点では、各プロジェクトのリスクをどのように軽減したり、回避したりするか、に注力するようになる。
リスクを完全にゼロにすることは、お金もリソースも使い過ぎるので、現実的ではない。

各プロジェクトでは、計画時にプロジェクト特性に応じて、リスクを洗い出す。
プロジェクトリーダーは、プロジェクトのキックオフ後、実行中では、リスクがどのように変化して、増大して手に負えなくなるか、事前に防げるか、に注力していく。

一方、事業部長や部課長の観点では、どこかのプロジェクトで火を噴くリスクがあると考えて、事前に各プロジェクトのリスクをコストで予算化しておく。
そういう予算は、プロジェクト外費用ならコンティンジェンシー予備費だし、プロジェクト内費用であればマネジメントリザーブ（マネジメント予備費）になる。
そして、実際に火を噴いたら、マネジメント予備費を使うし、更に足りなければ、コンティンジェンシー予備費を投入してでも、火を消すようにする。

一般に、マネジメント予備費を使う権限は、プロジェクトリーダーの采配と組織の最末端の管理職である課長の采配の２つで決まるだろう。
マネジメント予備費は契約時に、利益やコストを見込んで、契約金額に上乗せして積まれている。
マネジメント予備費を使うほど、利益は落ちるので、プロジェクトリーダーの権限ですべてを使っていいわけではなく、最低限の利益ラインを超える場合は、課長の承認が必要になるだろう。
普通は、一旦プロジェクトが火を噴けば、際限なくコストは膨らんでいく。

そして、コンティンジェンシー予備費は、事業部のトップである事業部長の承認で決まる時が多いだろう。
コンティンジェンシー予備費を使う段階まで来ると、経営陣にもその使途理由を問われるので、社内では相当な噂になりやすいだろう。

駄目なプロジェクトでは、プロジェクト計画時にリスクをそもそも洗い出せておらず、単なる課題一覧に過ぎない。
適当に解決するだろう、という期待を含めた課題管理に陥っている。
だから、リスクが顕在化して手に負えなくなると、肝心の予算がなく、単なるデスマーチ案件となってしまって、会社のお金や人員を無尽蔵に浪費していってしまう。
元々、リスクに対する予算などの手当がないので、何の戦略もなく、ズルズルと状況に押し流されるだけになる。

本来は、リスクの内容に応じて、影響度や深刻度、重要度に応じて、そのリスクが発生した場合にかかる費用を見積もり、それらの合算をコストとして予算として見込む。
もちろん、全てのリスクを洗い出して合算したら、途方もない金額になるから、ある程度のリスクは許容することで予算化しないことになる。
あるいは、コストが掛からない対策があれば一番良いが。

PMOの仕事をしていると、プロジェクト運営という観点だけでなく、プロジェクトの採算やコスト管理まで見るようになってきた。
その時に、駄目な会社では、ISO9001を運用していると標榜しながらも、プロジェクト計画書に記載されたリスク一覧が単なる課題一覧に貶められている風景を何度も見てきた。
本来、リスク管理とは何だろうか？という疑問があったが、リスクはコストの増減で管理するという発想が必要と分かり、ようやく腑に落ちた。