書籍概要

コスパのいいシステムの作り方
~しっかり見積もりたいのに勘を使うジレンマに向き合う

著者
発売日
更新日

概要

「うちって,システムにお金をかけすぎじゃない?」

そんな問いに的確な判断を下すにはどうすればいいか。

「勘に頼らない技術を求めても,結局は勘に頼る部分が少なからずある」
「過去の事例と比較しても,元のコストがまちがっていれば誤りの連続になるし,すぐに陳腐化する」

そんなジレンマに悩む方のために,大規模システムを多数経験してきた著者が,最小限のコストで最大の効果を得る「勘と経験」の本質を教えます。

こんな方におすすめ

  • インフラエンジニア
  • アプリケーションエンジニア
  • アーキテクト
  • プロジェクトマネージャー
  • 情報システム部担当者
  • 経営者

著者から一言

システムのコストはわかりにくい

「うちの会社って,システムにお金かけすぎじゃない?」

そんな疑問を持つことがあると思います。中でも特に「わかりにくいなぁ」と思うのがインフラに関するコストではないでしょうか。
アプリケーション開発におけるコスト算出には,キロステップ数,FP法などさまざまな手法や考え方が導入されてきました。メンテナンスフェーズに入っても,その手法を活用することはできます。手法の良し悪しはあれ,一定の評価指標があって,それを参考にすることができます。
一方,インフラコストは,製品を購入する「モノ」の部分,それらを組み合わせ構築する「ヒト」の部分(工数)に大きく分かれますが,いずれも画一的な手法を考え出すのは非常に困難です。なぜなら,毎回がカスタムメイドだからです。「うちは標準化しているから」という会社もあると思いますが,その標準はその会社がカスタムメイドしたもので,業界標準ではないですよね。その標準は,正しいのでしょうか。時代に合わせてフレキシブルに見直せてますか?
さらに,総コスト(TCO:Total Cost of Ownership)で考えると大きなウェイトを占めるランニングコストもインフラでは重要な要素になりますが,その評価もまた非常に難しいものです。製品の保守料,システムを維持する人のための工数を正しく評価する必要がありますし,それらを削減しようとするといろいろ難しい問題に直面するのではないでしょうか。

「安定して動いているけど,ものすごく高コスト……」をどう考えるか

私は,これまで証券・銀行といったユーザー企業の立場で,さまざまな金融システムを構築してきました。はじめの数年はアプリケーションの実装担当でしたが,10年が過ぎて,気がつけばインフラ担当になっていました。非常にハイトラフィックなシステムや,止めてしまうと大問題になるシステムも経験しています。
もう10年以上前になりますが,担当していた非常に重要なシステムが大トラブルを起こして,即座に2ちゃんねるに書き込まれ,30分後にはYahoo!ニュースのトップで記事になり,翌朝には日経新聞の記事になったこともあります。そういうトラブルは,ITインフラの全面障害に近い場合に起きます。一度そういうトラブルを経験してしまうと,ものすごいコストと時間をかけてシステムを構築・増強します。コストと人をかけて構築したシステムは基本的に安定するのですが,5年以上経過して次のシステム更改を考えるときに,ふと思うわけです。

「たしかに安定して動いているけど,ものすごく高コスト。これって正しいのだろうか?」と。

そういうシステムは,社内的には特別扱いされ,ある意味アンタッチャブルな状況になっているわけですが,過去の苦い経験から,それを低コスト化に振る勇気はだれもありません。責任を取りたくないですからね……。しかし,必要以上の高コストはユーザー企業の判断としてはまちがっていて,自社の利益率を下げて,競争力を下げていることにもなります。5年ごとの巨大な投資,毎年高額な経費は,経営者の悩みの種です。
では,どうやって適切なコストに持っていくか。
身も蓋もない話ですが,経験と勘以上に正しく判断することはできないと思います。「経験と勘」と書いてしまうといかにも胡散臭い感じがしますが,実態としてはそうだろうと思って(信じて)います。
ただ,「コスト算出には経験と勘が必要なんだ」以上終わり,ではみなさんに何もお伝えすることがなくなってしまいます。もちろん,私もそれを望んではいません。

経験と勘の正体とは

経験と勘は身につけるものですよね。つまり,「コスパよくシステムを作るための経験と勘をどのように身に着けられるか?」が本書のテーマです。
そこそこの規模の企業になると,システム担当・部門,よく「情シス」などと呼ばれる組織があると思います。システム部門が適切にコストを算出するには,自分で開発できる能力を持っていることが極めて重要です。自分で開発した時のイメージがあると,ベンダーから受け取った見積もりに対して,工数が高ければ感覚的に疑問を持つこともできますし,「導入する製品が高すぎるのでは?」「別の製品に置き換えたほうが安くなるのでは?」と気づくことができます。
勘と経験の正体は「開発能力」と言っても過言ではありません。開発能力がないと,基本的に過去のプロジェクトの見積もりとの比較でしか評価できなくなります。実際にそういう仕事の仕方をしているシステム担当者が多いのではないでしょうか。過去のシステムコストと比較する意味はあると思いますし,一定の指標として活用できると思います。ただ,過去のコストがまちがっていれば誤りの連続になりますし,そもそも進化の速いITの世界にマッチした判断方法でもありません。過去の指標は,あっという間に古くなります。
本書では,テーマごとに私の経験と勘を明らかにしていこうと思いますが,以下のスキルが重要になります。

  • ITインフラを自分で構築できるスキル
  • システムの目的(SLA)を正確に把握するスキル
  • 採用する製品の動きや仕様を把握するスキル
  • アプリケーションの動作をイメージし,どのようにリソースが使われるかを推察するスキル
  • インフラを構成する要素技術の変化,今後の見通し,価格動向を把握するスキル

これらのスキルを,本書では3部構成でまとめています。まず第1章から第8章までは,システムを構築するうえでの前提知識をまとめました。システム構築は単に技術力があればできるものではありません。幅広い知識と経験が必要で,その要素をまとめています。続いて第9章から第12章まではインフラのテクニカル要素をレイヤーごとに記載しています。何か1つの製品については触れず,どのような製品を使っても役に立つ考え方を記載しています。最後に第13章は,それ以前の章の総まとめです。実際のシステムのパターンごとに,第12章までの知識を集約して考え方を整理しています。
これらのスキルは私のこれまでの経験によるものですが,どのように考えてきたかをお伝えすることで,みなさんの経験と勘にプラスできることを願っています。

目次

第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の場合

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

サポート

現在サポート情報はありません。

商品一覧