  |
はてなキーワード:dbとは
AIの使い方について間違えてはいけないのは、ガソリン自動車は馬車より安く速く遠くまで移動できるぜ、で終わるのではなく
AIが本当に爆速でシステムの開発、実装、デプロイ、更新できるのだとすれば
CIよりも早く最新の状況に合わせてシステムの改修、デプロイできるのだとすれば
今この瞬間、最高の仕事をしてくれるシステムを爆速で生み出してくれるはずなので
なんだろう、過去に作ったシステムをありがたがるような使用法のシステムじゃなくて
今この瞬間にカスタマイズされたシステムをその場で作って出せるはずで
だからと言ってデータベースはすぐには変わらないし、収集してない他人のデータがいきなり参照できるようになったりもしない
それを踏まえつつ
じゃあ例えばユーザの要望が即実装されるYoutubeとかあったら便利か？
自分にはメリットの少ない実装も含めて大量の機能があふれ出るのは間違いないので、影響範囲は限定的で、利用者が望んだ機能だけが表に出てくるようにする
いやいやいやいやいや、そうじゃなくて、
WEBに限定するけど、人間に命令されたことを理解し、公開されているAPIやDBに接続して命令を実現するための組み合わせを考えて実行した場合の結果をシミュレートし、人間の確認を得てから実行する、ってことにすれば
うーん、どういうことだ
データのモデルはあらかじめ用意しておいて、UI部分はユーザの特性に合わせて動的に作らせる
しかしこれだとロジックもなにもないな・・・さらに盛られたサラダを見るなり食うなり好きにしろって言われてもって感じ
何をサービスしたいんだ俺は
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
RemindBookmark
サービス開始が結構先のゲームの発表とかあると、その時ブクマしてもサービス開始時には忘れてる問題。
ウェブ漫画とかで公開日が先で公開期間も決まってて気がついたら公開が終わってた問題。
これを解決するために、ブクマのタグで [2025-02-03] みたいな感じでサービス開始とか公開日の日付のタグをつけておけば、その日になったらそのブクマが表示されるサイトを作ってみた。
https://remind-bookmark.com/bookmarks/{はてなID}
で、{はてなID}が「今日」の日付のタグを付つけたブクマが表示される。過去の自分が「今日」思い出したいページにタグ付けしておく必要はある。
基本的にはこのページを毎日チェックしておけばサービス開始時とか、〇〇の公開とかのタイミングでいい感じに思い出せるはず。
https://remind-bookmark.com/bookmarks/{はてなID}/YYYY-MM-DD
で、{はてなID}が[YYYY-MM-DD]タグを付けてブクマした記事一覧が表示される。
同じく、YYYY-MM-DDにブクマした記事一覧も表示される。
一年前の自分がブクマした記事とかみて振り返りとかもできる。
[YYYY-MM-DD]
↑これ固定。つまり
[2025-02-03]
じゃないとちゃんと動かない。
[2025-2-3]
とかだとダメなので気をつけてください。
はてなブックマークフィード仕様 | Hatena Developer Center
https://b.hatena.ne.jp/sample/rss?tag=book
一応キャッシュしてブラウザリロードしまくっても、はてな側に負荷が掛からないようにはしてるけど、サイトが消えたら察してください。
こんな簡単な仕組みなのでDBは一切使ってない。ドメインはなんとなく買った。
仕組み上、公開ブクマなら誰のIDでも入力したら見えるけど、そもそもはてな本体で見えるし問題ないと思ってる。
わかる人ならわかると思うけど、ほぼすべて生成AI（cursor、claude-3.5-sonnet）にやってもらった。コーディングはもちろん、デザイン系とかいろんなテキスト考えてもらうとか。
Cline系は使いこなせないので使わなかった。
個人的には「合法的に名前が2つ使える」という、非常に厨二っぽい満足感をもって生活している。
免許もマイナンバーも旧姓併記がされるので、どっちの名前で生活しても通用する。
銀行口座も旧姓併記的な扱いができる(旧姓宛の振り込みをそのまま受け付けてくれるので、仕事先に言う必要がない)。
特に自分が個人事業主だからというのもあるが、仕事周りは旧姓、私生活は新姓と分けることで、気持ちの切り替えもしやすい。
妻は姓について「どっちでもいい」というスタンス。
ならば、会社勤めの妻より個人事業主の自分の方が時間の自由が利くので、名字を変える際の面倒事を受け入れやすいと思い、自分が名字を変えた。
屋号を使えば前述の「合法的に名前を2つ持つ」が実現できるし、気持ちのメリットもある。
お互い、自分の名前に特にアイデンティティを感じていないので、気楽に過ごさせてもらっている。
(それはそれとして、「同じ名字になった」現実についての愛情だの愛着だのはある)
とはいえ、本人たちが合意していても、双方の家族共に「なんで？！」という反応は受けた。
自分の両親は夫婦別姓までは想定していたっぽいが、まさか息子が名字を変えるとは思っていなかったらしく、母親が「私も名字変える！」とか言い出した時はどうしたものかと思った。
また、妻の兄弟からは「ウチに遺産なんかないぞ！」と裏で言われていたらしい。
実際のところ「なんか名前二つ使えて楽しそう」「会社勤めな妻のストレスが減るのが嬉しい」という理由がメインで名字を変えたので、そんな深読みをさせてしまったのは申し訳なく思っている。
尚、男性側が姓を変えて感じた事として、「色々な書類の名字を書き換える」事に対する同調圧力が恐らく女性のそれより緩い。
銀行口座を結婚後数年経って書き換えに行っても「あ、そうなんですね」で済む。
そんな感じで数年かけてゆるっと色々書き換えていったが、記憶にある限り「名字変わったなら早く書き換えてください」と怒られたのは確か一回だけ、それもなんかのショップの瑣末なポイントカードの時だった気がする。
裏でDBも作ってないような紙のポイントカードで怒られたのは、未だに釈然としていない。
勿論、名字を併用する面倒ごともある。
書留だか配達記録郵便だかで送られてきたが、当時まだ免許証もマイナンバーも旧姓併記版にしておらず、配達員さんに対して旧姓と同一人物であるという証明ができず、持ち帰られてしまった。
仕方ないので最寄りの免許センターで運転免許書き換えの必要書類を聞くと、「旧姓が分かる住民票」が必要と言われる。
それならと役所に住民票取りにいくと、なんと旧姓が書かれていない。
住民票に旧姓を記載するためには、本籍地に行って戸籍謄本を取ってくる必要がある。
これが分かった時点で、その日は一日たらい回しに使う事を決心し、本籍地の役所で戸籍謄本取得→現住所の役所で住民票更新→警察署で免許証に旧姓追記→郵便局で受け取り申請までを一日でやった。
…のだけど、郵便局でのこういうケースが相当なレアケースらしく、最後の郵便局で職員さんが奥に引っ込んでぜんぜん出てこない。
たぶん方々に確認したり裏で擦ったもんだしてくれたであろう結果、確か30〜40分後に更新版のクレジットカードを受け取れた。
マイナンバーカードでのコンビニ手続きがもう少し整備されると、こういう時嬉しいなと思う。
この時は、コンビニでの戸籍謄本の取得は色々面倒があり、できなかった。
あと印象に残っているのは、税務署で名字の変更申請をしようとしたとき。
曰く「そういう人はみんな旧姓のままか、しれっと名前書き換えて出してますよ」とのこと。
ちなみに名前を書き換えて出すとシステム上は別人扱いになり、過去の申告内容との紐付けはされないらしい。
(まあ管理番号があるし、それこそ今はマイナンバーも紐付くので、完全別人扱いってこともないとは思うが)
尚、最終的に何かの裏紙に旧姓と新姓を書いて、窓口の人に書き換えてもらった。
自分が自身の名字にこだわりがなく、且つそういうマイナートラブルを「なるほどそういう扱いになるんだ！楽しい！」と燃えてしまう性格なので成り立っている面はあるけれど、特に女性で「結婚したら書類は一斉に書き換えるのが当たり前」という同調圧力の中でこういったマイナートラブルに遭ったら面倒くせえだろうなとは感じる。
「家」の縛りが緩くなってきたこの時代に、夫婦別姓を望む人が多くなるのも当たり前だと思う。
なので、ここまでの話はそれはそれとして夫婦別姓もちゃっちゃとやればいいのにとは思っている。
自分の場合は「現行システム上は男性側が名字変えた方が総合的に二人のストレスが低くなって結婚生活が楽しくなる」という見込みで変えたのであって、最初から夫婦別姓が公式に選べるならどうしたか分からない。
姓を変えたければ変えればいいし、変えたくなければそのまま生活する。
よく夫婦別姓の反対意見で言われる「子供が不幸になる」という意見はシンプルに傲りだとしか思えない。
現時点で多数派である夫婦同姓の家で育った子供に「夫婦別姓をどう思うか」なんてアンケート取ったらネガティブな回答が多数派になるに決まってる。
その状況でポジティブな回答をする子供がいたら逆に達観しすぎてて怖い。
そういうニュースを見るたび「自分たちは別姓の夫婦を差別するよ」と暗に予告する、人としての程度の低さが見えてちょっと嫌。
