第1章　どうやって予算を確保するか

文化の違いで変わる見積りへの影響

• 短期的なプロジェクトでポイントになること
• 中期的なプロジェクトでポイントになること
• 長期的なプロジェクトでポイントになること
• コラム　お客さまのタイプの違いが文化の違いを生み出す

プロジェクトごとの予算確保から案件化まで

• コラム　ITへの投資
• RFPも出せなければPoCもできないタイミングで予算を取るための5つのポイント
• どういうことをやりたいかを聞いて，必要なコンポーネントをおおまかに考える
• コンポーネントからシステムの規模をイメージする
• 既存のリソースに空きがあるか確認する
• 購入するハードウェアの規模を想定する
• 使われるであろうミドルウェアを確認する

予算が決まった後にすべきこと

• 予算が想像以上に削られてしまった場合は
• コストを下げる基本原則は「必要以上の開発をおこなわない」こと
• コラム　心配性のユーザー部門への2つの対策

第2章　製品を安く買うための工夫

「製品は安く，工数はほどほどに」がコツ

• 結局，プロジェクトの主役は人
• ジャンプできる組織にはアソビが必要

製品の強み，弱みを正確に把握する

• 考えうるすべてのメーカーのカタログを入手し，スペックを徹底的に比較する
• 機器を見せてもらうために「きてください」と言わない3つの理由
• コラム　おもちゃを分解したことありますか？
• 社内の購買履歴から割引可能な金額を見極める
• ハードウェアの価格の動向を調べる
• ソフトウェアの価格の動向を調べる

ダブルスタンダードで価格をコントロールする

• 製品を自分で目利きする
• インフラをレイヤーで分割する
• 汎用的なものを選択する
• アプリケーションの影響を受けにくくする
• ダブルスタンダードにするのが難しい製品があることを理解する
• コラム　レイヤーで分割してダブルスタンダード化するとマルチベンダーになる

購入時に確認すべき3つのこと

• 購入のタイミングを意識する
• 特価申請の仕組みを理解する
• コラム　本気のディスカウント価格は購入する案件の中でしかわからない
• 見積もりを分解する
• コラム　接待好きの営業さんには要注意

第3章　開発費を削減するための工夫

インフラのコストを下げる基本原則

• まずは「必要以上の開発をおこなわない」
• 開発する機能を減らす
• サーバーの数を減らす
• ドキュメントを減らす

内製化を検討する

• 「内製」とは何か？
• 内製以外の部分やマルチベンダーの狭間のコスト
• 結局，内製は安いのか？
• 保守の体制に注意
• 一番重要なのはリーダーの営業力
• どういうプロジェクトを内製すべきか

契約で考えるべき4つのポイント

• 請負契約
• 準委任契約
• 故意・重過失
• 善管注意義務
• コラム　システムの要件が変わることへの疑問
• 契約内容は自らがチェックすべき

第4章　可用性，性能，運用性を考慮する

システムのコストとSLA

• SLAとは何か
• SLAの代表的なもの

可用性について考察する

• 「コンポーネント単位に故障する」と考えて，パーツを組み込むか決めていく
• 難易度＝最大：ダウンタイムゼロ
• コラム　強固なシステムにするにはべき等性が重要
• 難易度＝高：ダウンタイム5分以内
• 難易度＝中：ダウンタイム30分以内
• 難易度＝低：ダウンタイム12時間
• コラム　「30分止められないシステム」ってどんなシステム？

性能について考察する

• 性能はアプリケーションの実装が重要
• ディスクアクセスとキャッシュのバランスを考える
• リアルタイム処理のSLAについて

運用性について考察する

• バックアップを取得しやすくする
• 定期リブートの時間を確保する
• メンテナンスの時間を確保する
• コラム　クラウド業者のSLA

後から変わるSLAで不幸にならないためにすべきこと

• ユーザーを怒らせない
• システムの変化を見逃さない

後々SLAでもめないためのインフラのポイント

• 価格交渉によって下がった金額で，少しだけ可用性・性能の良い製品を買う
• 性能が極端に悪くなる実装をさせない
• システムの動作が変化する設定を導入しない

第5章　OSSかプロプライエタリか

バグの対処の方法によってコストは大きく変わる

• 自分で保守・メンテし，問題があれば自分でソースコードを読んで改良する
• バグに遭遇したタイミングで自分である程度切り分けして，ソースコードの解析を依頼する
• サブスクリプションを購入しておき，サポートにすべて解析を依頼する
• コラム　イニシャルコストとランニングコスト
• OSSの導入・保守までSIerにすべて依頼する

OSSの強みとは

• ソースコードがオープンである
• システムをほったらかしにしやすい
• バージョンアップに柔軟に対応できる

OSSの向き不向きを考える

• 丸投げする人はOSSに向かない
• 開発や管理を効率化するツールに向く
• コラム　推理小説に似ているシステムトラブル

第6章　標準化でコストダウンは図れるのか

標準化の功罪とは

• 学びの場を失わせる標準化
• それでも標準化が必要な理由

コスト効率と安全性を追求する標準化の進め方

• 設計前のポリシー検討が重要
• 標準を検討するパラメータを洗い出す
• 洗い出したパラメータを選別する
• ポリシーを加味して標準値を決める
• 「標準という設計」を提供するのではなく，「標準設定された環境」を提供する
• 保守の担当をだれが担うか

第7章　運用・保守の効率化を考える

増えていくシステム，減らしにくいランニングコスト

• ユーザー企業のシステムは増加する
• インフラのランニングコストは後から変えられない

保守作業を合理化するための考え方

• 運用と保守の違いとは
• 保守作業を開発部門が担うべき4つの理由
• 工数の管理には注意が必要

運用フェーズのコスト削減のポイント

• 障害対応以外についてコスト削減の可能性を考えていく
• 通常運用外の個別対応が多ければ，運用として引き継ぐ
• 連携先システムに変更作業がある場合は，システム連携を停止する
• 開発環境に変更を加えることが多い場合は，メンテナンス枠を決めてしまう
• バグ対応やパッチ適用の情報はくわしい人に集約し，半年に一度まとめて適用する

開発・運用の分離とDevOps

• なぜ，開発と運用が分離されるようになったか
• 開発・運用の分離とDevOpsを無理に融合させようとする議論には意味がない
• コラム　インフラとアプリの保守の違い

第8章　教育コストと体制維持コストの負担

エンジニアが成長するための4つの基本

• 自走できない8割のメンバーをどう育てるか
• わからないことはまず自分で“時間をかけすぎず”に調べる
• 調べてもわからない場合は「自分でどこまでやったのか」を説明してから聞く
• わからないことは何でも聞く
• 学んだこと，教えてもらったことは自分だけのものにせず，後輩に教える
• コラム　先輩社員陣には厳しく

技術スキルの伸ばし方

• 1つの技術を極めていると，ほかの技術へ応用しやすくなる
• 第一人者を目指すか，ゼネラリストを目指すか
• すべてのエンジニアに必要なのがOSの理解
• 製品への理解を深める

教育のためのコストを捻出する

• OJTのコストはプロジェクトコストに含める必要がある
• 体制を維持しつつ，教育もする
• コラム　人が成長するチームから人が抜かれていく

第9章　サーバー（IaaS）のコストを考える

「速いか遅いか」「壊れにくいか壊れやすいか」の2軸でコストを考える

• 「速さと故障のバランス」が高い部品か安い部品かを決める
• 技術を知ってから価格を知る

CPUの費用対効果

• マルチコア時代の考え方
• マルチコア化はソフトウェアライセンスがかかる
• CPUがマルチコア化しても足回りがついてこれない

メモリの強みを理解する

• 現在はメモリのコスパがいい
• メモリにライセンス課金モデルを組んでいるソフトウェアはほとんどない
• 大量に搭載したメモリをうまく活用する設計が必要

ディスクの故障とシステム停止を想定する

• ディスクで一番重要なのは“書き逃げ”があること
• 書き込めていても読み込めないこともある
• ミッションクリティカルなシステムではロット障害に注意
• SANブート構成にするかどうか
• SSDをどう使うか

ラックマウントサーバーか，ブレードサーバーか

• ブレードは後から埋めた部分の耐用年数が短くなってしまう
• ラックマウントサーバー1台でまかなえる規模がかなり大きくなった

第10章　仮想化でリソースを効率的に扱う

見積もりとコントロールがうまくできないから仮想化が必要になる

• 「とりあえず見積もりは1.5倍にしておこう」と考える罪深きエンジニアたち
• なぜ，ムダに気づきにくいのか
• 一番無駄が入りやすいのがバックアップ
• コラム　ハードとOSの分断も仮想化のメリット
• 買いすぎるのは見積もりが下手だからか？
• 買いすぎを解決する3つの方法

リソースをリニアに追加・削除するときの注意点

• CPUリソースは柔軟に変更しやすい
• メモリリソースの追加ではパラメータの再設計，再設定が壁
• ディスクの追加ではレイヤーごとの設計を確認
• コラム　たくさん使えていそうで使ってない技術

集約率を高め，効果的に仮想化するには

• 仮想化するなら鼠小僧になろう
• N＋1方式でサーバーの稼働率を上げる
• オーバーコミットしてリソース効率を上げる
• 必要とされるリソース配分よりもメモリを多めに搭載したハードを選ぶ
• コラム　コンテナ化にはシステム設計の整理が必要

第11章　ストレージを効率的に使い切る

ブロックストレージの投資対コスト

• デファクトスタンダードのベンダーを比較のベースにする
• ブロックストレージの基本機能
• ハイエンドストレージが優れているのはディスクI/O性能と信頼性
• 書き込み内容の整合性管理，ディスクの故障管理はそれほど差がない
• コラム　運任せの製品とそうでない製品
• スナップショットは性能が多少犠牲になることがあるがコストメリットがある
• レプリケーション，帯域制御，データ保全が必要かは要確認
• 重複排除はスナップショットと組み合わせると効果的
• シンプロビジョニングは非常に有効
• コラム　RDBMSのエンジニアはストレージの理解も容易

思ったよりも使えないディスク容量

• 2TB玉のディスクを買ったのに1TBちょっとしか使えない現実
• RAIDとストレージの管理領域によって容量はさらに減る
• ミドルウェアまで含めると使える容量が1/4程度になる可能性も

ディスクの特性と価格変動を考える

• SASかSATAか，それともSSDかで単価が大きく変わってくる
• 価格は下がり続けるので，前もって購入してしまうと不利
• IOPSマジックには要注意

ブロックストレージ以外のストレージを使いこなす

• 非常に使いやすいが使いどころに注意が必要なNAS
• コラム　別の製品でもそっくりな仕組みを使っていることがある
• 拡大が続くオブジェクトストレージ

第12章　ミドルウェアがコストに与える影響を理解する

ライセンスコストが問題になりにくいAPサーバー

• ライセンスを意識することがなかったクラサバ
• JavaでもAPサーバーのライセンスが問題になることは少ない
• LAMP，MEANは基本的にライセンスコストがかからない
• Windowsでもライセンスのコストは小さい
• バッチ処理とシステム間連携に注意

高額でプロプライエタリなRDBMS製品を使う理由

• 安定したサポートを受けられる
• 性能に関しての情報を取得する機能が充実している
• 可用性を高める機能がある
• ナレッジが多く，扱えるエンジニアも多い
• 長期間使い続けられる
• コラム　ストアドプロシージャに頼った実装を好まない理由

RDBMSで無駄なリソースを使う問題をどう解決するか

• SQLでは性能の悪いコードをかんたんに作れてしまう
• 性能を確認しにくいのがSQLの難しいところ
• バッチ処理とオンライン処理でデータベースユーザーを分離する
• バッチ処理とオンライン処理のそれぞれのユーザーに処理制限をかける
• ほかのRDBMSへのポーティングでは工数の見積もりに注意

NoSQLの活用でコストは減らせるか

• 安いハードウェアをたくさん使ってスケールアウトするBASEの発想
• CAP定理があるためデータベースはスケールアウトが難しい
• NoSQLはまだコストを削減するフェーズに入っていない

アプライアンス製品か，汎用品か

• アプライアンス製品には汎用性がない
• 移行，ポーティングが難しい
• 運用方法が制限される
• バックアップが難しい

第13章　システムタイプごとの高コスト，低コスト

シンプルなAP，DBの構成

• 汎用的なIAサーバーを使う
• 仮想化を使ってリソースを柔軟に確保できるようにする
• CPUとディスクはオーバーコミットする
• N＋1の構成にする
• HAの切り替えは仮想化製品に任せる
• オンプレで進めるなら松竹梅プランにせず，細かい要件に柔軟に対応できるようにする

同時実行ユーザーが多いシステム

• スケールアウト構成を基本に考える
• 処理のピーク性を意識する
• トランザクションの厳密性が必要な部分を切り出す
• 一貫性をもたせてデプロイする
• 流量制限や利用停止できるようにする

ミッションクリティカル系

• 壊れにくいハードウェアを選択する
• 構成をシンプルに
• 足回りは強いものを選択
• インフラエンジニアがアプリケーションに介入する
• ウォームアップを入れる
• 最新のソフトウェアは使わない

スパコン・HPCの場合

• 動作させるジョブの性質を把握する
• 「動かしてみて，チューニング」を繰り返す
• ハード的な強さを事前確認する