TAM 新人ディレクターシステムスキルアッププログラム第2回「システム案件のヒアリング」

新⼈人ディレクター
システムスキルアップ
プログラム
第２回「システム案件のヒアリング」
T ware 品川

第⼆二回：システム案件のヒアリング 12/05/23

今⽇日の内容

›  前回のフォーロアップ ›  システム詳細ヒアリング
›  IPアドレス、DNSサーバ ›  ⽬目的と聞くべきこと

›  ヒアリングの流流れ ›  エンジニアは何を知りた
›  初回ヒアリングと詳細ヒアいか
リング ›  エンジニアの考え⽅方

›  初回ヒアリング
›  ⽬目的と聞くべきこと

›  判断
›  エンジニアとの連携⽅方法

All Rights Reserved. Copyright (C) 2012, T ware 1


前回のフォローアップ
›  IPアドレスのクラス（抜粋） W

クラスアドレス範囲プライベートアドレス範囲

クラスA 0.0.0.0 -‐‑‒ 127.255.255.255 10.0.0.0 -‐‑‒ 10.255.255.255 　(16,777,216)

クラスB 128.0.0.0 -‐‑‒ 191.255.255.255 172.16.0.0 -‐‑‒ 172.31.255.255 　(1,048,576)

クラスC 192.0.0.0 -‐‑‒ 223.255.255.255 192.168.0.0 -‐‑‒ 192.168.255.255 　(65,536)

›  グローバル IPアドレスとプライベートIPアドレス B

›  グローバルIPアドレス
›  インターネット接続⽤用に利利⽤用され、インターネット上で重
複しないアドレス（世界的に管理理されている）
›  プライベートIPアドレス
›  特定の組織等に割当てられていないアドレスで管理理団体に
申請しなくても利利⽤用可能


›  グローバル IPアドレスとプライベートIPアドレス B

インターネット
ローカルＢ社
192.168.0.1
ローカル
グローバル 192.168.0.1
210.22.XX.Y グローバル
ローカル
210.22.XX.Y
192.168.0.2
Ａ社
ローカル
ローカル 192.168.0.150
192.168.0.1

ローカル
192.168.0.2 グローバル
210.12.X.YY




›  DNSサーバに登録されている情報 W

›  リソースレコード（抜粋）
レコード名内容

Aレコード名前に対するIPアドレス

CNAMEレコードその名前に対する別名

NSレコードそのゾーンの権威あるDNSコンテンツサーバの名前

MXレコードそのゾーンのメールサーバの名前

PTRレコード IPアドレスに対する名前　(IPアドレスは 1.1.168.192.in-‐‑‒
addr.arpa. の様に表記される)
$ dig www.tam-‐‑‒tam.co.jp
＜＜省略＞＞
;; ANSWER SECTION:
www.tam-‐‑‒tam.co.jp. 3600 IN CNAME mail.tam-‐‑‒tam.co.jp.
mail.tam-‐‑‒tam.co.jp. 916 IN A 210.168.112.4
＜＜省略＞＞


$ dig tam-tam.co.jp any W

＜＜省略＞＞

;; ANSWER SECTION:
tam-tam.co.jp. 3600 IN A 210.168.112.4
tam-tam.co.jp. 3600 IN MX 300 mx2.firstserver.ne.jp.
tam-tam.co.jp. 3600 IN MX 100 mail.tam-tam.co.jp.
tam-tam.co.jp. 3600 IN MX 200 mx1.firstserver.ne.jp.
tam-tam.co.jp. 3600 IN SOA nsas1.firstserver.ne.jp.
hostmaster.firstserver.ne.jp. 2011090700 172800 3600 604800 3600
tam-tam.co.jp. 3600 IN NS nsas1.firstserver.ne.jp.
tam-tam.co.jp. 3600 IN NS nsas2.firstserver.ne.jp.

＜＜省略＞＞



ヒアリングの流流れ

(1) 初回ヒアリング

?
(2) 判断

(3) システム詳細ヒアリング

提案/設計フェーズ



初回ヒアリング B

›  ⽬目的
›  システム化の対象、背景、規模などの概要を把握する
ü  技術的な詳細は後回しで良良い

›  聞くべきこと
›  システムについての顧客からのニーズの有無
›  システム化の⽬目的と背景
›  システムを利利⽤用したい理理由（⽬目的と背景）
ü  周辺の事情も含めて把握するのが望ましい
›  顧客が感じている問題点（改善したい点）
ü  既存システムが無くても、サイトが解決すべきものを確
認する
ü  問題点とシステム化の⽬目的との間にギャップがある場合
があるので両⽅方を確認するのが望ましい



›  システム化の⽬目的と背景（続き）
›  システムの運⽤用体制のイメージ
›  システムを使い続けるための体制があるか
›  新規の場合は、顧客が持っているイメージを確認
ü  顧客が運⽤用体制を決定していない場合もある




›  既存のシステムが存在するか
›  公開されている場合は、サイトのURL
›  サーバの変更更を検討しているか
›  既存のサーバ環境
›  ⾃自社サーバかレンタルか
›  レンタルの場合、業者名とプラン名
›  ⾃自社の場合、OSとWebサーバの名前（Apacheなど）
›  プログラミング⾔言語の種類（PHP, Javaなど）
›  サーバ環境の構成図があれば⼊入⼿手
›  予算規模
›  予算感の把握



判断 B

›  エンジニアとの連携⽅方法の判断
›  エンジニアにヒアリング内容を伝え、以後の対応を相談
›  動作の把握できる単純なものの場合
›  実績のあるパッケージ（ブログ等）を使⽤用する場合や、
フォーム類の場合など
›  仕様の確認等はディレクタ主導で進める
›  複雑なものの場合
›  データベースが必要なもの、管理理画⾯面が必要なもの…
›  システムの詳細を確認するためのヒアリングを⾏行行う
›  エンジニアの同⾏行行を依頼
›  開発を担当するエンジニアの参加が望ましい
›  なるべく早期からの同⾏行行が望ましい



システム詳細ヒアリング B

›  ⽬目的
›  エンジニアが参加し、システム設計のための情報を得る
ü  エンジニア主導

›  初回ヒアリング内容の確認
›  ヒアリング結果を、こちらの理理解した内容として確認
›  システムの⽬目的、システム化の対象、問題点、運⽤用体制、
既存システム
›  システム要件の詳細確認
›  必要機能
›  開発対象機能の概要を確認
ü  主な機能を確認（何ができれば良良いか）
ü  システムに関わる⼈人・モノは何かを確認



›  システム要件の詳細確認（続き）
›  連携が必要な関連システム
ü  社内データベース等、開発するシステムと連携が必要な
ものについての情報収集
›  既存システム
›  再利利⽤用の可能性の確認
›  開発対象の機能の確認
ü  動作中のサイトを確認しても、管理理機能等の⾮非公開機能が把握
できないので確認しておく
›  運⽤用⽅方法の確認
›  関連する⼈人・システムとの関連、業務の流流れを把握
ü  運⽤用⽅方法の改善案を提案するためにも確認しておく




›  セキュリティポリシーの確認
›  個⼈人情報の取り扱い、サーバ類に対する規則などを確認
ü  個⼈人情報はレンタルサーバに保存できない、サーバの基本ソフ
トは常に更更新しないといけない　など
›  サイトに必要な性能
›  ページビュー数などの性能⽬目標値の確認
›  サーバ環境の確認
›  既存サーバを使⽤用する場合
›  「システム環境確認シート」の内容を確認




›  サーバ環境の確認（続き）
›  新規サーバの場合
›  アクセス頻度度(PV)とバランス（回線を流流れる情報量量を推測）
›  コンテンツ容量量と内容（必要なディスク容量量と動画等の特別な
配慮が必要なコンテンツを含むかの確認）
›  コスト条件（初期、ランニング）
›  サイトの継続期間（サーバ業者との最短契約期間）
›  ブログなど特定のパッケージが前提になっているか
›  SSL利利⽤用の要否
›  OS、基本ソフトウェアの指定があるか
›  アクセス解析等の付随サービスの必要性
›  稼働状態監視の必要性



›  システム保守に関する指針の確認
›  システムのバックアップ、バックアップデータの保存期
間、障害発⽣生時の対応などについての規則などの確認
›  提出ドキュメントの確認
›  ドキュメント提出の必要性を確認
›  画⾯面遷移、各画⾯面の機能、テスト結果、データベース設計まで
は費⽤用内
›  より詳細なプログラム内部の情報は追加費⽤用（作成⼯工数が⼤大き
くなることも多い）



エンジニアは何を知りたいか B

›  開発者の気質（考え⽅方）
›  予めできるだけの情報を把握しておきたい
ü  なるべく早い時期に情報共有しておくのが良良い
›  最適な答えを出したい
ü  「○○機能が欲しい」という話より、どういう背景がある
か、重要な問題点は何か、最も喜ばれる改善点は何か、な
どの周辺の情報を共有しておくとよい
›  開発は⾃自分の頭の中のストーリーに従って⾏行行う
ü  修正に対して神経質になる傾向にある
ü  修正が発⽣生すると必ず影響範囲を検討するので、修正案⾃自
体も相談してみるとよい（より良良い修正案）



これだけは憶えよう

›  前回のフォーロアップ ›  判断
›  グローバルアドレスとロー ›  ヒアリング結果から以後
カルアドレスの違いの進め⽅方をエンジニアと
›  DNSサーバのリソースレ相談する
コード（A, CNAME, MX）
›  システム詳細ヒアリング
›  初回ヒアリング ›  エンジニア主導
›  システム化の⽬目的/背景、 ›  設計に必要な情報の収集
システムの環境などの情報
収集を⾏行行う
›  技術の詳細は後回しで良良い



ご質問、お問合せお寄せ下さい

toru@tam-‐tam.co.jp

support@i-‐tware.com


TAM 新人ディレクターシステムスキルアッププログラム第2回「システム案件のヒアリング」

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to TAM 新人ディレクターシステムスキルアッププログラム第2回「システム案件のヒアリング」

Similar to TAM 新人ディレクターシステムスキルアッププログラム第2回「システム案件のヒアリング」 (20)