Force.comスマートエンジニア〜賢太郎の場合〜
ピピピ…ピピピ…
賢太郎は目覚ましの音で目を覚ました。布団から手を伸ばして、目覚ましのアラームを止める。
「7時か…さて、起きるか。」
賢太郎はベッドから起き上がった。いつもの部屋とは違い、今日は出張のため名古屋駅近くのビジネスホテルに泊まっていた。手早く着替えるとビジネスホテルのレストランに向かった。朝は得意な方ではないが、いつもと違った環境のせいか不思議と目が覚めていた。
賢太郎はホテルのレストランで朝食を食べながら、メールをチェックする。スマートフォンを片手で操作しながら、もう片方の手でパンをかじる。今日は午後から昨日に同じ顧客と打合せをして東京に帰る予定だ。午前中はとりあえず予定は入っていないので、どこかカフェを見つけて別の作業をする予定だ。賢太郎は顧客からの1件のメールが目にとまった。トラブル対応の依頼に関するメールだった。
「午前中は経費精算でもしようと思ってたけど、無理っぽいな。またあけみちゃんに怒られるな。」
賢太郎は社内事務をいつも溜め込んでは、事務員の椎名あけみに怒られているのだ。そんなことをぼやきながら、メールの内容を食い入るように読み進めた。トラブル対応依頼のメールの内容をを一通り読んだところで、Skypeの呼び出し音が鳴った。賢太郎は発信者を確認して接続した。
「おはようございます。すごい開発の流石です。」
「流石さん、おはようございます。しぶい商会の山下です。朝からすみません。メールを送らせてもらったのですが、もうお読みになってもらっていますか？」
賢太郎にSkypeで連絡をしてきたのは、賢太郎が勤める「すごい開発株式会社」の顧客である「しぶい商会」の山下だった。先ほどのトラブル対応の依頼メールの送り主である。すごい開発はしぶい商会とスマートエンジニア契約を結んでおり、賢太郎はしぶい商会のメイン担当なのである。その他にもいくつかの顧客を担当しているが、しぶい商会が一番長い付き合いになる。
すごい開発のスマートエンジニア契約とは、月額固定でエンジニアに業務委託できるサービスである。すごい開発はクラウド型サービスであるセールスフォース・ドットコム社のForce.comを利用して各種の業務システムを提供するとともにメンテナンス要員であるスマートエンジニアを月額固定で貸し出している。最近流行りの納品しないシステム開発、エンジニアを複数企業でシェアする仕組みである。
「はい、先ほど拝見しました。」
「さすが！仕事が速くて助かります。実は、メールにも書きましたが、運用環境でエラーが発生しているので一刻も早く復旧する必要があるんです。至急対応してもらうことはできますか？」
「そうですね。午前中は予定が空いていたので対応してみます。まず、エラーの原因究明と回避策の検討を進めます。その後、エラーを発生させないようにする回避策の実施、根本対策の順に行います。」
「はい、その手順で問題ありません。」
賢太郎は午前中の事務作業は予定通りスキップして、顧客と対応方針について詰めていった。
「了解しました。ところで、開発環境でもエラーは再現しますか？」
「はい、再現しました。今回、新しいプログラムをリリースしたので、それが影響しているのではないかと疑っているのですが、あいにく修正した担当者がインフルエンザで病欠してしまっていて…」
「それは困りましたね。ただ、再現しているのであれば、原因究明は速く済みそうです。少し開発環境をお借りしますね。」
「はい、よろしくお願いします。」
「では、少し調査して折り返し連絡します。」
賢太郎は続いて送付されてきたメールの内容を確認しながら、原因究明のためのヒアリングを進めた。今回は運良く開発環境でエラーが再現しているので、ログを仕込めば早めに原因が分かりそうだ。クラウド型サービスのよいところとして開発環境もクラウドにあるため、自分のPCに環境を作らなくてもよいことである。しぶい商会は千葉市にあるので現地でしか作業できないような環境だったり、開発環境をローカル環境に持たないといけない環境だったりすると、今回のような対応はできない。
「さて、Chatterでボスに連絡しておこう。」
賢太郎は朝食の続きを急いで食べながらiPhoneでChatterのフィードを投稿した。Chatterとは企業内SNSであり、離れた場所にいてもメッセージをやり取りできるセールスフォース・ドットコム社のサービスだ。賢太郎のように出張していても本社にいる上司への報告が簡単にできる。
賢太郎は朝食を手早く済ませてホテルをチェックアウトして、いつも名古屋にくると利用しているコ・ワーキングスペースに向かった。コ・ワーキングスペースに着くと、賢太郎はMacBookAirを開いてトラブル対応を開始した。
「さて、まずはログを取りながら再現手順に従って操作してみよう。」
そういいながら、賢太郎は開発環境を手早くログインして、デバッグに取りかかった。すでに9時を回っていたので、とりあえずのリミットはあと3時間。賢太郎はそれまでに原因を究明して回避策の実施まで行うつもりでいた。
「ん？ガバナー制限にひっかかってエラーになってるぞ？いや、このソースはありえないだろ？」
賢太郎は山下にSkypeで連絡をした。
「山下さん、エラーの原因がわかりました。」
「えっ、もうわかったんですか？で、いったいどんな問題だったんですか？」
「昨日追加されたトリガーのソースコードに問題がありました。ガバナー制限というForce.comプラットフォームの制限を超えたためエラーとなっていました。」
「なるほど。で、対応策としてはどうしたらよいですか？」
「はい、対応策としては問題のソースコードを含むトリガーを無効にしてしまう手もありますが、あまり時間のかかる修正ではないので私の方で修正してしまおうかと考えています。理由としては、無効にしてしまうとトリガーの処理を前提として動作している箇所があった場合、別のエラーが発生する可能性があるためです。」
「そうですか。では、お願いします。」
賢太郎は今回の不具合を修正することにした。今回の不具合は、DMLを一括処理せず1件ごとにDMLを発行していたため、少し件数の多いデータを扱うとガバナー制限を超えてしまうというものだった。賢太郎は、ライブコーディングさながらの速さでソースコードを修正していった。修正箇所やソースコードの管理方法などについても軽くまとめた。
その後、二人で賢太郎が修正したソースコードをSandbox環境に反映して確認した。
「ありがとうございます。確認も取れたので、早速運用環境にアップします。でも、そんなに簡単な修正なんですか？」
「はい、ガバナー制限の対応方法としてはごく一般的な対応です。失礼かもしれませんが、新しく入られた開発者の方にガバナー制限について一度レクチャーしましょうか？」
「う〜ん、やっぱり新人に作らせたのがよくなかったですかね。Force.comにも色々と新しい機能も増えているようなので、一度レクチャーしてもらう機会を設けたいと思います。」
「新人の方が作られたんですか？そう聞くとちょっと不安になってきました。ともあれ時間内に修正できてよかったです。」
「そうですね。さすが流石さんです！いつもありがとうございます。」
山下からは毎度のことながら非常に感謝された。トラブル自体はいいことではないが、こういった瞬間の達成感はなんとも言えない。
そんな感傷に浸っていると賢太郎宛にChatterのフィードが投稿されてきた。
「
＠流石賢太郎 さん
月末になりました。今月の経費精算はまだでしょうか？(−_−＃)
（あけみ）
」
（おしまい）
この記事はForce.com Advent Calendar 2011に参加しています。
※この作品はフィクションです。実在の人物、団体、事件などには一切関係ありません。
