・ITシステムの開発はどのようなものか
・ITをうまく運用するにはどうすればよいか
を知る

システム開発の流れ

■RPA・BPR
・RPA:Robotic Process Automation
主にコンピュータ上で人間が行っている処理を自動化プログラムによって効率化すること

・BPR:Business Process Reengineering
(情報システムに限らず)業務フローや内部システムなどを見直し、全体効率化をおこなうこと

■ソフトウェアライフサイクル
システムの開発から破棄までの流れ

要件定義:何を実現するのかを決める
→外部/内部設計
→プログラミング
→テスト:想定通りに動作するかを確かめる
→システム移行
→運用・保守:システムが正常に稼働するよう常にチェック・改善する

■RFP・RFI
・ベンダー(開発会社)と取り交わす文章
主にシステム開発におけるベンダー選定で中心となる文章

・RFP:Request for Proposal:提案依頼書
└発注元が、ベンダーに対してシステムの提案を依頼する

・RFI:Request for Information:情報提供依頼書
└RFPに必要となる情報を依頼する

■システム開発コストの見積もり手法・TCO
・ファンクションポイント法
ソフトウェアの機能から、複雑さなどを加味して見積もる
例)ログイン機能で◯円、カート機能で◯円・・・

・類推見積法
過去に開発された類似システムの実績をもとに見積もる

・TCO:Total Cost of Ownership
ある設備の購入から廃棄までに必要な全てのコスト
└初期費用だけでなく、維持管理にかかるコストを含めて考える

■テスト
システムの内容が想定通りかをソフトウェアを実行しながら確かめること
・ホワイトボックステスト
内部構造が正しく動作するか
(プロセスを確認する)

・ブラックボックステスト
入力と出力が正しいか
(結果を確認する)

■プログラミングに関する単語
・デバック
プログラムのバグをなくすこと

・リファクタリング
プログラムの動作は変更せずに内部構造を整理すること
より効率の良い処理へと変更したり、より保守をしやすくする

開発手法

■ウォータフォールモデル
工程を順番に進めていく方法で主に大規模開発に向く

■スパイラルモデル
試作品(プロトタイプ)を作成する工程を繰り返す
開発期間が大きく狂うことがあり、管理が難しい

■アジャイル開発
イテレーション(一連の行程を短期間で繰り返すサイクル)を繰り返す
スパイラルモデルと異なり、サービスを稼働させながら常に改善を続ける
完璧なものを作り上げて世に出すというよりは、
世に出しながら完璧なものに近づけていくイメージ

■XP:エクストリームプログラミング
アジャイル開発手法の一つ
コミュニケーション・シンプル・フィードバック・勇気・尊重
の5つの基本原則をもとに開発を行う

・ペア・プログラミング
二人一組でプログラムを書く人とレビューする人に分かれて開発を行う

・テスト主導型開発
実装するテストを書いてから、そのテストをパスするコードを書く

・ストーリーカード
実装する予定の機能をボードなどで管理する
作業状況を瞬時に把握することができる

■スクラム
アジャイル開発手法の一つ
メンバーに役割を持たせることで、アジャイル開発の「自由すぎる」面をうまく扱うことができる

■DevOps(デブオプス)(developsとoperations)
開発担当と運用担当が協力し
フレキシブルに開発を行おうという枠組み

■リバースエンジニアリング
市場にある製品を分解したり、解析をすることで
設計や構造などを明らかにすること

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

■ステークホルダー
そのプロジェクトに対して、利害関係のある関係者
ステークホルダーと適切にコミュニケーションをとっていくことが大事

■WBS:Work Breakdown Structure
タスクを細分化した一覧表のこと
作業項目の洗い出しに使用される

■ガントチャート
横に時間軸を取り、タスクごとに作業期間をまとめた表
WBSを作成した後に作成する

■アローダイヤグラム
プロジェクトの作業日程や作業時間を把握するための図
└アローダイヤグラムの中で、最も長くかかる道筋・最大日数のことを「クリティカルパス」という
└アローダイヤグラムを使うことで、どの作業をどれくらい遅れられるかということも確かめることができる

ITサービスマネジメント

■ITIL(アイティル):Information Technology Infrastructure Library
ITサービスマネジメントにおけるベストプラクティス(一番良いと思われる方法)をまとめた書籍群

■SLA:Service Level Agreement:サービスレベル合意書
サービス提供者と利用者の間でのサービスの質に関する同意書

■サービスデリバリ
「長期的な視点でITサービスの改善を図る」活動
・サービスレベル管理:SLAの締結と継続的改善を行う
・サービス可用性管理:ユーザが利用したいときにサービスを確実に提供できるよう維持管理を行う
・サービス継続性管理:災害発生時にも適切にサービスを提供できるよう計画や対策を行う

■サービスサポート
ユーザが快適にITサービスを利用できるようにする
「日々の運用に関する管理」
└サービスサポートのヘルプデスク(サービスデスク)は単一の窓口を持つべきとされる(SPOC:Single Point Of Contact)

■より効率的なサービスサポートのための機能
・チャットボット
自動応答を行うチャット形式の問い合わせシステム

・FAQ:frequently asked questions(頻繁に尋ねられる質問)
一般的な問い合わせに対する解決策をまとめ
ユーザ自身が解決策を見つけられるようにしたもの

→これらの機能によってサービスデスクの負担軽減を狙う

■サービスサポートの構成要素
【インシデント(大きな問題)発生からの流れ】
1.インシデント管理
状況を把握し、復旧のための初期対応を行う
↓
2.問題管理
根本原因を特定し、再発防止を図る
↓
3.構成管理
ITサービスを構成する要素を管理する
↓
4.変更管理
要求に応じた変更内容を決定する
↓
5.リリース/展開管理
実際の環境に変更内容を反映する

■ファシリティマネジメント
ITサービス運用に使用する設備管理
(物理的な管理)

・サージ保護
雷などによる異常高電圧・電流から機器を保護する

・UPS:Uninterruptible Power Supply:無停電電源装置
停電などで電気が絶たれても、一定期間電力を供給する

システム監査とガバナンス

■内部統制
健全で効率的な組織運営のための体制を適切に構築・運用する仕組み

■ITガバナンス
ITシステムを適切に運用するための体制

■システム監査(システム監査人・被監査部門)
使用している情報システムが正しく運用されているかを確かめる

■システム監査の流れ
1.監査計画の策定
監査計画を作成
範囲や時期を決定
↓
2.予備調査
現状を把握し、監査手続きをまとめる
↓
3.本調査
監査を行い、調書としてまとめる
↓
4.評価・結論
調査結果に基づき、評価を行い、監査の結果をまとめる
↓
5.報告
保証意見と助言意見を行い、監査依頼元に改善指導をする
(監査人はあくまで助言するだけで、実際に作業するのは被監査部門)
↓
6.フォローアップ
適切な措置が取られているか改善状況を確認する