顧客満足度＝SE の充足感？
〜要望にお応えするのが仕事です
文：株式会社ビーブレイクシステムズ

鹿取裕樹

■

で閲覧できる仕組みを提供し、作業効を言うものである。そして、その欲張■プロジェクトの概要
プロジェクトの概要

率の向上を行う機能

りを叶えることがビジネスの最大の目■

IT 業界に限らず、顧客は「欲張り」的のひとつであると思う。

今回紹介するプロジェクトは、カス・FAQ機能

ただ、システム構築に関してはビル

タマーサポートセンターの運営業者がの建設や Web ページのデザインと違エンドユーザーであり、センター業務い、顧客の要望を目に見える形にするを運営するにあたって、オペレーターことが困難である。

およびその管理者の負荷を軽減するた

Web サーバの OS は Linux、サーブめの業務支援ツールの導入を行うとい

レットコンテナには Tomcatを採用しうものだ。

た。DBサーバのOSもやはりLinuxで、もちろん、画面などのモックアップを作ることで、概要レベルでの顧客の顧客からの質問に対して適切な回答を導き出すための支援ツール

承認は得られるが、システムの振る舞作業効率を向上し、顧客に対する正RDBMSにはPostgreSQLを用いた。まいまで見せることは期間・費用の面か確で迅速な対応を実現すること、そした、フレームワークとして自社フレーら、まず不可能である。てオペレーターによる案内業務の均一ムワークを用いている（図1）。

システムができあがり、それを確認するまでわからないのだ。たとえるならば、床屋で自分の望む髪型を正確に理容師に伝えることが難しいように、化を可能とすることがシステム構築の目的である。
システムの主な機能は、以下の 3 点であった。

顧客が我々ITエンジニアに正確な仕様を伝えることは難しいのだ。

・インフォメーション機能
担当者への連絡事項、顧客の状況把ことができたとしても完璧にそのとお握などの情報を提供し、迅速な対応をりに施術できる理容師が少ないように、可能にする機能

IT技術者もそれを実行するのは難しい

今回はそうした現場の実際をお伝えしたい。

100

Linux magazine March 2005

センターのオペレーターと管理者がイントラネット経由でWebブラウザでアクセスする。
■

さらに言えば、髪型を正確に伝えるのだ。

このシステムにカスタマーサポート■開発体制とスケジュール開発体制とスケジュール■
このプロジェクトを筆者の所属会社がすべて請け負うことになった。筆者がこのプロジェクトに参画したのは要・共有文書閲覧機能

件定義の段階からであった。

画面操作説明、受信機の取扱説明書、当初、顧客企業が望むすべての機能事務連絡表などの文章をWebブラウザ

を 3カ月以内に納品してほしいとの要望であったが、その期間内で全機能をった。それぐらいタイトなスケジューりたいと感じていたのだ。

ルだったのだ。

開発・テストすることはスケジュール以上のような経緯により、このよう的に難しいと判断し、最低限必要な機な非常にタイトなスケジュールとなっ■能だけを1次開発として3カ月以内に部たのである。

■背水の陣

背水の陣

■

分カットオーバーし、残りの機能をさユーザーはこのプロジェクトについらに 3カ月かけて導入することになって何社かに見積りを取っていたようだ

まずはキックオフミーティングが行た（図2）。

が、開発期間が短いということもあり、われた。ユーザー企業からは、経営企よくあることだが、もともとは現行ほとんどのベンダーが実現は難しいと画室の執行役員を始めとした情報シスの開発時期より 2 カ月前から開発を行判断し、受注をあきらめていたようだ

テム部のメンバーが参加した。

う予定であったが、パッケージ製品を使用するか、システムを新規開発するかどうかの選定に手間取り、すでに開スケジュール始時期が当初の予定よりも遅れていた5カ月間のだ。
また、このカスタマーサポートセン

1次開発

要件定義

設計／実装／テスト

ターでは問い合わせを行う顧客の数に対してオペレーターの数が不足してお2次開発

り、システムを導入することで業務の要件定義設計／実装／テスト効率を上げる必要があった。そのため、どうしても早期にシステムの導入を図

図2 参考事例の開発スケジュール

カスタマーサポートセンター

カスタマーセンター業務支援システム
現用系

イントラネット
待機系
DBシステムLinux PostgreSQL

WebサーバLinux
TomcatApache
自社フレームワーク※全サーバでRAIDを使用

図1 参考事例のシステム構成図

March 2005 Linux magazine101

Development

開発側は、すべて筆者の所属する会いった。

た、重要であると思われる項目につい社の社員だ。短期間の開発であるため最初のころはミーティングに H室長ては、必ず H室長が出席しているミー

エンジニア同士のコミュニケーションも出席し、議事録を承認してもらってティングで決め、議事録の承認をもらに工数を割けないという理由により、いた。ただ、H室長はシステム開発だうこととした。さらに、H室長欠席時外注は使わない方針となった。ただ、けではなく会社全般の業務を行っていに決めた項目は、承認を得られた内容

開発工数と参画するエンジニアの数をるため、ミーティングを欠席することであっても、H室長が出席した際に再比べると、明らかにリソースは足りてが多くなった。そのため、ミーティン度口頭で確認するようにした。

いなかった。そのため、土曜日を返上

グに出席していないぶんの議事録を、議事録が承認されているのだから、した形でスケジュールを組むことにな

あとから H室長に承認してもらうことそれ以上のことをするべきではないとった。

がたびたびあった。

いう意見もあるかと思うが、やはり、また、このスケジュールを組むにあ要件定義も中盤に差しかかった頃、ユーザーの望むことを実現するのが仕たって、以下の 2点についてユーザーミーティング中に H室長が以下のよう事である以上、これは必要な作業であ側から確約をもらった。

な発言をした。

ると考え、ユーザーにしつこいと思われるくらいに要件定義の内容を確認し①要件定義の段階での当社が指定した「その機能がなくなると困るなぁ」

スケジュールの確保ていった。
■②ユーザー側の理由で、要件定義／仕「あれっ？」と筆者は思った。それ■土曜日返上 土曜日返上

様確認／ユーザーテストが遅れた場

は、すでに以前のミーティングで承認■

合は納期を保証できないことされた話なのにと。
「いや室長、それは前のミーティング

要件定義の段階を終え、社内でのコーディング作業に入った。

上記①のユーザーのスケジュールので、Webでは実現するのは難しいから冒頭で触れたように、最初から土曜確保にも土曜日が含まれていた。それ機能を省くって話になったじゃないで日をスケジュールに組み入れていたたぐらい切迫したスケジュールであった。

すか。議事録にも書いてありますよ。
」

め、週6日PCと「にらめっこ」するこ

まさに背水の陣である。とユーザー側のシステム部員がフォロととなった。

■

ーを入れてくれた。私はホッとしながひとつ断っておきたいのは、1 日あ■議事録の限界
議事録の限界ら、心の中で「その通り！」と叫んでたりの作業時間は10時間前後であると■いた。

いうことだ。「だったら、1 日 13 〜 14

このプロジェクトでは、プロジェクその機能をWeb上で実現するのが難

時間作業すれば土曜日に作業する必要トを進行していくうえで、ユーザー側しいことは、情報システム部員にはわはないのでは？」と思われる読者もいのプロジェクト責任者である執行役員

かっていても、システムのプロではなるかと思う。

（以降、H室長と呼ぶとこにする）の承い H室長にはわからなかったのだ。さが、やはり人間の集中力が続くのは認が絶対条件であった。

らにまずかったのは、そのことを話し1日あたり8時間程度が限界だ。それを合ったときに H室長が欠席していたこ大幅に超過して作業しても作業効率はとである。

よくならないと考え、土曜日に作業を切迫しているプロジェクトではドキュメントを省くケースがよくあるが、筆者の勤める会社では、過去の経験かおそらくは他の業務に忙しかったせら最低限、議事録を取ることになっていか、議事録の内容をよく理解するこいた。

ともなく承認していたのだろう。

行ったのだ。
土曜日に出社すると、思いがけないことを感じるものだ。

今回のプロジェクトでもそれに倣い、これ以後、H 室長に要件定義の重要

まず、通勤の電車が空いていて座れ議事録を取り、それをユーザー側に承性を説明し、できる限りミーティングる。筆者は平日7時30分くらいに自宅認してもらいながら要件定義を固めてに出席してもらうようお願いした。まを出るのだが、平日にはまず座れたこ

102Linux magazine March 2005

とはない。それに通勤定期を有効活用

語をユーザーにわかりやすい言葉で伝現場管理者の判断で以前から業務用にできたと、ちょっと得した気分にもなえられるよう考えていたので、ユーザ使っていた PC もオペレーター用のクれる。休日出勤手当が付き給料が一時ー説明会はスムーズに進行し、特に問ライアントマシンとして使用していた。

的に増える。などなど、できる限り土題なく終了した。

曜出勤をポジティブな気持ちで楽しみながら出勤していた覚えがある。

しかし、このままでは終わらなかったのだ。

正直なところ、このプロジェクトの請負い範囲はソフトウェア開発である
ため、クライアント PC のスペックの食事については、事務所がオフィス説明会後、1 カ月くらいしてから筆指定までは行ったが、PCの購入・管理街にあるということもあって土曜日は者のオフィスにかかってきた一本の電については、すべてユーザーまかせに周辺の定食屋は閉店しており、休日に話……

していた。そのためこのような事態に陥ってしまったのだ。

関係なく開店している牛丼チェーン店をもっぱら活用することとなった。ち「FAQシステムのキーワード検索に時間

今後は、お客様のためを考えるのでょうどその頃、そのチェーン店が 3杯がかかります。そのためお客様にお待はあれば、顧客との契約範囲をサポー食べたら 1杯無料というキャンペーンちいただく時間が長くなってしまいま

トするだけではなく、その範囲外であを行っていたせいか、それ目当てに土す。どうすればよいですか？」っても、システムを利用するにあたって大事だと思われることは積極的にサ曜日に限らず牛丼ばかり食べていた記
オペレーターの管理者からだった。

ポートしていくことも重要であろうとその牛丼パワーのおかげで（？）
、無

今回のプロジェクトでは、「FAQシ思った。

事コーディングとテストを終え、カッステムのキーワード検索時のレスポン■

トオーバーを迎えた。

スは 5 秒以内に収める」という仕様が■1通のメール1通のメール■あったため、この問い合わせ内容が事■

ユーザー説明会後■ユーザー説明会後

実であれば仕様を満たしていないこと

■になる。

憶がある。

キーワード検索の件から 1 カ月ほど経過した頃、（PCのせいとはわかってあたりまえのことだが、実際にシス十分に負荷テストも行い、レスポンいながら）FAQ機能のレスポンス状況

テムを使うのは、H室長でも、情報シスに問題はないとの結果だったのにどが気になったので、筆者はオペレータステム部でもない。お客様と接するオうしてだろうかと思いながら、さっそーの管理者にその後のシステムの稼働ペレーターである。

く調査に入った。

状況を尋ねるメールを送った。3、4日
して以下のメールがきた。

カットオーバーの段階では H室長かSQL文の書き方、キャッシュの状況、らある程度の満足感は得られていたが、DB のパフォーマンスなど、考えられやはり実際のユーザーが「使って」、ることをすべて調査したが、特に問題「ご連絡ありがとうございます。メー「試して」、「評価する」ことで、初めは見つからなかった。

ルいただいた件ですが、今のところ問さらに深く状況を確認するためユー題なく動いております。また、何かごザーを訪問したのだが、そのときにあざいましたらご連絡差し上げますので、もちろん、本番システムが動くかどることに気がついた。すべてのクライ

その際は宜しくお願いします」

うかを確認するカットオーバー時も非アント PC でレスポンスが悪いわけで常に緊張はしたが、それ以上にユーザはなく、スペックが劣るものだけが処ーの反応は気になるものだ。

理が遅れていたのだ。てシステム構築の成否は判断されるのだと思う。

特になんてことはないメールの文面ではあったが、ユーザーとのスムーズ

今回の契約ではマニュアルの作成ま最初の話だと、システムを導入するなコミュニケーションが取れたことにで依頼されていたこともあり、筆者がに当たってクライアント PC は開発側よる妙な満足感があった。また、誰のシステムのユーザー説明会を実施した。

が指定したスペック以上のマシンを新ためのシステムなのかを身をもって感説明会前夜、システムの内容や専門用規購入することになっていたのだが、じた瞬間であった。

March 2005 Linux magazine

103