?1? SE????? 1-1 ???????SE

Document Sample
?1? SE????? 1-1 ???????SE Powered By Docstoc
					第1章 SEの仕事とは
 1-1 システム設計とSE

            株式会社ディー・アート
      上野淳三・広田直俊・白井伸児[著]
          「システム設計の考え方」


         H102124 宮澤新一
                      1
システム開発におけるSEの役割
• システム設計。

• システム要件を定義し、それを実現するシス
  テムの機能および構造を具体化する。

• システム設計者としてのSEの役割は、システ
  ム要求の把握からシステムの設計内容をプ
  ログラマへ伝達するまでである。
                         2
ユーザのシステム要求を把握する
• システム要求を把握する作業を一般に「要求
  分析」、「要求定義」あるいは「要件定義」と呼
  ぶ。

• 要求分析の内容や進め方はユーザの開発シ
  ステムに関する検討状況や、推進体制によっ
  て大きく変わる。


                           3
  ユーザの検討状況との関係


図1-1 ソフトウェアのライフサイクル




                      4
  ユーザの検討状況との関係
• ソフトウェアのライフサイクルは企画から始ま
  るが、通常、SEは開発段階からプロジェクト
  に参画する。

• 開発段階の要求分析工程はライフサイクル
  の出発点でなく、さらに上流にある。



                          5
  ユーザの検討状況との関係
• 要求分析は企画と開発の両方の段階で行わ
  れる。

• どの段階からSEがプロジェクトに参画するか
  により要求分析の作業内容は異なる。




                          6
  ユーザの検討状況との関係
• 社内SEの場合
 – 企画段階から入るケースが多い。
 – ユーザが白紙に近い状態からシステムの企画に
   着手することになる。
 – システム開発の目的や対象業務を定めるところ
   から要求分析が始まる。




                           7
  ユーザの検討状況との関係
• ユーザがシステム仕様を固めている場合
 – ユーザから要求仕様書の説明を受けるところか
   らSEの作業が始まる。
 – ソフトハウスなどの社外のSEはどちらかと言えば、
   このケースにあたる。




                          8
  ユーザの推進体制との関係
• ユーザ側の推進体制が異なれば、要求分析の進
  め方も変わる。

図1-2 ユーザからシステム要求を聞きだす




                          9
   ユーザの推進体制との関係
• 最も単純なケース

図1-2(1)ユーザの代表者からシステム要求を聞き出す




                              10
  ユーザの推進体制との関係
• 最も単純なケース
 – 小規模な部門システムを開発するケース。
 – ユーザがあらかじめ要求仕様を固めているケー
   ス。
 – ユーザの代表者とSEが1対1で対話するため、シ
   ステムイメージを頭合わせしやすい。
 – 比較的外乱が少ないが、代表者の背後にいる本
   当のユーザの意識をつかめないこともある。


                         11
  ユーザの推進体制との関係
• 一般的なケース

図1-2(2) 複数のユーザからシステム要求を聞き出す




                              12
  ユーザの推進体制との関係
• 一般的なケース
 – 複数のユーザグループの代表者からシステム要
   求を聞き出す。
 – 相反する要求や矛盾する要求もある。
 – 相反・矛盾する要求を整理してグループ間の調
   整を行い、要求を集約する必要が出てくる。
 – コントロールできない不確定要素が現れてくるこ
   ともある。


                        13
  ユーザの推進体制との関係
• 複数のSEが分担するケース

図1-2(3) 複数のSEがシステム要求を聞き出す




                            14
  ユーザの推進体制との関係
• 複数のSEが分担するケース
 – システム規模が少し大きくなり、ユーザの代表者
   が多くなるため、複数のSEが分担して要求分析
   を行う。
 – SE側で、それぞれが聞き出したシステム要求を
   SE同士で整理・調整・集約する必要が出てくる。
 – コントロールできない不確定要素が一段と大きく
   なり、作業プロセスも複雑になる。
 – 統制のとれた活動を展開する必要が出てくる。
                         15
  ユーザの推進体制との関係
• 新しい情報システムに求める役割が次第に
  経営や事業活動に密着したものになるにつ
  れて、ユーザ主導でシステムを企画する傾向
  が強くなっている。

• システム設計を担当するSEは、ユーザ主導
  の企画プロセスがどのように進められるかを
  理解しておく必要がある。
                     16
    システムを設計する
• SEがシステム設計で心得ておくべきことは、
  ユーザの要求をそのまま鵜呑みにしてシステ
  ム設計を行なってはいけないということ。

• 業務システムとしてやるべきこと、やってはい
  けないことをユーザに直言できないようでは、
  専門家の資格はない。


                      17
    システムを設計する
• ユーザもSEに対して専門家としての見識を
  期待しているため、その期待に応えて積極的
  に提案することが望まれる。

• ユーザの要求が、必ずしもユーザが求める真
  の要求でないことも知っておいた方がよい。



                     18
    システムを設計する
• ユーザは業務に慣れてしまっているため問題
  自体が見えなくなっていることがある。

• システム設計者において、ユーザの要求を
  しっかり見きわめ、取捨選択する必要がある。




                      19
    システムを設計する
• 必要と判断した要求を実現可能な形に構成し、
  システムを設計する。

• 設計した内容はユーザに説明して、ユーザの
  理解と承認を得る必要がある。




                     20
    システムを設計する
• 新しいシステムを構築するということは、ある
  意味で新しい業務モデルを設計する必要が
  あるということである。

• 現在の業務モデルから直接新しい業務モデ
  ルを検討するのではなく、現行のモデルから
  物理的な要素を排除した論理モデルを作成し
  て検討するようなことを行なう。
                      21
     システムを設計する
• 図1-3 論理モデルを使ったシステム設計プロセス




                             22
    システムを設計する
• 論理モデルを採用するのは、現実にある別の
  問題に気がとられて目的とする新しい業務モ
  デルの検討が進まないといった理由があげら
  れるためである。




                     23
       システムを設計する
• システム設計で用いる開発技法として、プロ
  セス中心アプローチ(POA:Process Oriented
  Approach)やデータ中心アプローチ
  (DOA:Data Oriented Approach)などがある。

• POAが、処理手順やデータの流れに注目し
  て現状を分析する手法であるのに対して、
  DOA では、データとその流れの分析に重点
  を置き、システム設計を進める。
                                  24
プログラマへ設計内容を正確に伝達する

• システム設計書は、プログラム開発を行なう
  ための仕様書としての役割がある。

• システム開発プロジェクトの関係者がシステ
  ムの完成イメージや実現方法・製作プロセス
  などの情報を共有する目的も合わせ持つ。



                         25
プログラマへ設計内容を正確に伝達する

• システム設計書には、仕様書としての精緻な
  面と、関係者に対する新システムのガイドブッ
  クとしてのわかりやすさの両面が求められる。




                      26
1-2 情報化の動向
  8~17ページ
   H102002
   安島澄人


             27
         新情報革命
• 経営学者として著名なドラッカーは、現在の
  情報化、つまり、コンピュータの発明以来の
  情報化を「第4の情報革命」と称している。

• またドラッカーは、今後、情報技術(IT)の分
  野における重心は技術(T=Technology)か
  ら情報(I=Information)に移行していくと展望
  している。
                             28
  情報技術のパラダイムシフト
• 思考の枠組みや考え方(旧体制)が壊れたり、
  根本的な変化が生じたりすることを「パラダイ
  ムシフト」と呼ぶ。

• 情報技術分野では、これまで、メインフレーム
  を代表とするシステム中心のパラダイムから、
  80年代にPC中心のパラダイムへ、さらに90
  年代にはネットワーク中心のパラダイムへと2
  回のパラダイムシフトが起きている。
                       29
   1-3 情報システムとは
• SEが取り組む情報システムはどういうものか。

• 情報システムの処理形態が発展してきた経
  緯
• 企業における業務面から見た情報システム
• 企業における役割から見た情報システム
  を紹介する。

                        30
  情報システムの処理形態
バッチ処理 (データの一括処理)
         ↓
オンライン
リアルタイム処理 (データの即時処理)
         ↓
データベース処理 (データの共有化と一元管
 理)

                        31
          バッチ処理

• コンピュータの処理方法

I:入力(Input)
P:処理(Process)
O:出力(Output)


                  32
 コンピュータの利用形態の変化
• コンピュータ利用開始から
  30年くらい前の利用形態

(1)技術計算などのコンピュータの計算能力
(2)給与計算などのデータ処理

(1)、(2)に重点を置いた使い方が中心だった。

                        33
 コンピュータの利用形態の変化(2)
今日、技術計算は
(1)CAD(Computer Aided Design:
         コンピューター設計)
(2)CAE(Computer Aided Engineering:
        モデルの特性解析シュミレーション)
(1)、(2)やスーパーコンピュータを使った天気
  予報のシュミレーション計算などの分野に発
  展している。
                                 34
      バッチ処理方式
• 給与計算のデータ処理が今日のデータ処理
  に発展した。

• 給与計算のようなある期間に収集したデータ
  をまとめて一括処理する方式を「バッチ処理
  方式」と呼ぶ。



                        35
  オンラインリアルタイム処理
• その後、コンピュータの利用技術が進み、オ
  ンラインリアルタイム処理への移行が始まる。

• コンピュータに端末から直接データを入力し、
  処理結果が直ちに必要な場所に出力される
  処理方式である。

• コンピュータの対象領域の拡大。
                      36
  システム設計の対象範囲
入出力設計や処理ロジックを中心としたバッチ
 処理システムの設計内容
           ↓
オンラインリアルタイムシステムのシステム設
 計では業務設計が主要なものとして加わる。

バッチ処理システムに比べて、SEが行うシステ
 ム設計の業務内容は質的に変わった。
                     37
       データベース処理
• 業務システムで蓄積したデータや組織が保有
  する情報を有効利用するために、それらを整
  理してコンピュータ上に保存し、必要に応じて
  取り出す仕組みを「データベース」と呼ぶ。
• データベースを構築し、活用するソフトウェア
  を「データベース管理システム DBMS
  (Data-Base Management System)
• データベースを運用するシステムを「データ
  ベースシステム」と呼ぶ。
                              38
 企業における業務機能面から見た
      情報システム
• 基幹業務を対象とした基幹系システムに始まり、そ
  のデータを活用する情報系システムへと発展してき
  た。
• 基幹系システム 販売管理、生産管理、在庫管理、
  財務会計、人事給与等
• 情報系システム 顧客情報管理、商品情報管理、業
  績情報管理
• OAシステム ワープロ、表計算、プレゼンテーション
  ソフトなど
• グループウェア 電子メール、電子掲示板、文書共
  有など

                          39
 企業経営における役割から見た
     情報システム
• 経営者が求めているのは、企業の将来にか
  かわる情報である。

• 企業の情報システムは、データを処理して業
  務を効率化することから始まり、経営に役立
  つ情報システムの構築を目指してきた。



                        40
EDPS (Electronic Data Processing
  System : データ処理システム)
• コンピュータの初期に始まった情報ビジネス
  の概念。
• 経理計算、給与計算などの従来から手作業
  で行っていたデータ処理を機械化し、処理の
  効率性向上を狙いとしている。




                               41
 MIS(Management Information
  System : 経営情報システム)

• 1960年代後半に始まった概念。
• 経営に必要な情報をあらゆる階層で活用す
  ることを目指した。
• 業務の効率化だけでなく、経営面でコン
  ピュータを活用する狙いがあったが、当時の
  技術レベルでは実現できなかった。

                              42
DSS (Decision Support System :
   意思決定支援システム)
• 80年代に始まった概念。
• MISが狙いとした、組織の目的に貢献する情
  報を作り出すという一面を焦点に絞ったシス
  テムである。
• 経営レベルでの意思決定支援を目的としてい
  る。



                                 43
  SIS (Strategic Information
 System : 戦略的情報システム)
• 90年代にできた概念。
• 情報技術を活用して既存の企業活動を抜本
  的に再構築することを目指している。
• 業務の効率化よりも、売り上げ増や競争優位
  の確立を目的としている。




                               44
  EC (Electronic Commerce :
         電子商取引)
• 90年代にインターネットの普及とともに急速
  に広がったシステム
• 情報技術を活用して、新しい市場機会を生み
  出すことを目指している。




                              45
     第1章 SEの仕事とは
1-4 システム開発プロジェクトにおけるSEの役割

                 株式会社ディー・アート
           上野淳三・広田直俊・白井伸児[著]
               「システム設計の考え方」


              H102124 宮澤新一
                          46
情報サービス産業における職能別就業者数

• 情報サービス産業における職種別就業者数
  のうち、職種別で一番多いのは「システムエ
  ンジニア(SE)」である。

• 「プログラマ」、「管理・営業」と続き、この人員
  構成から、SEが情報サービス産業の中核で
  あることがわかる。


                         47
情報サービス産業における職能別就業者
         数
図1-8 情報サービス産業における職種別就業者数の
     割合




                        48
 SEの役割の拡大と専門分化
• 情報処理技術者の分類はソフトウェア開発に
  おける役割をもとに行なうのが一般的。

• ユーザの要求分析、システム設計などのシス
  テム開発の上流工程を担当する技術者を
  「SE」と呼ぶ。



                     49
     SEの役割の拡大と専門分化
• SEの事業範囲は、以下のものである。
 –   利用者の要求分析
 –   システム設計
 –   プログラム開発の指導
 –   総合テスト
 –   本番移行時のユーザ支援
 –   システム構築の保守


• ライフサイクル全体にSEが主導的な役割を担う。

                            50
 SEの役割の拡大と専門分化
• 情報システムがSISやECといった形で企業
  経営に密接なものになってきている。

• システムの開発では、どういう形(How)で実
  現するかは二の次になり、どんなシステム
  (What)を構築するかが重要になる。



                           51
 SEの役割の拡大と専門分化
• 開発の最上流工程、あるいは、開発に入る前
  のシステム企画段階を担当するソリューショ
  ンの専門家のニーズが大きくなっている。

• 技術面ではオープンシステム化が進展し、シ
  ステムを構成するハードウェア、ソフトウェア、
  ネットワーク、データベース等が急速に多様
  化・高度化している。
                       52
 SEの役割の拡大と専門分化

• 大規模なプロジェクトになると、技術者を連携
  させ、プロジェクト全体をマネジメントする専門
  家であるプロジェクトマネージャが必要になる。




                      53
 SEの役割の拡大と専門分化
• 現状では、SEの守備範囲が広がりすぎてSE
  の定義があいまいになっていると言える。

• これまで一括にしていたSEの概念でこうした
  新しい役割をカバーするのは無理があるため、
  技術者を専門分化する方向が打ち出されて
  いる。


                      54
 SEの役割の拡大と専門分化
• システム化計画の立案などソリューションを
  担当するITコーディネータやシステムアナリス
  ト、業種・業務に詳しいアプリケーションエンジ
  ニア、技術面に特化したテクニカルエンジニ
  アなどが新しい技術者の分類になります。




                       55
システム構築におけるSEの役割
• 開発プロジェクトにおける基本的なSEの役割
 1.ユーザの業務要件の分析
 2.システム設計、システム方式設計、システム移
   行・運用設計
 3.プログラム開発の推進
 4.総合テストの実施
 5.利用部門に対する本番移行の支援



                           56
システム構築におけるSEの役割
図1-9 開発プロジェクトにおけるSEの役割




                         57
システム構築におけるSEの役割
• 建築などの成熟した分野では、設計と施工が明確
  に分離しています。

• システムの開発においては、プログラム開発工程へ
  の指示を設計書で行なえるかというと、そうはいか
  ない。

• 現状では、SEがプログラム開発、テスト、本番移行
  までを一貫して担当し、状況を見ながら細かく指示
  するのが一般的である。

                           58
ケースバイケースで変わるSEの役割

• 専任のプロジェクトマネージャが付くような大
  規模プロジェクトであれば、SEは担当部分の
  システム設計やプログラムソフト開発にある
  程度専念することができる。

• プロジェクトマネージャが付かない小規模な
  プロジェクトになると、リーダ格のSEがプレー
  イングマネージャを兼ねることができる。
                       59
ケースバイケースで変わるSEの役割

• ソフトハウスが開発業務を担当している場合、
  SE課長がプロジェクトマネージャになると顧
  客に報告しているケースでも、それは名目上
  のことで、担当SEが実質的なプロジェクト管
  理を行うケースが多いようである。




                      60
  SEが行うプロジェクト管理
• リーダー格のSEになると、プロジェクト全体の
  プロジェクト管理を行うことが多くなる。

• 初級SEも、一般に、自分の担当するサブシス
  テムの開発責任を負うことになる。

• 開発責任を負うということは、担当部分の納
  期・品質・コストについて責任を持つことを意
  味する。
                          61
   SEが行うプロジェクト管理
• システム開発はチームで行う。

• SEは複数のプログラマで構成された小さな
  チームを率いることになる。

• プログラム開発をプログラマ任せにせず、プ
  ログラマとよくコミュニケーションをとり、進捗
  状況を把握して管理する必要がある。
                           62
  SEが行うプロジェクト管理
• プログラマがプログラム開発に特化するのに
  対して、SEは他のプロジェクト関係者(ユーザ、
  プロジェクトマネージャ等)との連携をとりつつ、
  システム開発に関しては何でもやるつもりで
  いないと開発責任を全うすることはできない。




                       63
1‐5 SEに求められる
      知識と能力


    H102042 小林 弘晃


                    64
     SEの専門性(1)
• プログラマの能力差は把握しやすい

• SEの専門性や能力差は把握しにくい
 – 取り組んでいるシステムの内容、ユーザのレベル
   に応じて仕事の難易度が異なる

 – 開発した結果がSEの能力差なのか開発チーム
   全体の差なのか判断が付きにくい



                           65
      SEの専門性(2)
• 優秀なSEと、そうでないSEの差は明確
 – システム開発に要した工数

 – テスト期間に発見されたバグの件数




                        66
優秀なSEと優秀ではないSEの違い

• 優秀ではないSE
 – 忙しそうに駆け回っている
        ↓
    目先のことしか考えず、トラブルに追われてる

• 優秀なSE
 – 自席でゆったりしている
        ↓
    先のことを考え、トラブルになる前に先手を打つ
                            67
SEに要請される知識と能力(1)
• SEには幅広い知識と能力が求められる




                       68
SEに要請される知識と能力(2)
• 若手SEの様子
 – 業務分析や要件定義に単独で放り込まれること
   はない

 – 担当する部分が次第に増え、開発工程の上流工
   程へと拡大していく

 – 実践を積みながら業務の幅を広げ、知識とスキ
   ルを向上させていく


                           69
  仕事の進め方の基本(1)
• システム開発業務はプロジェクト対応
 – 基本的に同じ仕事はない

 – 業務環境やプロジェクトメンバーが変わる




                         70
  仕事の進め方の基本(2)
• 仕事の進め方の基本
 – PDCAサイクルで計画を立てて取り組む

 – 5W1Hで検討項目を洗い出す

 – ホウレンソウを忘れない

 – タスクの優先順位をつける



                         71
            PDCAサイクル(1)

• P: Plan
  – 目標を設定し具体的な計画に落とし込む
• D: Do
  – 計画に基づき実行
• C: Check
  – 実行過程で達成状況を測定・評価
• A: Action
  – 測定結果を受け、必要に応じて軌道修正
                          72
PDCAサイクル(2)




              73
     PDCAサイクル(3)
• 基本的に開発業務の中で何かまとまった仕
  事に着手するときに利用する
• 手戻り少なく、効率よく仕事を進められる
• 最初の計画段階が重要

• 1つのサイクルが終了したら、再設計のプロ
  セスから次のサイクルを回す

                         74
              5W1H
• 仕事の内容を手早く理解するのに有効
 –   Why(なぜ)
 –   Who(だれが)
 –   What(何を)
 –   When(いつ)
 –   Where(どこで)
 –   How(どのように)


                      75
              5W2H
• SEの業務では、数量を確認することが多い
             ↓
    5W1Hにもうひとつ「H」を加える

• 新たに加えられた「H」とは
 – How much・How many(いくら)



                            76
           ホウレンソウ
• 報告(ホウ)
 – 結論を先に、簡潔明瞭に事実と意見の区別をつ
   けて報告する
• 連絡(レン)
 – 上司と関係者に迅速かつ明瞭に伝達する
• 相談(ソウ)
 – こじれる前に上司や同僚に相談する


                           77
     タスクの優先順位
• 開発業務が佳境に入ると、SEは複数のタス
  クを平行して進めることが多くなる
            ↓
  重要度、難易度、納期などを考慮して、タスク
  に優先順位をつける




                      78
    ITスキル標準とは(1)

• 各種IT関連サービスの提供に必要とされる能
  力を明確化・体系化した指標である
• ITスキル標準の構成
 – ITサービスを11職種 / 38の専門分野として区分
 – 実務経験・実績をもとに「達成度指標」を設定
 – 必要なスキルを教育・訓練に活用する観点から
   スキル項目に要素分解
 – スキル項目ごとに「スキル成熟度」と「知識項目」
   を展開
                            79
ITスキル標準とは(2)




               80
ITスキル標準とは(3)




               81
    ITスキル標準とは(4)
• ITスキル標準の活用例
 – 人材育成・調達を行う際の目安となる

 – 自らのスキル開発をどのように行うべきかを判断
   する指標となる




                        82
1-6 SEの学習方法

   Uploadなし




              83

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:13
posted:5/21/2012
language:Japanese
pages:83