N501Y変異株スクリーニングの実施状況 [グラフ新規実装]

[kaizumaki]

変異株グラフを新規に実装します。

4/26（月）リリースです。実装完了前にしばらく離れる場合はDraft Pull Requestを出しておいてください。

N501Y変異株スクリーニングの実施状況　実装内容

構成比グラフと折れ線グラフの２軸になります。
構成比グラフといっても、実装は普通の積み上げ棒グラフです。
デザインは「モニタリング項目(4)」のグラフを参考にしています。累計切り替えはありません。
X軸は週次なので、「都営地下鉄の利用者数の推移」グラフが参考になると思います。
テーブルにはグラフで使用するデータ以外に検査数の実数を２項目追加します。

下準備

variant.json を追加しましたので、こちら を参考に、jsonの型定義ファイルを生成してください。

グラフ

• 積み上げ棒グラフ（１段目）
  • ラベル：N501Y陽性例構成割合
  • 単位：%
  • 小数桁数：１桁
  • データ： variant.json の n501y_positive_rate キー
  • 色： #1b4d30 （surfaceStyleA）
• 積み上げ棒グラフ（２段目）
  • ラベル：N501Y非陽性例構成割合
  • 単位：%
  • 小数桁数：１桁
  • データ： variant.json の n501y_negative_rate キー
  • 色： #c5e2c6 （surfaceStyleC）
• 折れ線グラフ（実線）
  • ラベル：変異株PCR検査実施割合
  • 単位：%
  • 小数桁数：１桁
  • データ： variant.json の variant_pcr_rate キー
  • 色： #cc7004 (surfaceStyleE)

※折れ線グラフはベジェ曲線ではなく直線でお願いします。
※折れ線グラフを前面表示でお願いします。
※小数桁数は utils/monitoringStatusValueFormatters.ts にある関数を使って実装してください。

テーブル

ラベル名は以下です。

日付	変異株PCR検査実施数	N501Y陽性例数	N501Y陽性例構成割合	変異株PCR検査実施割合
〇月〇日〜〇月〇日	〇〇	○○	〇〇	○○

• 変異株PCR検査実施数
  • 小数桁数：整数
  • データ： variant.json の variant_test_count キー
• N501Y陽性例数
  • 小数桁数：整数
  • データ： variant.json の variant_positive_count キー
• N501Y陽性例構成割合
  • 小数桁数：１桁
  • データ： variant.json の n501y_positive_rate キー
• 変異株PCR検査実施割合
  • 小数桁数：１桁
  • データ： variant.json の variant_pcr_rate キー

タイトル実装イメージ

• N501Y陽性例構成比
  • 注釈： 2021年●月●日から2021年●月●日までの期間の数値（現在判明している数値であり、後日修正される場合がある）
• 変異株PCR検査実施率
  • 注釈： 2021年●月●日から2021年●月●日までの期間の数値（現在判明している数値であり、後日修正される場合がある）

注釈

・N501Y陽性例構成割合：N501Y陽性例数／変異株PCR検査実施数　
・変異株PCR検査実施割合：変異株PCR検査実施数／新規陽性者数（報告日別）
・検体受付日を基準とする

配置

「その他参考指標」タブのグループの７番目（「検査実施件数」の次）に配置します。
「新型コロナコールセンター相談件数」カードの次の空白はつめてください。

実装イメージ

わからないことなどあったら、遠慮なくこちらのissueにコメントしてください！

[nard-tech]

私やります

[kaizumaki]

@nard-tech ありがとうございます！よろしくお願いします！ 🙏

[nard-tech]

@kaizumaki 「オープンデータを入手」のリンク先はどちらにすればよいでしょうか

[kaizumaki]

@nard-tech ありがとうございます！いまのところオープンデータにはなっていないので、文言ごとなしでOKです（実装イメージには載ってますね。すみません）。

[nard-tech]

@kaizumaki 承知しました．

そもそもの話で恐縮なのですが，既存のグラフの仕様では，割合に関する値はいずれもオレンジ色の折れ線グラフで表現されており，「N501Y陽性例構成割合」「N501Y非陽性例構成割合」を積み上げ棒グラフで表現することには違和感があります．（「都営地下鉄の利用者数の推移」も折れ線グラフにした方が棒グラフが重なっている状態より見やすくなると思っています）

「N501Y陽性例数」「N501Y陰性例数」を積み上げ棒グラフで表現し，「陽性例構成割合」「変異株PCR検査実施割合」のどちらかを実線，もう一方を破線で表現すれば，

• 割合を線で表現している他のグラフと仕様が合致する
• 陽性・陰性の絶対数をグラフで表現でき，検査数（陽性+陰性）と陽性例そのものの増加傾向が見えるようになる

というメリットがあります．

また，「N501Y非陽性例構成割合」は「陽性例構成割合」からすぐに分かることですので，テーブルに表示するのはいいとしても，グラフで表現すると冗長になる気がします．また，この中にはN501Y以外の変異株のケースが含まれていると思われ，「N501Yでない」ことに大きな意味があるとも思いません．

以上の点を考慮していま一度仕様を再考いただけないでしょうか．

[nard-tech]

今後他の変異株に対応する可能性を考えると，JSON の n501y_negative_rate という key の値についても，key を negative_rate とするか，そもそも値を JSON に入れない方がいいかもしれません．

[kaizumaki]

@nard-tech

以上の点を考慮していま一度仕様を再考いただけないでしょうか．

構成比グラフにしたのは東京都のほうで検討が練られた結果ですので、再考は今の時点ではできません。
（こちらのページが関連あると思います。）
ただ、こちらのissueの内容をリリースした後に、提案として新たにissueを立てていただくというのでもよいかと思います。その場合は東京都の要確認（need-official-confirmation）になりますので、お時間いただきますが、いずれはご提案について回答いたします。

今後他の変異株に対応する可能性を考えると，JSON の n501y_negative_rate という key の値についても，key を negative_rate とするか，そもそも値を JSON に入れない方がいいかもしれません．

確かにnegativeについて、そのご提案は理解できるのですが、今後の他の変異株のことは今は考えられないと思っていて（この先、どういう状況になるかわかりませんし、その時には別のグラフを立てることになるかもしれないですし）、現時点ではこのままでいきたいです。

[nard-tech]

構成比グラフにしたのは東京都のほうで検討が練られた結果ですので、再考は今の時点ではできません。（こちらのページが関連あると思います。）

東京都福祉保健局 https://www.fukushihoken.metro.tokyo.lg.jp/iryo/kansen/screening.html を拝見しました．
こちらの「都内の変異株の発生割合」のグラフをそのまま https://stopcovid19.metro.tokyo.lg.jp/ に掲載しようとされているのでしょうが，そもそも東京都福祉保健局のグラフは従来株の「割合」だけを表示しており，従来株の陽性数自体が減っているような誤解を招きかねないという問題があります．

https://www.fukushihoken.metro.tokyo.lg.jp/iryo/kansen/screening.files/screening_042202.pdf には陽性数も示されていますが，4月12日〜18日で従来株の陽性数が減っていると思われる程度で，それまでは従来株の陽性数には減少傾向は見られません．

従来株が変異株に置き換わっているのか，従来株も依然として多いが変異株が広がりつつあるのかを適切に表現し，事態の重さをより正しく伝えるには，割合と絶対数をともに掲載するのが適切です．

したがって，

東京都のほうで検討が練られた結果

とのことですが，「東京都での検討」が不十分だという疑念を抱いています．また，検討の内容が GitHub 上でオープンにされておらず，どのような意図・目的で仕様が決定されたかも不明確であり，東京都として検討した結果の正当性を判断できません．

先に述べた私の意見に対する正当な回答あるいは反論，または東京都として検討した内容およびこの仕様でよいとした根拠を示して頂きたいです．そうでないとこれ以上の実装はできません．

また，

こちらのissueの内容をリリースした後に、提案として新たにissueを立てていただく

というのは明らかに時間の無駄です．我々は private の時間で無償でやっておりますので，貴重なリソースを無駄に使いたくありません．

再考は今の時点ではできません

とのことですが，東京都が決めた仕様をそのまま実装するのでは，ただのウォーターフォール開発です．

議論をオープンにして，多様な意見を集めて意思決定をしていくことこそ GitHub を使って OSS で開発する目的であり，東京都が決めた仕様に盲目的に従うことは到底受け入れられません．我々 contributor は「東京都の決定にしたがってタダ働きする部隊」ではありません．

[ocean3fish]

@nard-tech 数々のcontributeや貴重なご意見ありがとうございます。

まず東京都の方針に沿ってグラフをリリースする、というやり方には意味があると思っています。
状況が刻々と変化する中で、公開可能な情報はいち早く多くの人に届けられるように対策サイト上で公開したいと考えています。
行政組織の意思決定には民間よりもはるかに多くの時間がかかり、情報の公開に慎重な姿勢を示す方も少なくない中、東京都の職員の方々は大変な尽力を重ねて我々に渡す所まで持ってきてくれています。
そのため、一度決まったものはまずリリース、その後オープンな場で改善提案をしてより良い形に、という方法が良いと考えています。

すべての意思決定プロセスがオープンになるのが理想ですが、一朝一夕には行かないと思っています。
使っているプラットフォームこそGitHubですが、オープンソースコミュニティの文化は行政組織においてまだまだ浸透していません。
行政組織の持つ情報のオープン化が進むには技術コミュニティへの信頼が蓄積されて行くことも重要だと考えており、提案が通らないことも多々ありますが、今可能な選択肢の中で一番最適な方法を一緒に模索する形で進めているつもりです。

@nard-tech さんのご意見を蔑ろにしたり無駄な作業をお願いするつもりは無く、迅速な情報発信と実物を見ながらのオープンな議論を可能にするために、@kaizumaki さんからは別途issueを立てるという提案があったものと思います。
さまざまな立場の方にコントリビュートして頂いているプロジェクトなので、立場によって色々な状況があることを考慮しながら、互いを尊重して進めさせて頂きたいと思っています。
今回せっかく実装をお引き受け頂けるとご表明頂いたので、この先もご協力頂けると幸いに思いますが、おっしゃる通り皆さんの自由な意思によるcontributeで成り立っているプロジェクトなので、もし考え方にご賛同頂けない場合はご無理をお願いするものではありません。
賛同できないので今回の実装のご担当を外れるという場合は、お早めにご表明頂けると助かります。

ただ、@nard-tech さんのようにオープンな文化を作っていく強い意思をお持ちの方にご参加頂けることは貴重だと思っていますので、一緒に徐々に流れを変えていくことが出来ないかと考えています。
ご検討頂けますと幸いです。

[nard-tech]

@ocean3fish どの立場からお話されているのか判然としませんが，Code for Japan の運営側の方でしょうか．

実装以前の段階で疑義があるにも関わらず東京都の方針に従ってしまうことはむしろ悪手だと思っています．
行政組織がこのような形で情報を提供すること（するようになってきたこと）自体に意味があると感じていますが，ただ提供すればいいというものではないはずです．
本プロジェクトの目的は「現状を多くの人に正しく伝えること」と理解していますが，アジャイル開発とはいえども伝え方を十分に議論せずにリリースしてしまうのには反対します．現状を正しく伝えられないリスクだけでなく，先に述べたような，余計な開発コストを生じることについても懸念しています．

私は都民ではありませんが，contributor として，エンジニアとしての立場から，一定の論拠をもって「その目的を達成するのであれば別のやり方があるのではないか」という指摘・提案をしています．

行政組織の意思決定には民間よりもはるかに多くの時間がかかり

という点については理解しますが，GitHub 上で OSS として開発することを選択したのは東京都なのですから，私に対して回答する責任があるはずです．

使っているプラットフォームこそGitHubですが、オープンソースコミュニティの文化は行政組織においてまだまだ浸透していません

というのは無責任な言い訳に過ぎないのではないでしょうか．

行政組織の持つ情報のオープン化が進むには技術コミュニティへの信頼が蓄積されて行くことも重要だと考えており、提案が通らないことも多々ありますが、

とありますが，多様な人材が活発な議論を重ねることで技術コミュニティへの信頼が蓄積されると思います．
技術者が東京都の支持に従うことで「信頼」が得られるのだとしたら，それは単なる主従関係の中での「タダで使える都合のいい手下」としての信頼でしかなく，よりよいものを作っていこうという思いで結ばれた対等な関係の中での信頼ではないでしょう．
私は提案が通らないことではなく，提案が議論の俎上にすら載らないことに対して憤りを覚えます．
ダメなものはダメと言える環境があり，発言できる人がいることこそ本当の技術コミュニティへの信頼につながると思っています．

今回の実装に関しては，やると表明した手前申し訳ありませんが，残念ながら降りさせていただきます．
グラフの仕様に関わらない範囲に関しては #6210 に上げていますので，どなたか引き継いで頂きたいと思います．

これをきっかけに東京都の皆さんも交えた議論が活発になることを期待します．

[ocean3fish]

@nard-tech すみません、以前もGitHub上やSocial Hack Dayでやりとりさせて頂いたことがあったので特に名乗らずにコメントしてしまいました。
Code for Japanの運営側で主にデータ周りの設計に関与している者です。
設計はGitHub外での作業が多いもので、ログがあまり無い中で恐縮です。

私も目指すべきは@nard-techさんのおっしゃるような、対等な立場でオープンに議論ができるコミュニティだと思っています。
運営側も要望を鵜呑みにしているわけではなく、改善の提案は随時行っています。
それが通ることも、通らないこともあります。
ただ、この対策サイトは東京都のオフィシャルサイトとして運営されている以上、最終的に責任を取るのは東京都です。
他の地域にあるように運営主体がコミュニティであれば別ですが、このプロジェクトにおいては開発コミュニティ側の提案者が責任を取れるわけではないので、最終的な判断は東京都で行うしかありません。

私は提案が通らないことではなく，提案が議論の俎上にすら載らないことに対して憤りを覚えます．

決して提案が議論の俎上に載っていないことはなく、東京都の職員の方々もこちらのGitHubはご覧頂ける状態になっていますし、見落としを防ぐために運営側からも取りまとめてお伝えしています。
実際にこれまでにcontributorの方のご提案が採用された例が多々あるのもご存知かと思います。
ただ、運営チームも結局は外野でアクセスできない情報は多いので、本気で東京都のスタンスを変えたいと思ったら、実際に中に入るしかないと思います。

「現状を多くの人に正しく伝えること」を最優先にというのも同意です。
正解が決まっているものならその通りに作れば良いですが、グラフには正解/不正解をはっきり決められないものも多いです。
グラフを見る人がどのくらいその対象についての前提知識を持っているかであったり、個人のバックグラウンドによっても捉え方が変わってしまうため、個人の思う「正しさ」がそのまま通用しないこともあります。
また、複数案あるうちのどれが良いかを検討する場合、現物を見ないと文章だけではイメージが追いつかない方もいるかと思います。
例えばもし今後も改善提案を頂ける場合、実装までせずともExcelやBIツールで具体的なイメージを作って提案することでもう少し検討に乗りやすくなるかもしれないとも思います。
意思決定プロセスを把握しているわけでは無いので無責任な意見と思われてしまったらそれまでですが、今後issueでメンション頂けたら、イメージ案を作る部分などお手伝いしつつ一緒に提案するということもできると思います。
ただ、検討にかける時間と情報発信のスピード感とのトレードオフは確実にあり、前述の通り責任を負うのは東京都なので、まずリリースを進めてから提案を受けて改善するというパターンは今後もあると思っています。

[ghost]

@ocean3fish 別の方のコメントに「東京都の決定にしたがってタダ働きする部隊」という表現がありましたが、なかなかうまい表現だと思いましたので、コメント致します。

まず、GitHubでは見えない東京都からの委託先のアクティビティがあることは一定程度推測できますし、善意等の動機付けで無償でコントリビュートされる方々には心から敬意を表するとともに深く感謝申し上げます。

しかしながら、率直に申し上げると、GitHubで見える東京都からの委託先の動きは、プロジェクトの立ち上げ期を除いて、共創気運を盛り上げるというよりは、コントリビュータにスルーパスすることで、自らのコストを下げて利益率を上げようとしてるのではないかという印象を持つことがあります。この印象を持つのは、必ずしもマジョリティではないかもしれませんが、そのように受け止める都民もいることをお伝えいたします。

[nard-tech]

@ocean3fish
issue が close されてしまっていますが，コメントさせていただきます．

私も東京都の関係者の皆様や Code for Japan の皆様と目指している方向は概ね同じだと思うのですが，立場の違いとそれによる見える範囲の違いにより意見のすれ違いが生じていると思っています．

最終的に責任を取るのは東京都です

最終的な判断は東京都で行うしかありません

それはまったくその通りで異論はありませんが，「最終的な判断」として上がってきた仕様がおかしいと思ったからこの issue で指摘をしたまでです．GitHub で issue を立てて一般からのコメントを広く受け付けている以上，それを止める権利は誰にもないと思います．

決して提案が議論の俎上に載っていないことはなく、東京都の職員の方々もこちらのGitHubはご覧頂ける状態になっていますし、見落としを防ぐために運営側からも取りまとめてお伝えしています。実際にこれまでにcontributorの方のご提案が採用された例が多々あるのもご存知かと思います。

「議論の俎上に載っていない」というのは言いすぎたかもしれません．contributor の提案が多々採用されているのも，commit 数でいえば私がトップですから，誰よりも知っているつもりです．

しかし，この issue のように，指摘・提案を受け付けて議論している余裕のない場合，その旨を明記して頂けると，開発者は納得できなければそのままスルーできますし，手を動かす場合にも今回のようなトラブルを避けることができます．

さらに言えば，このような場合は実装を行い pull request を出すところまで運営側で全て巻き取って頂いた方がよいと思います．GitHub で OSS として公開されていて，東京都も GitHub 上での contributor の参加を前提としてこのサイトを運営している以上，エンジニアの専門知識と経験と信念に基づく指摘が軽視されるということはあってはなりません．東京都のオフィシャルサイトという性質上，あるいはスケジュールの都合上，致し方ないことがあるのは承知ですが，おかしいと思ったものをそのまま実装するのはまともなエンジニアであれば生理的に無理でしょうし，Code for Japan さんは東京都とサイトの運営について安くはない契約を結んでいるのですから，このような場合は contributor に期待せずに，有償で運用を請け負った責任を果たして頂きたいと思います．

正直，@cutsortuniq さんの

GitHubで見える東京都からの委託先の動きは、プロジェクトの立ち上げ期を除いて、共創気運を盛り上げるというよりは、コントリビュータにスルーパスすることで、自らのコストを下げて利益率を上げようとしてるのではないかという印象を持つことがあります。

という受け止め方も納得できるところがあります．

私としても，継続的に安定した運用をするために必要な改善など，私などが issue を立てる前にもっと問題意識を持って取り組んで頂きたいと思います．

[nard-tech]

@ocean3fish

運営チームも結局は外野でアクセスできない情報は多いので、本気で東京都のスタンスを変えたいと思ったら、実際に中に入るしかないと思います。

Code for Japan さんの方々も日々ご苦労があるかと思いますので，「実際に中に入るしかない」というのはその中から出てきた本音だとは思いますが，それをここで言ってしまうのはズルいと思います．

昨年の3月に東京都が自らスタンスを変えて GitHub に現れたと多くのエンジニアが感じ期待したからこそこのプロジェクトは当初盛り上がったのだと思います．また，社会情勢が今なお続いているのにも関わらず往時の盛り上がりが見られないのは，単なる「ブームの衰退」によるものだけでなく，東京都のスタンスの変化がさほど感じられなかったせいかな，と感じることがあります．

盛り上がりと同時に宮坂副知事や関さんが注目され，いろいろと受賞などされるのも目にしましたが，クローズアップされたからには，最後まで本気で東京都のスタンスを変えに行って頂きたいと思います．そうでなければ，このプロジェクトに関わった数々のエンジニアの評価も世間で埋もれてしまいます．私も，これを機に離れるということはせず，引き続きコミットしていきたいと思います．

[nard-tech]

@ocean3fish

正解が決まっているものならその通りに作れば良いですが、グラフには正解/不正解をはっきり決められないものも多いです。

また、複数案あるうちのどれが良いかを検討する場合、現物を見ないと文章だけではイメージが追いつかない方もいるかと思います。

例えばもし今後も改善提案を頂ける場合、実装までせずともExcelやBIツールで具体的なイメージを作って提案することでもう少し検討に乗りやすくなるかもしれないとも思います。

その通りなので，なぜ最初の案より私の案がよいかについては丁寧に言葉で説明し，どちらがよいかを判断する材料については十分にご提供したつもりです．実は簡単な手書きのイラストも用意していたのですが，それを出す前に「再考はできない」と言われてしまったので残念です．

ただ、検討にかける時間と情報発信のスピード感とのトレードオフは確実にあり、前述の通り責任を負うのは東京都なので、まずリリースを進めてから提案を受けて改善するというパターンは今後もあると思っています。

今回は私の方で，情報発信のスピード感を犠牲にしてでも検討に時間をかけた方がよいのではないかと感じました．
トレードオフでどちらが勝つかは個人の感性によるところも大きく，どちらを優先すべきかに正解はありませんが，今回のように議論をする余裕もないという事情があるのであれば，先に述べたようにその旨を明記して頂くか，運営側で全て巻き取って頂くのがよいと思います．

私の感覚では，21日に issue が上がって26日にリリースであれば，グラフ1つの議論には十分な時間があるだろうと思ったのですが，さすがに東京都にそれは通じないということで，勉強になりました．

[kaizumaki]

@nard-tech コメントありがとうございます。まず、最初の方で「再考はできない」と乱暴に書いてしまったことはお詫びします。
今後の東京都や運営のスタンスについては検討中なので、ちゃんとしたお返事はまたの機会にさせてください。
１点だけ、

私の感覚では，21日に issue が上がって26日にリリースであれば，グラフ1つの議論には十分な時間があるだろうと思ったのですが，さすがに東京都にそれは通じないということで，勉強になりました．

これについては、一応営業日換算で動いていますので（とはいえ東京都の皆さんは昼夜土日祝問わず稼働してらっしゃることは知っています）、土日を引くと、グラフの再検討には時間がないと私の方で判断しました。
私たちは対策サイトの担当である政策企画局とやりとりをしていますが、グラフの検討にはデータのフォーマットを担当しているデジタルサービス局、データを集約・入力している福祉保健局、それらの上のほうの人たちといった具合に、多くの人が動いています。
なので、再検討をお願いしても、十分な検討する時間はなく、結局納得できる回答は得られないと思ったのです。

連休前ですので、各所慌ただしく、まだちゃんとしたお返事が差し上げられなくて申し訳ありません。もうしばらくお待ちいただけますと幸いです。

[kaizumaki]

ただいま東京都には回答をいただくように依頼しています。その前に、Code for Japan内で話し合ったので、一旦ここで私たちの回答をコメントします。

変異株グラフの件に関して @nard-tech さんをはじめコントリビューターのみなさんに情報や意図が伝わらずにご迷惑をおかけしたことを改めてお詫びします。
まず改善策としてラベルの整備をしたいと考えています。
今回のissueのように東京都からの依頼（officially-approved）については、はっきりとわかるようなラベルにしようと思っています。どういったラベルにするかは別途issueを立てますので、ご意見いただければと思います。
そして、東京都から仕様が決められたissueについては、期限内のリリースが最優先されることをわかるようにラベリングします。
ただ、実装するソースコードの改善提案は可能です。実際、過去にも、私が思いつかなかった実装方法をコントリビューターさんが提案してくれて、それが採用となったことがあります。

私たちはコントリビューターのみなさんのことを「無償の労働力」と思ってはいません。私たちだけでは思いつかない改善提案やソースコードは大変ありがたく採用させていただいていますし、数々のディスカッションの履歴は大きな財産だと思っています。そして運営側としてはコントリビューターのみなさんが参加しやすくするためにデータの整備をしたり、コミュニケーションをとったりしています。コントリビューターさんが見つからないissueについては最終的に運営側で対応しています。

Code for Japanとしては行政にオープンソースの文化や手法を入れたいと長年活動してきました。行政にオープンソースの文化を根付かせるのは簡単なことではないと、私自身痛感しています。ただ、今回 @nard-tech さんにご意見いただいたことを重く受け止めて、一歩でも前進できるように探っていきたいと思っています。

[nard-tech]

@kaizumaki ご対応頂きありがとうございます．東京都の皆さんも Code for Japan の皆さんも限られたリソースの中で頑張っておられることは承知しております．引き続きよろしくお願い致します．