作りたい機能が、納期に収まらない。

業務の効率化、データの蓄積、法令遵守などのために情報システムを活用します。費用や影響も大きいため、経営戦略と整合させて目的・範囲・活用方法を定めるのが情報システム戦略です。

EA（エンタープライズアーキテクチャ）は、企業全体の最適化を目指し、現状と目標の姿を整理する考え方です。ビジネス（業務）、データ、アプリケーション、テクノロジー（IT基盤）の四つの観点を対応させます。

DFD｜データフロー図

処理、データの流れ、保存先、外部とのやり取りに着目します。矢印はデータフロー、処理はプロセス、保存先はデータストア、外部の主体はデータの源泉・吸収を表します。

BPMN

業務プロセスの共通の表記法。担当者や部門ごとのレーンなどを使い、誰がどんな処理を行うかを表します。

アクティビティ図

UMLの図の一つ。処理、分岐、並行処理など、活動の流れを表します。担当範囲を表すこともできます。

営業経由とポータル経由で別々に管理していた受注を、一つの受付と在庫管理へ組み替えるのはBPRの考え方です。導入後も待ち時間や入力ミスを測り、改善を繰り返す活動はBPMです。BPRも「企業に一生一度だけ」という意味ではありません。

システムを使う側がユーザー企業、製品や開発サービスを提供する側がベンダー企業です。企画・設計・開発・導入などを統合的に担う企業をシステムインテグレーター（SIer）と呼びます。

共通フレームは、ソフトウェアライフサイクルプロセス（SLCP）の考え方などを基に、作業・役割・用語の認識を合わせるための枠組みです。代表的な流れは、企画、要件定義、開発、運用、保守。固定した一つの開発手順をすべての現場に強制するものではありません。

システム化構想

どの業務を、何のためにシステム化するかを考えます。

システム化計画

予算、人員、スケジュール、実施体制など、どう進めるかを具体化します。

業務要件定義

業務を成立させるルール、情報、役割、手順を明確にします。例えば「領収書を画像で添付し、上長が承認する」など。

利用者側の課題や優先順位は、開発会社へ丸投げできません。何を実現したいかを共有し、技術的な方法は専門家と相談して決めます。

RFIはRequest for Information、RFPはRequest for Proposal。最安値だけでなく、品質、運用、保守、拡張性などを評価します。RFIを必ず行わなければRFPを出せない、という決まりではありません。

システムは機器・ソフトウェア・データベースなどを含む仕組み全体、ソフトウェアはその中で動くプログラムです。要件定義は「何を」、方式設計は「どう実現」、詳細設計は「実装できる細かさまで」という違いです。

機能要件

システムが何を行うか。ログイン、受注、取消しなど。

非機能要件

性能、可用性、セキュリティ、運用性など、機能以外の品質や条件。例えば同時アクセス数や復旧時間。

外部設計（基本設計）

画面や入出力など、利用者から見える側の設計。

内部設計（詳細設計）

処理手順やデータ構造など、内部の具体的な設計。

単体テスト

個々のプログラムや部品を確認します。

結合テスト

部品同士の連携やインターフェースを確認します。

システムテスト

システム全体が機能・性能などの要件を満たすか確認します。

運用テスト

実際の運用に近い手順や環境で、業務や運用が成立するか確認します。

受入テスト

利用者側が、契約や受入条件を満たすか確認します。

設計を具体化して実装し、対応するテストで確かめる関係を表すのがV字モデルです。工程名や対応の細分化には流儀があります。

ブラックボックステストは内部を見ず、入力と出力で確認します。ホワイトボックステストは分岐や経路など内部構造に着目します。これらは単体テストだけの専用技法ではありません。関係者が成果物を一緒に確認する共同レビューも、工程の認識ずれを早く見つける助けになります。

移行は、本番で使える状態へ橋渡しする作業です。ソフトウェア導入、データ移行、利用者教育、運用手順の引継ぎなどを含みます。

開発チームだけで完成とせず、運用する人が、連絡先や復旧手順を理解しているかも確認します。使い始めることは、サービスを続ける仕事の始まりです。

ウォーターフォールは工程と成果物を管理しやすい一方、後からの大きな変更には負担がかかります。アジャイルは変化に応じやすい一方、継続した対話、優先順位付け、品質管理が欠かせません。「計画をしない」「文書を一切作らない」という意味ではありません。

ペアプログラミング

二人が、コードを書く役と見通し・確認を担う役などを分担し、協力して実装します。

リファクタリング

外部から見た振る舞いを保ちながら、内部構造を改善します。機能追加とは区別します。

テスト駆動開発（TDD）

まず失敗するテストを書き、それが通る最小限の実装をし、構造を整える循環です。

XP（エクストリームプログラミング）は、コミュニケーション、シンプルさ、フィードバック、勇気、尊重という価値を重視します。プラクティスの整理や数は版によって異なります。

スクラムは、短いスプリントを繰り返して価値を生むための枠組みです。スプリントは1か月以内の一定期間。目標に向けて使える成果を少しずつ積み上げます。

機能適合性

必要な機能を適切に提供する。

性能効率性

時間や資源を効率よく使う。

互換性

他のシステムと共存・連携する。

使用性

利用者が理解し、操作しやすい。

信頼性

必要なときに安定して使える。

セキュリティ

情報とアクセスを適切に守る。

保守性

分析、修正、試験を行いやすい。

移植性

別の環境へ移しやすい。

以上はISO/IEC 25010:2011の製品品質モデルにおける8特性の整理です。2023年版の製品品質モデルは9特性に改訂されています。版によって区分や呼び名が変わるため、問題文や契約で使う規格の版と定義を確認します。大切なのは、「どんな意味で良いシステムなのか」を具体化することです。

プロトタイピング

早期の試作品を利用者に見せ、認識を合わせながら進める手法。試作の修正を繰り返しすぎる負担にも注意します。

リバースエンジニアリング

実装されたソフトウェアなどを分析し、仕様や設計を読み解くこと。通常の設計→実装とは逆向きです。契約や権利にも注意します。

DevOps

DevelopmentとOperations。開発と運用が協力し、継続的に価値を届けるための文化・実践です。

プロジェクトは、固有の成果を生むための期限のある活動です。その目標達成に向け、計画や作業を管理するのがプロジェクトマネジメント。日々同じ仕事を繰り返す運用とは性質が違います。

スコープ

成果物と、そのために行う仕事の範囲。対象外も明確にします。

プロジェクト憲章

目的、責任者、権限などを示し、プロジェクトを正式に認める文書。

ステークホルダー

利用者、事業部長、開発者、取引先など、活動に関与し、影響を受けたり与えたりする人・組織。

PMBOKはプロジェクト管理の知識体系です。従来の整理には、立上げ・計画・実行・監視コントロール・終結の5プロセス群と、統合、スコープ、スケジュール、コスト、品質、資源、コミュニケーション、リスク、調達、ステークホルダーの10知識エリアがあります。版によって構成は異なります。

WBS（Work Breakdown Structure）は、成果物や必要な作業を段階的に分解した階層構造です。抜けや認識ずれを減らし、見積り・担当割当てにつなげます。時間の前後を示す図そのものではありません。

ガントチャートでは、予定期間や進捗を横棒で表します。予定に対してどの作業が遅れているかを確認できます。

アローダイアグラム（PERT図）では、矢印が作業、結合点が作業の開始・完了などの状態を表します。点線のダミー作業は、日数ゼロで依存関係だけを示します。

最長の経路がクリティカルパスで、この例の最短完了期間は13日です。CはAだけでなくBの完了も待ちます。一つの短い経路が終わっても、すべての作業が終わるまではプロジェクトは完了しません。

ファンクションポイント法は、外部入力・出力・照会・データなどの機能を、その複雑さに応じて評価し、ソフトウェアの規模を見積もる方法です。単なるコード行数ではなく、利用者に提供する機能に着目します。

4人月は、計算上は1人で4か月、2人で2か月、4人で1か月の作業量です。ただし、実際の仕事には順番の制約、技能の差、引継ぎや調整があるため、人を増やせば比例して短縮できるわけではありません。

ITサービスマネジメントは、利用者に価値のあるサービスを継続して提供するための管理活動です。ITILはその実践を整理した枠組みです。期限のある開発プロジェクトだけでなく、日々のサービスを見ます。

SLAには、稼働率、サポート時間、問い合わせへの初動時間、未達時の扱いなどを定めます。「いつでも使える」のような曖昧な言葉ではなく、測定できる条件にします。

一時的な迂回で受注を再開できれば復旧には役立ちますが、原因が残っていれば再発します。原因調査の完了を待って、すべての復旧を遅らせる必要はありません。

サービスデスク

問い合わせや障害報告などを一元的に受け付ける窓口。

エスカレーション

窓口だけで解決できない問題を、上位者や専門部署へ引き継ぐこと。

FAQ

よくある質問と回答をまとめたもの。

チャットボット

対話の形で案内や応答を行うプログラム。

ファシリティマネジメントは、設備や建物などを管理・最適化する活動です。システムでは電源、空調、防火、設置場所なども対象になります。

サージ防護

落雷などの過大な電圧から機器を保護します。

UPS｜無停電電源装置

停電時に一時的に電力を供給し、安全な停止や電源切替えを支えます。無期限に動かせる装置ではありません。

監査は、対象から独立した立場で、証拠を集め、基準に照らして評価する活動です。必ず社外の人だけが行うわけではありません。

システム監査

情報システムのリスク管理や統制などを評価します。

情報セキュリティ監査

情報資産の保護に関する管理や対策を評価します。

会計監査

財務諸表などの適切性を評価します。

業務監査

販売、製造などの業務の適切性や効率性などを評価します。

監査人には、利害関係などから見た外観上の独立性と、偏りなく公正に判断する精神上の独立性が求められます。

監査人自身が対象業務の責任者として改善を実行すると、自分の仕事を自分で評価する問題が生じます。改善の実施責任と、独立した評価の責任を分けます。

コーポレートガバナンス

取締役会や株主などを含め、企業の経営を適切に監督・規律付けする仕組み。

内部統制

組織の中で業務の適正さ、報告の信頼性、法令遵守などを支える仕組み。

職務分掌

権限や責任を明確に分けること。例えば申請者と承認者を分けます。

IT統制

アクセス権、変更管理、承認処理など、ITに関する統制とITを使った統制。

コンプライアンス

法令や規則、社会的な要請などに従って行動すること。

ソーシャルメディアポリシー

業務や私用のSNS利用で守るべきルールを定めるもの。

「全員を信用しない」ためではなく、誤りや不正に一人で気づけなくても、別の人や仕組みが止められるようにします。受注の取消しや返金にも、記録と確認の分担が役立ちます。