キャパシティ・プランニングの進め方：業務による負荷を洗い出す
キャパシティ・プランニングの作業手順は，3つのフェーズに分かれる。(1)構築対象のシステムが実行する処理の種類や量である「ワークロード（負荷）情報」の収集と，それを基にした性能要件の決定，(2)性能要件からリソースのスペックを見積もる「サイジング」，(3)サイジング結果を評価して精度を高めていく「評価・チューニング」である。 トランザクション処理とターンアラウンドタイムに関する情報を収集してシステムに必要な性能を見積もり，サーバーやストレージなどのスペックを決定する「キャパシティ・プランニング」の進め方を見ていこう。 図1には，キャパシティ・プランニングの基本的な作業手順を示した。作業手順は，大まかに次の3つのフェーズに分かれる。 (1)構築対象のシステムが実行する処理の種類や量である「ワークロード（負荷）情報」の収集と，それを基にした性能要件の決定，(2)性能要件からリソースのスペックを
第23回 一見ヒマな“予備兵力”を確保せよ 管理職は悪者になる勇気を持て
筆者が銀行のシステム部門で2～3年の経験を積み，ようやく一人前の仕事がこなせるようになったころ，同じチームのメンバーの仕事振りを見ていて不思議に思ったことがある。12～13人程度の小さなチームだったが，大きな案件を抱えて皆大忙しだったにもかかわらず，なぜか暇そうにしているメンバーが2人いたのだ。しかも，2人とも超のつくベテランSEだった。 ほかのメンバーが毎日深夜まで残業しているのに，この2人はほぼ毎日，定時に帰宅していた。筆者は納得がいかなかったので，チームを統括する課長に「なぜあの人たちに，もっと仕事を割り振らないのか」と聞いたことがある。すると課長はニヤリと笑ってこう言った。「彼らは予備兵力なんだよ」。 課長が言うには，現在のプロジェクトに，チーム全員のマンパワーを100％使ってしまったら，“突発的な事態”が発生したときに身動きがとれなくなる。だから“平時”には80％のマンパワーしか
木村さんが指南するDFDの上手な書き方
要求定義でDFDを利用する人は多いだろう。しかし，見よう見まねで書かれたDFDに出会うことも多く，業務の真の姿をとらえて構造化できていないケースも少なくない。 使えるDFDを書くにはどうしたらよいか。DFDの特徴に着目すると，上手な書き方が見えてくる。 「誰が」を記載しないこと DFDは，UMLのユースケース図と同様，対象となる業務の範囲を把握するのを主な目的として使われる図である。要求定義の初期段階で，システム化して解決したい問題領域を可視化することができる。要求定義でDFDをうまく書くには，DFDでは何が記述でき，何は記述されないのかをよく知っておくことが大切である。 ユースケース図と比較すると，DFDの特徴が浮かび上がってくる。（図1）の×印（図に記述しない対象）に注目してみよう。共通で×印が付いているのは「処理の順序やタイミング」だ。DFDとユースケース図は，これらが分からなくても
工事進行基準とJ-SOXの“最悪”な関係
工事進行基準と日本版SOX法（J-SOX）は、実はものすごく関係が深いのではないか――2007年秋ころから、記者はこんな疑問を抱いていた。受託ソフトウエアの開発に対し、工事進行基準の適用がほぼ決まりかけた時期だ。だがJ-SOXと工事進行基準の関係について明確に説明する文献はないに等しく、取材でもその話に出会えなかった。 「工事進行基準もJ-SOXも投資家保護を目的として適用される」「J-SOXの適用対象であるITベンダーが09年4月期以降から工事進行基準を採用すると、内部統制の整備・運用を見直さなければいけない」。こうしたたぐいの話は色々なところに書かれている。 記者の最大の関心は、工事進行基準を採用したITベンダーが実施する「見積もりの作成」や「進捗の把握」といった業務プロセスが、J-SOX対応の対象となるかどうかだった。J-SOXの適用対象となるとしたら、ITベンダーの負担が格段に増え
Eclipse 3.4の新機能は？ (1/4) - @IT
【改訂版】EclipseではじめるプログラミングNew! これからプログラミングを学習したい方、Javaは難しそうでとっつきづらいという方のためのJavaプログラミング超入門連載です。最新のEclipse 3.4とJava 6を使い大幅に情報量を増やした、本連載「Eclipseではじめるプログラミング」の改訂版となります Eclipseの星座は、“かに座” 2008年6月26日に、Eclipseの新バージョンEclipse 3.4（コードネーム「Ganymede（ガニメデ）」）がリリースされました。3.3がリリースされたのが2007年6月29日ですから、ちょうど1年間隔ててのリリースとなります。ちなみに、3.2が2007年6月29日、3.1が2005年6月27日、3.0が2004年6月25日ですから、6月の下旬に1年置きにコンスタントにEclipseの新版がリリースされています。Eclip
「ほかの誰のせいにもできない」Webアプリの脆弱性 ― ＠IT
2008/07/01 「これまでは脆弱性が発見されても、ベンダのせいにしていればよかった。しかし、今攻撃のターゲットになっているソフトウェアを書いているのは自社自身。ほかの誰のせいにもできない」――米国のセキュリティ組織、SANS Instituteの代表兼調査部門ディレクターを務めるアラン・パーラー氏は、7月1日に開催した記者説明会の席でこのように説明した。 SANSは7月1日、2日にわたって、情報セキュリティをテーマとしたイベント「SANS Future Visions 2008 Tokyo」を開催している。このイベントに合わせて来日したパーラー氏は、OSやネットワークに代わり、アプリケーション、それも独自に開発されたアプリケーションが攻撃者のターゲットになっていることを改めて指摘し、注意を呼び掛けた。 SANSが世界中に設置したセンサーを通じて収集した調査によると、攻撃のターゲットに
銀行の言語事情 - novtan別館
といってもグローバルに活躍するためのマルチリンガルな話ではありませんよ。 今やメガバンクになってしまいましたが、僕がIT業界に入ったときはまだ都銀と呼ばれていた某銀行でのお話。用語について一切説明せずに行ってみる。世代チェッカーかも。 ホスト系 今やメインフレームだからといってホストでもない時代ではありますが、都銀のシステムはトランザクション量やダウンタイムの問題からやっぱりメインフレーム、で、過去の遺産がありすぎてホスト型。 言語はCOBOLが中心ですが、コア部分に近づくとPL/Iだったりアセンブラだったりする。大事なスキルはJCLを書けること。まあ、JCL自体はシェルプログラミングと変わりません。VOL-=SELの指定とか面倒だけど。基本的に端末のI/Fを想定しているから、SNAとかFNAとかで通信しなきゃいけなくて手続きはめんどくさい。メモリとかディスクの容量が少なかったときの設計を
オフショア開発第三の地にベトナムが浮上
オフショア開発の地として新たにベトナムが浮上している。こつこつと仕事に取り組む真面目な人材が多く、人件費も安く抑えられることから、開発拠点に据える企業が増えている。だが安易にベトナムを選ぶと、成功は遠のくようだ。 業務を海外の企業にアウトソーシングするオフショア開発が欧米企業を中心に増えている。代表的な委託先としてインドや中国が挙がる中、第三の地として浮上しているのがベトナムだ。 ソフトウェアの開発年数は中国では30年に上るが、ベトナムはわずか10年ほど。エンジニアの技術力や数で中国やインドの後塵を拝するベトナムだが、政治や経済の変化によって投資の回収が困難になるといったカントリーリスクの影響が低いこと、人件費が抑えられることなど、開発拠点として優れた面も持っている。 日本ではエンジニアが慢性的に不足しており、優秀な人材の獲得は難しい。特に、製品のテストなど地道な仕事を担当する人材を確保す
サーバーエンジニアが入れておくと便利なFirefoxアドオン７選 - Unix的なアレ
サーバーエンジニアといえど、ページ表示のパフォーマンスチューニングなどブラウザで確認したりすることはよくあると思います。 自分自身のメモもかねて、そんな際に自分がよく使用しているアドオンを紹介したいと思います。 firebug JavascriptやCSSのコーディングをやる方にはおなじみですね。firebugです。私はjavascriptのDebugだけでなく、各コンテンツの取得時間を見る際にも使用しています。 https://addons.mozilla.org/ja/firefox/addon/1843 Yslow firebugに付加機能として追加できるyslowです。これもパフォーマンスチューニングの際には効果を発揮します。 expireの期間や、gzipしているかなどからそのページのパフォーマンスのランクを表示してくれます。 https://addons.mozilla.org
FlawedTheoryBehindUnitTesting - 単体テストに潜む誤った理論
FlawedTheoryBehindUnitTesting - 単体テストに潜む誤った理論 目次 この文書について 単体テストに潜む誤った理論 単体テストに潜む誤った理論 この文書について "The Flawed Theory Behind Unit Testing" の日本語訳です http://michaelfeathers.typepad.com/michael_feathers_blog/2008/06/the-flawed-theo.html 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... 私は Google の blogsearch 一式を使って単体テストに関する話題を拾っている。 普段は一週間に数十の blog やメーリングリストの議論に目を通す。 新しい話題もたまにはある。けれど、多くの話題は繰り返しだ。同じ主張が何度も現れる。 その中でもひときわ私を悩ませる
だれも教えてくれなかった外部設計の「極意」---目次
外部設計書で最も大切なことは，「システム開発を依頼してきたお客様」（発注者）に読んでもらい，理解してもらうことです。外部設計書を，開発メンバーではなく，発注者に理解してもらうためには，「いかに発注者にとって分かりやすい外部設計書を作成できるか」と「レビューを通じていかに合意形成を図るか」が重要になります。本連載では，発注者が理解しやすい外部設計書の書き方とレビューの方法に関する具体的なノウハウを解説していきます。 第1回 ユーザーと意思疎通が図れない外部設計書は危ない 第2回 ［システム振舞い編］一覧表に一工夫入れることで漏れや重複をなくす 第3回 ［システム振舞い編］全体を俯瞰でき，システム化範囲が一目で分かる業務フローを作成する 第4回 ［システム振舞い編］発注者が理解しやすいシナリオの記述方法 第5回 ［画面編］見れば“わかる”「画面レイアウト」の作り方 第6回 ［画面編］画面遷移を
第1回 ユーザーと意思疎通が図れない外部設計書は危ない
みなさんは，外部設計書を誰に読んでもらい，理解してもらおうとして思って作成していますか？レビューしてもらう開発プロジェクトのリーダー向けですか，後工程でプログラミングを担当してもらう技術者向けですか，それとも自分のためですか？ もちろん外部設計書は，リーダーも読みますし，プログラミングを担当する技術者も見ます。しかし最も大切なことは，「システム開発を依頼してきたお客様」（発注者）に読んでもらい，理解してもらうことです。上の質問に対して，「お客様」と自信を持って回答できることが，今の技術者に求められているのです。 外部設計書を，開発メンバーではなく，発注者に理解してもらうためには，「いかに発注者にとって分かりやすい外部設計書を作成できるか」と「レビューを通じていかに合意形成を図るか」が重要になります。 とはいえこれまでは，「発注者に理解してもらう」という観点での外部設計の体系的なノウハウはほ
「進捗率」では出来ないプロジェクト管理
4月18日，会社帰りに高田馬場の書店に立ち寄ると，予定どおり新著「間違いだらけのネットワーク作り」が店頭に平積みされていた。本を出版してもらうのはこれで6冊目だが，何度経験しても新しい本が出るのは嬉しいものだ。 まず，表紙が眼に飛び込む。前著「ネットワークエンジニアの心得帳」では筆が描かれていたが，今回はエンピツになっている。IT関係の本にありがちなピカピカと光沢のある紙じゃなく，落ち着いた色合いのシンプルなデザインが気に入った。手に取ってみると，いかにも紙らしいわずかなザラつき感があって手触りが良い。重さや厚さも手になじむ。中身で使われている紙はこれまでの本は純白だったが，今回はうすいクリーム色で眼に優しい。まるで自分の子供が生まれたように，新しい本というのはかわいらしく感じられる。 それから5日後，早くもこの本を読んでくれた方から感想を書いたメールが届いた。この方は情報部門の技術士で，
組込みシステム開発技術展レポート
会期:5月14日～16日 会場:東京ビッグサイト 組み込み関連のハードウェア/ソフトウェアの展示会である、「第11回組込みシステム開発技術展」が東京ビッグサイトにて、5月14日～16日の会期で開幕した。組み込み系製品の展示やデモのほか、専門セミナーも行なわれている。 入場料は5,000円。無料招待券の発送は終了しているが、オンラインで招待券引換証に入力/印刷の上、持参すると無料招待券と引き換えてくれる。 テーマがテーマだけに直接、コンシューマ製品とは関連しないものが多いが、Intelが先だって発表した、MID(Mobile Internet Device)向けプロセッサ「Atom」を搭載したものが数多く展示され、注目を集めている。 なお、会場ではソフトウェア開発環境展、データウェアハウス & CRM EXPO、データストレージEXPO、情報セキュリティEXPO、RFIDソリューションEXP
満足せる豚。眠たげなポチ。:業務システム開発でドキュメントを作ることについて
職場でここ３〜４ヶ月の間、システム再構成のためのドキュメント化プロジェクトというのを進めてきた。その中で『ドキュメントを書く』ということに対する意識が随分自分の中で変化したので、メモしておく。 まずは経緯から。 そのシステムは、いわゆるレガシーなシステムで、十数年来の歴史を持つ。これまで基盤が多少変わることがあっても基本的にソフトウェアアーキテクチャ（どのような単位で機能をモジュール化するか、どのように機能を抽象化し変化に対して柔軟にするか）に変わりはなく、作った当初の設計にツギハギしてメンテナンスを続けていた。 元々は、一体何をすれば増員以外の手段で開発量を上げられるかということを議論していた。現行のアーキテクチャのままでは求められる開発期間とバージョンアップのサイクルに対して近い将来限界を迎えることが明白であったためだ。 今のアーキテクチャや設計に問題があり、メンテナンス性を大いに損ね
ベトナムのオフショア開発事情知っていますか？
前回はインドのオフショア事情を紹介したが、今回はベトナムにおけるオフショア開発事情やベトナムの気質など幅広く紹介する。 ベトナムにおけるオフショア開発は、2～3年ほど前から「アツい」と注目されています。 しかし残念ながら、いまのところ「アツく爆発的に広がる」という状況ではなく、“大手を中心にジワりと広まりつつある”というのが現状です。そんなベトナムオフショアの魅力と、付き合う際のポイントをこれから数回に分けてお伝えします。 オフショア開発国としてベトナムが台頭してきた 中国における反日デモや、病気の蔓延（まんえん）などによる機能停止（または縮退運転）という事態が起きた際に、「中国への一極集中リスクに対する回避地」として、ベトナムが注目されるようになりました。 ベトナムは小中国といわれるほど、中国漢字文化圏の影響を受けていながら国全体が日本を向いており、逆に中国に対しては対中デモが行われるな
最後のボーランド製開発ツール？ Ruby開発環境プレビュー版を披露
ボーランドの開発ツール部門であるCodeGearは2008年5月9日、オープンソースのスクリプト言語であるRubyによるアプリケーション開発を支援するIDE（統合開発環境）「3rd Rail日本語版」のプレビュー版を披露した。3rd Rail英語版のバージョン1.1を日本語化したもので、「ベータ版だが、ほぼ完成に近い」（藤井等 CodeGearマーケティングディレクター）。製品版は5月22日に正式発表する予定で、価格や出荷時期はそこで明らかにする。 CodeGearは、ER/Studioなどのデータベース設計/開発ツール・ベンダーである米エンバカデロ・テクノロジーズに買収されることが決まっている（関連記事1、関連記事2）。買収は6月末に完了する予定。3rd Rail日本語版は、ボーランドCodeGear事業本部として投入する最後の新製品となる可能性が高い。 3rd Rail日本語版は、Ru
［見積もり編］WBSを軽視してはいけない
WBSは，見積もりの主要なツールの一つである。WBSとは，プロジェクトの成果物あるいは仕事（Work）を詳細化（Breakdown）して階層構造（Structure）で表現した図表のこと。WBSを作成する際のポイントは，プロジェクトで実施されるすべての作業を洗い出し，コントロールできる単位まで詳細化することである。 WBSを作成すれば，作業の漏れや重複を防げる。また，プロジェクト関係者の間で，成果物や作業などの認識のズレを解消できる。プロジェクトの成果物や仕事の責任分担を明確にすることもできる。 ただ，すべての作業を洗い出し，WBSを作成したからといって安心はできない。WBSをどのように書くかが重要である。 例えば，WBSにユーザーが作成する「業務手順書」があり，責任分担の「主担当：お客様」「支援：ベンダー」と記載してあったとする（図）。プロジェクト遂行中に業務手順書の作成が遅れると，ユー
第1回 Hudsonの導入 | gihyo.jp
継続的インテグレーションとは Hudsonの具体的な紹介に入る前に、まず簡単に「継続的インテグレーション」（Continuous Integration、以下CI）のおさらいをしましょう。CIは、Extreme Programmingに端を発し、Martin Fowlerによって広められた概念で、狭義には、別々に開発された部品を持ち寄ってお互いの動作を検証する「統合テスト」を早い段階から恒常的に行うことを指します。この当初の概念には必ずしも統合テストの自動化という考え方は含まれていませんでしたが、最近では、CIは単に統合テストだけではなく、広くビルド及びテスト全般を恒常的に行うことを指すようになり、またこれを現実的な工数で実現するための必須の手段として、ビルド・テストの工程を極力自動化する、という事が重要なポイントの一つになってきました。 この考え方の背景の一つには、コンピュータの高性能
「テストをすべきなのは知っているが，現実にはできない」という現場の状況をいかに打破するか，気鋭のソフト開発者とテスト技術者がパネル討論
「テストをすべきなのは知っているが，現実にはできない」という現場の状況をいかに打破するか，気鋭のソフト開発者とテスト技術者がパネル討論 Developers [Test] Summit 2008（デブサミTest） 「建前ではなく実際にテストを普及させるにはどうすればいいのか」。2008年4月23日，東京・九段で開催されたテストに特化したソフトウエア開発者向けカンファレンス「Developers [Test] Summit 2008（デブサミTest）」で「【徹底討論】テストなんていらない？！-テストを，どこまでやるべきか？」というパネル・ディスカッションが開催された。 司会を務めたのはタワーズ・クエスト プログラマ兼取締役社長であり，テスト駆動開発（TDD）の日本での第一人者である和田卓人氏。同氏に，オープンソース・プロジェクト「Seasar」のチーフコミッタであるひがやすを氏，テストの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
