社内SE1年目から貢献!情シス企画・開発・運用107のルール [単行本]

社内SE1年目から貢献!情シス企画・開発・運用107のルール の 商品概要

• 要旨（「BOOK」データベースより）

  本書は、若手社内ＳＥや社内ＳＥの仕事に興味がある方を対象にしています。社内ＳＥを取り巻く環境、社内ＳＥに期待されていること、社内ＳＥのスキルからはじまり、プロジェクト起案→立ち上げ→要件定義→設計・開発→テスト→移行→リリース・運用と、社内で実施されるプロジェクトの推進役になるためのルールを全１０７項目にまとめました。

• 目次

  第1章　社内SEを取り巻く概況
  
  Intro　社内SE 1年生への期待
  社内SE 1年生に期待されていること
  第1章の内容
  
  RULE　001　グローバルで拡大するIT需要を知る
  第4次産業革命とIT
  各国の第4次産業革命の取り組み
  新型コロナウイルスで加速するIT
  
  RULE　002　日本の少子高齢化とITの関係を把握する
  少子高齢化先進国・日本
  ビジネスを支えるIT
  社内SEも変わらなければならない
  
  RULE　003　自社のIT投資意欲を認識する
  自社のIT投資意欲
  伝統的なIT投資と新しいIT投資
  組織図から読み取れること
  
  RULE　004　社内SEとIT業種・職種との関係を把握する
  IT業界・IT業種
  社内SEとIT業種の関係性
  社内SEとIT職種の関係性
  
  RULE　005　SIer SEとSESについて理解する
  SIer SE、社内SE、SESの違い
  社内SEとSIer SE、SESのプロジェクト例
  
  RULE　006　企業のIT投資の構図を理解する
  企業活動とIT投資
  そもそもの目的を見誤らない
  
  RULE　007　2つの雇用の形を把握する
  雇用形態による違い
  社外情報収集の必要性
  
  
  
  第2章　求められるスキル
  
  Intro　実践で役立つスキルと考え方
  社内SEに必要なスキル
  第2章の内容
  
  RULE　008　成果を上げる構図を理解する
  成果を上げる構図
  成果を上げるステップ
  
  RULE　009　求められるスキル要素を理解する
  テクニカルスキル（業務遂行能力）
  コンセプチュアルスキル（概念化能力）
  ヒューマンスキル（対人関係能力）
  マネジメントスキル
  
  RULE　010　企業戦略と個人目標を紐づける
  企業戦略と個人目標
  個人目標の設定
  インプット＋プロセス
  
  RULE　011　内発的動機で行動の質を上げる
  適切な動機づけ
  内発的動機と外発的動機
  動機の見つけ方
  
  RULE　012　業務知識を身につけ、ビジネスに貢献する
  業務プロセス知識
  頻出の経営手法
  
  RULE　013　IT資格を活用する
  IT資格
  お勧めのIT資格
  
  RULE　014　コンセプチュアルスキルで課題を解決する
  お勧めのコンセプチュアルスキル
  コンセプチュアルスキル活用例
  コンセプチュアルスキルの鍛え方
  
  RULE　015　ヒューマンスキルで人間関係を円滑にする
  社内SE 1年生にとってのヒューマンスキル
  顧客視点
  相手への敬意
  
  RULE　016　学ぶためにまず時間を作る
  訓練（努力）の重要性
  振り返りと体系化で学びを加速する
  
  
  
  第3章　運用保守とプロジェクト管理
  
  Intro　社内SE 1年生の基礎業務
  業務全体感／第3章の内容
  
  RULE　017　運用保守業務で人脈を構築する
  運用保守業務
  関連する用語
  課題や依頼の対応フロー
  
  RULE　018　運用保守業務をこなして信頼を得る
  運用保守はチャンスの宝庫
  運用保守業務のコツ
  
  RULE　019　プロジェクトマネジメントでヒト・モノ・カネを管理する
  プロジェクトマネジメントは登竜門
  プロジェクトマネジメントの目的
  
  RULE　020　進捗を管理し、課題に対応する
  進捗管理の目的
  進捗管理の注意点
  
  RULE　021　WBSで進捗管理を効率化する
  WBS
  WBSの注意点
  
  RULE　022　人を管理し、プロジェクトを進める
  リソース管理の役割
  関連する用語
  リソース管理の流れ
  
  RULE　023　プロジェクト完走のために予算を管理する
  ガソリンを枯れさせない
  
  RULE　024　課題を管理し、解決する（させる）
  課題管理の要点
  課題管理の例
  
  RULE　025　コミュニケーション管理の仕組みに従う
  コミュニケーションのための仕組み作り
  プロジェクトと組織のコミュニケーションの違い
  コミュニケーション手段の使い分け
  
  RULE　026　成果物管理を体系化する
  管理する対象は幅広い
  フォルダー構成のルール
  
  RULE　027　メリハリある備品管理を行う
  無用なトラブルを避けるために
  管理すべき対象
  ソフトウェア、ハードウェア管理の例
  
  
  
  第4章　システム構築とは
  
  Intro　システム構築の全体感
  全体感と選択肢
  第4章の内容
  
  RULE　028　業務改善・改革のアプローチを押さえる
  改善・改革の手法
  手法ごとの違い
  
  RULE　029　システム構築のフェーズを押さえる
  フェーズの種類
  協業でフェーズを進める
  
  RULE　030　システム導入の選択肢を押さえる
  導入方法の選択肢
  
  RULE　031　開発体制の選択肢を押さえる
  外部リソースの守備範囲
  5つのパターン
  
  RULE　032　開発手法の選択肢を押さえる
  ウォーターフォール開発
  アジャイル開発
  ハイブリッド開発
  
  
  
  第5章　プロジェクト起案
  
  Intro　アイデア具現化の第一歩
  起案されないプロジェクト
  第5章の内容
  
  RULE　033　企画書作成プロセスを理解する
  企画書が最終の成果物
  企画の進め方
  
  RULE　034　業務フローとは何か理解する
  As-Is/To-Be業務フロー
  業務フロー検討のイメージ
  業務フロー作成支援のコツ
  
  RULE　035　ITソリューションを検討する
  ITソリューション検討
  提案で意識するポイント
  サイロ化を避けるために
  
  RULE　036　起案フェーズの役割分担を理解する
  役割分担の目的
  5つのステップ
  
  RULE　037　ITリテラシー向上を助ける
  よくある勘違い
  ITリテラシーが足りない
  ITリテラシーを上げる方法
  
  RULE　038　超概算見積もりを行う
  超概算見積もり
  見積もり情報の取得
  
  RULE　039　プロジェクトの開始承認を得る
  承認プロセスのとらえ方
  承認プロセスの種類
  根回しの考え方
  
  
  
  第6章　プロジェクト立ち上げ
  
  Intro　システム構築の方向性が決まる
  立ち上げフェーズの重み
  第6章の内容
  
  RULE　040　立ち上げフェーズの全体感を理解する
  関連する用語
  立ち上げフェーズの全体像
  
  RULE　041　RFI/RFPを作る
  RFI/RFP
  RFI/RFP実施領域の選択肢
  RFI/RFPの目次例
  
  RULE　042　ベンダーリストを作る
  ベンダーリスト
  ベンダーリストのための情報を集める
  
  RULE　043　役割分担表を作る
  RASCIの書き方
  RASCIの役割
  
  RULE　044　提案プロセスを理解する
  評価の進め方
  評価時のポイント
  
  RULE　045　デモとプレゼンを依頼する
  デモとプレゼンの目的
  デモの注意点
  
  RULE　046　提案内容を評価する
  評価のための役割
  評価軸と評価結果
  
  RULE　047　必要に応じてPoCを行う
  PoCの目的
  PoCの進め方
  PoCのコツ
  
  RULE　048　契約に向けて準備を進める
  契約なしの先行着手はNG
  請負契約と準委任契約の違い
  
  RULE　049　価格交渉のための準備をする
  支払う価格と受け取る価値
  見積もりの確認ポイント
  
  RULE　050　要件定義に向けて体制を構築する
  プロジェクト成功のための体制
  体制図作成のポイント
  
  RULE　051　関係者をプロジェクトに巻き込む
  人を巻き込むには
  集団の3つのタイプ
  
  
  
  第7章　要件定義
  
  Intro　システムに何を求めるかを定義する
  要件定義はWhatを定義
  第7章の内容
  
  RULE　052　要件定義とは何か理解する
  噛み合わない要件定義
  噛み合った要件定義
  
  RULE　053　SIer活用モデルを理解する
  SIer活用モデル
  丸投げは絶対NG
  
  RULE　054　要件定義の進め方を理解する
  "作る"と"使う"で異なるアプローチ
  社内SEとSIerの守備範囲
  
  RULE　055　システム構築関連用語を押さえる
  フェーズごとの用語
  
  RULE　056　要件定義の成果物を押さえる
  要件定義の成果物
  成果物の関連性
  
  RULE　057　成果物一覧でタスクの認識を合わせる
  成果物一覧の重要性
  成果物一覧の使い方
  
  RULE　058　プロジェクトキックオフを行う
  キックオフ会議でのインプット
  
  RULE　059　業務フローの作成を支援する
  業務フローの責任は業務部門
  業務フローを推進させるポイント
  
  RULE　060　システム要件とは何か理解する
  システム要件
  機能要件一覧
  
  RULE　061　機能要件を洗い出す
  業務フローから要件を特定する
  機能要件を深堀りする
  
  RULE　062　お客様視点で要件を検討する
  お客様視点
  お客様が本当に求めるものは？
  
  RULE　063　非機能要件を洗い出す
  非機能要件
  非機能要件の注意点
  
  RULE　064　事業部門、業務部門に丸投げさせない
  勘違いする人は必ずいる
  事業／業務部門との間合い
  
  RULE　065　要件漏れを防止する
  要件漏れの種類
  要件を全て実現することはできない
  要件漏れをゼロにする方法
  
  RULE　066　要件漏れをチェックする
  要件漏れを防ぐためのチェックリスト
  
  RULE　067　最適なソリューションを設計する
  個別最適を回避する
  カスタムで対応すべきかどうか
  
  RULE　068　画面要件、帳票要件を固める
  画面要件、帳票要件
  画面遷移
  帳票レイアウト
  
  RULE　069　データフローを固める
  マスタデータとトランザクションデータ
  データフローのポイント
  
  RULE　070　インターフェース要件を固める
  必要データ項目
  インターフェースを一覧化する
  
  RULE　071　課題を解消し要件FIXに進む
  課題のクロージング
  残課題を特定しアクションを促す
  見えにくい進捗を確認する
  
  RULE　072　要件はFIX"する"ではなく"させる"
  要件のFIX
  FIXしない判断
  
  
  
  第8章　基本設計と開発
  
  Intro　要件をどう構築するか社内SEがリードする
  丸投げすればこうなる
  第8章の内容
  
  RULE　073　進捗管理のポイントを押さえる
  社内SEが進捗を管理する
  進捗管理方法
  進捗管理の仕組み
  
  RULE　074　進捗報告会で報告を受ける
  進捗報告の目的
  進捗報告の注目点
  
  RULE　075　基本設計書をレビューする
  丸投げ社内SEのパターン
  レビューのポイント
  
  RULE　076　テストの種類と役割を理解する
  システム構築におけるテスト
  テストの役割分担
  
  RULE　077　テスト結果をレビューする
  単体テスト、結合テストの結果レビュー
  不具合の傾向から潜在している問題を見つける
  
  RULE　078　トレーニングを支援する
  基本操作トレーニングと業務運用トレーニング
  トレーニングの準備
  
  RULE　079　チェンジマネジメントを理解する
  チェンジマネジメント
  チェンジマネジメントとの関わり
  
  RULE　080　プロジェクトの反対勢力について理解する
  反対勢力は必ず現れる
  反対勢力のタイプと対策
  
  RULE　081　テスト／トレーニング環境を準備する
  テスト／トレーニングのための環境
  環境準備のポイント
  
  
  
  第9章　システムテスト
  
  Intro　品質改善のために不具合を正しくとらえる
  テストにおける不具合
  第9章の内容
  
  RULE　082　システムテストの全体像を押さえる
  システムテストの位置づけ
  システムテストの種類
  
  RULE　083　システムテスト計画を作成する
  テスト開始前の時間を有効活用
  テスト開始前の準備
  
  RULE　084　テスト計画書の書き方を押さえる
  システムテスト計画書
  
  RULE　085　システム間連携テストを行う
  システム間連携テスト
  システム間連携テストの注意点
  
  RULE　086　開始・終了判定チェックリストを活用する
  チェックリストが必要な理由
  チェックリストで押さえるべき観点
  
  RULE　087　現新比較テストを行う
  現新比較テスト
  データ比較と帳票比較
  現新比較テストの注意点
  
  RULE　088　性能テストを行う
  性能テスト
  性能テストの注意点
  
  RULE　089　エビデンスを残す
  エビデンス
  エビデンス取得のステップ
  エビデンスの注意点
  
  RULE　090　不具合を検知し報告する
  不具合のとらえ方
  不具合の検出例
  生じた違和感は共有する
  変更内容のアセスメント
  
  RULE　091　不具合の根本原因を究明する
  不具合対応のポイント
  
  RULE　092　システムテストの完了報告をする
  システムテスト完了報告
  人前で報告するときの心得
  
  RULE　093　受入テストを支援する
  受入テストの位置づけ
  社内SEの支援内容
  受入テストで見つかる課題
  
  
  
  第10章　移行
  
  Intro　To-Beへの移り変わりを設計、実行する
  移行は軽んじられがち
  第10章の内容
  
  RULE　094　移行関連用語を押さえる
  関連する用語
  
  RULE　095　移行の段取りをする
  移行の準備
  
  RULE　096　移行計画書を作成する
  移行計画書の目次例
  
  RULE　097　データ移行を行う
  データ移行の役割分担
  移行リスクの下げ方
  
  RULE　098　リハーサルで移行品質を上げる
  移行リハーサルのとらえ方
  移行リハーサルのポイント
  
  RULE　099　運用引き継ぎの流れを押さえる
  運用引き継ぎのパターン
  運用引き継

• 内容紹介

  事業会社の情シス部門やIT部門に所属する社内SE。社内SEは、システム構築・改修、パッケージ導入などITの側面から事業会社のビジネスゴール達成を支えます。
  社内SEは、ITの専門家であれば即評価されるわけではありません。社内SEが携わるプロジェクトには、外部のSIerや社内の他部門など多くの関係者が参加します。ITは道具と見定め、自社の課題解決のリード役となれる社内SEこそ高い評価を受けられます。
  
  本書は、若手社内SEや社内SEの仕事に興味がある方を対象にしています。社内SEを取り巻く環境、社内SEに期待されていること、社内SEのスキルからはじまり、プロジェクト起案→立ち上げ→要件定義→設計・開発→テスト→移行→リリース・運用と、社内で実施されるプロジェクトの推進役になるためのルールを全107項目にまとめました。
  社内SEの背骨となる基本がギュッと詰まった入門書です。

• 著者紹介（「BOOK著者紹介情報」より）（本データはこの書籍が刊行された当時に掲載されていたものです）

  加藤 一(カトウ ハジメ)
  山形県出身。Ｓｏｕｔｈｅｒｎ　Ｗｅｓｌｅｙａｎ　Ｕｎｉｖｅｒｓｉｔｙ　Ｃｏｍｐｕｔｅｒ　Ｓｃｉｅｎｃｅ専攻／Ｅ‐ｃｏｍｍｅｒｃｅ副専攻修了。大手医療機器メーカー社内ＳＥ／ＩＴブログ運営者／社内ＳＥ講師。国内外でＩＴコンサルタントや大手商社・医療系メーカーの社内ＳＥとして１５年以上従事。主に製造・物流システムの企画・開発・保守に携わり、グローバル１６拠点以上への大規模システム導入実績などがある。月間数万ＰＶの社内ＳＥ向け情報ブログ「ＩＴ　Ｃｏｍｐ＠ｓｓ」を運営中

• 著者について

  加藤 一 (カトウ ハジメ)
  山形県出身。Southern Wesleyan University Computer Science専攻／E-commerce副専攻修了。大手医療機器メーカー社内SE／ITブログ運営者／社内SE講師。国内外でITコンサルタントや大手商社・医療系メーカーの社内SEとして15年以上従事。主に製造・物流システムの企画・開発・保守に携わり、グローバル16拠点以上への大規模システム導入実績などがある。月間数万PVの社内SE向け情報ブログ「IT Comp@ss」を運営中。

社内SE1年目から貢献!情シス企画・開発・運用107のルール の商品スペック