  |
はてなキーワード: コストとは
### **誤りの指摘と補足**
#### **誤りの指摘**
#### **補足情報**
1. **無筋** であるため中性化による鉄筋腐食の問題がない。
2. **海水と反応して新たな結晶（アルミノシリケート鉱物）を生成し、長期的に強度を保つ** ため。
3. **高い耐久性を持つが、引張強度が低いため構造デザイン（アーチやドーム）が工夫されていた。**
2. **寒冷地ではアスファルトの方が補修しやすい（凍結融解に伴う損傷を迅速に修復可能）。**
3. **車両の走行性（タイヤのグリップ性や振動吸収特性）がアスファルトの方が優れている。**
4. **コンクリート舗装は白色で、夏場の路面温度がアスファルトより高くなりやすい（ヒートアイランド対策として不向き）。**
- 高流動コンクリートや超高強度コンクリートは、材料費や施工費が高くなりがち。
- 一般建築では、標準的なコンクリートの方がコストパフォーマンスが良い。
- 環境負荷の低い代替材料（例：フライアッシュやスラグ）の活用が進められているが、安定供給の問題もある。
- 放射性廃棄物の保管施設など、長寿命を求める用途では鉄筋を使用しないコンクリートが検討されている。
- 微生物や化学反応を利用し、ひび割れを自動修復する技術が開発されつつある。
### **総評**
ウクライナ全土がロシア領となった場合、ウクライナにある資源の全てがロシアの管理下に置かれることになる
この場合、ウクライナ資源の利権の分配は完全にロシア主導で行われることになるから、アメリカはその利権を対価として注ぎ込んできたウクライナ支援の諸々がプーチンの気分次第で全てパーとなる
であるので、アメリカ政府がウクライナ支援を完全に停止した場合、ゼレンスキーは自分の身の安全を条件にロシアに全面降伏してウクライナ国を消滅させることでアメリカに意趣返しができるかもしれない
アメリカはウクライナに、アメリカにとって必要な分だけ領土を保有し、かつロシアとは独立した国として存続してもらう必要がある
しかし相手がロシアである以上、ウクライナに存続してもらうには結局、軍事支援をする必要が出てくるので、そうなった場合、ロシアはウクライナを脅かすことでアメリカに経済的負担を強いることができるようになる
アメリカはその負担をNATOに肩代わりさせる算段なのだろうけど、その場合、EU加盟国をウクライナ利権から爪弾きにすればNATOがウクライナから引いてしまい、アメリカばかりかヨーロッパの庇護を失ったウクライナはロシアに再侵攻されて、最悪の場合アメリカはウクライナ利権を全て失うことになるから、ウクライナ利権についてはEU加盟国の取り分も確保する必要が出てきて、かくして保全すべきウクライナ領土は大きくなっていき軍事支援のコストもかさんでいくからEUも面倒を見切れなくなって結局ウクライナから手を引いてしまうかもしれないから、アメリカはウクライナ支援をNATOに完全に肩代わりさせることができない
ウクライナ利権にこだわる限りどう足掻いてもアメリカはロシアに振り回され続けることになるのだから、もしアメリカにロシアと敵対するつもりがなく世界の警察を務める気もないなら、これまでのウクライナ支援はサンクコストと割り切ってウクライナ利権をすっぱり諦めるのが一番賢いということになるような気がする
コンクリート工学修めてこの説明かぁ・・・うーん残念、かなり大学での成績悪そう、と煽ってみる。
「具体的な」なんて意味ももってる。この意味での対義語はアブストラクト（抽象的な）。
でも元の意味は、「液体が固まったもの」。対義語はmeltedかな。
だからアスファルトも豆腐も氷も、広義のコンクリートに入っちゃう。
ただし以下ではコンクリートを、日本で一般的な使い方、つまりセメントコンクリートの意で用いることにするぜ。
業界ではコンと略されることが多く、一般では年配にコンクリと略す人が多いな。
鉄筋コンクリートは、リーンフォースド（強化した）コンクリートでRCと略す。
(2) 引っ張りに強く圧縮に弱い鉄筋と、圧縮に強く引っ張りに弱いコンクリートが、力学的に補い合うから。
(3) 酸性になると酸化腐食しやすい鉄筋を、塩基性のコンクリートが、長期間にわたって化学的に保護してくれるから。
しかし中性になったコンクリートは、鉄筋との好相性のうち (2) (3)が逆転する。
水と空気で錆びた鉄筋は、錆びた分の体積増加で爆裂し、コンクリートを内側から壊し始める。
どこのコンクリート工学の教科書にも少なくともこの３点が併記で書いてあるはずだぞ。
4点目に材料の安価さや自由な可塑性を上げる場合もあるが、最低この3点から始めないとな。
惜しいけどここも減点・・・
1
2
1と2は機序が逆。
塩基性で保護されているうちは水や空気が浸入しても腐食や爆裂は起きない。
だから、コンクリートの寿命は、最初の打設時にまともに造られてさえあれば、あとは「メンテのマメさ」と「中性化」で決まる。
表面仕上げ（タイルや塗料など。打ち放しコンクリートに見えても透明な撥水材が塗ってある）の再施工、ひび割れ補修、そもそも超過荷重や繰り返し応力に晒されないよう管理、など。
ひび割れがあると奥まで早くCO2が侵入して塩基性が失われていく。一番外側の鉄筋の外にどれだけコンクリートがかぶっているか（かぶり厚）がポイント。かぶり厚が大きすぎてもひび割れやすい。
中性化したコンクリートを元に戻すには、電気的に戻すにせよ薬剤で戻すにせよ、とんでもないコストがかかるので、再築できない文化財などにしか使えない。
よって中性化は、実質的に不可逆な劣化。これがコンクリート建物の寿命を決定する。
減価償却費を計算するために用いる財務省令での耐用年数は、鉄筋コンクリート住宅で47年。
施工ミスが少なく、メンテがマメで、海岸沿いでなければ、基本的に鉄筋コンクリート造建物は150年使える。
これが真の耐用年数。
証拠を挙げよう。
国の研究機関である建設技術研究所、によるBCJ技研レポート第６号2024
https://www.bcj.or.jp/news/detail/363/
注目は第5ページ。
web上で公開されていない本書の方含めて要約すると、
・平均築年数49.2 年、過半数が築50 年超の既存RC 造建築物200 棟を診断した結果、現時点での「残存耐用年数」が100年を超えると評価されたものが全体の59％を占めた。
・すなわち、既存RC 造の約6 割は築後150 年はもつということが示された。
・古いRC造より、むしろモルタル仕上げしていない（乾式や撥水材仕上げなどの）近年のRC造の方が中性化の進行が早い。
ということ。これは、
・中性化の速度は時間の1/2乗に比例する。
・たとえば築50年の既存建築物で中性化が10mm進行していたなら、適切な管理を続ける限り中性化はその後50年間で3mm未満（最初の50年間の3割未満）しか進まない。
といった知見を積み重ねた結果見えてきたもの。
すでに新築では100年コンクリート、200年コンクリートを目指すようになりつつあるが、昔に造られたRC建築物でも、真面目に造ってあって、ずっとちゃんとメンテしてれば築150年は目指せるのだ。
三田の変なビル造った人が、普通は50年だがこのビルのコンクリートは200年持つ！とか自分で騒いでるけど、工学的には別に何も大したことしてない。
古代ローマのコンクリートは化学反応が少し違うが、そこは寿命を決める上で大きな差ではない。
ローマンコンクリートは無筋。鉄筋が入っていない。だから中性化したとしても大きな欠陥にはならない。
ただし最初に書いたようにコンクリートだけでは引っ張りに弱い。
だからローマの構造物は、すべての部分が圧縮だけで構造が成立するように、アーチ状にかけたり、ドーム状にしたり、壁をとてつもなく分厚く、柱を太くしてある。
ダムが上から見るとアーチ状になってるのは古代ローマの遺跡と同じ理屈なんだよ。
鉄筋コンクリートの発明は、薄くて軽くて引っ張りや曲げにも強い構造を可能にした。
しかし、逆に言うと1000年単位での寿命を諦めて、せいぜい150年～200年くらいの寿命にすることで実現したんだ。
ダムや、1000年持たせたいモニュメントや、100000年持たせなきゃいけない放射性廃棄物保管庫には、鉄筋コンクリートは向かない。
施工期間が、アスファルト（＝アスコン）の方が短いから、安いからだと元増田は書いてるが、他にもいろんな観点がある。
アメリカの都市部では、コンクリート（＝セメントコンクリート）で路面を造ることが多い。
高コストで採用されない高流動コンクリートの話があったが、そもそも鉄筋コンクリート自体も発明当初は高コストで嫌われて使われなかった。
特許が切れて技術が枯れて、おかげで今の低廉で入手しやすいコンクリートがある。
前にバズってたように、環境負荷の大きい生コンプラントが、常にどの地区にもある現在の状態が、いつまで維持できるかね・・・。
他にも超高強度コンクリートなど、コンクリート工学の発明は多い。
鉄筋の代わりに、化学的に安定なガラスなどの繊維を混ぜたコンクリートなんか、とてつもない強度になるし、やり方によっては鉄筋必要ない。
しかしその中でコストダウンにまで漕ぎつけられるものは少ない。
胚乳の部分だけ作れば白米替わりには十分だし
オフィスには無料のコーヒーマシンがあり、無限にコーヒーが飲める。
前職ではコンビニで毎日100円以上のコーヒーを買っていたけど、それが完全になくなった。
さらに、自販機の飲み物も微妙に安い。たかが数十円と思うかもしれないが、積もればタダのコーヒーと合わせて「実質給料アップ」感がすごい。
会社が入ってるビルの飲食店で割引が受けられる。特に感動したのが、昔から利用してたチェーン店の昼食が数十円安くなること。
塵も積もれば……ってやつで、1年続ければ数千円は浮く計算。
今まで「今日はちょっと節約するか」と思ってたあの努力、無意味だったかも？
家電量販店の割引、映画の割引券、その他もろもろの優待が使える。特に家電系の割引は助かる。
前職ではポイント駆使して必死に安く買おうとしてたけど、大企業にいるだけでそれが標準装備になるのは衝撃的だった。
たまに携帯会社やオフィス用品メーカーから「社員全員どうぞ！」ってクーポンが配られる。
え、こんなの普通の人はもらえないの？ っていう格差を感じる瞬間。
数万円する講座とかも「いけいけ！自己研鑽しろ！」って感じで補助される。
まあ税金がちょっとかかるんだけど、それでもほぼタダ。スキルアップにお金をかけなくて済むのはデカい。
大企業にいるだけで、今まで細かく節約してた出費が軒並みゼロになった。
これまで「節約しなきゃ……！」と頑張ってたのが馬鹿らしくなるレベル。こういうのを「富の再分配」って言うんですか？
無理解な経営陣の「短期開発」が生んだ、ダイハツ64車種の不正
https://monoist.itmedia.co.jp/mn/articles/2312/21/news094.html
不正行為が発生した直接的な原因は、過度にタイトで硬直的な開発スケジュールによる極度のプレッシャーであるという。
開発期間を短縮する「短期開発」によって発生する負荷やその悪影響を考慮せずに、短期開発を推進し続けた経営幹部の責任は重いと第三者委員会は指摘した。
短期開発がダイハツの存在意義として開発部門の組織内に根付いた結果、開発の各工程が全て問題なく進むという想定の下で、問題が生じた場合に対応する余裕を全く織り込まずにスケジュールが組まれるようになった。
その結果、開発期間の延長は販売日程に影響を及ぼすため問題に対して柔軟に対応することが困難だったと第三者委員会は分析した。
デザインの決定などに時間を要したり、設計変更で後工程に影響を与えたりした結果、最終工程である認証試験にしわ寄せされたとしている。
さらに、担当部署以外では「認証試験は合格して当たり前」「不合格になってスケジュールを変更することは到底あり得ない」という考えが強かった。
衝突安全試験の担当者は、コスト削減で使用できる試験車両に制限がある中で一発合格への強烈なプレッシャーにさらされながら業務を行っていたと第三者委員会は指摘した。
その結果、「認証申請書類に虚偽の情報や不正確な情報を記載してはならない」という当たり前の感覚が失われていったとしている。
2024年に発生した「ラーメン店」経営事業者の倒産（負債1000万円以上、法的整理）は72件にのぼった
原材料コストなどが高騰する一方、「ラーメン1杯＝千円の壁」に代表される価格転嫁の難しさで板挟みとなり、閉店を余儀なくされたケースが多くみられた。
ラーメン価格は値上げが続くものの全国平均700円を下回る水準が続いている。安い日常食のイメージがなお根強く、トッピングなしで1杯あたり1000円を超えると客足が遠のくといわれるほど「適正価格」の形成が難しいことも、利益確保が年々困難化する要因となっている。
今この文章は、ジャンクで買ったThinkPad X250で書いている。5000円だ。キーボードはガタガタで、一部のキーは反応しない。でも、それで困るか？いや、困らん。なぜなら、ThinkPadは修理できるからだ。
お前たちがありがたがってるiPhoneはどうだ？バッテリーがヘタったら修理費1万超え、ストレージが足りなくなったら買い替え。画面が割れたら修理に2万、下手すりゃ5万。そもそも、裏蓋すら開けられない時点で、お前たちのiPhoneはただの「使い捨てガジェット」だ。
それでも、お前たちは毎年のように最新のiPhoneを買う。「みんなが持ってるから」「なんとなく新しいのがほしいから」「買い替え時だから」。それ、お前たちの意思か？考えた末の選択か？
iPhoneを買うことは、みんなが飼っているから、という理由で芝犬を飼うようなものだ。 みんなが持ってるから安心、みんなが使ってるから問題ない、だから自分も。そこにあるのは思考停止だけだ。スマホは道具のはずなのに、お前たちはそれを選ぶことすら、周りに流されている。
ThinkPadは違う。キーボードが壊れたら？交換できる。バッテリーが死んだら？換装できる。SSDやRAMが足りなきゃ？増設できる。iPhoneのように「寿命が来たら買い替え」なんて思考は存在しない。自分で直し、強化し、最適な環境を作る。これこそが、ThinkPadを使う者の流儀だ。
しかも、コストの話をしようか？お前たちが持ってるiPhone、15万、20万。それでやることは？Twitter、YouTube、インスタ、メルカリ。それなら最新iPhoneを買う金で、40台のThinkPadが買えるぞ？ 40台あったら、スペアを20台持っても、さらに20台は砦を築けるぞ？
ThinkPadは、ただのノートPCじゃない。直せる道具、拡張できるツール、そして作業をするためのマシンだ。
iPhoneは違う。お前たちは、ただ画面をスワイプし、情報を消費し、広告を見せられ、気づけば時間を溶かしているだけ。
お前たちはどっちを選ぶ？
少子化の理由はシンプルで、子供を産まなくても女が生きていけるようになったから。だったら産まないという女が増えただけ。
少子化対策のためにどれだけ金をつぎ込んでも子育て環境をよくしても無駄。上手くいってる国はない。
だから子供を産ませたいのなら、子供を産まないなら死ぬ環境を作らないといけない。
まずは子供を産まない女の社会保障受給権をすべて停止する。年金、介護保険、健康保険を全部やめれば死ぬしかなくなるし、無駄な公金が浮く。
次に、子供を産まない女を反社として扱う。暴対法のように、経済的取引を全部違法とする。家も借りられない、被雇用もできない、事業もできないようにする。
社会を破壊する行為を行っているのだから暴力団員と何も変わらない。当然社会から排除されるべき。
日本保守党が、30歳になったら子宮摘出せよと言って炎上したが、これは少し言葉足らずだった。もっと詳細を詰めれば真っ当なことを言っている。
摘出手術には医療リソースも金もかかるので、病院で摘出させるのは少子化対策としては合理的ではない。
しかも医者が健康な子宮を摘出することは医師倫理に反するので不可能だ。
簡単なことだ。未出産女性の子宮に高額税を掛ければよい。年間1000万程度でいいだろう。
当然そんな高額な税金は払えないので、免れるためには子供を産むか子宮を摘出するしかない。
医者は税金逃れのための違法手術はできず、自身で子宮を取ることになる。当然死ぬだろう。
社会がコストを払うことなく無駄な人間を排除することができる。
死ぬか産むか。真剣な選択を突きつけなければ少子化は止まらない。
1990年代半ば、九州大学病院（九大病院）は病院情報システムの全面刷新を計画していた。従来の断片化したシステムを統合し、最先端のオブジェクト指向技術を全面採用した次世代システムに生まれ変わらせるという大胆な構想である
tumblr.com
。入札条件にも「純粋なオブジェクト指向技術で実現すること」を掲げ、業界内でも前例の少ない大規模プロジェクトに挑むことになった
tumblr.com
。この計画に応札した日本IBMは、開発言語にSmalltalkを採用し、社内外からオブジェクト指向開発の専門家を総動員する。日本IBM自身のチームに加え、Smalltalkの豊富な経験を持つ多数のシステムインテグレータ各社が協力企業として参画し、一時期は約200名もの技術者が開発に従事する巨大プロジェクトとなった
tumblr.com
。医療現場からは「21世紀を先取りするシステムになる」という期待の声が上がり、IBM側も「国内最高峰の病院に最新技術を投入できる」と意気込んでいた。誰もが、この試みに大きな希望を抱いていたのである。
プロジェクトは1996年、本格的に動き始めた。九大病院の情報システム担当者たちは、院内各部門から新システムへの要望をヒアリングし、「新システムへの要望リスト」を作成して日本IBMに提示した。しかし、その内容は具体性に欠けていたと言われる。「実現したい業務の全体像がはっきりしていなかった」のだ。病院側は約1,400床を擁するマンモス病院ゆえ、部門ごとの意見をまとめ上げ全体方針を打ち出すことが難しく、提出された要件定義書は「中身はほとんどなかった」と関係者は振り返る。一方の日本IBMも、その不十分な要件定義を十分詰め直すことなく開発を進めようとし、この問題を放置してしまった。プロジェクト序盤から、実は大きな不安の種が芽生えていたのである。
それでも当初の計画は極めて野心的だった。フェーズごとに順次システムを稼働させる計画で、第1次カットオーバー（最初の稼働開始）は1997年1月と定められていた
tumblr.com
。限られた時間の中、日本IBMと協力各社の開発チームはオブジェクト指向の新手法に挑みつつ、多数のサブシステムを並行開発するという難事業に取り組み始めた。しかし要件の曖昧さは各所で影響を及ぼす。開発メンバーの一人は後に「実際にはオブジェクト指向の入り口にさえたどり着けなかった」と語っており、肝心の新技術を活かす以前に基本事項の詰め直しに追われる状況だったという。
1997年初頭：見えてきた遅れとすれ違う思惑
年が明けて1997年になると、第1次稼働予定の目前になっても開発は難航していた。結局、日本IBMは1996年10月末になって九大病院側に「当初予定の1997年1月にはシステム稼働が間に合わない」と突然伝えることになる。これは病院側にとって青天の霹靂であった。代替策として「一部機能に範囲を絞れば1月稼働も可能」といった提案すら無く、一方的に延期が告げられたことに、病院担当者たちは強い不信感を抱いたという。プロジェクト・マネージャー同士の密なコミュニケーションも欠如しており、延期決定前から両者の意思疎通は十分でなかったようだ。これが最初の綻びとなった。第1次稼働時期は当初計画より9カ月遅れの1997年10月へと大幅に後退する
tumblr.com
。
この延期表明を境に、現場は混乱に陥る。病院側は日本IBMだけに任せておけないとの思いから、一部の協力会社と直接組んで独自にプロトタイプ開発に乗り出すなど、プロジェクト体制は分裂気味になった。一方、日本IBM側の士気も下がり始める。ある協力会社メンバーは「これほど求心力のないプロジェクトも珍しい」と当時を振り返り、リーダーシップ不足だったIBMの姿勢に驚いている。複数の外部企業（延べ10社以上）が関与する巨大プロジェクトでありながら、日本IBMは1997年10月頃まで一貫して主導権を握れずにいた、と多くの関係者が指摘する。誰がハンドルを取っているのかわからないまま巨艦だけが突き進む――そんな不安定な状況であった。
事態を重く見た九大病院と日本IBMは、1997年2月から6月にかけて要件定義のやり直しに着手する。一度作成した要件定義書を更地に戻し、業務フローも含めてゼロから整理し直す作業だ。しかしこのリカバリーにも時間を要し、プロジェクトの遅延はさらに広がっていった。「ようやく問題点に光を当て始めたかに見えたが、時すでに遅し。気づけば頭上に厚い雲が垂れ込めていた」と語る関係者もいる
。プロジェクトは先の見えないトンネルに入り込み、関係者の心にも次第に不安が募っていった。
1997年春：一筋の光明 – オブジェクト指向データベースの導入
混迷を極めるプロジェクトに光が差し込んだのは、1997年春のことである。要件定義の立て直しと並行して、日本IBMはシステムの技術基盤を強化すべく重大な決断を下した。従来のリレーショナルDBではなく、米国GemStone Systems社のオブジェクト指向データベース（ODB）「GemStone」を採用する方針を固めたのだ
tumblr.com
。GemStoneはSmalltalkとの相性が良いことで知られ、オブジェクト指向開発との親和性が高い製品である
tumblr.com
。この採用決定に伴い、GemStone社から複数名のコンサルタントが来日しプロジェクトに参加。停滞していた開発体制の再整備が行われた
tumblr.com
。経験豊富な専門家の助言により設計も見直され、チームはようやく開発の目処を掴み始めたのである
tumblr.com
。
病院側もこの動きを歓迎した。長引く遅延に業を煮やしていたものの、最新のODB導入で性能や拡張性の課題が解決されるならばと期待を寄せた。協力各社の技術者たちも「ようやくトンネルの先に光が見えた」と胸をなでおろした
。現場には久々に前向きな空気が漂う。遅れを取り戻すべく、再結集した開発チームはスパートをかけた。システム全体のアーキテクチャをGemStone前提に再設計し、失われた時間を埋めるため懸命な努力が続けられる。巨大プロジェクトは今、再び軌道に乗ろうとしていたかに見えた。
しかし、その光は長くは続かなかった。1997年7月初旬、プロジェクトに再び試練が訪れる。日本IBMとGemStone社との契約交渉が突如決裂し、参画していたGemStone社コンサルタント陣が全員帰国してしまったのだ。肝心のGemStone製品も利用不能となり、頼みの綱を断たれた開発チームは一瞬にして暗闇に放り込まれた。まさに「悪夢のような出来事」であった。
7月20日になって、日本IBMはようやく協力各社を集め緊急説明会を開いた。日本IBM側の説明によれば、「GemStoneとの交渉決裂は企業（日本IBM）の根幹に関わる問題による」という。詳しい理由として、契約書の条項に**「システムのユーザー等が何らかの理由でGemStone社を訴えた場合、メイン・コントラクタである日本IBMが全ての法的対応を負わねばならない」といった内容が盛り込まれており、日本IBMはこの重い責任リスクを受け入れられなかったのだという。さらに料金面でも折り合わず、3カ月間におよぶコンサルタント8名の派遣とソフトライセンス料などに数億円近い費用**を要求されたことも判明した。法的リスクとコスト高騰――企業として譲れぬ一線を越える契約条件に、日本IBMは最終的に「ノー」を突きつけた形だ。だが、それは即ちプロジェクトの生命線を断つことを意味していた。
この報に接した開発現場は騒然となった。GemStoneを中核に据えて進めてきたアーキテクチャ設計を一から練り直す必要が生じたためである。ある協力会社の関係者は「この時点でプロジェクトの失敗を覚悟した」とまで語っている。大黒柱を失ったチームには動揺と失望が広がった。折しも夏本番を迎え、福岡の空は照りつける日差しに覆われていたが、プロジェクトには再び厚い雲が垂れ込め始めた。
GemStone脱落という非常事態に対し、日本IBMと九大病院は必死のリカバリーを図る。1997年8月上旬、急遽代替のODB製品としてフランスA.D.B社の「Matisse」を採用する決断が下された。Matisseは国内では知名度の低いODBだが、日本でも過去にSmalltalkアプリケーションのデータベースに採用された実績があり、「何とか使えるめどは立つ」と判断されたのである。
しかし代替品とはいえGemStoneとMatisseでは機能に大きな違いがあった。GemStoneで可能だったサーバ側でのSmalltalk処理実行がMatisseではできず、セキュリティ機能も貧弱だったため、開発チームは不足分を自前で作り込む必要に迫られた。この結果、システム全体の設計をクライアント中心処理へ大幅に変更せざるを得なくなり、再び設計の手戻り作業が発生した。炎天下での再出発である。エンジニアたちは寝食を忘れ、懸命にコードを書き直した。
その甲斐あってか、1997年9月末の時点で第1次開発の主要部分を年内に実現できる見通しが立ったという。一度は暗転したプロジェクトにも、わずかながら光明が見えた。病院側も「何としても年内稼働を」という思いで支援を続ける。だが、このとき水面下では別の動きが進んでいたことを、現場の多くは知らなかった。
1997年10月9日、事態は最終局面を迎えた。この日開かれた会議で、日本IBMはSmalltalkによる開発断念と、マイクロソフト社のVisual Basic（VB）への全面的な方針転換を突如宣言したのである。晴天の霹靂とも言えるこの決断に、現場は凍りついた。幾多の苦難を乗り越えようやく目指してきた最先端技術での構築を諦め、当時広く普及していたVBという「オブジェクト指向ではない」開発ツールで作り直すというのだ。九大病院が当初求めた**「純粋なオブジェクト指向」**という条件にVBが合致するかは議論の分かれるところだが
tumblr.com
、病院側ももはや背に腹は代えられない。最優先すべきはシステム稼働そのもの――この苦渋の転換を受け入れる以外になかった。
実はこの決断に至る伏線は存在した。日本IBMは1997年4月頃から密かにVB採用の可能性を九大病院に打診しており、さらに8月頃からは段階的にSmalltalk担当エンジニアを現場から引き上げ始めていたという。ある協力会社のメンバーは「裏ではVBによる開発をすでに進めていたようだ」と振り返っている。つまりGemStone交渉決裂後、表向きはMatisseによる巻き返しを図る一方で、日本IBM本体は別動隊でVB版システムの構築に乗り出していた可能性が高い。振り返れば、日本IBMにはSmalltalkに固執しない理由もあった。同社は翌98年2月の長野冬季オリンピック向けシステムをSmalltalkで構築しようとして失敗し、結局VBで作り直したという“前歴”もあったと伝えられる。アトランタ五輪（1996年）では自社Smalltalkツール（VisualAge）を投入したものの、国内の大型案件では苦戦が続いた経緯があった＊4。豊富な人材がいるVBなら「最後は人海戦術で何とかできる」という計算も働いたようだ。GemStoneとの契約不成立も、IBMにとっては結果的にSmalltalkを断念する良い口実になったのではないか――協力会社メンバーの一人はそんな憶測さえ口にする。
方針転換の発表とほぼ同時に、Smalltalkで開発を担っていた協力会社の大部分はプロジェクトから撤退することになった
tumblr.com
。10月中旬には、多くの外部技術者が病院を後にしている。自ら招いた転換とはいえ、日本IBMにとっても苦渋の決断であった。投入したリソース・費用は莫大で、一からVBで開発し直すのは会社としても大きな後退だ。しかし背に腹は代えられない状況まで追い詰められていたことも事実であろう。IBMの現場責任者は病院側に深々と頭を下げ、「必ずや残された方法で間に合わせます」と約束したという。九大病院の担当者も沈痛な面持ちで頷き、「形はどうあれ、患者さんに影響を及ぼす前にシステムを動かしてほしい」と絞り出すように告げた。
以降、日本IBMは自社内のVB技術者や、自社が持つ病院向けオーダリングシステムのパッケージ製品＊5などを総動員してシステム構築を続行した
tumblr.com
。データベースも、当初IBMが提案していながら見送っていた自社のリレーショナルDB「DB2」を採用する公算が高まった
tumblr.com
tumblr.com
。もはやオブジェクト指向の夢を追う余裕はない。現実的かつ確実に動く仕組みを、一刻も早く届ける――プロジェクトはその一点に向け再編成された。かつて200名近くいた開発陣は大幅に縮小され、構成メンバーも一変する。病院の看護師スケジュール管理など一部のサブシステムは、撤退しなかった協力会社が細々とSmalltalk開発を続けていたが、その姿はもはや主流から外れた存在となっていった
tumblr.com
。ある古参の協力技術者は去り際に「全力を出して戦う前に、白旗を上げてしまったという感じがする」と寂しげに語ったという。こうして九大病院プロジェクトの第1フェーズ――オブジェクト指向技術による野心的挑戦のフェーズは幕を下ろしたのであった。
VBへの方針転換後、九大病院の現場には複雑な空気が流れていた。病院スタッフにとってシステム刷新は長らく待ち望んだ悲願だったが、その中身は当初聞いていた「最新技術の結晶」から一転して、従来型の技術で作られるものになってしまった。「結局、夢物語に終わったのか」という落胆の声も一部にはあった。しかし同時に、「多少古くてもいい、とにかく業務を改善する仕組みを早く動かしてほしい」という切実な声も強まっていた。目指すゴールは変われど、一日でも早く新システムを稼働させ、慢性的な業務負荷を軽減することが現場の切実な願いとなったのだ。プロジェクトチームは日夜作業を続け、簡易な操作研修なども始めながら、年明けまでの稼働に向け突き進んだ。
そんな中、1997年11月3日付の西日本新聞朝刊一面にこのプロジェクトに関する記事が掲載される。タイトルは「九大病院システム未完 巨額費用に批判」。内容は「九大病院はシステムが未完成にもかかわらず日本IBMに月額4,250万円を支払い続けており、税金の無駄遣いとの指摘が出ている」という衝撃的なものだった。同日、このニュースは地元RKB毎日放送（東京ではTBS）のテレビニュースでも報じられ、九大病院プロジェクトは社会問題として一気に世間の注目を浴びることとなった。院内では「患者そっちのけで何をしているのか」といった批判も耳に入るようになり、大学本部や所管官庁からの問い合わせも相次いだ。追い打ちをかけるように外部からの視線が厳しくなる中、病院とIBMはただひたすら開発を前に進めるしかなかった。
結末：プロジェクトの結末と残された教訓
1998年初頭、紆余曲折を経た九大病院の新システムは、当初の構想とは似ても似つかない形でようやく一部稼働に漕ぎつけた。日本IBMは多数のVBプログラマを投入して力技でシステムを完成させ、旧来システムの置き換えを順次進めていった。最終的に納入されたのはSmalltalkでもオブジェクト指向DBでもなく、Visual BasicとリレーショナルDBによるシステムだった。かくして九大病院の「純粋オブジェクト指向システム」への挑戦は事実上の敗北に終わった。現場の医師や職員は、当初期待された華々しい先端技術の恩恵を受けることはなかったが、ひとまず業務に支障のない情報システムが手に入ったことで安堵するより他なかった。プロジェクトは当初の理念を捨てて現実路線へ舵を切ることで、なんとか沈没だけは免れたと言えるだろう。
振り返れば、この失敗の背景には最新技術への挑戦ゆえの困難もあったが、それ以上に古典的とも言えるプロジェクト運営上の Permalink | 記事への反応(0) | 21:29
ごもっともではあるんだけど
あとからテーブル設計変えたくないからある程度進めよう〜って思ったら結局こんくらいになった
セブン、昔はともかくいまは言うほど上げ底してない（むしろペラッペラの容器になってないか？）と思うんだが、いまだに上げ底言われてるのをみる限りやっぱり一度ついたイメージってなかなか払拭できないもんだな
というかセブンに限らずどこも容器ペラッペラになってる気がする
円安になると日本の企業は「利益拡大！」って騒がれることが多いけど、それって一部の輸出企業の話。実際には、円安の影響で苦しんでいる企業のほうが多いんじゃないかと思う。
たとえば、エネルギーや食品業界は輸入依存度が高いから、円安になると仕入れコストが跳ね上がる。電力会社は燃料を輸入するし、外食産業は食材のほとんどを海外から買ってる。小麦とかコーヒー豆とか、どんどん値上がりしてるのに、簡単に価格転嫁できるわけでもない。ファミレスやコンビニも値上げしてるけど、限界があるよな。
IT企業もそうだよな。ドル円が110円なだけでどんだけコスト変わるんだろうって思わないのかな。なんで国が2年以上も異常な円安を放置していることに対して共同声明とか出して圧力かけないのか理解できねーわ。
不動産業界もやばい。建材や設備のほとんどが輸入だから、建設コストが上がってる。特に、オフィスやマンション開発してる大手不動産企業は影響をモロに受ける。円安のせいで建築コストが上がる→デベロッパーの利益圧縮→結局、消費者が高い価格を払うハメになる。不動産の高騰なんて誰も大して得してねーからな。
さらに、航空業界も燃料費の高騰で大打撃。ANAやJALなんて、円安が進むたびにコストが増えるから、チケット代に上乗せするしかない。サーチャージだけ分けてチケット安く見せるとか必死に工夫してるわ。
製造業でも、円安だからといって必ずしも恩恵を受けるわけではない。たとえば、部品を輸入して製造している企業は、原材料費が上がるため、円安のメリットを十分に活かせない場合がある。特に、中小企業は価格転嫁の余地が少なく、円安が続くと資金繰りが厳しくなる。倒産数めっちゃ多いからな。アレ円安のせいでけーだろ。
また、日本の消費者も円安の影響を受けている。輸入品が値上がりしまくっている。
海外のハイブランドのものは、数年前と比べてもうファオタが背伸びしても届かなくなってる明らかに高くなっている。
昔20万とかで買えた服が今じゃ50万の価格帯になってるんだよな。正気じゃねーわ。
そもそも、日本人ってそもそも海外旅行行かなくなってるから、円安のひどさにあんまり気付いてないんじゃないかと思う。昔は「1ドル100円」の感覚で海外で買い物できてたのに、今は円の価値がどんどん落ちて、現地で普通にメシ食うだけでも高すぎる。でも、そもそも海外に行く機会がないと、この感覚すら実感できないんだよな。旅行行かないから「まぁ関係ないか」って思ってるうちに、どんどん日本の購買力が下がってるの、マジで終わってる。
ベーグル8ドルとか、円が100円ならまだマシだけど160円ならもう耐えられねえよ。
日本企業の多くは、輸入依存度が高いのに、円安対策ができてない。結局、円安の恩恵を受けられるのはトヨタやソニーみたいな一部のグローバル企業だけで、多くの企業はむしろ苦しんでる。
しかも、円安が長引くと、給料もろくに上がらないのに物価だけどんどん上がる地獄が続く。海外ブランドは買えない、ガジェットは高い、食材は値上げ、飛行機代も爆上がり。それでも政府は「まだ様子見」とか言ってるのが本当に腹立つ。今の日本人、これが異常な状況だってことにすら気付いてないんじゃないか？
このままだと、円安が進むたびに「日本の労働者は安く買い叩かれる」「生活水準は下がる」「企業は疲弊する」の負のスパイラルが加速するだけだよな。ほんと、いい加減なんとかしてくれよ。声明出せよ。本当にこのままで良いと思ってんのか？
これはオンプレミス回帰を謳っていたり、パブリッククラウドを否定するものでは無いです
2025年現在、サーバを準備するってなると、初手で AWS だの GCP だのってのを SNS ではよく目にするけど、
世の中の大半のシステムって、レンサバで十分だし、もっと言うなら事務所の片隅に置いたラップトップに「絶対シャットダウンしないでください」って付箋貼って置いておけば十分なモノばっかりじゃない？
オートスケールが云々とか、スペックの拡張が容易だとかクラウドのメリットはたくさんあるけど、実運用でそんなに使わなくない？
VM のスペックが足りなくなってきたから拡張しますっって、そんな場当たり的な対応よりも、コードのチューニングした方が良くない？
テレビで特集されたとかでアクセスが増えたときに捌けないと困るとか、そんなのサーバが落ちた方が流行ってる感出るじゃん
機会損失とか言うけど、そんなテレビの特集で最終的に購入までしてくれるユーザなんてほんの一握りなわけで、そこに大した機会なんてないんですよ
確かに超有名なサービスとかなら、そういうのがあった方が良いと思うけど、世の中の大半って管理者用の管理サイトとか、大したアクセスもないコーポレートサイトとか
そんなのばっかりでしょ
月額のコストを見ても、クラウドは過剰なコストが掛かりすぎてる場合が大半じゃない？
今一度本質を見つめなおして欲しい
その年代で、もう別姓制度に適合した人はそりゃ反対織だと思うよ
自分はそれだけ多大なコストを費やしたのにいまさら別姓制度とか、自分の時に導入してくれよ、自分はやったんだよって話でしかない
ちょっと愚痴書くけどさ、氷河期世代もこのパターンが多いと思うんだけど、
「◯歳、未経験ですが人並みの会社に就職したいです」で人並み以下の会社に就職すると大抵ブラック企業なんだよ…😟
だから、「20歳、未経験なので人並み以下の会社に就職しました」で精神病んで、退社しても若いからしばらくして回復するじゃん
で、「30歳、ちょっと経験あるけど、やっぱり人並み以下の会社しか雇ってくれないので、人並み以下の会社に就職しました」でまた精神病んで退職して、また回復して、
「40歳、もうちょっと経験あるけど、人並み以下の会社も雇ってくれなくなりました」で流石に再起不能になるみたいな…
新卒だと「22歳、未経験ですが人並みの環境の大手企業に就職できました」ができる「可能性がある」
あくまで可能性であって、つらい実験の授業落として留年したとか、病気で留年したとか、就職氷河期だったとか、もうそこでつまづいたらはい上がれないよ…😟
色々あって、運よく人に自慢できる実績とか、自営業としてやってた開発経験とかあるけど、まあでも基本そんなの人事に鼻で笑われるんだよね
自営業のつらさみたいなのがおまえに分かるのか、売掛金トラブルとか、ただ会社に勤めてるだけのてめーに経験ねーだろ💢みたいに思っちゃったりするけど、
まあ、ニコニコ笑って面接何度も落とされたり、そのうち書類も通らなくなるし、
精神障害者、身体障害者になったら、尚更スティグマが酷くなったようにしか思えない
会社のWebページとか、NHKみたいなサイトとか、SDGsとか、多様性とか、文字が躍ってるだけで、結局は新卒、上位層、金銭的に環境的に恵まれてる人が牛耳ってるだけじゃねーの？
その上、トランプになった途端にGoogleみたいな企業まで、いや、これまで多様性とか重視してもコストかかるだけでつらかったんですよー、だから、やめるねｗｗｗみたいなの何なの？
俺、養老孟司があんまり好きじゃない、どちらかという嫌いなんだけど、YouTubeでオススメに出てきたから、ちょっといくつか観てみたんだけど、
相変わらずこいつ頓珍漢なこと言ってんなー、そうじゃねーだろ、と思いつつ眺めてて、ひとつだけ俺も全面同意する話があったんだけど、
これまでの国の教えてくれたこと、世間で正しいと言われてたことはすべて間違ってました、アメリカが持ってきた民主主義がこれからは正解になります、
ってそういうことなわけだけど、養老氏が、世の中なんてこんなもんなんだって思った、って言ってて、あー、それは同じこと思うし、俺は終戦なんかなくても普段からそう思ってますよ
だって、宮崎駿じゃないけど、朝令暮改な上司に振り回されたりとか、
そこまでいかなくても、技術的な話でも、こういう設計が正しい、みたいなのがあっても、その次に何かそれを覆すのが現れるわけですよ
例えば、Ruby on Rails以前と以降ってあると思うんだよね
Rails以降、みんなRailsっぽい、なんかRailsの影響を受けた設計になってる
でも、それ以前に、似たような設計を思ついて現場で提案しても、アホか、みたいな対応をされるわけですよ、上司とか同僚に
ところが、偏見だけど、どっちかというと日本人より英語圏とか、なんかイケてる宣伝とかカリスマ性とか、社会運動をどうやって起こすかみたいなもんで、
そうやって外部から受け入れられていくと、上司も同僚も、俺もそう思ってた、みたいな話になるわけですよ、アホかとバカかと
日本の外側から同じ発言を外圧されると、俺も私もそう思ってたんだー、って言って付き従うみたいなの、日本に生きてて子供の頃から何度も見てきた光景ですよ
ほんともうね…
えーと、何の話をしてたんだけっけ…😟
追記：
まあ、でも、とんでもなく💩なJavaコードを手伝わされたことがあるんだけど、誰もコアな部分を読まないで、みんな💩を再生産してる現場で辟易したんだけど、
金にもならないし、評価にもならないし、上司にちょっと遠回しに言ったら心証悪くされたり、仕事しろよ（💩再生産しろよ）みたいに言われたんだけど、
コアな部分読んでて、あれ？これって古いコードだけどRailsっぽいことしたかったのかな？と思ったんだよね
だけど、このコアな部分を誰が書いたか、もうとっくに退職した誰かなんじゃないか、みたいなところまで考えて、まあ、でもそれを言うとまた上司と揉めるんで黙ってたんだけど、
このJavaのコードを書き始めたとき、初期のメンバーの誰か、多分、発言権があるとか偉い人がRailsっぽい設計をしたかったんじゃないか、
とは思うんだけど、このオレオレJavaでRailsやろうとしました、のコードが色々と酷くて、それが延々と悪影響を尾が引いてる感じになってるんだよね
思うに、Webフレームワークって、技術というより、どっちかというと設計思想だと思うんで、統一されて一貫した設計思想がないと崩れちゃう
内製オレオレフレームワークにしないで、外部のフレームワークを使うといいのは、フレームワーク自体のメンテは当然外部がやってくれて、一貫した設計思想があって、ドキュメントもあってってとこだと思う
中途半端にオレオレするぐらいなら、敢えて古いアーキテクチャというか設計思想を使った方がいいと思わされたんだよね
だから、Rails以前にRailsっぽいことやりたい、オレオレフレームワークやりたい、って言うなら、ちゃんとしたコードになるまでフレームワークを突き詰めるべきだし、
ドキュメントもちゃんと書くべきだけど、なぜかExcelで書かれた？クソみたいなドキュメントしかないんだもん…😟どうせいちゅうのよ…
まあ、しかも、上司なのか、同僚なのか知らんけど、物理的な嫌がらせをされるようになったんだよね、どの開発現場で
物を隠されるとか、飲み物に変なものを混ぜられるとか、ニュースとかでもよく話題になったりするじゃない
ああいう嫌がらせとか、仕事を妨害されるような行為をされ始めたんで、その犯人には好都合に思われただろうけど、怖いんでその会社辞めたんだよね
辞めた、って言ったら、親とか親族にギャーギャー言われたんだけど、そのへんの気味の悪い話は自分は忘れたかったんで、あんまり言い訳しなかった
まあ、あんまりにも酷いコードだったんで、そもそもこれはどういう経緯でできたのか、最初はどうだったのか、みたいなのを探ったりしてたのは、
周囲の反感を買っただろうし、そうは言っても、今になって思い出しても、やっぱり酷い、これをそれなりの値段で客に売りつけてるのも詐欺とは言わないが酷い
そう思ったので、頼まれもいないのにコアな部分のソースコードを眺めてみたり、流石にこれはマズいだろ、これは変えたい、
と思っても、そのマズい仕様が前提になって、そのフレームワークの上にまたクソみたいな大量のコードが乗っかっているわけで、
そのクソみたいな仕様を変えたら、すべて変更になるし、そんなことはほぼ不可能、できたとしても、それを認めてもらえない職場だってことは、まあ最初から分かっていたわけだけど、
