業務システムの保守について

今回は契約先企業に常駐し、社内システムを保守する仕事について、お話しいたします。

社内システムを利用する利用者には様々なニーズがあります。
一般的に、そのニーズを取りまとめする担当は、社内情報システム部門となります。

情報システム部門には、多くの相談が寄せられます。
・画面に項目を増やしてほしい
・画面の操作を簡略化してほしい
・入力する文字数を増やしたい
・チェック機能を追加したい     etc…


他にも業務のやり方の変更や規定見直しによるものなど、様々な話があります。
システム保守担当者の仕事は、利用者のニーズを聞くところから始まります。
システム開発は設計・開発・テストをする事が仕事と思われがちですが、
実はその工程に入るまでにも、重要なステップをいくつも踏んでいます。
今回はその件に少し触れたいと思います。


社内システムは、部門別又は専門性のある業務に特化した機能が多く
別のシステムやデータベースと連携させている場合が多い。

利用者から見えているシステムは、氷山の一角。
実はシステムの裏側に複数の処理や制約が入っています。
場合によってはそのシステムだけでは完結しない別システムの仕様も存在します。
それらは、当然システム仕様書に記載されていますが、
利用者がそれらを理解しているわけではありません。

■要望の背景の確認
スタートは利用者の声から始まります。
利用者から「ボタンを増やして欲しい」とニーズが出てきます。
システム保守担当者は、利用者のニーズが、社内システムに対して、
理にかなっているのか、ヒアリングします。
・「ボタンを増やしたいのはなぜか」
・「それをすることで誰がどう助かるのか」
・「どうしてそんな要望を出されているのか」

すると徐々に利用者のニーズが「ボタンが欲しい」のは、
「誤操作の抑制」や「新たな業務の追加、変更」である等、
「ボタンが欲しい」本当の理由が浮き彫りになってきます。

ニーズの理由を聞き出す作業が、案件化の前準備になります。

■改修すべきかどうかの判断材料の作成
利用者の「本当の理由」を聞き出した後に進めるのは、
「改修要否の判断材料集め」になります。
現場によって様々ですが、大きく以下のポイントを押さえます。
① 改修することで得られる効果
② 改修に掛かる時間(工数)の算出
③ 上記①と②を比較した上での費用対効果の算出

少し難しい話ではありますが、
「改修することで得られる削減費用」と「改修することで発生する費用」を比較。
※削減時間と改修にかける費用が見合っているかどうかを数値化する作業。

一般的に「定量効果」と呼ばれるものですが、とにかく比較できるようにします。
これらもシステム保守担当一人では作成できませんので、
利用者やシステム開発担当と相談し、時間を確認していきます。

場合によっては今の現場の環境だけでは対応出来ず、
新たなソフトやサーバーを構築する可能性もあります。
全てを自身で算出する必要はありませんが、いかに根拠のある数字にするかが、
技術者の腕の見せ所と言ったところでしょうか。
なお、「定量効果」が少ない場合も、
数字に表せない効果(法令対応やチェック処理強化による誤記入抑制等)は、
「定性効果」といい、こちらを提示することもあります。

■現場の空き状況や納期の確認
上記の試算で効果があると見越した場合、
次に考慮すべきは納期や現場の空き状況になります。
場合によってはこちらを先に進める場合もありますが、
どれだけ効果があったとしても、それを対応できるシステム開発担当者が
居なければ対応はできません。効果が高く是非とも対応すべきとなれば、
現在進めている案件を調整して本案件を進める等、調整が必要になります。
これらも判断材料として検討した上で資料化します。

■システム保守担当者の仕事 (案件化に至るまで)
これら全ての情報を資料化して、
ようやく、判断材料を情報システム部門へ提供できる流れとなります。

情報システム部門担当者は、
私たちが準備した資料(判断材料)と、システム保守担当者の補足説明を聞きながら、
対応すべきか否かの判断を行います。
一度で終わる場合もあれば、何度も資料の修正、打合せを繰り返す場合もあります。

幾度の判断の後、システム開発が必要となり初めて、顧客ニーズが案件化しスタート
されます。

■最後に
上記はシステム開発案件に至るまでの一例です。いかがだったでしょうか?
企画提案に近い流れではありますが、システム保守担当者の仕事(一部)であり、
あまり知られていない仕事の一つです。
ここまでの間にプログラムを触ることは一切ありません。
※解析や仕様書の読込はありますが。

技術はあるに越したことはありません。
けれどそれが全てではない、そんな風に思っていただければ幸いです。

Posted in エンジニアブログ |

オンサイトという働き方

お客様先に常駐してシステム開発の要望に応える形です。
そのため様々な業務に携わることができます。

お客様が困っていることについて、

  • ・何に困っていて
  • ・どうしたいと考えられているか
  • ・何が出来れば満足されるか
  • ・どうやって実現していくか

など予算・工期・環境などのお客様内の制約の中で
様々な角度から検討・議論してシステム開発を行いリリースします。

無事にリリースされると利用者の反応を直接感じられることが多く、
仕事のやりがいを感じることができると思います。
その分トラブルなどの厳しさについても感じられることが多いため、
身が引き締まる思いをすることがあるのも事実です。

なお、様々な業務に携わることが出来るため
業務ごとの変化に対応する必要があり大変だとは思いますが、
聞いて理解し、考えを提案する楽しみがあり、対応力が鍛えられます。

また、お客様だけでなく常駐先の社員や同業他社の方など
様々な立場の人と仕事をするため、
いろいろな考え方を吸収できる機会や刺激を受けることが多く成長につながります。

特に一緒にプロジェクトに携わった方々とは苦労を共にすることから、
プロジェクトが終わった後に良い関係性が出来上がっており、
別の仕事に声をかけていただけることもあります。

ここまで書くと中々求められるスキルが高そうだと尻込みするかもしれませんが、
仕事に取り組む姿勢など結果だけではなく過程も評価していただけることから
経験の浅い若手なども成長を見越してチャレンジさせてもらえますので安心してください。

他にも魅力はいろいろとあると思いますが「オンサイト」という働き方いかがでしょうか。

Posted in エンジニアブログ |

電話自動音声案内基盤の構築

電話自動音声案内基盤の構築

〜 ヘルプデスクの問い合わせ負荷改善 〜

事例:ヘルプデスク(代表番号)にお問い合わせが集中する

undefined

 

ヘルプデスク(代表番号)の課題例

例1)「ヘルプデスク」=「困った時の問い合わせ先」というイメージが一般的で、簡単に解決できる様な内容でも問い合わせが入り、本来、問い合わせるべき内容や緊急性・重要度の高い(クリティカルな)問題の問い合わせが滞ったり、対応が遅れる場合がある。

例2)問い合わせ内容とヘルプデスク担当者のスキル(担当分野)がアンマッチで、適切な解決に導くまでに時間が掛かる場合がある。

例3)在宅勤務で、ヘルプデスク(電話設置場所)に人がいない場合、受電できない場合がある。
不在前日に電話転送の設定を実施すれば受話可能だが、(例2)の状況が発生する。
※転送先を複数割り当てられないなどの課題も残る。

例4)災害時や停電時など、物理的に受電できない場合、復旧に時間が掛かる可能性がある。

 

AWS を活用した音声案内基盤

AWS が提供している「コネクトセンター」サービスである「Amazon Connect」を利用します。
「Amazon Connect」では、AWSの電話回線契約を新規締結するか、既存回線の移管(※1)も可能です。
音声案内やコンタクトフローの作成は、Web画面上にフローを配置したり、ガイダンス内容はキーボードで入力可能です。
また、プッシュダイアルの入力にも対応可能で、入力内容を元に振り分け先の紐付けも比較的容易に作成が可能です。

※1:既存回線の移管に関しては、AWSの規定や移管元の回線業者の規約により、実施可否が異なります。

 

Amazon Connect を使用するメリット

①お問合せの切り分けに掛かるヘルプデスクのコスト(時間ロス)軽減が見込める。

②コンタクトセンターの立ち上げが短期間で実現できる。

③従来のコンタクトセンターの構築・運用に掛かるコストよりも費用を抑えられる可能性がある。

④申請すれば、同時接続数(回線数)の上限を比較的容易に変更できる。

⑤ヘルプデスクの拠点(会社)で障害・災害が発生した場合でも、問い合わせが止まらない。
転送先が拠点(会社)の場合は、Web画面上で転送先の変更が可能なため、ヘルプデスクの業務・機能が短期間で復旧できる可能性がある。

⑥すでに保有している電話番号を移管・流用することができる。(可否に条件あり)

 

Amazon Connect の課題

課題1)Amazon Connect で取得する日本国番号(+81)の電話番号は、個人では取得不可能。
電話番号の取得は、会社・団体など組織であることの証明書類を提出する必要があります。
2023年4月28日現在、個人では日本国番号を取得することはできません。

課題2)日本局番で取得できる電話番号には、下記のとおり制限がある。
・直通ダイヤル(DID)番号:
「050」プレフィックス番号
「03」東京都のプレフィックス番号(日本の他の都市の電話番号を提供していません)
・通話無料番号:
「0120」プレフィックス番号
「0800」プレフィックス番号

課題3)Amazon Connect から別回線への転送には、別途追加料金(転送通話分の追加料金)が掛かる可能性がある。
Amazon Connect 内部のユーザー間で転送した場合、追加料金は掛かりません。

課題4)Amazon Connect に移管した電話番号は、移管前の状態には戻せない。
Amazon Connect の設定で、電話番号の解除・開放(デタッチ)を実施した場合、同じ番号を自由に設定(アタッチ)できません。
※電話番号の管理がAWS側に依存するため、一度開放した電話番号は、他社に使用(アタッチ)される可能性があります。

 

Amazon Connect 導入時の注意点

既存の電話番号を移管して、Amazon Connect 環境を構築する場合は、いきなり既存の番号を移管するのではなく、AWS(Amazon Connect)が提供している「050」などの電話番号を使用し、環境構築と動作確認を実施してください。
動作確認の結果、想定通りの運用が実現可能と判断できた上で、既存の電話番号を移管する手続きに進むことをオススメします。
※(課題4)で触れたリスクを回避する意図があります。

主に活用するAWSサービス:

    • ・Amazon Connect
    • AWSが提供するクラウド環境のコネクトセンターサービスです。
      メリット:導入・運用が容易で、一般のコネクトセンターよりコスト軽減の可能性がある。
      課  題:日本局番(+81)の取得は、組織のみ可能という制約がある。(個人取得不可)
Posted in エンジニアブログ |

DDoS(DoS)なんかに負けないぞ!!

DDoS(DoS)なんかに負けないぞ!!

〜 クラウドをうまく活用したDDoS(DoS)攻撃の撃退方法 〜

 

事例:オンプレミス環境のWebサーバがDDoS(DoS)攻撃を受けている

 

DDoS(DoS)攻撃とは?

DDoS(DoS)とは、Webサイトに対して、短時間に大量のアクセスが送られることにより、
Webサーバの想定キャパを超えるリクエストを処理しきれず負荷が高くなった結果、
通常のアクセスが不可能になったり、リクエスト結果が返ってこなくなるWeb攻撃です。
Webサーバの負荷が限界を超えた場合は、サービス停止やサーバーダウンも発生します。

 

オンプレミスのDDoS(DoS)攻撃対策

オンプレミス環境のWebサーバが、DDoS(DoS)攻撃に対して取れる策はいくつかあります。

  1. 想定外の大量アクセス(サーバ負荷)に耐えられる様、CPUやメモリなどのスペックをUPさせる。
  2. DDoS(DoS)攻撃の送信元IPアドレス(国単位IP or 個別IP)に対する
    アクセスの拒否設定を追加する。

デメリット:
DDoS(DoS)攻撃に備えてスペックをUPした場合、一時的にはサーバ負荷に耐えることが可能です。
ですが、DDoS(DoS)攻撃自体を防いでいるわけではないため、より大量のアクセスが発生した場合、
対策がイタチごっことなりランニングコストが上がる結果、サイト運営の売上利益・コストパフォーマンスが低下、さらには、サイト運営自体の継続が困難になります。

特定の国単位のIPアドレスやDDoS(DoS)攻撃の送信元である個別IPアドレスに対して、
サーバー側でアクセスの拒否対象として設定すれば、攻撃自体を防ぐことはできます。
ただし、同じIPアドレス帯からアクセスしてくる一般ユーザからのアクセスも拒否するため、
サイト運営としての機会損失に繋がる場合もあります。

 

クラウドを活用したDDoS(DoS)攻撃対策


弊社では、AWSクラウドをうまく活用(いいとこ取り)して、オンプレミス環境の構成を変えずに
DDoS(DoS)攻撃に対する恒久的な対応と、DDoS攻撃に伴う損失の軽減実現を提案しています。

今回の対策事例では、
オンプレミスのWebサイトに割り当てているドメインをAWSの公開ドメインに移管し、
AWS側からオンプレミスのWebサイトに転送するためのドメインを新規で発行・割り当てる形となります。
公開ドメインと転送ドメインの間にはCDNサービスを設けることで、
AWS内部にWebサイトのキャッシュが保持されるため、
キャッシュされたアクセスに対しては、オンプレミスのWebサイトにアクセスを
転送することなくAWSからレスポンスを行います。
オンプレミスのWebサイトは、AWSがキャッシュしていないアクセスのみが転送されるため、
サーバ負荷の軽減も期待できます。

主に活用するAWSサービス:

    • AWS Shield Standard
    • AWSアカウントを登録すれば無料で使えるDDoS(DoS)攻撃の防御サービスです。
      メリット:DDoS攻撃の自動で検知し、Webサーバへのアクセスを遮断する。
      課  題:無料枠のため、DDoS攻撃のアクセスに対する従量課金は発生する。
    • AWS Shield Advanced
    • 追加料金(有料)で使えるDDoS(DoS9攻撃の防御サービスです。
      メリット:DDoS攻撃のアクセスに対して発生する従量課金分は請求されない。
      課  題:ひと月3,000USDの定額制、かつ、1年間のサブスクリプション契約が必要。
    • Route53(DNS)
    • AWSサービス内のWebサイトのドメインを登録・管理するサービスです。
      メリット:ドメイン取得からドメイン登録設定までが簡単に実施できる。
      課  題:有料サービスしか選べないこと。(無料枠が存在しない)
    • AWS Certificate Manager(ACM)
    • AWSサービス内のWebサイトに対するSSL証明書を発行・管理するサービスです。
      メリット:有効期限の自動更新が可能。外部のSSL証明書の取り込み・移管も可能。
      課  題:無料枠で提供される証明書は、ドメイン証明のみ。
    • Cloudfront(CDN)
    • AWSサービス内のWebサイトに対するCDNを提供するサービスです。
      メリット:CDNにより、レスポンス性能の向上とオンプレミス自体のサーバ負荷が軽減。
      課  題:設定・運用に関する知識が必要。(誰でも簡単に設定できる訳ではない)
Posted in エンジニアブログ |