（第2回）ダメ発注その1、要件定義もできない“低クオリティ”
ユーザー企業には「発注責任」がある。しかし実際には、この当たり前のことをわかっていないユーザー企業は数多い。その結果、システム開発プロジェクトが頓挫し、ユーザー企業とITベンダーの双方が大きな打撃を受けるケースが頻発している。この特集では、ユーザー企業がシステム開発をITベンダーに発注する際に陥りがちな問題点を、発注のQCD（品質、料金、期日）の観点から分析する。 今回は“Q”、つまり発注の品質にフォーカスして問題点をあぶり出す。なお、この特集は日経コンピュータの2008年6月15日号に掲載した記事をベースに、内容を一部修正して著者の現時点での認識などを加えたものだ。オリジナルは4年半前の記事だが、ITベンダーの事業部長、営業部長クラスの人に匿名を条件に語ってもらった“事実”は、今でも全く古さを感じさせない。 一括契約はここが恐ろしい 発注の品質、つまり要件定義の問題は、ほぼすべてのITベ
要求工学の実践ノウハウを集大成した要件定義手法Tri-shapingの実践
昨今の企業におけるICT システムの位置づけは，効率化のための道具から，戦略的な武器へと変わってきている．これに伴い，要件定義の難易度が増している．経営や業務に対する価値を考えながら，業務自体を改革／改善でき，システム活用を具現化できる人材が求められている．この人材を本稿ではビジネスアナリストと呼ぶ．ビジネスアナリストとして何をすべきか，何を知っているべきかについて，これまであやふやだったが，REBOK やBABOK の登場によって体系化された．REBOK やBABOK は名前に「BOK」とあるように知識の体系であり「何を」すべきかをまとめたものである．これらを実践で活かすには「どのように」アナリシスするかというHow-to を可視化することも重要である．富士通は2011 年にTri-shaping（トライシェイピング）を発表した．これは弊社が今まで培ってきた実践ノウハウや考え方を集大成し
利用部門の改善要望はうのみにするな
「すべての改善要望を実現するには、人もコストも時間も全く足りない」「利用部門に申し訳ないと思いながら、何年も棚上げにしている改善要望がたくさんある」──。 最近、システムの稼働後に綿々と行う保守開発について取材したとき、現場のエンジニアからこんな声を聞いた。保守開発では、利用部門から日々届く大量のシステム改善要望にどう対処するかが大きな問題になっている。 人もコストも時間も足りず、一部の改善要望しか実現できない。そのため、実現しない改善要望について、どうやって利用部門の納得を得るかが課題になっているという。そこで、受け付けた要望を一覧化し優先順位を付ける、という取り組みが一般に行われている。客観的に優先順位付けを行うため、重要度、緊急度、工数などいくつかの指標を設けて、改善要望ごとに点数を算出する現場もある。 この優先順位付けの方法について、日経SYSTEMS主宰の「要件定義統一方法論検討
要件定義がすんなり進むわけがない
「要件定義が何の問題もなく進むわけがないじゃないですか」――。日経SYSTEMS 11月号の特集「難航した要件定義 苦境からの脱出法」の取材を進めているときのことだ。要件定義を担当する、あるエンジニアから聞いたこの一言は、昨今の事情をよく表していると思った。 誤解のないように補足しておくと、冒頭のエンジニアのスキルが低いというわけではない。「ベテランのエンジニアでも要件定義で難航することが少なくない。それだけ要件定義が難しくなってきた」といった意見は多くの要件定義担当エンジニアから聞くことができた。 ちなみに、ここで言う要件定義とは、現状の業務とシステムの分析、新しい業務フローを定義する業務要件定義、それに基いて概要レベルのシステム要件をまとめるシステム要件定義などを含む。 要件定義が難航する三つの理由 要件定義が一筋縄ではいかないのは以前から指摘されてきたことだが、それでもなお多くの要件
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
