紙台帳への記載，役場と企業とのやりとり，命令系統の三層構造，コンピュータ入力…。「年金記録問題検証委員会（年金検証委）」の中間報告では，様々な問題が様々な段階で積み重なり，今日に至ったとしています。そんな状況で，社会保険庁のプライムコントラクタであるNTTデータのSE魂はどうだったのか？ それとも，魂なんて元々なかったのか？ 社保庁の理不尽な要求に毅然として「No！」を言ったのか？ コンテンツはコンテクスト（文脈）の中で意味を持ちます。コンテクストが全く違えば，同じコンテンツでも全く違う意味になります。

　複数の年金手帳，オンライン前の処理の杜撰（ずさん）さ，アルバイト入力…。基礎年金番号を統合することで表面化した凄まじい件数の宙に浮いたデータを目の当たりにして，社保庁のSEたちはどのように感じたでしょう？ 少なくとも，バラバラの台帳では出現しなかった潜在的問題が露呈したのは，コンピュータ統合した効果です。複数回にわたる名寄せ統合で，日本の総人口よりも多かった3億件の被保険者番号は絞り込まれ，宙に浮いた年金番号は5000万件にまで絞り込まれました。今後どのように問題を解決していくのか？そのプロセスに関しては相当の議論が重ねられたと思います。

　過去からの様々な杜撰（ずさん）な措置が積み重なった結果が，5000万件の宙に浮いた年金番号です。一挙に解決するのは不可能です。おそらく，社保庁の決断は「年金の裁定申請時に決着させる」だったでしょう。少なくとも，オンライン化で社保庁の業務運用の品質レベルが下がったわけではありません。今までの杜撰さの本質的（？）解決は，裁定時決着しかない。私が社保庁の担当者であっても，そう考えてあきらめただろうと思います。

　これも当時の文脈（コンテクスト）背景での判断です。宙に浮いた5000万件の半分以上が，裁定申請時を過ぎた60才以上の年金番号だと分かっても，方針の変更はありませんでした。政治的な“決着”だったからです。昨年，民主党の長妻議員から年金問題を追及された安倍さんの最初の答弁は，「不用意に国民を混乱させるな！」というものでした。メディアが年金問題を叩き始めた今年に入っても，最初は同じ反応でした。

　システムとは異なる要素が有機的複雑に組み合わされた，部分に分解できない全体系です。それをエンジニアリングするのがSE（システムエンジニア）です。ITのターゲットドメンは人間系システムですから，そのエンジニアリングはさらに難解です。

　社保庁とSEとの要求定義や機能設計の現場が実際はどうだったのかは，分かりません。SEの対象は，あくまでもIT化する業務です。ユーザーやクライアントが言えるのは，曖昧や冗長を含んだ要望や思いです。それをユーザー運用の観点から全体を見ながら本質をつかみ，ユーザーからの要求の行間を読み，その上で行間を読む必要のない明確な要求定義（Requirements）を策定するのがSEの仕事です。

　しかし，SEが納得できないRequirementsを無理強いするユーザーもいます。その場合，SEは断固として「No！」と言わねばなりません。それでもヤレと言うユーザー相手には，遂行せざるを得ない時もあります。しかし，優秀なSEであればそうした場合にも，必ず代案を用意しておきます。80％以上の確率で，問題が生じますから。

　ユーザーに対する「No！」は，システムの実装フェーズにおける技術的問題ではなく，ITをツ－ルとして利用するターゲットドメインのビジネス局面に対して申し立てできなくてはなりません。Requirements通りに作れば良いというユーザーとは，必ず「言った言わない」の不毛の議論になりますから，何故問題になるのかを説明した文書（議事録）を交わしておきましょう。「No！」と言わなかったばかりに，「専門家のSEが認めたから」と責任をIT側に押し付けるケ－スは山のようにあります。

運用維持はシステム規模に合わせて幾何級数的に難しくなる

　ここに「社保庁次期システム構想」があります。2006年の情報ですから，年金が国を揺らすような大問題になるなんて想像だにしていません。かなり詳細なデータです。これを見てNTTデータが悪いと簡単に言えるでしょうか？

　この中で，宙に浮いた5000万件の年金番号に関係する記述を探しました。もちろん，宙に浮いたデータがあるなんて言えるわけもありません。ぼかしながら「年金裁定時までに…（略）…確認整備を行っている」とだけあります。裁定時に決着するから，と軽く考えているわけでもないようです。社保庁システム全体の規模は，2100万ステップです。紛れもなく大規模システムです。何と700万ステップのプログラムもあるようです。Web2.0とかマッシュアップとかの問題ではありません。基幹システムの複雑性は，尋常ではないのです。

　COBOL言語とメインフレームは堅牢性に関して，オープンシステムの比ではありません。堅牢性は年金システムに求められる重要な視点です。ただ，制度改正や政治問題からバンバンにシステム変更があると思います。ユーザーである社保庁は，納期なんてほとんど聞いてくれなかったでしょう。

　システムの運用維持は，規模が大きくなると幾何級数的に難しくなります。コミュニケーションギャップが起き，それに関わるオーバヘッド作業だけで6，7割を占めます。つまり計画を進捗する本来の工数は残りの3，4割になってしまうのです。ソフト開発が労働集約である以上，どうしようもありません。