システム開発(請負)での納品物(ドキュメント)とは、
A:作業工程内で作成されるものをいうのか、
B:別途金額が発生する制作物なのか、
どのように考えるのが普通なのか、教えてください。

(経緯)
Webサイトのシステム開発のリニューアルを行うことになり、
以前開発を依頼した会社に見積りをあげてもらいました。
※私が会社に就職する前に依頼経験がある会社で、私自身は初の対応の会社です。

PG単価4万円、作業工数:64人日(2人月)、260万の見積りで、
納品物としてはソースコード一式のみ。
それ以外の設計書や定義書などドキュメントは一切なし。

ソースコードのみでは、自社での検収作業が大変なので、
「検収作業を自社で行うためにもせめて設計書をつけて欲しい」と話をしたら、
新しい見積りで、設計の工数が倍になって、320万となっていました。
設計書だけで、40万も違うものかと驚きました。

こちらとしては最初の見積りで「設計」「製造」「テスト」の工程が提示されていたため、
その際に作るであろう設計書をもらえればと考えていましたが、
プロトタイピング開発であるため、設計書に関してはリリース後に
最終的なシステムをもとに書き起こして提出するという流れになるといわれました。
検収で必要としていると伝えたにも関わらず、リリース後に渡すというのも、
よくわからない説明で困りました…。

通常、設計書などは途中工程で作成されるだろうと考えていましたが、
そうではないのでしょうか。
価格を吊り上げるためのやり方に思えて仕方ありません。

これについて、ご意見お願いします。

このQ&Aに関連する最新のQ&A

A 回答 (2件)

元開発系のSEです。


ドキュメントは基本的には別だと考えます。
作る側の論理から言えば、設計書などは内部で作成するものはあっても、納品物として収めるのであれば、書きなおし(工数)が発生するからです。

ただ、おっしゃるようにプログラムを作るには設計書は作成するでしょうし、テストを行うにはテスト一覧やテスト結果の一覧などドキュメントは必ず作成されるので、それを流用して費用を抑えるように言ってみるのがよいかもしれませんね。
    • good
    • 0
この回答へのお礼

アドバイスありがとうございます。お礼が遅れて申し訳ありません。

>ただ、おっしゃるようにプログラムを作るには設計書は作成するでしょうし、
>テストを行うにはテスト一覧やテスト結果の一覧などドキュメントは必ず作成
>されるので、それを流用して費用を抑えるように言ってみるのがよいかもしれませんね。

上記の形で相談してみました。
多少の金額は請求されましたが、個の方法でかなり費用を抑えることができました。
適切なアドバイスありがとうございました。

お礼日時:2011/04/28 10:31

システム開発(請負)での納品物(ドキュメント)とは、


「契約時に納品対象と決めたドキュメント」だと思います。

なので、見積もり時に「ソースコードのみ」となっていれば
ソースコードのみになるのではないでしょうか


ちなみにシステム開発時に設計書を必ず書くとは限りません。
開発費を抑える為、設計書ではなく設計メモレベルに抑えることも
しばしばあります。


「設計書」の作成で見積もりが40万も違うということですが
設計はSEが行う為、PG単価ではなくSE単価(PG単価4万ならSE単価は5~6万)で
計算すると思いますので、40万(計算すると60万)であれば妥当だと思います。



もし投稿者様側の検証で使用するだけであれば
依頼先側が「設計」「テスト」の工程を行うに際し
 なにを元(議事録、メモ書きなど)に設計し
 なにを元にテストしOKとしたかを明確にしてもらい
 その資料の提示をお願いしてみたらどうでしょうか

ただし検収作業での試験項目は、検収作業側が依頼した仕様をもとに
試験項目を作成すべきだと思いますよ。
もしかしたら相手が仕様を間違っていることもありますので




全項目に回答できたかな・・・
    • good
    • 0
この回答へのお礼

アドバイスありがとうございます。お礼が遅れて申し訳ありません。

>ちなみにシステム開発時に設計書を必ず書くとは限りません。
>開発費を抑える為、設計書ではなく設計メモレベルに抑えることも
>しばしばあります。

おっしゃる通り、これまでは製作費を抑えるためにあえて設計書等のドキュメントを
作成せずにいたようです。ただあまりにドキュメントがなさすぎて…。

ひとまず、テスト時の試験内容を頂くことで落ち着きました。
設計書関係はあとで自分でコツコツ作っていくことにしようかと思います。

アドバイスありがとうございました。

お礼日時:2011/04/28 10:36

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人はこんなQ&Aも見ています

このQ&Aを見た人が検索しているワード

このQ&Aと関連する良く見られている質問

Q英語の請求書の雛形がほしい

海外向けの請求書や納品書をはじめてつくるのですが、英語の請求書の雛形でいいものありませんでしょうか。

Aベストアンサー

https://www.miraiz.bz/Template/Index/
のなかの(経理書類)請求書(英語) というやつはどうでしょうか?

Qシステム仕様書の必要性について<システム開発>

Web系のシステム開発の仕事をしている者です。

作成したシステムの仕様書を必ず作るべきか?必ずしも作る必要はないか?
という議論をしており、その中で意見が分かれて困っております。

ここで問題としている仕様書とは、社内のシステムメンバー内で情報共有するため、
自分が作成したシステムの構成や機能説明などを簡単にまとめたものになります。

システムの構成や仕様は、社内で特に統一されているわけではありませんので、
作成した担当者によっては作り方が異なり、説明なしでは解析するのに
余計に時間がかかる場合があります。
このため、各自で作成したシステムの簡単な仕様書を作成しておき、
後で確認する際や引き継ぎの際に役立てはどうかという提案をしています。

しかし、一部の者は、仕様書作成のために多少でも時間を割くことどうかという意見や、
仕様書を作成することでどれだけの成果(売り上げ)になるのか?という意見もあり、
なかなか理解が得られません。

仕様書の必要性は作成するシステムの内容や規模にもよるかと思いますが、
円滑な情報共有と担当者が不在となった際のリスクヘッジの意味でも必要と私は考えてます。

社内に限定したシステム開発の現場において、
システム仕様書はあまり重要ではないのでしょうか??
私の独りよがりなのかどうか、よくわからなくなってきてます。

同じようなお仕事をされている方、同じような経験のある方がいれば、
ご意見、アドバイスなど頂けますと幸いです。

よろしくお願い致します。

Web系のシステム開発の仕事をしている者です。

作成したシステムの仕様書を必ず作るべきか?必ずしも作る必要はないか?
という議論をしており、その中で意見が分かれて困っております。

ここで問題としている仕様書とは、社内のシステムメンバー内で情報共有するため、
自分が作成したシステムの構成や機能説明などを簡単にまとめたものになります。

システムの構成や仕様は、社内で特に統一されているわけではありませんので、
作成した担当者によっては作り方が異なり、説明なしでは解析するのに
...続きを読む

Aベストアンサー

ドキュメントに要するマンパワーを無駄と思ってはいけない。
これをおろそかにする人は目先のことしか分かっていないのです。

仕様書は本来はシステム開発のための設計書であり、コーディングよりも前にできていなければならない。
そして、システム開発途上で変更が生じた場合も、その仕様書に手入れを施して、常に最新の状況に維持することです。

これによって、そのシステムは組織で維持できることになるのです。

Qビジネス文書の名前を英語に変更したいです。

突然ですが質問させて頂きます。


私はビジネス文書を日本語から英語へ変更しようとしています。

まず、以下6種類のビジネス文書の名前自体を英語に変更したいです。

私なりに英語に変更してみたのですが正解でしょうか?


1)見積書 → Quotation

2)発注書 → Purchase Order, Order sheet / form

3) 納品書 → Statement of Delivery

4)受領書 → Acknowledgement

5) 請求書 → Invoice, Bill

6)領収書 → Receipt


いろいろと参照してみると、納品書と請求書は両方ともInvoice、

受領書と領収書は両方ともReceiptという結果が多いのです。


混乱をさけるために全て別々の名前をつけたい場合、どの単語が最適でしょうか?

実際に多く使われている単語を知りたいので、是非アドバイスをください。

不明な部分や質問があれば補足致しますし、小さな情報でも結構ですので宜しくお願いします。

突然ですが質問させて頂きます。


私はビジネス文書を日本語から英語へ変更しようとしています。

まず、以下6種類のビジネス文書の名前自体を英語に変更したいです。

私なりに英語に変更してみたのですが正解でしょうか?


1)見積書 → Quotation

2)発注書 → Purchase Order, Order sheet / form

3) 納品書 → Statement of Delivery

4)受領書 → Acknowledgement

5) 請求書 → Invoice, Bill

6)領収書 → Receipt


いろいろと参照してみると、納品書と請求...続きを読む

Aベストアンサー

1)見積書 Quotation → OK

2)発注書 Purchase Order, Order sheet / form → OK

3)納品書 Statement of Delivery → 納品伝票の類と思いますが 普通の商品ではStatement of Delivery という言い方はしません。Delivery slip, Delivery noteぐらいです。Statement of Delivery とは土地建物とか大型機械の取引のように法律で決められていたりする時に使われる用語です。

4)受領書 Acknowledgement → 物品受領書のことと思いますが、それなら Goods Receipt (or Receipt of Goods)が適切です。acknowledgementではちょっと意味が広くなります。

5)請求書 Invoice, Bill → 消費税のある国(日本もそうですが)正式には Tax invoice とします。

6)領収書 Receipt → 4と差別化するため Payment Receipt (or Receipt of payment)が適当です。

1)見積書 Quotation → OK

2)発注書 Purchase Order, Order sheet / form → OK

3)納品書 Statement of Delivery → 納品伝票の類と思いますが 普通の商品ではStatement of Delivery という言い方はしません。Delivery slip, Delivery noteぐらいです。Statement of Delivery とは土地建物とか大型機械の取引のように法律で決められていたりする時に使われる用語です。

4)受領書 Acknowledgement → 物品受領書のことと思いますが、それなら Goods Receipt (or Receipt of Goods)が適切です。acknowl...続きを読む

Qシステム開発をしています、ちょっとした携帯アプリの開発をするために、ス

システム開発をしています、ちょっとした携帯アプリの開発をするために、スケジュールを組んでみなさいと上司から命令がきました。
1年生位の技術スキルでオープン系の開発経験はあるのですが、全く未経験の携帯アプリの開発のスケジュールを組んでみろと言われても全くわかりません。

スケジュールを立てるために参考になるサイトはありますでしょうか?
なお私の場合、スケジュールを組んだことは1度もなく全くの素人レベルになります。

お手数ではございますが、アドバイスをお願いできないでしょうか。

Aベストアンサー

システム開発能力は、徒弟制度で学ぶ世界なので、時間を
かければできるというものではないでしょう。天才的な
人は別として・・・

やったことのないことに、タイムテーブルが書けるわけがありま
せん。経験があってすら、スケジュールどおりに進まないのが
この世界です。

まずは調査が必要でしょう。
1. 開発に必要な道具、環境
2. 開発スキルを取得するための講習会などへの参加
  本当は、そういう現場に送ってもらうのが一番ですが、
  上記したように徒弟制度の世界なので、これは簡単には
  できない。

商品となると、様々な配慮が必要で(OSのバグの回避とか、エラー
発生時の対応とか)、とりあえず動作すれば良いというものでは
ないので、慎重にやる必要があります。経験者が仲間にいないと
相当大変だし、結局うまくいかないかもしれません。

Q英語翻訳

日本語から英語へ翻訳するサービスはネット上に結構ありますが、
早くて(1日以内に納品)、安い、お勧めのものはありますか?
どなたか教えてください!!

Aベストアンサー

翻訳会社を選ぶのには、一回テスト的に依頼してその出来具合を実際に確かめるしかいい方法はないと思います。依頼する前に、その翻訳会社の実績見本などを見せてもらえるとより確実なのですが。
以前仕事で、翻訳会社を何社か使ったことがありますが、その出来具合を100%は鵜呑みにせず、自分で確かめるようにしないと困るようなものもあります。特に、専門的なもの(電子とか、法律的なものなど)
はご自分がやる暇がないので外部に依頼する位でないと。

Q納品の定義,システムの動作の常識違反の責任の所在

概要
文字数制限のため
。無し
簡潔文章で失礼します。

一般向けに公開のメール配信WEBシステムの開発で当方クライアントです


1.システム開発の
納品
の定義は?

また納品物がWEBシステムやWEBサイトの常識に反する動作をする場合の責任の所在は?


2.相手が社内最終テスト結果、品質保証書を未提出です
これら書類の未提出を理由に
納品不完全として、契約解除できるか?

3.その他、相手側にビジネスマナーに反する行動が見受けられます
それを理由に契約書の解除条項の
重大な背信行為、契約を継続し難い重大事由
とできるか?

よろしくお願いします




詳細説明

1.契約書には納品物および納品方法は
開発したソースコード一式
サイトを公開するためのサーバの設定作業
該当ソースコードを該当サーバ上に設置しサイトを公開できる状態にする
です

しかし、この納品物は

仕様書記載の機能が未搭載
画像表示の抜け、ステータス表示のミス有り
単純な足し算結果すらミス表示
ボタンを押しても反応せず
ボタンを押下すると別の機能が実行
ログアウト機能がない


などの仕様書違反、単純ミス、ポカミス、WEBシステムの常識違反の嵐です
少しテストをすれば見抜けるものばかりです
絶対、社内テスト未実施でしょう

ただし、本道の機能であるメール配信機能だけは何とか使えます。
「途中で間違った操作を絶対にしない
 操作ミスをした場合、何が起きるかわからない」
という条件付きですが。

その結果、
検収表53ページ
表示ミス指摘の画像キャプチャ63ページ、
という膨大になりました

これでは到底一般公開できませんが、契約書の
公開
とは一般的には
単に不特定多数からのアクセスを可能とする
or
人様に見せて恥ずかしくない状態
どちらでしょうか?

また、ミスだらけ、エラーだらけ、それも隠れた瑕疵ではなく、ちょっとテストをすればぼろぼろ出てくるようなミス続出、エラー満載であっても納品日に間に合いさえすれば、
欠陥商品を納品しても納品完了になってしまうのでしょうか?
当方は到底承服しかねますが。
もっとも検収OKを出すつもりは全くありません。



2.上記のとおり、社内テストは未実施でしょう
テスト表を催促したら連絡掲示板にて

以下のテストを行いました
●●機能
●●機能
●●機能
・・・

と、単純に機能名だけを連ねた文面を送ってきました。
その中には仕様書記載にも関わらず、機能を搭載していない機能まで、
「実施したテスト」
として書かれていました。

(まさか、
テストはやったが、エラーを確認したとも、デバッグしたとも言ってませんよ、
という詭弁でしょうか?)

当方の
システム開発側は納品前の社内テストの結果をベンダに提出するのが常識
との考え間違いですか?

当方は、この
「社内テスト結果表の未提出」
あるいはおざなりに書かれた
以下のテストを行いました
●●機能
●●機能
●●機能
・・・
の中に、
「納品されたシステムに未搭載の機能がある。
 未搭載の機能について、一体何をテストしたと主張するのか?」
ということをもって
「顧客に対する虚偽報告、すなわち重大な背信行為」
として契約解除したいのですが。


3.今回はWEB上のお仕事マッチングサイト上でこの仕事を依頼しました
無論、契約前に相手社長と面談しました
しかし、契約後から相手が連絡を怠るようになりました
連絡掲示板にて質問を投げかけても都合の悪い質問には回答しなかったり、
更には

「連絡掲示板に投稿したのだけれど、連絡掲示板のシステム不良で、投稿した文章がきえてしまった。以前にもこういうことがよくあった。
 お仕事マッチングサイトには苦情を言ったが、適当にはぐらかされてしまい、改善されていない」
などと子供の言い訳じみたことを言う事もありました。

あまりにもおかしな釈明なので
「掲示板のシステム不良については承知いたしました。
鉄道会社は列車遅延した場合、遅延証明書を発行いたします。
貴社が嘘を言っているとは思えませんが、今回、当方が投げた質問にたいして、
”回答を投稿したが消えてしまった”
件はこのお仕事マッチングサイトから、”システム障害証明書”を発行してもらい、当方へ提出願います。
また、以前にもそのようなトラブルを経験しているのなら、なぜ、投稿内容が確実に反映されたか否か、をよく確認しないのですか?
 ”掲示板システムのトラブルを過去に経験している”、と主張するなら、そこに注意を払わなかったのは貴社のミスです。
 今後はその釈明は受け付けませんがよろしいですか?」
と問いかけたら黙ってしまいました。
(ということは、あの釈明が本当かウソか、わかりますよね)

更には納品後には急に

「言った言わないになるから面談は不可」

といい出し、更には当方の電話着信を英語留守番電話で対応し始めました
とても失礼な態度であり、到底今後の保守契約など結ぶつもりはありません。

当方は、再度面談して、検収結果の項目一つ一つについて、
「当方は検収の結果、エラーを発見したが、貴社は本当にテストをやったのか? 
 テストをやったのならなぜ検収でエラーが出てくるのか?
 テスト時にエラーを確認していたのなら、なぜデバッグせずに納品したのか?
 デバッグしていない成果物は納品とは認められない」
と問い詰めたいのです。(と同時にその場で契約解除したい)
がしかし、先方は社長不在を理由に会おうとしません。

検収締め切りまで時間が無いので、すで内容証明郵便にて契約解除を申し出ましたが、
ますます面会は拒否することでしょう。

-----

文字数制限のため、文書簡潔にしました。
足りない分はお礼欄、補足欄にて補足いたします。
よろしくお願いします。

概要
文字数制限のため
。無し
簡潔文章で失礼します。

一般向けに公開のメール配信WEBシステムの開発で当方クライアントです


1.システム開発の
納品
の定義は?

また納品物がWEBシステムやWEBサイトの常識に反する動作をする場合の責任の所在は?


2.相手が社内最終テスト結果、品質保証書を未提出です
これら書類の未提出を理由に
納品不完全として、契約解除できるか?

3.その他、相手側にビジネスマナーに反する行動が見受けられます
それを理由に契約書の解除条項の
重大な背信行為、契約を継続し難い...続きを読む

Aベストアンサー

 
社内最終テスト結果、品質保証書などを問題視する必要は無い

仕様書記載の機能が未搭載
画像表示の抜け、ステータス表示のミス有り
単純な足し算結果すらミス表示
ボタンを押しても反応せず
ボタンを押下すると別の機能が実行
ログアウト機能がない

仕様書を満足できないなら出来るまで相手の費用でさせればよい。
それが嫌なら契約破棄を言わせろ
 

Q発注テーブルの発注残数を納品テーブルの納品数で更新する

SQLはまだ初心者ですので、教えてください。
発注テーブルに発注数と納品数、発注残数の項目があり、納品テーブルに納品数があります。
納品テーブルの納品数の合計値で発注テーブルの納品済数と発注残数を更新したいのですがどの様なSQL文を書けばよいのでしょうか。

テーブルイメージは以下の様です。
<発注テーブル>
発注番号 商品 発注数 納品済数 発注残数
1 A 100   0 100
1 B 200   0 200

<納品テーブル>
発注番号 納品番号 商品 納品数
1 1 A 40
1 1 B 20
1 2 A 40
1 2 B 10

この状態で、納品テーブルの同一発注番号の納品数を商品毎に集計して、発注テーブルの同一発注番号の商品毎の納品済数と発注残数を更新したいのです。

更新後のイメージは以下の様です。
<発注テーブル>
発注番号 商品 発注数 納品済数 発注残数
1 A 100   80 20
1 B 200   30 70

どうぞよろしくお願いします。

SQLはまだ初心者ですので、教えてください。
発注テーブルに発注数と納品数、発注残数の項目があり、納品テーブルに納品数があります。
納品テーブルの納品数の合計値で発注テーブルの納品済数と発注残数を更新したいのですがどの様なSQL文を書けばよいのでしょうか。

テーブルイメージは以下の様です。
<発注テーブル>
発注番号 商品 発注数 納品済数 発注残数
1 A 100   0 100
1 B 200   0 200

<納品テーブル>
発...続きを読む

Aベストアンサー

kmeeさんの対応方法が良いかと思いました。
こういうのをいいたいのだと思います。
自分も良くやりますし、クエリも手順を分解して順番追えば簡単に作れますよ。

具体的にはこんな感じですね。
UpdateJoinを使った更新クエリです。
From句を使うのがポイントですね。

@発注番号に更新対象の発注番号をセットし実行すると
その発注番号の発注テーブルのデータが更新されます。

declare @発注 table(発注番号 int,商品 varchar(10),発注数 int,納品済数 int,発注残数 int);
declare @納品 table(発注番号 int,納品番号 int,商品 varchar(10),納品数 int,flg tinyint);
declare @発注番号 int

insert into @発注 values(1,'A',100,0,100),(1,'B',200,0,200);
insert into @納品 values(1,1,'A',40,0),(1,1,'B',20,0),(1,2,'A',40,0),(1,2,'B',10,0);
set @発注番号 = 1

--Update Join
update @発注 set 納品済数 =納品数,発注残数 = 発注数 - 納品数
from @発注 as 発注 inner join

--Updateに必要なテーブルを副問い合わせ
(select 納品.発注番号,納品.商品,sum(納品.納品数)as 納品数 from @発注 as 発注,@納品 as 納品
where 発注.発注番号 = 納品.発注番号
and 発注.商品 = 納品.商品
--更新対象の発注番号を指定
and 発注.発注番号 = @発注番号
group by 納品.発注番号,納品.商品) as 納品

--副問い合わせしたデータの結合条件(inner join のon)
on 発注.発注番号 = 納品.発注番号
and 発注.商品 = 納品.商品

※テーブルにテーブル変数使っているのでASでリネームしていますが、
実テーブルならリネームいりません。

kmeeさんの対応方法が良いかと思いました。
こういうのをいいたいのだと思います。
自分も良くやりますし、クエリも手順を分解して順番追えば簡単に作れますよ。

具体的にはこんな感じですね。
UpdateJoinを使った更新クエリです。
From句を使うのがポイントですね。

@発注番号に更新対象の発注番号をセットし実行すると
その発注番号の発注テーブルのデータが更新されます。

declare @発注 table(発注番号 int,商品 varchar(10),発注数 int,納品済数 int,発注残数 int);
declare @納品 table(発注番号 int,納...続きを読む

Q生命保険のシステム開発

生命保険のシステム開発に関する知識がほしいと
思い技術書みたいなのを探しています。

生命保険をやっている方はどのように勉強しているのでしょうか?

もし、やり方やこの本が良いよみたいなのがあれば教えてほしいです。

Aベストアンサー

業務フローではないですが、公開入札ならではのこんな情報も
公開されていますよ。
#一般企業のは、RFPもらえる会社じゃないと見れない・・

http://www.google.co.jp/search?hl=ja&source=hp&q=%E3%81%8B%E3%82%93%E3%81%BD%E3%80%80%E6%96%B0%E5%A5%91%E7%B4%84%E4%BA%8B%E5%8B%99&lr=&aq=f&oq=

Q請求書・納品書の日付と作成日について

いつもお世話になっております。

当方営業事務をしております。
春~この時期営業が長期出張のことがたまにあり、長期出張中に納品がきまっている品物については、先に納品書を作成しています。
納品書はもちろん納品日です。
納品書作成日である決裁のハンコの日付=納品日となっています。

社長より決裁のハンコを頂くときに、納品書作成日を納品日と同じにしなくてもいいんじゃないか?と指摘されました。

納品書作成日が納品日よりも前というのは、何か問題がないでしょうか?
また、うちの会社のフォーマットは売掛票~物品受領書までがセットで印刷されるのですが、この方法だと請求書・売掛票も実際の納品日よりも前の日付で売掛票・請求書が発行されてしまいますが、これも問題ないでしょうか?

Aベストアンサー

納品時ごとのフォーマットであれば、納品書作成が、納品日より前になるのは別にアリだとは思います。

どのような販売形態かにもよりますが、直接、お客さまに手渡しされているような形なら、注文を受けた日に納品書を作成し、納品できる日、納品を指定された日を記載するなどのように、明日納品する分の納品書を前日に作成しましたでも問題はないかと思います。
逆をいえば、お客さまから「先日納品してもらった分について、納品書もらってなかったから、今度くるとき、ちょうだい」と言われる事もあると思いますので、納品書作成日が納品日より後になることも、当然あると思いますし、(紙出力日ではなく、データ入力時が作成日になるシステムならありえないか...。)

ただ、頻雑になってしまうので、極力、納品日と納品書作成日が同じになるように作成していたほうがミスは少ないでしょうね。

余談ですが、納品日だけでなく納品書作成の日付まで、管理されているなんて、すごくキッチリされているんですね。すばらしいです。

Qシステム開発の全体像を学べるオススメの本

私はSEとして働いており、現在2年目になります。

現在のPJでは推進チームに参画しているのですが、
これまではコーディング・単体テストしか経験したことがなく、
他メンバの会話を理解できなかったり、自分で判断を下せない事が多々あります。


・○○が問題と言われても、何故○○が後のフェーズで問題となり得るのかわからない
・作業標準を定めるようなタスクにおいて、どのように定めるのがベターであるか判断できない

システム開発に関する経験、知識が足りない事が主な原因と考えているのですが、
システム開発の全体像を学ぶのにオススメの本がありましたら教えて頂きたいです。
以下のような内容が含まれていると嬉しいです。

・各フェーズの典型的な成果物(その目的、具体的内容)
・成果物作成のためのインプット資料と作業内容

よろしくお願いします。

Aベストアンサー

情報処理推進機構が出版している「共通フレーム2007」はどうでしょうか
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-50247-7
共通フレーム(SLCPーJCF2007)は、ISO/IEC 12207を基本として日本のニーズを追加したものになっています。

これには、具体的な成果物はありませんが、作業の目的が書かれています。

ソフトウェア会社では、共通フレーム(SLCPーJCF2007)に基づいた開発ができるようになっているところがあります。特に大手では


また、IPAでは、成果物の事例をユーザ登録が必要ですが公開しています。
http://sec.ipa.go.jp/tool/ep/

その他開発に関わる書籍もあります。
http://sec.ipa.go.jp/publish/index.html#ent

以上、参考になったら


このQ&Aを見た人がよく見るQ&A

人気Q&Aランキング