ヒアリングシート兼案件概要 御客様名 ：ｘｘｘｘｘｘｘｘｘｘｘｘ 案件名 ：ｘｘｘｘｘｘｘｘｘｘｘｘ ヒアリングシート兼案件概要 　　御客様名 ：ｘｘｘｘｘｘｘｘｘｘｘｘ 　　案件名 ：ｘｘｘｘｘｘｘｘｘｘｘｘ 適宜変更して下さい。 作成日：2014-xx-xx 更新日：2014-xx-xx

1.商談経緯 商談発生のきっかけとなったイベントなどの名称・日付・面談者等や、その後初回提案までの経緯を箇条書きにします。

2.導入目的 お客様の導入目的（具体的な課題やIT予算上のテーマ等）を記入します。

3.対象コンテンツ 対象となるコンテンツとスケール コンテンツの種類 検索の最小単位としての ドキュメント数（F/S） レコード数（DB） データ数（WEB） ルートフォルダ数（F/S） View数（DB） サイト数（WEB） テンプレート数(Notes) フォルダ階層数（F/S） ページ数（WEB） DB数（Notes） 総データサイズ 総テキストサイズ □ファイルサーバー □データベース - □WEBサイト □Notes 対象となるコンテンツのヒアリングは主に下記を測る（予測・想定する）ことを目的として行います。 １．開発規模・効率 ２．ハードウェア設計・性能設計（概要） ３．要求機能想定 ・　ファイルサーバー検索単体では標準的な検索以外に要件がある可能性は多くありませんが、他コンテンツとの統合検索がある場合は業務上の相関関係を確認する必要があります。 ・　DBのViewは検索粒度に合わせて仮想的に統廃合するイメージを伝えながらヒアリングします。 ・　Notesの場合、DB毎に定義設定を行う作業が発生するが近似DBについては作業効率が大幅に向上するため、DB数よりもテンプレート数が重要な数値となります。

3.対象コンテンツ（ファイルサーバー） ファイルサーバの情報を記入してください。 ＃ 確認項目（大分類） 確認項目（小分類） 記入欄 1 検索対象ファイル情報 現在の総ファイル数 ［ ］ファイル 2 現在の総ファイル容量合計 ［ ］ □MB、□GB、□TB 3 将来のファイル増加想定 ［ ］年後 [ ］倍　 4 クロール対象ファイル種類 □Word、□Excel、□PowerPoint、□VISIO □PDF、□HTML、□テキスト、□リッチテキスト □圧縮ファイル（□ZIP、□LZH、□その他） □その他［ 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ］ ※MS-Officeのバージョン：□ 2003、□ 2007、□ 2010、□ 2012 ファイルサーバ情報 ファイルサーバ構成 □サーバ直付けHDD、 □ NAS、 □ FC-SAN、□その他［ 　　　　　　　 ］ ファイルサーバ台数 ［ 　　　　　　　　 ］台 クロール対象ルートフォルダ数 ［ 　　　　　　　　 ］フォルダ ファイル参照権制御 □ADのユーザ・グループとACL（アクセス権限リスト）によるファイル毎の参照制御制御が必要 □その他 インデックス更新間隔 希望間隔：□夜間更新、□数日内に更新、□１週間以内、□考慮不要 許容間隔：□夜間更新、□数日内に更新、□１週間以内、□考慮不要 5 ネットワーク帯域 □十分な帯域有り（24時間、複数のクローラーがファイル収集可能） □時間帯（営業時間帯等）によりクロール不可時間有り ファイルサーバー検索はエンドユーザーからみると要件はシンプルなように見えますが、対象が膨大な非構造データであることから、その内容の特徴や偏重、特殊事情をできるかぎり把握し、採用する内部コンポーネントの選定準備や処理プロセス概要の想定をする必要があります。

3.2.対象コンテンツ（データベース） データベースの情報を記入してください。 １．データベースの種類 ＃ 確認項目 記入欄 1 データベース種類 □SQLServer［Ver. 　　］ 、□Oracle ［Ver. 　　］ 、□MySQL ［Ver. 　　］ 、□PostgreSQL ［Ver. 　　］ □その他［　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　］ 2 検索対象システム システム数：［　　　　　］システム（数） ※システム毎にデータベース種類が異なる場合は、その関係を記述してください。 　　　　　システム名　　　　　　　　　　　　　　　　　データベース種類（バージョン） 1. ［　　　　　　　　　　　　　　　　　　　］　［　　　　　　　　　　　　　　　　　　　　］ 2. ［　　　　　　　　　　　　　　　　　　　］　［　　　　　　　　　　　　　　　　　　　　］ 3. ［　　　　　　　　　　　　　　　　　　　］　［　　　　　　　　　　　　　　　　　　　　］ 4. ［　　　　　　　　　　　　　　　　　　　］　［　　　　　　　　　　　　　　　　　　　　］ 5. ［　　　　　　　　　　　　　　　　　　　］　［　　　　　　　　　　　　　　　　　　　　］ 3 入力元DBへのアクセス □御客様にてView化＋データ仕様提示　 □御客様にて設計指示＋当方で設計開発（ベース情報提示前提） □プロジェクトマターで分析設計開発（ベース情報提示前提） 4 検索システム独自の ビジネスシナリオの挿入 □要　、□否 要の場合（概要）[　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　] 5 その他 ・BLOB属性項目　□ない　、□ある その他の特記事項　[　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　] １．データベースの種類 　選択肢のどのDBが対象なのかによって社内テスト環境準備の手順・工数・調達コストが異なります。 ２．検索対象システム 　検索業務要件の予測に活用します。対象を確定できない場合、（全般に言えることですが）およその数やサンプルでもよいので情報を入手して下さい。 ３．入力元DBへのアクセス 　クローラー・ハンドラーツールの選定とクレンジングプロセスの要否の判断に活用します。 ４．検索システム独自のビジネスシナリオの挿入 　選定評価項目の一部になる可能性もあるため極力具体的なイメージを確認したい項目です。 ５．その他 　・BLOB属性項目の有無 　　BLOB(Binary Large Object)というDBで定義上のデータ型名。この項目の中身はドキュメント等を添付ファイルとしてDBレコードと紐付ける、いわゆる文書管理システムもしくはそれに準じた情報管理システムの場合が大半で、これを検索の対象とする場合は標準的なクロール機能ではテキスト情報を採取することはできないためカスタマイズ要件のひとつとなる。（2013年4月現在）

3.3.対象コンテンツ（データベース詳細）＠＠＠システム システム別にデータベースの詳細情報を記入してください。 ＃ 確認項目 記入欄 1 システム名 ［　　　　　　　　　　　　　　　　　　　　　　　　　　　　］ 2 テーブル数　 ［　　　　　　　　　　　　］テーブル 3 添付ファイル有無 □有、□無　　　※有の場合は１レコードにひもづくファイル数［　　　　］ 4 テーブル別項目数、 レコード数 　　　テーブル名　　　　　　　　　　　項目数　　　　　　　レコード数 1. ［　　　　　　　　　　　　　　　　　］：［　　　　］項目、　［　　　　　　　　　］レコード 2. ［　　　　　　　　　　　　　　　　　］：［　　　　］項目、　［　　　　　　　　　］レコード 3. ［　　　　　　　　　　　　　　　　　］：［　　　　］項目、　［　　　　　　　　　］レコード 4. ［　　　　　　　　　　　　　　　　　］：［　　　　］項目、　［　　　　　　　　　］レコード 5. ［　　　　　　　　　　　　　　　　　］：［　　　　］項目、　［　　　　　　　　　］レコード 5 将来のデータ増加想定 ［ 　　　　　　　　　］年後　［ 　　　　　　　　　］倍　 6 差分更新関連情報 　　　テーブル名　　　　　　　　　　　更新日時項目の有無　　　　　　削除フラグ項目の有無 1. ［　　　　　　　　　　　　　　　　　］：　□有、□一部有、□無　　 　□有、□一部有、□無（物理削除） 2. ［　　　　　　　　　　　　　　　　　］：　□有、□一部有、□無　　 　□有、□一部有、□無（物理削除） 3. ［　　　　　　　　　　　　　　　　　］：　□有、□一部有、□無　　 　□有、□一部有、□無（物理削除） 4. ［　　　　　　　　　　　　　　　　　］：　□有、□一部有、□無　　 　□有、□一部有、□無（物理削除） 5. ［　　　　　　　　　　　　　　　　　］：　□有、□一部有、□無　　 　□有、□一部有、□無（物理削除） 7 データ参照権限制御 □アクセス権限なし、□システム単位で参照制限有り、□レコード単位で参照権限制御有り 8 ユーザー側権限 □ユーザー単位の権限制御（ADユーザーと連動）、 □ユーザー単位の権限制御（AD以外の管理） □グループ単位の権限制御（ADグループと連動）、 □グループ単位の権限制御（AD以外の管理） □アクセス権限なし　□その他［　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　］ 9 データベースクロール時間の制限 □24時間クロール（DBアクセス）可能 □クロール不可時間帯有り［　　　　　　　　　　　　　　　　　　　　　　　　　　　　］ ★ このページはシステム毎にコピーして記述してください。 当ページはデータベースのプロフィール全般についてのヒアリングページとなります。 可能であれば、ER図とテーブル項目定義書を入手してください。

4.利用画面イメージ ★標準的なデモによる製品の紹介を通じて一般的な検索でできることとの違いを概要レベルで説明済みであることを前提とします。 利用するページバリエーションとページ内機能構成のイメージを記載していただきます。 < イメージ例 > ・製品紹介資料のAppendix画面 ・Googleの初画面 ・Googleの検索結果画面 ・Googleの検索結果画面のプレビューイメージ ・Yahooのようなポータルページ ・ダッシュボードのような情報鳥瞰ビュー ・データ閲覧UI ・グラフ分析UI 上記のヒアリングをベースに以後のヒアリングも含めて分析し、ページタブ構成やゾーンによる表示切替の構成案を作成・提案します。

5.画面遷移 ★標準的なデモによる製品の紹介を通じて一般的な検索でできることとの違いを概要レベルで説明済みであることを前提とします。 ページ間のデータ連携や具体的な画面遷移を記入していただきます。 【ポイント】 画面遷移の要件確認の際、「行き」にのみ着目してその後の流れを考慮していないがために業務の流れとして不都合や矛盾が生じるケースが多々ありますので、注意が必要です。

6.機能要件 製品標準機能以外で具体的な機能要件があれば、記載して下さい。 ページに配置されたwidgetの機能で要件として確定している要件をページ毎に記入していただきます。 ・表示対象コンテンツ ・クリック時の挙動 ・アクション実行時の挙動 ★標準的なデモによる製品の紹介を通じて一般的な検索でできることとの違いを概要レベルで説明済みであることを前提とします。 ・製品標準機能以外 御客様に具体的なイメージ（既存システムUIの踏襲等）がある場合に記入していただきます。 ・ページに配置されたwidgetの機能要件をページ毎に記入していただきます。 　・表示対象コンテンツ 　・クリック時の挙動 　・アクション実行時の挙動

7.アクセス制御 １．独自ACL付加の要否 ２．制御する仕様を記載してください。 □希望する 、□希望しない 希望する場合 　　　　□希望する　、□希望しない 希望する場合 ２．制御する仕様を記載してください。 □コンテンツに対するアクセス制御 □ページに対するアクセス制御 □データの値でのアクセス制御 □検索結果を詳細表示する際のアクセス制御 当ページのヒアリングは原則としてマスト要件を確認します。あまり深い（細かい）レベルでのアクセス制御を求められるとサポート工数が飛躍的に大きくなる可能性が高まります。 １．独自ACL付加のための情報 　一般的なディレクトリーサービスにおけるACLの採取以外にDBまたはDBシステム独自のアクセス制御が存在し、これに準拠して検索権限制御を行いたい場合や当検索システム独自のルールで制御したい場合にその意思をヒアリングします。 ２．制御仕様 　希望する項目にチェックを入れていただき、その詳細をヒアリングします。共通要件は以下の二点。 ・システム的に制御判断する情報の有無・所在、判断材料の生成元・生成方法案等 ・当検索システム独自の運用機能として希望する制御か？御客様全体統制としてのルールか？ 2-1.コンテンツ 　検索対象自体の検索の可否を制御する 2-2.ページ 　ページ構成イメージ上においてそのページでの検索の可否を制御する 2-3.データ値 　コンテンツまたは検索インデックスが保持するデータ項目の値によって検索の可否を制御する

8.1.システム環境 システム配置 対象コンテンツの存在場所 ネットワーク環境 8.1.システム環境　システム配置 対象コンテンツの存在場所 ネットワーク環境 対象コンテンツ⇔INDEXサーバ間（クローラの動作環境の把握） クライアント⇔InSightサーバ間（描画レスポンスに影響、遠隔地有無）

8.2.システム環境 運用環境 セキュリティポリシーの有無（有の場合は詳細確認） 8.2.システム環境　運用環境 セキュリティポリシーの有無（有の場合は詳細確認） 使用予定のシステム管理ツール（退避・ログ監視等）の有無（有場合は詳細確認） 当該システムにおけるサービスレベル（概要）予定 管理体系（オーナー・管理者・オペレーター・エンドユーザー） 　サポート費用を積算する際、もっともタスクの内容や規模の予測が難しいフェーズが運用設計となります。 　当該システム単体の要件と御客様保有ITシステム全体との整合が必要な要素も多く、事前ヒアリングが難しい場合が多いです。 　確定要件と検討要件を分類してヒアリングします。提案者側の経験として一般的と思われるモデルの提示も有効。 　このページの情報が曖昧な場合は運用設計を成果責任とせず、運用設計支援として工数を積算し、顧客タスクを支援する形をとることも検討したいところです。 また、システム導入プロジェクトにおける検収や本稼働開始に対して踏むべき御客様社内プロセスは多様なため、思わぬ工数の消費につながる場合があります。できることであれば大まかなプロセスについては確認しておきたいところです。

8.3.システム環境 その他 ユーザ認証方式（SSOカスタマイズ要否判断） 調達されるサーバーのスペック制限・予定等 8.3.システム環境　その他 ユーザ認証方式（SSOカスタマイズ要否判断） 調達されるサーバーのスペック制限・予定等 冗長構成の要否（必要な場合ご希望の概要を記載して下さい） １．ユーザー認証方式 　ユーザー認証方式が確立されていて自社独自の認証システムが存在し、これを介在する必要がある場合（多分ほとんどが該当）、通常新規参入のWEBシステムからの認証連携に関してなんらかのアダプトAPIまたは連携ガイドラインが存在しているはずですので、入手して下さい。

9.導入規模/スケジュール 利用者の規模（パイロット時のユーザ数/本稼動時のユーザー数）、導入予定部門 想定される同時ログインユーザ数（本番稼働時） ソースボリューム（パイロット時/本稼動時/将来の拡張想定） 希望納期・キックオフのタイミング等

10.導入サポート環境 1. 作業場所・環境 2. 検証環境（ステージングサーバー）構築 3. 開発環境構築 □構築する 、□構築しない □構築する　、□構築しない ・構築する場合 □レプリカ　、□コンパクト □常駐　、□非常駐　　　　　　　　　　　→　仮想システムを想定 ・構築しない場合 　検証手順やと本稼働との区別等についてご記入下さい。 3. 開発環境構築 ステージングサーバーを用意する予定か否かで作業効率と検証手順が大きく変わる可能性があり、作業見積工数と日程案作成に影響があります。