第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 情報化の動向 ８～１７ページ H102002 安島澄人 27 新情報革命 • 経営学者として著名なドラッカーは、現在の 情報化、つまり、コンピュータの発明以来の 情報化を「第４の情報革命」と称している。 • またドラッカーは、今後、情報技術（IT）の分 野における重心は技術（T＝Technology)か ら情報（I＝Information)に移行していくと展望 している。 28 情報技術のパラダイムシフト • 思考の枠組みや考え方（旧体制）が壊れたり、 根本的な変化が生じたりすることを「パラダイ ムシフト」と呼ぶ。 • 情報技術分野では、これまで、メインフレーム を代表とするシステム中心のパラダイムから、 80年代にPC中心のパラダイムへ、さらに90 年代にはネットワーク中心のパラダイムへと2 回のパラダイムシフトが起きている。 29 1-3 情報システムとは • SEが取り組む情報システムはどういうものか。 • 情報システムの処理形態が発展してきた経 緯 • 企業における業務面から見た情報システム • 企業における役割から見た情報システム を紹介する。 30 情報システムの処理形態 バッチ処理 （データの一括処理） ↓ オンライン リアルタイム処理 （データの即時処理） ↓ データベース処理 （データの共有化と一元管 理） 31 バッチ処理 • コンピュータの処理方法 I：入力（Input) P：処理（Process) O：出力（Output) 32 コンピュータの利用形態の変化 • コンピュータ利用開始から 30年くらい前の利用形態 （１）技術計算などのコンピュータの計算能力 （２）給与計算などのデータ処理 （１）、（２）に重点を置いた使い方が中心だった。 33 コンピュータの利用形態の変化（２） 今日、技術計算は （１）CAD（Computer Aided Design: コンピューター設計） （２）CAE（Computer Aided Engineering: モデルの特性解析シュミレーション） （１）、（２）やスーパーコンピュータを使った天気 予報のシュミレーション計算などの分野に発 展している。 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 １‐５ ＳＥに求められる 知識と能力 H102042 小林 弘晃 64 ＳＥの専門性（１） • プログラマの能力差は把握しやすい • ＳＥの専門性や能力差は把握しにくい – 取り組んでいるシステムの内容、ユーザのレベル に応じて仕事の難易度が異なる – 開発した結果がＳＥの能力差なのか開発チーム 全体の差なのか判断が付きにくい 65 ＳＥの専門性（２） • 優秀なＳＥと、そうでないＳＥの差は明確 – システム開発に要した工数 – テスト期間に発見されたバグの件数 66 優秀なＳＥと優秀ではないＳＥの違い • 優秀ではないＳＥ – 忙しそうに駆け回っている ↓ 目先のことしか考えず、トラブルに追われてる • 優秀なＳＥ – 自席でゆったりしている ↓ 先のことを考え、トラブルになる前に先手を打つ 67 ＳＥに要請される知識と能力（１） • ＳＥには幅広い知識と能力が求められる 68 ＳＥに要請される知識と能力（２） • 若手ＳＥの様子 – 業務分析や要件定義に単独で放り込まれること はない – 担当する部分が次第に増え、開発工程の上流工 程へと拡大していく – 実践を積みながら業務の幅を広げ、知識とスキ ルを向上させていく 69 仕事の進め方の基本（１） • システム開発業務はプロジェクト対応 – 基本的に同じ仕事はない – 業務環境やプロジェクトメンバーが変わる 70 仕事の進め方の基本（２） • 仕事の進め方の基本 – ＰＤＣＡサイクルで計画を立てて取り組む – ５Ｗ１Ｈで検討項目を洗い出す – ホウレンソウを忘れない – タスクの優先順位をつける 71 ＰＤＣＡサイクル（１） • P： Plan – 目標を設定し具体的な計画に落とし込む • D： Do – 計画に基づき実行 • C： Check – 実行過程で達成状況を測定・評価 • A： Action – 測定結果を受け、必要に応じて軌道修正 72 ＰＤＣＡサイクル（２） 73 ＰＤＣＡサイクル（３） • 基本的に開発業務の中で何かまとまった仕 事に着手するときに利用する • 手戻り少なく、効率よく仕事を進められる • 最初の計画段階が重要 • １つのサイクルが終了したら、再設計のプロ セスから次のサイクルを回す 74 ５Ｗ１Ｈ • 仕事の内容を手早く理解するのに有効 – – – – – – Why（なぜ） Who（だれが） What（何を） When（いつ） Where（どこで） How（どのように） 75 ５Ｗ２Ｈ • ＳＥの業務では、数量を確認することが多い ↓ ５Ｗ１Ｈにもうひとつ「Ｈ」を加える • 新たに加えられた「Ｈ」とは – How much・How many（いくら） 76 ホウレンソウ • 報告（ホウ） – 結論を先に、簡潔明瞭に事実と意見の区別をつ けて報告する • 連絡（レン） – 上司と関係者に迅速かつ明瞭に伝達する • 相談（ソウ） – こじれる前に上司や同僚に相談する 77 タスクの優先順位 • 開発業務が佳境に入ると、ＳＥは複数のタス クを平行して進めることが多くなる ↓ 重要度、難易度、納期などを考慮して、タスク に優先順位をつける 78 ＩＴスキル標準とは（１） • 各種ＩＴ関連サービスの提供に必要とされる能 力を明確化・体系化した指標である • ＩＴスキル標準の構成 – ＩＴサービスを１１職種 / ３８の専門分野として区分 – 実務経験・実績をもとに「達成度指標」を設定 – 必要なスキルを教育・訓練に活用する観点から スキル項目に要素分解 – スキル項目ごとに「スキル成熟度」と「知識項目」 を展開 79 ＩＴスキル標準とは（２） 80 ＩＴスキル標準とは（３） 81 ＩＴスキル標準とは（４） • ＩＴスキル標準の活用例 – 人材育成・調達を行う際の目安となる – 自らのスキル開発をどのように行うべきかを判断 する指標となる 82 1-6 SEの学習方法 Uploadなし 83
© Copyright 2025 ExpyDoc
