システム開発を見える化するマインドマップ 6つのケーススタディから学ぶ応用例

マインドマップを駆使した「見える化」の応用例を紹介!

このような方におすすめ

若手から中堅クラスのシステム(IT)エンジニア
マネジメント(プロジェクト管理)中心のシステム開発者
  • 著者シンプル・ビジョン 監修/渡邉 安夫 著
  • 定価2,052 (本体1,900 円+税)
  • A5 240頁 2008/04発行
  • ISBN978-4-274-06719-8
  • 定価
  • ポイント0
  • 数量

※本体価格は変更される場合があります。
※通常2〜3日以内で発送いたします。

  • 概要
  • 主要目次
  • 詳細目次

放射思考法「マインドマッピング」の利用法を、若手から中堅クラスのシステム(IT)エンジニアを対象に紹介する。カバーするのは、システム開発プロジェクトの仕事のイロハからマネジメント的な領域までとなる。マインドマップは手描きで作ってもよいが、ソフトを使ったほうが効率よくできるため、マッピングツール「MindManager」を利用した作成方法も紹介する。

https://www.ohmsha.co.jp/book/9784274067198/
Chapter 1 見える化戦略−「プロジェクト」をカタチにしよう!
Chapter 2 企画・構想−「未来」を見える化しよう!
Chapter 3 要求定義−「想い」を見える化しよう!
Chapter 4 計画策定−「活動」を見える化しよう!
Chapter 5 設計・開発−「しくみ」を見える化しよう!
Chapter 6 開発マネジメント−「状態」を見える化しよう!
Chapter 7 導入・教育−「運用」 を見える化しよう!
Appendix マッピングツール MindManager を使ってみよう!
システム開発を見える化するマップの実例集
はじめに
Chapter 1 見える化戦略「プロジェクト」をカタチにしよう!
1.1 システムエンジニアの仕事って何だろう?
1.1.1. システム全体を設計する
1.1.2. システムの開発計画を作成する
1.1.3. 開発に必要な資源を調達する
1.1.4. 開発チームを指揮する
1.1.5. 予算、納期、品質を管理する
1.1.6. プロジェクト全体を管理する
1.1.7. 実務に不可欠なスキルとは?
1.2 マインドマップで「見える化」しよう
1.2.1. マインドマップとは?
1.2.2. 常に中心にテーマ(目的)を持つ
1.2.3. 全体像がわずか1枚で俯瞰できる
1.2.4. 関係性が見える、わかる
1.2.5. わからないことがわかる
1.2.6. 俯瞰力を継続的に高められる
1.3 マインドマップを推奨するワケ
1.3.1. 気づく力が高まる
1.3.2. 相互理解が深まる
1.3.3. 思考のカタチが残る
1.3.4. 思考の再開が素早くなる
1.4 マインドマップ入門者の落とし穴
1.4.1. 中心のテーマが曖昧になる
1.4.2. 多面的に思考を展開できない
1.4.3. 要素間の関係までは考えない
1.4.4. 想像力やイメージを喚起しにくい
1.4.5. 直感力に乏しくわかりにくい
1.5 マッピングツールを使いこなそう
1.5.1. 生産性や創造性が同時に高まる
1.5.2. 編集・更新が素早く行える
1.5.3. チームで情報を共有できる
1.5.4. 情報の活用スキルが高まる
コラム 多面的な視点でといきなり言われても
Chapter 2 企画・構想「顧客」を見える化しよう!
2.1 企業って一体どんなカタチ?
2.1.1. 探りあいのインタビュー
2.1.2. 顧客のスガタが掴めない
2.1.3. 顧客に理解を示し信頼を得る
2.1.4. 顧客の本音をスムーズに引き出す
2.2 プロジェクトの上位目的を知ろう
2.2.1. 目的と手段の違いを理解する
2.2.2. 抽象的な言葉に隠された真意
2.2.3. 目的の構造と繋がりを把握する
2.2.4. 本当の目的を見極める
2.3 システム化の方向性を見極めよう
2.3.1. 走りながら…プロジェクト特有の罠
2.3.2. 方向音痴なプロジェクト
2.3.3. 最初に方向性を決め合意する
2.3.4. プロジェクトの地図と羅針盤を共有する
2.4 システム化へのプロセスを見える化しよう
2.4.1. 丸投げ方式のシステム開発プロジェクト
2.4.2. 見えにくい顧客と開発企業との役割分担
2.4.3. プロジェクト全体を共通認識する
2.4.4. 関係者間に一体感が生まれる
2.5 ケーススタディ
2.5.1. 顧客を見える化する.
コラム 顧客のIT業界用語にご注意を!
Chapter 3 要求定義「想い」を見える化しよう!
3.1 顧客の本音や想いを引き出そう
3.1.1. 聴き手主体のインタビュー.
3.1.2. わからない顧客の言葉
3.1.3. わからないことや誤解を知る
3.1.4. 顧客の想いが理解できる
3.2 まずは顧客の業務を理解しよう
3.2.1. 業務を部分に分けて理解する
3.2.2. 未知の顧客業務
3.2.3. 業務を全体に統合して理解する
3.2.4. 問題のありかを発見できる
3.3 顧客の言葉で要求を描き出そう
3.3.1. 個々の機能中心のニーズ
3.3.2. 見えない業務の繋がり
3.3.3. 業務中心のニーズを掘り下げる
3.3.4. 業務とシステムを一体化する
3.4 顧客自身に気づいてもらおう
3.4.1. SEの頭で整理・解釈する
3.4.2. 顧客自身もよくわからない
3.4.3. 顧客の心を整理・整頓する
3.4.4. 本当に大切なことに気づかせる
3.5 ケーススタディ
3.5.1. 顧客の業務を見える化する
コラム それって要求定義それとも要件定義?
Chapter 4 計画策定「活動」を見える化しよう!
4.1 仕事の中身を分解しよう
4.1.1. やるべき仕事をすべてリストアップする
4.1.2. 仕事のレベルや関係が理解しにくい
4.1.3. 仕事の構造や関係を見える化する
4.1.4. 実行が危うい仕事が一目でわかる
4.2 活動イメージを具体化しよう
4.2.1. 仕事単位に担当者を割り当てる
4.2.2. 仕事の品質が担当者任せとなりやすい
4.2.3. 仕事の活動イメージを具体化する
4.2.4. 危険性が高い仕事が一目でわかる
4.3 スケジュールを策定しよう
4.3.1. 期限から遡ってスケジューリングする
4.3.2. 現実離れしたスケジュール
4.3.3. 全体像で開始と関係を意識する
4.3.4. 常に冷静に一歩先を見て行動できる
4.4 活動計画を実績に活かそう
4.4.1. スケジュール(期限)を中心に管理する
4.4.2. 計画を柔軟に変更することができない
4.4.3. 計画を更新しながら目的地を目指す
4.4.4. 目的地は変えずに計画(経路)を変える
4.5 ケーススタディ
4.5.1. 作業計画を見える化する
コラム 見えないということは恐ろしい
Chapter 5 設計・開発「しくみ」を見える化しよう!
5.1 顧客との相互理解を深めよう
5.1.1. 開発者の視点でシステム(木)の雛型を創る
5.1.2. 対象となる部分にしか目が届かない
5.1.3. 顧客の視点で業務(森)の雛型を創る
5.1.4. 潜在的な問題点を発見する
5.2 パッケージ製品の適合性を見極めよう
5.2.1. デモや機能を中心に比較検討する
5.2.2. ブラックボックス化された内部仕様
5.2.3. 業務要件との適合性を見極める
5.2.4. 機能連携上の落とし穴に気づく
5.3 レビューの見える化で気づきを促そう
5.3.1. 設計書の詳細部分をレビューする
5.3.2. 網羅性と整合性の確保が困難
5.3.3. 設計書の構造全体を俯瞰する
5.3.4. 抜け・漏れ・重複が簡単に見つかる
5.4 テストの見える化で品質を高めよう
5.4.1. システム中心の機能テスト
5.4.2. テスト担当者は業務を知らない
5.4.3. シナリオ中心の業務テスト
5.4.4. 業務への影響度合いが一目でわかる
5.5 ケーススタディ
5.5.1. ソフトウェアの構造を見える化する
コラム システム開発は誰のため?
Chapter 6 開発マネジメント「状態」を見える化しよう!
6.1 情報の意味を共有しよう
6.1.1. 口頭、文書に埋もれてしまう意味
6.1.2. 失われた言葉の意味
6.1.3. 記号化によって意味を伝える
6.1.4. 情報の伝達効率が高まる
6.2 品質のバランスを見極めよう
6.2.1. リスト化による問題管理方法
6.2.2. 判別しにくい解決優先度
6.2.3. 問題の発生分布を俯瞰する
6.2.4. 影響範囲を最小限に止める
6.3 問題解決プロセスを共有しよう
6.3.1. 担当者主体の局所的な問題解決
6.3.2. 見えにくい問題の影響範囲
6.3.3. チーム主体の大局的な問題解決
6.3.4. チームの知恵を結集できる
6.4 成果物へのアクセス環境を改善しよう
6.4.1. 体系化が困難なフォルダ管理
6.4.2. 関係性を失ってしまった散在情報
6.4.3. 目的に関連付けられた情報管理
6.4.4. 必要な情報がすぐに取り出せる
6.5 ケーススタディ
6.5.1. 問題解決を見える化する
コラム 言った/言わないがなくなった?
Chapter 7 導入・教育「運用」を見える化しよう!
7.1 テストでは全体を俯瞰しよう
7.1.1. 開発者サイドから見た運用テスト
7.1.2. システム中心のテストプロセス
7.1.3. 顧客サイドから見た運用テスト
7.1.4. 最初に通るべき道が見つかる
7.2 テストは運用のシミュレーション
7.2.1. リスト化されたテスト項目を順次実行
7.2.2. 問題の影響範囲がわかりにくい
7.2.3. シナリオ全体を俯瞰しつつ選択実行
7.2.4. 起こりうる事態を想定し対策を練る
7.3 わずか1枚のマニュアルマップ
7.3.1. 複数ページにまたがるマニュアル目次
7.3.2. どこを見たらいいのかわからない
7.3.3. マニュアルの体系や構造を地図化する
7.3.4. 探したい情報が一目でわかる
7.4 効果的な導入トレーニングの秘訣
7.4.1. システム操作方法を中心に教育する
7.4.2. 業務との関係性がわかりにくい
7.4.3. 全体像と業務との関係性を理解させる
7.4.4. スキルの習得効果を継続的に高める
7.5 ケーススタディ
7.5.1. テストシナリオを見える化する
コラム それって運用テストなの?
Appendix マッピングツールMindManagerを使ってみよう!
A.1 MindManager Proとは?
A.1.1. 稼働要件
A.1.2. コンセプト概要
A.2 役立つ基本テクニック
A.2.1. 中心には目的を書き込もう
A.2.2. 主要トピックをイメージ化しよう
A.2.3. 色を効果的に割り当てよう
A.2.4. 重要な関係を視覚化しよう
A.3 実践的な応用テクニック
A.3.1. 関連情報をリンクする(ハイパーリンク機能)
A.3.2. ノートに付加情報を記録する(ノート機能)
A.3.3. 仕事情報を設定する(プランニング機能)
A.3.4. 情報の意味を記号化する(マップマーカー機能)
A.3.5. 任意のトピックを分割出力する(トピック送信機能)
A.3.6. 様々な形式へ変換する(エクスポート機能)
A.3.7. 特定の情報を抽出する(フィルタリング機能)
A.3.8. マップをテンプレート化する(テンプレート機能)
A.4 システム開発を見える化するマップ10
A.4.1. 顧客プロファイル
A.4.2. プロジェクトプロファイル
A.4.3. プロジェクトスコープ
A.4.4. PMBOK2000
A.4.5. システム開発WBS
A.4.6. プロジェクトチームデザイン
A.4.7. リスクマネジメント
A.4.8. 問題解決マネジメント
A.4.9. 問題解決プロセス
A.4.10. ミーティングレポー
A.5 詳しい情報を入手するには
A.5.1. 試用版をダウンロードする
A.5.2. 無料戦略レポートを読む
A.5.3. Project Management Jetpack
索 引