)
Microsoft Solutions Framework (MSF) プロセス
Microsoft Solutions Framework (MSF) は、定義された一連の原則、モデル、規範、概念、ガイドライン、および Microsoft の実証済みのプラクティスに基づく、ITソリューション提供プロジェクトのための熟慮され鍛えられたアプローチです。 価値あるビジネス ソリューションを与えられた期間および予算内で作成するためには、実証済みのアプローチが必要です。MSF は、ITソリューションをより早く、より少ない人数、より低いリスク、より高い品質で構築するための、適応性の高いフレームワークを提供します。MSF を利用することにより、チームは、ITプロジェクト失敗の最も一般的な原因に直接対処することができ、プロジェクトの成功率を改善し、ソリューションの品 質を向上させて、より大きなビジネス インパクトをもたらすことができます。MSF は、ITプロジェクトや環境の動的な性質
開発プロセス導入のアンチパターン/パート2：プロセスと基準（中編）
反復開発は、初期段階におけるリスク削減と価値創成とのバランスを計画的に取ると最も効率的になることが分かっている。つまり、反復ごとに重視するものに優先順位を付ければ、最大の価値を提供する中でビジネス、組織、プログラム、および技術にとって最大のリスクを示す機能の開発を選ぶことになる。しかし、これら2つの目的（最大のリスクと最大の価値）は必ずしも常にそろっているわけではなく、早期の価値創成か早期のリスク削減のいずれかの計画的選択が余儀なくされる。 リスクを削減すれば、既製品（COTS）の選択やアーキテクチャの安定性、そしてチームの効率に関するわれわれの理解など、技術選択の不確実性も減少する。これらの要因と論理的に正しい見積もりを行う力は直接関係しているため、不確実性の削減は見積もりとの食い違いも低減する。 早期のリスク削減と価値創成はプロジェクトの成功にとって重要であるため（図2参照）、適切な基
反復開発の「ここはぜひカバーしたいポイント」/パート2：プロセスと基準（前編）
反復開発の「ここはぜひカバーしたいポイント」/パート2：プロセスと基準（前編）：The Rational Edge（1/2 ページ） 現代のソフトウェア開発作業のガバナンスに対してIBM Rationalが推奨するアプローチをカバーする連載の第2回となる本稿では、プロセスに絶対不可欠な構成要素や最適な評価指標を紹介する。 本連載のパート1「開発プロジェクトを『統治』するベストプラクティス」「開発プロジェクト『統治』のピンポイント解説」では、高効率ソフトウェア開発ガバナンスを紹介し、プロジェクトごとの成功に必要な組織と利害関係者のコラボレーションとともに、高効率ガバナンスの目的と原則を説明した。パート2では、高効率ソフトウェア開発ガバナンスに絶対不可欠なプロセスと基準周辺の手法に重点を置く。「プロセス」は、有効な高効率開発で利用される戦略を指しているが、その基本コンセプトはRational
要求開発にオブジェクト指向が本当に使えるのか？(1)
要求開発では，多くのUMLのダイアグラムが使われており，オブジェクト指向ベースのクラス図なども出てきます。技術者/開発者として，おそらく最初に思う疑問は「オブジェクト指向とかUMLとか，こんな難しそうなものをユーザーが果たして理解できるのか？ 現場で使えるのか？ 得ができるのか？」といったことだと思います。 私も要求開発の可能性に気づいて，要求開発に取り組み始めたのですが，取り組みながらもぬぐい去れない疑問が，上記の内容でした。 この問題を整理していきたいと思います。ITをビジネスで活用するシーンを想像してみましょう。要求開発アライアンスでは，システム開発を大きく二つのフェーズに分けています。一つは，存在する要求やRFP（Request For Proposal）にしたがってシステム作る「システム開発」フェーズ。もう一つは，戦略からシステム化する要求を作り出す「要求開発」フェーズです（図1
Part8 業務の目的と要求――利害関係者を漏れなく洗い出す,目的を構造化して業務要求を定義
Part8では，プロジェクトという視点を加えて利害関係者を考えます。利害関係者の目的とその構造を明確にして業務要求を定義します。要求の優先度は，重要度とリスクを加味した難易度で決定します。 Part8は，演習編の6回目です。Part7までは，業務システムの動的な振る舞いであるプロセスや，業務の静的な構造に着目する演習を解説しました。対象とする業務を様々な視点から分析してきたわけです。 Part8では，対象とする業務そのものだけではなく，業務を改善するためのプロジェクトという視点も考えます。業務は，理想と現実というギャップを抱えています。そして，そのギャップを解消するのがプロジェクトです。すなわち，業務を“問題領域”とすれば，プロジェクトは“解決領域”になります。 Part8の演習の目的は，プロジェクトの利害関係者を漏れなく洗い出し，利害関係者の目的とその構造を明確にした上で，業務レベルの要
Openthologyのプラグイン
本稿の第一回では，要求開発の四つのフェーズの一つである立案フェーズに注目し，ビジネスの本質レベルでの可視化を行う「概観ビジネスモデリング」について述べました。第二回では，概観ビジネスモデリングにおいて有効な業務フローの表記法の例として，LFD（Lane Flow Diagram）を紹介しました。 Openthologyは，要求開発の実践のために有効な手法を「プロセスセル」という単位でプラグインすることを考えています。LFDは，「LFDによる概観ビジネスモデリングプロセスセル」として，立案フェーズにプラグインされています。今回は，Openthologyのプラグインについて紹介します。 プロセスキャビネット 第一回で述べたように，Openthologyでは，要求開発の各段階を「フェーズ」と呼び，「準備」「立案」「デザイン」「シフト」の四つのフェーズを設定しています。そして，フェーズごとに行う作
概観ビジネスモデリングによるビジネスの「見える化」
Openthologyでは，準備，立案，デザイン，シフトの四つのフェーズを定義し，段階的な詳細化，モデリングなど要求開発プロジェクトの推進をガイドします。今回は，立案フェーズの「概観ビジネスモデリング」について紹介します。 筆者は，ITコンサルタントですが，ユーザー企業の情報システム部門で十数年間システムの設計・開発に携わった経験があります。企業がIT投資の対価として求めるものは，コストの削減や付加価値の創造です。 技術の進歩やインターネットの普及によりITで実現できることが広がる中，最近では，業務の効率化，コストの削減といったテーマに加え，企業の本業に近い分野で，経営戦略に直結したビジネスシステムを構築するといったテーマが増えているのを実感します。 経営戦略の実現を支えるビジネスシステムを構築する場合，企画段階におけるシステムへの要求はあいまいである場合が多いです。この場合，経営戦略の「
要求開発は誰のためのもの？
筆者は，SI企業で働く20代のエンジニアです。これまで小規模なプロジェクトにSEとして参加してきました。残念ながら，現場で要求開発に携わった経験はありません。 こんな私ですから，アライアンスの定例会でとある方に「要求開発は誰のためのもの？」というシンプルかつ本質的な質問をされたとき，思わずうろたえてしまいました。そのとき自分がどう答えたかは忘れましたが，とにかく理解不足が露呈してしまったことだけは覚えています。そう，うまく説明できないことは，十分理解できていないことの証なのです。 このとき，助け舟を出してくださった方が私に代わって説明してくれたのは，「要求開発は，ユーザー企業のためのもの」ということでした。しかし，まだ私にはなぜ「ユーザー企業のためのもの」なのか，その意味が今一つ理解できていませんでした。 消化不良気味の様子の私に，その方が質問を投げかけました。「ユーザー企業は何のためにI
反復型開発における見積もりの実際：ベースとなるのはユースケース
オブジェクト指向技術の浸透や，反復型開発の広がりなど，システム開発を巡る状況が大きく変化している。見積もり方法も，従来のやり方では通用しないケースが増えてきた。反復型開発における見積もりの基本的な考え方や，ユースケース・ポイント法の活用手順について解説する。 オブジェクト指向開発の普及に伴い，ソフトウエアを段階的に繰り返して開発していく「反復型開発（イタラティブ開発）」を採用するプロジェクトが増えている。反復型開発は従来のウォーターフォール型開発とは基本的な考え方やフェーズの分け方が異なるため，従来型の見積もり技法を適合できない面がある。 そこで第4部では，反復型開発における見積もりの基本的な考え方と，現在，一般的に用いられている「ユースケース・ポイント法」を中心とした見積もり技法について解説する。なお，システム開発のプロセスは反復型開発において最も標準的な「統一プロセス（Unified
開発標準導入の阻害要因
ソフトウェア開発を主業務とする企業や部署においては、常にその改革・改善が求められているはずだ。そこでは開発標準の導入や改善が、1つの大きな改革・改善項目の候補になることは明らかである。 1. ソフトウェアの開発標準の現状 「自社の開発標準がある 52.2％」 これは、少々古いですが2003年に日経ITプロフェッショナル誌が行ったアンケート（日経BP社発行 日経ITプロフェッショナル 2003年7月号 「開発プロセス大全」より引用）結果です。これだけを見ると、半数とはいえ日本でも開発標準を活用した組織的なソフトウェア開発が行われているようにみえます。しかし、同じ調査で以下のような結果も出ています。 「開発標準の種類：ウォーターフォール型 82.8％」 これだけでは何とも断言できませんが、おそらくこれらの標準の大半が、メインフレームやオフコン向けの開発標準の可能性があります。実際、筆者がいろい
要求開発におけるモデリングのコツ(2)---ユーザーの視点でモデリングせよ
前回触れたように，要求開発におけるモデリングにはシステム開発の場合とは違った難しさがある。中でも問題となるのが，モデルを理解すべきユーザー（業務担当者）自身がモデリングの重要性を認識していない場合があることだ。 こうした場合，いきなりUMLのモデルを業務担当者に示しても，「理解できない」と拒絶される場合が多い。そもそも，業務モデリングでUMLによる表記などの細かい流儀にこだわるのが間違いと言える。前回の表にもあるように，要求やステークホルダを一覧表にまとめたものも立派なモデルなのだ。モデルが必要だからといって，やれUMLだのと肩肘をはる必要はない。普通に分かりやすく書くにはどうするべきかを考えてみるとよいだろう。 要求開発のモデルは，システム設計とは違い，業務の観点から行うものである。こうした業務レベルのモデルでは，表記方法の正しさや整合性はそれほど重要ではない。それよりもまず，業務担当者
要求定義の方法論を知る【前編】：DOA型要件定義の実際
日本IBMのシステム開発プロジェクトで多くの実績を持つDOA（データ中心型アプローチ）型の要件定義手法を解説する。「いまさらDOAか」と思う読者もいるかもしれない。しかし，DOAはあらゆるプロジェクトに応用できる極めて基本的なアプローチである。基本をしっかりと押さえて欲しい。 「いつまでたってもユーザーインタフェースが決まらない」，「設計の段階で機能が追加され，開発範囲が膨れ上がった」，「テスト段階に入ってからも仕様変更が多発する」，「システム・テストの中盤でデータベースが変更され，すべてのテストをやり直さなければならない」…。システム開発ではこうした声があちこちのプロジェクトで聞かれる。なぜこのような状況がいつまでも改善できないのか。結論から言えば，これは要件定義のやり方にそもそもの問題がある。 本来システム開発プロジェクトでは，予算，期間，開発の優先順位に見合った最適なスコープ（開発範
アーキテクトはコンポーネントをうまく使う
もちろん、各項目の知識やスキルは大本でつながっているので、例えばファシリテーションやネゴシエーション能力がなければプロジェクトはマネジメントできないし、最適な開発方法論を適用するには、当然技術知識が必要になる。足りない知識やスキルは実践で身に付けるか、または講習やセミナーを受けて勉強するなどして、ITアーキテクトとしてのスキルを磨いていくのだ。 この表に挙げたもののうち、特に実績とノウハウが要求されるのが「システム設計」と「総合」分野だろう。「技術」や「開発」も当然ノウハウが必要だが、この分野に関していえば、SI企業の多くが事例をデータベース化し、ノウハウを共有できるようにしている。そういう意味からいえば、ファシリテーションやネゴシエーションは、個人の資質やアイデアとも関係する分野であり、なかなか汎用的な知識となりにくい。 一方「システム設計」は、ある程度データベース化されているとはいえ、
【中級】反復開発 現場のノウハウ 第1回
決まらない要件や不安定なアーキテクチャ――。システム開発における「リスク」は年々増大し続けている。だが，リスクという課題に対して，従来のウォータフォール型開発では力不足だ。今，現場の開発者たちは反復型開発でリスクと上手に付き合う解を見つけた。先行ユーザーの成功と失敗から得られた最新情報を基に，実践上のポイントを明らかにする。 「1200万人分のバッチ処理をJavaで成し遂げなければならない」──。初めて挑む技術的難題に対して，電通国際情報サービス（ISID）の土屋尚友氏（産業ソリューション開発部 グループマネージャー）は，反復型開発プロセスのRUP＊1に活路を求めた。技術リスクを抑えることに適した開発プロセスと考えたからである。結果は，土屋氏の狙い通りに成功を収めた。 一方，ディーシーカードでカード会員向けのサイト構築を指揮する小林良彦氏（デジタル事業推進部 インターネット推進グループ 部
要求開発におけるモデリングのコツ(1)---観点と粒度に着目せよ
表1を見ればお分かりの通り，システム開発と同様に要求開発においてもモデルの多くはUMLで記述する。一般に，1つのモデルは多面的ないくつかの視点で示される。例えば概観ビジネスモデルは，ユースケース図，クラス図，業務フロー図といった複数のダイアグラムで表現する。これは，立体を表現する際に，三面図や影など複数の視点の図を利用するのに似ている。表1は，要求開発の各フェーズの成果物においてどのようなモデルを利用するべきか，その指針を示していると言える。 システム開発におけるモデリングの経験がある人なら，表1を参照して必要なモデルを作成していけば済むと思うかもしれない。しかし，それだけでは要求開発におけるモデリングはうまくいかない。モデリングで大切なのは，モデルの「観点」と「粒度」だ。たとえ同じようなモデルを描くにしても，システム開発と要求開発ではこの「観点」と「粒度」が異なるのである。 観点とは，モ
Main Page - SAD
Introduction This wiki was initially developed in the context of an Independent Study course of the Masters of Software Engineering program at Carnegie Mellon. The wiki contains a template for a wiki-based software architecture document, the documentation of the architecture of the Java Pet Store v1.4 application, and reflections. The goal of this academic exercise is to evaluate: how well differ
現場で使うOpenthology(2)---おいしい部分だけを“つまみ食い”
前回は，「使われないシステム」が出来上がる原因が要求定義にあると考えていた折に，要求開発方法論Openthologyに出会い，筆者の悩みを解決する大きな助けとなったことを述べた。今回は，Openthologyを実際のプロジェクトに適用する際のヒントをいくつか紹介したい。 システム開発に取り掛かる前段階としての要求定義では，様々な問題が発生する。筆者がこれまで携わったプロジェクトでも，「システム化する部分ばかりに目がいって，ビジネス上のゴールまできちんと詳細化できない」「要求仕様が膨れ上がってまとめきれず，時間切れになる」といったケースがあった。問題を簡単にまとめると，以下の2つになるだろう。 (1)要求を検討する際の目的とゴールが明確になっていない。 (2)本来議論すべき対象が可視化できておらず，議論が発散する。 こうした問題を解決するために，筆者は身近なプロジェクトにOpentholog
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CC V3 プロトタイプ型機能特定保証ガイダンス
IBM Developer
http://damagecontrol.codehaus.org/Continuous%20Integration%20Server%20Feature%20Matrix