夢想散極彩

夢想、或いは眠りながら生きた日々の続き

【読書メモ】ベンダー・マネジメントの極意―プロジェクトを成功に導く外注管理

タイトル:ベンダー・マネジメントの極意―プロジェクトを成功に導く外注管理
作者:長尾 清一
出版社/メーカー: 日経BP
発売日: 2009/07

ベンダーの選定から終結まで。
気をつけるべき点がよくまとまっている。
全体的にアメリカでのプロジェクトマネジメントを前提にしているが、
実際国内でも普通に適用出来る内容だと思われる。
問題はサブベンダーとナアナアになっていてしっかりと準備をさせない会社組織かもしれないが…

本書の見どころとして、全体的に契約(契約書、SOW、プロシージャーズマニュアル)に基づいた
記載がなされており、何をどこまでやればいいのか(やっていいのか)がわかりやすい。
(もちろんPJごとの契約により異なる点があるが、原則論として)

特に肝に銘じたいのは、請負契約・準委任契約・派遣契約の責任範囲の違い。
請負にも関わらず主体性のないサブベンダを甘やかしてはいけない。
ただし、役割分担をきっちり主張するためには、事前の契約やSOWがモノをいう。
プライムベンダはあくまで論理的にビジネスを展開しなくてはならない。
自身の中で、サブベンダとの役割が明確ではない(契約などファクトに基づいていない)のでは、
マネジメントしているいうよりは、運に頼っているというべきである。

目次

【PROLOGUE】 ~外注化は魔法の杖か!?
< PROLOGUE 1 > 外注管理における7つの誤解
 ・ITの市場動向と外注化の必然性
 ・外注管理の成功を阻む誤解とは
< PROLOGUE 2 > 外注化戦略の重要性
 ・問題が山積する外注化の現状
 ・経営戦略と外注化戦略の同期化が鍵
< PROLOGUE 3 > 外注管理の全体像
 ・まずは全体像を理解する

【UNIT1】 発注フェーズ
< PROCESS 1 > 外注化プランを策定する
 ・戦略に合った発注スコープを決定する
 ・タイミングを外さない発注スケジュール
 ・外注コントロールプランも厳密に
< PROCESS 2 > ベンダー選定の事前準備を行う
 ・予備選定は情報収集から
 ・何故このベンダーを候補に挙げるのか
 ・初期調査は会って確かめる
< PROCESS 3 > RFPを作成する
 ・10のステップで準備作業は入念に
 ・目的に合わせてRFPをまとめる
< PROCESS 4 > 提案書を評価する
 ・ClarificationとDeviationによる評価
 ・まずRFPへの対応度を評価する
 ・提案書の詳細評価は3つの側面から

【UNIT2】 契約締結フェーズ
< PROCESS 5 > ベンダーを決定する
 ・最終候補を絞り込む
 ・内定ベンダーとのすり合わせ
< PROCESS 6 > 外注契約を締結する
 ・リスク分散のツールとしての契約書
 ・外注コントロールのツールとしての契約書
 ・候補ベンダーとの契約交渉

【UNIT3】 開始フェーズ
< PROCESS 7 > コントロールの初期設定を行う
 ・サブベンダーと共同で行う5つのステップ
 ・キックオフによるトーンの設定

【UNIT4】 実施フェーズ
< PROCESS 8 > 外注コントロールを実施する
 ・内部と外部コントロールの違い
 ・どの程度、介入すべきなのか
< PROCESS 8-1 > 進捗管理はヒアリングが決め手
 ・進捗管理の4つの鉄則
 ・ヒアリングが決め手
 ・重要な記録としての議事録
< PROCESS 8-2 > リスク管理は具体性の検証を
 ・リスクの具体性、対応策の実効性を検証
 ・リスク管理の支援強化
 ・全体的な視点でリスクをさばく
< PROCESS 8-3 > 品質管理で手抜きは禁物
 ・品質管理の4つのポイント
 ・フェーズ移行基準の達成検証
< PROCESS 8-4 > 仕様変更は6つの策でさばけ
 ・変更管理の6つのポイント
< PROCESS 8-5 > コスト管理は当事者意識が必須
 ・委託業務のコスト管理は誰がする
 ・ベンダーマネジメント作業のコスト削減
< PROCESS 8-6 > 利害対立管理は証拠固めが基本
 ・利害対立は避けられない
 ・段階を踏んだエスカレーションで解決を図る

【UNIT5】 終結フェーズ
< PROCESS 9 > 外注管理を終結させる
 ・チェックリストで漏れなく締める
 ・外注管理の評価で次につなげる

【APPENDIX】 オフショア開発
< APPENDIX > オフショアで甘さは厳禁!
 ・なぜトラブルが絶えないのか
 ・日本流では失敗を招く!

メモ

・請負契約における責任
 請負契約では、基本的な作成責任は受注側に発生する(成果物のQCDを守ることが契約内容。
 ただし、サブベンダが下流工程より参画するような場合、インプットドキュメントの不備など、
 プライムベンダ側の瑕疵となるような事象がある場合、責任はプライムベンダ側となる。
 上流ドキュメントを盾に過失相殺が発生しないよう、十二分に注意する必要がある。
 (当然ではあるが、後工程で決める、などとしたままで渡してはいけない)

・協力会社対応の大前提 ※オフショア向けだが、国内も同様
 - 契約はトラブルが発生する前提で
 - 仕様書の作成や説明では曖昧さを排除
 - 開始時にルールを叩きこむ
 - プロジェクトマネジメントはエビデンスの収集
  →プロジェクトでは必ず何かある。やりとりのエビデンスを残すこともマネジメント。

・Back to Backの原則
 主契約(ユーザ - プライムベンダ間)と外注契約(プライムベンダ - サブベンダ間)の契約を一致させる。

・開始フェーズの作業
 - 契約書の読み合わせ
 - SOW、責任分担の再確認
 - 実行プランのウォークスルー
 - 品質管理プランのウォークスルー
 - プロシージャーズマニュアルの読み合わせ ※会議体、進捗管理など推進ルール

 作業開始の前提すり合わせは非常に大切。
 特に、品質管理や進捗管理などは初期の意識付けが必須。
 当然、プロジェクトとしての全体ルールを事前に作る必要がある。

 また、SOWについては最初にWBSが正しく(抜け漏れなく)作成されていることが前提となるため、
 そちらに重きをおくべきかもしれない。

・サブベンダの評価
 - 技術
 - マネジメント
 - 価格

 技術・価格は言うまでもないが、マネジメントの評価が重要。
 請負契約の場合、原則としてマネジメント(進捗、品質、コスト、課題、リスク)はサブベンダのタスクである。
 契約上、プライムベンダがサブベンダ作業のマネジメントを行うことはできない。

【読書メモ】絵で見てわかるITインフラの仕組み

タイトル:絵で見てわかるITインフラの仕組み (DB SELECTION)
作者:山崎泰史,三縄慶子,畔勝洋平,佐藤貴彦,小田圭二
出版社/メーカー:翔泳社
発売日: 2012/09/19

非常に内容の濃い本。
システムトータルを考えるために必要なインフラ知識の欠損を補うことができる。
ITアーキテクチャに関わるSEは必ず抑えておくべき内容。
(インフラエンジニアの場合でも、全体俯瞰という意味では役立つかも)

SIerのSEは本書の内容理解を必須にすべき。

目次

CHAPTER 1 インフラアーキテクチャを見てみよう
1.1 はじめに
1.2 集約型と分割型アーキテクチャ
1.3 垂直分割型アーキテクチャ
1.4 水平分割型アーキテクチャ
1.5 地理分割型アーキテクチャ
CHAPTER 2 サーバーを開けてみよう
2.1 物理サーバーとは
2.2 CPU とは
2.3 メモリとは
2.5 バス
2.6 まとめ
CHAPTER 3 3階層型システムを見てみよう
3.1 3階層型システムの図解
3.2 主要概念の説明
3.3 Web データの流れ
CHAPTER 4 インフラを支える理論の基本
4.1 直列/並列
4.2 同期/非同期
4.3 キュー
4.4 排他制御
4.5 ステートフル/ステートレス
4.6 可変長/固定長
4.7 データ構造(配列と連結リスト)
4.8 探索アルゴリズム(ハッシュ/ ツリーなど)
CHAPTER 5 インフラを支える理論の応用
5.1 キャッシュ
5.2 割り込み
5.3 ポーリング
5.4 ピンポン
5.5 ジャーナリング
5.6 レプリケーション
5.7 マスター・スレーブ
5.8 圧縮
5.9 エラーチェック/誤り訂正
CHAPTER 6 システムをつなぐネットワークの仕組み
6.1 ネットワーク
6.2 【基礎】階層構造とは
6.3 【基礎】プロトコルとは
6.4 TCP/IP による今日のネットワーク
6.5 【レイヤー7】アプリケーション層のプロトコルHTTP
6.6 【レイヤー4】トランスポート層のプロトコルTCP
6.7 【レイヤー3】ネットワーク層のプロトコルIP
6.8 【レイヤー2】データリンク層のプロトコルEthernet
6.9 TCP/IP による通信のその後
CHAPTER 7 止めないためのインフラの仕組み
7.1 耐障害性、冗長化とは
7.2 サーバー内冗長化
7.3 ストレージ冗長化
7.4 Web サーバーの冗長化
7.5 AP サーバーの冗長化
7.6 DB サーバーの冗長化
7.7 ネットワーク機器の冗長化
7.8 サイトの冗長化
7.9 監視
7.10 バックアップ
CHAPTER 8 性能を引き出すためのインフラの仕組み
8.1 レスポンスとスループット
8.2 ボトルネックとは
8.3 3階層型システム図から見たボトルネック
8.4 まとめ

メモ

◆用語
◇ハードウェア
・QPI ( Intel QuickPath Interconnect )
 CPU - メモリ間を接続する技術。従来のFSB(Front Side Bus)を置き換えている。

・HBA ( Host Bus Adapter )
 コンピュータの拡張スロットに刺すインタフェース用カードの総称。
 SCSI、SATA、FCなどストレージ系が代表的だが、NICやUSBインタフェースを含むこともある。

・ICH ( I/O Contoroller Hub )
 低速なI/Oを処理するための技術。サウスブリッジ。
 2000年代のPCではIOHとセットのアーキテクチャ設計が多かった。

・IOH ( I/O Hub ) 関連:MCH (Memory Contoroller Hub )
 高速なI/Oを処理するための技術。ノースブリッジ。従来はメモリやSCSIの接続先であったが、
 現在のIntelチップセットではMCH機能(メモリのI/O管理)がCPUに統合されている。
 そのため、ICH(サウスブリッジ)で行っていた処理をIOHにまとめられており、Intel
 モダンチップセット(2013/09時点)では、ノースブリッジ、サウスブリッジの区別はなくなっている。

 [参考]
  X58 Block Diagram ※IOH + ICHの例
  http://en.wikipedia.org/wiki/File:X58_Block_Diagram.png

  インテル® Z87 チップセット搭載プラットフォームのブロック図 ※Z87がIOH(CH)+ICHにあたる
  http://www.intel.co.jp/content/www/jp/ja/chipsets/performance-chipsets/z87-chipset-diagram.html

  PCからノースブリッジが消える日 ※アーキテクチャの推移
  http://pc.watch.impress.co.jp/docs/2008/0122/kaigai411.htm

◇ネットワーク
・MSS ( Maximum Segment Size )
 1TCPセグメントに格納可能な最大サイズ。このサイズに対しTCPヘッダ(20byte)が付加される。

・MTU ( Maximum Transmission Unit )
 IPパケットの最大サイズ。TCPヘッダ、IPヘッダを含む。
 IPv4ヘッダは20byteのため、TCPヘッダと合わせて40byteとなり、MTUが1500byteの場合、
 効率的な転送を行うためにはMSSは1460byteとする必要がある。

Ethernetフレーム
 IPパケットにEthernetヘッダ、Ethernetトレイラを付加したもの。

 [参考]
 MTU / MSS / RWIN
 http://www.infraexpert.com/info/5adsl.htm

・トランクポート( Trunk Port ) / トランクリンク ( Trunk Link )
 VLANを使用する場合に、L2/L3スイッチ間を接続し、1ポートの接続で
 複数のVLANフレームを転送できるポート。
 なお、通常の1LAN用のポートのことをアクセスポート、その接続のことをアクセスリンクと呼ぶ。

・ブロッキングポート
 SPTにて論理的にせき止められたポート。

・SPT ( Spanning Tree Protocol )
 スイッチに搭載されている、ネットワークの経路情報を管理する仕組み。
 通常は最適な1経路を維持し、不要な経路をブロックする(ブロッキングポート)。
 ネットワーク障害発生時には、経路を再計算し、別経路を通るよう制御を行う。

・ポーリング ( Polling)
 様々な対象に定期問合せを行うこと。5分に一度ステータスを確認する、など。

◆内容メモ
・ネットワークアクセスの概略
 [クライアントプロセス]
  ブラウザ等→HTTPリクエスト発生→ソケット生成→システムコール→(カーネルへ)
 [カーネル]
  TCPセグメント化→IPパケット化→Ethernetフレーム化→ドライバにキューイング→(NICへ)
 [NIC以降]
  L2スイッチ→L3スイッチ(ルータ)→(相手ネットワークへ)

・システムの動作はとにかくシステムコール
 NIC、HDD、PCIe等、CPU周り以外は基本的にカーネルへのシステムコールによって動作する。

・3層構造(サーバ)
 3層アーキテクチャ(プレゼンテーション層、アプリケーション層、データ層)に基づく構造。
 Webサーバ - APサーバ - DBサーバの構成。MVCとは概念が異なる。
 3層ではWeb-DB間通信は発生しないが、MVCのトポロジではView -Model間の通信が発生。