世界時の決定などに関わる国際機関の国際地球回転・基準系事業(IERS)が、天文時間と原子時間のずれ修正を目的として例年6月末と12月末に行うかどうかが検討される「うるう秒」の挿入を、2026年12月末も行わないことを決定しました。
地球の自転をもとにした天文時間と、原子時計をもとにした原子時間にはごくわずかなズレが存在し、特定の1日だけ1秒加えてズレを修正する「うるう秒」の挿入が行われます。「うるう秒」は挿入する場合は協定世界時の6月末か12月末と決められていて、日本時間だと翌日の8時59分60秒がうるう秒にあたります。
しかし、不規則に1秒追加されることで時間に不連続性が生じていることや、正確な時刻が必要とされるシステムで問題を引き起こす恐れがあることなどから、廃止を提唱する声があり、2022年に行われた国際度量衡総会で「2035年までにうるう秒を廃止する」ことが決定しています。
最後に「うるう秒」が挿入されたのは2016年12月末(日本時間で2017年1月1日8時59分60秒のもの)なので、今回の決定により、まる10年間「うるう秒」なしが確定したことになります。
ちなみに、地球の自転速度は変化していて、近年はむしろ加速傾向がみられ、2029年までに「負のうるう秒」が必要となる可能性が大きいという計算結果が報告されています。
⇧ とりあえず、
- 地球の自転をもとにした天文時間
- 原子時計をもとにした原子時間
が混在した「システム」ないしは「データ」を扱う「ケース」において問題になるということだと思われますが、
1秒増えようが減ろうが大したことではないようにも思えますが、原子時計が刻む正確な時間によって動いている現代社会への影響は甚大で、2012年のうるう秒ではオーストラリアのカンタス航空や掲示板型ソーシャルニュースサイトのReddit、Linuxで動作しているサーバーシステムなどで障害が発生しました。
地球の自転が速くなっているため2029年までに「負のうるう秒」が必要になる可能性大、ネットやITサービスが大混乱になる危険性も - GIGAZINE
⇧ 上記によりますと、一般的な「業務システム」においても問題が起きた事例があるそうな...
業務フローに関するタスクを把握するにはWBS（Work Breakdown Structure）的な整理が重要よね...
とあるセミナーを傾聴して、「医療」の「手術」の話が興味深かったので備忘録として。
常々、「激務」という「医療現場」において、「人手不足」もあり何かにつけて時間が取れないですと。
そして、「手術」については、
- 経験できる機会
- 優れたノウハウを連携される機会
が、安定していないらしい。
何となく、そんな気はしていたのだが、「手術」の「ノウハウ」が後人に伝承されるかどうかは綱渡り状態であることが事実であると、改めて認識させられると、「偶然」に感謝するしかない...
とは言え、「手術」の「ノウハウ」が途絶える可能性があるという「リスク」を抱えた状況は、宜しくない...
で、
⇧ 上記のように、「手術」をする「術者」の「暗黙知」になってしまっている部分を「形式知化」するための「フレームワーク」が作られたらしい。
何かに似ているなと思ったのだが、
Work Breakdown Structure (WBS、作業分解構造)は、プロジェクトを理解し管理する上で、プロジェクトの各工程を各担当者の作業レベルまで展開し木構造にまとめたもの。どのレベルまで展開するかはプロジェクトの全メンバーが作業内容を「具体的に○○をする」と理解出来るレベルまでに分解するのが理想であるが、最低でも作業担当者とプロジェクト管理者の理解が得られるレベルまでは必要である。
⇧ 上記の「目的」と狙いが近いと思われる。
ただ、「手術」は、正確な「手順」を実施しないと「人命」に影響するので、非常に厳密に「抜け漏れ」が無い「手順」を「可視化」する必要があることから、
MECE（ミーシー (Mee-cee); 英語: Mutually Exclusive, Collectively Exhaustive）とは、「相互に排他的な項目」による「完全な全体集合」を意味する頭字語である。要するに「漏れなく・ダブりなく」という意味で、経営学や経営コンサルティングなどの領域でよく使われる言葉である。アメリカ合衆国の戦略系コンサルティング会社マッキンゼー・アンド・カンパニーに所属していたバーバラ・ミントによって開発された概念であり、ロジカルシンキング (論理的思考) の一手法として用いられている
⇧ 上記のように、
- 漏れが無い
- ダブりが無い
- 無駄が無い
といった整理ができている必要がある。
まぁ、昨今の「ソフトウェア開発」で「アジャイル開発」的な「開発手法」を採用している場合については、「作業分解構造（WBS：Work Breakdown Structure）」を不要とすることが多いと思われるのだが、「作業分解構造（WBS：Work Breakdown Structure）」的な整理で「タスク」を洗い出す必要はある気はするのよね...
結局のところ、「タスク」の「全量」を「可視化」してみないことには、「タスク」の「過不足」が検証できないですしな...
あと、「可視化」していないと、複数人で「業務」に従事している場合に「認識齟齬」が生じることになりますしな...
こればっかりは、「人間」の「認知」が何某かの「バイアス」の影響を回避することが不可能という構造上、
語句
⇧ 上記のような「進化」が「人類」に起きない限りにおいて、避けることはできないと思いますしな...
話が脱線しましたが、「医療」の「手術」の場合は、
- 患者の属性
- 持病はあるのか
- 年齢
- 性別
- 体格
- 健康状態
- 執刀者の属性
- 知識量
- 経験
- 技量
- 体力
- 集中力
- チームワーク
などによって、最適な「術式」の「在り方」が変わって来るはずなので、「情報」の整理の難易度が高い気はする...
まぁ、「ソフトウェア開発」自体も「業務フロー」が「ファジー」な状態になっているので、
『我々は「雰囲気」で「ソフトウェア開発」をしている』
から脱却することが無い状況ではあるのだが、「医療」の「手術」という「領域」においては、「ノウハウ」を「共有」する体制を確立して行って欲しいお気持ち...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
