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

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

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

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

p.12で「アジャイル開発の採用や調達単位変更の試行」を行ったとあるのですが、結局2022年度の最終報告書に書かれていた「アジャイル開発の導入ガイドの整備」「契約方式・調達仕様書・調達方式の整備」とかは実施されていない模様。最終報告書が出たのが2023年3月だったので、当然2023年度予算はそれよりずっと前に提出されているわけで、2023年度はいったん最終報告書の内容は横に置いておいて、予算策定時に検討されていた内容？として「試行してみようぜ」をやったってことなんですかね。
p.14は主に「ウォーターフォール型開発だったら、発注元は発注後の作業はそんなに多くなくても回せていたのに、アジャイル開発だとスクラムイベントとかで発注後も定期的な稼動発生してツラい」とかいう意味だと思われます。今後の取り組みに「外部の先進的な成功例も参考とし」と書かれているのがちょっときな臭い。参考元が民間だと「アジャイル開発にしたらよりチャリンチャリンするか？」「早期撤退が良い判断と認められるか？」、参考元が米国だと「官公庁におけるITエンジニアの総数の違い」とかがあるので、自分としてはローカライズが必須、場合によっては前提条件ふまえて一から指針を作った方が早道なのではという気がしているのですが……
p.15は契約形態の話で、調達改革検討会の中でも「公共調達なんだからまず透明性を確保しなさいよ」と言われていた点につながるので、デジ庁の中だけに閉じる話じゃないのでは？というのが感想。
p.16は調達単位の設定の話。まず前提として「発注元の人的リソースに不足がありツラい」という状況と、「中小・スタートアップ企業等の多様な事業者が参入出来る案件規模に分割」したいという思惑が噛み合っていないように見える。さらに、受注者の規模をめがけて調達単位を区切ろうとすると、既設システムがある場合なんかは「システムとしてソフトウェア工学的に適切な分割範囲」でなくなる（分割損が出るだけならまだよくて、発注単位優先で分けると発注先間で作業に順序関係が発生したりするのでその調整まで必要になる）。さらに、「調達単位の細分化に係るリスクやメリット・デメリットについて、発注担当者の理解が進んでいない」とか言われている。これって「何がしたいのか自分に思いはありませんが、上からアジャイル開発で調達範囲分割しろと言われております！」みたいな状況を誘発するのでは？

2024-04-28

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

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

日経BP SHOPのページにアクセスする。日経BPマーケティングのページや日経クロステックのページからはリンクされていないので注意。
トップページの検索欄で「雑誌を記事単位で検索」を選択。日経xTECHのページから記事単位での購入をしようと思っても、やはりリンクがないので注意。
「雑誌を記事単位で検索」を選択
検索欄に記事の名称を入れて検索し、一覧の中から購入したい記事を選択。記事を買い物カゴに入れて購入する。Amazon等からの購入方法はない模様。
日経IDにログインし、氏名・住所・電話番号、支払い方法（クレジットカード情報）を入力すると購入できる。PDFのダウロードは100回まで可能。

2024-04-01

How long does an old DNS A record live in stub resolver according to TTL?

Network AWS

Question

A cached DNS A record in a full resolver expires after the TTL has elapsed. A timer for TTL starts when the full resolve gets an answer from an authoritative name server.

So, how about stub resolvers? How about a full resolver that gets an answer from an upstream full resolver? If a full resolver returns the TTL value of the authoritative answer, a stub resolver will access an old server after the TTL of the authoritative answer (e.g. server relocation).

Result

Full resolvers return TTL lower than the one in authoritative answer, according to the elapsed time from when the full resolver got an authoritative answer.
Some full resolvers start TTL count irrelevantly to the TTL of the authoritative answer, but it's relatively small (60-300 seconds).

Examples

For example, the TTL of www.tut.ac.jp on ns1.tut.ac.jp (authoritative name server) is 43200.

satob@K690XN:/tmp$ dig www.tut.ac.jp a @ns1.tut.ac.jp

; <<>> DiG 9.16.48-Ubuntu <<>> www.tut.ac.jp a @ns1.tut.ac.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45864
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 945070fcdf30040054d73dfd66097241d24c3e11ae55afa3 (good)
;; QUESTION SECTION:
;www.tut.ac.jp.                 IN      A

;; ANSWER SECTION:
www.tut.ac.jp.          43200   IN      A       52.156.43.168

;; AUTHORITY SECTION:
tut.ac.jp.              43200   IN      NS      dns-x.sinet.ad.jp.
tut.ac.jp.              43200   IN      NS      ns0a.tut.ac.jp.
tut.ac.jp.              43200   IN      NS      ns1.tut.ac.jp.

;; ADDITIONAL SECTION:
ns1.tut.ac.jp.          43200   IN      A       133.15.20.16
ns0a.tut.ac.jp.         43200   IN      A       52.156.46.44

;; Query time: 10 msec
;; SERVER: 133.15.20.16#53(133.15.20.16)
;; WHEN: Sun Mar 31 23:25:05 JST 2024
;; MSG SIZE  rcvd: 184

But when you get an answer from a full resolver, the value of TTL is lower than 43200. (Note that 192.168.233.1 is my full resolver)

satob@K690XN:/tmp$ dig www.tut.ac.jp @192.168.233.1

; <<>> DiG 9.16.48-Ubuntu <<>> www.tut.ac.jp @192.168.233.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22876
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.tut.ac.jp.                 IN      A

;; ANSWER SECTION:
www.tut.ac.jp.          42992   IN      A       52.156.43.168

;; Query time: 0 msec
;; SERVER: 192.168.233.1#53(192.168.233.1)
;; WHEN: Sun Mar 31 23:26:07 JST 2024
;; MSG SIZE  rcvd: 58

Some full resolvers, for example, Google Public DNS (8.8.8.8), start TTL count from a smaller value (half of the original TTL?)

[cloudshell-user@ip-xx-xx-xx-xx ~]$ dig www.tut.ac.jp a @8.8.8.8

; <<>> DiG 9.16.48-RH <<>> www.tut.ac.jp a @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42917
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.tut.ac.jp.                 IN      A

;; ANSWER SECTION:
www.tut.ac.jp.          21600   IN      A       52.156.43.168

;; Query time: 159 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Mar 31 10:22:49 UTC 2024
;; MSG SIZE  rcvd: 58

AWS's full resolver used in CloudShell (10.0.0.2) returns TTL 300 for most of the queries.

[cloudshell-user@ip-xx-xx-xx-xx ~]$ dig www.tut.ac.jp

; <<>> DiG 9.16.48-RH <<>> www.tut.ac.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44459
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.tut.ac.jp.                 IN      A

;; ANSWER SECTION:
www.tut.ac.jp.          300     IN      A       52.156.43.168

;; Query time: 129 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: Sun Mar 31 10:21:22 UTC 2024
;; MSG SIZE  rcvd: 58

Query for some domains served by CDN returns TTL 0. For example, a query for www.ipa.go.jp returns TTL 0.

satob@K690XN:/tmp$ dig www.ipa.go.jp

; <<>> DiG 9.16.48-Ubuntu <<>> www.ipa.go.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19943
;; flags: qr rd ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.ipa.go.jp.                 IN      A

;; ANSWER SECTION:
www.ipa.go.jp.          0       IN      CNAME   d2aiu9f88m0xez.cloudfront.net.
d2aiu9f88m0xez.cloudfront.net. 0 IN     A       13.33.174.6
d2aiu9f88m0xez.cloudfront.net. 0 IN     A       13.33.174.90
d2aiu9f88m0xez.cloudfront.net. 0 IN     A       13.33.174.89
d2aiu9f88m0xez.cloudfront.net. 0 IN     A       13.33.174.31
ns-130.awsdns-16.com.   0       IN      A       205.251.192.130
ns-1012.awsdns-62.net.  0       IN      A       205.251.195.244
ns-1045.awsdns-02.org.  0       IN      A       205.251.196.21
ns-1632.awsdns-12.co.uk. 0      IN      A       205.251.198.96

;; Query time: 0 msec
;; SERVER: 172.30.176.1#53(172.30.176.1)
;; WHEN: Mon Apr 01 00:05:29 JST 2024
;; MSG SIZE  rcvd: 329

In the authoritative server, TTL is set to 60. So it looks like some of the resolvers upstream from me rewrite TTL.

satob@K690XN:/tmp$ dig d2aiu9f88m0xez.cloudfront.net a @ns-1012.awsdns-62.net

; <<>> DiG 9.16.48-Ubuntu <<>> d2aiu9f88m0xez.cloudfront.net a @ns-1012.awsdns-62.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8904
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;d2aiu9f88m0xez.cloudfront.net. IN      A

;; ANSWER SECTION:
d2aiu9f88m0xez.cloudfront.net. 60 IN    A       13.33.174.6
d2aiu9f88m0xez.cloudfront.net. 60 IN    A       13.33.174.90
d2aiu9f88m0xez.cloudfront.net. 60 IN    A       13.33.174.89
d2aiu9f88m0xez.cloudfront.net. 60 IN    A       13.33.174.31

;; AUTHORITY SECTION:
d2aiu9f88m0xez.cloudfront.net. 172800 IN NS     ns-1012.awsdns-62.net.
d2aiu9f88m0xez.cloudfront.net. 172800 IN NS     ns-1045.awsdns-02.org.
d2aiu9f88m0xez.cloudfront.net. 172800 IN NS     ns-130.awsdns-16.com.
d2aiu9f88m0xez.cloudfront.net. 172800 IN NS     ns-1632.awsdns-12.co.uk.

;; Query time: 59 msec
;; SERVER: 205.251.195.244#53(205.251.195.244)
;; WHEN: Mon Apr 01 00:08:22 JST 2024
;; MSG SIZE  rcvd: 260

satob@K690XN:/tmp$ dig d2aiu9f88m0xez.cloudfront.net a @ns-1012.awsdns-62.net

2024-03-20

「おそいひと」主演住田雅清のインタビュー

昔、映画「おそいひと」主演の住田雅清がインタビューで「泥棒もスケベエもいます」みたいなことを言っていたのを覚えていて（関西の人だからか「スケベ」でなく「スケベエ」と言っていたのが印象的だった）、その資料が映画のオフィシャルサイト*1から見つけられなくて探していたんだけど、昔のx51.orgにあったのを見つけた。

https://web.archive.org/web/20120504090201/http://x51.org/x/07/12/2050.php

*1:http://osoihito.jp/top/index.html