第5回 システムと業務をUMLでマッピングしよう
筆者が現行システムの見える化において「RUP（Rational Unified Process）」を用いる理由は二つある。一つは，作業の手順やその成果をすべてUMLで完結できること。全面的にUMLを用いることで，あいまいになりやすい成果物を論理的に一貫した形式で表現できる。 もう一つは，ビジネス分析モデルとシステム・モデルという抽象度の異なるモデル同士をひも付けられることだ。システムはあくまで業務を実現するための手段に過ぎない。そのシステムは業務とともに変化し続ける。こうした状況では，ビジネス分析モデルとシステム・モデルを同期させながら，継続的にメンテナンスできることが重要である。その点，UMLで業務とシステムをマッピングできるRUPは，見える化に向いた手法といえる。 まずはシステムをモデル化する RUPによる現行システムの分析（As-Is分析）は，システムと業務のモデル化を並行して進め，
第4回 データの「見える化」ならDFDを使おう
「ずいぶん前に使っていたと，先輩から聞いたことがある」「今はUMLがあるからそんな手法はいらないのでは」――。開発現場で最近，DOA（Data Oriented Approach）についてこんな声を耳にする。確かに，システムの部品化が進んでSOA（Service Oriented Architecture）に注目が集まり，UMLやBPMN（Business Process Modeling Notation）を用いたモデリング手法が広がりを見せている。 しかし，従来から変わっていないことがある。それはすべてのシステムは必ず「データ」を扱うことだ。システムが大きくなればなるほど，扱うデータも多くなる。ここで機能を中心に考えていると，データの漏れや不整合の発生を招き，システム全体を見渡すのが難しくなる。だから筆者は，データの流れの把握と分析に着目したDOAにこだわる。以下では，筆者が実践するD
第10回 ソースコードのロジックを見える化したい！
「全ソースコードを対象にした個別調査では，時間がいくらあっても足りない」──。昨年，改修に伴う影響分析で，500万ステップに及ぶソースコード（COBOL）の内部仕様を，わずか1カ月，それも1人で見える化した野村総合研究所の藤田由起氏（情報技術本部 生産技術部 副主任テクニカルエンジニア）はこう強調する。藤田氏は「複雑な内部仕様は全体の一部。それを全体の傾向から探り当てることが時間をかけない秘訣」と明かす。 内部仕様の中心は，処理ロジックである。この処理ロジックは，一部の言語を除いて，リバース機能を持つツールを使えば見える化できる。ただし，ソースコードが複雑に絡み合うスパゲッティ状態にあると，リバースしても内容が複雑すぎて解釈できない。その問題を回避するには，スパゲッティ状態のソースコードを，あらかじめ解きほぐす必要がある。 そこで藤田氏は，スパゲッティ状態にあるソースコードの全体傾向を「規
Part2 問題＆解決
現場担当者が悩む七つの疑問を取り上げる。Part1で解説した手法は，あくまでも手法に過ぎない。現場での経験を経なければ，実効性のあるものにはならない。ここでは，見積もりの手法を使いこなすノウハウを先人の経験に学ぶ。 見積もり担当者は，様々な手法を駆使した上で，試行錯誤を繰り返しながら後で困らない見積もりの算出に苦心している。まずは「見積もりの精度を上げるには？」「見積もりミスを後でカバーできる？」など見積もり担当者が疑問に思う七つの問題を取り上げ，現場での工夫からその解決策を探っていこう（表1）。
なぜ過ちを繰り返すのか？
なぜ過去の経験が生かされないのか。現場の声から探った。失敗の連鎖を断ち切るには，プロジェクトの情報を記録し，活用する技術が必要だ。 開発メンバーからの報告を聞いて，プロジェクト・マネージャ（PM）の大木太一氏（仮名）は肩を落とした。 「ERPのデータで不具合が起きています。製品の不具合のようです」。 リカバリに時間がかかるので開発作業が遅延することが確実になった。このプロジェクトを終えた今，大木氏は肩を落とした理由をこう振り返る。 「前回のプロジェクトでも，同じメンバーで同じ不具合を経験していたんです。それを回避する設計は分かっていたはず。なのに，また同じミスを繰り返してしまった。それがとても残念だったのです」。 前回のプロジェクトの教訓が生きていなかった。 終わらせ方が悪いと後で困る 同じ失敗を繰り返す現場は，プロジェクトの“終わらせ方”に問題がある。写真コンテンツの提供サービスを手掛け
［データ設計］マスター系と更新系を明確に分ける
福士有二 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部 データ設計の肝になるのは，データの最小単位であるデータ項目と，データ項目のまとまりと関連を示した論理データ・モデルである。画面設計や業務プロセス設計より先に設計作業を進め，追加や変更がある場合は速やかに対処することが肝心である。 図6に示したのが，データ設計で作成する設計書とその関係である。大きく分けて「(1)設計基準作成」「(2)データ項目設計」「(3)データベース論理設計」という三つのステップがあり，全部で8種類の設計書を作成する。要件定義で作成した「業務用語集」「概念データ・モデル」「データフロー図（DFD）」を用意しておこう。図7と照らし合わせて読んでほしい。
見積もりがブレるメカニズム
三者三様の見積もり結果となった。工程別に工数を積み上げるやり方，ステップ数を生産性係数で割って工数を算出するやり方，FP法を使うやり方など見積もりプロセスはまちまち。コストの見積もり結果も165万円から300万円までと，大きな差があった 3人はいずれも10年以上のキャリアを持つベテランSEである。にもかかわらず，見積もり結果には大きな開きが出た。なぜこんなに差が出たのか。彼らが使った手順とそのコメントから考えてみよう。 銀行のシステム開発・運用を担当する小沢勉氏（仮名，46歳）の場合，最初にプロジェクトを「基本設計」「詳細設計」「プログラミング」といった工程別に分割し，それぞれに必要と思われる工数を積み上げた。ただ，小沢氏はWebシステムの開発に携わった経験がない。「ホスト系の開発と同じような感覚で素直に計算すると，実績とズレた値が出ると思った。なので，工数の一部を修正した」と言う。 中堅
第1回 SAPアドオンを作れるABAPを体験してみよう
SAPジャパン フィールドサービス統括本部 エデュケーションサービス事業本部コンサルタント。SAP NetWeaver，エンタープライズSOA関連のトレーニングデリバリーを担当。 皆さんはSAPという会社やERPについてご存じでしょうか。ERPは一般に，財務会計，調達，生産，販売，在庫，人事など企業の基幹業務を統合した業務パッケージ・システムのことを指します。SAPは，ERPで最もよく知られた企業向けソフトウエア・ベンダーであり，企業システムにかかわる様々なソリューションやサービスを提供しています。 SAP ERPをはじめ，SAPの多くのビジネス・アプリケーションは「ABAP（Advanced Business Application Programming）」というプログラミング言語で開発されています。SAPシステムのプラットフォーム上にABAPの開発環境が用意されており，開発者やユーザ
［量子コンピュータ1］突然商用化した夢のマシン
実現は遠い未来のことだと考えられていた「量子コンピュータ」。それが突然、従来とは異なる方式で実現した。カナダD-Wave Systemsが開発し、米グーグルや米航空宇宙局（NASA）が導入した量子コンピュータ「D-Wave」だ。 D-Waveが期待通りの性能を出すことができれば、現在のビッグデータ活用が子供の遊びに思えてくるほどの、計り知れないビジネス上のインパクトがもたらされる。そんなD-Waveに、日本の研究や技術が大きく寄与していたことを知っているだろうか。 それだけではない。現在、日本の国立情報学研究所（NII）が、D-Waveのさらに上を行く日本独自の量子コンピュータの開発を進めている。 次なるIT革命の中心地は、実は日本だ。知られざる量子コンピュータの真の姿に迫る。 米航空宇宙局（NASA）や米グーグルが、熱い視線を注ぐ日本人研究者がいる。彼が生み出した理論が、「量子コンピュー
竹内 健の「エンジニアが知っておきたいMOT（技術経営）」
趣旨 技術力で優位でありながら事業で韓国企業や台湾企業に負けるのはなぜか。日本のエレクトロニクス復興には，技術開発の最前線にいるエンジニアが市場動向やビジネスモデル，サプライチェーンなどを常に考えながら技術開発を進めることが必要になる。本コラムでは技術開発を進めるためにエンジニアが知っておくべきMOT（技術経営）を紹介する。 1991年，東京大学 工学部物理工学科卒業。1993年，同大学院工学系研究科 物理工学専攻 修士課程修了。同年，東芝 研究開発センター USLI研究所 研究員。NANDフラッ シュ・メモリの研究開発に従事。東芝在籍の15年間に世界初の64M，256M，512M，1G，2G，16GビットNANDフラッシュ・メモリの商品化に成功。マーケティング，プロジェクトマネージメント，企業間交渉や米国法廷での訴訟などフラッシュ・メモリのビジネス広範に携わる。2003年，米 スタンフォ
運用担当者、激減中
ユーザー企業の情報システム部門で今、運用担当者の人数が大きく減り始めていることをご存じだろうか。 運用業務には、「アプリケーション保守」や「OS/ミドルウエア運用」、「ITインフラ運用」などがあるが、あらゆる業務に関わる運用担当者が減少しているのだ。まずは4社の事例を紹介しよう。 サイバーエージェント 運用担当者の人数 20人→0人（予定） サイバーエージェントで消費者向けWebサービスを手がけるアメーバ事業本部では、現時点で20人いるOS/ミドルウエアの運用担当者を、2年後の2015年までにゼロにする計画だ。 彼らは現在、OS/ミドルウエアをサーバーにインストールしたり、パッチを適用したり、アプリケーションの負荷に応じてサーバー台数を増減したりする業務を行っている。これらの業務を、オープンソースソフトウエアの運用管理ツール「Chef」を導入することで、自動化する計画だ（図1）。
CCPM
期間短縮を図るためのプロジェクト管理手法の1つ。工程表の作り方を変更し、締め切りを守る意欲を引き出す。実践にはプロジェクト目的や優先順位の明確化が必要。 仕事を納期通りに終わらせるうえでカギを握るのはモチベーションと集中力です。 しかしビジネスパーソンには、宿題に悩む学生と同様に、締め切りが迫るまで着手したくない心理がありがちです。また、上司から認められた納期よりも早く終了したとしても、言い出すメリットがないので前倒しの完了報告をしない心理もあります。 さらに、複数の仕事を同時進行で掛け持ちすることを当然と考えています。そのほうが時間を有効活用している気分に浸れるからです。しかし実際は、頭の切り替えに時間がかかるので、集中力が低下して仕事が遅くなりがちです。 TOC（制約条件の理論）の創始者であるエリヤフ・ゴールドラット博士は、そうした心理的な問題を回避できるプロジェクト管理手法を考案しま
第1回 Androidアプリの脆弱性とは
スマートフォンのアプリケーション・ソフトウエア（以下、アプリ）をインストールすることで個人情報が盗まれてしまった―。2012年前半からこんな事件がテレビのニュースや新聞の記事を時々、賑わすようになった。こうした悪さをするアプリ、いわゆるマルウエアが使う手口は、ユーザーを騙して不正なアプリをインストールさせ、ユーザーに気付かれないように端末内の情報（電話帳のデータなど）を取得するものであった。 Androidでは、当該アプリのインストール時にアプリが必要とする権限について提示する。ユーザーがこれを許可しない限り、アプリはインストールされず、データは窃取されない。しかし、多くのユーザーはアプリが利用する権限を気にせずにインストールする傾向にあるため、結果として電話帳情報や位置情報など個人に関わる情報が悪意あるものの手に渡ることになる。ユーザーの間で、アプリが求める権限を気にするという習慣が根付
プロジェクト名人を目指すなら知っておきたい「CCPM」
一般にプロジェクトとは、「独自の成果物（またはサービス）を創出するための期限のある活動」を指す。ルーチンワークさえこなせばよしとされる職務を例外として、多くのビジネスパーソンが、1度は何らかの「プロジェクト」に関わったことがあるはずだ。 そもそもIT業界や土木・建築業界では、大半の仕事がプロジェクトの形で回っているともいえる。そのほかの業種でもプロジェクトは珍しくない。新店舗や新商品などを開発することも、コンペなどに参加して勝利を得ようとすることも、被災地で期限を明確にして復旧/復興を図ることも、一種のプロジェクトである。 広義に解釈すれば、家族で手分けして家財を整理して引っ越すこともプロジェクトの一種と捉えられる。こう考えれば、プロジェクト管理のノウハウはビジネスパーソンだけのものではない。 これほど関わりの多いキーワードであるにもかかわらず、プロジェクト管理の行動特性（コンピテンシー）
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
バッファーマネジメントとモニタリングシート
上流工程-見積もり---目次：ITpro
Java技術最前線 櫻庭祐一 連載目次 ：ITpro