  |
はてなキーワード:定義書とは
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の知識どうこうじゃなくて、やる気と誠実さと政治力ですね
↓
経営戦略IT室長・CTO的な猫 ＜ ほいじゃまXXを実現しよう。こんなスケジュールで 👈 ここの周辺に変な猫がいると不幸が起きる
↓
↓
↓
↓
A部署の上司猫：ふんふん、新しいシステムに変えるのか。怠いからテキトーにOKでヨシ！👈 ここがんばろう
↓
B部署の上司猫：ふんふん、A部長ヨシ！って言ってるからヨシ！ 👈 ここがんばろう
↓
いろいろやってシステム移行
↓
A部署・B部署の真面目な現場猫：アレ？新しいシステムで○○ができないや。○○ってどうなってます？
↓
整理して説明しても理解する気がしないので整理はしない。ほぼそのまま切り貼り
↓
経営戦略IT室長・CTO的な猫 ＜ ほいじゃまXXを実現しよう。こんなスケジュールで 👈 ここの周辺に変な人がいると不幸が起きる
↓
↓
実際に実装する猫
↓
A部署の上司猫：ふんふん、新しいシステムに変えるのか。怠いからテキトーにOKでヨシ！👈 ここがんばろう
↓
B部署の上司猫：ふんふん、A部長ヨシ！って言ってるからヨシ！ 👈 ここがんばろう
↓
システム移行
↓
A部署・B部署の真面目な現場猫：アレ？新しいシステムで○○ができないや。○○ってどうなってます？
↓
運用フェーズだったはずの猫：要件定義書にないからヒアリングしてこれから会議して決めます
～～～～～～～～
まんまバズってたこれなんだよな
ベンダ「お客さん、ご注文は？」
IT土方 「XXってことは、今までも出来ていなかったってことだから、別そのままでよくない・・・？」
とか
IT土方 「○○は使え無くなるみたいです。ベンダーに確認をとったところ、△△で代替えできるみたいですが、検証を行なっていただいていいですか？」
〜作りました～
こんなだわ
例えば、『俺の要望聞いてくれないから、○○○○の技術者は無能』とかそういうやつ。通常それIT屋さん関係ないやつです
関係があるとしたら、Tech Startup で規模が小さくて創業者がまだ開発者として仕事してるとかそういうのに限定される
改善要求に対して、どれを採用するか・どのような順序で対応するかの決定を担うのは、
企画部門や運営部門やアカウントマネージャー(営業)などであって、通常IT屋さんじゃないです
別にこれはITプロジェクトに限ったことではないです。多くのプロジェクトは様々な部門を横断して行われる
一度も働いたことがない、フランチャイズではない小規模な個人店で店長と従業員しかいところで働いたことしかないなら、特におかしくはない。
しかし、まさかの役割分担がある規模感でオフィスワーカーの経験有り、何だったら元がつくとしてもIT屋さんに分類される何かで、
何度考えても何故なのかはわからない。実際に働いてわからないのだから、どうしたら認識ができるようになるのかわからない。謎である
『インターン制度も研修も無いよ』って会社もフツーにあると思う。これは別に何もおかしくない
でも、ドキュメンタリーやフィクションやお外で得た情報で、そういうのがある会社もあるんだなっていう認識はあると思います
ところで、IT企業研修センターや類するメニュー組んで実施してくれる会社、絶滅した認識ないです
何度考えても何故なのかはわからない。実際に働いてわからないのだから、どうしたら認識ができるようになるのかわからない。謎である
現場を任されている責任者に採用に関する一切が任されることもあるけど、日本は解雇規制が厳しく、一度直接雇用したらなかなか首に出来ない
なので、組織規模が大きくなると、カルチャーマッチングだの、長期的な人材の育成・活用ガーだので、人事は通常しゃしゃりでてくる
そういうの無視しても、採用は事業計画や組織戦略に直結する重要な経営活動だし、人事部は採用計画の策定から実行に至るまで、
経営目標の達成に貢献する人材を確保する責任を担う云々ってことに一般的にはなっている
現場の知識はないので、採用取り継ぎ役だけに徹しとこ・・・としてる場合も、通常どこの求人メディアに広告を打つかなどを決めているのは人事です
～～～～～～～～
ITわかんない人がエンジニア採用する時に何かを目安にしたいでしょ？
ぶっちゃけ Tech Startup の開発者兼社長の知識レベルは期待しないから、
経営者と採用担当者は基本的なIT知識を持ちましょう以外に正解はないんだけど、
みんなそれっぽいこと(厳選したぞ！)がしたいわけです
なので最後を売りにしている人材会社とそれを真に受ける人事担当者がいるってだけです
あと競技用プログラミングで良い成績の人は基本的にエンジニア向いてると思います
単に何をさせるかだけでしょ
つかどうあっても、常識的なIT知識がない状態で業務内容を正しく分析することできないので、
できるのはIT人材会社がいうことを鵜呑みにして頷くことだけだよ
日本のIT業界も、アニメ業界と似ていて、業務に必要なスキルを持った人を揃えることができない問題に直面することがそこそこある
要領が悪いSIのSEや社内開発のプロジェクトリーダーが、業後や休日にポンコツ技術者の作業を手直しているケースを見かけたりもする(おそロシア)
これは、過労死リスクを高めるだけでなく、まぁフツーにプロジェクトの遅延にもつながるよね
しかし、本当にやるべきなのは、適切なスキルを持つ人材を事前に準備し、アサインすることなんだよね
事前準備や根回しが間に合わない場合でも、『いや、○○の経験をある人揃えられないなら無理ッス』とハッキリ言って、とにかく周囲に理解を求め、状況に抗う姿勢を示すことが大事なのよ(無理なものは無理)
政治的または予算的な制約で人材確保がどうしても不可能な場合は、開き直って、誰が参画してもスムーズに業務を進められるような効率的なワークフローを構築することに全力を注ぐべき。社内の過去案件の資産を徹底活用し、チームで仕事ができる環境を整えることが最優先。つか、ITは本来、効率的なワークフローを作るお仕事だからね
もちろん、ちょっとナレッジ整えて教育したくらい、枠整えたくらいでは、どうにもならねぇポンコツメンバーってケースもあるだろう
しかし、それでもやっぱりやるべきことは、ワークフロー構築に全力を注ぐだよね
なぜなら、どうにもならねぇことはどうにもならねぇからだ。選択肢は、『メンバーが育つのを待つ』か、『危機感を持った人が人材を投入してくれるのを待つ』か、『プロジェクトから逃げる』の3つだよ
いや、それで査定は乗り切れない、俺私の無限残業でリカバリーする！！！！って言ったって、どのみち、俺私に社内やプライベートで予期せぬ予定が入る度に、プロジェクトは遅延するよ
同じ体力と時間を使うなら、予期せぬ事態にも対応できる体制を作り上げることの方に使おう(次回も使える)
天才とガチgeek以外は、お給料貰えるかやってるだけやで。だってリーマンだもの
自分のやらんといけんとこだけクリアできてりゃ、必要になったその時に勉強すりゃあいいのよ
サラリーマンなんだしな
ここ頑張るだけだわ
経営本部猫：○○で市場を取るぞ 👈ここ頑張ろう。IT音痴じゃちゃんとお仕事してるか判断出来んでしょ
↓
経営戦略IT室長・CTO的な猫：ほいじゃまXXを実現しよう。こんなスケジュールで 👈ここ頑張ろう。野心ある謎の人を入れると地獄
↓
↓
実際に実装する猫
↓
A部署の上司猫：ふんふん、新しいシステムに変えるのか。怠いからテキトーにOKでヨシ！ 👈ここ頑張ろう
↓
B部署の上司猫：ふんふん、A部長ヨシ！って言ってるからヨシ！ 👈ここ頑張ろう
↓
システム移行
↓
A部署・B部署の真面目な現場猫：アレ？新しいシステムで○○ができないや。○○ってどうなってます？
↓
運用フェーズだったはずの猫：要件定義書にないからヒアリングしてこれから会議して決めます
↓
経営戦略IT室長・CTO的な猫 ＜ ほいじゃまXXを実現しよう。こんなスケジュールで 👈 ここの周辺に変な人がいると不幸が起きる
↓
↓
実際に実装する猫
～～～希によくおこること～～〜
↓
A部署の上司猫：ふんふん、新しいシステムに変えるのか。怠いからテキトーにOKでヨシ！👈 ここがんばろう
↓
B部署の上司猫：ふんふん、A部長ヨシ！って言ってるからヨシ！ 👈 ここがんばろう
↓
システム移行
↓
A部署・B部署の真面目な現場猫：アレ？新しいシステムで○○ができないや。○○ってどうなってます？
↓
ここの結論を先にいうと，神奈川県公立高等学校入学者選抜インターネット出願システムなんだからドメインは shutugan.pref.kanagawa.jp か shutugan.pref.kanagawa.lg.jp などの地域型JPドメインか属性型JPドメインを使う設定をするべきであった．
これは最近問題になっているいわゆる行政サイト使い捨てドメイン問題とも関連あるし，（１次ソースにするには怪しいとしても総合的にみると載っている情報は正しそうな）カナガクhttps://kanagaku.com/archives/69495 によれば，なんと shutsugankanagawa.jp shutsugan-kanagawa.jp nyuushi-kanagawa.jp の三つとも本番環境として使われているようなのであり( nyushi-kanagawa.jp は違う)，その状況だけ見ても本物に混じって偽物がスパムやフィッシングを行っていてもほぼ見分けが付かないのである．
Googleから見ても，取得が容易なjpドメインで最近取得したドメイン，似たようなドメイン，似たようなメール，が送られてくるのである．ユーザの受信ボックス・迷惑メール・ゴミ箱に大量に届く懸念がある以上，ブロックするのが定石である．
仮にブロックせず受信ボックス・迷惑メール・ゴミ箱に届けた場合，大量送信によってユーザの使用量を圧迫し 15GB 到達すると，そのユーザは新規のメールを受信できなくなり本当に必要なメールを取りこぼす可能性がでてきてしまう（容量空ければ受信できなかったメールを受信し始めるわけではない）．
なので，大量送信SPAM 判定したメールはできる限りブロックする選択が，Gmail にとってある意味最善手なのである．
なお，神奈川県は令和 4 年度までは @pref.kanagawa.jp をメールで使っていたが令和 4 年度以降から @pref.kanagawa.lg.jp に切り替えているので，ベストは shutugan.pref.kanagawa.lg.jp であったと思われる．
サブドメイン毎にドメインレピュレーションが分かれているためあまり深い意味はないが，少なくともpref.kanagawa.lg.jp は 2007/04/16 に登録され有効なドメインなので，新規登録に比べて信頼性が高いと判断される．
なお，kanagawa.jp とkanagawa.lg.jp の切り替えもいろいろと謎はあるが，それはまた別の問題．
※webページはkanagawa.jp の方だし他方 e-kanagawa.lg.jp なんてのもあり……ちなみに e-kanagawa.jp は株式会社つくばマルチメディア登録ドメインで行政は関係ない．
少なくとも動き始めにはDKIM / DMARC が設定されておらず，問題になってから設定し始めてもそれはSPAMを頑張る業者と行動様式が似るので無駄なあがきとなっている可能性が高い．
SPF は2006年，DKIM は2011年，DMARC は2016年に出てきた対SPAM技術である．DNS 弄ったりメールサーバー建てるような人でないならこれらの設定方法は知らなくてもしかたない．
だがそれらを生業としている側の人間なら， 2024 年現在， 13 年前に提案されたDKIM すらちゃんと設定できないというのは，iPhone 4 やInternet Explorer 9 向けの開発しかわかりませんとか，スマホアプリでLINE 聞いたことないというのを2024年に言っているのと同じレベルなのである．
そのぐらい前の時代に提案された迷惑メール対策・認証系の機能を未実装で本番環境動かすというのは，語弊のある誇張表現をするならWindows Update やapt upgrade を 13年間しないで通信を試みるようなもので，自殺行為に等しい．
もちろん，その通信を受ける側はこいつヤバいやつだってすぐわかるので，かなり辛口で評価することになり，ちょっとでもSPAM の雰囲気出してきたらブロックするのは定石．
そしてブロックされたSPAM 側はあの手この手でおかまいなしにSPAM 送ろうとするので似たような内容やドメインでしつこく送ろうとするので，似たようなものもどんどんブロックするのである．
なので初手でヤバいやつ認定されないのが極めて重要にもかかわらず，そこを怠っていたのである．
実際に，2024 年 1 月12 日時点の mail.shutsugankanagawa.jp はどうなっていたかというとDKIM 設定がないまま本番環境を動かしていたようである． https://archive.md/qykwX
ここで実際いろいろ正常化しても，それはSPAM業者があの手この手でなんとしてでもSPAM 送り届けようと頑張っている様子と一緒なので，ある意味無駄なあがきなのであるどころか，SPAM認定を加速させた可能性も否定できない．
Gmail もSPAM対 策は馬鹿じゃないので，送信ドメインを変えても文面があまり変わっていないならSPAM とするし，送信元のIP とかも見てSPAM とするので，AmazonSES 使いつづけたり新IP で何回も試行するとうまくいかないし，送信元信頼性の高い送信サーバーサービス経由で送れたりするようになっても，SPAM扱いされることもよくある．
ちょっと送信に成功しだしてまたいっぱい送り出してSPAM業者扱いされるのはやっていることがSPAM業者と同じことというか，その辺の今時のSPAM業者よりSPAM業者っぽい挙動をしているのである．
今でもたまにGoogle anti-SPAM/phishing 網をくぐり抜けてくるえきねっと のフィッシングメールもびっくりするほどであろう．
Gmailユーザーへの送信ガイドラインみたいな文章は，最近の DMARC騒動で見る人が多いこのページが一番詳しいhttps://support.google.com/a/answer/81126?hl=ja .今はその騒動に応じてかなり加筆されているが，このページは開発中はどうであったのだろうか．
まず開発スケジュールについては，この開発は神奈川県の調達情報によると，調達案件番号 0001450060020230089R業務名『神奈川県公立高等学校入学者選抜統合型WEB出願システム構築及び運用・保守業務委託』で間違いないと思われ，開札日が令和5年3月31日だからプロジェクトの始動はその後だろう．
※税金使途への意識高い県民はご存じの通り，ここから誰でも調べられる https://nyusatsu-joho.e-kanagawa.lg.jp/DENTYO/P6515_10
ちょうどその頃のWeb Archive がたまたまあって 2023/03/07 時点ではこうなっていたhttps://web.archive.org/web/20230307005024/https://support.google.com/a/answer/81126?hl=ja
冒頭では
重要: 2022 年11 月より、GoogleGmailアカウントにメールを送信する新規の送信者はSPF またはDKIM の設定が必須になりました。
とさらっとメールを送信する新規の送信者はSPF 「または」DKIM の設定が必須である一方，『ドメインのメール認証を設定する（必須）』の重要のところをよく読むと，
重要: 2022 年11 月より、個人用Gmailアカウントにメールを送信する新規の送信者は、SPF またはDKIM を設定する必要があります。Google では、新規の送信者から個人用Gmailアカウント宛てのメールをランダムにチェックして、認証されたメールであることを確認します。認証方法が一つも設定されていないメールは拒否されるか、迷惑メールに分類されます。この要件は、すでに送信者である場合は適用されません。ただし、組織のメールを保護し、今後の認証要件をサポートするために、必ずSPF とDKIM を設定することをおすすめします。
のようになっていて，「今後の認証要件をサポートするために、必ずSPF とDKIM を設定することをおすすめ」など，やんわりと新規の送信者は認証しっかり 必ずSPF とDKIM を設定することをおすすめ しているのである．
こういう書かれ方しても，個人のメールサーバーとかならSPF かDKIM どっちかで運用してみてドメインを駄目にしても笑い話になるけど，自治体で運用するシステムであえて，博打に挑戦する必要あるのだろうか．
まぁ本来発注側の要件定義書とかにちゃんとSPF /DKIM を設定することなどと書いておくべき案件だったかなとは思う（たぶん書かれていなかったんだろう）．
とにかく今は全世界の3割弱がGmail と言われている中で，本当にGmail が謎仕様のブラックボックスで届かないことが多発していたら国内外もっと騒ぎになるのでGmail 側に今回の件で大きな瑕疵があったとはいいがたい．
設定不備およびその後の作業内容で地雷原を突き進んで自爆しているのだろう．
アホらしいけどアホに一番わかりやすくいえばGoogle Workspace /Gmail 同士ではIPメールサーバーのレピュテーションと無縁になれて，世界中の他の宛先にもだいたい問題なく送れるので，SPF /DKIM / DMARC の設定だけ気にすればよく，かなりシンプルなのである．
AmazonSES 使えていたんだからGoogle Workspace も不可ではないはず（ISMAPにGoogle Workspace もいるので，あとは要件しだいだけど）．
今日は花金で午後暇になったのでざっと調べて書き出したけど，去年（おそらく最小限の修正などで運用するための発注） 3,600,000円 だったシステムを，今年は全面刷新して 138,600,000 円かけたわけだけど，ちょっとさすがに値段の割にお粗末な印象がある．
まぁ入札調書の開札日付が「平成」のままになっていたりしているの見ると教育委員会側も事務方スタッフが発注前から既に疲れてるんだろうなとも思うなど，ただそういう大人の事情はともかく受験生の心情を考えると，本来あるはずのない余計なストレスを掛ける結果に，大人の一員として恐縮してしまう．
一つ思うのはこれ「一般競争入札（技術審査型）」だけど本当にちゃんと技術審査したのかね？する能力あった？安い方に安易に決めてないだろうな？？と，突っ込んでいった方が今後の神奈川県の教育環境のために遠からずなるかなと思ったけど，よく考えたら私は神奈川県民じゃなかったわ
コンサルも込なら良いが大体は要件定義からだ。つまりお前らは要求定義は出来ている前提だ。なんも分からないから経営層や現場との橋渡しのみなら邪魔だから今すぐSE名乗るの止めて仕事辞めて田舎で畑耕せ。
AccessやFilemakerで弄れる程度でSE名乗るならせめて自社業務の流れや種類は把握しておけ。何聞いても現場に確認しますじゃ時間かかるんだよ。なんなら分かるんだ？別に業務フロー寄越せとか言ってないぞ。
割とマジで自分が経営層から何をシステム化してほしいのか分かってない奴が多い。体感5割以上。最近じゃインボイス対応。インボイス対応してください言われて現状や影響箇所は何をしたいか聞いたら「さぁ？」って言う。じゃ、何しにきた。挙句に「そのやり方も提案するのがシステム会社でしょ！」とキレる役職者まで。コンサルは契約に入ってないんだけどな。ちなみに別の会社でシステムのお偉いさんしてたとか言ってたがExcel方眼紙使ってたので速攻無能確定。おまけに技術も知識もアップデート出来てないし平気で偽装派遣みたいなこと言ってくる。前の職場どんなとこだよ
クラウドとか言語とかアーキテクチャとかフロントエンドもバックエンドも何も知らないなら勉強しろとも言わないが分かった風の口聞いてググった程度の知識でマウント取るな。むしろ都度説明求めろ。
ランニングやイニシャルコストの話で妥当かどうかをこっちに証明させるな。お前らで判断しろ。少なくともボッタクっては居ない。あと逆に原価厨みたいに人件費等々無視した計算もすんな。人はタダじゃない。
小売りとかだと土日もやってたりするけど対応ほしけりゃ契約時に言え。割り増すから。電話やメールでなくて後日文句言うな。あと平日業務時間外にZoomとかやるな。金寄越せ。
要件漏れとかあってこっちがリスケ等を要求しても承知しないでキレたり三顧の礼したりするの止めろ。そのバカみたいな時間を社内調整に回せ。夜の22時とかに泣きながらZoomでお願いしに来るな。不動産営業にでも転職しろ。
要件定義書、設計書、テスト仕様書、その他いろいろ作って会社で確認してもらってるよね。読め。だいたい書いてある。仕様漏れとかでこっちが記載してる言って読んでないってキレるな。あとどこの企業も読んでないとか言うな。ちゃんとしてるとこは読んでる。
大体馬鹿なユーザー企業はアジャイル開発何も知らないくせに「要件定義要らない、数週間で出来る、ドキュメントも要らない、仕様変更簡単」と思ってる節がある。なぜか最初にアジャイル開発で～とか言ってくることも。何もできないならウォーターフォールの方が数倍マシだぞ。アジャイル開発だとお前の役割重要になるんだぞ。ちゃんと管理出来るんか？だいたい動き出してからウォーターフォールの動き求めてきたりするw
ちゃんと要求まとめて要件定義から参加して受入まで出来たり、アジャイル開発ができるユーザー企業の社内SEなんて日本の中小企業の1割にしかいないと思っているので、自信ない人は是非パッケージに頼るかもっとたくさんお金払って全部お任せにしてください。
どっちも無理なら退職して熊本に出来る半導体工場で地道に半導体製造の職員として働けば？
上流SE。
要件定義から保守まで自分とチームメンバーで力合わせてやってきて、追加改修もまだまだたくさんこれからある状態の時にいきなり全部取り上げられて他の案件に異動。
その案件は設計製造全部終わってて、半年ぐらいかけてずっと社内と現地で大規模なテスト中。バグが出まくっててずっと残業60時間超え続けてて、3人ぐらい病んで休職中。
その中で私はほぼずっと放置されている。
「人手が足りないから来い」と言われて異動したにもかかわらず仕事はほぼなし。仕様のレクチャーもなし。
それで納期遅れても何にも言われない。
そしてその何にも分かってない状態で月の半分ぐらい現地テストに同行させられる。
何すれば良いかわかんないし聞いても「いや、ちょっととりあえず座ってて」と言われるので朝9時から夜8時までずっと座ってボーっと要件定義書読んでる。
私以外の人は忙しそうにしてる。
忙しい忙しいと言って人を招集しておいて、新しい人を教育する=自分の負担を軽くするための行動を一切せずいつまでも「あ〜忙しい忙しい」と目の前で言われても私にはどうすることもできません。
こんなに存在意義ない感じになるなら元の案件を頑張り続けたかった。
今の案件やり遂げても手柄は全部元からいた人のものなんだから評価も上がらないし、私からしたら設計製造のおいしいところは全部食い尽くされて意味不明なテストをただ眺めるだけって、リソースの持ち腐れもいいところだろ。
SE辞めたい。
