要件定義を得意ワザにしよう
「システム開発で、何が一番難しい？」と尋ねられたら、「要件定義」と答える人が多いのではないか。ユーザーが何を望んでいるのか的確につかみ、ときとして関係者間で対立する要望を整理し、システムの要件にまとめて関係者の合意を得なければならない。技術者からは「いろいろ神経使うし、大変だよね…」という声が聞こえてきそう。 要件定義のスキルを磨くには「知識＋実践」が不可欠だ。ここでは要件定義に関する好評連載・特集をピックアップした。これらの手法やノウハウを使って、より良い要件定義ができるよう、実践に役立てていただければ幸いである。 認識のズレや要件の抜けを防ぐ「詰めの質問術」 システムの出来が見違える コツ1●言葉の定義を聞く コツ2●言い換えて聞く コツ3●タイミングを聞く コツ4●なぜ必要なのかを聞く コツ5●そうではないケースを聞く コツ6●順番が逆のケースを聞く コツ7●状態の変化に注目して聞く
「情報システム部はもっとやれる」と訴えたい
「情報システム部という組織はもっともっと会社や社会に貢献できる。部長を9年間務めて得た結論です。ところが世間を見渡してみると残念ながら、情報システム部の地位というものはなかなか上がらない。そうじゃないぞ、と何とかして訴えたい。情報システム部から離れる今、そう思っています」。 ある製薬メーカーの情報システム部長はこう語った。この発言をした時、彼は9年間在籍した情報システム部を離れ、別な部の責任者になる内示を受けていた。彼はもともと、研究開発、営業、経営企画といった各部門を経て、情報システム部を担当した。部長として着任するまで、情報システムの仕事に関わったことは無かった。 情報システム部長を命じた社長は、「ITにガバナンスがかかっていない。予算や実績が外からはっきり分かるように透明化してほしい」とこの部長に指示したという。 情報システム部がブラックボックスになっていることが気になった経営者が、
ソフトウェアの品質を上げるにはどうするべき？ | スラド デベロッパー
ストーリー by hylom 2010年11月10日 14時47分 バグが何件出るかなんて予測できるの？ 部門より ITproにて、「品質管理のやり方として正しいのはどれ？ - 今日の腕試し！」なるクイズが掲載されている。品質を上げるの必要なのはバグ出しだけではないが、設問をつくるために敢えてバグ出しをターゲットにしたのだろう。それはいいのだが、個人的にみてこの3択には正解の要素が見受けられない。特に、正解をみてしまうと「今時、こんな方法をとっているベンダーとは疎遠になりたい……」と思ってしまう。 ちなみに、バグ出し（と、そのためのプログラム作り）には開発期間の半分はとるべきだと私は考えているが、そううまくいかないのも現実である。理想と現実に挟まれるSEやプログラマが多いであろうが、諸兄はどこを落とし所にしているのだろうか？ ちなみに、私の現職は中小企業のシステム管理である。前職はプログラ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
