よつやTips

元IT技術者がおくる情シス超入門：VB.NET / SQLServer / 弥生製品 / ひとり情シス

【CS】サポート担当初心者向け、技術者と仲良くなる方法！

超初心者向け概要 カスタマーサポート

こんにちは、四ツ屋です。四ツ谷でも四つ矢でもなく、四ツ屋です。

突然ですが、カスタマーサポート（CS）のタマゴなそこのアナタ！

技術者との関わり方に困っていませんか？

 

当ブログはワタクシ、四ツ屋が過去の経験を元に、何らかの文字に書き起こしてネットの海に不法投棄してやろうという趣旨です。

なので今回は、開発者だったりカスタマーサポートだったりとあちこちフラフラしてる私から見た、カスタマーサポート（＝問合せの対応者）が技術者（＝調査担当者）と上手に付き合う方法を模索してみようと思います。

 

「なんでこいつのために自分が気を遣わなアカンねん！！」

そんな風に思う人は、この記事を読むのは時間のムダです。

自分の思う方法でやってみてください。

 

技術者ってぶっちゃけ面倒くさい

私自身も開発者として在籍していましたが、とにかく面倒くさい！

技術者宛ての問合せの電話を取り次いだだけで嫌な顔をされる！！

 

なんでやねんな？

電話、おめー宛てやろ？？

 

理不尽だな―とは思います。すごーく思いました。

でも、理不尽だと文句を言おうにも、治らないのです。なんでやねん。

 

最初にシステム開発の現場に入ったときに、すごーく悩みました。

なんでこんなに不機嫌なんだこのひと？と。

 

退職後、あとから考えるとその人の性格もあったかな、と思います。

勿論、すべての技術者が当てはまるとはいいませんが、個人的に、私がこれまで出会ってきた技術者って、意外と面倒くさい、って思う人が多い。

そんな面倒くさい人と、業務上付き合っていく、いい方法は？

 

技術者と仲良くなるメリット

大体のチームとしては技術・サポート・営業くらいにざっくり分かれてますよね。

で、技術メンバと営業が仲が悪いことが多いです。経験上。

ぶっちゃけ私も営業と喧嘩することが多かっ

 

 

どの立ち位置にいてもスムーズに業務が回せるといいのは間違いありません。

しかし、実際にサポートの立場にいると、技術者と仲良くなっておくことは業務が圧倒的にやりやすくなります。

だって、サポートチームで受けた問合せのうち、内容が解決しなかったら絶対に技術メンバに頼らざるを得ないのだもの。

 

サポートだから格下だからとか、技術者が偉いと言っている訳じゃありません。

CSにはCSの、技術者には技術者のそれぞれ得意分野があるのです。

営業にもあるのかもしれないけどな・・・

 

しかし、技術者に頼らなければならないときに、

「それは仕事なんだからちゃんとやってよー」って思うのと、

「気持ちよく仕事してもらおう」と思うのでは、ちょっと違うのです。

その秘訣を探るため、技術者のことを少し、知ってみませんか？

 

技術者に嫌われるひととは？

気持ちよく仕事をしてもらうためには、もちろん、好かれる方がいいですよね。

技術者が嫌う人って、実は一貫しています。

それは・・・

自分で何も調べないひと、丸投げするひとです。

 

もちろん時間やタスク量的にそれが出来ない場合は仕方ないですが、常に丸投げマンは嫌われます。

※ここで言うところの「嫌われる」って言葉ですが、「子供じゃないんだから好き嫌いで仕事するなよ～」って思うかもしれませんが、そう思われる方は前述の通り、この記事を読まないでいいかなと思います。

 

「おいこら四ツ屋、てめーなにを当たり前のこと言ってるんだ」と思われる方もいるかもしれませんが、実はこれが出来てない人って多いのです。

・ヒアリングできていない

・正しい動作、正しい結果が何か分からない

・なぜその問合せが来ているのか背景、理由がわからない

・説明できない

こういう人から、「○○について教えて～」って言われても、ゲンナリしてしまいます。

 

テクニカルサポートがいればその限りではないのですが、前提として、技術者って開発の時間を削って調査をしてくれることが多いです。

その中で、依頼される側の技術者が、アレコレとサポート担当者に聞かないと状況がわからないのでは、不機嫌にもなりますよね。

 

技術者に上手く調査依頼をする方法

人と仕事をするには、「気持ちよく仕事をしてもらうこと」が大事です。

特に、お願いをする時に注意すべきことをまとめました。

・優先度と期限

・経緯や背景、仕様の前提条件

・最終的にどうある状態が正しいのか

・自分でどこまで調査をしていて、何がわからないのか

これらをきちんと伝えることが重要です。

 

これを見たアナタ、「いやいやこんなの当たり前じゃん」と思いますよね？

ちゃんと上記が守れている方ならそこまで苦労はされてないはず。

あとは、普段から技術者がどんな仕事をしているのか、コミュニケーションをきちんととっておくことです。

やっぱり、関わりの薄い人とは意思の疎通がやりづらくなってしまうというもの。

普段から、できるだけ会話をしておいた方がいいです。

 

是非、少しずつでもいいので試してみてください。

【CS】サポート初心者向け、問合せの初期対応

超初心者向け概要 カスタマーサポート

こんにちは、四ツ屋です。

最近SQL関係の記事ばっかりだったので、ちょっと今日は気分転換に、システム管理者向けの不具合切り分け方法をご説明したいと思います。

ニッチな記事のような気はしますが、このブログ自体がニッチなところだという自覚があるので・・・（笑）

 

あなたはシステム開発会社のカスタマーサポートです。

ある日のこと、いつものようにお客様から問合せが来ました。

さて、あなたは一人で問合せをクローズまでもっていけるでしょうか？

 

最も重要なことは、状況を正確にヒアリングすることです。

サポートをする上で最も重要な能力で、これさえ出来ればあとはぶっちゃけ、何とでもなります。

自分で対応を判断しかねる場合でも、ヒアリングさえできていれば他の人に助けを求めたときのパスが圧倒的にスムーズになるからです。

 

しかし実は一番むずかしいのが「ヒアリング」です。

問い合わせてくるお客様のシステム理解度によっては何を言っているのかわからない！ということも少なくありません。

 

人によっては、なんかもう言ってることが支離滅裂だってこともしょっちゅうです。

もちろん、支離滅裂なサポート窓口の人もいますが（笑）

 

・・・では、一体どのようにして問合せを処理すればよいでしょう？

 

■原因究明が先？代替案が先？

問合せの内容には緊急度が高いもの、重要度が高いもの、様々なものがあります。

お客様からの問合せでは「今すぐなんとかして！」というものが少なくありません。「いつでも良いけど見ておいて～」なんて、滅多にないですよね？

しかし、何でもかんでも「今すぐ！」は難しいですし、「なるはやで！」って言われてしまうと他のタスクに忙殺されて放置し、怒られてしまう・・・なんてことも。

※注）なるはや＝なるべく早く、の略ですが、最近じゃお客様からのメールででも頻出の略語ですね。

 

まずは何よりも、緊急度の確認が重要です。 

お客様の作業は止まってしまいませんか？

あと一時間で、セールが開始されるのに間に合わない！なんてありませんか？

急ぎの問合せや、緊急事態が発生している場合には、まずは深呼吸。

 

解消しなければならないリミットがいつなのかということを確認しましょう。

 

リミットが迫っているにも関わらず原因が分からないようなケースでは、代替案を提示するなどして時間を確保し、その上でしっかりと原因究明と対応を行うことも時には必要です。

 

様々な事案を個別に判断する必要がありますが、何よりもまずは緊急度を確認することが重要です。

 

※急がない場合には？※

急がない場合は、じっくりと腰を据えて原因の究明ができます。

しかし急がないといって、何日も音信不通のまま放置しておくのはいけません。

 

サポートのメンバーにとっては何社も取引しているうちの一人のお客様かもしれませんが、お客様にとっては困りごとがあるからこそ問合せをしているのです。

原因の調査が難航していても、その進捗の報告を待ちわびています。急がない場合だとしても、折に触れて進捗の報告などをしましょう。

 

■調査するには？

調査できる時間を確保したら、腰を据えて調査をしましょう。

問合せには様々な種別がありますが、基本的に運用が軌道に乗っているシステムの場合、ざっくりと下記の内容に分けられます。

  

＜意図した動きをしない・不具合・エラーが発生している場合＞

・システム上の不具合（バグ）

・お客様の運用上の操作ミス

・設定内容のの変更

 

＜質問や要望の場合＞

・運用方法の変更や新施策に伴う機能利用の方法について

・新機能・オプション機能の適用について

・エンドユーザからの問合せについて

 

ざっくりとはこんなところかと思いますが、もちろん複合しているケースもあれば、特定の操作によって発生する不具合などのケースもあります。

まずは不具合やエラーに関するものから紹介していきましょう。

 

■不具合の調査

不具合が発生している場合に確認すべき内容を見ていきましょう。

 

【１．不具合内容の確認と正常な状態を想定】

・画面上でエラーの表示が出ている

・画面が遷移しない、動かない

・表示されている内容がおかしい　・・・など。

 

できれば実際の画面を見るのが一番ですが、できない場合にはどのような表示がされてしまっているのかを文章やキャプチャなどで確認しましょう。

自分の環境で確認できない場合には、お客様にキャプチャ画像を送ってもらうこともアリです。

その際には必ず、「あるべき姿」がどういう状態なのかを想定しておいてください。

最終的にどのように動いているのかが正しいのかをお客様と認識のすり合わせをし、他の人に説明できる状態であることが重要です。

（システムの仕様をきちんと理解していることが前提です・・・）

 

なお、この時点で過去に前例がないかを確認するのも良いでしょう。

その場合には所属しているサポートチームごとにナレッジをもっている可能性があるので、関連する単語で一通り調べてみましょう。

 

【２．発生手順と状況を確認する】

・いつ、誰がどのような手順で操作をおこなったのかをお客様に確認する

・操作ログ、アクセスログ、IISログなどを確認する

 

その不具合がどのような操作手順で発生したのかを知ることは原因究明の有用な手段です。

操作手順を知ることで、原因がわかるケースはとても多いのです。

 

もしログを落としているのであれば、各種ログを確認することで実際にどのような手順で操作をしていたかを確認することも出来ます。

ログを落としているシステムであれば日頃からログを見る癖をつけると、いざという時に役に立ちます。

 

【３．再現できるかどうかを確認する】

・まったく同じ操作を同じ環境で実施して再現するか

・同じ環境で行えない場合にはテスト環境、開発環境などで実施

 

手順を確認したら、その手順で再現できるかどうかを確認しましょう。

再現してしまえば、原因はほぼ掴めたと言ってもよいでしょう。

 

常に再現しない場合には、問合せされたお客様のに再度発生するかを確認し、お客様側の他の担当者の端末で発生するかどうかを確認することも有効な手です。

不具合が再現しない場合は、特殊な操作をおこなった、端末特有の不具合、ネットワーク等インフラの状況、同時刻にバッチ処理が行われていたなど、想像だにしない原因であるケースがあります。

 

最も厄介なのが、再現したりしなかったりするケースです。最悪です。

この場合にはもう周りに助けを求めるようにしてください。

同じ手順を繰り返すことによって再現する特定の条件が分かることもありますが、一人で悩むとドツボにハマるのでオススメしません。相談大事です。

 

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

これだけの手順を踏んでも分からないケースは沢山あります。

最後まで分からないけどなんとなく発生しなくなった、とかいうこともあります。

 

しかし、ここまで一人で確認でき、内容と結果の説明が出来るようになると、他の人に助力を求めやすくなります。

 

特に技術者は、よく分かってないのに「どうしたらいいですか？」って訊いてくる人を嫌う傾向にあります。 

ある程度は自分で情報を拾い集め、それをまとめた上で、何が正しい状況であるのかを説明できるようになっておいた方が良いです。

 

次回は、技術畑に生きる人々への「調査、お願い♡」の仕方をやります。

【SQL】超初心者向け！抽出（SELECT）基本の構文

超初心者向け概要 SQL

こんにちは、四ツ屋です。

今日はSQLServerに格納したデータを抽出する基本的な方法について紹介したいと思います。

 

概要編ではSQLServerのデータのやり取りは、
SELECT（抽出）
INSERT（新規登録）
UPDATE（更新登録）
DELETE（削除）
この４つとお伝えしましたが、そのうちの「SELECT」について、紹介していきます。

 

■データ抽出「SELECT」の基本構文
SELECT [フィールド名]
FROM [テーブル名]

実はこれだけなのです。かんたんですね。
かんたんすぎて笑えますが、本当にこんなものです。
あとは必要なオプションを付け足していくだけです。

 

１．抽出したい条件を指定する。
SELECT [フィールド名]
FROM [テーブル名]
WHERE [条件式]

条件は、WHERE句で設定します。
たとえば、名簿の中から女性のみを抽出したい場合は、
SELECT *
FROM [名簿]
WHERE 性別 = 女性

こういうイメージですね。

補足ですが、SELECTのあとの「*（アスタリスク）」はFROMで指定したテーブルのすべてのカラムを表示するときに使います。

便利なのでつい使ってしまいますが、抽出した結果、全カラムが表示されるのでデータ量が多い場合にはその分抽出結果の表示に時間がかかります。

パフォーマンスを気にする場合は注意してください。


さて、WHERE句には条件式を入れればいいので、たとえば「性別 = 女性」以外にも、
「年齢＞19」で、20以上のひとを絞り込むことができます。

複数の条件を指定したい場合には、ANDやORでつなげることができます。

SELECT *
FROM [名簿]
WHERE 性別 = 女性
AND 年齢 > 19

これで、20歳以上、かつ性別が女性のレコードのみを抽出することができます。
OR句を使った例であれば、

SELECT *
FROM [名簿]
WHERE 性別 = 女性
OR 年齢 BETWEEN 10 AND 20

上記の用に、性別が女性、または年齢が10歳～20歳までの人を抽出することが可能です。
比較演算子など、様々な条件で抽出ができます。

どうでもいいけど、コードを記述するならSyntaxhighlight入れたほうが見やすいですよね。勉強したら入れますｗ

 

２．抽出した結果の列を整理する。

SELECT [フィールド名]
FROM [テーブル名]

さきほど、「*（アスタリスク）」を使うことで全カラムを抽出できるというお話をしましたが、ここでカラムを指定する場合の方法です。

SELECT [ID], [Name], [Sex]

FROM [名簿]

このように、DBのカラム名をカンマ区切りで記述することにより、指定したカラムの結果のみが表示されます。

また、基本的にカラムの物理名は英語で記述することが多いです。

上記のクエリでいうところの、ID、Name、Sexなどですね。パッと見た時に英語になってしまいますが、結果表示の際の列名を変更したい場合は、AS句をつけることによって、表示名を変更することができます。

その場合には下記のように記述します。

SELECT [ID] AS '会員ID', [Name] AS '会員名', [Sex] AS '性別'

FROM [名簿]

上記のように記述することで、「ID」は「会員ID」、「Name」は「会員名」、「Sex」は「性別」というように、分かりやすい列名に変更することができます。

結果を列名ごとコピー（Shift + Ctrl + C）したあとにエクセル等にペーストする場合には後から列名を変更する必要がなくなりますので、ルーチン化するような作業の場合はとても便利です。

 

■データ抽出時のロックについて

ロックってなんじゃそりゃ？って方も多いかと思います。

データベースにはロックという機能があり、これが非常に面倒くさい重要だったりします。

たとえば、ロックをかけないで何でもかんでもデータの変更ができちゃうぜ！ってなってしまった場合、データがおかしなことになってしまうことがあります。

データがあるべき状態にあるかどうかを「データの整合性」というのですが、データの整合性保持のために、ロックをかける必要があります。

・更新ロック（見るのはいいけど更新・削除はNG）

・読取ロック （見るのもだめよ～）

上記の二つがあります。

読取ロックの場合には、SELECTで抽出しようとしても抽出できません。

また、WEBシステムなど、不特定多数の人がデータの更新を行う場合には特に気をつける必要があります。

その場合はWITH NOLOCKでロックをかけないようにするなどの工夫が必要です。

 

↓参考サイト

[SQL Server]SQLServerのNOLOCKロックヒント(ダーティーリードがしたい） | 開発備忘録＆ふと思ったこと

【備忘】SQLServerで文字列に全角カナ・半角カナを区別させるには。

SQL 備忘録

半角が含まれてるかどうかの比較なら、バイト数で全角と半角の比較をすればかんたんに出来ますが、もう一種、比較の場合について。

www.yotsuyatips.com

SELECT *
  FROM [TableName] WITH(NOLOCK)
 WHERE ([FieldName] LIKE '%[ｱ-ﾝ]%' COLLATE Japanese_BIN)

これでもイケちゃうというやつです。

SQLServerでは通常、全角と半角の区別を付けてくれないのですが、CALLATE句を利用することによって、照合順序を変更することができます。

詳細はこの辺を参考にどうぞ。↓

Windows 照合順序並べ替えスタイル

超初心者向け！SQLServerデータベースの構造

SQL 超初心者向け概要

こんにちは。暑くて外に出る気がしない四ツ屋です。

今日はSQLServerのデータ構造の基本をさらっとお伝えしますね。
夏なのでさらっと……
 
１．データベース
２．テーブル
３．カラム（列）
４．レコード（行）
５．フィールド
 
これだけ覚えておけばとりあえずは大丈夫です。
 
■データベース構造の中身について
 
１．データベースについて
アプリケーションソフトのデータを格納する「箱」のようなものです。
システムの構造によって、データベースの構造は変わります。
例えば、アプリケーションとデータベースは１：１には限りません。
たとえば、会社内で同一の商品マスタを複数の部署が参照し、その部署ごとに出荷管理システムが存在する場合、１つのアプリケーションで複数のデータベースを参照することもありますね。
複数のテーブルの集まりが「データベース」です。
 
 
２．テーブルについて
では、データベースの中身「テーブル」についてです。
データベースがエクセルファイル本体だとすると、テーブルとは表、ワークシートのようなものです。
テーブルはそれぞれ、格納する内容によって名前をつけ、その中身が分かるようになっています。
 
ひとつのテーブルに何でもかんでも入れればいいというわけではないので、データの種別ごとにテーブルが分けられるように設計されるのが通常です。
 
 
３．カラム（列）
テーブルの構造は設計・開発時に決められ、後から変更する場合には注意が必要です。
アプリケーションでデータの登録・更新をするなどの場合に、データベース側だけ変更がかかっていると、エラーになることがあるためです。
そのため、データベースのカラムを追加・削除したり、変更したりする場合には、アプリケーションの利用を止めることがあります。
 
カラムとは、テーブルの「列」のことです。
分かりやすく「住所録」で例えると、名前、住所、電話番号など、どの情報を格納するか、が決められています。
また、カラムごとに、どのようなデータの形式かを格納するかも決めます。
この形式のことを「データ型」といいます。
たとえばエクセルではセルごとにフォーマットを「文字列」や「数値」「日付」などを設定することができますが、SQLServerではカラムごとに決めています。
エクセルのようにセルごとにデータ型を変えることはできません。
 
４．レコード（行）
レコードとは、テーブルの「行」のことです。
テーブルという「表」において、カラムが列、レコードが行ですね。この概念が非常に重要です。
 
レコードは、アプリケーションの操作や、クエリによって新規登録、更新、削除を行うことができ、その場合、カラムとは異なり、追加・変更をする場合にも特にデータベースの構造が変わる訳ではありません。
 

f:id:yotsuya_yz:20170712235620p:plain


（図）カラムとレコード、テーブルの説明図です。
 
５．フィールド
フィールドとは、上記の図でいうところの各セルを指します。
例えばデータベース上で一つのフィールドの値を特定するには、どのレコードのどのカラムか、ということがわかれば特定ができます。
フィールドに入る値は、カラムで設定した書式に基づいた値を格納しています。
 
 
■正規化とは？
先程、テーブルの説明で「何でもかんでも入れればいいというわけではない」と書きました。
 
例えば、サイトで会員登録したユーザー情報と、その会員のサイトでの購入履歴は同じテーブルに格納することは基本しません。
まったく用途が異なるものだからです。
そういった場合は、ユーザーのIDだけを、購入履歴側のテーブルに格納することによって、どのユーザーがいつ、何を購入しているのかが分かるようになります。
 
どこまで同じテーブルに入れ、どれを異なるテーブルに格納するかは、アプリケーションの設計によりますが、要は、効率よくデータベースを管理するか？ということにあります。
 
正規化は詳しくやるとものすごくめんどうくさいので、もっと教えろよ四ツ屋！という方は、こういうサイトをご覧頂くといいかなと思います。
 

 

www.fellow-ship.com