中身は表題通り。
@echo off setlocal set start=1 set end=20 rem set output=%%i:~-2% setlocal enabledelayedexpansion for /l %%i in (%start%, 1, %end%) do ( set dirname=hoge00%%i set dirname=!dirname:~-2! mkdir !dirname! )
バッチファイルは正直苦手。わかりにくくて、触っていてフラストレーションがたまる。。
産業用途で、抜け防止にDVIコネクタのようなロック機構が好まれることがある。
しかし、DVIコネクタは巨大だ。
今所属している会社の産業用アクチュエータ・ロボットのコントローラ（PLC）もこんな感じでDVI１個でかなりの前面を占めている。
USB-Cは小さいけど、産業用途としてどうなんだろうと検索してみるとロック機構のついたUSB-Cというものが存在していた。
規格外でオリジナルかと思いきや、USB規格の一部として存在していた。
２つのネジで固定するタイプ
１つのネジで固定するタイプ
USB Type-C® Locking Connector Specification | USB-IF
将来的には4個くらい搭載してソフトウェア更新用途などで使うデータ転送USB、ディスプレイ（表示機）接続用USB、Ethernetネットワーク用USBとかまとめられたりするんだろうか。
MBSEのデータ中心は文書（ドキュメント）を不要とするのだろうか。
MBSEでよく目にするキーフレーズの１つに、ドキュメントを中心とした成果物からデータを中心とした成果物への移行があるように思う。
参考：
MBSE is Not SysML - Jama Software
そして、データ中心に移行するために様々な入力・編集・表示を行うMBSEツールが必要とされている。そうでなければ、容易に再利用できるデータとならない。
ここで、引っかかる点としてデータ中心に移行したら、将来的にはデータを扱うMBSEツールのみで完結し、文書は不要になるのだろうか、という点である。
データを中心に据えながらもそれを、表示する文書は必要である、というのが現時点での私の回答である。
実際、MBSEツールでダイアグラムを作ったとしても、それと類似のプレゼンテーション文書を作ったり、そのダイアグラムを貼りつけたWordの文書を作ったりしている。
データを中心にしながらも、その周りに適宜必要な文書を作成し、補完している感覚である。
例えば、次のようなダイアグラムでデータ（MBSEモデル）を構築したとしても、誰かに説明するために、もう一度同じ構造でアームやドライブの写真や絵を使ったプレゼンテーションを作るというのがパターンである。
プレゼンテーションの視点（ViewPoint）は読み手に依存し、表現が異なる。つまり、読み手に合わせて表現を変えていく必要があるということを示唆している。
（ISO 42010より）
とはいえ、ある区切られたチームとプロセスで必要となる表現がすべてそろうならば、ツールのみで完結することも可能となるのかもしれない。
このある限られた表現セットを再利用可能な形で定義することで、毎回視点から検討しなくても良くなる。
ただ、毎回わずかに視点が異なるから、結局ある程度のフレキシビリティが必要なるところに難しさも生じているように感じる。
結局、データ中心にすることで文書間の整合性が保たれたり、データのみで完結するケースもあるが、文書はコミュニケーションのためにこれからもずっと必要になるのだと考える。
最近、自身の関わるシステムが情報システムから、物理的に人と相互作用するシステム（ロボット等）や、ツールを使って人を中心とした何かを成し遂げるシステムに関わることが多くなったように思う。
それらは、一般的にはシステムというよりも仕組み、取り組み、ワークショップのような名詞の方がしっくりくるかもしれない。
このような現場にいて思うのは、情報システムと同じかそれ以上に要求を精緻なものにして、かつ、それを共有することの困難さだ。
それを困難にしていることの１つは、言語の違いだと思う。
ソフトウェア設計者同士であれば、細かい表記方法までは知らずともUMLは共通の言語として知っていることも多く、モデリング言語そのものに迷うことがあまりなかった。
しかしながら、多様な人が集まって何らかのシステムを構築するとき、UMLは現状その共通言語となりえない。
そして、誰にもわかりやすいいわゆるパワポの図のようなものを作るのだ。
このとき、最初からパワポで作っても良いかもしれないが、そうするとパワポは自由すぎて不便なのである。
モデリング言語（考えの枠組み）を考えながらモデリングしたい対象を表現するような感じになってしまう。
だから、いったんUMLやSysMLのような特定の言語でモデリングしておき、それをベースにしてパワポに言語変換することを時々している。
大学のとあるプロジェクトのためにWBSを記述することになった。
PowerPoint、Miroなどを試した後、astah*のクラス図を使ってみた。
ワークパッケージをネスト関係を使って階層構造にしていく。
ツリー構造なら何でもよいと思うが、モデリングツールを使う利点は「図」とは別に、構造を伴ったモデルデータがあることだ。
部分的なWBSを作りたければ、ダイアグラムをもう１個作ってドラッグするだけで良い。
PowerPointやMiroなどのお絵かきだともう一度作り直しとなる。
また、どこかのダイアグラムでワーク名を変えたとき、他のダイアグラムも追従してくれる。
別にastah*でなくても、UMLモデリングツールであれば、同じことができる。慣れているツールを使うのが楽である。
数年前にロバストネス分析について記事にした．
hiroi.hateblo.jp
この分析を含むICONIXプロセスを世に展開，下記を執筆されたDoug Rosenburgさんがその後にどんな活動をされているかを調べてみた．
Use Case Driven Object Modeling with UML: A Practical Approach (Addison-Wesley Object Technology Series)
すると近年は「並列アジャイル（Parallel Agile）」と呼ばれるものについて展開されているらしい．
どうやらつい先日，astahのセミナーでICONIXプロセスが紹介されたらしい．
昨日の astash セミナーの内容を平鍋さんがまとめてくださいました。
— hiro@miraito (@hirodragon112) 2020年8月22日
ありがとうございます！
そして逆に勉強になります！
実際のhiroさん笑 https://t.co/NdOIImhej9
そして，その後の平鍋さんがまとめられた記事で私の以前の記事が触れられていた．
anagileway.com
たまたま上の記事をtwitterで見かけ，ロバストネス分析やICONIXプロセスのことを思い出した．そのついでにICONIXプロセスってその後どうなったのだろう，と気になり少し調べてみたので記録しておく．
さっと調べた限り，2本の論文（ArticleとSpecial Issue Paper）が見つかった．
The parallel agile process: Applying parallel processing techniques to software engineering
まず，新しい方の論文について．Abstractから後述の論文と比較して，VR/ARゲーム開発における適用が追加されている．また，Abstractの以下の記述にあるように，並列開発がキーとなっているアジャイル開発プロセスとなっているようだ．
The paper summarizes the overall challenge of software schedule compression, identifies managed parallel development as generally the most powerful but least‐ practiced strategy for schedule compression, and summarizes the key elements required to support parallelism.
Rapid, evolutionary, reliable, scalable system and software development: the resilient agile process
本論文は古い方ではあるが，以下にある通り，並列アジャイル（この時点ではResilient Agileと呼称）を進化させた経緯が記載されている様である．こちらから読んだ方がより理解が進むかもしれないと感じた．
This paper summarizes our experience in defining and evolving RA by applying it to three representative emergent-technology applications
まだポチッてもいないのだが，今年（2020年初頭）には，書籍も執筆・発行されている．
Parallel Agile book — available NOW! | by Doug Rosenberg | Parallel Agile Blog | Medium
読んでみた結果，これは！となったらまた追って記事にしようと思う．
