目次
Contents
これまでの記事
・コールセンターの運用について ～第１回 運用保守～
・コールセンターの運用について ～第２回 開発～
前回まででコールセンターシステムの運用保守・開発について実体験を交えながらご紹介させていただきました。
さて、エンドユーザーであるお客様自身が実際にコールセンターシステムの運用保守を行っているメンバーに対して開発依頼を行う場合、システム開発のプロセスや開発環境については直接触れることはほとんどありません。
そのような中で開発されるシステムに不安感を感じる方がいらっしゃるかもしれません。
そこで今回は「コールセンターシステムの運用について 第３回 運用保守サービスの品質」と題して、開発案件を実施する上で常に気を付けていることについて、いくつかご紹介してみようと思います。
【運用保守サービスの品質とは】
私が考えるコールセンターシステムの「運用保守サービスの品質」とは、お客さまへ納品しているシステムの品質そのものと直結しています。
お客様へ納品したシステムの評判が良ければ、品質の高いサービスだったと評価していただけるでしょう。
反対に納品したシステムの評判が悪ければ、品質の悪いサービスだと評価されてしまい、システムを運用保守する会社としての評判も悪化させてしまう恐れがあります。
そんなシステムの品質についてですが、私は次の３つで構成されていると考えています。
[ 案件への理解度 ]
開発を担当する案件について、担当するメンバー全員が依頼内容についてどれだけ理解できているかです。
私が参加していたコールセンターシステムの現場は、十数年続いているような歴史のあるシステムが対象でした。
それだけ期間が長くあるとシステム自体も複雑なものになっていました。
この場合、重要なKEYのひとつに、設計思想の理解があります。開発当時はどのような目的で設計されたものか、この理解が浅いと要求仕様や処理・機能間の連携の見落とし、運用上の齟齬といった障害を発生させてしまう危険があります。
第二に、当然ですがプログラムや改修履歴の理解です。これによってどのようなリスクがあるかは語るまでもなく、これまでの経緯やその理由を把握しておくに越したことはありません。
たとえ小さな変更プロジェクトでも参加メンバーが経緯や改修履歴についてきちんとした理解ができていなければ、当初の想定とは異なったシステムをお客様に納品してしまうことになりかねません。
[ 開発者の技術力 ]
重要視するのは、開発者一人一人が保有する技術的知識と、過去の経験から培ったノウハウです。
私が参加していたコールセンターシステムの案件は稼働期間が長く歴史あるシステムです。多くの技術者が参加し、たくさんのプログラムが実装されていて、それらの中には簡潔で分かりやすいプログラムもあれば、複雑でわかりにくいプログラムも存在します。
それらを読んで感じたことは、技術的知識が豊富な人が優秀なシステムを作れるわけではないということです。
システム開発では１つのプログラムに多くの人が修正を行います。
プログラムを作成する際に複雑なロジックを盛り込んでしまうと、修正する際にそのプログラムを理解できず障害の原因となってしまう可能性があります。
以上のことから、技術力とは「誰にでもわかりやすい開発を行う技術」であり、そのために必要なのが“ルールの作成”と“ノウハウの蓄積”だと考えています。
[ コミュニケーション ]
プロジェクトにおけるコミュニケーション管理です。文字通り人と人のコミュニケーションのことを指しているのですが、私が特に重視したことはお客様へのレスポンスです。
プロジェクト中はお客様から開発者への要件の追加依頼や開発状況の確認など確認事項は尽きません。このような確認事項は、担当者からの返答が遅延しがちだったり、返答内容があいまいであったりすると、不安を覚えてしまいます。お客様の抱いた不安は、結果的にプロジェクト内での問い合わせが細かくなったり、期日が必要以上に厳格になる等の行動に反映されていってしまいます。
このことから、品質には、お客様・エンジニア双方が安心してプロジェクトを推進できるコミュニケーション環境が重要だと考えられます。
また、近年ではIT関連のインシデントも世間に広まりやすい世の中です。
実際には関係のない事案だと分かっていても、お客様はどうしても不安を覚えてしまうことがあります。そのような場合のレスポンスの速さや内容次第では、お客様が余計な心配を抱えてしまいかねません。
そうならないためにも、正確な内容を可能な限り迅速にレスポンスすることが大切です。
【質を向上させるための取組み】
運用保守・開発のサービスの質について、私の意見を前述にていくつかご紹介しました。
この章では、それらの質を向上させるための取組をご紹介します。
[ 案件への理解度 ]
やはり大事なことは、依頼書をしっかり確認することと、依頼書の内容についての詳細を必ずお客様に確認することです。
自社で以前に請け負ったシステムの場合であれば有識者がチーム内にいたりします。
そうでなくてもドキュメントが残っていれば、それらを活用することで、担当する案件について理解を深めることは可能です。
ただし、新しいプロジェクトではそういうわけにはいきません。
新規または運用期間の短いプロジェクトだと、そのプロジェクトの理解度は参加メンバー全員がほぼ同じであるケースが多いと思います。このような場合も重要なことは、やはり依頼書をよく読み込み、その設計思想やシステムの目的を理解することです。特にコールセンターシステムの場合はシステム利用者であるコールセンターの先には必ずコンシューマーが存在します。依頼書の読み込みは最終的にはコンシューマーの利用シーンまでを想像・理解するように努めています。
そうすることで、案件内容やお客様の意図などをより理解することができます。
また、依頼書を確認する中で不明点が出てくることもありますが、そのような時は必ずお客さまと会話しましょう。
依頼書の確認はお客様との信頼関係の形成に役立つ上に、障害も未然に防いでくれます。
不明点の洗い出しは、１人の読み込みでは漏れてしまう可能性もあるので複数人でのレビューをおススメします。
案件への参画歴の短いメンバーをアサインすれば理解度も増すことができ、プロジェクト全体の品質向上にも繋がります。
[ 開発者の技術力 ]
重要視するのは「誰にでもわかりやすい開発を行う技術」です。
私が参画したプロジェクトは比較的運用期間の長いプログラムが多く、その場合は前述のとおり多くの技術者が参加し、たくさんのプログラムが実装されていて、それらの中には簡潔で分かりやすいプログラムもあれば、高度だが複雑でわかりにくいプログラムも存在します。実際にプログラムを後から改修する場合は前者の方が圧倒的に作業がし易く障害のリスクが低いことは言うまでもありません。
また、このような個人による属人的な開発を防ぐためには、プロジェクトの「ルールの作成」と「ノウハウの蓄積」が何よりも大切です。開発工程だけではなく、後々の運用・保守までを想定した計画の作成が必要不可欠となります。
[ コミュニケーション ]
私はコミュニケーションの質を高めるため次の３点を常に意識しています。
・話しやすい雰囲気づくり
・相手の話をよく聴き、意図を理解する
・相手が理解できる言葉で話す
お客様と会話をする時、私たちは「お客様が抱える課題を正確に把握する」必要があります。
そのためには、お客様からの話を引き出すことが重要だと考えています。
お客様が気兼ねなくお話しできるように、より良い雰囲気作りを心がける。
お客様の話される言葉をしっかり聴き、何を伝えたいのかを理解する。
こちらから話す場合は専門用語の使用は避け、分かりやすい言葉に置き換えながら話す。
全て簡単なことですが、常に意識しながらコミュニケーションをとることで、自然と質も高まってくると思います。
【まとめ】
今回は「コールセンターシステムの運用について ～第３回 運用保守サービスの品質～」と題して、運用保守・開発サービスの品質やそれらを高めるための取組についてご紹介しました。
お客様へより高いサービスを提供することは、そのまま会社への信頼につながります。
逆にサービスの質の低下は、そのまま会社の信頼の低下につながってしまいます。
今回ご紹介した「案件への理解度、開発者の技術力、コミュニケーション」はあくまで私個人の意見となりますので、もっと大切なことがあるかもしれません。
お客様に提供しているサービスについて、どうすればより高品質のサービスを提供できるかを常に考えながら業務を行うことが、巡り巡ってより質の高いサービスの提供につながると考えています。
これまで３回にわけてコールセンターの運用に関するついてご紹介してきました。
それらの情報が少しでも皆様のお役に立てたのであれば幸いです。
記事：Y.F
