PLMツールとは部品表の構成管理ツールでありGitHubである

製造業のパッケージ製品に出てくるPLMとは結局何なのだろうか？
考えたことをラフなメモ書き。

【参考】
BOM/部品表入門: マテリアル・マネジメント改革の基本技術 (図解でわかる生産の実務) | 佐藤 知一, 山崎 誠 |本 | 通販 | Amazon

図解 DX時代のPLM/BOMプロセス改善入門 デジタル化 段階別課題解決のアイデア100 | 三河 進 |本 | 通販 | Amazon

5つの問題解決パターンから学ぶ実践メソッド BOM(部品表)再構築の技術 | 三河 進 |本 | 通販 | Amazon

誰も教えてくれない「生産管理システム」の正しい使い方 | 本間 峰一 |本 | 通販 | Amazon

誰も教えてくれない 「工場の損益管理」の疑問 | 本間峰一 |本 | 通販 | Amazon

誰も教えてくれない ｢部品工場の納期遅れ｣の解決策 | 本間峰一 |本 | 通販 | Amazon

誰も教えてくれない「SCM計画立案・遵守」の疑問 あなたの会社の生販在（PSI）計画は機能していますか？ | 本間峰一 |本 | 通販 | Amazon

製造業におけるPLM製品とMES製品の違いは何か？: プログラマの思索

E-BOMとM-BOMの違いは何か？: プログラマの思索

製造業のDXを推進する部門をITコーポレート部門に割り当てるとなぜ失敗するのか: プログラマの思索

製造業の本質は「すり合わせ」と「PSIのトレードオフ」にある｜akipii

【1】製造業でよく使われるパッケージ製品は、ERPだと思っていた。
いわゆる生産計画と生産実績の管理、そこから会計管理までつながる基幹系システムのことだ。

しかし、製造業ではもう一つの重要なパッケージ製品があると分かった。
それがPLMツールだ。
製品そのもののライフサイクル管理を指す。
たいていは部品表を管理するためのツールだ。

では、なぜPLMツールは製造業でそこまで重要なのだろうか？

【2】PLMツールの本質は、部品表の構成管理にある。
その理由と経緯について書いてみる。

【3】製造業のビジネスモデルとは、製品を製造して、付加価値を付けて販売することだ。
その製品は数多くの部品から構成される。

自動車なら10万個の部品、飛行機なら100万個の部品が必要と言われる。
その他の精密機械装置であれば、1万～10万点ぐらいの部品から組み立られるケースが多いだろう。
部品数が10個程度ならまだしも、数千個、数万個になると、人間の記憶や紙媒体だけで管理するのは難しい。

しかし、今までの中小製造業では、こういう組立加工の製品を現場の長年の勘と経験だけでやってきた。
ちょっとした大手製造業ですら、せいぜいExcel媒体で管理しているに過ぎないケースが多い。
日本の製造業の現場では、ベテラン社員が長年の技能経験を元に、部品のノウハウを蓄積してきたおかげで、口頭伝承でも何とか製造できてきた。
でも、新人社員の確保が難しくなったり、技能継承が難しくなったりして、もはや勘と経験だけでは維持できない。
だから、PLMツールを用いて、部品表を整備し、部品の特徴や組立加工時のノウハウを全て蓄積することで解決しようとする。

【3】一方、こういう勘と経験が長年続いてきた理由の一つに、日本の製造業は見込生産よりも受注生産が主体のビジネスモデルだったからではないか、と考えている。
実際、日本の製造業では製番管理で部品や原材料の発注購買から生産計画、生産指示、生産実績まで管理しているケースが非常に多い。
たとえば、中小製造業なら元請けから製造委託を受けたり、過去の受注生産を元にリピート受注したり、リピート製番から部品を少しカスタマイズして派生開発したりするケースが多いだろう。
つまり、過去の受注生産の実績データを元に、製番をどんどん派生させて部品を少し入れ替えたり、カスタマイズして生産するケースが多いのだ。
すると、今までの受注生産の経験を活かして、ちょっと派生開発する程度で、現場の頑張りで何とかやってこれた、という実態が多いのではないだろうか。

しかし、多品種少量生産が普通になった現代では、過去のリピート製番から多数の派生製品が作られるので、過去の変更履歴やその経緯、変更理由が分からなくなっている。
そのために、生産後のクレームや本番障害、生産途中の仕損品の増加などに苦しめられているのではないか。

だから、過去のリピート製番にある部品表や工程表（レシピ）を記録し、リピート製番から派生開発する時はその変更履歴や経緯を記録したい。
そのためにPLMツールを導入して、部品表の変更履歴を残したいのだ。

そんな経緯があるから、PLMツールが必要だと理解している。

【4】「BOM/部品表入門: マテリアル・マネジメント改革の基本技術 (図解でわかる生産の実務) | 佐藤 知一, 山崎 誠 |本 | 通販 | Amazon」では、部品表の履歴管理が重要だ、という主張がある。
今までその理由は分かっていなかったが、たぶん、日本の製造業ではリピートの受注生産が多い背景があるので、部品表の履歴管理をPLMツールで一括管理すべきだから、と考えている。

【5】PLMツールが部品表の構成管理であるということは、ソフトウェア開発にたとえれば、部品表の履歴管理をGitHubで管理しているようなものだ。
実際、過去の1つの製番に対し、複数の製番が派生開発されるケースが多いからだ。
つまり、ルートにある製番からツリー状にどんどん部品表が広がっていく。
ちょうど、カンブリア紀から現代までの生物の歴史みたいに。

【6】すると、PLMツールによる部品表の構成管理では、どのようにリビジョン管理されるのか？
そのやり方は「図解 DX時代のPLM/BOMプロセス改善入門 デジタル化 段階別課題解決のアイデア100 | 三河 進 |本 | 通販 | Amazon」に詳しく書かれている。

具体的には、リピート受注時に、大元の製番から派生させて新規製番を作る。
しかし、受注生産の場合は、製品の仕様が固まるまで、顧客と何度かやり取りが発生する。
その都度、製番に紐づく部品構成は何度も更新されて記録される。
普通はリビジョンを付けて管理する。

そして、最後に見積もり確定する時に仕様が固まる。
この時に、製番が確定するので、バージョンを付けてFixする。
バージョンを付けて確定した製番が重要であり、その途中経過のリビジョンの製番データは不要だ。
普通は、社内で設計部門が承認した版をバージョンとして残し、過去のリビジョンは消す機能がPLMツールに必要だろう。
これらの部品表の構成管理は、PLMツールのワークフロー管理機能として実現されているだろう。

ソフトウェア開発から見れば、丁度この考え方は、Githubのブランチ新規作成とタグ付けと同じだろう。

また、GitHubのDiff比較と同様に、PLMツールでもリビジョンごとの部品表比較が重要だ。
設計部門の運用を見ると、部品の差分結果のコメントに、変更理由や見積もりに至った経緯を書き込んでいる。
この差分結果を出力してエビデンスを残して、見積もりの根拠に使っている。

PLMツールには他にも重要な機能がたくさんあるので別途まとめてみたい。

【7】まとめとして、PLMツールの存在意義は何なのか？

PLMツールは元々、設計部門が作るE-BOM、生産計画部門が作るM-BOM、購買部門が作るP-BOM、保守サービス部門が作るS-BOM、それらを統合して一括管理するツールだ。
一方、日本の製造業のビジネスモデルでは、受注生産が非常に多く製番管理が主体なので、製番の派生開発のために部品表の構成管理として使いたい意図がある。

PLMツールで部品表の構成管理を一括管理できれば、部品表の精度が上がることで設計品質の向上、生産計画におけるM-BOMの精度向上により生産リードタイム短縮、受注前の引き合いで見積もりを即座に行うことによる見積もりリードタイム短縮につながるメリットがある。
そこまで行き着くには、製造業の内部で、単に部品表を口頭伝承や紙媒体からデジタル化するだけでなく、PLMツールに蓄積された資産を有効活用できる施策を実行しなければならない。
製造業にはまだまだ改善できる余地がたくさんあるのだ。

explaining-specific-examples-of-purpose-specific-bomfrom akipii ogaoga

how-does-mes-manufacturing-execution-system-workfrom akipii ogaoga

「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想

GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみを読んだ。

【0】リモートワーク主体の組織運営をどうやってやるか、PDCAで整理した本と思う。
とは言っても、リモートワーク普及に奇策はない。

【1】Planでは、ガイドラインを定めて形式知化する。
リモート責任者など組織体制も整備する。
経営層が率先してリモートで働く。
利用するツールは絞り込む。

他にもいくつか施策はあるが、割りと形式知化を重視している点が印象に残った。
リモートだからこそ、対面でのやり取りがないので、どうしてもローコンテキストな対話にならざるを得ないだろうから。

コミュニケーションルールも定める。
非公開情報ではSAFEアプローチを取る。
Sensitiveなのか、Accurateなのか、Financialなのか、Effectなのか、の判断基準を定めて、情報を公開しても良いのか判断する。

【2】Doでは、従業員の動機づけ要因、衛生要因を整備する。
リモートに合った組織文化が根付くように実行する。
心理的安全性を重視する。
人材戦略、つまり従業員の動機づけ要因では、ダイバーシティ、インクルージョン、ビロンギングを重視する。

ダイバーシティは、人種や性別、年齢、宗教、性的指向などの多様性を認めること。
インクルージョンは、マイノリティもマジョリティもすべての従業員が活躍できる状態を目指すこと。
ビロンギングは、自分の居場所はここである、という感覚。
帰属意識みたいなものかな。
一昔前の日本の会社の愛社精神みたいなもの。
今風ならエンゲージメントかな。

面白い点は、ビロンギングを重視していること。
従業員の流動性が高くても、帰属意識を重視しているのはなぜか。
たぶん、マズローの欲求5段解説で考えれば、帰属欲求が満たさなければ、承認欲求や自己実現を満たす欲求に達しないからだろう。

他にも、イテレーション、透明性も重視している。
この辺りはアジャイル開発の文化に近いので理解しやすい。

コンディショニングを実現する章は衛生要因の話だろう。
長期休暇制度、人間関係の構築、運動の推奨。

【3】CheckとActoinでは、KPIを用いた評価制度を作り、イテレーションごとにフィードバックを回していく。

SMARTな目標を定めて成果を評価する。
GitLabで活躍できる能力や意欲があるのに、マネジメントの問題で活かしきれない状況を避けるために支援する。
マネージャはメンバーを支援する。

優れたマネージャのコンピテンシーは事前に把握しておく。
感情的知性（EQ）、コーチング、衝突の解決、フィードバック文化の体現、高業績チームの構築。

Actionでは、メンバーに精神的成長と技術的成長を促す。
技術的成長を促すには、現状のスキルレベルと目指すスキルレベルの可視化が不可欠。
しかし、日本企業はスキルマップが画一的だったりそもそもなかったり、メンバーのスキル保有を把握していない。

能力開発のプロセスでは、コルブの経験学習モデルが有効。
具体的経験→内省的観察→抽象的概念化→積極的実践のサイクルを回して、能力を高めていく。
日本と海外の差は、抽象的概念化と積極的実践の部分だろう。

抽象的概念化では、普通の業務では既に他の人や過去の人が既に実践しているから、ノウハウや問題解決の手順は既に知られている。
しかし日本ではわりと形式知化されていないので、一人で暗中模索して試行錯誤しながら解決策を導く手間がかかる。
海外では形式知化されたマニュアルや書籍、トレーニングが充実しており、それらを通じて先人が得た整理された知識まで早期に到達することができる。

積極的実践では、せっかく研修したのに、研修に対して意味がないと感じたりネガティブな印象を持ったりする。
座学の場合は特にそうだろう。
だから、研修を実務に適用し、研修転移を進めるために、マネージャや周囲が定期的にコミットメントしたりフィードバックするのが大事になる。
GitLabでは、個人開発計画を作成し、メンバーのキャリア開発について議論しているという。

【4】そんな話を読むと、GitLabではリモートワークを単に活用しているだけでなく、包括的にメンバーの意識付けからスキルアップまで組織的に考えていることが分かる。
おそらく長年の試行錯誤を経て、3000ページにのぼるGitLabのガイドラインにまとめられたのだろう。

また、この本では、既に知られているビジネスやマネジメントのフレームワークがふんだんに使われていて、情報が整理されて理解しやすいと感じた。

パッケージ設計の原則の意義は変化しているのか

パッケージ設計の原則についてちょっと議論する場があり、色々考えるものがあった。
考えたことをラフなメモ書き。

【参考】
パッケージ設計の原則を本で学ぶ - Qiita

パッケージ設計６つの原則～ポイントは関連性/依存性/抽象度 | プレイン・プログラム

コンポーネントに関する6つの原則 - Qiita

【1】パッケージ原則6個の復習。

1. パッケージ再利用等価原則　Release Reuse Equivalency Principle
* 再利用の粒度はリリースの粒度と同じ
2. 共通閉鎖原則　Common Closure Principle
* クラスは共に変化し、共に存在する
3. 共通再利用原則　Coomon Reuse Principle
* 共に再利用されないクラスを同じグループに入れるべきではない
4. 非循環依存関係原則　Acyclic Depenedencies Principle
* パッケージ間の依存関係は循環してはいけない
5. 安定依存関係原則　Stable Dependencies Principle
* 安定している方向に依存する
6. 安定抽象原則　Stable Abstracttions Principle
* 安定したパッケージは抽象的であるべきだ

【2】パッケージ再利用等価原則が最も基本の原則と考える。

ちょっと昔のJavaシステム開発であれば、リリースモジュールwar/earがリリースの単位であり再利用の単位になる。
サブシステムごとにwar/earをビルドして検証環境でテストした後、オンプレの複数台のサーバー環境ごとに、複数のAPサーバーへwarを手動でデプロイしていた。
ロードバランサーからデプロイするサーバーを切り離して、1つずつwarファイルをデプロイして起動確認し、確認OKならば外部通信できるように設定していた。
つまり、そういう面倒な手動のリリース作業があった。

オンプレのサーバ環境にwar/earファイルをデプロイする単位は普通はサブシステム単位なので、そういう粒度で再利用しやすくする。
その場合、war/earファイルはできるだけサイズは小さい方がAPサーバ再起動時間も短くなるし、リリース作業も短くなるので、リリース作業ミスの確率も減らせる。

特に最近はAWSのようなクラウド環境では、サーバ環境そのものを使い捨てみたいにコンテナから自動生成するので、コンテナ(リリースする単位)のサイズが小さいほどサービスの再起動時間が短くなり、サービス停止時間も短縮化でき、顧客満足度も高くなる。
JavaGoldを取得した時に、モジュールの話で、モジュールサイズをできるだけ小さくしたい要望がある理由がそこにあると聞いて納得したことがあった。

クラウド上の開発がJavaに与えた影響は何なのか: プログラマの思索

Javaのモジュールシステムは複雑性をより増している: プログラマの思索

Javaのモジュールシステムの考え方をまとめてみた: プログラマの思索

【2】ただし、リリースモジュールの保守性や分割についてトレードオフがある点は理解できる。

実際、サブシステム単位にリリースモジュールwar/earをビルドする場合が多いので、普通はリリースモジュールのファイルサイズは非常に大きくなりがちだ。
なぜなら、リリースモジュールには、Apacheの共通ライブラリ、会社特有の共通ライブラリなどのJarという共通コンポーネントを多数含んでいるからだ。
同様に、RailsのようなWebアプリでも、bundlerの中には共通ライブラリGemを多数含んでいる場合が多い。

すると、リリースモジュールのファイルサイズを小さくしたくなる。
簡単に思いつくのは、リリースモジュールから他のサブシステムと共通で使う共通ライブラリは別出しして、デプロイする時は共通ライブラリは再リリースしなくて良いようにしたい。
APサーバ上に共通ライブラリを別で配置して事前ロードしておいたり、別APサーバ上に共通ライブラリを配置するケースも考えられるだろう。

メリットは、リリースモジュールのうち共通ライブラリは既にAPサーバにデプロイされているので再リリースは不要であり、リリースモジュールのサイズを小さくできる。
その分、ビルド作業時間、リリース作業時間を短縮でき、リリース作業ミスのリスクも減らせるだろう。

一方、デメリットは、共通ライブラリに手を加えた場合、既にデプロイ済みのサブシステムのwar/earファイルに影響が発生してしまう。
デグレがないか事前確認が必要だし、共通ライブラリがサブシステムのAPサーバとは別APサーバにデプロイされていて、共通ライブラリが複数のサブシステムから呼び出されているならば、複数のサブシステムに影響が発生してしまう。
共通ライブラリのリリース作業中にAPサーバを停止する事態が発生すれば、呼び出し側の複数のサブシステムで業務停止してしまうリスクが発生する。

また、共通ライブラリにサブシステムA向けのAPIを追加したり改修して、他のサブシステムB向けのAPIは触らない場合であっても、共通ライブラリをリリースする時にサブシステムAもBにも影響が発生してしまう。

だから、一般には、サブシステムごとに共通ライブラリを含んでリリースモジュールをビルドする場合が多いと思う。
すると、たとえば、サブシステムAの共通ライブラリXのバージョンは1.1、サブシステムBの共通ライブラリXのバージョンは1.2、みたいにコンポーネントのバージョンがサブシステムごとに違ってくる場合も発生するだろう。

つまり、サブシステムで利用する共通ライブラリのバージョン管理、構成管理が重要になってくる。
この仕組みがMavenであり、Railsならbundlerなのだろうと思う。
ライブラリやコンポーネントの構成管理というソフトウェアの複雑性をビルド管理の仕組みで補っているわけだ。

【3】では、昨今のアジャイル開発、DevOps、クラウドなどにより、パッケージ設計の原則の意義は変化しているのか？

メタな観点ではパッケージ設計の原則の意義は変わらない。
リリースモジュールは再利用できる単位であることは変わらないし、モジュールの分割方針やデプロイ方針も基本は変わらない。
しかし、具体的なリリース手順や開発プロセスは影響を受けていると思う。

例えば、SaaSビジネスでは、リリース作業時間は極力短くしたい。
リリース作業時間は広義の意味では、顧客に機能を提供するリードタイムと同じ。
BtoCのSaaSビジネスならば、機能改善の要件定義からリリースまでのリードタイムを短縮化する事は売上に直結する。
ちょっとした機能改善を即座にリリースできれば、顧客満足度も上がり、ユーザ数増加が売上につながるから。

また、特に昨今はクラウドでサーバーごとの仮想化するなどして丸ごとコンテナ化し、コンテナを使い捨てみたいにいくらでもデプロイできるから、リリース作業時間はできるだけ短くしたい。

これは、DevOpsの考え方と非常に相性が良いと思う。
DevOpsで開発チームがシステム運用と一体化したプロセスになるし自然にアジャイル開発になるはず。
つまり、アプリ開発者はアプリも開発するし、クラウド上でインフラ基盤もサーバー基盤もコンテナをプログラム化して自動配置できるようにすれば、開発も運用も一体化できるはず。

そして、リリース作業時間と言うKPIを開発チームが毎回計測し監視すれば、改善すべきか評価できるはず。
リリース作業時間、ビルド時間、デプロイ時間などはアジャイル開発の主要なメトリクスの一部と捉えられるだろう。
システム停止やデータ移行の時間も含めてリリース作業時間に3日間かかっていたのを、1時間で終わらせたり、わずか5分で終わらせれば、その分システム停止時間も短くでき、顧客の業務や顧客の操作時間への影響を減らせる。

そんなことを考えると、アジャイル開発やDevOpsという考え方は、サーバの仮想化やクラウドの技術のおかげで進化している部分も大きいのだろうと思う。
こんなことは既に当たり前の考え方と思うけれど、アプリ層の設計技法もインフラ基盤の仮想化技術に相当影響を受けているのではないか、と思う。

小説活動にプルリクエスト駆動が必要になってきた

小説活動にプルリクエスト駆動が必要になってきた記事を見つけたのでメモ。

【参考】
Pull Request駆動で小説を開発する

GitHub上に構築した小説執筆環境について

akipiiさんはTwitterを使っています: 「コミット履歴を整理するためにプルリクエストを使う発想。面白い。Pull Request駆動で小説を開発する https://t.co/EJ5fHkyr1O」 / Twitter

【1】まず、なぜ、小説家にGitHubが必要なのか。
理由は以前書いた。

GitHubが無料でプライベートリポジトリも使えることで小説家にもGitが必須になってきたのではないか: プログラマの思索

小説家がGitHubを使うメリットは2つあると思う。
一つは、小説というドキュメントがGitHubの構成管理の配下になることで、成果物の履歴管理の恩恵を受けられること。
もう一つは、GitHubのワークフローを受け入れることで、プルリク機能が使えて、ソーシャルコーディングならぬソーシャルライティングが可能になること

【2】次に、なぜ、小説家にプルリクエスト駆動が必要なのか。

小説家がGitHubのプルリクエストを使うメリットは2つある。
1つ目は、GitHubのコミット履歴が意味ある情報のみに集約できること。
2つ目は、ブランチが小説の各シーンのToDo管理に適用できること。

【2-1】1つ目は、小説というテキストをどんどんコミットしていくと、途中のToDoや作業中の成果物も全てmasterに反映されてしまう。
すると、小説が完成版に至るまでの作業履歴に、途中の作業履歴や思いついたアイデアの破棄などの雑多な情報が不純物として混じってしまって、最終成果物の品質を維持しにくくなる問題点がある。

本来は、1日では完成しきれなかった原稿、思いついたアイデアを試したがやっぱり捨てた原稿は、本流のmasterから分離して一時的に退避しておきたい。
つまり、未完成の原稿、思いついたアイデアの原稿は、トピックブランチで管理すべきなのだ。

そうすれば、本流のmasterには完成されたシーンの原稿だけが取り込まれることになるので、常に最新版の原稿の品質を維持することができる。
コミット履歴という情報を整理したい、という意見は、こういう意図があるのだろう。

【2-2】2つ目は、トピックブランチで、作業中の原稿や思いついたアイデアの実験を管理したいことにつながる。
トピックブランチは、作業中の原稿であり、実験で途中経過の原稿である。
つまり、トピックブランチは、小説のワンシーンに当たる各シーンのタスク管理を行っているわけだ。

トピックブランチのコミット履歴に作業中の状況を記載すれば、チケット管理ツールのチケットの作業履歴に相当する運用になっている。
GitHubならば、トピックブランチを派生する時にIssueを発行できるから、Issueで作業のステータスや重要度、作業履歴をリポジトリとは別に管理できる利点がある。

プルリクエストを行うことの意義は、トピックブランチで作業途中の成果物を管理すること以外に、チケット管理で作業状況のステータスや重要度を管理することもあるわけだ。

【3】Pull Request駆動で小説を開発する記事に知的刺激を受けた理由は、過去の偉大な哲学者や思想家は、GitHubのような優れた開発環境を知らなかったが故に、本来の創作活動の潜在力に一定の限界があったのだろうな、と思ったからだ。

akipiiさんはTwitterを使っています: 「@MadoWindahead 過去の偉大な哲学者ですら、プログラミングを知らなかった、というフレーズが強烈でした」 / Twitter

加速！#DevSumi #devsumiB pic.twitter.com/d8nFXH4bjc

— 門屋浩文＠redmineエバンジェリストの会主宰 (@MadoWindahead) February 15, 2019

門屋浩文＠redmineエバンジェリストの会主宰さんはTwitterを使っています: 「@akipii エンジニアの知的生産という本を書いた人のセッションでした」 / Twitter

門屋浩文＠redmineエバンジェリストの会主宰さんはTwitterを使っています: 「@akipii まだ、なさそう https://t.co/PO5I82pmft 参照してください」 / Twitter

デブサミ2019【15-B-1】エンジニアの知的生産術 ビフォー・アフター #devsumiB - Togetter

過去の偉大な哲学者や思想家に比べて、現代の知的生産者は、ワープロやPCという単純にオンラインで物書きできるツールがあるメリットだけでなく、GitHubのような優れた構成管理ツールを使いこなすことで、ちょっとしたアイデアの実験をトピックブランチで自由に試して、その中で高品質で完成したものだけをプルリクエストでマージして、高品質な成果物を生み出す仕組みを習得できる。
つまり、知的生産活動の難易度はたった50年前の人達よりも、はるかに楽になってきている。

GitHubが生まれるつい20年前までは、Wordで原稿を書けたとしても、途中の原稿はコピー新規で履歴管理したり、複雑なフォルダ管理でやるしかなく、相当面倒だった。
しかし、今の時代はそんなアホな成果物の管理をする必要もない。

そして、今後の成果物はGitHubで管理しやすいように、できるだけテキストで書いていくべきだ。
そうすれば、GitHubで成果物の履歴管理ができるだけでなく、思いついたアイデアの実験をトピックブランチで別で管理して、その作業状況も一括管理できるメリットがある。

そういう仕組みを上手く使いこなした方が絶対に良いに決まっている。

【資料公開】チケット駆動開発の解説～タスク管理からプロセス改善へ #redmine

プロジェクト＆プログラム・アナリシス研究部会で講演した資料「チケット駆動開発の解説～タスク管理からプロセス改善へ」を公開します。

【参考】
お知らせ2点：P&PA研究部会「チケット駆動開発」(1/11)、BOMに関する1日集中セミナー(1/27) : タイム・コンサルタントの日誌から

プロジェクト・マネジメント・システムは存在しうるか : タイム・コンサルタントの日誌から

【1】資料のテーマは、下記の通り。
基本的な前提として、Redmineの経験者を対象としている。

チケット駆動開発は、ソフトウェア開発で使われる障害管理ツールをタスク管理に利用する開発手法を指す。
チケット駆動開発はアジャイル開発と親和性が高いので、アジャイル開発のプラクティスを利用しやすく、チーム運営に役立つ。
チケット駆動開発を支えるチケット管理ツールは、汎用性が高く、とても有用な為、色々な業界の現場のプロセス改善に使われている。
チケット駆動開発の発端、仕組み、事例、プロセス改善に使われる理由を解説する。

チケット駆動開発、チケット管理ツール、Redmineというものを知らなければ、たぶん理解しにくかったかもしれない。

僕は、そういう内容を前提の上で、現時点で、チケット駆動開発とチケット管理ツールがどういう課題を乗り越えて、ここまで進化してきたのか、そして、今後はどんな未知の分野や課題があるのか、を整理して示したかった。
よって、70ページものボリュームになってしまった。

分かってくれる人に理解してもらえれば本望かなと思って公開してみる。

チケット駆動開発の解説～タスク管理からプロセス改善へ from akipii Oga

プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ

「プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ」というツイートを見つけたすごく共感した。

【参考】
Rui UeyamaさんはTwitterを使っています 「少数派の意見かもしれないけど、プログラミングしてるときはでっかいピタゴラ装置を作ってるみたいな感じで、数学が関係ある感じがあんまりしない。」 / Twitter

結城浩さんはTwitterを使っています 「@rui314 デバッグしてるときと証明読んでるときはなんか似てる。素直に読みつつ穴探ししてるみたいな感覚。」 / Twitter

英語勉強中さんはTwitterを使っています 「@rui314 めちゃくちゃわかります。僕は書いてるとき数学のことなんか考えてないです」 / Twitter

akipiiさんはTwitterを使っています 「プログラミングはこの感覚に近いな」 / Twitter

プログラミングは「ブロックを組み合わせる」感覚に似ている: プログラマの思索

「プログラミングのできる羊とできない山羊を区別する方法」の記事のリンク: プログラマの思索

「60%の人間はプログラミングの素質がない」記事のリンク: プログラマの思索

プログラマに必要なスキル: プログラマの思索

プログラムを書いている時、数学の知識を使っているかと言われるとそうではない気がする。
むしろ、APIやFWのライブラリをまずは頭に叩き込んでおき、自分が実装したい目標に対して、それらAPIをどうやって組み合わせて意図通りに動かすか、に注力している。
ちょうど、ブロックで巨大な積み木を組み立てている感じに似ている。

だから、「プログラミングしてるときはでっかいピタゴラ装置を作ってるみたいな感じ」にはとても共感するし賛同する。

たとえば、RDBでSQLをデータ抽出したり、機械学習や深層学習のライブラリを使って母集団を推定したり、マーケットを予測したり、Web上の通信を暗号化したりする時、数学の理論はAPIやライブラリの中に隠れてしまっている。
それらライブラリを呼び出すだけで、高尚な理論を使えるのは素敵だが、だからと言って、プログラミングが楽になっているわけではないと思う。

一方、やりたいことを実現するには、PythonやRDB、Webサーバー、Dockerなどの開発環境を揃えて、Githubで構成管理し、CIツールでビルド＆デプロイできるようにして、Jupyter を動かせるようにしたり、IntelliJなどの開発環境を構築したり、とプログラミングの前準備がすごく多い。
普通の初心者はこの部分で挫折するのだろうと思う。

僕自身、新しい環境を揃えてプログラミングスタイルを覚える時は割と苦痛に感じる時もあった。
Ruby on Railsもそうだし、AWSでの環境構築、GNS3でのCiscoルータ＆スイッチの環境構築の時もそうだ。
Python＋Anacondaはまだマシだった。
プログラミングは奥が深い。

チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine

チケット駆動開発のプロセスとチケット管理システムの全体像はこんなイメージではないだろうか？

チケット駆動開発のプロセスとチケット管理システムの全体像 from akipii Oga

【1】チケット駆動開発とは、チケットを起点として、業務の活動をすべてチケットで追跡する仕組みでありプロセスだ。

具体的には、リリース計画を作成して、チケットを一括登録したり、チケットを随時登録する。
登録されたチケットは担当者によって日々更新されたり完了されて、その進捗状況は、ガントチャートやロードマップなどのチケット集計機能によってリアルタイムにモニタリングできる。
管理者はこの情報を使って日々の意思決定やリスク管理に適用する。

リリースバージョンでグルーピングされたチケットが全て完了になったら、そのバージョンはCloseされて、成果物がリリースされる。
ソフトウェア開発ならば、バージョンつまりスプリントやイテレーションがCloseされると同時に、そのバージョンのモジュールがビルドされてデプロイされてリリースされる。

リリースされたモジュールや成果物は開発者が検証したり、ユーザが実際に使ってみて、開発者が見つけた障害修正やユーザの改善要望が管理者へフィードバックされる。
管理者はそのフィードバック情報を元に、次のリリース計画をブラッシュアップして、次のスプリントを開始する。

すなわち、チケット駆動開発とはアジャイル開発を実装したプロセスの一つとみなせる。

【2】一方、チケット駆動開発はチケット管理ツールという具体的なソフトウェア製品よって支えられている。
このソフトウェア製品という特性と実際の運用をまとめたものをチケット管理システムと呼ぶことにしよう。

【2-1】チケット管理システムの具体的な中身は何か？
基本はPMBOKが言うPMIS、つまりプロジェクト管理情報システムだ。
すなわち、チケットというインプット情報をPMISへ食わせた後、PMISがいろんな観点で加工して、PJ管理に必要な各種レポートをアウトプットして吐き出す仕組みだ。

第三者の観点から見れば、チケット管理システムはすごく単純だ。
なぜなら、インプット＋プロセス＋アウトプットという逐次実行の仕組みに過ぎないからだ。

【3】しかし、チケット管理システムというPMISの機能を解剖すると、単純な機械でありながら強力な機能を持っていることが分かる。
PMISの主な機能は、フロー管理とストック機能の2つだ。

【3-1】まず、フロー管理は、チケットを流通媒体とみなし、タスクをサクサク流すことに力点を置く。
MS Plannerのタスクカード、Agile開発やカンバン駆動開発のストーリーカードやタスクカード、申請承認ワークフローの申請書に相当する。
フロー管理では、作業のリズムを重視する。

【3-2】次に、ストック機能は、チケットを記憶媒体とみなし、日々の作業結果を記録していくことに力点を置く。
障害管理票や課題管理票、WBSなどの記録媒体。
過去の作業履歴、得られた経験や知識はチケットに記録されているので、チケットが蓄積されるほどナレッジ資産になる。
ストック管理では、ナレッジ基盤を目指す。

【3-3】実際は、チケットがフローとストックの2つの意味を二重に持っていることから、PMISはフロー管理とストック管理の機能を自然に持つようになる。
この特徴により、数多くのチケットを集計した結果から有用なメトリクスが得られる。
例えば、ガントチャート、EVM、リソース管理、タスクボードなど。
また、この特徴により、蓄積されたチケットの履歴やチケット間の関係、成果物とチケットの相互関係から、トレーサビリティの機能が生まれる。

【3-4】チケット駆動開発では、ビルドしたモジュールはバージョンというタグがあり、バージョンでグルーピングされたチケットがあり、そのチケットには作業履歴が残っていて、チケットには構成管理ツールの配下に置かれたソースコードや設計書などの変更履歴が紐づくように、運用される。
このトレーサビリティという機能があるからこそ、開発者は自信を持って開発できるし、管理者もリリースしたモジュールの品質を自分でコントロールできるようになる。

【4】チケット管理システムには、その運用を支える数多くのロールがある。
チケット管理をスムーズに運用するために必要なアクターがあることは、Redmineコミュニティで数多く研究されてきた。

【4-1】チケットを起票する現場の人は、PMISを業務のナレッジ基盤とみなす。
自分が入力した作業結果だけでなく、他人の作業結果も参考にして、ナレッジを利用することで自分の作業手順を効率化することに役立つ。

【4-2】管理者は、PMISをメトリクス集計のプロセス黄ばんと看做す。
彼らは、ガントチャート、EVM、リソース管理、タスクボード、信頼度成長曲線など各種の有用なメトリクスを用いて、業務活動の進捗管理、品質管理、要員管理をモニタリングし、日々の意思決定に活かす。

【4-3】お巡りさん（Redmine警察）は、チケット管理の守護神だ。
彼は、現場の人や管理者がチケット管理に困っていたら支援して、チケット管理をスムーズに運用させる。
チケットは生鮮食料品みたいなもので、日々更新されなければ、ただのゴミに過ぎない。
だから、お巡りさんは定期的にチケット管理システムを通じてチケット管理が運用されているか見て、チケット駆動開発を守る人になる。

【4-4】エバンジェリストはチケット管理の伝道師だ。
チケット管理がいかに素晴らしいか、チケット管理を通じて組織をどのように発展させていくべきか、現場の人や管理者を啓蒙する人だ。
エバンジェリストは熱い気持ちを持ち、チケット管理に関わる人の心に息吹や熱気を注入する人だ。

【4-5】PMISは、現場の人達や現場のプロセスに合うようにカスタマイズしたくなるので、マイスターという開発者がPMISをその現場特有のPMISへカスタマイズし、現場のプロセスに局所最適化する。
マイスターはまさにPMISの職人だ。
マイスターから見れば、PMISはPJ管理の開発基盤という側面も持つ。
つまり、チケット管理システムというPMISはプロジェクト管理を実現するソフトウェアフレームワークという開発基盤とみなせる。
すなわち、チケット管理システムはカスタマイズしやすい特徴を持つので、いろんな現場に適用できるように局所最適化しやすい。
だからこそ、改善が大好きな日本人にはチケット管理システムが合うのだろう。

【4-6】活動家は、PMISのログ（Redmineの活動タブ）を見て、現場の人達の活動、さらには組織の活動をモニタリングし、PMISを組織のプロセス改善の基盤として使う。
活動家は、1個のPJや1個の部署だけでなく、複数のPJや部署を横断して、人間の血液診断や健康診断のように、PMISを通じて組織の活動診断を行う人になる。

【5】こういうポンチ絵を描いてみると、チケットで作業も課題も障害も管理する、という単純なアイデアから生まれたチケット駆動開発は、いろんな側面に支えられて、豊富な応用結果を持つことが分かる。
こういうことを考えるのが楽しい。

脱Excel！ Redmineでアジャイル開発を楽々管理：エンジニアがお薦めする 現場で使えるツール10選（3）（1/5 ページ） - ＠IT

ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索

Redmine警察・マイスター・活動家は導入の立役者 | マドびっ！ Madosan's View

Redmineの普及促進にはRedmine警察やRedmineマイスターという役割の人達が必要: プログラマの思索

打ち捨てられていたRedmineが復活するまでの軌跡 - Qiita

第21回東京Redmine勉強会の感想 #redmineT ～Redmineは業務も組織も包み込む柔軟性がある

第21回東京Redmine勉強会の感想をラフなメモ書き。

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

2021/11/27 第21回勉強会 - redmine.tokyo #redmineT - Togetter

【1】最初は、@g_maedaさんのRedMica、そしてRedmineの最新機能の紹介。

【1-1】複数キーワードによるAND検索の実装は嬉しい。
チケット一覧から、Google検索みたいに細かい条件で検索できる。
チケット検索機能の強化につながるので、Redmineをナレッジ資産として使う現場としては貴重な機能と思う。

【1-2】チケット一覧でカスタムクエリをデフォルトで表示できるようになった。
PJごとに、みんなが見たいビューはたいてい決まっている。
最初にカスタムクエリで絞り込んでおけば、今日はどの作業に注力すればいいのか、考える必要もないはず。

【1-3】CommonMarkdownの試験的なサポートも興味深い。
斎藤さんのLTでは、Confluenceがすごく便利と話されていた。
実際、Confluenceでは、Wordのような直感的なUIで表も挿入できるし、履歴管理もすごく楽。
Confluenceがあれば、Excelの設計書を廃止して、すべてConfluenceで設計書を書くことができる。

一方、RedmineのWikiでは、Markdownの原稿を逐一プレビュータブで開いては確認する手間がかかる。
また、表のセルの結合、細かな文字の装飾も直感的ではない。

本来は、WikiはWordやExcelの代替機能になるべきだ。
そうすれば、Redmine上で、日々のタスク管理や課題管理はチケット、技術情報や設計書はWikiに全て集約できる。
それ以外の足りない機能は、REST APIやGit連携などの機能によって、他の外部ツールと連携すればいい。
最終的には、Redmine一つでPJの情報をすべて一括管理できるし、Redmineはナレッジ基盤そのものになるはずだ。

【1-4】Mermaid.jsによる作図機能は面白い。
PlantUMLみたいに、UMLのクラス図、シーケンス図、フローチャートをテキストで表現できる。
ただし、redmica_ui_extensionプラグインの機能なので注意。

個人的にはPlantUMLは好き。
モデルそのものもテキストで管理できれば、Gitで履歴管理できるので、設計書をソースコードと同じように管理できるのはいい。

My Redmine インストール済みプラグイン | My Redmine

GitHub - redmica/redmica_ui_extension: This plugin adds useful UI improvements to RedMica.

plantuml - Plugins - Redmine

Redmineには2つのPlantUMLプラグインがある - taikii blog

【2】第21回 パネルディスカッション ＜Redmineとわたしたち＞では、モデレータ、パネラーの女性5人によるフリーディスカッション。

【2-1】面白いのは、5人の女性のキャリアが全員違うことだ。
もちろん、5人全員がRedmine経験歴は10年なのでベテランばかり。

akipiiさんはTwitterを使っています 「Redmineを使う女性だけのパネルディスカッション。サーバ管理者、プロジェクトマネジャー、SEPG、PMO等の色々なキャリアを持つ。組込ソフトウェア会社、外資系、サービス系、メーカー系など色々な属性。面白そう。 #redmineT」 / Twitter

【2-2】僕の琴線に触れたのは、ともこさんとりょうこさんの発言だった。
りょうこさんは外資系SIのPMでPlanioを使っているので、プロマネ観点が多い。
だから、Redmineパトロールみたいにチケット保守や、多数の社外関係者のユーザの権限管理の観点が多くなる。

akipiiさんはTwitterを使っています 「PMの方の意見では、Redmineのパトロールが大事。Redmineの運用がずれてしまうので、定期的にチケットの運用をパトロールする。ゾンビチケットを駆除したりとか。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Redmineの良さ。半年前のチケットを元にコピーして今回の作業チケットを作れるので、差分だけ見ればよく作業漏れがなくなる。関連チケットでチケットを相互関係付けられる。色んな会社の人が使うので権限管理が細かく決められるのがいい。 #redmineT」 / Twitter

一方、ともこさんは全社のソフトウェアの障害管理、全社PJのゲートレビューの管理、Redmineサーバーの管理をされているので、PMOの観点が多い。

akipiiさんはTwitterを使っています 「Redmineが使いにくい所では、UIが初心者のハードルが高い意見が多いが、UIよりもワークフロー設計の方に課題がある意見の方に興味を持った。トラッカーとステータスで障害管理、定常業務の作業管理のワークフローをどう設計するか？の方が重要だし腕の見せ所と思う。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Redmineに限らずチケット駆動の弱点の一つは、チケットの説明欄が自由すぎること。起票者の能力によってバラついて作業連携やコミュニケーションにロスが出る。そこでテンプレートを用意したり、事前にテンプレートチケットのリンクをWikiに用意して誘導する。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Redmineを通じて対面だけでなく非同期のコミュニケーションもやっている。1年前の障害チケット、既に去った人が書いたチケットを読んで意図を理解する。チケットの説明欄に、障害内容や関連するチケットがこれです、と書けば伝えられる。書いて伝える能力が要求される。 #redmineT」 / Twitter

【2-3】女性ならではの観点では、お母さんみたいな役割もあるらしい。
この辺りは中年男性の僕には分からない笑。

akipiiさんはTwitterを使っています 「管理者がオレオレ運用ルールを押し付けると、メンバーは何でやねん！と反発してしまう。そこで相談しやすい雰囲気を作って、お母さんみたいな役割を持って、悩みを聞きまくる。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Redmineをパトロール中に、この表現はダメだよね、と気づいたら、チケットもコメントもコッソリ直したり指導する。IT技術者の説明はぶっきらぼうで、これが仕様です、と書いてもノンITの人には伝わらない。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「心理的安全性を高めて雰囲気を良くして、チケットに書いたら、お互いに時間を有効に使えるよ、と伝えたい。 #redmineT」 / Twitter

【2-4】5人のディスカッションでは、「柔軟性」というキーワードが多かった。
「Redmineはユーザとツールの観点で柔軟である」と。

ツールの観点では、Redmineはプラグインやパッチのおかげ機能追加がすごく柔軟な特徴を持つ。
一方、ユーザの観点では、Redmineは現場の人たちのニーズに応じて、運用ルールを柔軟に変更してFitさせることができる。

僕は、「柔軟性を英語でいうと、Elasticと思う。AWS用語でよく出ると思う。 #redmineT」と思っていたが、どうやらFlexibilityの方がイメージが合っていると思う。

akipiiさんはTwitterを使っています 「柔軟性には、ツールの柔軟性と人としての柔軟性の2つの観点がある。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「100人上のユーザの中で女性PMが一番Redmineが詳しいが、若い人の意見に時々はっと気づく時がある。自分が決めた運用ルールが絶対ではないのでこう変えてもいいかもと思う時もある。人の柔軟性を実現してくれる柔軟なツールがRedmine。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Redmineは、各人が貯めている経験や知識を吐き出すのに向いている。他人の言葉にハッとする時はむしろTwitterや対面の方が多いのではないか。 #redmineT」 / Twitter

【3】田畑さんの森林管理でRedmineを利用している事例はとても面白かった。
岡山の山奥の村に、林業でDXをやっているらしい。

【3-1】Redmineを使う場面は、補助金の申請業務や日々の作業管理。

akipiiさんはTwitterを使っています 「林業だけでは収入が少ないので、補助金の書類が大事。書類が多い。そこでRedmine。人によって情報格差が大きい。知っている人は作業できるが、知らない人は作業できない。ストレスが溜まる。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「ステータスは、下請けさんの作業街が多いので追加。監督者対応中も追加して65歳の監督者を想定。補助金の申請業務は他者対応待ちを追加。実際の業務で必要だから。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「プロジェクト＝現場。バージョン＝作業監督。チケット＝作業で数時間。トラッカー＝設計、実施、監査など。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「トラッカー＝設計、監督、実施後で作ったが、WFが同じなので分ける必要はなかったかもしれない。 #redmineT」 / Twitter

【3-2】Redmineで工夫している点は、ワークフロー設計と、GTTプラグインを入れて、チケットに地図情報を記載している点だ。
実は、第20回勉強会 - redmine.tokyoで「 第20回 LT: Redmineで地理空間情報を扱う、Redmine GTT (Geo-Task-Tracker) plugin の紹介」で知って、取り入れたらしい。

Redmineと地図情報を組み合わせるアイデアは面白いと思う。
営業活動や配送管理などにRedmineを適用できるのではないか。

akipiiさんはTwitterを使っています 「森林管理は口承伝承。作業手順を文字化して標準化したい。作業手順記録はWiki、作業状況確認はRedmine＋GTTプラグイン。前回勉強会LTのGeoTaskTrackerプラグインを使う。 #redmineT」 / Twitter

GitHub - gtt-project/redmine_gtt: Plugin that adds spatial capabilities to Redmine

akipiiさんはTwitterを使っています 「チケットにGTTプラグインの地図情報が表示される。チケット説明は簡単に書く。詳細はWikiに書く。チケットの説明に詳しく書くと流用しにくい。 #redmineT」 / Twitter

【4】僕も久しぶりに「Redmine屋から見たMS Planner #redmineT」を講演した。
Teamsに付属しているPlannerを使っているのだが、とにかく使いづらくて仕方ない。
Plannerは所詮ToDo管理に過ぎず、もっと細かなタスク管理や課題管理をやるのには向いていない。
当たり前なんだけどね。

MS PlannerはRedmineと違って使いにくいのは複雑なワークフロー管理ができないから: プログラマの思索

懇親会で聞いてみたら、ブレークアウトルームの大半の人はTeamsを使っている。
Slackを使う人はごく少数。
Office365を使う企業は多いので、Teams利用者が圧倒的に多い。
すると、フリーのPlannerも付属してくるので皆知っている。

しかし、Plannerは使えませんという声が圧倒的だった。
興味深い意見は、Plannerのタスクには更新履歴が残らないので、ナレッジにならない。
使い捨てのカードみたい。
PostItの感覚でしか使えない。
本来は、Redmineのように、完了したチケットでも後から参照したいのに、と。

【5】今回の勉強会は参加者が100人にも到達しなかった。
同日開催の裏番組のOL勉強会が多かったせいだろう、という意見が多かった。

また、@naitohさんのRedmine.tokyo21 questionnaireの通り、初めての参加者が少なく、4回以上の参加者が圧倒的に多くなっている。
この傾向に危険を感じる人も多い。

でも僕はあまり気にしていない。
我々の勉強会が楽しくて盛り上がっていれば自然に人は集まる。
誰でも参加できるような雰囲気さえあればいい。
他人の都合に合わせる必要はないし、こちらの雰囲気が良くて気になるなら、こちらの都合を合わせてくれればいい。

コミュニティはボランティアなので、過大なコミット感まで持たなくていい。
むしろ、緩く長く続けることのほうが大事と思う。
年2回開催という絶妙のバランスのおかげで、スタッフの作業負荷も大きくない。
5月、11月に定期的に開催できるリズムがあるから、参加者もスタッフも講演者も予定を入れやすい。

この勉強会ももう10年以上も続いているのは一つの奇跡だと思う。
他のアジャイルコミュニティも浮き沈みがあって、スタッフの入れ替え時期には開催できなかったりしていた。

三浦かずひとさんの通り、純粋に楽しめればいいと思う。

みうら かずひとさんはTwitterを使っています 「#redmineT 最近RedMineに対する思いもないし、特段興味を持って参加ではなかったのだけど…「利用者視点かつファンでない視点で見つめる」と、「お、工場？」「お、林業？」とか、凄く純粋に楽しめました。」 / Twitter

【6】2021年もAdventCalendarをやっているので、興味のある方はぜひ応募してみてください。
書いてみると、1年後には記念になるのがいいです。

Redmine Advent Calendar 2021 - Adventar

Redmine屋から見たMS Planner #redmineT from akipii Oga

RedMica 2.0 (2021-11) 新機能ハイライト de Go Maeda

ある工場の Redmine 2021 ( Redmine of one plant 2021 ) from Kohei Nakamura

Redmine.tokyo21 questionnaire from Jun Naitoh

Redmineで地理空間情報を扱う、Redmine GTT (Geo-Task-Tracker) pluginの紹介 from Ko Nagase

AWSサービスとSW品質特性のマッピングはどうなるか

ふと思いついてメモして、Blogに書くまで昇華できていないアイデアを書き殴っておく。
AWS初心者のロジカルでないメモ。

AWS Fargate とは？「コンテナ」と「仮想マシン」の違い｜AWS上のコンテナ関連のサービス | FEnet AWSコラム

AWS Fargateとは？Amazon ECSとの関係性やメリット・デメリットを解説｜コラム｜クラウドソリューション｜サービス｜法人のお客さま｜NTT東日本

AWSサービスとSW品質特性のマッピング一覧を作ることで、クラウドが何を解決しようとしているのか、整理したいと思っている。

AWSの最大の恩恵は移植性だろう。OSパッチやセキュリティパッチの作業から基本は解放される意義は大きい。
他にも、障害耐性などの機能性やAutoScalingなどの効率性もあるだろうが、盲点なのは保守性ではないだろうか。

Infrastructure as Codeにより、サーバー構築は全て構成管理の配下に置かれ、保守性を大きく担保する。
しかし、それはアプリケーション層のApacheのhttpd.confの構成管理を意味しているわけではない。
むしろ、AWSがNW機器の物理的実体からデータプレーン、コントロールプレーンという論理的実体へ分離することで、膨大なネットワーク機器を一括管理し構成管理できるようにした点が大きな利点のはず。
AWS上で「データプレーン」を提供しているのは「AWS Fargate」と「Amazon EC2」、AWS上で「コントロールプレーン」を提供しているのは「Amazon ECS」と「Amazon EKS」です、という文言を偶然拾って、ああそういうことなのか！と気づきを得た。
だから、Kubernetesが画期的な技術なわけだ。
CCNAを取得したおかげでこの辺りの意義がなんとなく実感できたから。

インフラ関係のPJをレビューしていていつも思うのは、専用回線の切り替えやDNS切り替えだけのNWリプレースの作業のPJで割と本番障害が多くて、なぜたかがNW機器の入れ替えぐらいでそんなに作業ミスが多いの？といつも思ってた。
DNS切り替えなんて所詮、向き先を変えるだけでしょ、と思ってた。
たぶん、その背後には、数多くのNW機器があり、その設定ファイルを手作業で書き換えて、手作業で検証する必要があって大変なのだろう。
だから、NW層のレベルで構成管理できる意義はとても大きいのだろうと推測している。

なぜ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という考え方はそれを解決する一つの技術と捉えられるのだろう、と思う。