第13回 ［データモデル編］発注者が確認しやすいようにCRUD図をアレンジする
CRUD図を利用して発注者とレビューをされたご経験はありますか？ CRUD図というと一般的には以下のような図をイメージされるのではないでしょうか。 このCRUD図を使って，機能とデータの抜け・漏れや処理の集中，不完全な分割などがないかどうかを検証する「CRUD分析」で発注者に確認したいことが発生したときに，CRUD図をそのまま見せても，発注者はなかなか理解しずらいものです。 確認したい内容に絞り込んだ表を作成する そこでCRUD図をそのまま発注者に見せるのではなく，以下のようにアレンジしたCRUD図を作成してみましょう。 この図のポイントは以下の通りです。 ・申請書作成や承認といった処理のタイミングごとに，各エンティティの作成，参照，更新，削除があるかどうかを表した表形式にする。 ・確認したいエンティティとタイミングのみ記載する。 ・エンティティの数が多い場合は分類する。 ・作成，参照，更
顧客の膨らむ要望にいかに対処すべきか
顧客の要望から、プロジェクトはスタートするといっても間違いではないだろう。とはいえ、どこまで顧客の追加要求を受け入れるべきなのだろうか。そうした点を解説する。 プロジェクト管理で最も重要な課題 プロジェクトマネジメントで最も重要な課題は、 「『成果の設定（仕様の確定）』と『仕事の設計（作業の洗い出しとスケジュール化）』は不確実である」というリスクへの対応 プロジェクトが「うまくいっている」「うまくいっていない」の判断 の2点であると解説しました。これらの内容については、前回の「プロジェクトマナージャは、説得術を磨くべし」をお読みください。 さらに1つ目の課題の対応策として、大別して下の5通りの方法が存在することをお伝えしました。 客に要件定義を依頼 契約の見直し 「成果の設定」「仕事の設計」の精度向上 関係者への説得・承諾 追加要求の影響を最小化 今回は、5の追加要求の影響を最小化、かみ砕
［要件定義/システム設計編］要件のふくらみ
要件定義やシステム設計の不具合も，プロジェクトマネジメントの不備に次いで，プロジェクトが火を噴く大きな原因である。例えば，システム要件が当初の予定よりもふくらんだり，要件定義/システム設計が甘いために手戻りが発生してプロジェクトが遅延する，といったケースだ。 そこで，（1）要件のふくらみ，（2）要件定義の遅れ，（3）設計/アーキテクチャの不備，といった理由による火事の火消し術を事例を基に紹介していこう（図1）。 （1）要件のふくらみ ギブ・アンド・テイクで削減 利用部門の追加要件を受け入れて，システム要件が当初の予定よりもふくらんでしまうことは多い。読者も経験したことがあるのではないだろうか。実際，利用部門とプロジェクト・メンバーがその場の話し合いで要件の追加を決めるケースは少なくない。プロジェクト支援などを手がけるテクノサージの佐藤義男氏（ビジネスコンサルティング事業部長）も「利用部門か
テキストマイニングで顧客対応力強化を図る
テキストマイニングは、コンタクトセンターの情報発信力の強化だけでなく、ほかでも有効である。そのキーワードとなるのが顧客対応力である。その点を解説する。 3-1 顧客対応力を高めるキーはFAQ なぜ、顧客対応力を向上させることがコンタクトセンターに求められているのだろうか。それは、顧客との重要な接点になってきたコンタクトセンターの対応品質が、顧客が企業の姿勢を判断する1つの重要な要素となっているからである。 例えば、『コールセンター白書 2007』（リックテレコム刊）の「通販会社を評価する際、オペレータの対応品質がどの程度影響するか」（n=300）という質問に対して、「その後の利用を左右するほど大きな影響がある」が18％、「かなり影響がある」が43.3％、「オペレータの対応よりも商品の質などを要求するのでさほど影響はない」が38％、「まったく影響しない」が0.7％とあり、約6割の人がコンタク
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
