ユーザー要件を引出すテクニック： ユースケースかストーリーボードか
ユーザー要件を引出すテクニック： ユースケースかストーリーボードか：The Rational Edge（1/2 ページ） 機能はITシステムを成功させるために重要な要因の1つだ（最も重要だとする声もある）。ユーザーは、自分たちの仕事が楽に、早く、確実に片付くよう、ITシステムが支援してくれることを期待している。ユーザーは、ヒューマン・コンピュータ・インターフェイス（HCI）経由でシステムと対話するが、1990年代前半にGUIが台頭したことで、多くのユーザーが自分たちのニーズやシステムとの対話方法に対する希望を明確に示すようになった。ソフトウェアエンジニアリングにおけるHCIに重点を置いた場合、そこには解決しなくてはならない2つの問題がある。a）一般に、ユーザーはユーザビリティの専門家ではないこと、そして、b）ソフトウェアエンジニアはHCIの内側にある機能を特定し、それを構築しなくてはならず
第1回 要件定義作業を容易にするシステム化企画書の意義 | IT Leaders
「ユーザー企業が必要としているシステムはどのようなものか」を定義する要求仕様書。実際に作成する上では、まずはきちんとしたシステム化企画書をまとめることが肝要となる。システムに求める機能はUML（統一モデリング言語）で定めるユースケース図を用いると分かりやすい。 要求仕様を取り巻く議論が活発だ。書店には要求仕様を冠とする書籍が立ち並ぶ。どれを手に取ってもなるほどという内容だが、これらの本に1つだけ欠けているものがある。それは、要求仕様を書く側の技術力について言及されていないことだ。 それだから本を読めば要求仕様書が書けると勘違いしてしまう。要求仕様書を書くには深い業務知識と経験が必要である。さらにITについても造詣が求められる。ことはそう簡単ではない。 しかしながら要求を仕様化する方法や手段は「要求仕様技術」として少しずつ確立されつつある。技術であれば習得することができる。 この連載では、シ
要求分析に表れるソフトウェア技術者の心
要求分析に表れるソフトウェア技術者の心：上を目指すエンジニアのための要求エンジニアリング入門（3）（1/3 ページ） 上級技術者を目指すのであれば、要求エンジニアリングの習得は必須である。要求を明確化できれば、後工程の不具合が減少し、プロジェクトコストの削減や競争力強化につながるからだ。6回に渡って、要求エンジニアリングの基礎を解説する。 在庫調整が進んだので生産増、景気回復が望めるとの一部報道がある。しかし、経済環境は相変わらず厳しい。 とはいえ、ソフトウェア開発を糧にして生きるには、ソフトウェアの開発需要が必要である。需要の提供者、中でも業務システムを必要とするユーザー企業、およびソフトウェア製品やソフトウェアを組み込んだシステム機器ベンダの多くは急激な収益悪化に直面し、コスト削減を迫られている。こんな時期には、収益向上あるいはコスト削減に効き目があると期待できるソフトウェアやシステム
第8回 「遺失物管理」と「M&A案件管理」は同じか？
経営者にとって、情報システムは頭痛の種になりがちだ。業務に必須だが投資に見合った効果が出るとは限らない。ほかの設備投資に比べて専門的で難解でもある。 野村総合研究所で約20年間勤務した後に、人材派遣大手スタッフサービスのCIO（最高情報責任者）を務め急成長を支えた著者が、ベンダーとユーザー両方の視点から、“システム屋”の思考回路と、上手な付き合い方を説く。 前回（第7回）では、私が“システム屋”と呼ぶITベンダー・システムインテグレーターが、業種ごとの組織体制とは異なる組織体制を作れば、従来とは異なる可能性が広がるのではないかということを説明しました。例えば、食品卸や証券会社、人材派遣会社などは、業種は違っても“仲介業”という業態で見れば同じです。互いのノウハウ・価値観を共有できる可能性があるのです。 ただし、一見“仲介業”に思えて、価値観が違うということもあります。私が経験した事例を挙げ
クリエイティブなエンジニアスタイル５カ条：第4条：要求開発まで踏み込むべし | 豆蔵ソフト工学ラボ
クリエイティブなエンジニアスタイル５カ条 第4条：要求開発まで踏み込むべし 印刷 株式会社豆蔵 プロフェッショナルフェロー 萩本 順三 2009/04/22 ［業界への提言］ 要求開発とは、ビジネスを"見える化"し、IT化すべき箇所をできるだけ早く定め、そこに必要とされる要求を決めていく活動ことである。要求開発はビジネス開発と言っても過言ではない。クリエイティブなエンジニアスタイルとして、なぜ要求開発まで踏み込むべきなのか説明しよう。 第4条：要求開発まで踏み込むべし エンジニアリングを楽しむという事 クリエイティブなエンジニアは、エンジニアリングを楽しむべきである。そしてエンジニアリングの価値を証明すべきなのである。 エンジニアリングを楽しむためには、納得感のあるエンジニアリングを行うことが必要となる。なぜなら納得感があるからやりがいがあり、楽しめるからだ。 さて、エンジニアは、どのよ
Part1 成功に導く必須スキル
方法論はそれなりに整備されているものの不完全。ユーザー企業は要求を決めず，またコロコロ変える――このような状況から脱却するにはどうすればいいのか。結論を言えば，「銀の弾」は存在しない。やるべきことを地道に実践するのがベストだ。 要求定義に絡む問題は根が深い。ユーザーからあいまいな要求しか出てこなかったり，要求があとからコロコロ変わったりするケースが少なくない。しかも，よりどころとなるべき方法論は不完全。それどころか，標準的な方法論がない企業や組織もある。こんな状況に直面すれば，「要求定義をうまくやるなんて無理」と諦めてしまうかもしれない。しかも最近は，要求定義の難しさがますます増している（図1）。 だからといって手をこまぬいているだけでは，システム開発プロジェクトで品質，納期，コストを遵守することは難しい。プロジェクトを成功に導くためには，最上流である要求定義こそが最も重要だからだ。 4つ
株式会社マジカジャパンの羽生章洋が書いてるブログ:営業と要件定義 - livedoor Blog（ブログ）
そういう不可欠の職種である営業ですが、良い印象を与えないことがある理由は何かというと、無理矢理押し込むという風に思われているからではないかと感じます。要するに押し売りなのではないかと。あるいはyes but法などに代表されるような、ああいえばこういう的に言葉巧みに相手を追い込んでいくというような、駆け引きで買わせるという風に思われていることもあるかもしれません。 しかし私どものような業務システムの受託開発のように、既に存在する商品を売るのではない、所謂ソリューション営業あるいはコンサルティング営業の場合には、この押し込み型の営業というのは、実はなかなかに厳しいものがあります。 SI業界でも押し込み型の営業スタイルで成功体験を築き上げてきた方々はいます。ただその場合は、よくよく見るとシステムというよりもやはりハードウェアありきだったと見受けられることが多いのです。 受託開発の営業というのは、
眠る開発屋blog｜最新オンラインカジノのニューカジノ情報
もしもこの世から「残業」が完全になくなったら ３年ぐらい前に読んだ本を思い出した。 １９８０−９０年代の話ですが、残業について、 「時間外・休日労働の弾力的運用が我が国の労使慣行の下で雇用維持の機能をはたしている」（１９８５年労働基準法研究会報告）とか、「我が国の労働慣行の実情に合うような上限設定が可能かどうか定かでない」（１９９２年同報告）と、雇用維持の為のコストとして恒常的な長時間労働を是認する考え方が主流でした。 需要の低下に応じて、生産水準を下げなくてはならなくなっても、バッファがあるから解雇せずに大丈夫でしょ、という。。。 まぁ、 ところが、その後、労働法政策が内部労働市場の雇用維持から外部労働市場における移動促進に徐々にシフトしていったにもかかわらず、この長時間労働哲学には疑問が呈されないまま２１世紀に至っているのです。 と著者は問題視しているわけだけど。 話変わって、最近友人
アジャイルだウォーターフォールだいう前にさぁ - Identity Not Found
もうさあ。 アジャイルだかウォーターフォールだかどうでもいいよ。 どっちでもいいから、ともかくまずは顧客の要望をきちんとほじくりだして並べてみせてくれよ。 通り一遍のヒアリングでいきなり開発し始めておいて、そうじゃなくてこんなのがいいって指摘したら、仕様変更です直せるけど納期に影響が出ますって。それがアジャイルとかいう手法なのかい? 顧客の出した要望は開発側でまとめてくれよ。顧客が自分でまとめた要望なんて穴だらけなんだよ。 この要望でどんなものが出来上がるのか、開発側は頭ん中にすぐに組み立てられるだろうさ。けど顧客側にはわかんないんだよ? どんなものが出来上がるのか想像もつかないのに、最初から満足な量の要望なんて出し切れないんだよ? 要望を仕様書としてまとめる代わりに、いわゆる「最低限を満たして動くもの」をもってきたとしよう。それに誘引されて顧客側の頭のなかに「どんなものを作るべきなの
機能要件設計書だけで20種類
意図が伝わる設計書を作るには，前提として「それぞれの設計書がどういう役割を担うか」「それぞれの設計書が相互にどういう関係にあるか」を正しく理解しておくことが重要である。豊富なサンプルとともに，設計書の役割と関係，さらには書き方のコツを解説する。 石川貞裕 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部 担当本部長 向坂太郎 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部 「基本設計書」と聞いて，どんなものをイメージするだろうか。業務フロー図や画面レイアウト，E-R図など様々だろう。大規模，高品質のシステムを開発するなら，図1に示すような多くの設計書を作成することになる。 中心となる機能要件設計だけでも20種類。それぞれの役割や関係をきちんと理解し，過不足なく設計情報を盛り込むことが求められる。 難しいのは，設計書の読み手が開発者だけではないことだ
仕様分析
どういったソフトウェアを作れば要求を満たせるのかを考えるのが仕様分析 のステージです。仕様分析のステージのアウトプットは仕様書です。 仕様書とは「何をすればいいのか」を規定するものです。「それをどのように 解決するのか」はここでは問題としません。まずは解決すべき問題をはっきり させましょう、というのです。 なお、ここで紹介する方法はあくまで数ある方法のうちの一形式であって、こ うしなければいけないというわけでもありません。対象となるソフトウェアに よって方法には向き不向きがありますので、いろんな方法を研究して自分なり に考えてみるのがいいでしょう。 目次ドメイン分割アプリケーションドメインオブジェクトの定義まとめ
画面設計とか外部設計とか、もうやめようよ - masayang's diary
昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう？ 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え
生き残るために「要求エンジニアリング」を学ぶ
生き残るために「要求エンジニアリング」を学ぶ：上を目指すエンジニアのための要求エンジニアリング入門（1）（1/3 ページ） 上級技術者を目指すのであれば、要求エンジニアリングの習得は必須である。要求を明確化できれば、後工程の不具合が減少し、プロジェクトコストの削減や競争力強化につながるからだ。6回に渡って、要求エンジニアリングの基礎を解説する。 2009年、世界経済にとって厳しい年を迎えた。IT／ソフトウェア業界においても、ほかの業界と同じく厳しい時代になるだろう。この業界ではコストの大半を固定費である人件費が占めており、経済環境の変化に対応する力が弱い。だから、経済環境がいっそう厳しくなれば、プロジェクト価格の低下はもちろん、プロジェクト件数も減少し、ベンダ間の競争が激化する。企業は利益を出すために――いや、企業を存続させるために、多かれ少なかれ人件費の削減、時間単価の切り下げや時間当た
あいまいな要件定義は問題，ビジネスモデルの変革が必要
システム開発契約やソフトウエア開発を巡るトラブルに詳しい弁護士として知られる。数多くのトラブル案件にかかわった経験を基に、要件定義の重要性を指摘する。要件定義の支援を専門に手掛けるコンサルタントの育成と開発プロセスの透明度向上で要件定義の質を高めることが、システムに関するトラブルを減らすために有効だと明言する。 システム関連のトラブルが、訴訟に発展するケースが増えています。 一般的に、システム関連のトラブルの争点は、いくつかに分類することができます。 契約が成立したかどうかという契約の正否に関するものが一つ。それから追加契約したかどうかあいまいなままに、ずるずる仕様を変更してしまって結局、きちんと契約していたかどうかで争うものがあります。 このほかに、開発したソフトウエア開発の品質の問題、あるいは成果物の著作権の帰属、第三者の知的財産権を侵害しているかどうか、といったことがよく争点になりま
イメージに訴えて、要件定義を効率化すべし
システム開発の最初にして最大の難関である要件定義。ここをいかに効率的に乗り越えるかによって、その後の開発スケジュールも、顧客の信頼度も大きく変わってくる。 要件定義とは、そもそも時間が掛かるもの 前回、『超短期開発を支える7つのエッセンス』として、家造りの文化について解説しました。今回からエクスプレス開発を支える具体的なノウハウを紹介していきたいと思います。 まずは“7つのエッセンス”のうちの「提案と選択」からです。顧客の要件を定義してシステムを設計するのは、システム開発において最も重要な作業です。ここでボタンを掛け違えてしまうと、後でシステムを修正するのは困難なこともあり、システムエンジニアの間では「要件定義には時間がかかっても仕方がない」といった風潮があります。 もちろんシステムエンジニアの立場からいえば、顧客企業側で迅速に要件を明確化してくれるに越したことはありません。しかし、顧客企
顧客の「真の要求」が分かる技術者を目指せ － ＠IT自分戦略研究所
ソフトウェアを創造するエンジニア。しかし、その仕事は本当に「創造的」だろうか。仕事を創造的なものに変え、価値を生むための発想法を紹介する。 毎日忙しく仕事に追われていると、アイデア出しが重要なことを忘れてしまう。しかし、ある1つの商談をめぐって競合が発生すれば事態は一変し、顧客を勝ち取るために競合他社に勝つ「提案」が必要になる。あるいは、昨今の景気後退のように、市場の急激な変化によって自社の製品やサービスの売れ行きが下降気味になれば、新たな情勢に適した「新しい製品やサービス」を生み出すことが必要だ。アイデアが必要になるのは、このような局面であることが多い。顧客に「なるほど」といわせるだけの説得力のある提案や、「これはすごい」といった感動を起こさせる何かを生み出さなければならない。 もちろん、製品やサービスによっては、市場が成熟し、価格だけで勝負しなければならないというものもある（図1は、製
TRIZ ― ＠IT情報マネジメント用語事典
旧ソ連で生まれた問題解決技法。問題（矛盾）を創造的・発明的に解決するための弁証法的な思考法と具体的な方法論??すなわち、膨大かつ綿密な思考・創造支援のための技法とツール、およびシステマチックな問題解決プロセスを提供する、壮大な技術思想体系である。 TRIZは、技術進化・創造的発明というものを「理想性の向上」と見なし、問題をシステム（技術システム）としてとらえて、その要素間の矛盾（弁証法的矛盾）をトレードオフや最適化のようにほどほどの均衡点を探るのではなく、完全に克服することを目指す。 TRIZという表記は、日本語で「発明的問題解決の理論」を意味するロシア語（キリル文字）のТРИЗ（теория решения изобретательских задач）の頭文字をローマ字にしたもの。この表記で世界的に通用するが、英語ではまれにTIPS（theory of inventive proble
L'eclat des jours(2008-11-12)
_ なぜなぜ仕様 要件定義−基本設計−詳細設計（または直接実装）というような、段階別のシステム設計を考える。 たとえば、数10年前にこんな要件があったとする。 ・プリペイドカードの導入効果を知りたいのでプリペイドカードでの売上合計を簡単に知りたいね というわけで、プリペイドカードを利用した売上を調べられるようにしたとしよう。 それから幾星霜、システムの更改時期がやって来る。 基本は単純移行＋最新鋭のいろいろ と決まる。 その時に、現行のプログラムを眺めながら、当時の基本設計も参照しながら、移行プランを練ったり、移行プログラムの仕様を切ったり実装したりすることになる。 そこで誰かが気づく。この「プリペイドカード売上レポート」とか「プリペイド売上計上サブシステム」ってなんだ？ 「はて？」 そこで相談することになる。「これ、使ってるのか？」 こういうとき、お客さんと相談するのはあまりうまくない。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
oɹǝznɹɐɥ@tumblr
Business Analyst/Business Analysis Community & Resources | Modern Analyst