試験対策(v2β)

トップ

グローバルIPアドレス(Global IP Address)

インターネットで使われるIPアドレスのこと
IANAで管理されている

エスカレーション

リスクへの対応戦略の一つ
対応策がプロジェクトマネージャの権限を越えると判断した場合や、プロジェクトのスコープ外である場合にとられる

ProxyARP(代理ARP)

何らかの理由でARP応答できない場合に、本来ARP応答を返す機器に代わってルータなどがARP応答をする仕組み

NAT-PT(Network Address Translation Protocol Translation)

IPv4ネットワークをIPv6ネットワークを互いに接続交換する方法の一つ
RFC2766として標準化されている

品質尺度

品質マネジメントの実行プロセスで管理対象として使用される品質特性の解説と、それらをいかに測定するかについて具体的に述べたもの

JIS X 25010:2013(システム及びソフトウェア製品の品質要求及び評価(SQuaRE)―システム及びソフトウェア品質モデル)

品質特性
- 信頼性
  - 中断時又は故障時に、製品又はシステムが直接的に影響を受けたデータを回復し、システムを希望する状態に復元することができる度合い
- 使用性
  - 製品又はシステムが、それらを運用操作しやすく、制御しやすくする属性をもっている度合い
- 保守性
  - 製品若しくはシステムの一つ以上の部分への意図した変更が製品若しくはシステムに与える影響を総合評価すること、欠陥若しくは故障の原因を診断すること、又は修正しなければならない部分を識別することが可能であることについての有効性及び効率性の度合い
- 互換性
  - 二つ以上のシステム、製品又は構成要素が情報を交換し、既に交換された情報を使用することができる度合い
  - 保守作業者の利用時の品質に大きな影響を及ぼす
- 機能適合性
  - 明示された状況下で使用するとき、明示的ニーズ及び暗黙のニーズを満足させる機能を、製品又はシステムが提供する度合い
- 性能効率性
  - 明示された状態(条件)で使用する資源の量に関係する性能の度合いのこと
システム及び/又はソフトウェア製品の品質特製の定義のうち、"性能効率性"の定義
- 明記された状態(条件)で使用する資源の量に関係する性能の度合い
利用時の品質モデル
- 有効性
  - 明示された目標を利用者が達成する上での正確さ及び完全さの度合い
- 効率性
- 満足性
  - 製品又はシステムが明示された利用状況において使用されるとき、利用者ニーズが満足される度合い
  - 実用性
    - 利用の結果及び利用の影響を含め、利用者が把握した目標の達成状況によって得られる利用者の満足の度合い
  - 信用性
  - 爽快性
  - 快適性
- リスク回避性
  - 製品又はシステムが、経済状況、人間の生活又は環境に対する潜在的なリスクを緩和する度合い
  - 経済リスク緩和性
  - 健康・安全リスク緩和性
  - 環境リスク緩和性
- 利用状況網羅性
  - 明示された利用状況及び当初明確に識別されていた状況を超越した状況の両方の状況において、有効性、効率性、リスク回避性及び満足性を伴って製品又はシステムが使用できる度合い
  - 利用状況完全性
  - 柔軟性
製品品質モデル
- システム及びソフトウェア製品の品質特性
  - 機能適合性
    - 明示された条件下で使用するとき、明示的ニーズ及び暗黙のニーズを満足させる機能を、製品又はシステムが提供する度合い
    - 機能完全性
    - 機能正確性
    - 機能適切性
  - 機能効率性
    - 明記された状態(条件)で使用する資源の量に関係する性能の度合い
    - 利用者が特定の目標を達成するための正確さ及び完全さに関連して、使用した資源の度合い
    - 時間効率性
    - 資源効率性
    - 容量満足性
  - 互換性
    - 同じハードウェア環境又はソフトウェア環境を共有する間、製品、システム又は構成要素が他の製品、システム又は構成要素の情報を交換することができる度合い、及び/又はその要求された機能を実行できる度合い
    - 共存性
    - 相互運用性
  - 使用性
    - 明示された利用状況において、有効性、効率性及び満足性をもって明示された目標を達成するために、明示された利用者が製品又はシステムを利用することができる度合い
    - 製品又はシステムが、それらを運用操作しやすく、制御しやすくする属性をもっている度合い
    - 適切度認識性
    - 習得性
    - 運用操作性
    - ユーザエラー防止性
    - ユーザインタフェース快美性
    - アクセシビリティ
  - 信頼性
    - 明示された時間帯で、明示された条件下に、システム・製品又は構成要素が明示された機能を実行する度合い
    - 中断時又は故障時に、製品又はシステムが直接的に影響を受けたデータを回復し、システムを希望する状態に復元することができる度合い
    - 成熟性
    - 可用性
    - 障害許容性(耐故障性)
    - 回復性
  - セキュリティ
    - 人間又は他の製品若しくはシステムが、認められた権限の種類及び水準に応じたデータアクセスの度合いをもてるように、製品又はシステムが情報及びデータを保護する度合い
    - 機密性
    - インテグリティ
    - 否認防止性
    - 責任追跡性
    - 真正性
  - 保守性
    - 意図した保守者によって、製品又はシステムが修正することができる有効性及び効率性の度合い
    - 製品若しくはシステムの一つ以上の部分への意図した変更が製品若しくはシステムに与える影響を総合評価すること、欠陥若しくは故障の原因を診断すること、又は修正しなければならない部分を識別することが可能であることについての有効性及び効率性の度合い
    - モジュール性
    - 再利用性
    - 解析性
    - 修正性
    - 試験性
  - 移植性
    - 一つのハードウェア、ソフトウェ又は他の運用環境若しくは利用環境からその他の環境に、システム、製品又は構成要素を移すことができる有効性及び効率性の度合い
    - 二つ以上のシステム、製品又は構成要素が情報を交換し、既に交換された情報を使用することができる度合い
    - 適応性
    - 設置性
    - 置換性
例
- システム開発のプロジェクトにおいて、リスク識別を効率よく行うための手段として、"JIS X 25010:2013(システム及びソフトウェア製品の品質要求及び評価(SQuaRE)-システム及びソフトウェア品質モデル)"が規定する利用時の品質特を用いてソフトウェアの品質に関するリスクを分析することにした
- 満足性に対するリスクとその評価の事例
  - 操作に習熟していない利用者が、誤った使い方をしたときの対処方法が分からずに困惑し、快適でないと評価される
- 利用状況網羅性
  - システムが稼働する環境に依存した機能を使用しているので、現在の稼働環境とは異なる環境のプラットフォームに展開できず、柔軟でないと評価される
- リスク回避性
  - ソフトウェアパッケージを導入した際に、消耗品が多く必要となって、コストが膨らみ、効率的でないと評価される
- 効率性
  - 導入したソフトウェアパッケージの目新しさだけが目立ち、業務の一部を手作業で補完しなければならず、有効でないと評価される
JIS X 0129-1「ソフトウェア製品の品質―第1部：品質モデル」の後継規格であるJIS X 25010「システム及びソフトウェア製品の品質要求及び評価システム及びソフトウェア品質モデル」で規定されている
利用時の品質特性の定義と品質副特性
- 有効性
  - 明示された目標を利用者が達成する上での正確さ及び完全さの度合い
  - 副特性
    - 有効性
- 効率性
  - 利用者が特定の目標を達成するための正確さ及び完全さに関連して、使用した資源の度合い
  - 副特性
    - 効率性
- 満足性
  - 製品又はシステムが明示された利用状況において使用されるとき、利用者ニーズが満足される度合い
  - 副特性
    - 実用性、信用性、快感性、快適性
- リスク回避性
  - 製品又はシステムが、経済状況、人間の生活又は環境に対する潜在的なリスクを緩和する度合い
  - 副特性
    - 経済リスク緩和性、健康・安全リスク緩和性、環境リスク緩和性
- 利用状況網羅性
  - 明示された利用状況及び当初明確に識別されていた状況を超越した状況の両方の状況において、有効性、効率性、リスク回避性、及び満足性を伴って製品又はシステムが使用できる度合い
  - 副特性
    - 利用状況完全性、柔軟性
製品品質特性の定義と副特性
- 機能適合性
  - 明示された状況下で使用するとき、明示的ニーズ及び暗黙のニーズを満足させる機能を、製品又はシステムが提供する度合い
  - 副特性
    - 機能完全性、機能正確性、機能適切性
- 性能効率性
  - 明記された状態(条件)で使用する資源の量に関係する性能の度合い
  - 副特性
    - 時間効率性、資源効率性、容量満足性
- 互換性
  - 同じハードウェア環境又はソフトウェア環境を共有する間、システム又は構成要素が他の製品、システム又は構成要素の情報を交換することができる度合い、及び/又はその要求された機能を実行することができる度合い
  - 副特性
    - 共存性、相互運用性
- 使用性
  - 明示された利用状況において、有効性、効率性、及び満足性を明示された目標を達成するために、明示された利用者が製品又はシステムを利用することができる度合い
  - 副特性
    - 適切度認識、習得性、運用操作性、ユーザエラー防止性、ユーザインタフェース快美性、アクセシビリティ
- 信頼性
  - 明示された時間帯で、明示された条件下に、システム、製品又は構成要素が明示された機能を実行する度合い
  - 副特性
    - 成熟性、可用性、障害許容性、回復性
- セキュリティ
  - 人間又は他の製品若しくはシステムが、認められた権限の種類及び水準に応じたデータアクセスの度合いをもてるように製品又はシステムが情報及びデータを保護する度合い
  - 副特性
    - 機密性、インテグリティ、否認防止性、責任追跡性
- 保守性
  - 意図した保守者によって、製品又はシステムが修正することができる有効性及び効率性の度合い
  - 副特性
    - モジュール性、再利用性、解析性、修正性、試験性
- 移植性
  - 一つのハードウェア、ソフトウェア又は他の運用環境若しくは利用環境からその他の環境に、システム、製品又は構成要素を移すことができる有効性及び効率性の度合い
  - 副特性
    - 適応性、設置性、置換性

知的財産基本法

知的所有権について定めた法律
知的財産権は、特許権や著作権などの創作意欲の促進を目的とした「知的創造物についての権利と、商標権や商号などの使用者の信用維持を目的とした「営業標識についての権利」に大きく分けられる

リース契約

ハードウェアのファイナンスリース
- 購入にともなう一時的な多額の資金流出はないが、リース料には金利分が上乗せされるのが一般的
天災地変や偶発的な事故によって、リース物件が損傷、滅失した場合の危険負担は、リース会社ではなくユーザが負うことになる

付加価値分析

付加価値比率(売上高対加工高比率)
- (経常利益＋労務費＋人件費＋支払利息割引率－受取利息配当金＋賃借料＋租税公課＋減価償却実施額)÷売上高×100(%)
機械投資効率
- (経常利益＋労務費＋人件費＋支払利息割引率－受取利息配当金＋賃借料＋租税公課＋減価償却実施額)÷設備資産(回)

財務レバレッジ分析

成長性を分析する
財務レバレッジ
- 総資本÷自己資本(倍)

短期支払能力分析

財務体質を分析する
流動比率
- 流動資産÷流動負債×100(%)
- 短期的資金の余裕度、支払い能力
- 1年以内に資金化できる流動資産と返済しなければならない流動負債との比率で、流動資産が流動負債の2倍あれば理想とされる
当座比率
- 当座資産(現金・預金＋受取手形＋売掛金＋有価証券)÷流動負債×100(%)
- 会社の支払い能力、資金の余裕度
- すぐに現金化できる当座資産による支払能力を見る指標
- 高いほど安全性が高い

資本の安定性分析

自己資本比率
- 自己資本÷総資本×100(%)
- 調達資本面での安定性
- 総資本に占める自己資本(株主資本)の割合を示す比率で、会社が調達した資本の安定性を示す
- 値が高いほど良い
負債比率
- 負債÷自己資本×100(%)
- 会社の安定性
- 返済義務のある負債が返済義務のない自己資本でどれだけまかなわれているかを示す指標
- 低いほど安定

調達と運用の適合性分析

財務体質を分析する
固定長期適合率
- 固定資産÷(自己資本＋固定負債)×100(%)
- 設備投資の安定的資金の割合で安全性が分かる
- 固定資産が長期性の資本である自己資本と固定負債の合計でどのくらいまかなわれているのかを示す指標
- 低いほど安全
固定比率
- 固定資産÷自己資本×100(%)
- 長期的な投資に充てる資金で安全性がわかる
- 固定資産と資本との比率で、固定資産の安全性を見る
- 100%以下が理想

キャッシュフロー分析

経営体質を分析する
CFインタレストカバレッジレシオ
- (営業キャッシュフロー＋支払利息割引料＋税金)÷支払利息割引料(倍)
- 利息の支払における安全度
営業CF対有利子負債比率
- 営業キャッシュフロー÷有利子負債×100(%)
営業CF対投資CF比率
- 営業キャッシュフロー÷投資キャッシュフロー(絶対値)×100(%)

回転率・回転期間分析

資本効率の分析
各種資産がどの程度効率的に活用されたのかを分析する
総資本回転率
- 売上高÷総資本(総資産)(回)
- 資本の活用効率
- 企業が総資本をどの程度効率的に活用しているかを見るもので、回転数が高いほど効率的に活用している事になる
- 総資本に対する利益の割合であり、その値が大きいほど収益性が高い
固定資産回転率
- 売上高÷固定資産(回)
有形固定資産回転率
- 売上高÷有形固定資産(回)
売上債権回転期間(割引・裏書譲渡手形含まず)
- (売掛金＋受取手形)÷売上高×365(日)
- 売り上げに対する未回収分の割合
売上債権回転期間(割引・裏書譲渡手形含む)
- (売掛金＋受取手形＋割引手形＋裏書譲渡手形)÷売上高×365(日)
- 売り上げに対する未回収分の割合
受取手形回転期間(割引・裏書譲渡手形含まず)
- 受取手形÷売上高×365(日)
受取手形回転期間(割引・裏書譲渡手形含む)
- (受取手形＋割引手形＋裏書譲渡手形)÷売上高×365(日)
売掛金回転期間
- 売掛金÷売上高×365(日)
棚卸資産回転期間
- 棚卸資産÷売上高×365(日)
- 売上原価と在庫の割合
製品(商品)回転期間
- 製品(商品)÷売上高×365(日)
原材料回転期間
- 原材料÷売上高×365(日)
仕掛品回転期間
- 仕掛品÷売上高×365(日)
買入債務回転期間
- (支払手形＋買掛金)÷売上高×365(日)
買掛金回転期間
- 買掛金÷売上高×365(日)
支払手形回転期間
- 支払手形÷売上高×365(日)

売上高利益率分析

生産や販売活動にどの程度の費用をかけてどの程度の利益を得ることができたかを分析する
売上総利益率(粗利益率)
- 売上総利益÷売上高×100(%)
- 粗利率から商品力や会社の特徴を把握する
- 営業活動での収益性をはかる
売上高営業利益率
- 営業利益÷売上高×100(%)
- 本業の収益性が把握できる
- 営業活動での収益性をはかる
売上高経常利益率
- 経常利益率÷売上高×100(%)
- 資本の活用効率
- 経常的活動から正常収益力が把握できる
- 本業以外の収益(営業外収益)も含めて判断する指標
売上高当期純利益率
- 当期純利益÷売上高×100(%)
売上高対労務費率
- 労務費÷売上高×100(%)
- この値が低いとき、品質・デザインなどが同じであればコスト面での競争力が強い
売上高対販売費・管理費比率
- 販売費・管理費÷売上高×100(%)
- 低いほうが望ましい

ワンタイムパスワード(OTP;One Time Password)

1回に限り利用できる使い捨てのパスワード
パスワードを使い捨てにする方法
1回しか使用されず、有効期限が設定されているため、盗聴されたり推測されたりしても不正使用することができない
認証のたびに毎回異なるパスワードを使用することでセキュリティを確保するが、そのためには生成するパスワードに規則性や連続性がなく(ランダムであること)、ユーザがパスワードを覚えなくてもよいようになっている必要がある
代表例はS/KEYと時刻同期方式
S/KEY
- チャレンジレスポンス方式にしたワンタイムパスワード
- 用語
  - パスフレーズ：パスワードのこと
  - シード：チャレンジレスポンスでいるチャレンジコードのこと、乱数
  - シーケンス番号：ハッシュ演算を行う回数を管理する番号
- シーケンス番号の回数だけハッシュ処理をしてワンタイムパスワードを作る
- サーバはクライアントから送られてきたハッシュ値をもう一度ハッシュして認証するので、認証に使うハッシュ値は送信されない
- クライアント：(シーケンス番号-1)回のハッシュ処理
- サーバ：(シーケンス番号)回ハッシュ処理したものとクライアントから送られてきたものを1回ハッシュしたものとを比較する
時刻同期方式
- チャレンジコードの代わりに時刻を使ってワンタイムパスワードを作成する
- チャレンジのやり取りを省略できるが、クライアントとサーバで時刻を同期させる必要がある
- 時刻からパスワードを作成する装置であるトークンが必要
- トークン
  - 時刻からパスワードを作成する装置
ワンタイムパスワードの実現方法には、チャレンジレスポンス方式と呼ばれるソフトウェアを用いた方式や、セキュリティトークンと呼ばれるワンタイムパスワード生成装置などを使う方法がある
ログインのたびに変化する認証コードのことであり、窃取されても再利用できないので不正アクセスを防ぐ
トークンという装置が自動的に表示する、認証のたびに異なるデータをパスワードとしてサーバに送信する

システムの信頼性特性と評価

RASIS(Reliability,Availability,Serviceability,Integrity,Security)
- コンピュータシステムの高信頼化技術をまとめたもの
- 信頼性(Reliability :リライアビリティ)
  - 故障しにくいこと
  - 要求された機能を、規定された期間実行する能力
  - 数値化の尺度
    - - 故障と故障の間の平均時間
      - 連続して問題なく使える時間を示す
      - 大きいほど故障しないシステム
- 可用性( Availability :アベイラビリティ）
  - 高い稼働率を維持できること
  - コンピュータシステムを必要に応じていつでも使用できる状態に維持する
  - 要求されたサービスを、提供し続ける能力
  - 使いたいときにシステムが使える状態にある割合
  - 数値化の尺度
    - $稼働率=\cfrac{MTBF}{MTBF+MTTR}$
- 保守性( Serviceability :サービサビリティ)
  - 障害が発生した場合に迅速に復旧できること
  - 故障発生時にどのくらいで修理できるかという意味
  - 数値化する尺度
    - - 小さいほどよい
      - 機器のユニット化やホットスワップなどでMTTRを小さくできる
- 保全性( Integrity :インテグリティ)
  - データが矛盾を起こさずに一貫性を保っていること
  - 情報の一貫性を確保する能力
  - データ改ざんや不整合、データが失われたりする度合い
  - プログラムの瑕疵や過負荷時の誤動作、操作ミスによって誘発される
  - 完全性向上の手段
    - アプリケーション監査、データのバックアップ、フールプルーフの導入など
- 機密性( Security :セキュリティ)
  - 機密性が高く、不正アクセスされにくいこと
  - 情報の漏洩、紛失、不正使用などを防止する能力
  - クラッカーの攻撃やテロリズム、自然災害などにシステムがどの程度脅かされているか
- システムの信頼性評価項目であるRASISのうち、Integrity(完全性)を高める方法
  - 排他制御を行うことによって、複数の利用者が同時にデータベースの更新処理を行う場合でも、データの整合性を保証する
信頼性指標と信頼性計算
- 稼働率
  - 運用しているシステムが正しく稼動している比率
  - $稼働率=\cfrac{MTBF}{MTBF+MTTR}=\cfrac{平均故障間隔}{平均故障間隔+平均修理時間}$
  - 直列： $a×b$
  - 並列： $1-(1-a)×(1-b)$
  - MTBFを長くし、MTTRを短くすれば、装置の稼働率は高くなる
  - 稼働率は、可用性(Availability ；アベイラビリティ)を示す尺度となる
  - システムの信頼性を比較する目的で稼働率を測定するのに適切な時期
    - システムの運用を開始した直後に発生したトラブルが解決されて安定してきた時期
  - 2台の処理装置が並列に接続されているシステムにおいて、両方の処理装置が正常に動作しないとシステムは稼働しないとき、両方の処理装置の故障の発生は独立しており、稼働率が等しい場合の、処理装置の稼働率とシステムの稼働率の関係を表すグラフ(破線は処理装置の稼働率とシステムの稼働率が等しい場合を表す)
- 故障率
  - $故障率=1/MTBF$
  - 直列： $1-(1-a)×(1-b)$
  - 並列： $a×b$
- MTBF(Meam Time Between Failure;平均故障間隔)
  - 故障の復旧から次の故障が発生するまでの平均時間
  - 予防保守ではMTBFを長くし、システムの稼働率を高くする保守を行う
  - 2つのシステムの信頼性評価指標の関係：故障発生率が等しければ、MTBFも等しい
- MTTR(Mean Time To Repair;平均修理時間)
  - 修理に必要な時間
  - MTTRはMTBFに対して無視できるほど小さい場合、MTBFが2倍になると故障発生率は1/2になる
  - $全運転時間=MTBF+MTTR$
  - あるシステムにおいて、MTBFとMTTRがどちらも1.5倍になったとき、稼働率は変わらない
- 稼働率の等しい装置を直列や並列に組み合わせたときのシステム全体の稼働率
  - 稼働率をaとしたときの式と、a=0.9の時の値
    - A:1-(1-a)(1-a)(1-a):0.999
    - B:1-(1-a)*(1-a):0.99
    - C:1-(1-a)*(1-a^2):0.981
    - D:{1-(1-a)*(1-a)}^2:0.9639
    - E:1-(1-a^2)*(1-a^2):0.9639
    - F:a{1-(1-a)(1-a)}:0.891
    - G:a^2:0.81
    - H:a^3:0.729
- バスタブ曲線
  - 工業製品の故障発生の傾向を表すものであり、初期故障期間では故障率は高くなるが、その後の偶発故障期間での故障率は低くなり、製品寿命に近づく摩耗故障期間では故障率は高くなる
    - (1)初期故障期：製作課程での欠陥により使用開始とともに故障する時期
    - (2)偶発故障期：ごく稀にしか故障が発生しない安定した時期
    - (3)摩耗故障期：部品などに摩耗や劣化が蓄積してきて故障が増加してくる時期
  - コンピュータシステムのライフサイクルを故障の面から、初期故障期、偶発故障期、摩耗故障期の三つの期間に分割するとき、システムを故障なしに長い時間動かすためには、偶発故障期に定期点検で部品を交換することによって、摩耗故障期を迎える時期を遅れさせることが重要である

システムの信頼性評価指標

システムの稼働率
- MTBFを変えずにMTTRを短くできれば、システムの稼働率は向上する
二つのシステムの信頼性評価指標の関係
- 故障発生率が等しければMTBFも等しい
予防保守によって、システムのMTBFは長くなる
MTBFがx時間、MTTRがy時間のシステムがある。使用条件が代わったので、MTBF、MTTRがともに従来の1.5倍になった。新しい使用条件での稼働率
- 従来と同じ値
コンピュータシステムの信頼性
- システムの予防保守は、MTBFを長くするために行う
MTBFを長くするよりも、MTTRを短くするのに役立つもの
- エラーログ取得機能
MTBFが長くなるもの
- 記憶装置のビット誤り訂正機能
- 命令再試行機能
- 予防保守
システムの信頼性指標に関する記述
- MTTRは、システムの修復に費やす平均時間を示している
- 稼働率：MTBF÷(MTBF + MTTR)
- 故障発生率：MTTR÷(MTBF + MTTR)
システムの信頼性指標に関する記述
- MTBFとMTTRは、稼働率が0.5のときに等しくなる

保守

システムが正常に稼働できる時間を長くし、障害の発生頻度を下げるための定期メンテナンスが中心的な作業
システムの可用性を高める方法には、障害の発生を抑制してMTBF(平均故障間隔)を長くする方法と保守性を固めてMTTR(平均修理時間)を短くする方法がある
保守センタを1か所集中から分散配置に変えると、保守作業のための移動時間の短縮に役立つのでMTTRを短くできる
ハードウェアの保守
- ハードウェアの保守作業の形態は大きく分けて障害の発生を予防する予防保守と、何らかの事象が発生した場合に行う事後保守に分かれる
- 予防保守(計画保守、定期保守)
  - ハードウェアの故障や機能低下、誤作動などが発生することなく、安定的に稼働できるように、設定された保守スケジュールに従って実施する保守形態
  - 予防保守を適切に実施することで、MTBF(平均故障間隔)を伸ばすことが期待できる
- 事後保守
  - 異常音や異臭の発生といった何らかの異常事象が発生した際に、その事象を取り除くために実施する保守形態
  - システム障害からの復旧なども事後保守に含まれることもある
  - 適切な事後保守を短時間で実施することは、MTTRの短縮につながる
長期の保守計画を立て、システムに異常が見られなくても定期的に保守を行う
備した機器を特定することができるように機器の設置場所を台帳に記入しておく
全国に分散しているシステムの保守
- 保守センタを1箇所集中から分散配置に変えることによって、MTTRは短くなる
- 予防保守を実施することでMTBFを長くできる
- 保守センタを1か所集中から分散配置に変えて駆付け時間を短縮することによって、MTTRは短くなる
ソフトウェア/プログラムの保守管理
- 業務プログラムの運用・保守の考え方
  - 業務プログラムに精通することは運用管理を容易にするが、全ての担当者がそうなることは困難なので、運用マニュアルなどを整備しておく必要がある
- 保守作業の生産性に影響しないもの
  - 運用中に発生するソフトウェアの障害件数
- 保守作業の生産性に影響するもの
  - ソフトウェアの検証を行うときの難易度
  - ソフトウェアを変更するときの難易度
  - プログラムやドキュメントがどの程度理解しやすいかの度合い
- 影響度の調査を効率よく行うためには、リポジトリなどのツールを使用する
- 本稼働中のライブラリのプログラムは直接修正せず、テスト用のライブラリにコピーしてから修正作業を行う
- 障害を引き起こす可能性のあるプログラムを見つけ、あらかじめ修正する
- ソフトウェアの保守作業の効率向上施策
  - コーディング規約に準拠したプログラムの作成
- ソフトウェア保守
  - 稼働中のソフトウェアに対して、発見された障害の是正や、新しい要件に対応するための機能拡張を行う活動
- アプリケーションシステムの更新作業
  - アプリケーションの変更内容は、障害原因などを究明する際にも役立つので必ず記録する
- アプリケーションの保守
  - 適切
    - 保守作業が完了しないまま放置されるのを防ぐためにも、保守完了を記録する
  - 不適切
    - テスト終了後は速やかに本稼働中のライブラリにプログラウを登録し、保守承認者に報告する
    - 変更内容が簡単であると判断できるときは、本稼働用のライブラリを直接更新する
    - 保守作業は、保守作業担当者によるテストが終了した時点で完了とする
データベースシステムと業務アプリケーションが稼動しているサーバのOSのバージョンアップの案内が届いた場合、バージョンアップを行うか否かの判断
- バージョンアップされたOSでのデータベースシステムの稼動を確認した後に、業務アプリケーションの稼動を確認し、問題がなければバージョンアップをする
システムのハードウェア保守
- 予防保守は、故障が発生する前に対策を実施する
- 異常が発生していなくても、計画的に保守点検を行う
- ハードウェアの保守点検及び修理作業を実施するときに、運用管理者が実施すべき、事前又は事後の確認
  - 臨時保守の場合、事前に保守作業者が障害の発生状況を確認したことを確認し、事後に障害原因や作業実施結果を確認する
印刷されたマニュアルをオンラインマニュアルに切替えることによって改善が期待できる問題
- アプリケーションのバージョンとマニュアルのバージョンが一致しない問題
品質の定量評価の指標のうち、ソフトウェアの保守性の評価指標となるもの
- 修正時間の合計　÷　修正件数
- (適正規模の基準を満たすプログラムの数)÷(プログラムの総数)
変更管理に該当する作業
- ソフトウェアベンダから提供されたセキュリティパッチの内容を確認し、自社システムに適用する場合の影響を評価する
ある製品の開発に使用された組込みシステムの開発環境における維持管理
- 開発環境は、使用頻度に関係なく、定期的に動作確認などを行って維持管理すべきである
完全化保守
- 問題は発生していないが、プログラムの仕様書と現状のソースコードの不整合を解消するために、リバースエンジニアリングの手法を使って仕様書を作成し直す
是正保守
- ソフトウェア製品の引き渡し後に発見された問題を訂正するために行う修正
適応保守
- ソフトウェアの引き渡し後に、変化した環境において、ソフトウェア製品を使用できるように行う修正
- オペレーティングシステムの更新によって、既存のアプリケーションソフトウェアが正常に動作しなくなることが判明したので、正常に動作するように修正した
予防保守
- 引き渡し後のソフトウェア製品の潜在的な障害が運用障害になる前に発見し、是正を行うための修正
MTBFを長くする対応
- 記憶装置のビット誤り訂正機能
- 命令再試行機能
- 予防保守

ソフトウェア保守での修正依頼の保守のタイプによる分類

保守を行う時期	修正依頼の分類
	訂正	改良
潜在的な障害が顕在化する前	予防保守	完全化保守
問題が発見されたとき	是正保守	―
環境の変化に合わせるとき	―	適応保守

トラフィック理論

呼
- 接続要求
- 要求することを発呼、受けることを着呼という
呼量
- 通信量
- その回線を使った時間
- 呼量=呼数×(平均回線保留時間/単位時間)
アーラン
- 呼量を表す単位
- 単位時間当たりの通話量
- ある回線で一定時間に伝送できる最大量が1アーラン

インターネットの国際化ドメイン名(IDN:Internationalized Domain Name)

IDNでは、通信する際に、感じやアラビア文字などのドメイン名を、ASCII文字だけからなる文字列のドメイン名に一定の規則で変換する

労働者派遣法(労働者派遣事業の適正な運営の確保および派遣労働者の就業条件の整備等に関する法律)

業務内容に制限がある派遣要員個人の能力に期待する契約であるが、要員をあらかじめ指名することはできない
派遣要員に関して知ることができるのは、氏名、性別、年齢のみ
派遣要員には、原則として完成責任も瑕疵担保責任もない
委託側にも労働者派遣法に伴う義務が多く発生する
原則的には派遣要員を派遣した側には著作権がない
契約範囲外の業務を指示してはいけない
自己の雇用する労働者を、契約の相手方の指揮命令を受けて、契約の相手方の労働に従事させる契約
労働者派遣における派遣元の責任
- 派遣先での時間外労働に関する法令上の届出
派遣された労働者を別会社へ再派遣することは認められていない
派遣労働者の就業場所の変更を伴う配置転換は、派遣先企業に認められていない
労働者派遣事業を適正に行うとともに、立場の弱い派遣労働者を保護する法律
労働者派遣事業を適切に行うことを定めた法律
労働者派遣とは、派遣元が雇用する労働者を、その雇用関係を維持したまま派遣先の指揮命令を受け入れて派遣先の労働に従事させること
派遣期間は最長3年
完成責任、瑕疵担保責任は課せられない
派遣先責任者の義務
- 労働者派遣法等の関連法規の規定、労働者派遣契約の内容、派遣元事業主からの通知内容を、派遣労働者を指揮命令する立場の者やその他関係者に周知させる
- 派遣先管理台帳を作成して、記録・保存する
- 派遣労働者から受けた苦情に適切に対応する
- 派遣元事業主との連絡調整を行う
労働者派遣法では、派遣先が省令の定めに従って派遣先責任者を任命し、次の事項を行うことを義務付けている
- 労働者派遣法等の関連法規の規定、労働者派遣契約の内容、派遣元からの通知内容を、派遣労働者を指揮する立場の者やその他関係者に周知徹底する
- 派遣先管理台帳を作成して記録し、3年間保存する
- 派遣労働者からの苦情の申し出を受け付け、適切に対応する
- 派遣元事業主との連絡調整を行う
2015年に改正され、全ての労働者派遣事業が許可制となり、全ての業務の派遣期間の限度が原則3年となった
派遣期間
- 派遣要員の１回の派遣期間には限度があり、延長は再契約が必要
- 労働者派遣事業法で認められた特殊な技能を要する業務であれば、同一人の派遣を3年を越えて行うことができる
指揮命令
- 指揮命令は委託者側にある
- 労働者の就労に関して、雇用関係とは別の指揮命令系統に従うことになる
- 派遣労働者への指揮命令権は派遣先企業にある
派遣先の責任として定められているもの
- 派遣先企業には派遣労働者からの苦情処理に当たる義務がある
- 派遣契約内容を派遣労働者を指揮命令する者やその他の関係者に周知すること
- 派遣労働者の受入れに関する記述のうち、派遣先責任者の役割、立場
- 派遣先責任者は、派遣労働者に直接指揮命令する者に対して、労働者派遣法などの関連法規の規定、労働者派遣契約の内容、派遣元からの通知などを周知しなければならない
契約関係
労働者派遣法に適合するもの
- グループウェアのメンテナンスを行うために、自社社員と同様に作業を直接指示した
- システム開発期間が長期になるので、派遣されるプログラマの派遣期間を3年とする契約を結ぶ
- 労働者派遣法で認められた特殊な技能を要する業務であれば、同一人の派遣を3年を超えて行うことができる
労働者派遣法に適合しないもの
- 派遣契約の内容にかかわらず合理的な理由がある場合には、派遣先の作業指示者の判断で派遣労働者に残業を命じることができる
- 派遣先の事業所に属する従業員はだれでも、派遣労働者に業務命令を行うことができる
- 派遣者労働法で認められた業務であれば、派遣先の判断で派遣労働者の業務内容を変更できる
- 営業情報システムのメンテナンスを担当させている派遣社員から、直接に有給休暇の申請があり、業務に差し障りがないと判断して、承認した
- 生産管理システムへのデータ入力を指示したところ、入力ミスによって、欠陥製品ができたので、派遣元企業に対して製造物責任を追及した
- 販売管理システムのデータ処理が提示に終了しなかったので、自社社員と同様の残業を行うよう指示した
- 派遣期間中は作業負荷がかかることが予想されるので、20代男性の派遣を依頼する
- 派遣されるプログラマ候補者の業務経歴書を提出させ、書類選考によって面接の対象となる候補者を絞り込む
- 労働管理実務に詳しい担当者がいないので、責任者を置かず派遣社員からの苦情処理を派遣元会社に依頼する
事例
- プロジェクトマネージャのP氏は、A社から受託予定のソフトウェア開発を行うために、X社から一時的な要員派遣を受けることを検討しているが、このとき、派遣者への業務指示など、派遣に伴う各種業務をP氏が直接行うことをX社に伝えることは労働者派遣法に照らして適切である
- A社で雇用しているオペレータのQ氏を、B社に派遣することになった場合に、Q氏は、B社の定められた指揮命令者の下で労働に従事する事は労働者派遣法で定められている
- [A社(発注元)]←請負契約→[B社]←派遣契約→[C社]
  - 上記のような契約でA社、B社、C社の開発要員がプロジェクトチームを組んでソフト開発業務を実施するときB社の担当者がC社の要員に業務の割り振りや作業スケジュールの指示を行う事は適法
- A社では、自社で働いている派遣会社B社からの派遣社員の就業管理用に、B社のWeb版の派遣社員就業管理システムをインターネット経由で使用している時、このシステムを用いた当該派遣社員の日常の就業時間の承認者は派遣先A社の業務責任者である
大規模なシステム開発を受注したA社では、不足する開発要員を派遣事業者であるB社からの労働者派遣によって補うことにした。A社の行為のうち、労働者派遣法に照らして適切なもの
- システム開発が長期間になることが予想されるので、開発要員の派遣期間を3年とする契約を結ぶ
派遣先の対応として適切なもの、ここで、派遣労働者は期間制限の例外に当たらないものとする
- 工場で3年間働いていた派遣労働者を、今年から派遣を受け入れ始めた本社で正社員として受け入れた
派遣元事業主の講ずべき措置等として定められているもの
- 労働者の教育訓練の機会の確保など、福祉の増進
派遣先事業主の講ずべき措置等として定められているもの
- 派遣先管理台帳の作成
- 派遣先責任者の選任
- 派遣労働者を指揮命令する者やその他関係者への派遣契約の周知

労働者派遣法

例
- A社は、A社で使うソフトウェアの開発作業をB社に実施させる契約を、B社と締結した A社監督者が、B社の雇用する労働者に、業務遂行に関する指示を行い、A社の開発作業を行わせる
労働者派遣事業における派遣労働者の労働時間、休日、休暇などの具体的な就業に関する枠組み設定について適切/不適切
- 適切
  - 派遣元と派遣労働者との間で設定し、派遣先はその範囲内で派遣労働者を指揮命令の下に労働させなければならない
- 不適切
  - 派遣元と派遣先との間で設定し、派遣労働者はその条件に従わなければならない
  - 派遣先が設定し、それを派遣元と派遣労働者に通知することになっている
  - 派遣先と派遣労働者との間で設定し、両者の間の労働契約に盛り込む必要がある
労働者派遣における派遣元の責任
- 派遣先での時間外労働に関する法令上の届け出
労働者派遣における派遣先の責任
- 派遣労働者に指示する業務の遂行状況の管理
- 派遣労働者に指示する業務の遂行状況の管理
- 派遣労働者の日々の就業で必要な職場環境の整備
大規模なシステム開発を受注したA社では、不足する開発要員を派遣事業者であるB社からの労働者派遣によって補うことにした
- A社の行為のうち、労働者派遣法に照らして適切なもの
  - システム開発が長期間となることが予想されるので、開発要員の派遣期間を3年とする契約を結ぶ
- 不適切なもの
  - 派遣候補者の履歴書及び業務経歴書の提出をB社に求め，書類選考を行い，面接対象者を絞り込む
  - 派遣された要員が大きな作業負担を負うことが見込まれるので，B'社に20代男性の派遣を求める
  - 派遣労働者がA社の指揮命令に対して申し立てた苦情に自社で対応せず，その処理をB社に任せる

著作権法

著作権の保護を対象としている法律
著作権
- 著作物ならびに著作者の権利およびこれに隣接する権利
著作物
- 思想又は感情を文章や音、絵などで創造的に表現したもの
- 著作権法における著作物に関する記述
  - 著作権法では、著作物を「思想または感情を創作的に表現したものであって、文芸、学術、または音楽の範囲に属するもも」と規定している。著作物の例としては、小説、脚本、論文などの言語の著作物、音楽の著作物、舞踊または無言劇の著作物、映画の著作物、プログラムの著作物がある
- 文芸、学術、美術又は音楽の範囲に属する著作物を、その著作者が独占的・排他的に支配して利益を受ける権利
- 二次的著作物
  - 著作物の翻訳、編曲、変形、脚色、映画化などにより創作されたもの
  - 二次的著作物を他人が創作する場合には、原著作物の著作者の許諾が必要である
- データベース著作物
  - 論文、数値、図形などの情報の集合物に対し、電子計算機を用いて検索できるように体系的に構成されたもので、その情報の選択または体系的構成によって創作性を有するもの
- 編集著作物
  - 新聞や百科事典のように、その素材の選択または配列によって創作性を有するもの
- 著作権法の保護の対象となる著作物
  - インターネットで公開されたフリーソフトウェア
  - ソフトウェアの操作マニュアル
  - データベース
  - コンパイラのプログラム
- 著作権法の保護の対象とならない著作物
  - 国または地方公共団体の機関が発する告示、訓令、通達その他これに類するもの
  - プログラム言語や規約
  - アルゴリズム
著作権の存続期間
- 著作権の存続期間は、著作物の創作の時に始まり、著作権法に別段の定めがある場合を除いて、著作者の死後50年を経過するまでの間は存続する。また、共同著作物の場合には、最終に死亡した著作者の死後50年を経過するまでの間は存続する。法人その他団体が著作の名義を有する著作物の著作権は、原則として、その著作物の公表後50年は存続する。一方、映画の著作物の場合は、原則として、映画の公表後70年は存続する。
- 著作者は、諸作物を創作したときに「著作権者」となり、権利取得のために特別な方式を必要としない。なお、著作権は譲渡や相続が可能であるが、著作人格権は一身専属的な権利であるため、他人に譲渡できないし、相続の対象にもならない
- 著作物を創作した時点で権利が発生する
- 個人の著作物の保護機関化終了するのは、著作者の死後50年
- 法人が作成し、公開、販売したソフトウェアの著作権の権利期間は公開から50年
権利の発生のために申請や登録の手続を必要としない
日本国内においては、著作物に著作権表示が明記されていない場合でも、無断で複製して配布したときには著作権の侵害になる
特許権の場合、独自の発明の実施であっても、先に権利を取得した人がいれば権利の侵害になるが、著作権では、独自の創作であれば、結果として同じものを創作しても権利の侵害にはならない
著作権者の許諾なしに公衆に情報を送信する行為は、サーバに情報を蓄積するか否かにかかわらず権利侵害となる
創作された表現を保護する権利であり、著作物を創作した時点で成立し、著作者の死後50年を経過するまでの間存続する
映画の著作物の保護期間は公表後70年となっている
ソフトウェア／プログラムの著作権
- 特徴
  - プログラム中のアイデアやアルゴリズムは保護しないが、プログラムのコード化された表現を保護する
  - 機能を実現するために必要なソフトウェアとして作成されたプログラムは保護の対象となる
  - ソフトウェアには、著作権の移転や権利の設定にかかわる登録制度が設けられている
  - ソースプログラムとオブジェクトプログラムの両方とも著作権法によって保護される
  - インターネットで公開されたフリーソフトウェア、ソフトウェアの操作マニュアル、データベースは保護の対象
  - 著作物を作成するために用いるプログラム言語や規約(アルゴリズム)は、著作権法による保護の対象外
  - 使用許諾契約の場合、使用者は著作権を取得できない
- 著作権の帰属
  - 特に取り決めのない場合、労働者派遣契約によって派遣された派遣労働者が派遣先企業の指示の下に開発したプログラムの著作権の帰属先は派遣先企業にある
  - 開発されたプログラムの著作権の帰属に関する規定が契約に定められていないとき、著作権の原始的な帰属は請負の場合は発注先に、派遣の場合は派遣先に帰属する
  - A社は、B社と著作物の権利に関する特段の取決めをせず、A社の要求仕様に基づいて、販売管理システムのプログラム作成をB社に依頼した場合のプログラム著作権の原始的帰属
    - B社に帰属する
  - プログラム開発における職務上の著作について、就業規則などに特段の取決めがない限り、権利は法人に帰属する
  - 法人の発意に基づき、その法人の従業員が職務上作成するプログラムの著作権は、別段の定めがない限り、その法人が著作者となる
  - 改変が認められているフリーソフトウェアを改変した場合、改変部分の著作権は改変者の著作物となる
- 適法の例
  - 他人の著作物であるプログラムを購入し、自社のパソコンでより効果的に利用するために(パフォーマンスを上げるために)改変を加える事
  - 処理速度の向上など、購入したプログラムを効果的に利用するための改変
  - 購入したソフトウェアをバックアップコピーする
  - 著作者の了解を得ないで、購入したCDの楽曲を自分のPCにコピーし、PCで毎日聴いている
  - インターネットの掲示板で議論されていたアイディアを素にプログラムを作成した
  - 学生のころに自分が作成したプログラムを使い、会社業務の作業効率を向上させるためのプログラムを作成した
  - 購入した書籍に掲載されていた流れ図を基にプログラムを作成した
  - A社が開発したソフトウェアの公開済みプロトコルに基づいて、A社が販売しているソフトウェアと同等の機能を持つソフトウェアを独自に開発して販売した
  - 他人のソフトェアを正当な手段で入手し、逆コンパイルを行った
  - 複製及び改変する権利が付与されたソース契約の締結によって、許諾されたソフトウェアを改造して製品に組込み、ソース契約の範囲内で製品を販売した
- 違法の例(著作権侵害)
  - 使用許諾を受けている購入プログラムを、著作者に無断でコピーし、子会社に使用させた場合、著作権法に抵触するおそれがある
  - 海賊版を複製したプログラムと事前に知りながら、業務で使用した
  - 業務処理用に購入したプログラムを複製し、社内教育用として各部門に配布した
  - 職務著作のプログラムを、作成した担当者が独断で複製し協力会社に貸与した
  - 違法な複製を防止する技術的保護手段を解除しコピーする行為やそのためのツールを製造・販売・配布する行為
  - 著作者の承諾を得ないで雑誌に掲載されていた漫画を記録媒体に記憶させて、インターネット上に公開し、ファイル共有ソフトによって、不特定多数の者に自動公衆送信できるようにした場合
  - ある自社製品のパンフレットで使用しているスポーツ選手の写真を、撮影者に無断で、ほかの自社製品のパンフレットに使用する
  - 新聞の写真をスキャナで取り込んで、提案書に記載する
  - ユーザ団体の研究会のように限られた対象者に対し、雑誌の記事をコピーして配布する
  - インターネットからダウンロードしたHTMLのソースを流用して、別のWebページを作成した
  - ソフトウェアハウスと使用許諾契約を締結し、契約上は複製権の許諾は受けていないが、使用許諾を受けたソフトウェアにはプロテクトがかけられていたので、そのプロテクトを外し、バックアップのために複製した
webページの著作権
- 特定の分野ごとにWeb ページのURLを収集し、簡単なコメントをつけたリンク集は、著作権法で保護される
- マルチメディアの素材集(画像データや効果音など)をソフトウェア販売店で購入し、自社の Web ページ作成時に利用しても、使用許諾の範囲内で使用していれば、著作権法違反にはならない
- Webページを作成する際、著作権者に確認せずに行った著作物利用
  - 適切なもの
    - 車の販売台数を説明するために、通商白書の統計データをそのまま使って図表化し、Webページに活用した
    - 経済白書の記載内容を説明の材料として、出所を明示してWebページに転載する
  - 不適切なもの
    - カーテン記事のカタログに掲載された図柄が、著名デザイナ制作のもので、背景に適切だったので、スキャナで取り込んで、色を変更して活用した
    - 最新情報を提供するために、新聞の写真をスキャナで取り込んで活用した
    - 雑誌のイラストを加工して、Webページ上の自社広告に活用した
保護の対象
- 表現された著作物
- プログラム、データベース、ホームページ
保護の対象外
- アイデア、ノウハウ、アルゴリズム(解法)、プログラム言語、規約など
権利期間
- 個人帰属
  - 作成した時点で自動的に発生する
  - 実名個人は死後50年間、無記名個人は公表後50年間
- 法人帰属
  - 公表した時点から50年間
帰属の例(プログラムの作成)
- 従業員が職務上作成：原則として法人
- 請負契約：原則として請負側
- 派遣契約：派遣先
- 共同開発：共同著作物となり、原則として共同開発者双方
著作財産権
- 契約書に記載があれば譲渡できる
- 複製権、上演権などがある
著作者人格権
- 著作者人格権は著作者に専属し、他者には譲渡できない
- 契約書に記載があっても譲渡できない
- 公表権、氏名表示権、同一性保持権の3つがある
著作隣接権
プログラム開発において、法人の発意に基づく法人名義の著作物について、著作権法で規定されているもの
- 就業規則などに特段の取り決めがない限り、権利は法人に帰属する
著作権法によるソフトウェアの保護範囲
- ソースプログラムとオブジェクトプログラムの両方とも著作権法によって保護される
著作権法による保護の対象となるもの
- ソースプログラムそのもの
組込み機器用のソフトウェアを開発委託する契約書に開発成果物の著作権の帰属先が記載されていない場合、委託元であるソフトウェア発注者に発生するおそれがある問題はどれか、ここで、ソフトウェアは委託先が全て自主開発するものとする
- 開発成果物を、委託元で開発する別のソフトウェアに適用できなくなる
Webページの著作権
- 特定の分野ごとにWebページのURLを収集し、独自の解釈を付けたリンク集は、著作権法で保護される
プログラムの著作物について、著作権法上、適法である行為
- 処理速度を向上させるために、購入したプログラムを改変した
保護の対象となり得ないもの
- プログラム言語や規約
保護の対象となるもの
- インターネットで公開されたフリーソフトウェア
- ソフトウェアの操作マニュアル
- データベース
- ソースプログラムとオブジェクトプログラム
- 特定の分野ごとにWebページのURLを収集し、独自の解釈を付けたリンク集
プログラムの著作物において、著作権法上、適法である行為
- 処理速度を向上させるために、購入したプログラムを改変した
自社開発したソフトウェアの他社への使用許諾
- 使用許諾の契約は特許法ではなく、著作権法の範囲になるため、特許で保護された技術を使っていないソフトウェアであっても、使用許諾することは可能
A社が著作権を保有しているプログラムで実現している機能と、B社のプログラムが同じ機能をもつとき、A社に対するB社の著作権侵害に関する記述のうち、適切なもの
- A社のソースコードを無断で使用していると、著作権の存続期間内は、著作権侵害となる
公衆への提供などが行われた他人の著作物をAIの学習データとして利用する行為に関して、著作権法に照らして適切なものただし、著作物の利用は、AIによる情報解析の範囲で行われ、著作物に表現された思想又は感情を享受することを目的とするものではないまた、日本国内で作成された著作物を日本国内で利用する場合であり、利用者と著作権者との間で特段の契約は存在しないものとする
- 著作権者の利益を不当に害さない場合、その必要と認められる限度において、商業利用であるか否かを問わず、著作権者の許諾なくAIの学習に利用できる
企業が請負で受託して開発したか、又は派遣契約によって派遣された社員が開発したプログラムの著作権の帰属に関して契約に定めがないとき、著作権の原始的な帰属
- 請負の場合は発注先に帰属し、派遣の場合は派遣先に帰属する
企業間で、商用目的で締結されたソフトウェアの開発請負契約書に著作権の帰属が記載されていない場合、著作権の帰属先
- 請負人に帰属する
著作権法及び関連法令によれば、職務著作の要件のうち、プログラムの著作物の場合は満たす必要がなく、プログラム以外の著作物の場合は満たす必要があるもの
- 法人等が自己の著作の名義の下に公表していること
著作権法で保護されるもの
- コンパイラのプログラム
職務著作の要件のうち、プログラムの著作物の場合は満たす必要がなく、プログラム以外の著作物の場合は必要なもの
- 法人等が自己の著作の名義の下に公表していること
複製権
- 例
  - A社は、新規に量産販売する組込みシステムにB社が開発し市販しているOSを改造することなく搭載しようとしているとき、A社がB社から許諾を受けなければならないもの

暗号化

暗号に関するデータのうち、次に示す処理で出力可能なもの
- 処理
  1. カウンタを初期化する 2.その時点に得た時刻データを共通鍵で暗号化する 3.カウンタの値と2.の結果のXORをとり、更に共通鍵で暗号化する 4.3.の結果を出力する 5.3.の結果と2.の結果のXORをとり、さらに共通鍵で暗号化する 6.5.の結果をカウンタの新しい値とする 7.4.の出力について、必要とする文の数を得るまで2.～6.を繰り返す
- 擬似乱数
カウンタモード
- 暗号化したいメッセージとカウンタと呼ばれる値を暗号化した結果とのXORを暗号文とするモード

ルータ(router)

2つ以上のネットワークを接続するネットワーク機器
ネットワーク同士を接続する機器
2つ以上のネットワークインタフェースを備えており、データを中継する
ネットワーク層の接続機器
ネットワークとネットワークを結ぶ通信機器
IPアドレスによって通信を制御する
MACアドレスでの通信制御も可能
ルータの扱うネットワークは、ブロードキャストドメイン(IPブロードキャストが届く範囲)
経路制御
- IPアドレスを参照して、宛て先が送信元と同じ方向のネットワークにあるか判断し、ある場合は転送しない、ない場合は転送する
- 転送できるネットワークが複数ある場合は、距離やコストなどの経路情報をもとに最適な経路へ送り出す
- ルーティングテーブル(経路制御表)
  - 経路情報を保存するテーブルのこと
  - ルーティングプロトコルを使うなどして経路情報を収集し、ルーティングテーブルを更新する
  - パケットのあて先がルーティングテーブルにない場合、あらかじめ決めておいたルータにパケットを転送する
  - このルータをデフォルトゲートウェイという
インターネット接続用ルータのNAT機能
- プライベートIPアドレスとグローバルIPアドレスを相互に変換する機能
LAN間接続装置
伝送媒体やアクセス制御方式が異なるネットワークの接続が可能であり、送信データのIPアドレスを識別し、データの転送経路を決定する
IPアドレスを解析することによって、データを中継するか破棄するかを判断する
受信したパケットを、ネットワーク層で分割(フラグメンテーション)する
OSI基本参照モデルにおける第1～3層だけのプロトコルを変換する
IPアドレスを基にしてフレームを中継する
ルータがパケットの経路決定に用いる情報
- 宛先IPアドレス
ルータで接続された二つのセグメント間でのコリジョンの伝搬と宛先MACアドレスの全てのビットが1であるブロードキャストフレームの中継の組合せ
- コリジョンの伝搬：伝搬しない
- ブロードキャストフレームの中継：中継しない
OSI参照モデルの第3層(ネットワーク層)情報を基に中継を行う装置
IPパケットの転送
ルーティングプロトコルの実行
IPパケットのフィルタリング
LAN同士やLANとWANなど複数のLANをOSI基本参照モデルの第3層(ネットワーク層)で接続し、パケットの中継処理を行う
伝送媒体やアクセス制御方式の異なるネットワークの接続が可能であり、送信データのIPアドレスを識別し、データの伝送経路を決定する
データの通信経路を制御し、ネットワーク間を中継する
二つのLANセグメントを接続する
上位層での中継機能は持たない
インターネット接続用ルータのNAT機能
- プライベートIPアドレスとグローバルIPアドレスを相互に変換する
ネットワーク層での接続を行い、広域網を介してLAN間を接続する場合などに使われる
中継する必要のないデータを識別し、通過を抑止することができる
IPネットワークにおけるルータ
IPアドレスを利用してパケット転送の経路を選択する
ルータがパケットの経路決定に用いる情報
- 宛先IPアドレス
ルータで接続された二つのセグメント間でのコリジョンの伝搬とブロードキャストフレームの中継
- コリジョンの伝搬：伝搬しない
- ブロードキャストフレームの中継：中継しない

ベイズ統計

事前分布・事後分布といった確率に関する考え方に基づいて体系されたものであり、機械学習、ディープラーニング、迷惑メールフィルタなどに利用されている統計理論

プロジェクトマネジメント

スコープコントロール
- 連携する計画であった外部システムのリリースが延期になったので、この外部システムとの連携に関わる作業は別プロジェクトで実施することにした
スケジュールコントロール
- 開発ツールの新機能の教育が不十分とわかったので、開発ツールの教育機関を2日間延長した
コストコントロール
- 要件定義完了時に再見積もりをしたところ、当初見積もった開発コストを超過することが判明したので、追加予算を確保した
リソースコントロール
- 割り当てたテスト担当者が期待した成果を出せなかったので、経験豊富なテスト担当者と交代した
プロジェクト資源マネジメント
- プロジェクトチームの育成プロセス
  - 目的
    - 継続的にプロジェクトチームのメンバのパフォーマンス及び相互関係を改善する
プロジェクト憲章
- プロジェクトを正式に承認する文書であり、プロジェクトマネージャを特定して適切な責任と権限を明確にし、ビジネスニーズ、目標、期待される結果などを明確にした文書
業務計画書
- 組織のビジョン、目標及びビジネスニーズとともに、プロジェクトが提供するプロダクト、サービス、又は所産の特定を明確にした文書
プロジェクト計画書
- どのようにプロジェクトを実施し、監視し、コントトールするかを定めるために、プロジェクトを実施するためのベースライン、並びにプロジェクトの実行、コントロール、及び終結する方法を明確にした文書
プロジェクトスコープ記述書
- プロジェクトの最終状態を定義することによって、プロジェクトの目的、成果物、要求事項及び境界を含むプロジェクトスコープを明確にした文書
システムの開発に使用するプログラム言語や開発手法を早期に検討することによって、開発リスクを低減し、投資効果の最大化を図る
スコープ
- 目的1をもつプロセスと目的2をもつプロセスとが含まれる対象群
  - 目的目的1：プロジェクトの目標、成果物、要求事項及び境界を明確にする目的2：プロジェクトの目標や成果物などの変更によって生じる、プロジェクトの機会となる影響を最大化し、脅威となる影響を最小化する
リスク対応
- 転嫁
  - 損害の発生に備えて、損害賠償保険を契約する
スコープの管理の活動
- 連携する計画であった外部システムのリリースが延期になったので、この外部システムとの連携にかかわる作業は別プロジェクトで実施することにした
- プロジェクトスコープのクリープ
  - 時間、コスト及び資源の調整が行われず、コントロールされていないプロジェクトスコープの変更
リソース(資源)マネジメントの活動
- 開発ツールの新機能の教育が不十分と分かったので、開発ツールの教育機関を2日間延長した
- 割り当てたテスト担当者が期待した成果を出せなかったので、経験豊富なテスト担当者と交代した
コストマネジメントの活動
- 要件定義が終了した時点で再見積もりをしたところ、当初見積もった開発コストを超過することが判明したので、追加予算を確保した
コンティンジェンシー計画を作成するプロセス
- リスクへの対応

プロジェクトマネジメント

立上げ
- 情報化戦略、中長期戦略に基づいて個別システム計画(プロジェクト計画)が策定される
- プロジェクトの立上げ
  - プロジェクトを立ち上げるときにプロジェクト目標の明確化を最初に行う
  - スポンサーがプロジェクトを正式に承認し、開始させること
  - プロジェクトマネージャはプロジェクト立ち上げ時に任命される
- プロジェクト概要書
  - 立ち上げ時にプロジェクトマネージャが作成し、スポンサーが承認する
- プロジェクト憲章作成
  - プロジェクト立上げ時に、プロジェクトの活動を総合的に管理及び調整するために定める
  - プロジェクトの立ち上げプロセスで作成する
  - プロジェクトを認知、承認するために、その要求事項、目的や妥当性、全体スケジュール、任命されたプロジェクトマネージャと権限レベルなどを記した文章
  - 作成目的
    - プロジェクトを公式に認可させるために発行する
  - 盛り込むべき内容
    - プロジェクトの目的
- キックオフミーティング
  - プロジェクトが正式に発足したことをステークホルダに発表する
  - プロジェクト概要書の内容が説明される

計画

スコープ定義
- スコープ
  - プロジェクトにおいて作成する成果物とその成果物を生み出すために必要な作業の範囲
- プロジェクトスコープ記述書
  - プロジェクトの要素成果物と、これらの要素成果物を生成するために必要な作業について記述する
  - プロジェクト概要書に記載されている内容を掘り下げて明確にする
  - プロジェクトのスコープを定義するために、プロジェクトの目的や成果物、プロジェクトの境界、成果物受入規準、承認要件など
- スコープ検証
- スコープコントロール
プロジェクト計画書の作成
- プロジェクト概要書とWBSを詳細化し、プロジェクトのあるべき姿を示したもの
- プロジェクト管理の対象について計画する
- プロジェクトの実行、監視コントロール、終結方法などを規定するために、スケジュールマネジメント計画書やリスクマネジメント計画書など、各計画プロセスのアプトプットの集合体として作成した文書
進捗計画 (スケジュール計画)
- 進捗管理のためのスケジュールを計画するために日程計画を作成する
- プロジェクト実施手順書
  - プロジェクト目標を達成し、必要な要素成果物を生成するために、プロジェクトが実行する作業を階層構造で記した文書
- WBSを作成し、利用する
- 大・中・小日程計画の作成
  - 大日程計画
    - プロジェクト全体の日程の計画であり、重要な管理項目(設計・開発・テスト・移行・本番稼動)について比較的粗い時間の単位で策定するもの
    - 最小の計画期間
      - 3ヶ月または6ヶ月程度
    - WBSの上位層を見ながら作成する
    - 全体スケジュール、マスタースケジュールとも呼ばれる
  - 中日程計画
    - 大日程計画に基づいて作成する日程の計画であり、サブシステム別、工程別に策定する
    - 最小の計画期間：1ヶ月程度
    - WBSの中位層を見ながら作成する
    - 大きなシステムの場合、サブシステムごとに作成されることもある
    - フェーズドスケジュールとも呼ばれる
    - 作業項目だけでなく担当チームを表記することもある
    - 中日程計画では納期、予算などの制約条件を確認し、作業量や必要工数を算出し、各月に作業項目を割り当てていく
  - 小日程計画
    - 中日程計画に基づいて作成する日程の計画であり、サブシステムごとに詳細な作業項目に分割し、各作業項目に日単位の時間と要員を割り当てたもの
    - 最小の計画期間：1週間～1日単位
    - WBSの下位層を見ながら作成する
    - 作業項目と担当チーム、担当作業者を明示する
    - ワークスケジュールとも呼ばれる
- 作業順序の検討
  - 正しい日程計画を作成するために、依存関係にある作業感の整合性を保つ
  - アローダイアグラムやガントチャートなどを使用する
- 作業量と要員配置の検討
  - 作業順序が決まったら、各作業の所要日数を算出し、工数を確保し、要員配置を決定する
  - 工数の山積み
    - 各作業の工数を期間ごとに合計し、期間別必要工数と保有工数(プロジェクト内の要員の工数合計)とを比較すること
  - 工数の山崩し
    - 期間別工数が保有工数を上回っており、工数が不足している場合に、作業を後回しにして、期間別必要工数を平準化すること
  - 工数山積表
    - 各作業の所要工数を期間に沿って累積し、期間ごとに必要な工数の総計を明らかにする表
  - TRM(Task Responsibility Matrix)/RAM(Responsibility Assignment Matrix)
    - 各作業とそれを担当する要員を表にまとめたもの
    - WBSで展開した作業単位ごとに関連する人とその責任権限関係を表形式で表したもの
  - WBS、作業順序、作業見積り、工数山積み、TRM/RAM
    - 相互に関連しているため、どれかを修正したら影響を受ける他も修正しなければならない
    - 相互に関連しているため、これらすべての整合性がとれた時点で完成となる
- 段階的詳細化と管理指標
  - 段階的詳細化
    - プロジェクトの特性の一つで、プロジェクトの進捗にしたがって成果物が徐々に詳細化されていくこと
    - プロジェクト計画も成果物の詳細かに応じて詳細化していく必要がある
    - PPP(Phased Project Planning ；段階的プロジェクト計画)
      - 計画を段階的に詳細化していく手法
      - ①予備分析、②仕様決定、③設計、④開発・運用の④段階に区分してプロジェクトを計画し、管理する
      - プロジェクト→フェーズ→タスクの3段階において、計画―実行―評価、が繰り返され、詳細化される
  - 進捗管理指標の設定
    - 管理指標は進捗度を表す定量的指標
    - 進捗計画策定段階で作業工程ごとに設定する
レビュー計画
- プロジェクト計画の一環として作成する
- 日付、出席者、回数、時間、エラー発見数、レビュー手法、レビューするドキュメント枚数、などを決定する
テスト計画
- テスト計画の立案
  - プロジェクト計画の一環として作成する
  - テスト期間、テスト実施者、テスト項目及びその数、テストデータ、バグ発見予定数、テスト手法、テストするプログラム行数、などを決定する
  - テスト計画書は、品質に大きな影響をおよぼすので、プロジェクトマネージャは必ずチェックしなければならない
  - テスト範囲に例外ケース、以上ケースが含められていることを確認する
- テスト計画の作成タイミング
  - 単体テスト計画書
    - プログラム設計が完了した時点
  - 結合テスト計画書
    - 内部設計が完了した時点
  - システムテスト計画書
    - 外部設計が完了した時点
  - 運用テスト計画書
    - システム分析・要求定義・外部設計が完了した時点

費用計画

ソフトウェア開発プロジェクトの場合、費用のほとんどが人件費である
プロジェクトの開始、終了期間は、財務会計制度の会計期間とは一致しないので、プロジェクト原価は会計期間をまたがって発生する

原価計算の方法

個別原価計算と総合原価計算の比較

	個別原価計算	総合原価計算
集計単位	製品1つ	会計期間と同じ (期間別に集計する)
計算方法	財務会計で把握された費用の一部を抽出して計算する	工場で発生した会計期間の前原価を集計し、製品別に分類する
適用する業種	建設業、造船業、ソフトウェア、開発業など	製造業、運輸業、サービス業など

総合原価計算
- 少量の製品を大量に生産する工場に適用する
個別原価生産
- 1つの製品を生産するものに適用する

費用別計算と部門別計算
- 費用別計算
  - 勘定科目別に費用を集計する
  - 直課
    - 特定のプロジェクトに関連して発生した費用のみを抽出してプロジェクト原価とする
  - 直課できない費用は、いったん部門別費用として集計される
- 部門別費用
  - 部門別に集計された費用
プロジェクト別計算
- プロジェクト直接費
  - 配賦基準によってプロジェクト別に分配できる費用
- プロジェクト間接費
  - 適切な配賦基準がなく、プロジェクトに分配不能な費用
  - プロジェクト直接費の合計で分配または均等に配分する場合が多い
- プロジェクト直接費の配賦
  - プロジェクト直接費は、配賦基準によって各プロジェクトに配分する
  - 配賦基準
    - 費用を各プロジェクトに配分する場合の基礎となる基準
  - 配賦基準の例
    - 社内外要員の稼働工数
    - プロジェクトが使用している部屋の面積
    - サーバやクライアントの台数
- 予定単価によるプロジェクト原価の計算
  - １年を通しての予定単価とそれに要する数量から毎月のプロジェクト別原価を計算する
  - 人件費は、予定単価と工数をかけた金額を各プロジェクトの原価にする
  - 予定単価を使用すると実績額との差額が発生する
  - 差額は決算年度末に再配賦して調整する
費用計画の策定手順
- 費用計画の策定は、他の計画と整合性をとりながら策定する
- 手順
  - WBSの作成
  - 作業順序の設定、作業量の見積り、要員配置
  - 開発規模および工数の見積り
  - 配賦基準、予定単価の設定
  - 人件費以外のプロジェクト原価の見積り
費用計画書の作成
- 費用計画書
  - プロジェクトの前提条件や制約条件などのすべてを含んだ策定手順のまとめ
- 月別原価計画書
  - 費用計画を月別にまとめたもの
  - 勘定科目別、サブシステム別、作業別、担当チーム別などプロジェクトの特性に応じて様式を決定する
費用計画作成上のポイント
- ソフトウェア開発をするため以外の営業費などの費用はプロジェクト原価に含めない
- リスクとして想定できない事故が発生した場合の原価予定分は予備費として計上する

組織計画
- 開発体制
  - ユーザチーム
    - ユーザ側の意見を代表するチーム
    - 開発後のシステムを運用する者の立場で要求定義・テストを行う
  - 開発チーム
    - ユーザチームの要求定義に従って、設計・プログラミング・テストを行う
    - 社内の要員だけでなく協力会社からの要員も含まれる
  - 支援チーム
    - 監査・品質保証。開発環境・データベース・ネットワークなどの専門的な立場からシステム開発を支援するチーム
- プロジェクト組織
  - プロジェクト開発プロジェクトのほとんどはタスクフォース組織である
- プロジェクトチームの類型
  - 開発チーム
    - フェーズ別チーム編成
      - 設計チーム、開発チームなど
      - サブシステム間の調整が容易
    - 機能別チーム編成
      - 受注サブシステムチーム、出荷サブシステムチームなど
    - プラットフォーム別チーム編成
      - サーバ関連、通信関連、端末関連など
      - 動作するハードウェアによって設計・開発の手法が異なる場合に使われる
      - アプリケーション、ミドルウェア、OSのようにソフトウェアの層によって分割する場合もある
    - 会社別チーム編成
      - 受託側が複数の会社から構成される場合に利用することがある
      - 会社間のコミュニケーションが不足しがちになるため工夫が必要となる
  - 開発支援チーム
    - 品質保証チーム
    - 開発環境チーム(基板チーム / インフラチーム)
    - 新技術チーム
      - 当該プロジェクトで初めて使用する技術を専門に担当するチーム
  - プログラミング作業におけるチーム構造
    - チーフプログラマチーム
      - チーフプログラマがプログラム作成の全責任を負い、他のメンバはチーフプログラマを支援する役割を負うチーム編成
    - スペシャリストチーム
      - チーフプログラマと専門分野を持ったスペシャリストとで編成するチーム
    - 民主的チーム
      - 1人のチームリーダと複数のプログラマが対等な関係に位置づけられるチーム編成
    - 階層的チーム
      - チームリーダの下に上級プログラマを置き、その下に中級・下級プログラマを置くチーム編成
- 組織計画策定手順
  - WBSの作成
  - 要員選定と調達
  - 要員配置の決定
  - 研修計画の決定
    - 事前集合研修とするのかOJTにするのかについて決定する
  - コミュニケーション計画の決定
    - 情報の伝達方法やタイミングを決定する
- 組織計画策定上の留意点
  - 各要員の経歴・経験一覧などの書類だけでなく、面談して人柄などを確認して要員選定する
  - 要員が他のプロジェクトなどと兼任する場合、時間配分や優先順位などを予め決定しておく
  - 予備の要員を確保しておく
  - クリティカルパスになる作業にはなるべく自社の要員を配置する
  - プロジェクトマネージャ・チームリーダ・メンバの責任と権限の範囲、指揮命令と情報の流れを明確にし、計画書に記載する
- コミュニケーション
  - コミュニケーション計画
  - 情報配布
  - 実績報告
  - ステークホルダ・マネジメント
見積り
- 開発するシステム全体の見積り工数が算出されたら、工程別の作業工数を見積もる
- 配分表を用いて全体工数を各工程に振り分ける
- 人月
  - 人月=人数×時間(月)
  - 2人で3ヶ月=6人月
  - 6人で1ヶ月=6人月

プロジェクトの運営・管理
- 実績把握
  - プロジェクト活動の結果がどのようになっているのかを、プロジェクト活動中を通して把握すること
  - プロジェクト作業の監視コントロール
    - プロジェクト管理においてマイルストーンに分類されるもの
      - 設計レビュー開始日
    - プロジェクトマネージャが行うプロジェクト関係者とのコミュニケーション
      - どのような報告をいつ、だれに対してどのような方法で行うか、プロジェクトの開始時点で決めておく
  - システム開発を外部に委託する場合の配慮すべき事項
    - 開発の進捗状況を自社でも把握することで、問題点を早期に発見して対処する
- 改善活動
  - 実績把握の結果を評価し、計画で予定していたこととの乖離が大きい場合は対応策を実施する
プロジェクトの終結
- 終結
  - プロジェクトが当初の目標を達成し、成果物をスポンサーに引き渡した時点
- 本番稼動判断基準
  - 新システムを本番稼動して良いか否かを判断するための基準
  - システムの完成度、性能、設備、ドキュメントなどからなる
- プロジェクト評価
  - プロジェクトの全行程完了後に、プロジェクト計画時の目標(納期、工数、予算、品質など)と実績の差異分析を行い、総括すること
- 完了評価
- プロジェクト完了報告書
  - スポンサーが成果物を正式に受け入れたことを記録するために作成する
- 教訓(Lessons Learned)
  - 計画と実績の差異、原因、実施した対応策の選択理由、その他将来に実施されるプロジェクトのために有用な情報をまとめたもの
  - プロジェクト完了報告書に記載する
  - プロジェクト全体で一つ作成する

プロジェクトの構成要素

プロジェクトの定義・特徴
- プロジェクト
  - 独自の成果を想像するために実施される有期的活動
- 主な特徴
  - 有期性
    - 明確な開始日と終了日
  - 独自の成果物
    - 過去に作成されたことがない製品やサービスを開発する
  - 繰り返し性がない
    - 同じプロジェクトを2度以上行うことはない
  - 段階的な詳細化
    - 作成される製品やサービスは徐々に段階を追って詳細化される
  - 複数のメンバ
    - プロジェクトマネージャと複数のメンバによって実行される
- 多くのプロジェクトライフサイクルに共通する特性
  - プロジェクトの開始時は不確実性の度合いが最も高いので、プロジェクト目標が達成できないリスクが最も大きい
- プロジェクトのライフサイクルの一般的な特徴
  - 実現する機能の不確実性は、プロジェクトが完了に近づくにつれて減少する
ステークホルダ
- プロジェクトの成否によって影響を受ける関係者
- プロジェクトの成果が、自らの利益になる者と不利益になる者がいる
- 組織の内部だけでなく、外部にもいる
- プロジェクトに直接参加する者と間接的な関与に留まる者がいる
- 個人として特定できない者もいる
- プロジェクトマネージャ
  - プロジェクトを成功裡に終わらせるためにプロジェクト管理を実行する責任者
  - 求められる役割
    - リーダーシップ
      - メンバをまとめ成果物を完成させる
    - コミュニケーション
      - ステークホルダとコミュニケーションを図り、調整する
    - 交渉・折衝
      - プロジェクトの外部者と交渉し、プロジェクトの目的を達成するために影響力を発揮する
    - 問題解決
      - 発生した問題を解決する
  - プロジェクトマネージャの役割・活動
    - 考慮すべき制約条件
      - 対象範囲、納期、予算
    - システム化計画書に基づいてプロジェクト管理計画書を作成し、承認を得る
    - プロジェクトの進捗を把握し、問題が起こらないように適切な処置を施す
    - プロジェクト計画を策定する際の留意事項
      - システム化計画書の内容を自己の責任において十分に確認し、問題点が見つかった場合は、上位の管理者に報告し調整する
    - システムテストで、あるプログラムに不良が多発しているとの報告があった時にプロジェクトマネージャが最初に行うべきこと
      - 問題のあるプログラムの品質を再評価し、システムテストへの影響を把握する
    - システム開発の結合テスト段階において、開発済の機能に追加や修正が必要となり、データベースの構成も変更することになったときのプロジェクトマネージャの対応
      - ＷＢＳを改定しプロジェクトスケジュールを見直す
      - 追加又は変更に要するコストを見積もる
      - データベースの構成変更に伴うリスクを洗い出す
    - プロジェクトのリスクチェックリストを作成するために、過去のプロジェクトで使用したリスクチェックリストを手に入れたときの対応
      - 適切
        
        過去のリスクチェックリストは過去の情報や知識を基に作成されたものなので、新たに作成するリストチェックリストの参考にする
      - 不適切
        
        過去のリスクチェックリストは過去の情報や知識を基に作成されたものなので、これに載っていないリスクの検討は不要と判断する
        
        プロジェクトごとにばらつきが出ないように、過去のリスクチェックリストをそのまま使用する
        
        プロジェクトとごにリスクは変化するので、過去のリスクチェックリストに載っていないリスクだけで新たにリスクチェックリストを作成する
- プロジェクトメンバ ( メンバ )
  - プロジェクトの目的を達成するために必要な活動を行う担当者
  - 求められる役割
    - 報告
      - 作業の進捗報告、発生した問題などを適時にに報告する
    - 作業の遂行
      - 自分に割り当てられた作業を忠実に遂行する
    - チームワーク
      - 他のメンバと調和し、全体の作業効率を高めるように努力する
- チームリーダ
  - メンバがいくつかのチームに編成される場合のチームの長
  - プロジェクトマネージャの指示に基づいて、メンバを指揮する
- 顧客
  - プロジェクトの成果物を使用する個人または組織
  - ソフトウェア受託開発プロジェクトの場合は、開発委託をした会社が顧客となる
- スポンサー
  - プロジェクトに対して、現金・預金その他物品の形で財源を提供する個人もしくは組織
  - プロジェクトを正式に認可する者でもある
  - スポンサーの例
    - 社長
    - CIO(Chief Information Officer;情報統括役員)
    - ステアリングコミッティ
      - プロジェクトの意思決定機関
標準化
- プロジェクトメンバが、１つの目標に向かって力を合わせ、協調するために作業手順、内容、書式などの方法を明確に規定すること

プロジェクトマネジメントの管理項目

管理
- 予め予定した望ましい幅の中に諸活動を調整すること
管理サイクル
- PDCA ( Plan Do Check Act )
  - Plan ( 計画 )、Do ( 実行 )、Chack ( 評価 )、Act ( 改善 ) の4つの管理サイクルを廻すことにより遂行される管理活動
- PDCAサイクルのうち、A(Act)で実施すること
  - 資源の活用に関する改善目標の設定やプロセスの改善などを行う
品質管理
- 品質計画
- 品質保証
  - プロジェクトで定めた品質基準を確実に満たすための、計画的かつ体系的な活動を行う
- 品質管理
  - QCD
    - Quality ( 品質 )
    - Cost ( 価格 )
    - Delivery ( 納期 )
    - QCDはトレード・オフの関係にある
  - 品質の考え方
    - 品質の作り込み
      - 品質は、検査工程でエラーを発見することで作るものではなく、製造工程で作りこんでいくものだとする考え方
    - 当たり前品質
      - 開発されるソフトウェアが本来持つべき最低限の品質
      - 不十分であるとユーザに不満足感を与える
    - 魅力的品質
      - 開発されるソフトウェアが当たり前品質を超えて具備する、操作性など、付加価値的な品質
    - 設計品質
      - 外部設計、内部設計を通じて作りこまれるソフトウェア品質
      - 設計仕様がユーザの要求に整合していることを指す
    - プログラム品質
      - プログラミングを通じて作りこまれるソフトウェア品質
      - プログラムが設計仕様通りに正しく動作することを指す
  - デザインレビュー
    - 計画・分析・設計などの各フェーズを振り返り、その成果物を吟味すること
  - 不良摘出目標数
    - レビューやテストを実施する前に、作りこまれた不良を予見し、発見すべき目標数
  - 成果物に不具合があったとき、その修正内容が仕様どおりであることを確認する
  - ソフトウェア品質の管理指標
    - 成果物ごとのレビュー時間
- 品質目標
  - 定性的目標と定量的目標の両方を設定する
  - 工程別定量的品質目標
    - 計画・分析・設計
      - 作成した設計書の枚数
      - 実施したレビュー時間
      - 発見エラー数
      - 実施したレビュー時間÷作成した設計書の枚数
      - 発見エラー数÷作成した設計書の枚数
    - プログラミング
      - コメントの行数合計
      - 共通ルーチンのステップ数÷全ステップ数
    - テスト
      - プログラムステップ数
      - 実施テスト項目数
      - 発見バグ数
      - 実施テスト項目数÷プログラムステップ数
      - 発見バグ数÷プログラムステップ数
    - 全工程
      - 仕様変更数
- 品質実績データの把握
  - 記録項目
    - レビュー
      - レビュー対象成果物、実施日、出席者、実施時間、エラー発見実績数、レビューした成果物の枚数
    - テスト
      - テスト対象機能もしくはプログラム、テスト実施者、テスト項目およびその数、使用したテストデータ、バグ発見実績数、テストしたプログラム行数
  - エラー記録票 (　バグ記録票 )
    - 発見したエラー、バグを1件1枚で記録する
  - エラー一覧表 ( バグ一覧表 )
    - エラー、バグの解決状況を管理するために、エラー記録票(バグ記録票)をまとめたもの
  - レビュー(テスト)工程品質管理図
    - レビュー(テスト)の進行状況と品質状況を把握する
    - レビューの項目消化予定・実績はレビュー項目の残数を縦軸、レビュー日数を横軸にとった通常右下がりの曲線となる
    - エラー発見予定・実績は累計エラー発見件数を縦軸、レビュー日数を横軸にとった通常右上がりの曲線となる
    - 未解決エラー件数
      - 発見されたが解決されていないエラー数
      - 一定の数を超えていないことを確認する
    - 管理図の例
- 品質評価
  - 差異分析
    - 予定と実績を比較し、その際が大きい場合は原因を分析し、品質の評価を行う
    - 定量的品質目標だけでなく定性的目標に付いても評価する
- 品質改善
  - 品質評価をした結果、品質不良と認められる設計書もしくはプログラムに対して品質改善を実施する
  - 原因と改善策の例
    - 開発要員のスキル不足
      - 開発要員に教育研修を実施する
      - 開発要員を交代させる
      - チーム編成を変える
    - 開発標準を遵守していない
      - 開発標準の遵守を徹底する
      - 開発標準を追加・変更する
    - 仕様変更が多い
      - 仕様変更を一時的に凍結する
      - 仕様変更を実施する時期を後にずらす
    - 設計仕様に曖昧さが多い
      - 前工程に戻って再設計・再定義をしなおす
      - 前工程のレビューを再実施する
      - プロトタイプを作成し、仕様を早期に確定する
    - 前工程のバグを引きずっている
      - 前工程のテストを再実施、もしくは追加実施する
    - 未経験の新技術部分にバグが集中している
      - 新技術部分を切り離し、問題解決をする特別チームを編成する
リスク管理
- リスクに対しては発生の予防と、発生による被害を最小限にする対策を行う
進捗管理 ( スケジュール管理 )
- 目的
  - 納期・コスト・品質の3つをバランスよく保ち、適度な水準に安定させる
  - プロジェクトの進行状況をステークホルダに示すことで安心感やより多くの支援を受ける
- 進捗実績の把握
  - 進捗実績はプロジェクト運営時に常時把握しなければならない
  - 進捗実績報告の重要性をメンバに認識させる
  - 進捗計画で定めた進捗実績把握の方法に従って実績データを収集する
  - 実績データと成果物を照合して実績データの正確さを検証する
  - 総合テストの開始までに発注先から成果物が納品されることを確認する
  - マイルストーンで予定通りに成果物が作成されたことを確認する
- 進捗実績の評価
  - 差異分析
    - 予定と実績の差を吟味し、その原因を究明すること
  - 予定と実績の差異を分析し、状況の判断を行う
  - プロジェクトマネージャの判断で対応を決定する
- 進捗遅延原因
  - メンバへインタビューや成果物などの調査によって究明する
  - プロジェクト内部に起因するもの
    - 作業工数の見積り誤り
      - 作業の見落とし
      - 作業工数の過少見積り
    - 分析ミス・設計ミス
      - 上流工程での分析ミス・設計ミスが結合テスト工程やシステムテスト工程などの下流工程で発見された場合は、手戻り作業(修正作業)が発生するため大きな進捗遅れにつながる
      - プログラムミスは影響範囲がそのプログラムに限定されるため、小さな進捗遅れの原因にしかならない場合が多い
    - 開発環境の整備不良
    - メンバの病欠や退職
  - プロジェクト外部に起因するもの
    - 仕様変更の多発
      - 途中まで進捗した作業を最初に引き戻してしまうため、大きな遅延原因となる
- 進捗遅延対策
  - プロジェクトマネージャは、どの対策を取るのか、いつ行うのかなどを判断しなければならない
  - 主な進捗遅延対策
    - 作業順序の組換え
    - 並行作業の実施
    - 担当者の組換え
    - 追加要員の投入
    - 開発環境の整備
    - 機能仕様の削減
    - 部分的な本番稼動
    - 本番稼動日の延期
  - クラッシング
  - ファストトラッキング技法
  - クリティカルチェーン法
  - 対策時のポイント
    - 全体計画の見直し
      - すぐに対策を行うのではなく、原因究明を行い、プロジェクト全体への影響度把握と全体計画の見直しを行う
      - スケジュール・プロジェクト計画書の更新を行う
    - ステークホルダとの調整
      - ステークホルダへの説明と調整を行う
      - ステークホルダ間の調整は代替案の比較によって進める
    - 解決不能状態への対処
      - 上級管理者へ報告し、判断を仰ぐ
    - 進捗遅延対策の効果確認
      - 進捗の遅れが回復しているかを確認し、効果が得られない場合は、再度、対策案を検討する
      - 効果が一時的であると判断した場合は、遅延の再発防止策を検討する
費用管理 (コスト管理)
- 費用実績の把握
  - 開発予算と実績の差異を監視し、必要に応じて計画変更を行う
  - 財務会計データの一部を抽出・集計して費用実績を算出する
  - 作業日報から稼動実績工数を把握する
  - 作業日報と費用実績をまとめて原価実績報告書を作成する
  - 予定と実績の差異を算定し、原価差異報告書にまとめる
  - 成果物の手直しなどの問題対策が予算超過につながらないことを確認する
- 費用実績の評価
  - (予定-実績)原価差異が小さい場合
    - なにもしない
  - (予定-実績)原価差異が大きい場合
    - マイナスに大きい場合(原価超過)
      - 対策を検討・実施する
    - プラスに大きい場合(原価過少)
      - 生産性が上がっている場合もあるが、進捗が予定よりも遅れている可能性もある
  - 進捗管理や品質管理などの他の管理項目では何も問題が発生していないが原価差異だけが大きい場合は、状況を正しく把握出来ていない可能性が高い
  - 原価差異分析手法
    - EVA
    - トレンドチャート
  - 費用超過対策の実施
    - 費用超過原因
      - 計画時の見積り過少に起因するもの
        
        作業工数の見積り誤り
        
        やるべき作業を見落とした
        
        作業工数を少なめに見積もってしまった
        
        購入品の見積り誤り
        
        サーバ台数、OS・開発ツールなどのライセンス数や単価を少なく見積もった
      - 実行時のミスに起因するもの
        
        分析ミス・設計ミス
        
        開発環境の整備不良
      - 想定外の問題発生に起因するもの
        
        仕様変更の多発
        
        提供された資料の誤り
    - 費用超過対策
      - 顧客との交渉
        
        費用超過原因が顧客の仕様変更にある場合
        
        仕様変更などの責任が顧客側にあることを証拠付ける資料を用意する
        
        請負金額の改訂、仕様変更の凍結、必要機能の削減など
      - 協力会社との交渉
        
        費用超過原因が、協力会社の要員や作業の進め方にある場合
        
        協力会社の要員の生産性が予想よりも低い場合には、それを証拠付ける資料を用意する
        
        請負金額の改訂、要員の交替、作業方法の改善など
      - 生産性の向上
        
        作業方法や開発支援ツールを変更し生産性を向上させる
        
        作業方法や開発ツールの変更には費用がかかるため、費用対効果を考えて導入する
        
        メンバのモラールの低下が原因の場合は、メンバと話し合いを行うことで解決策を考える
組織要員管理
- 要員の動機付け
  - 要員管理のポイントはメンバのやる気(モラール)を維持・向上させることにある
  - 動機
    - 目標を達成するための行動に駆り立てる要因
  - モチベーション(動機付け)
    - 動機を向上させること
- コミュニケーション
  - 公式なコミュニケーション
    - 計画書を配布する、実績法局所を提出する、会議に出席する、レビューを実施するなど
    - 公式なコミュニケーションのほとんどは文書で行われ、また文書化される
  - 非公式なコミュニケーション
    - 雑談、手書きのメモを渡す、状況を口頭で聞くなど
    - 非公式なコミュニケーションのほとんどは口頭で行われる
    - 非公式なコミュニケーションが発端となり重大な問題点を発見する場合もあるので軽視できない
    - 非公式なコミュニケーションを通して、公式なコミュニケーションで入手した情報の正確性や信憑性を評価する
  - 問題点の発見と対策
    - 主な問題点
      - メンバ本人に起因するもの
        
        病気や怪我
        
        他のメンバとの相性
        
        知識や経験不足
      - メンバ本人に起因しない物
        
        兼任している他の業務が多忙になった
        
        派遣会社や協力会社からの命令、母体組織の人事異動により当該プロジェクトから外れることになった
        
        以前に参画していたプロジェクトで発生した問題の対応
        
        仕様変更により作業量が増加した
        
        割り当てられた仕事が多すぎるもしくは少なすぎる
    - 問題点の発見方法
      - 公式なコミュニケーションによる方法
        
        勤怠管理表、作業日報、作業進捗管理表などから作業量の適切さや負荷の状況を確認する
        
        問題点一覧表を確認し、問題点が特定のメンバやチームに集中していないか確認する
      - 非公式なコミュニケーションによる方法
        
        作業場の巡回や雑談
        
        仕事を離れたイベントの実施
    - 対策
      - メンバ個人への対策
        
        カウンセリング
        
        再教育
      - 組織体制の見直し
        
        他の責任者との交渉
        
        兼任業務の負荷、優先順位の見直し
        
        チーム編成の組み換え
        
        TRMの変更
        
        要員交替・追加要因の投入
- 協力会社管理
  - 受注したソフトウェア開発の一部を他社に委託する場合に、委託計画・実施・評価・改善活動を行い、ソフトウェア開発状況を管理すること
- システム開発を外部に委託する場合に行う管理方法
  - 一括請負の場合は、成果物を納入するまでの過程については、すべて委託先の責任とリスクで作業を実施するので、発注元が委託先の従業員に直接指示を出すことはできない
- 人的資源計画
- チーム編成
- チーム育成
- チームマネジメント
契約管理
- 契約に関する一般原則
  - 契約自由の原則
    - 契約は当事者が自由に決められるという原則
    - 契約内容は、法律の強行規定を除き、当事者がが自由に決めて良い
  - 契約優先の原則
    - 強行規定を除く法律の規定と契約とでは、契約を優先するという原則
  - 基本契約書
    - 取引を開始する前に、会社の規模や新庄状況などを調査し、業者登録をする場合に締結する契約書
  - 個別契約書
    - 取引の内容について約束を決める契約書
  - 守秘義務
    - 契約を履行する過程において、契約当事者の双方が知り得た互いの営業上や技術上の秘密を他に漏らさない義務
  - 瑕疵担保責任
    - 仕事の目的物に瑕疵がある場合、その瑕疵を補修し被った被害を請負人が注文者に賠償する責任
- ソフトウェア開発でよく締結される契約
  - 請負契約
  - 委任契約
  - 派遣契約
  - パッケージ売買契約
  - 保守契約
  - SI契約
  - アウトソーシング契約
- 費用に関する契約
  - 定額契約
  - 実費償還契約
  - タイムアンドマテリアル契約
  - 定額インセンティブフィー契約 (FPIF契約)
  - 単価契約
- ソフトウェア開発を請負契約で外部委託するときに、発注側が行わなければならないこと
  - 成果物一覧や納期の提示
- 契約時に、受託者と委託者の作業範囲を明確にする
- 請負契約には法律上、作業状況の回答義務はないため、契約書に作業報告の義務を受託者に課すようにするケースが多い
- 契約に関するリスク管理
  - 主なリスク
    - 仕様変更の多発
    - 予定していた生産性を達成できない
    - 採用した新技術が不安定、性能不良となる可能性
    - 法律や制度の変更
  - リスク対策
    - 契約の範囲を小さくする
      - 期間を短くする、システム化の対象範囲を小さくする
      - 請負契約の場合、契約の範囲を小さくすることは特に有効な対策となる
    - リスクの少ない契約形態を選択する
      - 派遣契約→委任契約→請負契約の順にリスクが少ない
      - 不確定要素の多い上流工程(システム分析・要求定義フェーズなど)を委任契約、下流工程(外部設計以降)を請負契約とすることでリスクを軽減できる
    - 契約金額・納期の見直し条項を入れる
      - 民法が規定する請負契約では、委託者が当初想定した指示内容を変更するケースを想定しないため、見直し条項を追加する
    - 入手した資料の品質に左右されないようにするための条項を入れる
      - 受託者が利用する成果物の品質に問題があり、その問題が成果物に引き継がれた場合に免責されることを含める
    - 守秘義務条項を入れる
- 協力会社との契約
  - ソフトウェア開発の委託手順
    - 計画フェーズ
      - プロジェクト計画の確認
      - 外注計画書の作成
      - RFPの作成と説明
      - 発注先選定
      - 契約の締結
    - 実行・評価フェーズ
      - 実績把握
      - 実績評価と対策の実施
      - 成果物のレビュー・検収
      - 支払い・完了報告書の作成
  - プロジェクト計画の確認
    - 社内では技術力や工数が不足していることを確認し、要員数・必要な技能・時期・を明らかにする
  - 外注計画書の作成
    - 以下の事項を記載する
      - 委託業務の内容
      - 成果物
      - 委託形態
      - 委託時期
      - 費用概算
      - 外注管理方針
      - 発注先候補
    - 作成上の留意点
      - 委託する業務の範囲を明確にする
      - 費用を見積もる場合、協力会社に支払う費用だけでなく、社内の外注管理に必要な費用もかさんする
      - 協力会社に遵守させる諸基準の備状況を評価し、不十分であればその整備作業も計画書に盛り込む
  - RFPの作成
    - RFPの記載事項
      - 委託業務、成果物、委託形態、委託時期、外注管理方針など提案のための前提条件
      - 提案書に記載すべき事項・要件
        
        会社の概要、管理体制、総合的な技術力を示す指標
        
        予定している要員の一覧表
        
        見積金額及びその算定方法
      - 事務的な連絡
        
        提出期限、提出方法、選考結果の通知方法など
    - 発注先候補に送付し、説明会を実施する
  - 発注先選定
    - 留意事項
      - 見積金額だけでなく、品質その他の管理体制を加味して評価する
      - 会社の規模や信用能力だけでなく、予定する作業方法、作業予定要員の知識や技能の評価を重視する
      - 類似システム開発経験の有無を確認する
      - その会社を発注先に選定した場合のリスクを評価する
      - 二次選考が必要な場合には、その先行手順を決定する
    - 提案書を入手する前に選考基準を作っておく
  - 契約の締結
    - RFP、提案書に基づき契約書を作成する
    - トラブルのもととなるため、契約締結前に作業を開始してはならない
  - 実績把握
    - 会議の開催や報告書の入手によって、協力会社の状況を把握する
    - 会議では必ず議事録を作成する
    - 実績把握方法は社内のものと同じでなければならない
  - 実績評価と対策の実施
    - 協力会社の進捗状況や品実状況が思わしくない場合には、何らかの対策を講じる
  - 成果物のレビュー・検収
    - 協力会社が作成した成果物をレビュー基準、検収基準に従ってレビュー、検収する
  - 支払い・完了報告書の作成
    - 完了報告書を作成し、次プロジェクトに課題や教訓を残す
生産性管理
- 生産性の計画
  - ソフトウェア開発の生産性は、時間あたりに完成させる設計書枚数やソースプログラムのステップ数で考える
  - ソフトウェアによって獲得される価値を、ソフトウェア開発に必要な作業量で割ったもの
  - 生産性
    - 投入する資源の量と産出した価値の比率
  - 生産性=産出した価値/投入する資源の量
    - 生産性＝品質×増幅効率×開発効率
  - ソフトウェア開発の生産性=成果物の量/投入する作業工数
  - プロジェクトマネージャは、生産性をどの程度見込むかの判断を行う
- 生産性の増減要因
  - 採用するツールや開発環境の整備状況
  - 開発するソフトウェアの規模、難易度、設計仕様の複雑さ
    - 開発規模と生産性は、反比例する関係にある
  - 開発済みドキュメント、プログラムの再利用度
    - 過去に開発した成果物(設計書、仕様書、プログラムなど)を再利用出来れば、新規に開発すべき量が減少するので生産性が向上する
    - ソフトウェアの生産性=完成させる成果物の量/投入する作業工数 =完成させる成果物の量/新規開発する成果物の量 × 新規開発する成果物の量/投入する作業工数 =増幅効率×開発作業効率
    - 増幅効率
      - 完成させる成果物の量を、新規に作成する成果物の量で割った値
      - この率を向上させるには、過去に作った、もしくは他人が作った成果物を再利用する
      - 増幅効率を上げれば生産性は向上する
  - 共通ルーチン(関数)の全体に占める割合
    - 共通ルーチンの全体に占める比率が高いと生産性は向上する
    - 各メンバが開発するようが減少する
  - 仕様変更の回数及び規模
    - 仕様変更が多発すると生産性は低下する
    - 仕様変更に関する工数をそのまま投入した工数に加算すると本来の生産性が分からなくなるため、別に集計する
- 生産性の予定(目標)
  - プロジェクトで採用する生産性の定義と算定式を決定する
  - 過去の生産性の実績値を調査する
  - WBSや作業順序を見て作業予定状況を確認する
  - プロジェクトの特殊性(採用する新技術や難易度など)を加味して、生産性の予定(目標値)を決定する
- 実績把握と評価
  - 進捗管理によって把握される成果物の作成状況と組織要員管理での作業日報の工数の対比によって把握する
- 評価上の留意点と対策・検討
  - 開発環境の整備などの前提条件
    - 未整備であれば専任者を任命し、至急作業に着手させる
  - 採用した技術・ツールなどの問題点や不具合
    - 使用しているメンバにヒアリングを実施する
    - 問題があれば代替手段の採用を検討する
  - 開発規模
    - 開発規模が急増しているならば、前提条件が大幅に変わっているので、生産性を含めて計画全体を見直す
  - 開発済みドキュメント、プログラムの再利用率
    - 再利用率が低い場合には再利用を促進するための説明会を実施する
  - 共通ルーチンの占める比率
    - 他人が作成したルーチンの使用を拒否するメンバに対するカウンセリング
    - 成功例・失敗例のような生産性向上事例集を作成する
  - 仕様変更の回数・規模・影響範囲
    - 仕様変更が当初の想定よりも多い場合は、仕様凍結を検討し、ユーザ部門などと調整する
構成管理・変更管理
- 対象
  - ドキュメント
    - 設計ドキュメント、マニュアル
  - ソースコード、定義ファイル
  - オブジェクト、実行形式ファイル
  - 開発環境、テスト環境
    - OSのバージョンやパッチレベルの違いでアプリケーションの動作が異なる場合があるため、開発環境やテスト環境の内容を管理する
  - パッケージソフトウェア、OS
- 計画変更要員
  - 外部に起因
    - 法律、制度の改正
    - 経済環境の変化
    - 競合他社の動向
    - 接続する機器の変更
    - ユーザの要求
  - 内部に起因
    - 分析ミス・設計ミス
    - 性能不良
    - 生産性不良
- バージョン管理
  - ソフトウェアの構成要素であるソースファイルやドキュメントの版数を管理する
  - バージョン
    - 大きな仕様変更や構成変更の管理に使用する
  - リビジョン
    - 小規模な変更やバグ修正の管理に使用する
  - ベースライン
    - 正式なレビューや承認を受け、ある版数として固定された成果物の集まり
- 構成管理
  - コンピュータシステムの構成要素に生じる変更を管理すること
  - 特にソースプログラムやドキュメントの変更管理を指す場合もある
  - 構成管理ツールの利用
    - ソースコードだけでなくドキュメントを管理できるツールを積極的に利用する
  - 構成識別体系の確立
  - 構成状況の記録
- 変更管理
  - 障害や顧客からの仕様変更要求により設計やプログラムに対して加えられる変更を管理すること
  - 要求された変更がどのバージョン、リビジョンに関連するのかを管理する
  - 仕様変更は、予定数を計画し、その範囲内に収めるようにコントロールする
  - 変更依頼書
    - ユーザの要求仕様が変更されたり、テストにより発見された問題を解消するために、仕様変更が発生した場合にそれを記入する依頼書
  - 合意済みのシステム要件に対し、機能追加となる変更依頼を顧客から受けたときの受託側の対応
    - 決定権を持つ会議や責任者が、変更を行うかどうかを判断する
  - 変更管理の流れ
    - 変更要求の受付
    - 変更内容の調査、検討、決定
      - 検討結果によっては変更しない場合や、他の変更案件のタイミングに合わせて変更することもある
    - 変更の指示・実施・テスト・反映
    - 報告
- 品目の完全性保証
- リリース管理及び出荷
- 事例
  - ソフトウェア開発において、構成管理に起因しない問題
    - システムテストにおいて、単体テストレベルのバグが多発して、開発が予定通り進捗しない
  - ソフトウェア開発において、構成管理に起因する問題
    - 開発者がバグを定められた手続に従わずに修正したので、今まで動作していたプログラムが、突然に不正な動作をする
    - 仕様書、設計書及びプログラムのそれぞれが一致しないので、プログラム修正時にソースプログラムを解析しないと、修正すべきプログラムが特定できない
    - 一つのプログラムから多数の派生プログラムが作られているが、派生元のバグ修正がすべての派生プログラムに反映されていない

プロジェクトマネジメントのツール

WBS ( Work Breakdown Structure ；作業分割構造図 )
PMBOK ( A Guide to the Project Management Body of Knowledge )
P2M
- プロジェクトマネジメントのための標準体系であり、日本企業の実情や文化などを考慮し、プロジェクトだけでなくプログラムを視野に入れたマネジメントを行うために必要な作業のガイドラインを提供する
BABOK ( A Guide to the Business Analysis Body of Knowledge )
SQuBOK ( A Guide to the Software Quality Body of Knowledge )
- ソフトウェア品質の基本概念、ソフトウェア品質マネジメント、ソフトウェア品質技術の3つのカテゴリからなる知識体系
SWEBOK (A Guide to the Software Engineering Body of Knowledge )
- ソフトウェア要求、ソフトウェア設計、ソフトウェア構築、ソフトウェアテスティング、ソフトウェア保守など10の知識エリアからなる知識体系

その他

プロジェクト・スコープ・マネジメント
- スコープ計画
- スコープ定義
- スコープ検証
- スコープ・コントロール
プロジェクト・タイム・マネジメント
- アクティビティ定義
- アクティビティ順序設定
- アクティビティ資源見積り
- アクティビティ所要期間見積り
- スケジュール作成
- スケジュール・コントロール
  - プロジェクトのスケジュールを短縮する方法
    - 順番に行うように計画した作業を並行して行うように変更する
  - クリティカルパス上の作業が遅延すると、プロジェクトの完了も遅延する
プロジェクト・リスク・マネジメント
プロジェクト調達マネジメント
スケジュール管理
工程管理
プロジェクトにおけるコミュニケーション手段
- プル型コミュニケーション
  - イントラネットサイト
- プッシュ型
  - 電子メール
  - FAX
- 相互型
  - テレビ会議
プロジェクトの特性
- 独自性も有期性もある
プロジェクトマネジメントの実績報告のプロセスにおいて、スコープ、コスト、スケジュールに関して、ベースラインと実績の乖離を明確にするために使用する技法
- 差異分析
プロジェクトの人的資源マネジメントに関して、”ブルックスの法則”で述べられていること
- 遅延しているプロジェクトへの新規要因の追加は、更なる遅れをもたらすだけである
スコープマネジメント
- プロジェクトの目的及び範囲を明確にするマネジメントプロセス
コストマネジメント
- プロジェクトの見積もりや予算管理を行うマネジメントプロセス
タイムマネジメント
- プロジェクトのスケジュールを明確にするマネジメントプロセス
リスクマネジメント
- 発生する恐れのあるリスクを特定し、そのリスクの評価を行い、対策を講じるマネジメントプロセス
プロジェクトスコープマネジメントにおいて、WBS作成のプロセスで行うこと
- 作業を階層的に細分化する
プロジェクトの進捗を金銭価値に換算して、コスト効率とスケジュール効率を評価する手法
- アーンドバリューマネジメント
プロジェクトの開始を公式に承認する文書の作成を依頼された者の行動として適切なもの
- プロジェクト憲章を作成し、プロジェクトスポンサに文書の承認を求めた
コントロール
- スコープコントロールの活動
  - 連携する計画であった外部システムのリリースが延期になったので、この外部システムとの連携に係る作業は別部プロジェクトで実施することにした
- コストコントロールの活動
  - 要件定義完了時に再見積りをしたところ、当初見積もった開発費用を超過することが判明したので、追加予算を確保した
- スケジュールコントロールの活動
  - 開発ツールの新機能の教育が必要と分かったので、開発ツールの教育期間を2日間延長した
- リソースコントロールの活動
  - 割り当てたテスト担当者が期待した成果を出せなかったので、経験豊富なテスト担当者に交代した
システム開発のプロジェクトにおいて、EVMを活用したパフォーマンス管理をしている。開発途中のある時点でCV(コスト差異)の値が正、SV(スケジュール差異)の値が負であるとき、プロジェクトはどのような状況か
- 開発コストは問題ないが、進捗に遅れが出ているので、遅れを改善するための対策が必要である
一般的なプロジェクトにおける開始から集結までの時間の経過に伴って変動する要素について表してる
プロジェクトの品質コストを適合コストと不適合コストに分類
- 適合コスト
  - 不良が発生する前にかける費用のことで、予防コストと評価コストがある
    - 品質保証教育訓練
- 不適合コスト
  - 不良が発生した後にかかる費用のことで、内部不良コストと外部不良コストがある
    - クレーム調査費
    - 損害賠償費
    - プログラム不具合修正費
プロジェクトマネジメント計画書
- どのようにプロジェクトを実施し、監視し、管理するのかを定めるために、プロジェクトを実施するためのベースライン、及び、プロジェクトを実行し、管理し、終結する方法を明確にした文書
スコープの管理の活動
- 連携する計画であった外部システムのリリースが延期になったので、この外部システムとの連携に関わる作業は別プロジェクトで実施することにした
コロケーション
- プロジェクトマネジメントにおいて、プロジェクトチームのパフォーマンスを高めるために、チームメンバーを同じ作業場所に集めること
ファストトラッキング
- 例
  - 設計が終わったモジュールから順にプログラム開発を実施するようにして、スケジュールを短縮した
プロジェクトマネジメントのプロセスのうち、計画プロセスグループ内で実施するプロセス
- スコープの定義

デジタル経営改革のための評価指標(DX推進指標)

経済産業省が策定
経営者や社内関係者が、データとデジタル技術を活用して顧客視点で新たな価値を送出していくために、現状とあるべき姿に向けた課題・対応策に関する認識を共有し、必要なアクションをとるための気付きの機会を提供することを目指すもの
DXを実現する上で基盤となるITシステムの構築に関する指標において、"ITシステムに求められる要素"について経営者が確認すべき事項
- 環境変化に迅速に対応し、求められるデリバリースピードに対応できるITシステムとなっているか
DX推進に向けた現状や課題に対する認識を関係者が共有し、行動につなげるための気づきの気機会を与えるものとして、経済産業省が策定
背景
- DX推進に向けた現状や課題に対する認識を関係者が共有し、行動につなげるための気付きの機会を与える
内容
- DX推進のための経営のあり方、仕組に関する指標
  - DX推進の枠組み(定性指標)
  - DX推進の取組状況(定量指標)
- DXを実現する上で基盤となるITシステムの構築に関する指標
  - ITシステム構築の枠組み(定性指標)、
  - ITシステム構築の取組状況(定量指標)

クロック周波数

複数の回路の同期をとるための周期的な信号
クロック周波数によって CPU の命令実行タイミングが変化する
クロック周波数が高くなるほどパソコンの命令実行速度が向上する
同じ構造をもつCPUであれば、クロック周波数が高いものほど処理速度が速い
CPUのクロック周波数と、主記憶を接続するシステムバスのクロック周波数は同一でなくてもよい
クロック周波数2GHzのプロセッサにおいて、ひとつの命令が5クロックで実行出来る時、1命令の実行に必要な時間
- 2.5ナノ
クロック周波数が1.6GHxのCPUは、4クロックで処理される命令を1秒間に4億回実行できる

SCM(Supply Chain Management;供給連鎖管理)

資源調達から製品販売までの全体の流れ(サプライチェーン)を企業や組織を超えて管理し、情報を共有化して、商品供給全体の効率化と最適化を図る手法
資材調達から販売までの全体の流れを一括管理する手法
販売実績をもとに販売予測を行い、これを販売計画や生産計画などの各種計画に展開する
販売予測が製造や部品調達に反映されるため、無駄のない計画を立てることができる
在庫削減、業務費用削減、欠品の削減、納期短縮などの効果が期待できる
複数の企業や組織にまたがる調達から販売までの業務プロセス全ての情報を統合的に管理することによって、コスト低減や納期短縮などを目的とする
企業間を通じた物流を適切に計画・管理してコスト削減を実現すること
購買、生産、販売及び物流の一連の業務を、企業間で全体最適の視点から見直し、納期短縮や在庫削減を図る
資材の調達から生産、保管、販売に至るまでの物流全体を、費用対効果が最適になるように総合的に管理し、合理化する
調達から販売までの複数の企業や組織にまたがる情報を統合的に管理することによって、コスト低減や納期短縮などを目的とする
部品や資材の調達から製品の生産、流通、販売までの、企業間を含めたモノの流れを適切に計画・管理し、最適化して、リードタイムの短縮、在庫コストや流通コストの削減などを実現しようとする考え方
部品の供給から製品の販売までの一連のプロセスの情報をリアルタイムで交換することによって、在庫の削減とリードタイムの短縮を実現する
複数の企業や組織にまたがる調達から販売までの業務プロセス全ての情報を統合的に管理することによって、コスト低減や納期短縮などを目的とする

ルーティング制御

ルーティング(routing)
- どのネットワーク宛のデータを、どのルータから送信するのかという経路情報のこと
ストリクトルーティング
- パケット転送経路を厳密に指定すること
- 送信元から宛先までに経由するルータのIPアドレスリストを送信元のルータが指定することでパケット転送経路を厳密に指定すること
デフォルトルート
- 宛先への経路が分からなくても通信ができるように宛先の経路が見つからないパケットを送り出すための経路
ルーティングプロトコル
- 必要な情報の収集を行い、ダイナミックルーティングを実現する
ソースルーティング(source routing)
- パケットが転送される経路のノードを、送信元ノードが明示的に指定するプロトコル
- IPパケットの送信元が宛先までの経路を指定する
- 送信元のルータが必要な経路情報を収集・分析して経路を決める
ルーティング技術
- 静的ルーティング
  - ルーティングテーブルを手動でつくる方式
- 動的ルーティング
  - ルーティングテーブルを自動でつくる方式
  - プロトコル
    - IGP
      - 自律システム内のルーティングを行うプロトコル
      - 代表例)RIP、OSPF
    - EGP
      - 自律システム間のルーティングを行うプロトコル
      - 代表例)BGP-4
- プロトコルで利用される技術
  - ディスタンスベクタ方式
    - RIPで使われている
    - 経路を決定する際のアルゴリズムで、方向と距離のみで判断する
    - ルータに与える負荷が小さい
    - 速度を考慮しないので実態にあわないルーティングをする可能性がある
    - ネットワークが複雑になると対応できないケースがある
    - 経路がループしてしまう可能性がある
      - 対策
        
        スプリットホライズン
        
        自分がルートを教えてもらった方向には、そのルートの広告を行わない
        
        ポイズンリバース
        
        余分なルートの情報を汚すことでループしそうな経路を抹消する
        
        複雑なネットワークでもループを抑制できる
        
        ルーティングテーブルが大きくなり、ルータやネットワークを圧迫する
  - リンクステート
- 経路情報のループ
  - ディスタンスベクタ方式では経路がループしてしまう可能性がある
  - ルータ故障時などに代替経路を設定する際に、2台のルータ間でパケットを送りあったりなどの現象が起こる場合がある
  - IPパケットには生存時間(TLL)が設定されるため、永遠にループし続けることはないが、スループットが低下する
  - 対応策
    - スプリットホライズン
    - ポイズンリバース
AS(Autonomous System)自律システム
- ASは「その内部に向かうパケットの配送に関して責任を持ち、他のASに頼ることなく、自己完結的に配送を処理できる領域」として定義される
- インターネットを複数のASに分割し、AS同士の経路の交換とAS内部の経路の交換を分離することで、ルータが処理しなければならない経路情報の増大を防ぐことを目的としている
- 単一のルーティングポリシーによって管理されるネットワーク
- 同一の管理ポリシによって管理されるネットワーク群であり、2オクテット又は4オクテットのAS番号によって識別される
ルーティングテーブル
- 転送情報を設定する
- ルーティングプロトコルによって動的に決定された経路、または予め定められているスタティックな経路に従って形成される
- 要素
  - ネットワークアドレス/サブネットマスク
  - 出力インタフェース
  - ネクストホップとなるIPアドレスまたはリンク層アドレス
ロンゲストマッチ
- サブネットマスク(プレフィックス)が長い経路を短いものより優先して選択すること
フローティングスタティック
- バックアップ経路の確保のために使用される
- 通常使用する経路の優先度をバックアップ経路よりも高く設定しておき、優先度の低いバックアップ経路をスタティックに設定する
ポリシールーティング
- 経路制御に関して特定のポリシーを設定し、宛先アドレスとルーティングテーブルに基づくのではなく、そのポリシーに従ってルーティングを行うこと
ルーティングプロトコル
- IGP(Interior Gateway Protocol)
  - AS内部の経路交換に用いるプロトコル
  - IPv4：RIPv2、OSPFv2、IGRP/EIGRP、IS-IS
  - IPv6：RIPng、OSPFv3、EIGRPv6、IS-IS
- EGP(Exterior Gateway Protocol)
  - AS間の経路交換に用いるプロトコル
  - BGP(Border Gateway Protocol)だけが使用されている
  - IPv6やMPLS VPNの情報を運ぶためにマルチプロトコル拡張を行ったものをBGP+と読んで区別することもある
- BGP
  - インターネットにおいてAS (自律システム)間の経路情報に用いられる
  - パスベクトル型のルーティングプロトコル
  - 経路制御は以下のもので行う
    - ASパス
      - 経由したAS番号
    - ローカルプリファレンス
      - 特定のネットワークに対して、他のASへのトラフィックを選出することを示す
    - MED(Multi-Exit Discriminator)
      - 同一ASに対して複数のEBGPピアがある場合の制御に使用する
  - 経路はローカルプリファレンスが大きいもの、ASパスが短いもの、MEDが小さいものの純で優先される
  - IBGP(Internal BGP)
    - 同一AS内で経路交換を行う
  - EBGP(External BGP)
    - 異なるAS間で経路交換を行う
  - ピアリング
    - BGPにより他のASとつなぐこと
  - トランジット
    - 一方のAS#Aから他方のAS#Bを経由して他のAS#Cとも通信できるようにすること
    - 「AS#BがAS#Aに対してAS#Cに対するトランジットを提供する」という
- BGPｖ4/BGP-4
ルーティング方式
- ソースルーティング
- ホップバイホップルーティング
  - ルータごとに最適経路選択を実行する方法
  - 個々のルータが自主的に次の経路を選ぶので、1つのリンク区間ごとに経路選択を行う
ルーティングアルゴリズム
- 経路ベクトル方式
  - 送信元から宛先に到着するまでに通過するノードを数えて、この値が最小となるルートを最適ルートとして選ぶ
  - ホップ数：通過するノード数
- リンク状態方式
  - IPネットワーク内の全てのノード間リンクについて、伝送速度や通信方式をコストと呼ぶ数値で表し、送信元から宛先に到着するまでに通過するリンクのコストを加算して、この値が最小になるルートを最適ルートとして選ぶ
RIP(Routing Information Protocol)
RIPv2
RIPng(RIP Next Generation)
OSPF(Open Shortest Path First)

QC7つ道具

品質管理に用いるツールをまとめた呼び名
ソフトウェアの品質マネジメントにも使われる
主に定量的な分析に用いる
種類
- チェックシート(チェックリスト)
- ヒストグラム
- パレート図
- 特性要因図(フィッシュボーンチャート)
- 散布図
- グラフ・管理図
  - グラフ
  - 管理図
- 層別

## チェックシート(チェックリスト)

作業を確実に実行するために、作業の実行を点検するために用いる表
調査や点検に必要な項目や点検内容をあらかじめ記載した調査用紙
観察結果を用紙にチェックしてデータの収集や点検を行う
点検、確認の漏れをなくすのに用いる
記録用チェックシート
- データを集計する場合、あらかじめ集計項目を定めておき、整理や集計がしやすいように表にしたもの

ヒストグラム

収集したデータをいくつかの区分に分類し、各区間に属するデータの個数を棒グラフまたは測定値の度数に比例する面積を持つ長方形を描き、品質のばらつきをとらえるもの
ヒストグラムに山が二つある原因を調べるためにすること
- 層別にして分布を調べる
ある特性値が幅広く分布しているときに、特性値の範囲をいくつかに分割して、計測値などがそれぞれの範囲にいくつ入っているかを計算して、その値を棒グラフにしたもの
ヒストグラムを見ることで、特性値の分布状況を視覚的に把握できる
データの分布を把握するのに用いる

パレート図

管理項目を出現頻度の大きい順に並べた棒グラフとその累積和の折れ線グラフを作成し、管理上の重要項目を選択する
データをいくつかの項目に分類し、出現頻度の大きさの順に棒グラフとして並べ、累積和を折れ線グラフで描き、問題点を絞り込む
現象や原因などを幾つかの項目に分類し、件数の大きい順に並べた棒グラフと、その累積和を折れ線グラフで表し、どの項目が重要かを判断するのに適している
項目別に層別して出現度数の大きさの順に並べるとともに累積和を示した図であり、主要な原因を識別するために用いる
分類項目別に分けたデータを件数の多い順に並べた棒グラフで示し、重ねて総件数に対する比率の累積和を折れ線グラフで示した図
システム運用中に発生している各種トラブルの減少を図るための対策を立案している。トラブルを誘発する要因ごとに改善可能な課題がある。同じ時間やコストを掛けるなら、要因を層別にし、より重要なものから手がけていくことにしたい場合の分析に適している管理図法
項目別に層別して出現度数の大きさの順に並べるとともに累積和を示した図であり、主要な原因を識別するために用いる
データを度数の多い項目から順番に並べて棒グラフで表し、累積和をプロットして折れ線グラフで表示したもの
プロジェクトの状況を把握するために使用する
優先順位や重要度の分析に用いる
項目を度数の大きい順に並べ、累積和をプロットする
商品の重要度など、ある事象に大きな影響を与える要因を分析する
発生した故障について、発生要因ごとの件数の記録を基に、故障発生件数で上位を占める主な要因を明確に表現するのに適している図法
事例
- 発生した故障について、発生要因ごとの件数の記録を基に、故障発生件数で上位を占める主な要因を明確に表現する
- クレームの発生件数を減らすための分析資料として、クレームの分類項目を作成し、分類項目別にクレーム件数を数え、分類項目とクレーム件 - 数を軸とするパレート図を作成する
- バグを原因ごとに層別し、それを多い順に並べることで、改善効果の大きい重要な問題点を抽出する
- 品質改善策の立案に際し、原因別の不良発生件数を分析し、優先取り組みテーマを選択する
- パレート図の使用が最も適切である分析対象
  - 品質不良の要因ごとの構成比率
- システムの品質を向上させるために、発生した障害の原因についてパレート図を用いて分析した結果分かること
- 障害の主な発生原因と、それらの原因別の発生件数が全体に占める割合
- 製造業のA社では、製品の組立に必要な部品を購買している。A社では、自社の仕入金額全体に占める割合が大きい部品を、重点的に在庫管理を行う対象として選びたい
- 品質問題を解決するために図を作成して原因の傾向を分析したところ、全体の80%以上が少数の原因で占められていることが判明した
- プロジェクトで発生した課題の傾向を分析するために、ステークホルダ、コスト、スケジュール、品質などの管理項目別の課題件数を棒グラフとして件数が多い順に並べ、この順で累積した課題件数を折れ線グラフとして重ね合わせた図を作成した。
- プロジェクトで発生している品質問題を解決するに当たって、図を作成して原因の傾向を分析したところ、発生した問題の80%以上が少数の原因で占められていることが判明した
- 発生した故障について、発生要因ごとの件数の記録を基に、故障発生件数で上位を占める主な要因を明確に表現する
障害を解決するために重点志向で対応策を考えるべき作業を明確にする
項目をデータ件数の多い順(度数の降順)に並べた棒グラフと、その度数の累積比率(累積和)を表す折れ線グラフを一つにまとめた図
ABC分析などの、主要な原因を識別して、重点的に管理すべき項目を選び出す目的で用いる
複数の問題が存在するときに、重要な問題から先に取り上げたり、多くの原因の中で結果に対する影響度の高いものから対策を打つことは、資源や期間に制約があるプロジェクトにおいて重要
パレート図は、重点志向を支援するためのツールとして、問題の重要度を視覚化するために有効

特性要因図(フィッシュボーンチャート)

ある時点での実体(人、組織、物など)の状態と、特定の事象発生によるある状態から他の状態への遷移を図示したもの
ある結果をとる原因を体系的に分析するのに用いる
ある特性の要因を様々な視点で掘り下げて分析するときに有効
物事の原因と結果の関係をまとめて表現するために使われる
ある結果(品質特性)をもたらす要因を樹木の枝のように分類し、細分化していくことで問題の整理とその対策の検討などに有効
図の形状からフィッシュボーンとも呼ばれる
問題に対し原因と考えられる要素を魚の骨のような形状に整理し、本質的な原因を追求して解決に役立てる
不具合がどのような原因に起きているのかなどを、魚の骨に似た図によって統計的に把握する手法
原因と結果の関連を魚の骨のような形態に整理して体系的にまとめ、結果に対してどのような原因が関連しているかを明確にする
問題や結果につながる要因を、体系的にまとめた図
要因を樹木のように分類し細分化する
要因の整理や対策の検討に有効
矢印付き大枝の先端に特性を、中枝、小枝に要因を表した図であり、どれがどれに影響しているかを分析するために用いる
結果とそれに影響を及ぼすと思われる要因との関連を整理し、体系化して、魚の骨のような形にまとめる
発生した障害のその要因の関係を魚の骨のような図にして分析する
トラブル対策を立てるために、ブレーンストーミングの結果を利用して原因と結果の関係を整理するのに適した図
例
- システム開発プロジェクトの進捗悪化の原因を把握する
- bはaの原因である
- 利用者とシステム運用担当者によるブレーンストーミングを行って、利用者に起因するPCでのトラブルについて、主要なトラブルごとに原因となったと思われる操作、利用状況などを拾い上げた
- a,bの関係 bはaの原因である

グラフ・管理図

グラフ

積上げ棒グラフ
- 同じX軸の値に対応する複数の棒グラフの値を合計した結果を表示するグラフ
- 例
  - A社では、昨年まではX,Y,Zの3種類の商品を販売していたが、今年は商品体系を変更してP,Q,R,Sの4種類の商品を発売している。 P,Q,R,Sそれぞれの購入顧客数と、その顧客数の内訳として昨年までX,Y,Zのそれぞれを購入していた購入顧客数を表示するために作成する
- 内訳の各量を積み上げた棒グラフ
- 複数項目の総量と内訳の推移を把握するのに適している
- 過去5年間のシステム障害について、年ごとの種類別件数と総件数の推移を一つの図で表すのに最も適したもの
層グラフ
- 項目の総量と内訳の推移を把握するのに適している
- 内訳の推移は、各層の厚さの変化の様子から把握する
二重円グラフ
- 内側の円と外側の円の内訳の構成比を比較したり、大項目から小項目へと内訳を詳細化して、それぞれの割合を把握するのに適している
レーダチャート
- くもの巣チャートとも呼ばれる
- 複数項目間での比較や全体に対するバランスを表現するのに適したグラフ
- 単一項目の比較では使用しない
- ｎ個の評価項目があるときに、円をｎ等分するように中心からｎ本の評価軸を設定して、各軸上に評価値をプロットし、隣接するプロットされた点同士を線分で結ぶことによって、項目間の相対的なバランス評価や平均からの隔たり具合を見るのに適したグラフ
- 放射状に伸びた数値軸上の値を線で結んだ多角形の図
三角グラフ
- 正三角形の内部の点から、各辺に下ろした垂線の長さの和は一定であるという性質を利用して、三つの辺に対応させた要素の割合を各辺への垂線の長さとして表したグラフ
Zグラフ(Zチャート)
- 移動合計が右上がりになるほど、業績が上向きであることを示している
- 一定期間の売り上げ実績や業績動向・業績傾向の分析結果を表示する
折れ線層グラフ
- 個々のデータを積み重ねた値を線で結んで帯状にし、項目全体とその内訳に関する時間的推移を表したグラフ
- 例)過去5年間のシステム障害について、種類別件数と総障害件数の年ごとの推移を比較する
帯グラフ
- ある商品のメーカ別の市場構成比を表すのに適切なグラフ
浮動棒グラフ
- 商品価格の最高値と最安値など、ある期間内に幅のある数値を時系列で表現できる

管理図

工程が管理できているかどうかを分析する
工程管理の分析に用いる
中心線(平均)、管理上限、管理下限を設定し、データをプロットする
管理上限を上回る、管理下限を下回る、七回以上偏りがある、などを工程異常と判断する
企業独自の判断基準を設定することもある
時系列的に発生するデータのばらつきを折れ線グラフで表し、上限と下限を設定して異常の発見に用いる
生産物の品質を時系列に表し、生産工程が管理限界内で安定した状態にあるかどうかを判断するための図
利用方法：中央線と上下一対の限界線を引いて、製品などの特性値をプロットし、品質不良や製造工程の異常を検出して不良原因の除去や再発防止に役立てる
プロジェクトの品質マネジメントにおいて、プロセスが安定しているかどうか、又はパフォーマンスが予測のとおりであるかどうかを判断するために用いるものであって、許容される上限と下限が設定されているもの
時系列的に発生するデータのばらつきを折れ線でグラフで表し、管理限界線を利用して客観的に管理する
X管理図
- 品質特性が重量、長さ、電気抵抗などの計量値で与えられる場合、その平均値の変化を見るために用いる管理図
X-R管理図
- 工程の平均を管理するために、計量値をそのまま個々に打点する管理図と範囲の管理図を組み合わせたもの
- 7の法則(the Rule of Seven)：7回連続で平均値を上回ったか下回った場合に対応する UCLは上方管理限界、 CLは中心線、LCLは下方管理限界
u管理図
- サンプルサイズが一定でないときに、単位当たりの不適合品の数(欠点数)によって工程を管理する場合に用いる
- プログラムのバグ数がポアソン分布に従う場合、単位当たりのバグ数に換算して管理するときに用いる
c管理図
- サンプルサイズが一定の時、単位当たりの不適合品の数(欠点数)によって工程を管理する場合に用いる
- 面積や長さなど、大きさが一定の製品に検出される不適合数
np管理図
- サンプルサイズが一定のとき、不適合品率を計算しないで不適合品の数(不良個数)によって工程を管理する場合に用いる
p管理図
- サンプルサイズが一定でないとき、不適合品の割合(不良率)によって工程を管理する場合に用いる
時系列的に計測値を折れ線グラフで示し、管理限界を超えたか、あるいはどのような傾向があるかなどを分析できる
製造工程の管理や監視に使われるグラフ
中心線(CL)と合理的に定められた限界線(UCK,LCL)を利用する
管理図を使うことにより、データのバラツキが偶然要因によるものか、工程異常によるものかを判定できる
7の法則
- 測定値が中心線を7回連続で上回る、あるいは7回連続で下回るといった測定結果が得られた場合は、製造方法や測定方法などに問題があると判断すること
- 7回連続で基準の範囲内であっても中心線を連続で外れる可能性極めて低く、通常は発生しないことを根拠としている
利用するケース
- 工程の状態や品質の状況を時系列に表した図であり、工程が安定した状態にかるかどうかを判断するために用いる

層別

特性に影響を与える因子を分けること
データ群を特徴によって分類するのに用いる
多くのデータを解析する際に、データをデータを持つ特性に応じてグループ化すること

WebSocket

チャットアプリケーションのようなWebブラウザとWebサーバ間でのリアルタイム性の高い双方向通信に利用されている
通信はGETメソッドで始まり、サーバ側からもクライアントにWebSocketの接続開始を要求できる
HTTPを拡張したプロトコルで、通信メッセージはXML形式以外も使うことができる
URIのスキームにhttpを使用し、HTTPと同じポート番号で通信する
双方向通信を行う仕組みであり、WebSocketの接続開始の要求はクライアント側から行う
Webブラウザは最初にHTTPを使ってWebサーバにハンドシェイクの要求を送る
実現できること
- クライアントのWebブラウザとサーバ間での双方向の通信

アンチパスバック

入室時と退室時にIDカードを用いて認証を行い入退室を管理するとき、入室時の認証に用いられなかったIDカードでの退室を許可しない、又は退室時の認証に用いられなかったIDカードでの再入室を許可しないコントロールを行う仕組み

状態図

オブジェクトの状態遷移を決定性オートマトンで記述したもの
状態：角のない長方形
状態遷移：有向辺
開始状態：黒丸
終了状態：内側が黒丸の二重丸
有向辺には状態遷移の名前のほかに、状態遷移の条件と状態遷移時に行われる動作を書くことができる
階層的に状態を記述した時の上位の階層をコンポジット状態またはスーパー状態、下位の階層の状態をサブ状態と呼ぶ

ストライピング

データを分散して複数の磁気ディスクに書き込むことによって、データ入出力の高速化を図る方式

データウェアハウス

経営者の意思決定を支援するために、ある主題に基づくデータを現在の情報とともに過去の情報も蓄積したデータベース
データリネージ
- データウェアハウスのメタデータ
- データがどこから発生し、どのような変換及び加工を経て、現在の形になったかを示す情報であり、データの発生源の特定又は障害時の影響調査に利用できる
ファクトテーブル
- データウェアハウスのテーブル構成をスタースキーマとする場合、分析対象のトランザクションデータを格納するテーブル
データクレンジング
- 業務系のデータベースから抽出したデータをデータウェアハウスに格納するために、整合されたデータ属性やコード体系などに合うように変換及び修正を行う処理
- データウェアハウスを構築するために、業務システムごとに異なっているデータ属性やコード体系を統一する処理

ハクティビスト(hacktivist、政治的ハッカー)

情報技術を利用し、宗教的又は政治的な目標を達成するという目的をもった人や組織の総称

コネクションレス型通信

相手が通信可能かどうか確認せずにデータを転送することで、効率を重視したデータ転送ができるように設計されたプロトコル
代表的なプロトコル
- IP、UDP
少量のデータ転送や音声や動画などのリアルタイム性が求められるデータの転送に利用される
ある程度正確性を犠牲にしても即時性を優先したい通信に向いている
あて先を特定しない全員宛て通信はコネクションレス型通信で行う
送信するすべてのパケットに、あて先を示す情報を付加する
通信開始前にコネクションを確認しない
オーバヘッドが小さい

ネットワークインタフェース

LANや無線LANなどの通信インタフェースのこと

公開鍵暗号方式

公開鍵
- 暗号化を行う鍵(暗号化鍵)
- 公開する
秘密鍵
- 受け取った暗号を復号する鍵(復号鍵)
公開鍵は暗号を作ることしかできない
公開鍵暗号方式を使った暗号通信をn人が相互に行う場合、全部で何個の異なる鍵が必要になるかここで、一組の公開鍵と秘密鍵は２個と数える
- 2n
楕円曲線暗号
- 公開鍵暗号方式であり、TLSにも利用されている
対となる二つの鍵(鍵ペア)を利用する方式
鍵ペアの特徴
- 一方の鍵で暗号化したデータは、対となる鍵でなければ復号できない
- 一方の鍵から、もう一方の鍵を推測できない
鍵ペアの特徴を利用し、一方の鍵を秘密鍵(Private Key)として他者に知られないよう厳重に管理し、もう一方の鍵は公開鍵(Public Key)として公開する
代表的な暗号化アルゴリズム
- RSA
  - 素因数分解の複雑さを利用
- 離散対数暗号
- 楕円曲線暗号
暗号化や復号の処理時間が長いため、大量のデータを一括して暗号化する用途には適さないが、使用法によって、情報漏洩対策や送信者認証に利用できる
情報漏洩対策として用いる場合
- 送信者は受信者の公開鍵で暗号化して送信し、受信者は自分の秘密鍵で復号する
- これによって、受信者以外による復号が不可能となる
- 共通鍵暗号方式の脆弱性である共通鍵の配送方法に公開鍵暗号方式を用いることで、共通鍵を安全に配送できる
送信者認証として用いる場合
- 送信者は自分の秘密鍵で暗号化して送信し、受信者は送信者の公開鍵で復号する
- これによって送信者本人が暗号化したことが検証できる
システム中でn人の利用者が相互に通信を行う場合、各利用者は一組の鍵ペアを管理するので、システム中に存在する鍵の数は2n個
鍵の管理が容易であるため、公開鍵暗号方式は不特定多数との通信に適している
公開鍵と秘密鍵のペアを用いて暗号化と復号を行う
暗号化通信を行う場合、送信者は受信者の公開鍵を取得してメッセージを暗号化する
利用者は自分の秘密鍵のみを管理すればよいので、鍵管理の手間は少ない
RSA
- 素因数分解の困難さを利用した公開鍵暗号化アルゴリズム
楕円曲線暗号
- ICカードなどでよく用いられる公開鍵暗号化アルゴリズム
対となる二つの鍵の片方の鍵で暗号化したデータは、もう片方の鍵でだけ復号できる
暗号通信をn人が相互に行う場合、全部で何個の異なる鍵が必要になるかここで、一組の公開鍵と秘密鍵は2個と数える
- 2n
公開鍵暗号の欠点
- 暗号化と復号には大きな時間がかかり、CPUに負荷をかける
- 一般に共通鍵暗号の数百倍～数千倍の時間が必要で暗号通信全てを公開鍵暗号方式で行うと、応答の時間に悪影響が生じる

総合収益性分析

企業経営全体の収益性を示す
総資本営業利益率
- $総資本営業利益率=営業利益\div総資本(総資産)\times100(\%)$
- 値が高いほうが収益性が高い
総資本経常利益率
- $総資本経常利益率=経常利益\div総資本(総資産)\times100(\%)$
- 値が高いほうが収益性が高い
総資本当期純利益率(ROA)
- $ROA=当期純利益\div総資本(総資産)\times100(\%)$
- 総資本に対する事業活動の成果効率
- 値が高いほうが収益性が高い
- 株主だけでなく、債権者も含めた資金提供者の立場から、企業が所有している資産全体の効率性を表す指標
- $純利益\div総資本＝(利益\div売上高)\times(売上高\div総資本)＝売上高利益率\times総資本回転率$
- すべての資本に対するすべての収益性
経営資本営業利益率
- $経営資本営業利益率=営業利益\div(総資本－建設仮勘定－投資等－繰延資産)\times100(\%)$
- 値が高いほうが収益性が高い
自己資本当期純利益率(ROE;Return On Equity)
- $ROE=当期純利益\div自己資本\times100(\%)$
- $自己資本=総資本\times自己資本比率$
- 値が高いほうが収益性が高い
- 株主資本の活用効率
- 企業が投下した自己資本に対してどれだけの利益を上げたかを示す、企業の収益性指標
- 自己資本に対する収益性を示す指標
- 株主からの出資と過去からの損益の累算の合計である資本が、どれだけの利益を生み出しているかを示す指標
- 株主持分に対する収益力の指標であり、株主持分の運用効率を示し、配当能力の目安にもなる
- 当期純利益を自己資本で割ったもの

減価償却

定額法：毎期均等額の減価償却費を計上する方法
定率法：毎期期首未償却残高に一定率を乗じた減価償却費を計上する方法
級数法：毎期一定の額を算術級数的に逓減した減価償却費を計上する方法
生産高比例法：生産量の度合に応じて減価償却費を計上する方法

連結会計

連結貸借対照表
- 親会社が、子会社を含めた企業集団の決算日における資産と負債、純資産を対比して示すことによって、企業集団の財務状態を表す連結財務諸表
連結株主資本等変動計算書
連結キャッシュフロー計算書
連結損益計算書

株主資本等変動計算書(S/S)

純資産の変動状況を表す

管理会計

会社の経営者が会社の経営方針や経営計画を策定し、これに基づいて会社の管理を行うことを目的としている会計
経営の必要に応じて、部門別、製品別、又はプロジェクト別に損益計算や財務計算が行われる
部門、製品、地域別などの予算統制、利益管理、業績評価など、経営判断のための内部報告書を作成する

財務会計

株主、投資家、取引先、銀行などの債権者、国などの企業外部の利害関係者に対して企業の財産の状態や経営の業績に関して報告する会計

新QC7つ道具

品質管理において業務を定性的に分析し、具体的な数値を分かりやすく図示する手法
問題がどのような性質や構造をもつかを明らかにするために用いる
種類
- 連関図法
- 親和図法
- 系統図法
- マトリックス図法
- アローダイアグラム法
- マトリックスデータ解析法
- PDPC法(Process Decision Program Chart;課程決定計画図)

連関図法

複雑な要因の絡み合う事象について、その事象間の因果関係を明らかにする方法
問題とその要因を洗い出し、要因と結果を論理的に矢印線で結ぶことによって、全体的な関係を明確にする
分析対象としている問題に数多くの要因が関係し、それらが相互に絡み合っているとき、原因と結果、目的と手段といった関係を追及していくことによって、因果関係を明らかにし、解決の糸口をつかむための図
業務で扱う各種のデータと、それらの相互関係を示す
複雑な要因の絡む問題について、その因果関係を明らかにすることによって、問題の原因を究明する手法

親和図法

収集した情報を相互の関連によってグループ化し、解決すべき問題点を明確にする方法
ばらばらの情報や漠然とした問題を、言葉の意味などからグループ化して問題の本質を明確にする
漠然とした問題、バラバラの情報やアイデアを言葉の意味合いを、親和性によりグループ化、図式化することで本質を明らかにする
錯綜した問題点や、まとまっていない意見、アイデアなどを整理し、まとめるために用いられる
収集した情報を相互の関連によってグループ化し、解決すべき問題点を明確にする
引き出された多くの事実やアイディアを、類似するものでグルーピングしていく収束技法

系統図法

問題解決に当たって、大きな問題を着手できるレベルまで段階的に分割したり、抽象的なものから具体的なものへと順次細分化したりする技法
目的を達成するための手段を導き出し、さらにその手段を実施するための幾つかの手段を考えることを繰り返し、細分化していく
目的・目標を達成するための手段・方策を順次展開し、最適な手段・方策を追求していく方法
例
- 目的を達成するための手段を導き出し、更にその手段を実施するための幾つかの手段を考えることを繰り返し、細分化していく

マトリックス図法

対になる要素間の関連性を比較しながら探り出す方法

アローダイアグラム法

開発作業の順序や相互関係を表すのに用いられる図
プロジェクトを達成するのに必要な作業を矢線で、作業の結合点を○印で表し、所要日数やコストを示して日程計画を立てるのに効果的な図
効率的なスケジュールを図示することで日程管理を行う
事例：建物の設計・施工に際し、幾つかの作業をどのような手順で進めれば工程に遅れが出ないかを管理する
プロジェクトを管理するために、作業全体を単位となる小さい作業に分解して、作業は矢線で表し、各作業の開始時点と終了時点を◯印に対応させた図のこと
プロジェクトの日程計画を作成するのに適した技法
作業の順序や作業相互の関係を表現したり、重要作業を把握したりするのに適しており、プロジェクトの作業計画などに利用される
クリティカルパス
- 作業開始から終了までの各パス(一連の作業)のうち、日数が最大のパスのこと
- クリティカルパスを短縮することが、全体の日数削減に役立つ
- クリティカルパス上の作業が3日前倒しで完了すると、プロジェクトの完了も必ず3日前倒しとなる
ダミー作業
- 実際の作業ではないが、後続作業が先行作業に依存関係を持つことを示す作業のこと
最遅開始日
- 後続作業に影響を与えずに最も遅く始められる日
最早開始日
- 作業を最も早く開始できる日
余裕日数
- 最遅開始日から最早開始日を差入引いた日数

マトリックスデータ解析法

多数の数値データを整理する方法

PDPC法(Process Decision Program Chart;課程決定計画図)

事前に考えられるさまざまな事象(結果，状況，処置など)を予測し，プロセスの進行を進める手順を図化し，問題が生じたときには，目標に向かって軌道修正することが可能
実施過程で起こりうる不測の事態を事前に予測しながら、計画の開始から最終結果に至る過程や手順を時間の推移に従って矢印で結合した図であり、試行錯誤を避けられない状況における最適策の立案に役立つ
目的を達成するための手順と対応策を洗い出して線で結び、最適の手順を捜す
PDPC法がもっとも有効に活用される事例
- ライフサイクルの短い商品の販売計画の策定に際し、競合他社の出方を想定して、幾つかの大体策を準備する
システムの運用設計においては、運用操作ミスを防止するために、あらゆる場合を想定した設計を行うことが大切である。これまでの経験を生かしながら、道の常用を先読みして対応手順の検討、問題点の所在の確認を行う必要がある。これをまとめるときに活用できる手法
事態の進展とともに様々な事象が想定される問題について対応策を検討し、望ましい結果に至るプロセスを定める方法
目的を達成するための手順と対応策を洗い出すことで最適の手順を探す

CRUDマトリックス(情報分析図)

各機能が、どのエンティティに対して、どのような操作をするかを一覧化したものであり、操作の種類には生成、参照、更新及び削除がある
要求の分析にあたって、データとプロセス(データの作成(Create)、読取り(Read)、更新(Update)、削除(Delete))の対応関係をマトリクス形式で検証するもの
業務プロセスと、取り扱うデータとの関係をマトリックスで表現したもの
CRUDマトリックスを利用することで、データとプロセス(データの作成、読取り、更新、削除)の対応関係を整理できる

サンプリング

母集団からサンプルを抜き取って検査を行い、サンプル中の不良個数によって母集団の品質を判定する手法