このコラムは、株式会社エル・ティー・エスのLTSコラムとして2015年2月から連載を開始した記事を移設したものです。
ライター
好印象:情報サービス産業は親しみやすさが大切な職業
挨拶や身だしなみといった社会人としてのマナーが好印象に繋がることは改めて説明することではないと思いますが、システム開発の現場で気を付けた方が良いことのひとつとして「専門用語」の使い方が挙げられます。カタカナ用語やアルファベット3文字の略語を使ってお客様との打ち合わせを進めていませんか?無意識に専門用語を使っている可能性が高いのでメンバー同士で注意しておくと良いと思います。
迅速性:納期遵守は当たり前、納期までの振る舞いが大切
「納期の設定」:誠実な納期回答が顧客満足を向上させる
お客様は「ベンダーが担当している作業がいつ終わるのか知りたい」という事前期待を持っています。したがって、納期を遵守する以前に、納期を事前にしっかり回答することはプロセス品質の基本です。ちょっとした作業でも必ず納期を明確にするようにしましょう。また、迅速性という名の通り、納期はお客様の期待するスピード感に合っている必要があります。ベンダーの目線で優先順位を決めるのではなく、お客様が期待している納期を確認した上で優先順位を決めて、その期待を超えるスピードで対応するべきだと言えます。
「進捗の報告」:タイムリーな進捗報告は、迅速性の価値を高める
ベンダー側からすれば作業は順調でとくに報告するようなことはない場合でも、お客様からすれば進捗状況がまったく報告されないのは不安です。「順調に進んでいます」の一言だけでもお客様は安心するものです。万が一なんらかの理由で作業が納期に間に合わないリスクが発生した際は、その理由を含めすぐに状況を報告し、納期を再調整しなければなりません。最悪なのは、納期直前や納期を過ぎてから報告することです。
「納期の遵守」:お客様の立場で「納期遵守」を考える
納期はただ守ればよいというものでもありません。納期当日に提出された成果物が不完全な状態だった場合、それは「納期遵守」とは言えませんよね。「間に合ったから良いでしょう」という姿勢では、顧客満足を得られるわけがありません。
ここまで見てきたように「納期」という単純な言葉の中にも、お客様の満足度を左右する要素はたくさんあることがわかります。やみくもに納期を守れればいい、ということではなく作業の過程全般の顧客満足を考えて納期を遵守したいものです。
正確性:正確性でトラブルは許されないが、正確性で感動サービスは作れない
迅速性と並ぶ基本的なプロセス品質が正確性です。システム開発に限らず正確な情報の伝達やミスのない対応はサービスの基本です。
「共有事項の明確化と遵守」:チーム全体で約束事項の共有と引き継ぎを大切にする
プロジェクト開始時にはベンダーがお客様に約束した事項について、チーム全体で同じ認識を持っている必要があります。きちんと共有していないと「営業が提案時にお客様に約束したことを現場にきたSEが知らない」ことでお客様からクレームがくる、ということが起こってしまいます。また、お客様メンバーとも情報を共有しておかなければお客様の期待がどんどん膨らんで「これもやってくれるはずじゃなかったの?」と過剰な作業の依頼を招くこともあります。この他、お客様先の情報セキュリティやコンプライアンスに関するルールは、お客様によって大きく異なりますのでしっかり確認しておくことが大切です。(後から参画するメンバーへの共有も忘れずに!)
「状況の正確な把握」:プロジェクト状況を把握するには、正確に報告する風土を醸成する
プロジェクトマネジメントの世界では、プロジェクトの状況をどのように定量的に管理するかという議論を長く続けてきました。EVM(Earned Value Management)※1 のような可視化手法を使うことは大切ですが、その難しさは理論よりも正しい報告がされるプロジェクトの風土を作り上げるところにあります。進捗報告のミスやチーム間での記述の矛盾、お客様側の認識と違う報告など、この種のトラブルはよく見かけます。遅れの原因や現場の状況、人員の士気を把握せず、ただ進捗の数値だけを気にしたマネジメントをしてしまうと、このような事態が起こります。
コストとスケジュールの両面からプロジェクトの状況を正しく把握し、将来の見込みを予測するプロジェクト進捗管理手法。
「成果物の欠陥防止」:ミスだらけの成果物では、基本的な信頼関係を築けない
作業が進むと避けて通れないのが成果物の欠陥防止という観点です。ここではプロセス品質の話をしていますので、ソフトウェアそのものの欠陥についてはとくに触れませんが、設計書や仕様書といった文書、進捗報告書や議事録など、プロセス品質の観点からも欠陥を防止すべき対象がたくさんあります。
正確性にこだわりすぎて顧客満足を下げている日本のSE
さて、システム開発サービスに従事する方の中には、ここに書かれていることを当たり前に感じた方も多いと思います。しかし、大切なのはここに書かれたような正確性をひたすら守ることではなく、この正確性を他の品質とうまくバランスを取るところにあります。プロジェクトで正確性だけにこだわりすぎると、それが原因でお客様の満足度を下げることもあるのです。正確性にこだわり、迅速性や柔軟性といった他の品質とのバランスを損ねると、顧客満足を下げてしまうことがあります。他にも以下のような例が挙げられます。
- 仕様凍結後の仕様変更は一切認めず、お客様の要望を実現しようとする姿勢を見せない
- 技術的に正確な言葉にこだわり、お客様の理解度を考慮しない
- 会社間の役割分担にこだわり、お客様が困っていても作業を助けない
- ちょっとした変更でも「当初の前提からずれた」ということで再見積りする
実際のプロジェクトでは計画変更や決定事項の変更が発生することは珍しくありません。もちろんプロジェクト全体を考えて断るべき依頼もありますが、ただやみくもにルールを盾にして当初の計画にこだわりすぎても、お客様が困るばかりでなく、ベンダー側も自分たちの作業を進めることができなくなってしまいます。したがって、全体最適を考えて、状況に柔軟に対応する姿勢がベンダーに求められています。
ベンダーはシステム開発の投資対効果に責任を持つ立場ではないですから「動くシステムを作るだけであれば、仕様は早く凍結してしまったほうがいい」「提案時の前提と違うことが起きれば再見積りとしてしまったほうが合理的」というような思考になりがちです。動いたシステムがユーザー企業のビジネスに十分に貢献しなくても、悪い言い方をすれば「自分たちには関係のないこと」なのです。
しかし、システムの投資対効果に責任を持つユーザー企業側の責任者はそうはいきません。結果的にベンダー側の無責任と見られる姿勢は顧客満足を下げる要因になっていきます。本来、お客様と一体感を持ってプロジェクトを推進していかなければならないのにそうできないのは、ベンダーに何が欠けているからなのでしょうか。現在のベンダーに絶対的に欠けている品質要素こそが次に触れる共感性なのです。
というわけで、次回は共感性・柔軟性・安心感について掘り下げていきます。
サービスサイエンスによる顧客共創型ITビジネス
本書はビジネスをサービスの論理から改善するための「サービスサイエンス」に基づくITビジネスについての書籍です。システム開発会社、企業のIT部門、サービスサイエンスを駆使してプロジェクトを成功させていく方向を明確にしていきます。
著者:諏訪 良武, 山本 政樹
出版社:翔泳社(2015年1月28日)