目線の置き方は？
原発事故対応
満杯状態になっている冷却水に対する汚染除去装置、なかなか本稼働しない。
仏アレバ社、米キュリオン社、両社製の除去装置の組み合わせ、シーソーゲームの様に、不具合が見つかっている。
慣れない作業に加えて、技術の異なるメーカー製の組み合わせの結果、だろうが、国産設備は無いのだろうか？
国内の原発、確か６０基弱あったと思う。
これだけ原発数があり、トラブル対応を含め、付帯設備としては重要なものであるのに、ライセンス生産も含め、国産化されていないのが不思議？
システム、トラブル対応も含めてスムースに運用するためには、効率もさることながら、遺漏ない全体構築が求められる。
これは、ＩＴ関係にも当てはまるだろう。
コンピュータによるデータ処理、システムを構築するためには、自社開発は別として、ユーザー側の仕様要求をまとめる役割が非常に重要になる。
システム開発会社、ソフトウエア開発のプロではあるが、業務処理のプロではない。
このため、ユーザー側の開発責任者、システム化する業務のみではなく、その業務が関係する全体を把握していることが必要となる。
先日も、「緊急時迅速放射能影響予測ネットワークシステム（SPEEDI）」、そのままでは実際の運用に供することができない、という事例がニュースになっていた。
前提が？ ということだが、システムに対する要求仕様を作成したユーザー側の責任であろう。
http://www.bousai.ne.jp/vis/torikumi/index0301.html
http://www.nsc.go.jp/mext_speedi/index.html
システム構築における『仕様書』の重要性、これを説明できる事例は多々ある。
３０年近く前のこと、前職で、同社初めてのインハウス・オンラインシステムを構築する業務を担当した。
(以前にも関連するブログを書いた。)
元々経理屋であるため、数字の流れは分かっているが、営業現場でのデータ生成・修正等については、分かっている様で分かっていなかった。
このため、現場からの要求仕様を求めた。
ユーザーとなる各現場からの仕様要求、それを受けたシステム開発会社のプログラム仕様書、立ち上げ時のトラブル対応の完了後、改めて確認して感じたこと。
現場からの仕様要求、手作業時代の自分の担当業務の範囲での目配り、直近で発生したトラブル対応、等々。
期待した、業務を見直し業務効率を上げる、システム化による新規要求、といったものがほとんど見受けられない。
今は、その仕切りは無くなったが、当時はＣＰＵの性能が小さいために区分けが必要とされた、照会系・勘定系の連携には全く触れず。
また、データ修正等の影響範囲がシステム開発会社に伝わらない仕様、となっていた。
データ生成プロセスは比較的簡単であるが、データ修正時の影響範囲、これはシステム全体を把握していないと見過ごすことが多々。
結果として、データ不整合となる。
宿泊部門責任者だったＫ君、経理部門責任者だったＮ君、キャッシャー責任者だったＡ君、その他の人達に随分と迷惑をかけた。
毎日の営業成果を翌朝に把握したい当時のＴ総支配人、システム責任者として、（毎朝）頭を下げる日が１か月以上続いた。
現場の人には本当に迷惑をかけたが、この時の経験、今でもしっかり生きている。
全体把握、スケジュール作成・管理、個別業務の深掘り、情報検証、業務に携わる組織・構成員のスキル評価、外的環境評価、将来変化への対応、等々・・・・
先夜、長男がオフィスを訪ねて来て、夕食を共にした。
彼は、某システム開発＆運用会社で金融系のシステム開発に従事している。
自分と同じ轍を踏まない様、現在のシステム水準を知らない自分としては、過去の経験を簡単に述べるだけに止めたが、主旨は十分に伝わっただろうか？？
