タグ

仕様に関するre_troのブックマーク (5)

  • ヒアリングの極意を学ぶ

    現行の業務やシステムには、どんな問題があるのか。どう変えたらいいと思うのか―。プロジェクトに関係する利用部門の担当者から、そうした意見を聞く作業は、要件を決める上で非常に大切である。トップダウンのアプローチだけでは偏りがあるからだ。ボトムアップのアプローチとして、利用部門の現場の意見を聞き、新しい業務やシステムの要件を考える材料を得る必要がある。 ヒアリングで特に難しいのは「(利用部門の担当者に)参画意識を持ってもらう」「整理しながら聞く」「些末な問題・要望を取り除く」「音を聞き出す」といったことだ。これらの極意を取り上げてみよう。 ヒアリングの極意、四つのポイント 参画意識を持ってもらう 整理しながら聞く 些末な問題・要望を取り除く 音を聞き出す 超上流の失敗パターン いつまで経っても業務要件がまとまらない 数カ月かけた業務フロー作成が水の泡に

    ヒアリングの極意を学ぶ
  • RFP/要件定義/要求仕様---違いは明確?

    「RFP(提案依頼書)」「要件定義書」「要求仕様書」──。この三つの言葉を見て、その違いを明確に説明できるだろうか。筆者は、日経SYSTEMSという雑誌を担当して日々システム開発現場における開発手法や実務情報を記事としてまとめているが、この三つの用語には、定義に曖昧な部分があったり、違いが分かりにくい面があったりすると感じている。 三つの用語が示すドキュメントはいずれも、ユーザーがどんなシステムを開発したいのかを記述したものだ。実は、筆者がこれまで普通に使っていた用語は、三つのうちRFPと要件定義書の二つ。これらについては、それなりに違いを理解しているつもりである。対して、要求仕様書という用語はあまり使っていなかった。 ざっくりいえば、RFPはシステム開発を発注するベンダーを選定するために、どんなシステムを作りたいかを提示して、最適な提案をベンダーから引き出すためのもの。一方の要件定義書は

    RFP/要件定義/要求仕様---違いは明確?
  • 要件決めの極意

    システム開発プロジェクトの要件定義フェーズでは、ITエンジニアは利用部門から問題や要望をヒアリングする。さらにそれを基に、真の問題とその解決策となる新しい業務やシステムについての仮説を立て、要件の「検討会議」に臨む。この検討会議では、各利用部門の代表者としてそれぞれのキーパーソン数人が何回かにわたって集まり、集中的に要件を決めていく。 ITエンジニアにとって、この検討会議における最大のテーマは、何といっても合意形成である。このときの合意形成がしっかりしていないと、後の工程で仕様変更の原因になりかねない。 ただし合意形成は容易ではない。例えば、利用部門のキーパーソンとはいえない人が選ばれて出席してくる。参加者の間で意見対立が生じたり、要件についての解釈が参加者によって異なったりする。結論が出ても、納得していない参加者がいる。検討会議の結果について、各利用部門の部門長の承認がなかなか得られない

    要件決めの極意
  • 首相官邸ホームページのリニューアル構築費用に対して製作者側からの考察

    首相官邸の公式ホームページが2012年4月2日、リニューアルされた。 これが「お金をかけすぎている」とインターネット上で批判の嵐となっている。増税や公務員削減などが実施されようとしている中、無駄使いではないかという声が多くあがっているのだ。 首相官邸HP、リニューアルに4500万円 ネットで怒りの声 「もっと安くできる」 – J-CASTニュース この記事ですが、ネット上での「高い」という声は一般消費者感覚としては理解出来ますが、Web業界で働く私の周囲のリアルな同業者からも、ネット上の一般の方と同じように「高い」「騙されてる」「金のムダ使い」というような意見が出まして、ちょっと違和感を覚えました。 また一方で、同業の方でも実際このクラスの規模の案件を受託しているような受託業者さん界隈からは「これくらいはかかる」「この金額以下だと受けられない」という声も聞かれました。 私は後者の声に同感で

    首相官邸ホームページのリニューアル構築費用に対して製作者側からの考察
  • 仕様変更に強い開発をするための、ヒアリングモデル

    仕様変更に強い開発をするための、ヒアリングモデル:仕事を楽しめ! エンジニアの不死身力(21)(1/2 ページ) 今回のテーマ:仕様変更が起きる理由、そしてそれを防ぐには ある程度の経験を積んだエンジニアなら誰しも、顧客から仕様変更を依頼されて困った経験があるかと思います。 仕様変更が起こると手戻りが発生し、開発工数の増大や予算の圧迫、納期遅れなどを引き起こします。さらに。「仕様だ/仕様ではない」「言った/言わない」といったコミュニケーションのトラブルは感情論になる場合が多く、顧客との信頼関係も悪化します。エンジニアは無理な仕様変更で士気を落とし、顧客は社内調整などでいら立ちを覚えます。 せっかく開発するなら、リソース的にも感情的にも気持ち良く仕事をしたいものです。そこで今回は、「なぜ仕様変更は起こるのか?」をテーマに、仕様変更が起きる原因を探り、それを防ぐヒアリング方法を紹介します。 ヒ

    仕様変更に強い開発をするための、ヒアリングモデル
  • 1