元SE女子部部長、あれこれやっています
皆さま、こんにちは！ 転勤族協会TKT48代表／ITコンサルタント／産業カウンセラーの「おくちゃん」こと 奥田美和です。
前回、衝撃の（？）コラムを投稿してから、約１か月。
何をしていたかというと…
・ミサワホームと、TKT48の姉妹グループ「TMT48」結成！
・TKT48 KEIO隊と一緒にプレゼンに行って、調布市役所の方と意気投合！
・通信社、新聞社の取材を受ける
・日本パブリックリレーションズ協会の「広報・PRスタートアップ講座」に参加
・熊本地震の１次情報（行政やメディアや現場発信の正確な情報）収集、拡散
・FBの限界を感じ、インスタグラムにチャレンジ（#TKT48、で検索♪）
SE女子部部長をお休みしたら、続々と大きな話が舞い込んできて、ようやく本業のITコンサルタントの仕事に専念できました。
９回転職してきて、どの職場でも新規プロジェクトを立ち上げ軌道に乗ったところで手放してきたので、ちょうどいいタイミングだったのかもしれません。
■「１次情報」の重要性
ところで、今回の熊本地震に関する様々な情報が流れてくる中で、思ったことがありました。
私は発信元＋発信日時を見て「災害時の情報は、３時間も経てば古い」と思ってシェアしなかったのですが、３日前の物資不足の情報がシェアされてきたりしました。
――それはもう解決されて、今は別の物が必要とされているよ！
シェアした方に悪気はなく、ただ広く周知するお手伝いをしようとシェアしたのだと思いますが、情報（Information）技術（Technology）を扱うIT業界出身のITコンサルタントとしては見過ごせません。
業務システム開発をされているSEの方ならわかると思いますが、情報（データ）には必ず「インプットデータ」「マスターDB」と、「更新データ」「一時DB」があります。
例えば、生保のシステムを思い出しながら書いてみると、下記のような感じです。
※今も夜間一括バッチ処理があるだろうという前提で書きますが、もし無くなっていたらごめんなさい。
「インプットデータ」 顧客Aの申込書（変額年金保険を追加）→ オンライン入力
「マスターDB」※インプットデータ追加前の状態
顧客DB：AさんのID＝001、保険＝001（に加入済）
商品DB：終身保険のID＝001、医療保険のID＝002、変額年金保険のID＝003
「更新データ」顧客ID＝001、保険＝003
「一時DB」※更新データを、オンライン入力でOKボタン押下時に、一時DBに更新
顧客ID＝001、保険＝003、……、入力日時＝16/4/16 10:00、更新日時＝空白
顧客ID＝010、保険＝001、……、入力日時＝16/4/16 15:00、更新日時＝空白
夜間一括バッチ処理で「一時DB」のデータを「マスターDB」に更新処理中、エラーになり、ロールバックが中途半端でDBの内容がおかしくなり、夜間にSEが呼び出されるような緊急事態になった時……。
どこまで更新されたところでエラーになったのか、まず、マスターDBの更新日時を確認。
担当SEがプログラムのバグを探している間、次に準備するのは、１次情報（バッチ処理前に必ず取るマスターDBのバックアップ、インプットデータ）です。
――とにかく、問題が発生する過程の、一番最初の部分。
最初の状態から、いくつかプログラムの処理を経て出力された中間データの信頼性は、低いのです。
今回は例え話が今一つで恐縮ですが、何が書きたかったかと言うと、
「１次情報（行政やメディアや現場発信の正確な情報）以外は信頼しない」「まずは更新日時を確認」ということ。
だから、色々な情報がシェアされてきても、その大元を辿り、必ず発信源を掴み、それが正しいと確信してからシェアしました。
いかに、１次情報を、素早く収集するか。
それは、金融業界でシステム開発をやっていた、ある意味「炎上現場」で学んだ、生き延びるための知恵なのかもしれません。
本当は、広報PR講座で学んだことがとても面白かったのでコラムにするつもりでしたが、また今度。
■本日のまとめ：広報PR業界と、IT業界の違い
広報PR業界の仕事は、いかに「情報を広めるか」。
IT業界の仕事は、いかに「広まってバラバラになった情報を集約させるか」。
非常時は、バラバラな情報から１次情報だけを抽出し、拡散する。