原子炉の損傷事故で溶けた燃料が浅い水のプールに落ちると、燃料の一部が多数の微小な液滴に分裂する可能性があることを、日本原子力研究開発機構などのグループが模擬実験で明らかにした。遠心力と重力が関与する2つのパターンがあった。液滴が固まって生じる燃料デブリの形成過程を理解することで、東京電力福島第一原子力発電所の廃炉における最重要課題である燃料デブリの取り出しに貢献できるとしている。
原子炉損傷事故で溶けた燃料が微小液滴に分裂、原子力機構など 燃料デブリの理解へ | Science Portal - 科学技術の最新情報サイト「サイエンスポータル」
2011年の東日本大震災による大津波で被災した福島第一原発では、炉心損傷で原子炉内の燃料が格納容器の底に溶け落ちた。底には水が浅く広がっていた可能性も考えられるが、溶融燃料が落ちた後の広がり方についての知見は少ない。水で冷えて固まる過程では、多数の液滴ができる場合や大きな固まりになる場合などが想定できる。東電は2024年11月と今年4月にデブリを試験的に取り出した。粒状のものが観察されているが、まだ全体像は分からない。
原子炉損傷事故で溶けた燃料が微小液滴に分裂、原子力機構など 燃料デブリの理解へ | Science Portal - 科学技術の最新情報サイト「サイエンスポータル」
⇧ 未だに「ブラックボックス」な部分が多いものを実運用しているのが恐ろしいですな...
試験の安全性は問題なく確保されているのか不安になりますな...
バイモーダルIT（Bimodal IT）という言葉とMode 1とMode 2との関係
先日、「SHIFT Agile FES (Agile Japan Satellite)」というカンファレンスに参加してきました。
その中で『KEYNOTE 3 トップエンジニアが語るDX最前線』というセッションで、
- 小野 和俊
- 山﨑 賢
のお二方のトークセッションの中で、
- バイモーダルIT（Bimodal IT）
- Mode 1
- Mode 2
の話が出て来て、初めて聞く言葉だったので備忘録として。
ネットの情報を漁っていたところ、
- モード1（守りのIT）は財務や受発注や製造管理などの基幹システムに代表される、SoR（System of Record）と呼ばれる記録型のシステムです。安定性と信頼性が重視されるデータ処理を担っています。
- モード2（攻めのIT）はビックデータのような膨大で流動性のある顧客接点に関わるデータを的確に捉えて分析し、新規ビジネスや情報価値を創造していきます。
⇧ 上記サイト様がまとめてくださっておりました。
ゲーム「ドラゴンクエスト」の「さくせんをねる」で例えるなら、
- Mode 1
- いのちだいじに
- Mode 2
ということになるのだろうか。
で、実際のところ、「DevOps」的に見た場合、
- Mode 1
- Mode 2
といった感じの傾向になりやすい気がしており、所謂、「トレードオフ」になる部分が多いと思われるので、「バイモーダルIT（Bimodal IT）」を実現するのは難易度が高いという話。
このあたりの話は、「ビジネス」が絡んでくるので、
『キャズム』（原題: Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers 「深淵を越えて: 主流顧客を対象としたハイテク製品の市場調査と販売」）は、ジェフリー・ムーアのハイテクマーケティングについての著書。1991年発売。ISBN 4798101524。
マーケティング手法の提案
新しい革新的なITを売り出す際のマーケティング手法を提案している（技術採用のライフサイクル）。
まず購買層を次のように分類する。
- イノベーター (innovators)
- 新しい技術が好きで、実用性よりも新技術が好きな人。オタク。
- アーリー・アドプター (early adopters)
- 新しい技術によって、競合相手などを出し抜きたいと思っている人々。
- アーリー・マジョリティー (early majority)
- 実用主義で役立つなら新しい技術でも取り入れたいと思っている人など。
- レート・マジョリティー (late majority)
- 新しい技術は苦手だがみんなが使っているなら自分も使わなければと思う人たち。
- ラガード (laggards)
- 新しい技術を嫌い、最後まで取り入れない人々。
それぞれの間に溝があり乗り越えなければならないが、特にアーリー・アドプターとアーリー・マジョリティーの間の大きな溝（キャズム）を乗り越えられるかどうかが、その製品が普及するか、一部の新製品マニアに支持されるにとどまるかどうかの一番の鍵である。
⇧ このあたりが影響してくると思われる。
「売上」に焦点を当てた場合、
⇧ 上図にあるように、「キャズム」を超えるまでは、兎にも角にも「システム」を可及的速やかに「リリース」したいので「Mode 2」路線が望ましいわけだ。
と言うのも、「経営層」からすると、兎にも角にも「売上」が「指標」となるわけなので、「売上」を向上させてくれる機会の発生頻度が高くなる可能性のありそうな「Mode 2」を優先させたくなるわけだ。
なのだが、何が「システム」の利用者の琴線に触れるのかは「不確実性」が高いこともあり、「下手な鉄砲も数撃てば当たる」という考え方に近いというのは「中らずと雖も遠からず」なので、「Mode 2」路線を選択したからといって必ずしも「売上」の向上が確約されるかというと、然にあらず。
一方、「エンジニア」からすると、「Mode 1」路線が魅力的なわけだ。
と言うのも、
図11は、初期母体量に対して毎年20%の追加・改変を行う場合の工数を、そのまま放置して母体構造が劣化していく場合と、リファクタリングによって母体量も１割程度低減して全体構造を良構造に保ち続けた場合の比較をCOCOMO型のコストモデルでシミュレーションしたものです。
初段ではリファクタリングの工数が上積みされますが、途中で逆転しますし、工数増大のカーブも前者が累乗的に増加するのに対し、逆のカーブで工数が爆発しないのが見てとれます。
https://www.zipc.com/jp/assets/download/watchers/vol10-04.pdf
⇧ 上記のPDFにあるように、「Mode 2」路線は「母体劣化」に繋がる可能性が高いということがあると思われる。
何も考えずに「ソフトウェア開発」を進めていくと、「機能追加」の度に工数が増大していく傾向になりがちなので「リファクタリング」が必要、というような話は、
■サンプルコードのプログラミング言語：JavaScript
あたりの書籍で触れられていた気がする。（記憶違いかもしれないが...）
もしかしたら、こちらの書籍で触れられていたのだったかも…
読んだのが昔なので朧気なのだが...
■アーキテクチャ関連
勿論、開発した「システム」に障害が起きたとしても全て対応してくれるスーパーエンジニアが面倒を見てくれる前提であるならば、「Mode 2」路線で進むのもありだとは思うのだが、まぁ、現実的に不可能な気はするので、
- バイモーダルIT（Bimodal IT）
- Mode 1
- Mode 2
⇧ の内「1. バイモーダルIT（Bimodal IT）」を選んだ場合は、どの領域のタスク（作業）で、
- Mode 1
- Mode 2
のどちらの方針で取り組むのかについて、線引きして、場合によっては妥協が必要になってきますと。（むしろ、妥協せざるを得ない方が多い気はするが...）
おそらく、スーパーエンジニアがいるのであれば、
- スーパーエンジニアがアプリケーションのたたき台を作成
- リリース手順を作成する（非スーパーエンジニアが作業）※1
- アプリケーションをリリース（非スーパーエンジニアが作業）※1
- リファクタリングの計画（非スーパーエンジニアが作業）※1
※1 アプリケーションの構成が、あまりにも難解であったり、複雑なフローのタスク（作業）になってきそうな場合は、スーパーエンジニアが作業する感じになる可能性がある。つまり、暗黙知の解消は後回しとなるので、引継ぎ作業で巻き取ることが困難になるリスクは高くなり得る。
と言った感じの開発フローになるんかね？
ただ、チームで、どの領域のタスク（作業）で、
- Mode 1
- Mode 2
のどちらの方針で取り組むのかの分類を「視える化」しておくべきな気はしますかね。
「WBS（Work Breakdown Structure）」で「タスク（作業）」を「MECE（Mutually Exclusive and Collectively Exhaustive）」に洗い出して、
- Mode 1
- Mode 2
のどちらで対応するのかを「可視化」しておかないと、複数人で「タスク（作業）」を分担している場合なんかは、確実に認識齟齬が発生しまくるのよな...
方針を決めてから、各々の「主体性」に任せるのは分かるのだが、何の方針も定めずに各々の「主体性」にお任せと言っておきながら、後出しじゃんけんで方針を訂正されるという不条理が多いのが、ITの世界なのよね...
「指示待ち」の問題は、どちらかというと、事前に方針を「ステークホルダー」同士で決めていないのが悪いのであって、「指示待ち」に苦しむ上司とかって情報については、むしろ加害者は上司になることが多いってことを自覚して欲しい気はする...
話が脱線しましたが、「バイモーダルIT（Bimodal IT）」を実現するには、チーム内で方針を「可視化」して整理しておくしか無い気はしますかね...
もし、何の方針も決めずに各々の自由にさせるっていうのであれば、問題が起きた際の責任は全てチームで共有してもらう必要がありそうですな...
とりあえず、「ソフトウェア開発」において、
のいずれで開発を進めるにしろ、「タスク（作業）」の全体的な方針を決めておいた方が良い気はする...
個人開発であれば、好き勝手にすれば良いのかもしれませんが...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
