Part1 業務分析の知識体系、BABOKを理解する
20年以上にわたりシステム構築の現場で仕事をしてきた筆者の経験では、プロジェクトの失敗を探ると要件定義までの上流工程の問題に行き着くことが多い。定義した要求に過不足がある、要求の内容が誤解を生む表現になっている、整理が不十分なまま要求が個条書きされており整合が取れていない──。こうした事態が、みなさんの現場でも起こっていないだろうか。 利用部門などから要求を引き出して分析し、それを基にソリューションを立案してその妥当性を検証する。さらに、要求の変更を管理していく。ソリューション企画から要件定義までの上流工程を中心に、こうした要求にかかわる一連の作業をいかに行うかが、プロジェクト成功の大きなカギを握る。 しかし多くの現場には、要件定義までの上流工程について標準的な方法が存在せず、ITエンジニアの属人的スキルに頼っているのが実情だろう。スキルの高いITエンジニアが要件定義までの工程を担当するか
他システムとの連携に関する要求の取りまとめ方
新たにシステムを導入する上で，必ず検討しなければならないことの一つが，既存の他のシステムとの連携の必要性である。例えば現行の基幹システムが導入から長い年数が経過し，その陳腐化への対応のために再構築（リプレース）を行う場合，再構築の範囲に入っていない周辺のシステムに注目する必要がある。基幹システムなどの場合は，他の周辺システムにデータを渡したり，その逆にデータを受け取ったりしているケースが多い。そのようなデータの受け渡しが行われている場合は，新システムにおいても当然そのデータ連携機能が必須となってくる。 これまで述べてきた技術要求と違って，他のシステムとの連携というのはほとんどの場合，発注側企業の固有の事情となる。そのため，RFPの段階であってもなるべく正確に要求を伝える必要がある。特に連携するシステムが複数ある場合などは，漏れがあったり，混同したりなどのミスがあるとベンダーの見積もりが大き
第4回 プロセスを可視化し、業務とアプリを接続する
アビームコンサルティング フェロー 徳田 弘昭 前回は、ビジネス全体の統制を効率よく、かつ経済的に実施できるようにするための「ビジネスシステムの断絶を防ぐ6つの仕組み」を説明しました。6つの仕組みは以下の通りです。 （A）業務プロセス全体の可視化 （B）業務プロセスとアプリケーションの接続 （C）正確な稼働記録の獲得 （D）関連情報のDB化 （E）関連情報の自動獲得 （F）関連のトレースと表示 今回から具体的な説明に入ります。今回は（A）業務プロセス全体の可視化、および（B）業務とアプリケーションの接続を取り上げます。 （A）業務プロセス全体の可視化 1つ目は、企業全体の業務プロセスやルールを文書に記述し、その文書やルールを適切に維持・保守する仕組みです。既存のアプリケーション群を全社の業務プロセスに当てはめてみると、図1のように表現できます。 図1の中心を成すのは、「（全社）業務プロセス
ユースケース、それともユーザストーリー？
Murali Krishnaはこう言う(リンク)。 アジャイル開発へ効果的に移行できないという失敗は、ユーザストーリーが何たるかを理解できていないという根本的な失敗に根ざしていることが多い。 ユーザストーリーの最も重要な側面は、ユーザストーリーが要件（機能）の「スケジュール可能な」ユニットであり、スケジュールは他に依存していないということです。ユーザストーリーの「他に依存せずスケジュール可能な」特徴を実現する鍵となるのが、「ユーザ」がどう使うかという目線に立ってユーザストーリーを表現することです。そうすればユーザが実際にインタラクトできるエンドツーエンド（UIからバックエンド）に実装された機能性のユニットが手に入ります。 Krishnaはアジャイルコミュニティで多数の人々が信じている「ユーザストーリーは唯一、最良のよりどころ」を正確に描写し、Mike Cohnによる「Advantages
要求分析に表れるソフトウェア技術者の心
要求分析に表れるソフトウェア技術者の心：上を目指すエンジニアのための要求エンジニアリング入門（3）（1/3 ページ） 上級技術者を目指すのであれば、要求エンジニアリングの習得は必須である。要求を明確化できれば、後工程の不具合が減少し、プロジェクトコストの削減や競争力強化につながるからだ。6回に渡って、要求エンジニアリングの基礎を解説する。 在庫調整が進んだので生産増、景気回復が望めるとの一部報道がある。しかし、経済環境は相変わらず厳しい。 とはいえ、ソフトウェア開発を糧にして生きるには、ソフトウェアの開発需要が必要である。需要の提供者、中でも業務システムを必要とするユーザー企業、およびソフトウェア製品やソフトウェアを組み込んだシステム機器ベンダの多くは急激な収益悪化に直面し、コスト削減を迫られている。こんな時期には、収益向上あるいはコスト削減に効き目があると期待できるソフトウェアやシステム
株式会社マジカジャパンの羽生章洋が書いてるブログ:営業と要件定義 - livedoor Blog（ブログ）
そういう不可欠の職種である営業ですが、良い印象を与えないことがある理由は何かというと、無理矢理押し込むという風に思われているからではないかと感じます。要するに押し売りなのではないかと。あるいはyes but法などに代表されるような、ああいえばこういう的に言葉巧みに相手を追い込んでいくというような、駆け引きで買わせるという風に思われていることもあるかもしれません。 しかし私どものような業務システムの受託開発のように、既に存在する商品を売るのではない、所謂ソリューション営業あるいはコンサルティング営業の場合には、この押し込み型の営業というのは、実はなかなかに厳しいものがあります。 SI業界でも押し込み型の営業スタイルで成功体験を築き上げてきた方々はいます。ただその場合は、よくよく見るとシステムというよりもやはりハードウェアありきだったと見受けられることが多いのです。 受託開発の営業というのは、
機能要件設計書だけで20種類
意図が伝わる設計書を作るには，前提として「それぞれの設計書がどういう役割を担うか」「それぞれの設計書が相互にどういう関係にあるか」を正しく理解しておくことが重要である。豊富なサンプルとともに，設計書の役割と関係，さらには書き方のコツを解説する。 石川貞裕 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部 担当本部長 向坂太郎 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部 「基本設計書」と聞いて，どんなものをイメージするだろうか。業務フロー図や画面レイアウト，E-R図など様々だろう。大規模，高品質のシステムを開発するなら，図1に示すような多くの設計書を作成することになる。 中心となる機能要件設計だけでも20種類。それぞれの役割や関係をきちんと理解し，過不足なく設計情報を盛り込むことが求められる。 難しいのは，設計書の読み手が開発者だけではないことだ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。