【第2話】見えない指示、進まないリカバリ：その日、私の仕事はなくなりました 〜僕の業務システム改善日記〜（3/3 ページ）

[谷口有近（シロッコ情報技術研究所），ITmedia]

　「問題になりそうなデータの部分だけ切り出して再実行します」

　チトセは、早速データのバックアップを取得し、ファイルの編集を始めた。

　「栗原さん？でしたよね。お願いがあるのですが、このデータを取り込む先のテーブルのレコード数を数えておいてもらえませんか。それと、一週間前から昨日までの分を、日付別で数えてください。お願いします」

　「は、はい！　えっと、履歴として残してるテーブルでいいですか？」

　「最低限それで。できれば関連しそうなテーブル全てを見たいところですが、まずはそこを確認してください。念のためチェックというところで。投げたSQLが後で分かるようにSPOOLしておいてくださいね。数が分かったらすぐに教えてください」

　自分が今やろうとしたことを先回りして注意し、ほれ見たことかと言わんばかりのタイプは、正直苦手だ。そんなことぐらい分かってますよと言い返したくなる。でも、チトセの指示から伝わってくる安心感は何だろう。

　ケンイチは、目の前で次々と物事を決定し、行動していくチトセが、まるでシステムと会話しているかのような、そんな不思議な錯覚を覚えつつ、指示されたSQLを組み立てて実行した。

　「…あ…れ？　本日分のデータ、既に出来上がってますね。おかしいな。そして、いつもの10倍近くの量がありますね。同じようなレコードがあるようにも見えます」

　データが多重で生成されているようだということに気付いたとき、当初考えていたスキップ処理のリミット時刻は既に過ぎていた。（つづく）

メッサー有近のITオペコラム

【今回の解説フレーズ】

いつ復旧するのか、その目処を報告しろって言ってるんだよ。分かる？

システムトラブルが発生した際、復旧を目指して全社一丸となり、エキスパートが原因を特定しつつ、復旧目処を計算して社内に展開、可及的速やかに運用部隊がシステムを再稼働させ、カスタマー部門が迅速に開示を行って復旧目処を伝えることで、顧客をはじめとするステークホルダーのお怒りを収めていきたいわけであります。

夜中に呼び出された複数のベンダーが、エース級の技術者が捕まらず、原因を満足に調べられない状態なので、何とか時間を稼ぐためにも、営業担当者は進んで会議室に監禁され、上級SEは責任と賠償問題を盾にひたすら罵倒を続ける事業会社の管理職にジャンピング土下座を繰り広げるという状況は、都市伝説であってほしいところ。

復旧させるためのプロセスとしては、まともに考えれば原因の追究が何よりも先です。原因は判明せずとも、特定のプロセスをリスタートすれば改善するかも、そして正常化した後に調査することができるかも、という判断も状況次第では有効なことがありますが、リスタートしてしまうことで環境がすっ飛んでしまい、調査ができない事態に陥る可能性もあります。大変判断が難しく悩む場面です。

確かなことは、トラブルは想定外の状況が起きているのでトラブルなのだということ。焦りは禁物。「復旧目処の報告を行うことが報連相だろ！」などと指示している暇があったら、差し入れの缶コーヒーでも買ってきたほうが、何倍もマシでしょう。

----------------------

谷口有近（たにぐち ありちか）

SNS系ITベンチャーから転身、2001年にカブドットコム証券入社。高負荷でミッションクリティカルな証券取引システムでの基盤設計から、構築・運用全般に従事。BCP用遠隔データセンターネットワークの構築などを担当し、2009年にITプロフェッショナルエヴァンジェリストとして開発と運用の統合的な改善業務を推進。

2011年より社長付IT戦略担当として、エンタープライズにおけるクラウドや仮想化を前提としたシステム改善、タブレットでの先進的UXの実装、ビッグデータ関連のR&Dを担当し2013年に退社。

独立後、現在はICTによる業務改善を目指す組織の業務支援やビジネス開発を中心に、事業会社経験を生かした講演などを行う。