なぜ東京都のCOVID-19重症基準は独自基準なのか
これ、よく言われるし大きな問題だと思うけど、そもそもなぜ都はそのように国とは異なる基準で数字を出すのだろうか。都がなにか合理的な説明をしてるのなら聞いてみたい。 https://t.co/ssMHLhXS3h
— 仲俣暁生（thoughts, words and action） (@solar1964) July 29, 2021
確かにこの基準の差は気になりますよね。
その理由ですが、昨年2020年の8月20日に開催された第7回東京都新型コロナウイルス感染症モニタリング会議にて、国立国際医療研究センター国際感染症センター長の大曲貴夫氏と福祉保健局長による説明がありました。
長文ですが、以下の議事録から引用します（PDF）。 https://www.bousai.metro.tokyo.lg.jp/_res/projects/default_project/_page_/001/011/435/7kai/20200820.pdf
なお、会議の資料「重症基準について」は以下のURLでダウンロードできます（PDF）。 https://www.bousai.metro.tokyo.lg.jp/_res/projects/default_project/_page_/001/011/435/7kai/202008207.pdf
【危機管理監】
それでは、第7回東京都新型コロナウイルス感染症モニタリング会議を開始いたします。
《略》
それでは早速ですが、「感染状況・医療提供体制の分析」につきまして、大曲先生からご説明をお願いいたします。
【大曲先生】
国際医療研究センターの大曲と申します。 8月19日時点の感染状況・医療提供体制の分析結果をご報告いたします。
《略》
コメントは以上でありますが、一つ、この時間をいただきまして、モニタリング指標について少し解説をしたいと思います。
モニタリングの指標で医療提供体制を示す中で、重症患者数がございます。こちらについては、モニタリングの過程、モニタリングの指標としてどのように選ばれて、使われているかということを、専門家としてご説明をしておきたいと思います。
東京都においては、重症の病床を戦略的に把握して運用するために、人工呼吸器、体外式心肺補助、ECMOでありますが、その管理下にある患者数、これを重症患者数として、このモニタリング指標として、専門家が見ながら活用をしています。
この数値をあえて選んだのは、理由がございます。
この数値は、実は、使い始めたのは4月頃の話であります。その頃は、思い起こすに、都の全体の医療の状況を見渡す中で、どこに本当に重症の患者さんがいらっしゃるのか、それが何人いらっしゃるのか、その1人当たりにどれぐらいのリソース、具体的に言えば人工呼吸器であり、ECMOでありますけれども、それがどれぐらい都の中で使われているのかということが、なかなか見えにくいと思っておりました。その中で、ちゃんと見える指標をということで探してきたのが、編み出したのが今回の重症患者数であります。
理由でありますけども、病院によって集中治療室、ICUですね、ここにいつ入っていただくのか、あるいはいつ出ていただくのかという基準があるわけですけれども、この基準は、病院の状況によって様々であります。
ただ、病院ごとでICUの入室や退室の基準が異なっていても、人工呼吸管理を行う、あるいはECMOを導入するというのは、医師や病院による判断の差が生じにくいと考えています。そこで、これらは共通の基準で、重症患者数を数えられてトレンドを知ることができると考えております。客観性が高いというところですね。
重症化リスクの高い患者もICUで管理する病院があります。あるいは流行拡大によって、ICUやHCUをコロナの患者さんの専用とする病院もございます。ですので、必ずしもICUに入院した患者さんが、重症患者とは限らないという事例もあります。具体的には、ICUには入っていらっしゃいますけれども、人工呼吸はしていないですとか、ICUが入っているけれども、ECMOは使っていないという患者さんも現実にはおられます。ということで、人工呼吸器の管理を必要としないICU入室患者を含めないことで、何をモニタリングしているか明確になります。
ここは私の補足でありますが、現実の医療の場では、必ずしもICUには入っていないけれども、人工呼吸を受けているという患者さんも現実にはおられますし、そういう方々もやはり我々としては重症と考えていますので、そうした方々は、人工呼吸器なり、あるいはECMOなりが装着されているので、我々東京都のモニタリングの指標としては、重症とカウントしております。
人工呼吸器管理をするということは、人工呼吸器などの資機材、あるいは診療ケアに当たる医師や看護師だけでなく、人工呼吸の呼吸器の管理に当たる臨床工学技士などの人員も必要とします。要は、様々なリソースが必要で、これは医療提供体制の明らかな負担となります。ですので、人工呼吸器管理開始ということは、医療提供体制への負担の大きさの目安として、私たちはわかりやすいと考えています。また、もう一つ大事なのは、患者さんが回復すれば人工呼吸器管理はしなくなるわけです。ですので、人工呼吸器管理の数を数えていけば、患者さんの回復に伴って、資機材や人員等のリソースの再利用についても、把握がしやすいと考えています。
都では、人工呼吸器の管理をいつ始めたのか、それはいつ終わったのか、ECMOをいつから使い始めたのか、ECMOをいつまで使っていたのかという期間を把握しています。その期間を知ることができます。また、人工呼吸器やECMOから外れましたと、そういう報告を受けることで、患者さんが、客観的に見ても明らかに回復傾向となっていることが把握できますという形で、都のモニタリング指標としての重症患者数の把握は行われて参りました。
なお、厚生労働省では、新型コロナウイルス感染症患者の療養状況等に関する調査が行われております。こちらでは、ICU等での管理、人工呼吸器管理又はECMOによる管理が必要な患者さんの数を、重症患者数として報告するよう、厚生労働省より、各都道府県に依頼がなされています。
東京都としては、ICU等での管理状況についても合わせて、厚生労働省に報告することとしていると伺っております。
長くなりましたが、私からの報告は以上でございます。
【危機管理監】
大曲先生ありがとうございました。
以上の重症患者数の考え方についてのコメントを今、先生からいただきましたけれども、それを受ける形で、資料を1枚おめくりください。
「重症基準について」ということで、都の方の考え方を、福祉保健局長からお願いいたします。
【福祉保健局長】
資料をご覧ください。
今、大曲先生の方からご説明があった通り、都では現在、人工呼吸管理又はECMOを使用している患者さんを重症患者さんというふうに位置付けております。
これはですね、4月26日までは、保健所を通じてICU、人工呼吸管理、ECMOの患者さんを聞き取って数を集計しておりましたが、その頃に合わせて、今、大曲先生からあった通り、専門家の先生方から、ICUをカウントすることは実態に即してない部分があるというご意見もいただきました。
また、保健所を通じて情報を取ることが、なかなか正確な数値が取りにくいという面もありましたことから、専門家の意見や、現場の実態を反映しているという基準であるという考え方から、人工呼吸管理またはECMOを使用している患者さんを重症患者という位置付けで、4月27日から開始しているところでございます。
この基準については、今後も変更なしということで、モニタリング指標として引き続き戦略的に活用していく考えでございます。
また、ホームページ等の公開情報についても、この数値を用いることといたします。
理由については今、大曲先生からございましたので、省かせていただきますが、今般厚労省から集中治療室、ICU等での管理が必要な患者についても、含めて報告するよう依頼がございましたので、依頼に基づいた患者数を参考値として提出することといたします。
私からは以上でございます。
【危機管理監】
ありがとうございました。
感想
独自基準の妥当性については特に意見するほどの知見はないのですが、モニタリング会議の議事録が各回公開されているのは大変素晴らしいですね。今後も続けていただければありがたいです。
藤井太洋『ハロー・ワールド』文庫版の解説を書きました＆表題作用語解説（非公式版）
ちょっと間が空いてしまいましたが、先月発売された藤井太洋さんの『ハロー・ワールド』の文庫版に、大変僭越ながら解説（！）を書かせていただきました。
追記：2021年4月14日まで、Kindleで講談社文庫の50%ポイント還元をやっているそうです。
いやー、コンピュータ書関連の書評みたいなやつならともかく、文庫、しかも一般向けの小説の解説を書く機会をいただけるとは思っていませんでした。頑張って書いてはみたものの、果たして本書を読まれる方の参考になっているかどうか心もとない限りですが、貴重な機会をいただけたのはありがたい限りです。 怖くて藤井さんご本人の感想はうかがっていないのですが（直接やりとりしたのは編集者の方だったので。大変お世話になりました）、苦笑していただけたのであれば幸いです。
ちなみに本書ですが、「なんでも屋」タイプのITエンジニアを主人公とした私小説みたいな短編集です。IT寄りの私小説と言うと、作品の傾向を度外視すれば円城塔『プロローグ』を思い出したりしますが、あちらが私小説というのはどうかという程度にはこちらも私小説というのはどうかという感もあるかもしれません。
あ、あと短編「巨象の肩に乗って」はMastodonがそのままの名前で出てくるMastodon小説なので、Mastodon使ってる人はぜひどうぞ。正直この短編についてはいろいろと言いたいことがあるのですが、ネタバレ全開だし解説という感じでもないので、ほとぼりが冷めたら何か書くかもしれません。
という話はさておき。
先述の通り、解説なるものは今まで一度も書いたことがなかったのに加えて、最近書いているようなITエンジニアをターゲットとした文章ではなく、しかもSF読者とかですらなく（藤井さんは一般的にはSF作家と思われているような気がしますが、本書は『ビッグデータ・コネクト』などと同様、基本的にはSFではないのです、たぶん）一般のエンターテインメント系読者を想定していったい何をどういう書けばいいのか……と悩んだ末に、とりあえず作中の用語解説から書いてみたのですが、これがいくら書いても書いても終わらず、表題作の途中までで力尽きました（そして文庫解説用の原稿はゼロから書き直しました）。
ある意味ではこの用語解説の方がよほど「解説」になっているとは思わないでもないとはいえ、質・量ともに文庫に添付される解説にはなりようがありません。さりとて塩漬けにしておくのももったいないので、表題作に関しては最後の方まで追記したものを、こちらで公開してみます。
もっとも、以下をざっと見ていただいただけでも「これがエンタメ小説の用語解説……？」と思う方もいらっしゃるかもしれませんが、この本はこういう小説で、しかもしっかり一般向けのエンターテインメントなのです。そういう意味で興味を持たれた方なら、きっと本書を読んでうなづいたり突っ込んだり唸ったりで楽しめると思います。ぜひどうぞ。
「ハロー・ワールド」用語解説
8ページ
- Tシャツ
特に海外のIT系のイベントではやたらTシャツを配りたがる傾向がある（※個人の見解です）。
- グーグル
会社としては、昔はGoogle Inc.だったが現在はGoogle LLCになっている。 というか持株会社はAlphabetになっていたりXXVI Holdings Inc.になっていたりするので難しい。 日本だと「グーグル合同会社」だったり「グーグルクラウドジャパン合同会社」だったりする。
9ページ
- Hello, World!
本書の説明の通り。もちろん実際にはどんな文言でも構わないのだが、とりあえず手癖のように「Hello, world」と出力させてみたりする。 カンマやエクスクラメーションマークは省略したりしなかったりする。 Wikipediaにもそこそこ詳しい解説がある。
- これを表示するところからソフトウェア開発は始まる
表示端末がある場合はそれでよいが、例えば組込みソフトウェアの場合、そもそも画面出力もなければ通信もできない場合もあるので、ハロー・ワールドの代わりにLEDを点滅させるところから始める場合も多いらしい。これは「Lチカ」と呼ばれており、LEDをチカチカ点滅させることを指す。
- C言語の初めての教科書
「The C Programming Launguage」、通称K&R。現在は第2版が流通している。 日本でも200刷を超える大ベストセラーとなっているが、さすがにちょっと書き方が古いという批判もある。
- LISPのようにマイナーな開発言語
そそそんなにマイナーじゃないですよ！！！１と弁護したくなるひとは単なる言語おたくの可能性も高い。 とはいえLispと言えば歴史と伝統を誇る超有名な言語であり、今でもその流れを組む言語（ここではSchemeやClojureを念頭に置いています）もある。
ちなみに郭瀬のように「放っておけば……説明しかねない」タイプは筆者の周りにも多いというか、正直なところ他人のことは言えないのはこの文書を書いている時点でお察しの通りである。
10ページ
アップルの開発者向けイベント。Steve Jobsが日本時間の夜中にプレゼンしていたのが有名だが、あれはメディアや一般人向けの発表で、開発者にとってはその後のテクニカルな発表が本番だそう。 2020年はさすがにオンラインでの開催となった。
- サンフランシスコのホテルは高い
そのため参加者はAirBnBを使ったりするそうだが、それでもWWDCの期間は大変高いとのこと。
11ページ
- 学者臭いコード
ちょっと言い過ぎ感もあるけど、まあそういうのもある気がする。学者というか研究者は検証してベンチマークをとったり、とりあえず使い捨てのコードを書くことが多そうなので、業務アプリケーションのコードとは異なるのは納得感がある。
- 西新宿でランチ
西新宿にはなぜかカレー屋が多い。
12ページ
- Macbook Proの十五インチモデル
若干重いけれども画面の大きさには代えられないので頑張って持ち歩く人も多い。 なお筆者は体力がないのでMacbook Air派だったが、本書解説を書いている時点でいきなり壊れた（！）ので13インチMacbook Proの薄いやつに乗り換えた。
- エッジ
「エッジ」と言えば堀江貴文氏が創業した会社「オン・ザ・エッヂ」が「ライブドア」になる前に一瞬「エッジ株式会社」という名前になっていたのを思い出すが、年代も雰囲気も違うので関係なさそうである。
- 五反田のIT企業
家賃が高すぎる渋谷を嫌った企業が五反田に集まっているらしい。
13ページ
- Swift
Appleの開発している、比較的新しいプログラミング言語。 iOS開発といえば、少し前まではObjective-CというCの流れを汲むオブジェクト指向プログラミング言語が使われていたが、現在ではSwiftに置き換わりつつある。
Webブラウザ用言語として今はなきNetscape Communications社が開発したもので、現在では各種ブラウザは元よりWebサーバー等でも動作する。 初心者でも比較的簡単に書けるようになっているが、プロの書くJavaScriptは別世界の言語とも言えるくらい似ても似つかないものであり、かつては「世界で最も誤解されたプログラミング言語」という異名も持っていたほどである。
スティーブ・ジョブズがNeXT社で開発したOSであるNeXTSTEPの開発環境の流れを汲む、それなりに歴史の長い開発環境ソフトウェア。 macOSとiOS開発には欠かせない。
- もしそのアプリを育てるつもりがあるなら
ソフトウェアに対して「育てる」という用語（メタファー）は一部の界隈ではよく使われる。 もちろん、ふつうのアプリは生物のように勝手に育つわけではないのだが、手間暇がかかること、環境にも影響されること、設計工程と製造工程に分かれるのではなく少しずつ追加・改修していくことなどの意味を込めて「育てる」と呼んでいる。
14ページ
汪がノートPCではなくiPadを持っているのは、もりもり開発をする役割（ロール）ではないことを示唆している。
16ページ
- 「コーヒー、置いていいですか？」
iPadはともかく15インチMBPはわりとでかかったので、それを2台並べた机にコーヒーを置くのはちょっと気を使いそうではある。
- CAD
元は「Computer-Aided Design」の略であり、「コンピュータ支援設計」という意味になるはずだが、一般的には設計支援のためのソフトウェアのことを指す。 最近だと3Dプリンター用のデータを作ったり、VR用の人やモノのデータを制作したりするのにも欠かせない。
17ページ
- 人差し指だけで打鍵するプログラマーもいるほどだ
素人っぽくも見えるかもしれないが、こういうタイプのひとの一部は異常な速度で人差し指キー入力をしたりするので侮れない。
- ベンチャー企業とは異なる安定した働きぶり
CADの会社は比較的安定していて、そんなにガツガツしてない印象があるが、実際のところはよくわからない。
18ページ
- グーグルアースを立ち上げた
Google製のネット地球儀、のようなサービス。 Googleマップの写真モードと混同しがちだけれどちょっと違う。少なくともPCアプリ版はGoogleマップには存在しない(2020年10月現在)ので、「グーグルマップを立ち上げた」という表現は難しい。
- アメリカの都市部に住んでいれば
アメリカの通信回線はあまり良くなかったと言われている。
- データ通信が定額料金でない東南アジア
日本でも公衆Wifiや光回線は定額だけれど、スマートフォン等は定額料金ではないので状況は近そう。 俗に言う「ギガが減る」という現象である。
- 広告に含まれる識別コード〈Cookie〉
広告配信サービスではその閲覧情報を記録（トラッキング）するためcookie内にIDを生成し、ブラウザから送信させるようにすることがある。最近ではサードパーティーcookieを忌避する動きがあるため、cookie以外の方法でトラッキングする方法が提唱され揉めている。一方でそのようなトラッキングからユーザーを守るブラウザ拡張やアプリもあり、いたちごっこが現在でも続いている。
- Webに広告がなかった頃のインターネット
Web広告については、1994年にhotwired.comが掲載したバナーが最初と言われている。
日本では1996年、「Yahoo! JAPAN」のバナー広告がはじまりとのこと。
- 自由なWebが広告に汚染されていく
広告があること自体は自由なWebを阻害するものではないが、広告収入を期待し始めると広告のポリシーにそぐわない（アダルト等）コンテンツの掲載をやめたり、コンテンツの内容も広告に最適化し始めたりするため「自由」が減らされることが危惧されている。
- インターネットの自由を信じる原理主義者
「原理主義者」かどうかはさておき、例えば電子フロンティア財団(EFF)は実際に広告ブロッカーを開発したりしている。
19ページ
- 専門を持たない何でも屋
ネットには「稀によくいる」タイプ。 ネットでは様々な専門技術があり、専門家ほど詳しくなくても多少なりとも知っているだけで作業が捗ることが多々あるので、実際重宝されがちという面もある。
- ソフト開発の部門にいる人間にしては口も回る
もちろんふつうに社交的な人もいるが、ソフト開発部門の人は普通の意味での社交性はあまり評価されないので、無口な人、自分に興味のあることしか話さない人でも排斥されず居心地が悪くない傾向はありそうである。
20ページ
- Swiftを十分に活用しているからだ
ここで想定している広告ブロッカーは、おそらくWebKitを使った専用ブラウザとして配布するか、ブラウザのプラグイン的な形で動くのではないかと推測される。
*「Swiftは難しくないぜ」
JavaScriptも特に最近は簡単ではなさそうだが、この書き方だと現代風の複雑なbuildプロセスを使うJavaScriptの書き方ではなく、ベタ書きでできるJavaScriptを使っているように見える。それと比べるとSwiftは難しいかもしれない。
- 20以上のプログラミング言語を苦もなく使いこなす
プログラミング言語はある程度似通った言語が多いため、20言語をマスターするために1言語マスターする20倍の労力が必要、というわけではない。いろんな分野のコードを書くのが得意・好きな人はそれに近いくらいなんとなくマスターしていてもおかしくはない。
22ページ
- 中国は金盾という国民のネット利用を監視して内外の通信を分断している。
英語では「great firewall」とも呼ばれるが、「firewall』自体は一般的な技術である。ただし、それは企業内や特定拠点などで外部との通信を制御・遮断するためのものであり、国家で行っているところは多くない……と言いたいところだが、実際には国家によるブロッキングはさまざまな形で行われている。日本でも一般社団法人インターネットコンテンツセーフティ協会が提供する「児童ポルノ掲載アドレスリスト」を各インターネット・サービス・プロバイダ（ISP）がブロックする、という形で行われている。
23ページ
- オーストラリアのすぐ北に浮かぶ島
本書で後述される通り、ニューギニア島。
24ページ
- 三人がかりで半年かけて、百万円にもならない
確かにこの売上で独立してメインの仕事にするのはちょっと厳しい。 というか単行本版では200万円だったのに文庫版では半減していてちょっとびっくりした。
25ページ
- Slack
同種のチャットサービスとして、最近は企業ではTeams、企業以外ではDiscordも使われているが、やはりSlackの人気も根強い。
26ページ
- A/Bテスト
実際のコンテンツとユーザーを使って行うテスト。具体的には本書の説明の通り。 ネット上でのマーケティングでは一般的なもので、そのための機能やツールも多い。
- marketing_framework.dylib
dylibという拡張子はmacOSやiOS用の（動的リンクできる）ライブラリに使われているもの。何かしらの便利なフレームワークのライブラリを使っていることが分かる。
27ページ
- 画像はスマートフォンで二行ほどの小さなもので、閲覧の邪魔にはならない。
とは言うものの、あまり画面が大きくない端末では気になることは気になるし、誤ってタップしてしまうとストレスになるので、嫌っている人も一定数いる。もっとも、だからといってたった数百円でもお金を払って有料版を買う人は多くないのも現実であり、世の中は厳しい。
- こいつでプログラムも書きますよ
実際にそういう人もいる。すごすぎる。 もう少し穏当なタイプでは、Bluetoothでキーボードを使うという話も聞く。
29ページ
- 離脱率
マーケティングの人は「チャーンレート」と言うことが多そうなイメージがある。
30ページ
インターネット上での「アドレス＝住所」を示す数値。元々はIPv4という仕様が使われていたが、最近はIPv6という新しい仕様も少しずつ使われる機会が増えつつある。
アドレス数は、ざっくりとした上限はIPv4では32ビット=4バイト=約43億個になる。これがIPv6では10の38乗個まで増える。
いつ・どこからアクセスがあったのかを記録するデータ。このような時系列の記録データのことを一般的に「ログ」と呼ぶ。
最近は個人情報の扱いについて厳しくなったため、アクセスログの扱いも何かとセンシティブではある。 また、以前はアクセスログを単なるテキストファイルとして保存していたが、クラウド・コンテナ等の利用により、生のアクセスログは直接扱わないことも多い。
- IPアドレスが偏ってる
IPアドレスは（大まかには）地理ごとに使われるアドレスが決まっているため、どこからアクセスされるかがわかることもある。
31ページ
- ドットで区切られた三桁の数字の羅列
IPv4の4バイトのIPアドレスは、「192.168.1.2」というように各バイトを「.」で区切って表現することが多い。1バイトは0から255までなので、「3桁の数字」となる。
- 無料のフリースポットごしに使う人が多いからこそ有効な方法だ
IPアドレスは必ずしも地理的な場所と紐ついているわけではないため、IPアドレスがわかっても場所が分からないこともありうるが、「無料のフリースポット」では地理的な場所とIPアドレスが対応している、という想定を示している。
32ページ
- Tor
接続経路を匿名化するためのソフトウェア（元々はそのための規格のことを指していたらしい）。 アンダーグラウンドなネットワークを作るのにも利用される。
実際のネットワークの上に、仮想的なネットワークを作ることができ、それをVPNと呼ぶ。 ここでは、Torの通信を使ってその上にVPNを作ることを想定している。
33ページ
- 無料無線スポットに侵入して、そのコンピューターを踏み台に
ここでは無線スポットにそれを管理・制御するコンピューターがある想定で、そのコンピューターに（勝手に）侵入し、そこに（iPhoneのブラウザーに偽装した）Macbookのブラウザーをつなぐような形と思われる。
34ページ
- 広告なんかにカメラを乗っ取らせるわけがない
アップルのSafariはGoogle Chromeなどと比べ、ブラウザのセキュリティにはうるさく、ブラウザと外部との連携は制限を緩めたがらない（※個人の見解です）。ましてや第三者の広告から操作できたとなると大問題になりかねない。
35ページ
「スクリプト」とはプログラムのこと。ここではブラウザー上でのJavaScriptを指している。
- 〈金盾〉みたいなものがあればインターネットの経路を汚染して、偽のアップデーターを食わせることも可能だ
通信の中身を傍受して、アップデーターへのアクセスだと判断すれば、実際のアップデーターにはアクセスにいかず（あるいはアクセスしても返ってきたデータは捨てて）偽のアップデーターのファイルを返すように差し替えることで、ここで言っていることは実現可能となる。実装はそれなりに大変そう。
36ページ
コンピューター（特にソフトウェア）の欠陥。脆弱性とも言う。
- セキュリティアップデートがすぐ行われる
iOSやAndroidでは、OSや基本アプリケーションのアップデートが不定期で行われるが、そのうちセキュリティの修正を含む場合「セキュリティアップデート」などと呼ばれたりする。
38ページ
- JavaScriptには荷が重い
SwiftはiOS上で動くアプリケーションのための言語だが、JavaScriptは通常はWebブラウザーの中で動作する言語であり、動作速度に差があることに加えて、ブラウザーの制限も受けるため、Swiftの方が融通が効く、ということを言わんとしている。
39ページ
- 政府広報の広告プログラムで使われている命令を上書き（オーバーライド）して
元からある関数・メソッド等を実行しようとしたときに、別の関数を実行するように書き換えることができる。それを「上書き」と呼んでいる。
- サーバーはアマゾンで借りた
おそらくAWS（Amazon Web Service）のEC2という仮想サーバーのインスタンスを新しく建てた、と思われる（意表をついてLightsailの可能性もあるけど。最近であればAWS Lambdaを使っていたところかもしれない）。別にAmazonにあるサーバーのハードウェアを一個借りる、というわけではない。
- 画像サーバーのスクリプトが動作しておくようにする
詳細は不明だが、転送された画像データを保存するようなスクリプトと思われる。
- 上限は200台
クラウドでは誤って数千・数万のインスタンスを立ち上げてしまう可能性もある。そのようなことを防ぐため、あらかじめ上限を設定できたりする。 とはいえ、AWSでは通常はもっと厳しい上限が設定されているはずなので、すでに上限緩和の申請は適用済みかと思われる。
48ページ
京王線（京王高尾線）の終着駅。明大前からでは準特急でも50分近くかかる。
52ページ
- アップルから追放（バン）される。二度とアプリを作れなくなるぞ。
例えばWindowsやLinuxなどであれば、自作アプリを第三者の端末にインストールすることは容易だが、iOSは通常AppStore経由でしか配布できず、TestFlightという試作版アプリの配布すら制限がある。そのため、たとえアプリを作り、自分の端末では動かせたとしても、他人には一切配布できなくなる、と懸念している。
- 作者:藤井 太洋
- 発売日: 2021/03/12
- メディア: 文庫
翔泳社セール対象商品(PDF)のうち定番ぽいタイトル11冊
翔泳社さんのセールが8/20までだそうなのですが、某所に書いた「定番ぽいやつ（紙で買ってるけどPDFもついでに買っておくと良いかも的な）リスト」をこちらにもかんたんな説明をつけて書いておきます。
なお、この「定番ぽい」というのは、何年も前から良い本として広くおすすめされてきた本や、これから末永くおすすめされそうな本、ということです。一般に書籍の評価は、賞味期限の長短やターゲットの広さ・狭さとは異なるので、別に広くおすすめされない本でもいい本はありますし、将来はさておき今なら必読、という本もあるわけです。が、それらを並べはじめるときりがないので、ここではそういった本はここでは触れません。
そういう縛りがなければ、例えばカイゼン・ジャーニーシリーズ（という言い方でいいのかな？）やルビィのぼうけんシリーズや技術者の数学書シリーズとかもあるわけで、各自探してみるとよいかと思います。
一方、もっとニッチな内容の本が読みたいとか、最新の情報が欲しいとかいう方のために「技術書典」というイベントがあります。突然ここから宣伝になるのですが、次回技術書典9は来月9月にオンラインにて開催予定で、ただいまサークル参加者を絶賛募集中です。読むだけじゃなくて何か書いてみたい！ という方がいればぜひご応募ください。
さらに技術書典ではスポンサーも絶賛募集中なので、興味があるとか持続化給付金が余ってるという方がいらっしゃればぜひお声がけください。宣伝は以上です。
※ COI開示: 翔泳社さんとは業務での取引がありますが、本件については金銭物品その他のやりとりはありません。
レガシーコード改善ガイド
いかにも定番ですね。自動テストが当たり前とは言えなかった時代に「レガシーコードとはテストのないコードである」と喝破した本です。
とはいえ、別に本書が想定する現場としてはテストが当たり前にあるわけではありません。あくまで「レガシーコード」を改善する本なわけで、状況としてはテストがないところから始まるのです。テストがない、あるいは足りてない、と思うあなたのための本なので、安心して読んでいただけるかと思います（当たり前のようにテストがある開発しかしてない人も、いつかテストのないコードと戦わなければいけなくなった日に備えるべく読んでおくとよいでしょう）。
それでも躊躇してしまう人には「第24章 もうウンザリです。何も改善できません」だけでも読んでいただきたいです。直球ど真ん中すぎる章タイトルですが、ひどい状況であっても著者は投げ出したりTwitterで愚痴ったり転職を煽ったりせず、それでもできるコード改善方法を挙げてくれます。いやまあ投げ出すべき状況もあるかとは思いますが、そうしないで頑張ってみるあなたを応援してくれる本です。
エンタープライズアプリケーションアーキテクチャパターン
PoEAA、あるいはPofEAAと呼ばれる本です。エンタープライズと名前がついてますが、エンタープライズはあまり関係なく、主にサーバとクライアントに分かれる環境では一般的なアプリケーションのアーキテクチャパターンが網羅されている本です。
だいぶ前の本ですし、最近はあまり直接的に言及されることは少なくなった気もするのですが、つい油断すると本書のパターンの名前が一般会話で出てきて困ってしまうこともあるかもしれません（トランザクションスクリプトとかサービスレイヤーとか）。特に後述するDDDとかを読むにあたって、本書を読んでないと理解するのは相当大変だと思います。
翻訳は正直微妙というか、私の持ってる紙の本にもちらほら手書きで修正している跡が残っているのですが、そこは目をつぶって頑張って読んでいただきたいです。そんなことで頑張りたくない…という方は原著を読むという選択肢もあります（セール関係なくてすみません）。
エリック・エヴァンスのドメイン駆動設計 ソフトウェアの核心にある複雑さに立ち向かう
DDD本です。現在では定番中の定番といってよいでしょう。
ドメイン駆動設計については、なんとなく実装パターン的な扱いをされることも少なくなさそうですが、基本的にはドメインモデルをどう作る（＝モデリングする）か、そしてそれを崩さずにソフトウェアアーキテクチャと対応させるか、という手法だと理解しています。「ドメイン駆動設計」であって「ドメイン駆動開発」ではないのは、偶然ではなく意図的なものだと思ってます。
そのドメイン駆動設計を理解するためには、なにはともあれ本書を読まれると良いかと思います。
実践ドメイン駆動設計
IDDD本、でいいんでしたっけ。DDD本を実践してみる、というタイトルそのままの本です。
設計手法といっても開発に落とし込まないといけないのですが、ドメインモデリングの戦略的設計よりも戦術的設計の設計パターンばかりが知られることによって結局単なる設計・実装手法になっているのでは…？ という問題意識と、DDD本刊行から10年たって時代の変化を反映させたいというところから書かれた本だと理解しています。
実は本書はちゃんと読んでなくて（Javaはほとんど使わないので…）、いくつか実装の参考にした程度なのですが、DDD本だけではよく分からない・ピンとこないという方は本書も合わせて読むといいんではないかと思います。
プログラマのためのSQL 第4版 すべてを知り尽くしたいあなたに
SQLとSQLプログラミングを、DBA(DB管理者)視点ではなくプログラマ観点から理解する本です。
個人的にお世話になった本の最新版ということであげておきますが、今なら他にも良い本がありそうではあります。が、安心して読める本が継続して出版（そして翻訳）されることは大変ありがたいことなので挙げておきます。
詳解UNIXプログラミング［第3版］
Unixプログラミングの定番書です。
Unixでシステムコールを叩くプログラムを書く場合や、Unixで動くアプリケーションの運用をする場合には絶対に読んでおくとよい、と言われていた本です。困ったときに本書を読むとちゃんと載っているので読んでおけと言われ、本当かなと思いつつ読んでみたら本当に載っててびっくり、という経験をした人は少なくないのではないでしょうか。
Unixと関わる限り、いざという時のために手元においておきたい本です。
ユースケース駆動開発実践ガイド
この文章を書きながら本書があることに気づきました。ICONIXという開発方法論の本です（手元の本が見つからないので記憶で書いてます）。
開発方法論は現在は受難の時代というか、よい入門書とかも少ないんですよね…。みんなどうやって入門しているんでしょうか。 本書は数少ない生き残りの本なのですが、ICONIXは開発プロセスの中では比較的とっつきやすい（主観です）からかもしれません（たまたま偶然かもしれません）。 いきなりDDDとかでモデリングやるよりは、いったんICONIXとかを試してみてからの方が分かりやすいんではないかと思います。
そういう意味で貴重な本なので、クラス設計（関数寄りだと型設計になるんでしょうか？）とかの良し悪しがわからない、という人はぜひ読んでみるといいかと思います。
組織パターン チームの成長によりアジャイルソフトウェア開発の変革を促す
デザインパターン的なパターン言語を組織やプロジェクトマネジメントにも応用してみた、という本です。
ソフトウェアのパターンじゃないパターン言語はなかなか難しいものが多いような気がするのです（主観です）が、本書はその中でも上手くいっている方ではないかと思います。基本として読んでおくとよいかと思います。
モダン・ソフトウェアエンジニアリング
これは新しい本ですね。あらゆる開発方法論を大統一するEssenceを紹介する本です。
まー、正直言ってEssenceは大変ビミョウというか、記述用言語としてなら開発方法論マニア（？）には便利かもしれないけど現場の役に立つかどうかは怪しいところではあるかなあ…というのが率直な感想です。が、せっかくのIvar Jacobson先生最新の集大成っぽい本ですし、「開発方法論、そしてソフトウェア開発とは何なのか」をメタな視点から見てみるのは、そういう機会がない人には一度はやってみた方がよいかとは思います。そういう意味では読んでみる価値はあります。
イノベーションのジレンマ 増補改訂版
これはソフトウェア開発のみならず、ビジネス書としても大定番ですね。ハードディスク業界の例が出てくるのでソフトウェア開発者の方にも親近感が湧きそう…と思ったけど今どきのソフトウェア開発者はハードディスクとか知らなかったりするんでしょうか…どうなんだろう…というのは置いておいて。
この本のミソは、市谷さん風にいうと「正しいものを正しく作る」にも関わらず失敗する（ことがある）、そしてそれには理由がある（！）、というところですね。事業が失敗していく原因を、作り方が間違えていたとか、作るものが間違えていた（顧客の要望を聞かなかった・答えなかった）ということだと考えられていたところに、そうではないという見解をケーススタディと合わせて紹介したところに価値があると言われています。が、素朴に読んでも面白いので、ビジネス書にも興味ある人は読んでみるといいかと思います。
CODE VERSION 2.0
こちらもソフトウェア開発の本ではないですが、ネット黎明期に「自由」と「規制」の関係（規制がなければ自由も死ぬし、規制しすぎても死ぬ、ではどうすればよいのか）を記して評判となった本です。
登場当初からはネットも進化し、そして規制も進化しているのですが、今の方がより両者の関係は深く、そして難しくなっているといえます。その意味では牧歌的なところもあるかもしれませんが、その重要性は高まっているとも言えるでしょう。
以上、ざっと挙げてみましたが、とりこぼし等あるかと思うので、気になる方は他の本も探してみるとよいかと思います。参考になれば幸いです。
技術系イベントにおけるアンチハラスメントポリシーの効果について
技術に関するカンファレンス等のイベントで使われるアンチハラスメントポリシーとは、技術系イベントなどでハラスメントに反対するというポリシーを明示するしくみで、最近では様々なカンファレンスで同様のポリシーが適用されています。私が運営に関わっているRubyKaigiというイベントもその一つです（ちなみにRubyKaigiでは2020年1月14日まで発表者募集中で、また現在スポンサーも募集中です）し、同じく運営に関わっている技術書典というイベントでも導入されています（ちなみに技術書典8サークル当選者の入金は12/22(日)本日締め切りなので、まだの方は今すぐ対応願います。そして技術書典8でもスポンサーを募集中です）。
とはいえ、アンチハラスメントポリシーは必ずしも正しく理解されているわけではないかもしれません。 まあ、正しいかどうかを私が判断するのは適切ではないかもしれませんが、私から見るとこれはちょっと理解されていないのでは、という発言も見かけます。
そのため、アンチハラスメントポリシーを実際に適用しているイベントの関係者として、私のアンチハラスメントポリシーの理解の一端を書いておきます。
アンチハラスメントポリシーを掲げることによって得られる効果
「アンチハラスメントポリシーを掲げれば参加者はハラスメントしないようになる（はず）」、と思われる方もいるかもしれませんが、それは正直誤解というか、過信と言ってよいでしょう。 なぜなら、ハラスメントは本人が意識していなくても行ってしまうものであり、そして意識していないのであればそれを封じるポリシーが提示されていても、言動が変わることが期待できないためです。
それでは、なぜ多くのイベントでアンチハラスメントポリシーが掲げられるのでしょうか。それには様々な理由があります。
ハラスメント遭遇時の報告先を明示できる
ハラスメントに遭遇した者が、ハラスメントがあったので何とかしたい、という場合、まず報告先をどこ・誰にすればよいかを考えるはずです。 ところが、ポリシーがない場合、どこに報告するのが正しいのかは自明ではありません。
とりあえずスタッフに言えばいいのかと思いつつ、そもそも誰がスタッフなのかも分からない場合もあります（イベントでは、スタッフでもないのにスタッフのように仕切ろうとされる参加者の方もたまにいらっしゃいます）。 そもそもハラスメントの報告は、あまり気軽に行えるものではなく、良く分からない人に伝えるのに不安な場合もあるでしょう。
アンチハラスメントポリシーには、多くの場合ハラスメントの報告先が明示されます。スタッフに伝える場合にも、スタッフの特徴（名札、Tシャツ、腕章等）が明記されます。 それによって、正しい報告先がわかります。
さらに、スタッフと思われる人がハラスメント的な言動をしていた、というケースもありえます。その場合、とりあえず問い合わせ先に投げるとしても、普通の問い合わせ先に投げるとその人にも直接伝わるのでは（そして報告者が特定されてしまうのでは）、という恐れがあります。
アンチハラスメントポリシーに特別の連絡先を用意する場合、スタッフの中でも少数の人のみに連絡し、報告者の秘密を守ろうとすることが可能です（それが期待されます）。 さらに慎重な場合には、匿名の報告を受け付ける窓口が別途用意されている場合もあります。
このようにして、ハラスメントの報告先を示すことで、問題があった場合、あるいは問題かどうか判断つかないけれど報告したい場合に、その適切な報告先を参加者全員に伝えることができます。
「ハラスメントに遭遇した」という「報告」を積極的に求めていることを明示できる
先ほどの項目以前の大前提として、そもそもハラスメントを受けた、あるいはハラスメントを見かけたことを通知することが適切な行為として認められており、そのことを参加者とも共有する必要があります。
ハラスメントの問題をより深刻にする、二次的被害をもたらすものとして、「ハラスメントを軽視する」ということがあります。
具体的に言うと、ハラスメントを受けたと報告があった時に、報告された側の人が「そんなの大したことじゃないですよ」とか「それくらいのことならよくあるし、気にすることじゃないのでは」といったような言葉を返したり、そう思わせるような言動をすることがあります。これがハラスメントの軽視です。
（なぜ軽視なのか念の為説明しておくと、ハラスメントが大したことか、気にすることかどうかを判断するのは報告を受けた者ではなく、ハラスメントを受けたその人であるべきだからです。もちろん、よくあることかどうかもハラスメントを受けた人にとってはどうでもいいことです。「私が」「今」「ここで」ハラスメントを受けたことが問題だからです。さらに念の為説明すると、ハラスメントの問題やその報告を重要視することと、そのハラスメントをはたらいた人に対して重い処分を下すかどうかは、直接関係しているわけではありませんし、処分を約束するものでもありません。）
ハラスメントの報告は、基本的にハッピーなものではありません。それは報告を受ける者にとってもそうですが、報告する人にとっても同様です。 何も好き好んで報告したいのではなく、報告することが今後の改善につながると期待して報告する場合が多いはずです。誰も報告しなければ、自浄作用も期待できないからです。
しかし、それをためらわさせる要素があると、報告も期待できません。報告はあくまで報告者の「善意」によるものでしかないためです。
また、報告者自身ですら自分の受けたハラスメントを軽視している場合もあります。残念ながら当たり前のように日々ハラスメント的な言動が行われている場も世の中にはあるようで、そのような経験を重ねた場合、主催者としては重視しているような言動ですら報告を遠慮してしまうかもしれません。しかも、ハラスメントの対応にはそれなりにコストがかかることは事実です。そのような背景を推測してしまうことにより、ハラスメントに遭遇しても、報告をためらってしまう危険性があります。これはハラスメントを防ぎたい主催者の意に反することです。
アンチハラスメントポリシーを提示することにより、その報告者の行為を無碍にせず、主催者としてはコストがかかろうが適切に対処したいと考えていることを明示することができます。
全スタッフにハラスメントを防ぐための権限を与えることができる
アンチハラスメントポリシーは、一般の参加者だけではなく、スタッフへのメッセージにもなります。
多くのイベントでは、スタッフ経験も豊富で、長い時間をかけて深く関わっているスタッフだけではなく、当日のみイベントのお手伝いを行うために参加するスタッフの方もいます。 とはいえ、参加者からみたら当日のみのスタッフもスタッフです。
イベントの発表中にハラスメントと思われる言動が含まれることはあります（実際にありました）。 そのような発表は、場合によっては即座に中止したり、そこまでいかなくても発表中・発表直後にお詫びをお伝えする必要もあるかもしれません。 これは、控えめに言って、発表の場を壊してしまうことになりかねません。
運営チームの代表者であればそのような強い措置の判断もできるはずですが、そうではないスタッフしかその場にいない場合、そんなことをやっていいのか…と躊躇ってしまう可能性は高いです。 そして代表者に情報が伝わり、その場に来たときにはすでに発表も終わっているかもしれません。
そのような状況でも、アンチハラスメントポリシーがあれば発表も中断させることも可能にする、とても強い権限をその場にいるスタッフに与えることの後ろ盾になります。 少なくとも、何もないよりは判断の助けになるでしょう。 もちろん、そのことも含めて、スタッフにはその権限の使用についてしっかりと情報共有し、理解を徹底する必要はありますし、相当頑張っても実際に現場で振る舞えるかどうかは未知数ではあります。そこは本当に難しいところなのですが、上手く運用したいところです。
まとめ
アンチハラスメントポリシーは、掲げることでハラスメントを排除できる、便利な御札ではありません。 このポリシーは、ハラスメントをなくそう、少なくとも減らしたい・見逃さない、という主催者側の意志を伝え、ハラスメントを受けるかもしれないなら参加したくない、という方にも参加してもらい、一緒にハラスメントをなくしていくためのツールの一つです。
もっとも、イベントの主催は簡単なことではありません。アンチハラスメントポリシーがあろうがなかろうが、主催者の苦労は少なからずあります。 正直ハラスメント対応まで気が回らない、想定できない、現実的にコストが割けない、などということもあるかと思います。 ハラスメント対応ができないのであればあらゆる規模のイベントを開催するべきではない、というのも現状では非現実的もしれません（将来的には違ってくるかもしれません）。
実際、比較的小さなコミュニティのイベントでは、ポリシーを明示せずともハラスメントを未然に防いだり、ハラスメントがあってもその対応をうまくハンドリングできることもあります。 しかし、様々な背景を持った、多くの参加者が見込まれるイベントでは、最低限の振る舞いのルールも共有されていない可能性が高いです。
そこで、困難を引き受けてでも、アンチハラスメントポリシーを掲げて、ハラスメントの防止に努めることを宣言し実施することには大きな意義・効果があります。 今後とも、より良いイベントが開催され、技術コミュニティが活発化されることを期待しつつ、イベントを開催される方・イベントに参加される方を応援したいと思っています。頑張っていきましょう。
蛇足
なお、ここに書いたことは、運営視点からのプラクティカルな効果についてであり、ポリシーを提示する本当の理由は「参加者の技術的な興味・関心と参加者自身を大切にし尊重するため」「人権を損なわないため」です。が、それについて書き出すとさらに長い話になるのでここでは省略しました。
開発者向けopenBD関連リンク集
公式
2017/01/23 セミナー資料
GitHub Organization
https://github.com/OpenBD は別物なのに注意
ライブラリ・ツール・アプリ in GitHub
Go
github.com openBD APIライブラリ (Go)
github.com ISBNで書誌情報を取得するツール (Go)
JavaScript
github.com 書誌情報表示サンプル (JavaScript)
github.com 新刊情報アプリ (JavaScript)
openBDの全データを整形しつつ単一ファイルにダウンロード · GitHub 全件取得スクリプト (JavaScript)
Ruby
Crawl all data using openBD API · GitHub 全件取得ダウンローダ (Ruby(Rails))
github.com openBD APIライブラリ (Ruby)
github.com openBD APIライブラリ (Ruby)
github.com openBDの登録データ取得 (Ruby)
Python
github.com 全件取得用ダウンローダ (Python)
PHP
github.com ISBNから書誌情報を表示するサンプル (PHP)
github.com 出版社記号を使って特定出版社の書籍データを抽出するサンプル (PHP)
hontoの書籍ページにISBNでリンクする
hontoの書籍ページは独自IDが振られているので、直接リンクできない。
例えば以下のようなURLになっている。
https://honto.jp/netstore/pd-book_28169493.html
これとは別に、ISBNを指定する方法がある。
http://honto.jp/redirect.html?bookno=(ISBN)という形だが、ここでのISBNは13桁ではなく、末尾のチェックデジットを落とした12桁になるのがポイント。
http://honto.jp/redirect.html?bookno= 9784822239176 ではダメ。
http://honto.jp/redirect.html?bookno= 978482223917 だとうまくいく（冒頭のURLにリダイレクトされる）。
もうちょっと何とかならなかったのか…という仕様としか言いようがない。
