上流工程の問題解決 要求定義編【後編】
ユーザー要求を引き出すには，開発者中心からユーザー中心にシフトする必要がある。ユーザー要求を引き出すには，ユーザーがシステムを最もイメージできる操作マニュアルを使い，実際のユーザーに会えない場合は，仮のユーザーを設定するのが有効だ。 Part2 「UCD」でユーザー中心の視点に切り替える ユーザー要求を引き出すには，開発者中心からユーザー中心にシフトする必要がある。ユーザー要求を引き出すには，ユーザーがシステムを最もイメージできる操作マニュアルを使い，実際のユーザーに会えない場合は，仮のユーザーを設定するのが有効だ。 ユーザー視点で要求定義を考え，ユーザーの使い勝手を最優先して要求定義を進めているのがスターロジックだ。「使い勝手だけでなく，開発の進め方やドキュメント，会話で使う用語に至るまで，自分がユーザーならどう受け取るだろうか，と開発者がとことん考えることが必要」（羽生氏）。 同社は，
上流工程の問題解決 要求定義編【前編】：ITpro
要求定義の手法を見直す動きが活発になってきた。これまでの開発者視点の手法では，社外ユーザー向けのシステムなどが開発しづらくなってきたからだ。旧来の手法で無理に進めれば，使われないシステムや赤字プロジェクトが増すばかり。要求工学，ユーザー中心設計，超上流など，システマティックな手法を取り入れ，いち早く要求定義の問題解決に挑んだ現場から，実践のノウハウを探った。 「システムの利用目的や対象ユーザーが大きく変わった。要求定義の認識を改める必要がある」──。30年間にわたり，情報システム部門，ユーザー，ベンダーと立場を変えながら金融システム開発の現場に携わってきたアイネスの菊島靖弘氏（金融システム本部 副本部長）は，こう警鐘を鳴らす。 帳票作成などの定型業務をシステム化していた時代，システムの利用ユーザーは発注者そのものであり，きちんと要求を語ることができた。ところが「Webシステム全盛の今は，社
要求開発とコタツモデル(2)－－アンチパターンを活用する
前回は，要求開発・要件定義フェーズを成功させるためのポイント「コタツモデル」についての説明を行いました。「コタツモデル」とは，ITシステム開発プロジェクトにおける，主要な三つのステークホルダーの関係性を表すメタファーです。 ビジネス戦略を決定するビジネス・オーナー（経営者や高位の責任者），実際のビジネスを遂行しているユーザー（現場担当者），そしてシステム開発担当者の三者によってシステムの目標を決定する＝一つのコタツに入って議論する状況を，要求開発アライアンスでは「コタツモデル」と呼んでいるものです。 今回は，具体的な「コタツモデル」形成のテクニックの一部についてご紹介したいと思います。 「コタツモデル」形成に王道なし，アンチパターンの活用 「（要求開発・要件定義などの）上流工程は異種格闘技戦である」──これは筆者の持論です。ITシステム開発の下流工程，すなわち設計・プログラミング・テスト・
「要求分析ツリー」を使って要求の構造をとらえる
システム構築プロジェクトの開始段階では，課題や要求を獲得する手段として，インタビューやヒアリングを使用するケースが多くあります。 企業活動のシステム化に際しては，オーナーである経営層から，実際にシステム操作をする現場の担当者まで，多くのステークホルダーが存在します。経営層と現場担当者では，当然のことながら視点や価値観が異なるので，同じ質問をしても聞く相手によって様々な回答が返ってきます。 例えば，現状の課題や新システムへの要望を質問した場合，経営者からは，「売上増加（3年後に年商120億にする）」とか「パート比率を上げることにより，人件費を削減したい」など，財務的な視点からの抽象度の高い要求が多くあげられます。一方，現場担当者からは，「在庫管理画面で他店の在庫を表示して欲しい」とか｢××システムのレスポンスが遅いので速くしたい｣など，自分の担当する業務に直結した具体的な機能要求があげられま
要求開発アライアンス openthology
マーケティング アフィリエイトとは何ですか？ アフィリエイトは、企業が第三者の出版社に報酬を支払い、その企業の製品やサービスへのトラフィックやリードを生成する広告モデルである。第三者であるパブリッシャーはアフィリエイターであり、報酬を得ることで、企業を宣伝する方法を見つけるインセンティブが得られます。 アフィリエイト・マーケティングの理解 インターネットの普及により、アフィリエイトマーケティングの存在感は増している。アマゾン（AMZN）は、ウェブサイトやブロガーがレビューや話題の商品のアマゾンページへのリンクを貼り、購入があった場合に広告料を受け取るというアフィリエイトマーケティングプログラムを作り、普及させた。このように、アフィリエイトは、販売行為を広大なネットワークに委託して行う成果報酬型のマーケティングプログラムである。 アフィリエイトはインターネットが普及する以前から行われていたが
第1回 システム要求の探究（その１）＝要求とは何か？
匠Style研究所・所長の萩本順三です。本研究所ではこれから、みなさんとともに“創発号”に乗って、ビジネスとITの摩訶不思議な世界を旅してみようと思います。みなさんはこれから、新しい発見をいくつもすることになるでしょう。もちろん私も、未知の領域に入り込むわけだから、ワクワクドキドキしています。 ただし、創発号の旅を楽しむには、いくつかのルールがあります。みなさんは、ユーザー企業の業務部門や情報システム部門、あるいはシステム開発会社の方々でしょう。それぞれの業務の中で経験してきた知識を最大限に生かし考えてもらわないと、旅はつまらないものになります。 大事なルールとして、まずは常識的と思っている事を疑うことをしてほしいのです。創発号に乗って外界を眺めている間に、きっと常識を覆すような事象を発見することになるでしょう。その時こそ常識を疑ってみると、そこにシンプルで美しい風景（解）が見えてくるので
要求定義の基本を知る
要求定義とは，ユーザーがシステムに望む機能や性能（＝要求）を洗い出し，整理する作業。設計/開発の前にこれをしっかり実施しているかどうかでプロジェクトの成否が分かれる大事な工程だが，意外になおざりにされている。実績に裏付けられたノウハウや方法論を学ぼう。 Part1 成功に導く必須スキル Part2 要求定義の方法論を知る Part3 オブジェクト指向に基づく方法論 Part4 ヒアリングの実践ノウハウ一挙公開 Part5 注目集める「要求工学」
「何のために」を業務部門と常に共有せよ
最善を尽くしたにもかかわらず、やっと稼働したシステムに対し業務部門は不満を抱くばかり――。こうした状況を引き起こす原因を“あいまいな要求定義”に求めて久しい。だが、要求定義のためのテクニックを身に付けただけでは、状況は一変しない。「何のためにシステムを作るのか」といった根本的なゴールを不明確なままに要求定義を急ぐからだ。業務部門とIT部門が一体になり、ゴールを明確にし、かつ共有するための体制作りがますます重要になってきた。 中堅損保会社の日新火災海上保険は2006年11月、契約内容を顧客に説明するための資料を作成する「ご契約内容確認マップ」システムを稼働させた。保険商品の内容が複雑になるなかで、契約時の顧客への説明責任をどう果たすかという経営課題を解決するための期待のシステムだ。 釜中貞彦 情報システム部長は新システムを、「稼働直後から営業部門の満足度は高い。納期も予算も予定通りで、情報シ
Part1 成功に導く必須スキル
方法論はそれなりに整備されているものの不完全。ユーザー企業は要求を決めず，またコロコロ変える――このような状況から脱却するにはどうすればいいのか。結論を言えば，「銀の弾」は存在しない。やるべきことを地道に実践するのがベストだ。 要求定義に絡む問題は根が深い。ユーザーからあいまいな要求しか出てこなかったり，要求があとからコロコロ変わったりするケースが少なくない。しかも，よりどころとなるべき方法論は不完全。それどころか，標準的な方法論がない企業や組織もある。こんな状況に直面すれば，「要求定義をうまくやるなんて無理」と諦めてしまうかもしれない。しかも最近は，要求定義の難しさがますます増している（図1）。 だからといって手をこまぬいているだけでは，システム開発プロジェクトで品質，納期，コストを遵守することは難しい。プロジェクトを成功に導くためには，最上流である要求定義こそが最も重要だからだ。 4つ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
上流工程-要件定義---目次：ITpro