2007/10/02
【信頼されるSEへの道 第34号】運用・メンテナンス性を考えた設計
■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□ ┌───────────────────────────── 2007.10.2 │ │ 信頼されるSEへの道 〜成長し続けるために〜 第34号 │ │ http://blog.livedoor.jp/brave33/ │ │ メルマガインデックス−過去のメルマガ一覧 │ ⇒ http://blog.livedoor.jp/brave33/archives/50529551.html └────────────────────────────────── ■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□ こんにちは、MICK です。 ご無沙汰してます。また、久々の発行になってしまいました。 すでに秋らしい感じになってきましたね。 さて、今回のお話です。 ここ最近、設計をよく監査したり、検討することが多いのですが、結構、 運用や耐障害性、メンテナンス性を考えない、自己満足的な設計が多いこと に気がつきます。 本来、システムを安全に動かすための設計自体が足かせになり、システムに 悪い影響を与えている場合があるのです。 今回はITスペシャリストとして、失敗したたくさんのシステムや設計方法 から、本来設計時に考えるべき内容を示したいと思います。 この内容は、ITコンサルタントやビジネスアナリストにステップアップする 際の大事な思考テクニックとなるものです。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ <PR> 転職希望、自分の市場価値を知りたい方に朗報です！！ 「信頼されるSEへの道」が自信をもって、エージェントを推薦します ⇒ http://blog.mag2.com/m/log/0000208094/107875439.html ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 【信頼されるSEへの道 第34号】運用・メンテナンス性を考えた設計 ●なぜそんな設計なのか？ システムをリリースし、運用が軌道に乗るまでの一連の作業を経験して いないエンジニアに多いのですが、不必要に複雑、つじつまが合えばよい、 運用を考えてない、メンテナンス性が非常に悪い、といった設計を多数 目にします。 たしかに、システムとしては稼動します。 リリースもがんばれば、うまくいきます。 ただし、その後の実運用やユーザ対応などで非常にコストがかかります。 システムの耐用年数も考慮する必要があるのですが、多くの場合、 1年もたたないうちに相当のコストが掛かってしまい、その分ですべての 作り変えの費用を支払ってもおつりがくるくらいのことがよくあります。 通常は固定費や電話サポートの費用などとして計上されるため、目につき にくいのですが、個別対応やデータ復旧、日々の運用など、人件費ベース で考えると、理想的な設計を行った場合の2−5倍ものコストが掛かっている ことが少なくないのです。 それでは、いくつかの具体的なパターンからその内容について、考えて 行きたいと思います。 ●データの生存期間やパージを考えない 以前はハードウェア自体のパワーが低かったこともあり、冗長な設計は すぐにタブー扱いされ、データ自体がどのくらいの件数まで対応可能か ということを普通に考えていました。 しかしハードウェアが劇的にパワーアップを遂げると、多少適当で複雑な 設計をしても、アプリそのものは動いてしまうようになったわけです。 ただし、落とし穴はすぐに現れます。 限られたシステムとしてはよかったのですが、そうしたシステムも さまざまな連携を求められ、いろいろなデータの引っ張り方を要求され、 さらには個人情報保護で、不要になったデータは定期的に削除しなければ ならなくなったりします。 システムさえ動けばいいと設計したばかりに、のちのちの作り変えや データ運用、可用性などが犠牲になっていたパターンです。 データをパージ(削除)する際も、あまりに正規化されすぎているため、 停止時間を大量に作らないとパージできなくなるといった弊害がでることも あります。 それなりのデータベースエンジニアなどが監査していれば、この時点での リスクは減らすことができます。 ただし実際には、一人のエンジニアが設計し、ろくなチェックも行われず、 足りない項目を指摘する程度でレビューを終えてしまうことがほとんどです。 ●エンジニアの自己満足 システムそのものが目的化してしまっている場合、注意が必要です。 本来システムは目的達成の一手段であるべきなのに、システムの革新性や 研究開発的な視点に目線が移ってしまった場合です。 システム要件に複雑なサーバ構成を持ち込んだり、ビジネスロジックが 交通整備されずに実装に移っている場合などです。 もちろん、複雑さが必要なシステムもありますので、その場合はそれなりの 制御構造が必要です。 ただし、ビジネスアプリの多くはエンジニアの思い込みやベンダー側の意図で 複雑怪奇なものが持ち込まれることが多々あります。 ここに基本設計の重要さがあるのです。 目的の実情にあっているのか、もう少しイレギュラー処理を後工程にまとめ られないか、ビジネスの要求はそんなに複雑なところなのか？ その複雑さは、誰にメリットをもたらすのか？ 同じ機能を実現するなら、シンプルな方がいいに決まってます。 多少の要件変更で、大幅にいろいろなコスト削減ができるなら、変更を提案 すべきです。 ●開発時だけではすまない のちのちの変更や拡張を考えると、メンテナンス性は非常に大事です。 データ運用だけではなく、ビジネスの変更や拡張に伴う修正は発生して 当たり前だからです。 先日見たレポートでは、システムコストの70%近くが運用やメンテナンスに 割かれているという結果がでていました。 運用ドキュメントや各プログラム、スクリプトのコメントなど、それぞれが 目的にあって作成されていればいいのですが、スケジュールがタイトな開発 になればなるほど、これらの資料はろくなものになっていません。 最近はこうしたことも非機能要求として、顧客から求められることも多く なりました。 つまり、開発に着手してしまってからでは取り返しのつかないものも あるわけです。 ●ベンダーやチームのモチベーション これらのことを要約すると、簡単で安定した確実なシステムを作れ、 と言っている気がします。 たしかにユーザからすれば、ビジネスからすれば、それが求められます。 ただし、新しい技術にチャレンジしたり、触れたりする機会を与えることも 大事です。 そのため、ベンダーは新技術を使った提案や開発を取りたがるわけです。 それらが開発者やベンダーそのものの技術力の宣伝にもなり、メンバーの モチベーション維持にも役立つわけです。 新しい技術が悪いとは言いません。 ただし、使ったことのない新しい技術には不確定要素も多く、気づかない 制約事項となり、いつの間にかリスクになることもあります。 そのため、さまざまな技術で複合的にシステムが作成される際、新しい 技術ばかりをふんだんに取り入れるのは、リスクにリスクをのせることに なります。 本来、そのリスクを承知で開発に挑むべきなのに、新技術は楽だ、格好いい といった表面的な評価や営業トークだけを真に受けてはいけないのです。 ●終わりに 今回は「運用・メンテナンス性を考えた設計」と題して、その理由や目的に ついて簡単にお伝えしました。 最近では、機能要求と非機能要求と明示的にスペックが求められることも 多くなってきました。 ただし、逆に意識している企業と意識していない企業の差は大きく、我々 ITスペシャリストが気を引き締めないと、残業ばかりで作ったうえに、 顧客満足度の低い、動かないシステムを納品する羽目になってしまいます。 自分だけならまだしも、たくさんのメンバーや関連するパートナーの 幸、不幸すべてが掛かっていると思うと、ないがしろに出来ないことだと 思います。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ご感想やご希望などありましたら、以下までメールください。 なにぶん忙しいので、全てに返信はできないかもしれませんが、 全てのメールに目を通すようにします。 また、ブログを準備しましたので気軽にコメントをお寄せください。 ※セミナー講師、新人研修の講師、コンサルティング依頼などについても、 以下までメールでお願いします。 ⇒ メールアドレス： info@yscre.com ⇒ ブログ： http://blog.livedoor.jp/brave33/ ⇒ メルマガインデックス： http://blog.livedoor.jp/brave33/archives/50529551.html ⇒ 登録・解除はこちら http://www.mag2.com/m/0000208094.html SEの方々にとっても、できるだけ役に立つ情報をお届けします。 ご友人や仕事仲間の方にも、ご紹介いただけたら、と思います。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ メルマガインデックス−過去のメルマガ一覧 ⇒ http://blog.livedoor.jp/brave33/archives/50529551.html 【第1号】技術系SEの勘違い 2006.09.19 【第2号】本当に必要な新人教育 2006.09.26 【第3号】新人のときにおかれる環境 2006.10.03 【第4号】SEの常識？社会人の常識？ 2006.10.10 【第5号】信頼される上司 2006.10.17 【第6号】もう一つの組織 2006.10.24 【第7号】積極的な思考 2006.10.31 【第8号】メンバー同士の行き違い 2006.11.07 【第9号】プロジェクトのチェックポイント(1) 2006.11.14 【第10号】プロジェクトのチェックポイント(2) 2006.11.21 【第11号】プロジェクトのチェックポイント(3) 2006.11.28 【第12号】プロジェクトのチェックポイント(4) 2006.12.05 【第13号】プロジェクトのチェックポイント(5) 2006.12.12 【第14号】デバッグの方法・考え方 2006.12.19 【第15号】一年を振り返る 2006.12.26 【第16号】要件定義の重要性 2007.01.09 【第17号】要件定義から要求開発へ 2007.01.16 【第18号】要求開発−要求の分類方法 2007.01.30 【第19号】要求開発−各要求の関係 2007.02.06 【第20号】アジャイルに見る理想の開発(1) 2007.02.13 【第21号】アジャイルに見る理想の開発(2) 2007.02.20 【第22号】信頼できるパートナー(1) 2007.02.27 【第23号】信頼できるパートナー(2) 2007.03.06 【第24号】Network World Conference 2007 Spring 2007.03.13 【第25号】セキュリティ監査とポリシー(1) 2007.03.20 【第26号】セキュリティ監査とポリシー(2) 2007.03.27 【第27号】セキュリティ監査とポリシー(3) 2007.04.03 【第28号】セキュリティ監査とポリシー(4) 2007.04.10 【第29号】オフショアとSEマインド(1) 2007.04.17 【第30号】オフショアとSEマインド(2) 2007.05.01 【第31号】忙しいときこその仕事術 2007.05.15 【第32号】データ分析とジャッジメント 2007.05.29 【第33号】なぜコンサルタントを雇うのか？ 2007.07.24 【第34号】運用・メンテナンス性を考えた設計 2007.10.2 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ＜お薦め書籍＞ できる人のスピード仕事術―即効! これ1冊でスイスイ仕事がこなせる →http://www.amazon.co.jp/gp/product/4822222888/000jp-22 フラット化する世界(上) トーマス・フリードマン (著), 伏見 威蕃 (翻訳) →http://www.amazon.co.jp/gp/product/4532312795/000jp-22 フラット化する世界(下) トーマス・フリードマン (著), 伏見 威蕃 (翻訳) →http://www.amazon.co.jp/gp/product/4532312809/000jp-22 豆蔵セミナーライブオンテキスト(1) わかるオブジェクト指向 (単行本) 山田 隆太 (著) →http://www.amazon.co.jp/gp/product/4774124605/000jp-22 要求開発−価値ある要求を導き出すプロセスとモデリング 山岸 耕二 (著), 安井 昌男 (著), 萩本 順三 (著), 河野 正幸 (著), 野田 伊佐夫 (著), 平鍋 健児 (著), 細川 努 (著), 依田 智夫 (著), ［要求開発アライアンス］ →http://www.amazon.co.jp/gp/product/4822282686/000jp-22 NYPD No.1ネゴシエーター最強の交渉術 ドミニク・J. ミシーノ (著), ジム デフェリス (著), 木下 真裕子 (翻訳) →http://www.amazon.co.jp/gp/product/4894511851/000jp-22 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 日本一キーストロークの短いアドレス！！ ↓アドレスを短く簡単にします。↓ ⇒ http://000.jp/ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ .
