このブログを読んでいるあなたは、アラフォーになってから、IT業界への転職や配置換えを考えている方だと思います。以前私は、IT業界へのジョブチェンジでアラフォーならではの、”最強”のメリットについて解説しました。しかし、これだけでは勝負にならないのもまた事実です。ある業界で働き続けた結果、その業界の業務知識を得たことは確かにメリットです。しかし、その業界を担当するベテランのシステムエンジニアの方が、自分以上に業務に詳しいということが往々にしてあります。お客さまとコミュニケーションを取る上で”最強”のメリットですが、職場内で無双できるようなメリットではありません。職場内で、経験年数数年の若手に知識を提供したり、中堅のシステムエンジニアと仕様について議論したりする、そんな職場内のコミュニケーションを円滑にするための道具くらいに思っておいたほうが良いかもしれません。
それでは、システムエンジニアとして活躍するために、どのような能力が必要なのでしょうか。私は次の3点が必要だと考えています；
- 出力されたデータに問題があるかどうか判断する。
- データベースから必要なカラム、レコードを抽出する。
- 操作ログから、その時刻付近に行われた変更を把握する。
これら3点について、解説していきます。
出力されたデータに問題があるかどうか判断する
「画面に不正な値が出力された」という一報が来たら、あなたはどのように行動しますか。私はすぐにデータベースにアクセスしてしまいます。自分自身を戒めなければなりませんが、これは間違いです。なぜなら、システムから不正な値が出力されるという事象に対して、自分の経験のみによる憶測での行動につながってしまうからです。特に、思い込みで行動してデータを修正した結果は、大規模なシステム障害の発生に繋がりかねません。とはいえ、早くトラブルを解決したいあまり焦ってしまうのもまた人の心です。
一報をもらったら焦りながらでもいいので、お客さまが操作している画面にどのような値が出力されているのかを眺めてみてください。そしてお客さまの詳細なお話を伺う前に、次の3点の該当箇所を確認してください；
- お客さま用のマニュアル
- 基本設計書
- DB設計書
調べているうちに、徐々に落ち着きを取り戻している自分がいるはずです。もう一度お客さまが操作している画面を見ると、これが正常動作か不正動作か想像がついてきます。これにより、システムの動作として正常の場合はお客さまに仕様の説明をすることができますし、そうでなさそうな場合はどこを調べたら良いのか検討をつける事ができ、その後の対応の覚悟を決めることができます。
データベースから必要なカラム、レコードを抽出する
データベースには、その名の通り膨大なデータが存在します。そのため、研修のときのような軽い気持ちで「SELECT * FROM （テーブル名）;」などと打とうものなら、万単位のレコードが選択されます。そんな万単位のレコードの中から怪しい物を探すとなると、見つける前に日が暮れてしまいます。そのため、上記のDB設計書をあらかじめ調べておくことが大切になります。つまり、設計書からどのベータベースを使っているのか、どのカラムの更新を行っているのか当たりをつけて、該当箇所を選択するのです。
簡単な例だと、「ある商品を買物した際に、商品の詳細ページに書かれている金額と、買い物かごの金額が違う」という状況が起こっていたとしたら、調べるべきは
- データベースに登録されている商品の金額
- 詳細ページに商品の値段を表示するロジック
- 買い物かごに金額を表示するロジック
になります。データベースの「商品マスタテーブル」に「商品コード」、「商品名」、「金額」、「登録日」などのカラムがあるとすると、SQLとしては、「SELECT * FROM （商品マスタテーブル） WHERE （商品コード）;」のようになります。これにより、少なくとも「この商品コードで登録されている商品の金額はいくらである」ということが分かります。つまり、詳細ページに書かれている金額は、商品マスタテーブルに登録してあるデータ通りかどうかがわかるということです。
3階層Webシステムを使っている場合、商品一覧から詳細ページに遷移する際、内部的にはSQLで絞り込みを行っているので、商品マスタテーブルと詳細ページの金額に差異があるとは考えにくいです。それらしい例が思いつかなくて申し訳ありません。このあたりは、良い例が思いついたら更新させていただきます。
操作ログから、その時刻付近に行われた変更を把握する
ここからは操作ログについてです。設計によりますが、操作ログにより操作日時、操作内容、成功可否、出力されたエラーメッセージなどを把握することができます。つまり、事象が発生した時刻をお客様から教えていただければ、その前後の操作ログを追うことにより、実際にどのような操作が行われたのか大体わかります。操作ログを見るときに注意しなければならないのは、出力されたエラーメッセージばかりに目が行き、操作日時を見落としてしまうことです。
私はよくやってしまうので反省しなければなりませんが、「エラーを見つけた！」と思っても、操作日時が離れているため因果関係がなさそうだったり、逆に「エラーが出てない」と思ってその操作日時付近の成功可否を見落としたりなどです。操作ログを追うときは、「何時に」「何が起こったのか」という視点で見ていきましょう。
余談ですが、操作ログは「否認防止」という特性を持っています。否認防止とは、JIS Q 27000を引用すると
主張された事象または処理の発生、及びそれを引き起こしたエンティティを証明する能力
です。難しい表現をしていますが、簡単に言うと「言い逃れはできない」ということです。「その時」「どのような操作がおこなれたのか」が記録として残っていますので、あとから「やっていません」とは言えないのです。これはお客さまの操作だけではなく、システムエンジニアも同様です。だからこそ私達は責任を持って行動しなければなりません。
運営業務を題材にシステムエンジニアに必要な能力を解説しました。アラフォーとなると仕事で様々な経験をしているのでちょっとやそっとのことでは動じないと思いきや、仕事の進め方が違ったり、知識が不足していたりするという不安があればそうもいかないようです。この記事で解説した必要な能力を、落ち着いて1つ1つ身につけ、実践していき、着実に成長していくことが大切なのではないかと考えています。
コメント