ITエンジニアの「やってはいけない」

［データセンターの管理・監視対策編］IT担当者とファシリティ担当者で情報が乖離してはいけない

　データセンターでは今後，日常的な運用監視を行っている担当者やIT部門だけでなく，他の部門とのコミュニケーションがいかに大切かを意識する局面が増えてくる。特に物理インフラにおいては，IT管理者とファシリティ管理者との責任の境界が明確でないため，両者の隙間に落ちた管理要素でトラブルが発生したときが問題…

［データセンターの管理・監視対策編］電力や空調の容量管理をおろそかにしてはいけない

　物理インフラ機器について，異常通知や閾値による監視だけを行っていても十分な管理とはいえない。地球温暖化対策の面からデータセンターにおける省エネや効率化の意識は高まっており，メンテナンスや運用だけでなく，計画段階から消費電力のランニング・コスト管理を行う必要がある。特に問題となるのが容量管理だ。

［データセンターの管理・監視対策編］環境監視をファシリティ担当者だけにまかせてはいけない

　多くのデータセンター管理者，特にIT管理者が見逃しがちなことに，物理インフラの「環境監視」がある。監視の主要な項目としては，温度，湿度，漏水，ドア，煙，振動，露点，エアフロー，監視カメラ，ほこり，化学物質などがあり，データセンターにおける脅威の原因になる場合がある。IT管理者はこれらの環境監視をフ…

［データセンターの管理・監視対策編］IT機器の管理・監視だけに満足してはいけない

　データセンターでは，常にセンター内のシステムを構成するIT機器（サーバー，ストレージ，ネットワーク機器など）を管理・監視する必要がある。例えば，サーバーなどのハードウエアの死活監視，OS/アプリケーション/プロセス/サービスのステータス・ジョブ管理など，さまざまな管理・監視項目がある。しかし，デー…

［要件定義編］成果物選定と標準化を後回しにしてはいけない

メソドロジをテーラリングする

　要件定義フェーズのアウトプット（成果物）を取り決め，それらの品質基準や完了基準を事前に設定するのは容易なことではない。しかし，こうした作業を後回しにして，要件のヒアリングを始めてはいけない。要件定義の作業がどの程度進んでいるのかとらえられなくなってしまうからである。

［要件定義編］現行業務，現行システム調査を回避してはいけない

To-beモデルのリスク

　ユーザーから一貫した網羅性のある要件を引き出すことは難しい。To-be（理想）のビジネス要件定義からシステム要件につなげる際に，例外なくシステムの網羅性，整合性といった問題に突き当たる。

［要件定義編］ビジネス要件を文章だけで表現してはいけない

モデリング手法を用いるメリット

　要件を記述する際は，自然言語の文章だけで表現するのではなく，モデリング手法を活用するとよい。それにより，「要件の網羅性を確認しやすくなる」「記述のあいまいさを抑えられる」「要件の論理性，整合性を維持できる」「ビジュアルで視覚的に理解しやすくなる」という効果が期待できる。

［要件定義編］ビジネス要件とシステム要件を混同してはいけない

まずビジネス要件を明確にする

　企業がシステム構築プロジェクトに投資をする目的は，ビジネス目標を達成することにある。したがってビジネス要件を見ずに，システム要件ありきで開始したプロジェクトは，たとえ計画通りにシステムが完成したとしても，本来達成すべき目標を達成できないリスクが高い。

［要件定義編］要件定義フェーズの計画を怠ってはいけない

計画はなぜ必要なのか

　要件定義の計画とは，要件を具体化するために実施するプロセスの予定をまとめたものである。このプロセスの実施状況を「見える化」することは，問題の兆候を早期に察知して，トラブルの発生を未然に防ぐために効果的である。

［ERP編］「顧客主体タスク」を顧客に丸投げしてはいけない

　システム導入プロジェクトには，様々なタスクがある。通常，プロジェクト計画時点やフェーズ開始時点でWBSを作り，実施すべき作業とその担当者を明確化する。このときベンダーは，切り分けられた「顧客が主体となって行うタスク」を顧客に丸投げしてはいけない。

［ERP編］帳票の検討を後回しにしてはいけない

　実際にシステム要件定義を始めてみると，帳票の検討を後回しにしてしまうことが多い。「帳票は単に処理の最後に出てくるリスト」であり，「ERPにデータさえあれば出力するのは簡単だから，後で考えればよい」という誤った思い込みに陥るからだ。帳票は，システムから見れば最終アウトプットだが，業務を回すためのイン…

［ERP編］顧客のギャップ判定をそのまま受け入れてはいけない

　業務要件を整理して機能要件に落とし込む一連のステップは，パッケージ導入ならではの醍醐味があり，コンサルタントにとっては腕の見せどころである。しかし，顧客とコンサルタントの意見が衝突して，双方が気まずい思いをすることが少なくない。

［ERP編］いきなりプロトタイプを始めてはいけない

　プロトタイプ・フェーズの目的は「新業務プロセスの決定」「標準機能とアドオン機能の切り分け」「パラメータ設定の決定」などがある。この目的を達成するために，プロトタイプで「何を」「どこまで」「どのようにして」決めるかを明確にしておかないと，プロジェクトは失敗する。

［ERP編］ERPと現行機能との比較をしてはいけない

　グランドデザイン・フェーズで「ERPと現行機能との比較」をやってはいけない。両者を比較し，ギャップが生まれた部分をERPに無条件で合わせてしまうと，経営課題・経営ニーズの解決が達成されないからだ。顕在化・潜在化した経営課題は，ERPを導入するだけで自然に解決するわけではないのである。

［データセンターの電源対策編］UPSを設置するだけで安心してはいけない

　UPSを設置することでそのシステムの可用性は当然，飛躍的に上がる。しかしUPSも永久には使えない。製品としての寿命は10kVA以下の場合5年程度で，バッテリーの寿命も使用環境によって変わって来る。UPSを設置するだけで安心してはいけないのだ。

［データセンターの電源対策編］ラックが使用している電流値を見逃してはいけない

　電気の使い過ぎはよくないと分かっていても，データセンターやサーバー・ルームの電源なら心配いらないと，見て見ぬ振りをしている方がいるかもしれない。しかし，それは大きな誤解だ。ラックで実際に使っている電流値を見逃してはいけない。

［データセンターの電源対策編］全体を考えずに冗長電源にしてはいけない

　主要なサーバーやストレージ機器には冗長電源が標準で付属していたり，オプションで追加が可能になっていることが多い。しかし，機器単体の可用性ばかり注目し，システム全体を考えずに，安易に冗長電源を利用してはいけない。

［データセンターの電源対策編］サーバーの数だけUPSを用意してはいけない

　サーバーとUPSを1対1の構成にする――確かにシステムの規模が極端に小さい場合や，事前に構成を全く計画できない場合ならやむを得ない。しかし，ラックが数本程度あり，10kW～20kW程度の消費電力の一般的なサーバー・ルームでは，サーバーの数だけUPSを用意すような構成にするべきではない。

［データセンターの熱管理編］コールドアイルとホットアイルだけで満足してはいけない

　コールドアイルとホットアイルを分けても，ラックの上部から熱気が循環してくる場合がある。当然，センターの冷却効率は落ちてしまう。そうした場合は，ホットアイル側の熱気を強制的に排出する排風機を設置し，データセンターの空調装置の吸気側に熱気を環流させるなどして対処する。

［データセンターの熱管理編］ラックとサーバーの間にスペースを空けてはいけない

　ラックとサーバーの側面にすき間があると，サーバーの排気がそこから前面へ回り込み，再循環を起こしサーバーの温度上昇をもたらす。これは，ルーターなどネットワーク機器用である幅700mmのラックに，サーバーを搭載した場合に起こりやすい。