業務システムの開発プロセスと、モダンなバージョン管理システムの機能のインピーダンスミスマッチ

ISO 12207、ISO 9126、IPAの情報システム・モデル取引・契約書のような契約に基づくシステムの開発プロセスって、モダンなバージョン管理システムで管理できるんだろうか？ たとえば以下のような仮定を置いた場合に、ソースコードに対する変更はどのようにモデル化され、それがバージョン管理システムの機能のうえにどうマッピングされるのか？という話。

• 全体をサブシステム毎に分けて、明確な責任分界点や工程毎の期限を設け、発注単位毎の独立性を保ったうえで開発・テストを進める
• 自身の責任分界点の外側のソースの内容を理解することは求められていない
• 作業者間で相互の信頼に基づく情報の共有は行われない
• 変更はCCBからの命令に基いて行われており、その命令以外の変更は入っていたらダメ
• 複数の命令を一つの変更にまとめて実施してはならず、命令と変更とは一対一対応する必要がある
• 複数のテスト環境のうえでテストと変更が同時に行われており、「最新のソースコード」と「各テスト環境にデプロイしたいソースコード」が一致しない（その時点で最新のソースコードのうち、テスト環境ごとに入っていてよい変更と入っていてはいけない変更とが存在する）
• 最終的にデプロイされるソースコードの正当性は開発者とは別のCCBが確認するが、CCB自身はソースコードの変更は行わない

たとえばSubversionのmoderator機能や、バージョン管理システムそのものではないけれどGitHub/GitLabのPull Request/Merge Request機能はCCBによる確認に使えるかもしれないが、mergeの際のconflictの発生を回避するためにどのような運用になっている必要があるか？とかは検討されていないのでは。

サティア・ナデラが言った「Appleは端末屋、Googleは広告屋、じゃぁ俺たちは？」の出典

日本語で「サティア・ナデラ マイクロソフト アップル 広告 端末」とかで検索しても全然引っかからないし、出てくる検索結果は会員限定記事ばかりなので、英語で2015年以前の記事に限定して検索したらTechCrunchの記事がすぐに出てきた。

Here's What Microsoft CEO Satya Nadella Thinks Apple And Google Do Best | TechCrunch

Appleは端末屋、Googleは広告屋、俺たちはモノを作るやつらを助ける会社（empowering others to build products）というのがこのときのナデラの見立て。

WindowsのWSLでSSHのpemファイルをchmod 400できない

問題

WindowsからWSLのSSHで公開鍵（.pem）を使ってログインしようとした際、pemファイルのパーミッションがowner以外から読み出し可能になっていると、OpenSSHが以下のようなエラーメッセージを出して接続に失敗する。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Windowsだと、ブラウザからNTFS上のディレクトリにダウンロードしたファイルのパーミッションはWSLから見るとデフォルトで777になるので、AWS EC2接続用のpemファイルをダウンロードしたときなどにこのメッセージを見ることがある。

stackoverflow.com

ここで、WSLでsudo chmod 400を実行すると、pemファイルのパーミッションが400にならず、なぜか555とかになってしまう。chmodコマンド自体も特にエラー等は返さない。

satob@K690XN:/mnt/c/tmp$ ls -la x.pem
-rwxrwxrwx 1 satob satob 387 Mar 18 00:23 x.pem
satob@K690XN:/mnt/c/tmp$ sudo chmod 400 x.pem
satob@K690XN:/mnt/c/tmp$ ls -la x.pem
-r-xr-xr-x 1 satob satob 387 Mar 18 00:23 x.pem
satob@K690XN:/mnt/c/tmp$

原因

WSLで/mnt/以下のファイルに対してchmodを実行した場合に上記の挙動になる模様。

対策

WSLで/home/以下のディレクトリにpemファイルをコピーしたあとにchmodを実行すれば、正しくパーミッションを400に設定できる。

注意事項

Stack Overflowなどで検索すると、PowerShellからicacls.exeを実行する方法が回答として挙げられていたが、自分の環境ではいずれもWSLから見たときのパーミッションは400にならなかった。

superuser.com

上記を実行するとパーミッションは400でなく444になった。

PS C:\tmp> icacls.exe x.pem /inheritance:r
処理ファイル: x.pem
1 個のファイルが正常に処理されました。0 個のファイルを処理できませんでした
PS C:\tmp> icacls.exe x.pem /grant:r "$($env:username):(r)"
処理ファイル: x.pem
1 個のファイルが正常に処理されました。0 個のファイルを処理できませんでした
PS C:\tmp>

satob@K690XN:/mnt/c/tmp$ ls -la x.pem
-r--r--r-- 1 satob satob 387 Mar 18 00:23 x.pem

しかも、そのあとWSLでchmodを実行しようとすると、sudoしているのにPermission deniedが返るようになった（原因不明）。

satob@K690XN:/mnt/c/tmp$ sudo chmod 400 x.pem
chmod: changing permissions of 'x.pem': Permission denied

superuser.com

上記を実行するとパーミッションは400でなく555になった。

PS C:\tmp> icacls.exe x.pem /c /t /Inheritance:d
処理ファイル: x.pem
1 個のファイルが正常に処理されました。0 個のファイルを処理できませんでした
PS C:\tmp> icacls.exe x.pem /c /t /Grant ${env:UserName}:F
処理ファイル: x.pem
1 個のファイルが正常に処理されました。0 個のファイルを処理できませんでした
PS C:\tmp> TakeOwn /F x.pem

成功: ファイル (またはフォルダー): "C:\tmp\x.pem" は現在ユーザー "K690XN\SATOB" によって所有されています。
PS C:\tmp> icacls.exe x.pem /c /t /Grant:r ${env:UserName}:F
処理ファイル: x.pem
1 個のファイルが正常に処理されました。0 個のファイルを処理できませんでした
PS C:\tmp> icacls.exe x.pem /c /t /Remove:g Administrator "Authenticated Users" BUILTIN\Administrators BUILTIN Everyone System Users
処理ファイル: x.pem
1 個のファイルが正常に処理されました。0 個のファイルを処理できませんでした
PS C:\tmp> icacls.exe x.pem
x.pem K690XN\SATOB:(F)

1 個のファイルが正常に処理されました。0 個のファイルを処理できませんでした

satob@K690XN:/mnt/c/tmp$ ls -la x.pem
-r-xr-xr-x 1 satob satob 387 Mar 18 00:23 x.pem

上記いずれの場合も特にエラーメッセージが返ることはなく、エクスプローラからファイルのプロパティを確認すると所有者だけに権限がついている状態になっていたので、icacls.exeの実行自体が失敗しているということはなさそうに見える。

デジタル庁 情報システム調達改革検討会のフォローアップ資料を読む

www.nikkei.com

日本の公共調達でアジャイル型開発プロセス（以下、アジャイル開発）を採用しようと思ったら、調達方式・契約形態の話は当然避けて通れません。2022年度にデジタル庁は「情報システム調達改革検討会」を立ち上げました。

www.digital.go.jp

2022年度の成果としてまとめられたデジタル庁情報システム調達改革検討会 最終報告書 簡易版では「アジャイル開発の導入ガイドの整備」「契約方式・調達仕様書・調達方式の整備」をやっていくぞということになっています。

で、その後2023年度が終わり、今年1年で何をやって、何が分かり、何ができたんだっけ？という資料である 2023年度デジタル庁情報システム調達改革のフォローアップ が出てきました。 簡易版の方は内容が要約されすぎてて成果しか書かれておらず、その背景にどういう思いがあるんだろう？とかが分からないので通常版の方を見た方がいいです。

で、p.12が「実際にこういうことをやってみました」という内容、p.14～16がその結果分かったことのまとめです。どうも、発注元も課題が大量にあるし、受注者側も気を抜けない状況という感じのように読めます。

• p.12で「アジャイル開発の採用や調達単位変更の試行」を行ったとあるのですが、結局2022年度の最終報告書に書かれていた「アジャイル開発の導入ガイドの整備」「契約方式・調達仕様書・調達方式の整備」とかは実施されていない模様。最終報告書が出たのが2023年3月だったので、当然2023年度予算はそれよりずっと前に提出されているわけで、2023年度はいったん最終報告書の内容は横に置いておいて、予算策定時に検討されていた内容？として「試行してみようぜ」をやったってことなんですかね。

• p.14は主に「ウォーターフォール型開発だったら、発注元は発注後の作業はそんなに多くなくても回せていたのに、アジャイル開発だとスクラムイベントとかで発注後も定期的な稼動発生してツラい」とかいう意味だと思われます。ほかにもスクラムでやろうと思ったら特にプロダクトオーナーには超人が求められるわけで、そりゃ発注を細分化しようとすればリソースの問題は出るだろうな、と思います。あとは今後の取り組みに「外部の先進的な成功例も参考とし」と書かれているのがちょっときな臭い。参考元が民間だと「アジャイル開発にしたらよりチャリンチャリンするか？」「早期撤退が良い判断と認められるか？」、参考元が米国だと「官公庁におけるITエンジニアの総数の違い」とかがあるので、自分としてはローカライズが必須、場合によっては前提条件ふまえて一から指針を作った方が早道なのではという気がしているのですが……

• p.15は契約形態の話で、調達改革検討会の中でも「公共調達なんだからまず透明性を確保しなさいよ」と言われていた点につながるので、デジ庁の中だけに閉じる話じゃないのでは？というのが感想。

• p.16は調達単位の設定の話。まず前提として「発注元の人的リソースに不足がありツラい」という状況と、「中小・スタートアップ企業等の多様な事業者が参入出来る案件規模に分割」したいという思惑が噛み合っていないように見える。さらに、受注者の規模をめがけて調達単位を区切ろうとすると、既設システムがある場合なんかは「システムとしてソフトウェア工学的に適切な分割範囲」でなくなる（分割損が出るだけならまだよくて、発注単位優先で分けた結果発注先間で作業に順序関係が発生したらその調整も必要だし、場合によっては発注先ごとに業務知識量が異なることで発生する軋轢みたいなものまで気にする必要が出てくる）。さらに、「調達単位の細分化に係るリスクやメリット・デメリットについて、発注担当者の理解が進んでいない」とか言われている。これって「何がしたいのか自分に思いはありませんが、上からアジャイル開発で調達範囲分割しろと言われております！」みたいな状況を誘発するのでは？

日経コンピュータの記事単位のPDFを購入する方法

職場に置いてある日経コンピュータに気になる記事があって「定期購入とかは要らないんだけど、この記事だけあとでKindleで読めるようにしておきたい！」みたいなときに、「日経コンピュータ 記事購入 kindle」とかでググってもぜんぜん目的に合致したページが引っかからないのでメモしておく。

1. 日経BP SHOPのページにアクセスする。日経BPマーケティングのページや日経クロステックのページからはリンクされていないので注意。
2. トップページの検索欄で「雑誌を記事単位で検索」を選択。日経xTECHのページから記事単位での購入をしようと思っても、やはりリンクがないので注意。

   

   「雑誌を記事単位で検索」を選択

3. 検索欄に記事の名称を入れて検索し、一覧の中から購入したい記事を選択。記事を買い物カゴに入れて購入する。Amazon等からの購入方法はない模様。
4. 日経IDにログインし、氏名・住所・電話番号、支払い方法（クレジットカード情報）を入力すると購入できる。PDFのダウロードは100回まで可能。