データ解析 〈2020年インフルエンザ流行終息！新型コロナはいつ？〉

新型コロナウィルスに関心が集中する一方で、インフルエンザの流行は終息しようとしています。年明け以降、患者数が急激に減少しシーズントータルで例年の半分程度となりそうです。およそ500万人がインフルエンザに罹らず済む見込みです。日本におけるインフルエンザ発症者の死亡率は約1万分の１なので500人の命が救われたに等しいことです。

こちらの患者数推移のグラフをご覧ください。東京都感染症情報センター インフルエンザの流行状況
今シーズンは例年より早く11月頃からインフルエンザの流行が始まりました。しかも、2009年に大流行した新型インフルエンザ AH1N1pdm09 の再流行で、患者数も急激に増加しました。
年末までは感染拡大が心配されていたのですが、年明け以降は急速に患者数が減少したのです。今シーズンの患者数推移が特異であることは、過去の推移との比較でも良くわかるかと思います。
一方、北米では2月時点で2600万人以上が罹患という状況です。AH1N1pdm09の怖さを物語るものです。ではなぜ日本で感染を抑え込むことができたのでしょう？コロナを契機とした予防対策でしょうか？人混みを避けることはインフルエンザに対する確実な予防策です。でもそれだけでしょうか？

暖冬傾向にあったことにも理由を求めることができるかもしれません。空気の乾燥は上気道粘膜を乾燥させ、ウィルス感染の初期フェーズ “細胞への吸着” の可能性を高めます。低温は体力を奪い、感染から発症までの可能性を高めます。

東京のコロナウィルス患者数が人口比で少ないことは気象条件が感染を左右していることを表しているのかもしれません。そうならばこの先の見通しを立てることもできます。もっとも患者が疎らな状況で結論を導くことは難しいです。3月初め現在の都道府県別患者数で、検定にかけられるような無作為抽出性を主張できそうにはありません。報道されているように偶発的な事象が患者発生の原因になっていると考えるほうが自然です（たまたま、あるイベントがあったために○○県では患者が発生したなど）。
予防対策の勝利なのか、天の恵みのおかげなのか、どうも判然としません。例えば次の情報から仮説を立てることはできるでしょうか？
都道府県別情報　インフルエンザ　新型コロナ
インフルエンザと新型コロナの流行に地域的な重なりを見ることはできますが・・難しいですね。

ひょっとしたら来週手掛かりが訪れるかもしれません。
3/9-14の週は千代田区の最低気温は10度を上回る高温予報です(3/4時点の10日予報)。
予報通り高温で推移したとして、東京都のインフルエンザ、新型コロナの新規患者発生数
がどうなるか？貴重なデータが収集できるかもしれません。

時流のテーマを題材に歯切れの悪いデータサイエンス、サイエンスにもなっていないお話しをしてしまいました。ただ実際、データサイエンティストが扱うテーマもこんな感じです。データに走る前に状況、基本理解に努めます。感染症の流行と終息要因の仮説として気温に注目している段階です。機械的に割り振りができるものは既にシステムに組み込まれています。結論を急がない、人間領域ではあえて機械と違う心構えでよいのではないでしょうか。
※週末は薬剤師業務をしており小児科、内科の患者さんと接しております。現場感からこのような投稿を上げた次第です。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。

オフィスエヌ ショートレビュー5万円から。

連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します

失敗できないプロジェクト 〈急所〉

プロジェクトの “急所” 、一つ挙げるとしたらどこでしょうか？　プロジェクト計画、要件定義、設計、開発、テスト

どれも大切ですが、問題が表に出てくるのは “テスト” ですよね。結合テスト、システムテストでこんな問題が起きることがあります。

１．テストに入れない（プログラム がない！、ファイル、テーブル がない）

２．テストに入れない（テスト仕様書がない！）

３．テストに入れない（環境がない！、時間枠がない）

１番目のケース、まさかそんな！と思われますよね。でも開発の遅れで一部プログラムが揃っていないということは経験があると思います。影響のないところからテストをはじめます。またテストを始めた途端、仕様の取り違えが判明しテストにならない、ということもあるでしょう。結合テスト段階で単体テストのバグが出るというケースです。そもそも取りこぼしでプログラムを作っていなかった、リリース期日の間違え、もあるでしょう。

規模が大きくなる程、この手の初歩的なミスが増えます。

プログラムができるまでは、ドキュメントベースで確認するしかありません。要件定義書、設計書など何百ページもあるドキュメントを目検していく訳なので、ベテランであっても一定割合で、ある、なしレベルのミスが発生します。

発生割合ですが、さすがに全体の10%ということはありませんが、0.1%ということもありません。感覚的に１%はありますね。２%前後はあってもおかしくないと考えておくのが相場です。

結合テストからシステムテストと進むにつれ、ある、なし レベルのミスは全体の足を引っ張ります。影響のおよぶ範囲のテストを止めてしまいます。ミスは避けられません。早い段階で露見させるのが賢い対策です。PM（プロジェクトマネージャ）、PMOの真価は課題対策にあります。

“仮組み”

そこで開発中であっても、週の最後に、出来ている分だけ、ある分だけのプログラムを集め、中途半端なデータベースにつないでしまうのですね。私はよくやりました。ポイントは集めるにあります。

ビルドエラーも出ます。マスターのコード定義もありません。初めは動きません。それでも無いものが分かるので

「来週これは作る予定だよね？」

と確認できます。そこでドキッとします。

「忘れるところでした（本当は、忘れていました）」

というふうに。

アジャイルだと、頻繁にビルドをしているので、ある、なしレベルのミスは防止できますね。限られた時間と集中力を設計開発に回せるのは利点です。

“仮組み” はウォータフォール開発や基幹系システムでもおすすめです。「忘れている」というと、担当者に対する落ち度の指摘です。指摘された方は気分のいいものではありません。指摘する側も、言いたくて言っている訳ではありません（言いづらいです）。人間同士お互いの負の感情はコミュニケーションを阻害します。できれば避けたいものです。

 “仮組み” は「ある」「なし」を見えるようにしています。担当者が「忘れていた」ことに違いはありませんが、指摘は、仮組み環境を経由した間接的なものになります。同じことでも人から直接指摘された時のような負の感情は生じないか弱いものになります。

「見える化」とか「可視化」は問題発見の効率化と合わせて、担当者の前向きな行動や、グループのコミュニケーションを維持する効用があるのではないでしょうか。

“仮組み” 試してみてはいかがでしょうか。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します