手短にアウトプット練習⑥

はじめに

自己研鑽がてら、極力定期的に何かしらの物事についてアウトプットをしていく。
手短に、シンプルに。


災害時の事業継続アプリをGitHubで無償公開(日本MS)

「リスクへの備えパッケージ」って?
災害時やパンデミックなどの緊急時に企業や官公庁が事業継続できるように支援するクラウドツール。
以下の3つのアプリから構成され、各社がアプリを自由にカスタマイズして利用できる。


① リモートワーク対応業務連絡アプリケーション
 Web会議システム:Teamsを活用して出社管理や日報の共有ができる。
② 安否確認アプリケーション
 部署などの単位でグループを作成し、グループ長が作成した専用リストで本人や家族の安否、被害や健康状況をグループ全員に共有できる。
③ 災害対応アプリケーション
 緊急時に作背負うする情報を迅速に把握でき、職員や従業員の災害対策報告を円滑に行える。災害発生後の交通、インフラへの影響、二次災害に関する報告など、常に最新の状況を把握して適切な対策アクションを撮れるよう情報の記録や管理ができる。


いつ、だれが、どこに公開した?
6月23日に日本MSがGitHubに無償公開した。


個人的な所感

①これらのサービスはMSのクラウドサービス上で公開されていて、利用者側がどれを使うかを選ぶことができる(SaaS)という点で良いと思う。


GitHub上に公開されたコードを利用者側で取得して独自にカスタマイズできる(OSS改変のようなイメージ)という訳ではないという認識だが合っているのかな?


③(特に②について)グループの作成とかの手順というか、使いやすさというか、ユーザビリティはいかほどのものなんだろう。あまり煩雑だと、使う側のハードルも上がると思うが…。


④(特に③について)従業員の勤務形態や勤務地によって、柔軟に開示される情報を変えることができれば便利そう。たとえば東京の会社に千葉からリモート勤務している人にしてみれば、欲しい情報はどちらかというと東京のものではなく、千葉のもののはず。
…自分が把握していないだけで、利用者の設定次第でそこらへんはカバーできるのかもしれないが。

  • その従業員は今日リモート勤務なのか出社しているのか。
  • リモートなら(会社の事業所に入館記録が無いのなら)従業員の所在地を社内システムから取得して、アプリへのインプットとして使う。
  • 出社しているのなら(会社の事業所に入館記録があるのなら)その事業所がある所在地の情報を、アプリへのインプットとして使う。


参考文献

日本MS、災害時の事業継続アプリをGitHubで無償公開 自由にカスタマイズ可能 - ITmedia NEWS
【技術・仕組】日本マイクロソフト「リスクへの備えパッケージ」を GitHub に公開 | TEAM防災ジャパン
日本マイクロソフト 未来につなぐプロジェクト ~これまでの 10 年、これからの 10 年

(おまけ)
Microsoftの「Azure」などが“政府認定クラウド”の仲間入り セキュリティ評価制度「ISMAP」に登録 - ITmedia NEWS

手短にアウトプット練習⑤

はじめに

自己研鑽がてら、極力定期的に何かしらの物事についてアウトプットをしていく。
手短に、シンプルに。


高速道路深夜割引について

高速道路深夜割引って?
深夜帯の高速道路の利用料金を割り引くというもの。
年代により割引率は異なっていたが、2021年3月時点では一律30%割引となっている。

対象となる時間帯は?
午前0時から午前4時。

いつごろから深夜割引の制度が始まった?
2000年代から。

どこで?(深夜割引の適用範囲は?)
NEXCO管轄の道路など。

なぜ?(高速道路深夜割引の目的は?)
一般道の沿道環境改善のため。
高速道路の料金を引き下げることで深夜帯の利用を促進し、一般道から車を減らす。


高速道路深夜割引の問題点

深夜割引を受けるために高速道路で渋滞が発生してしまっている。
深夜割引を受けるための時間調整のためにSAやPAが夜間に混雑したり、場所によっては本線上でも車両の滞留が発生している。

こうした背景から、深夜割引の見直しが検討されている。
2021年3月10日の有識者会議、第49回国土幹線道路会にて議題にあがった。


個人的な所感

個人的には、深夜割引自体はなくさない方がよいと思っている。
これが無くなると、深夜割引制度適用前の状態に戻ってしまうと思う。
 ⇒料金的な面で夜間に一般道に車が増える。
 ⇒車の通行音などの問題。

また、「0時~4時まで一律30%引き」となっているのも改良の余地があると思う。
たとえば、「利用開始した時間帯と走行区間によって柔軟に割引率が決定される」ようなシステムにするとか。

たとえば、こんな感じにして、「0時より前に利用開始しても(従来の割引率よりは少なくなるけど)メリットが出る」ようにしてみる。
利用区間(どこからどこまで)や利用時刻はETCから取れないものか(車を持っていないので分からない)。

利用距離(利用区間 利用開始時刻 割引率
50km未満 22時~23時 10%
50km未満 23時~1時 15%
50km未満 1時~4時 20%
50km以上200km未満 22時~23時 15%
50km以上200km未満 23時~1時 25%
50km以上200km未満 1時~4時 35%
・・・ ・・・ ・・・

要は「0時から4時」となっていたから、いいかえると「0時より前に高速を使っても何にもメリットが無い」状態だったからこの時間帯に合わせた渋滞が発生するわけで。

「0時より前に利用しても(少し早い時間に高速を利用してもメリットはある」というふうにすれば、「高速道路の料金を引き下げることで深夜帯の利用を促進し、一般道から車を減らす」という当初の目的を果たしつつ、利用者にとってもメリットがあるという状態を維持できるのではと考える。

この案のデメリットは、料金体系が複雑になってしまうということ。
一律3割引きというのは、実は利用者にとって分かりやすさという面でも一役買っているのかもしれない。


参考文献

高速道路「深夜割引」見直しへ 割引目的で深夜0時前に溢れるトラック「逆に不経済」 | 乗りものニュース

手短にアウトプット練習④

はじめに

自己研鑽がてら、極力定期的に何かしらの物事についてアウトプットをしていく。
手短に、シンプルに。


カーボンニュートラル

2050年までに温室効果ガスの排出を全体としてゼロにする(脱炭素社会を目指す)という宣言。


「全体としてゼロ」って?
温室効果ガスの排出量と、森林などによる吸収量を差し引いた値をゼロにする、ということ。


ここで言う「温室効果ガス」って?
二酸化炭素、メタン、一酸化に窒素、フロンガス


産業構造や経済社会の変革による大きな成長が期待されているし、国としても積極的に推している。


火力発電やごみ焼却施設はどうなるのだろう?
再生可能エネルギーによる発電設備が増える(設備投資が行われる)?
日本のごみ焼却の性能って確か世界トップクラスだったような。それにもメスが入るってこと?


ひとつの可能性

そしてカーボンニュートラルへのひとつの可能性を示してくれたのが、先月行われた富士スピードウェイの24時間耐久レース。
トヨタの水素エンジン搭載車が1500kmを走り切ったニュースは記憶に新しい。

今後は自動車業界にとどまらず様々な業種業界から、そうした思い切った挑戦がなされていくのかな。

参考文献

ondankataisaku.env.go.jp

www.enecho.meti.go.jp

toyotatimes.jp

手短にアウトプット練習③

はじめに

自己研鑽がてら、極力定期的に何かしらの物事についてアウトプットをしていく。
手短に、シンプルに。

STEM教育

このニュースを見ているときに見慣れない言葉が目に入ったのがきっかけ。
ベゾス氏と11分間の宇宙旅行 座席を30億円で落札:朝日新聞デジタル

S:Science(科学)
T:Technology(技術)
E:Engineering(工学)
M:Mathmatics(数学)
の教育分野を総称した言葉。

<目的・ねらい>
IT社会とグローバル社会に適応した国際競争力を持った人材を育成する。
「自分で学び、自分で理解する」能力を養う。

従来のような「先生が言ったことを子供が暗記する」という感じではない。
子供が主体。
そして、それをバックアップしよう、というのがSTEM教育。

<どれぐらい浸透しているか>
アメリ
・年間で数十億ドルという予算を投入して、国がSTEMを応援している。
・小さいころからPCやタブレットを使ったり、研究用のロボットを組み立てる、プログラミングの授業を行うなどを行っている。

新興国(インドやシンガポールなど)でもSTEM教育が盛ん。
両方に言えるのは、国が主体になって子供にSTEM教育を受けさせることで、より魅力的な人材を育成しようとしている、ということ。

日本ではアメリカなどと比べるとあまり浸透しているとは言えない。
・ICT教育環境の整備の遅れ
 - プログラミング授業の必修化が2020年度から。

民間では様々なSTEM教育のサービスや活動が始まっている。
例:埼玉大学のSTEM教育研究センター


参考
https://coeteco.jp/articles/10070

手短にアウトプット練習②

はじめに

自己研鑽がてら、極力定期的に何かしらの物事についてアウトプットをしていく。
手短に、シンプルに。

6次産業

1次産業(生産)×2次産業(加工)×3次産業(販売・流通) で6次産業。一連の流れの中で商品に付加価値を付け、それを消費者にお届けする。
Before: 野菜等を生産して終わり(そのあとの工程はその道の人にお任せ)。
After : 加工から販売(消費者に届ける)までやってしまおう。

<背景>
農林漁業の担い出不足と所得の確保が課題。
加工・販売も一緒に行うことで商品に付加価値をつけることができ(所得確保)、また、それを行うための雇用も生むことができる。

国としてもこの課題に対して動いており、平成23年3月1日、「地域資源を活用した農林漁業者等による新事業の創出等及び地域の農林水産物の利用促進に関する法律(六次産業化法)」が施行された。
 ⇒雇用や所得、食料自給率等の向上を目指す。
 ⇒国としても6次産業に対して積極的に支援を行っている。


<メリット>
①収益の拡大が見込める。
②雇用の増加。
地域活性化につながる。


<デメリット(考慮しないといけない点)>
①追加で設備などへの投資が必要。
②追加で専門知識を学ぶ(習得する)必要がある。

 ⇒国のサポートを受けられればある程度そのリスクも軽減できる。


<事例集>
事例①
冷凍しても保つプリプリ感!手軽に食べられるみかんの加工品開発:農林水産省

事例②
山を守り山へ感謝 地元特産の北山杉を使ったお棺で旅立ち:農林水産省

色々な実施例
6次産業化の取組事例集(令和3年3月):農林水産省
6次産業化の商品事例集(平成30年1月):農林水産省

使われていない土地の有効活用、自家用に作ったらおいしかったのでそれを届けたいと思った、生産した商品を再生(付加価値をつける)、雇用の確保のため、等そこにいたるきっかけは様々。
大学とタッグを組んで進めている事例もある。

手短にアウトプット練習①

はじめに

自己研鑽がてら、極力定期的に何かしらの物事についてアウトプットをしていく。
手短に、シンプルに。

暗号化方式

セキュアにデータをやり取りするための方法で、「共通鍵暗号方式」と「公開鍵暗号方式」がある。
誰が鍵を生成するのか、がミソ。

共通鍵暗号方式>
・データの暗号化と、暗号化したデータの復号を、同じ鍵(共通鍵)で行う。
・鍵の生成は誰がやる?
 ⇒データの送信者。受信者は、送信者から受け取った鍵を使って、暗号化されたデータを復号する。
・通信を傍受されて共通鍵を取得されると、悪意ある人にデータが復号されてしまう懸念がある。
・使用されるアルゴリズム: RC4、DES、3DES、AESなど


公開鍵暗号方式
・データの暗号化を「公開鍵」で、データの復号を「秘密鍵」で行う。
・鍵の生成は誰がやる?
 ⇒公開鍵、秘密鍵の生成ともに受信者が行う。
  ① 暗号化するための公開鍵と、復号のための秘密鍵を生成(受信者)
  ② 公開鍵を送信者に送信 (受信者)
  ③ 公開鍵でデータを暗号化 (送信者)
  ④ 暗号化したデータを送信 (送信者)
  ⑤ 秘密鍵で暗号化されたデータを復号 (受信者)
・データを復号できるのは、受信者が持っている秘密鍵のみ。
 ⇒万が一通信を傍受されて共通鍵が第三者に取得されたとしても、それでデータを復号することはできない。
 ⇒共通鍵暗号方式よりセキュア。
・使用されるアルゴリズム: RSAとElGamal

参考文献

www.infraexpert.com
www.atmarkit.co.jp

第7章:いつまで経っても変更作業が終わりません

はじめに

ソースコードの変更には時間がかかる。

  • 理解しにくいゴチャゴチャした構成になっている。
  • 「遅延時間」によりフィードバックを得るのに時間がかかる。

依存関係を排除してビルドの時間を短くし、フィードバックを早く得るための手法の紹介。
(依存関係を排除することで理解もしやすくなるだろうが、どちらかというと後者の「時間」という側面の記載のウェイトが多い印象)


「理解」という側面

何か変更を入れる必要が出たとして、変更に対する方法を見つけるにはある程度時間がかかる。
よくメンテされているコードに修正を入れるにしても、レガシーコードに修正を入れるにしても。

が、そこさえ分かれば、そのあとは前者を使う方が格段に速い。

  • 変更自体は簡単。
  • (書籍には書かれていないが)その変更が既存の動作に悪影響を及ぼしていないかの結果が分かる、という面もあると思っている。

後者の場合はそうはいかない。

  • 何をすべきか理解がかかるし、相手がレガシーコードなので変更も難しい。
  • 変更のために理解すべき範囲のカバーが十分にできない。


「小さく」「理解しやすく」「適切な名前の付いたパーツに分割された」システムでは、より速い作業が可能。
もし、そのプロジェクトで「コードの理解」という側面で問題があるのであれば、16章や17章が参考になるとのこと(本稿では割愛。というか、まだ読んでない)。

「時間」という側面

遅延時間
変更を行ってから、その結果を得るまでに経過する時間のこと。

インタプリタ言語(PerlとかRubyとか)でプログラミングをしている人は仕事の際にフィードバックをすぐに得ることができる。
が、コンパイル型言語で仕事をしている人にとってはそうはいかない。
ネックになるのは「コンパイルしたいもののために、関係のない部分までコンパイルしなければならなくなる依存関係」。


依存関係の排除
ビルドを簡単にするために、コードの構成を変更する方法の紹介。

例: 以下のように構成されるコードがあり、かつ、AddOpportunityFormHandlerに変更を加えたい。
ここで注目するのは、「①修正対象のAddOpportunityFormHandler」および「②(図には書かれていないが)AddOpportunityFormHandlerに依存しているクラス」の2つ。

修正前のコード構成
修正前のコード構成

着目点①:修正対象のAddOpportunityFormHandler
AddOpportunityFormHandlerのインスタンス化するときの問題点は以下の2つ。

  • 依存しているクラスはすべて具象クラス。
  • AddOpportunityFormHandlerをインスタンス化するときに芋づる式にいくつのクラスが呼び出されるのかは誰にもわからない。

これらの問題は、以下のようにすることで解決できる。

STEP1:ConsultantSchedulerDBへの依存を具象クラスではなくインタフェースに変更
STEP1:依存先を具象クラスからインタフェースに変更
STEP1:依存先を具象クラスからインタフェースに変更

  • ConsultantSchedulerDBインタフェースを実装した擬装オブジェクトでAddOpportunityFormHandlerオブジェクトを生成できる。
  • ConsultantSchedulerDBImplをいくら修正しても、AddOpportunityFormHandlerを再コンパイルする必要が無い。

⇒AddOpportunityFormHandlerはConsultantSchedulerDBImplに直接依存していないから。

⇒ AddOpportunityFormHandlerを再コンパイルする必要が出てくるのは、ConsultantSchedulerDBインタフェースに変更が入ったとき。

STEP2:OpportunityItemへの依存も具象クラスではなくインタフェースに変更
STEP2:依存先を具象クラスからインタフェースに変更
STEP2:依存先を具象クラスからインタフェースに変更

  • DB接続を責務にもつConsultantSchedulerDB(の実装クラス)とそれによって生成されるOpportunityItem(の実装クラス)への直接の依存がなくなることで、それらをいくら変更してもAddOpportunityFormHandlerを再コンパイルする必要が無くなる。

STEP3:パッケージ構造の変更
STEP3:パッケージ構成の変更
STEP3:パッケージ構成の変更

  • 1つのパッケージにまとめて入っていたクラスたちを、アプリケーション構造で明示的に表現する。


着目点②:修正対象のAddOpportunityFormHandlerを使うクラス
修正対象であるAddOpportunityFormHandlerを使うクラスの立場に立ってみると、以下のような解決すべき課題がある。

  • AddOpportunityFormHandlerに依存するコードのビルドも速くしたい。
  • AddOpportunityFormHandlerを修正するたびに再コンパイルしたくない。

これらの課題は、以下のようにすることで解決可能。

着目点②の課題を解決するためのコード構成
着目点②の課題を解決するためのコード構成
変更点は以下の2点。

  1. AddOpportunityFormHandlerを、何かしらのインタフェースの実装クラスにする。
  2. AddOpportunityFormHandlerに依存しているクラスは、そのインタフェースに依存するようにする。


依存関係の排除&コード構成を変更するメリット/デメリット
<メリット>
ビルド時間を早くすることができる。

  • 再ビルドとテストを素早く行うことができるようになると、開発の際に有益なフィードバックをたくさん得られる。
  • エラーが減少し、深刻な状況に陥らない。

<デメリット>
多くのインタフェースとパッケージを持つことによる概念的なオーバヘッドが発生する。

  • 妥当な代償。
  • 調査に時間はかかるだろうがトータルで見たら仕事は簡単になる。

ここでいう「概念的なオーバヘッド」は「今までと構成がどう変わったのかを調査したり理解する時間」だと思う。書籍には特に記載されていないが。


まとめ

依存関係がゴチャゴチャしているから理解もしにくいし、結果的に変更に時間がかかる。
依存関係がゴチャゴチャしているから遅延時間が多くなりフィードバックを得るのに時間がかかる、結果的に変更に時間がかかる。

なので具象クラスに依存するのではなくインタフェース(抽象)に依存させることで、それを解決しようぜ、という内容。


第6章のスプラウトやラップでは「とりあえず既存の処理のテストはせず放置。新規に追加修正を入れたところだけテストを書いてメンテする」という内容だった。
「修正箇所だけでなくそれを取り巻く大きなまとまりをメンテする(それができるようになる)」ためのヒントが7章で書かれていたのかな、という所感。


また、最初こそ時間はかかるかもしれないが、一度この仕組みを適用できれば、作業時間は劇的に変わることが書かれていた。
その「最初の一歩」をやるための時間をどうやって捻出するかが課題なのかなと思った。
(結局はプロジェクト次第?「その時間を結局捻出できませんでした。これまでもこれからも今のままいきます」になってしまうと、第7章で書かれていることも夢物語になってしまうと思った)


最後に、この章で述べられていることをひとことで言え、と言われたら「依存関係逆転の法則です」になる。
依存関係逆転の法則についてはググればたくさんでてくるので詳細はそちらで。
自分も「〇〇の法則」系については忘れかけている(忘れている)ところがあるので復習しておかないと・・・。