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

このQ&Aのポイント
  • システム開発に関する経験、知識が足りないことが主な原因と考えている方へ。システム開発の全体像を学ぶのにオススメの本をご紹介します。
  • 現在のPJでは推進チームに参画している方へ。システム開発に関する知識が不足している場合におすすめの本をまとめました。
  • システム開発の全体像を理解したい方へ。各フェーズの典型的な成果物やインプット資料について解説した本をご紹介します。
回答を見る
  • ベストアンサー

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

私はSEとして働いており、現在2年目になります。 現在のPJでは推進チームに参画しているのですが、 これまではコーディング・単体テストしか経験したことがなく、 他メンバの会話を理解できなかったり、自分で判断を下せない事が多々あります。 例 ・○○が問題と言われても、何故○○が後のフェーズで問題となり得るのかわからない ・作業標準を定めるようなタスクにおいて、どのように定めるのがベターであるか判断できない システム開発に関する経験、知識が足りない事が主な原因と考えているのですが、 システム開発の全体像を学ぶのにオススメの本がありましたら教えて頂きたいです。 以下のような内容が含まれていると嬉しいです。 ・各フェーズの典型的な成果物(その目的、具体的内容) ・成果物作成のためのインプット資料と作業内容 よろしくお願いします。

質問者が選んだベストアンサー

  • ベストアンサー
  • jeee
  • ベストアンサー率52% (119/227)
回答No.2

情報処理推進機構が出版している「共通フレーム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 以上、参考になったら

hithitoshi
質問者

お礼

ご回答ありがとうございます。 共通フレームは丁度勉強してみようかなと思っていたところです。 書籍をご紹介頂きありがとうございました。 参考にさせて頂きます。

その他の回答 (1)

  • layy
  • ベストアンサー率23% (292/1222)
回答No.1

>これまではコーディング・単体テストしか経験したことがなく、 プログラマの時代でも「何か問題意識」はあったはず。 ここをこうしたら効率がいい、ここの修正で不具合を招いて失敗した、等。 >・各フェーズの典型的な成果物(その目的、具体的内容) >・成果物作成のためのインプット資料と作業内容 プログラマの時代でも「何か成果物」はあったはず。 それを同じように、今のSEの視点に変えていけばいいのでは?。 「問題」は早い段階の作業工程で見つける方が良いです。 そこに疑問をいだいて、何か本を探すというものでもないのでは?。 これは経験値が生みだす考え方とは思います。 情報処理試験でも「○○設計とは」のテーマもありますし、それでいいのでは?。 それとも会計システム、在庫システム、といった業務知識が 必要なものなのかどうか。

hithitoshi
質問者

お礼

ご回答ありがとうございます。 プログラマ時代にも、確かに問題と感じることはありました。 ただ、そのときの観点はコーディング(特に画面・帳票系の実装)という 非常に限定的な範囲に止まっており、 その経験を今の仕事に活かせていないのが現状です。 現在のPJは規模が大きく、10弱のチームに分かれて開発を実施しているのですが、 プロジェクト推進チームはこれらすべてのチームの調整を行わなければならず、 明らかに知識・経験が不足していると感じています。 例えば、現在PJは基本設計に入ったところですが、そのフェーズにおいて、 基盤チームはシステム方式設計のためにどのような作業をしているのか データチームではどのようにDB設計を行っているのか など、よく理解できておらず、その詳細な話が出てもよく理解できないことが多々あります。 業務を通して知識・経験を身につければ良いのですが、 職場以外にも勉強できるようにと思い、質問しました。 情報処理試験の本ももう一度見直してみたいと思います。 ありがとうございました。 ※業務知識も必要なPJですが、今回の質問では考慮して頂かなくて結構です。

関連するQ&A

  • 完全在宅でのシステム開発は可能になってきているか?

    システム開発といってもいろんな形がありますが、どんなものでも完全在宅というのは考えられません。 ユーザーの要件をヒアリングし、要件定義/基本設計/詳細設計/実装/テスト・・・というフェーズは人と人とのコミュニケーションが大切です。 「システム開発は在宅では無理」という常識があります。 この常識をくつがえす開発方法を考えたら、もしかしたら大きなビジネスチャンスにつながるのではないでしょうか。 在宅でシステム開発をするには何が問題なのか。を一つ一つつぶしていき、新たなビジネスにしたいと考えています。 「何が問題なのか・・・」思いつくものを教えてください。 逆に「何がメリットなのか・・・」についてもお願いします。

  • システム開発の検査合格証について

    現在、システム開発が完了して検収フェーズなのですが、検査合格証を御客さん側から出してもらうため書式を作成しようとしているのですが、今まで業務上作成経験がないため、どのような書式を作成したらよいか探しあぐねています。 もし参考の書式があるサイトなどご存知の方がいらっしゃいましたらぜひご教示いただけると大変助かります。 どうぞよろしくお願いします。

  • システム開発を行う上での

    システム開発を行う上での FP法での見積もりに対する各工程の所要日数について お伺いさせて頂きます。 Aシステム : 120FP 生産性  : 7.5時間 / FP 月間標準時間 : 150時間(1人月) (1日は7.5時間、月間は20日とする。) 作業要員:2名 システム開発の工程及び工程別工数配分率 要件定義: 50% 内部設計: 20% 詳細設計: 35% プログラム設計 : 50% コーディング : 30% 単体テスト : 20% システムテスト :20% 上記内容で詳細設計の プログラム設計、コーディング、単体テストの 所要日数を算出したいのですが以下の計算で認識は合っておりますでしょうか? 120FP × 35%(詳細設計) = 42FP(42人日) 42FP × 50%(プログラム設計) = 21FP(21人日) 42FP × 30%(コーディング) = 12.6(12.6人日) 42FP × 30%(単体テスト) = 8.4(8.4人日) プログラム設計の所要日程⇒ 21人日÷2人 = 10.5日 コーディングの所要日程⇒ 12.6人日÷2人 = 6.3日 単体テストの所要日程⇒ 8.4人日÷2人 = 4.2日 以上。 宜しくお願い申し上げます。

  • システムアーキテクトの論文

    今度システムアーキテクトの試験を受けます。 論文を書く前にシステムの概要を書きますが システム開発の規模 ・総工数 ・総額 ・期間 等を書かなくては行けません。 私は汎用系SEでフリーランスをしています。 汎用機の案件は期間が長く、規模が大きく、複数の会社が関わるのが普通です。 また、ウォーターフォールで各フェーズ毎に見積もり等し直します。 このような場合どのように記述してよいかわかりません。 あくまでも自分が参画したフェーズだけを切り出して記述すれば良いのでしょうか。

  • システム開発後のシステムチェックとは

    短期のアルバイトを探しているのですが 期間、勤務地、時給等の条件にピッタリの求人があったのですが、その仕事内容がイマイチわかりません。 ■内容 システム開発後のシステムチェックのお仕事 テスト仕様書、試験項目にそって、動作確認、チェックをお願いします。 ■資格 システムテスト作業経験のある方歓迎 ゲームのデバッグみたいなものですか? 何か専門的な知識、スキルがないとできないような仕事なんでしょうか?

  • システム開発のインセンティブについて

    お世話になります。 弊社のシステム開発部門で業務時間外において システムの開発(アプリ等簡易なもの)を制作した際に 成果物に対してインセンティブを支払うことを検討しております。 ですが、休日等で作業を行った際に支払われるお金ですので 労働基準法では、その分の時間外手当が必要なのでは?と社内から 声があがっております。 また、時間外手当を支払わずインセンティブという形で支払った場合、 その製作者が退社した後、時間外手当を請求されるのでは?という意見も上がっております。 この場合は労働基準法ではどのように定義されているのでしょうか。 簡単な内容で大変恐縮ですが、ご回答の程宜しくお願い致します。

  • 請負開発のルール

    私は、小さなソフト開発会社でSEを行っております。 PerlPHPなどによるWEB開発おこなっております。 規模的には、小規模な開発が多いです。 今回の質問内容は、昨年当社でトラブルがあった件について投稿いたしました。皆さんの意見をお聞かせいただけますと幸いです。 昨年8月にあるシステムを請けました。 PHP+Postgresにての開発です。 サーバー構築も含めて請けました 発注元とのトラブル 当方PGの体調不良等あり 私の会社は一部の開発とサーバー構築を担当。 発注元が最終的に請負部分の納期に間に合わなかったので、見積の支払いを減額。また、できた部分の評価をされてしまいかなり減額されてしまいました。できなかった部分に関しては、発注元が引き継いだのです。 設計は当方で行いました。 サーバー構築も作業 各フェーズの仕様は、何度か変更になり、最終的なシステム全体の仕様書は無いまま開発にはいる。 11月末納期で作業していたのですが、フェーズ毎にチェックが入るたびに戻りがあり納期までに納入できませんでした。 しかも発注元では、私の会社に内緒で同じフェーズの開発を行っていたようなのです。そうとは知らず私の会社は請けた作業を行っておりました。WEBシステムなので、開発を行っている部分は発注元もリアルに確認できます。 またノウハウ等全て持っていかれているかと考えられます。そして最後には、納期に間に合わないので当方開発部分はほとんど使えないといわれ、開発環境サーバーへのアクセスもできないようにされました。 このような場合ですが、PHP関数、Javaスクリプトでのエラーチェック等、単体納品物とならないのでしょうか。 成果物が納期に間に合わないと言うことで、このような形になってしまうのでしょうか。 最初からトラブルがあったこともあり、発注元からのメールは喧嘩腰でした。 皆様の意見をお聞きできればと思います。

  • 技術者では通用しない

    IT系の技術者を数年やっています。 仕事としては、例えば1次受けのプロパーやSIlerに、 基本設計フェーズのメンバーとして参画して、方式や設計書を考えたり、 得意な技術分野を生かして、開発フェーズにも参画していました。 しかし現職に入ってからなのですが・・、こういった仕事は無くなり、 案件を受注して、PJ計画を考え、工数やスコープを考えるような、 動きを求められました。 しかしこの変化に、適応できず精神的に参っています・・。 基本設計の経験も少なく、より上流の仕事は経験がありません。 計画、要件定義、スコープ、契約、見積・・と必要作業があっても、 アプローチや判断基準がモヤッとしていて、仕事に自信が持てず・・。 上司に質問しても、自分の目線より高いお話が多く、苦慮しています。 こういった仕事は、やはり上流から納品まで一連の工程を経験していないと、 精度の高い仕事は難しいでしょうか?。 どうしても皆が持っている経験が自分には足りない、、と感じてしまいます。 以前のメンバーやサブリードでの参画のほうが、技術力が身について 遣り甲斐があったのかもしれません。 しかし雇われでは、年齢と共に先が見えてしまうのでしょうか・・?。 (幅広い技術力の人は不要なのでしょうか・・)

  • プログラムの開発フェーズにおける順位付け

    皆様 お世話になります。 プログラム開発フェーズにおける順位付けを行いたいと思います。 下記に列挙する項目に対し順位付けを行いたいと思います。 どうか皆様の考えをお聞かせください。 ■開発フェーズの作業  ・処理フローの作成  ・機能構造図の作成  ・コーディング  ・コンパイル  ・コンパイルエラーの修正  ・テスト項目の洗い出し  ・テスト仕様書の作成  ・テストデータの作成  ・単体テストの実施  ・テスト結果のチェック修正  ・エビデンス作成  ・コーディング(サブプログラムに分割)  ・処理速度向上の考慮  ・可読性(コメント)の考慮  ・共通関数の調査  ・共通関数の設計  ・機能のプレ開発  ・設計書を熟読  ・設計書の内容の確認作業  ・開発標準【命名規約/コーディング規約/】の作成  ・開発標準の確認作業  ・開発環境の設定  ・テスト仕様書のテンプレート作成  ・ソース管理方法の作成  ・進捗管理方法の作成【プロジェクトレベル】  ・各種レビュー   ※上記の作業内容の階層化順序付け

  • システム開発における

    システム開発における 問題点の分析について、アドバイス頂きたい事があり 投稿させていただきました。 <経緯> 現在使用している販売管理業務システムを 現行の業務と乖離してきている為内容を修正することとなった。 販売管理システムは、X業務システム、Y業務システム、Z業務システム 3つのサブシステムで構成されていて それぞれの業務に精通したメンバーを割り当てる必要があった。 ところが、かつて現有システムの開発に携わった経験を持ち、 各業務に精通しているメンバはわずか3名であり、 一方Z業務管理システムの構築に必要な特別なスキルを 身につけているのも、この3名だけであった。 結果として、A課長はこの3名をZ業務管理システムの開発に配置し、 X業務管理システム、Y業務管理システムともに、業務には精通しているが 開発スキルは不十分なメンバと開発スキルは十分だが業務の理解は 不十分なメンバの混成チームを編成し、各チームにリーダを配置し、本プロジェクトを開始した。 結合テストが終盤に差しかかる頃、 バグが多発しテストの進捗に影響を与えている状況が露呈した。 結合テスト工程でのバグ原因分析 サブシステム名 設計バグ件数 製造バグ件数 総バグ発生件数 X業務     51     89     140 Y業務     25     137    162 Z業務     2      21     23 全体      75     250    325 結合テスト工程でのバグ原因分析の結果によると、 X業務システム、Y業務システムについて それぞれ問題点を認めることができますが X業務システム、Y業務システムのリーダの立場として、 (1)表3の分析から、不具合を是正するためにどのようなことを行うか。 (2)プロジェクトの初期の段階でどのようなことをすれば根本的に  ここで生じている問題を回避することができたと考えられるか。 上記2点に関して、アドバイスを頂けないでしょうか。 以上。 宜しくお願い申し上げます。

専門家に質問してみよう