要件定義で必須の思考法、どうしたら身に付くか
システム開発プロジェクトでユーザーから要望を聞くとき、その目的を確認したうえで、それを実現するためのより良い解決策を考える。要件定義を担当するSEは、この思考法を習慣化すべきだ――。 2015年4月20日の本欄「ユーザーに遠慮するSEはバカになる」で、このことを指摘した。 上記の記事ではあえて上から目線で書いたが、ユーザーからの要望の目的を確認し、より良い解決策を考えるのは容易でない。このことを、記者は経験的に知っている。かつてシステムインテグレータの社内研修に参加させてもらい、要求分析の基礎トレーニングを受けた際、懇意にしていた講師から「（要件定義の記事を書いているので）もうちょっとできると思っていましたが…」と渋面を作られた経験がある。 要件定義の思考法は、手順を理解したつもりでも、実際にやると難しい。しかも、緻密な思考が求められ、かなり面倒だ。これをただちに習慣化せよというのは、いさ
[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG
「超上流」という言葉自体はとても気に入らないけれども、IPA 独立行政法人 情報処理推進機構 が作って公開している「超上流から攻める IT 化の原理原則17ヶ条」が、当たり前のことを当たり前に並べてあってとても役に立つ。 原理原則 17箇条 ユーザとベンダの想いは相反する 取り決めは合意と承認によって成り立つ プロジェクトの成否を左右する要件確定の先送りは厳禁である ステークホルダ間の合意を得ないまま、次工程に入らない 多段階の見積りは双方のリスクを低減する システム化実現の費用はソフトウェア開発だけではない ライフサイクルコストを重視する システム化方針・狙いの周知徹底が成功の鍵となる 要件定義は発注者の責任である 要件定義書はバイブルであり、事あらばここへ立ち返るもの 優れた要件定義書とはシステム開発を精緻にあらわしたもの 表現されない要件はシステムとして実現されない 数値化されない要
![[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG](https://cdn-ak-scissors.b.st-hatena.com/image/square/bfb41ba2bfefb166491d5d3e83380136f2017ab2/height=288;version=1;width=512/http%3A%2F%2Foshiire.to%2Fwp-content%2Fuploads%2F2015%2F01%2F17principles-300x212.png)
いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道
最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 （なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多
要件は現場に聞かない
企業を取り巻く変化に柔軟に対応する基幹系を構築するためには、要件定義の段階から従来とは異なるアプローチが必要である。それは「利用部門の声を基に要件定義をしない」ことだ。 経営統合やM&A、事業の大幅な転換などを予測するのは簡単ではない。かといって、今までのように利用部門の意見だけを聞いて要件定義をしていては、現状の業務効率化を優先するばかりで、変化に対応しづらい従来型の基幹系になってしまう。 柔軟な基幹系の構築に必要なのは、企業の進む方向性や提供すべきサービスなど、将来の基幹系に必要な要件をできるだけ盛り込むことだ。経営者や企画部門、取引先、顧客など様々な声を取り入れることで可能になる（図1）。特に、社外との接点がある基幹系では、顧客ニーズや市場動向を要件に取り入れることが必須である。 実際、物流大手の山九や、「LOWRYS FARM」「GLOBAL WORK」などカジュアル衣料を手がける
使えないシステムをなくすBABOKとは？
使えないシステムをなくすBABOKとは？：BABOK 2.0を読んでみよう（1）（1/3 ページ） 2009年3月末に「Business Analysis Body Of Knowledge（BABOK）」のバージョン2.0が、International Institute of Business Analysis（IIBA）からリリースされました。 本連載では、BABOKバージョン2.0の概要を紹介しながら、いま注目を集めている超上流のアプローチ、ビジネスアナリシスがどのようなものであるかを見ていきます。 “使えないシステム”を作っていませんか？ せっかく高いお金を払って開発したシステムが、とても使いづらかったり現場の業務にマッチしなかったりで、“現場で使ってもらえない”というケースがよくあります。 これではユーザーにとっては無駄な投資となり、もちろん大変な損失になります。システム開発し
RFP/要件定義/要求仕様---違いは明確？
「RFP（提案依頼書）」「要件定義書」「要求仕様書」──。この三つの言葉を見て、その違いを明確に説明できるだろうか。筆者は、日経SYSTEMSという雑誌を担当して日々システム開発現場における開発手法や実務情報を記事としてまとめているが、この三つの用語には、定義に曖昧な部分があったり、違いが分かりにくい面があったりすると感じている。 三つの用語が示すドキュメントはいずれも、ユーザーがどんなシステムを開発したいのかを記述したものだ。実は、筆者がこれまで普通に使っていた用語は、三つのうちRFPと要件定義書の二つ。これらについては、それなりに違いを理解しているつもりである。対して、要求仕様書という用語はあまり使っていなかった。 ざっくりいえば、RFPはシステム開発を発注するベンダーを選定するために、どんなシステムを作りたいかを提示して、最適な提案をベンダーから引き出すためのもの。一方の要件定義書は
もう許されない要求の不備
業務ロジックや画面といった機能要求が明確だからと安心してはいけない。性能や運用性といった非機能要求を明らかにできなければ“道半ば” である。その不備は7割に上る。意識を高め，スキルを磨くことが急務だ。 「この応答速度では遅い」「バッチではなくオンラインでないと業務に支障を来たす」──。金属チタン製造大手の東邦チタニウムは2008年5月，生産管理システムを稼働させた。ところが2年1カ月を要した開発プロジェクトでは，冒頭のような要求仕様の変更が相次いだ。そのため当初洗い出した要求を見直し，一度作ったプログラムの改修を余儀なくされた。 変更になったのは，例えばこんな要求である（図1）。当初，268の機能について，応答時間を「一律3秒以内，長くても5秒」としていた。しかしユーザー・テストの段階で，参照系の機能は5秒では遅いことが判明した。更新系機能の場合は，その画面のボタンをクリックすると一連の業
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
そもそも要件定義って何なのよ