デスマーチよ!さようなら!
−成功を呼び込む上流工程重視の開発プロセス+66の勝利の秘訣−

[表紙]デスマーチよ!さようなら! −成功を呼び込む上流工程重視の開発プロセス+66の勝利の秘訣−

紙版発売

四六判/264ページ

定価1,628円(本体1,480円+税10%)

ISBN 4-7741-2003-0

ただいま弊社在庫はございません。

→学校・法人一括購入ご検討の皆様へ

書籍の概要

この本の概要

システム開発歴20年の著者が悪戦苦闘のなかから1つ1つ拾いあげていったノウハウをあますところなく紹介します。本書にとりあげているノウハウは,すべて実際のプロジェクトで効果をあげている「現場審査済み」ばかりです。無理・無茶・無謀なプロジェクトによって精も根も尽き果てかけているエンジニアの方々に,火を吹く開発現場とさよならするための秘訣をお届けします。

こんな方におすすめ

  • プロジェクトを思うように運用できていないと考えているプロジェクトマネージャやSEの方
  • 過酷な労働で生活概念すら無くしかけているプログラマの方
  • 開発組織の経営者やユーザー企業の情報システム部に所属している方

目次

第1章 業務システム開発の現状

  • かつての開発
    • 生活概念がなくなる
    • 自衛隊のころ
  • なかなか変わらないIT業界
    • 改善しなければならないのはプログラミング技術ではなかった
    • 人は普通,ものごとを浅く軽く考えてしまう
  • マネジメントがプロジェクトを失敗させている
    • 失敗へ一直線
    • 思いこみ――重大かつ誰にでもあること
    • 元請け下請けの社会構造

第2章 業務システム開発を成功させるために

  • 本気でプロジェクトを成功させようと思っているか
    • 日本的徒弟制度
    • マネージャのマネジメント
    • プロジェクト成功の定義
  • プロジェクトの成功はモチベーションから
    • モチベーションの重要性
    • 高いモチベーションと一言でいっても
    • 日ごろの判断がもたらすもの
    • 逆に考える
    • ひとつひとつの判断がモチベーションの表現になる
  • 作って動かすためにすべての行動がある
    • 作りあげることがすべて
    • 優秀なプログラマに能力を十分発揮させる
  • 実作業者の実際の行動をイメージする
    • その作業は本当に必要か?
    • やるのであれば具体的にどうやるのか?
    • 結果として生まれた「開発プロセス」
    • 作って動かすためのドキュメント
  • 実作業者にとっての重荷を排除する
    • 排除するのはプロジェクトマネージャ
    • 不安や迷いを排除すると効率は7倍?
    • 常に実作業者の味方になる
  • 必要なことは徹底的にやって必要ないことは徹底的に省く
    • 逃げない
    • いえる雰囲気作り
    • 本当の進捗ミーティング
  • ITゼネコン形式
    • 人づてではできない
    • あくまで役割分担
    • プロジェクトマネージャと仕様策定者の役割
  • 自然言語(=日本語)による仕様表現と実装のパターン

第3章 業務システム開発の全体像

  • 体制と役割分担の重要性
  • 行動を選択する基準
    • 組織としての行動選択基準
    • 個人としての行動選択基準
  • スペックパターン開発プロセスの全体像
    • スペックパターン開発プロセスの概要
    • スペックパターン開発プロセスと従来の開発プロセスの視点の違い
    • スペックパターン開発プロセスのキーワード
    • スペックパターン開発プロセスにおける仕様書の考え方
    • スペックパターン開発プロセスの流れ
  • スペックパターン開発プロセスのエッセンス
    • よく見かける仕様書の問題点
    • データベースによる設計書の生産
    • 成立するコミュニケーション
    • 発展するコミュニケーション

第4章 よりよいコミュニケーションの実現

  • 開発プロセスを最大限に活かすために
  • 顧客の理解と信頼を勝ち取る
    • 当たり前のことを当たり前にする
    • 「コンピュータは魔法の箱」の時代は終わった
  • 日本の伝統的なコミュニケーション
  • 信頼はコミュニケーションから
    • 信頼を得られないプロジェクト
    • 顧客の怒りを買っているプロジェクト
    • スケジュールはコミュニケーションの手順書
  • プロジェクトの質はコミュニケーションの質
  • コミュニケーションが足りない
    • それは時の運?
    • 半端な楽は面倒を作り出す
    • 余計な意見はプロジェクトを壊す

第5章 プロジェクトの基盤となる会議法・議事録術

  • 会議と議事録はプロジェクトを進めるための両翼
    • プロジェクトの最重要ドキュメント
    • 伝えるべきことを伝える
  • 会議に対する基本姿勢
    • 笑顔の会議
    • 事前の準備
  • 深沢式会議法・議事録術
    • いったいわない
    • 深沢式会議法・議事録術のルール
    • 新人に議事録を押しつけない
  • より生産性の高い会議のために

第6章 成功させるための現場主義とプロジェクト計画

  • 現場を見てみなければわからない
  • プロジェクトの進め方のイメージ
  • わざわざ素人仕事にしない
  • 現場主義
    • ユーザーに向けた現場主義
    • 開発に向けた現場主義
    • 実作業者と意見を交わす
    • 曖昧なままでは勝手に解釈してしまう
  • プロジェクト計画はどう作るか
    • ドキュメントを考える
    • プロジェクト計画≒ドキュメント作成計画?
    • ドキュメントがシステムの品質を低下させている
    • 業務分析をしないでスケジュールを考えられるのか?
    • プロジェクト計画作成前の体制作り
    • 初期段階のプロジェクト計画の作成
    • プロジェクト計画で気をつけること
  • 業務分析のコツ
    • 業務分析で目指すこと
    • ヒアリングと現場見学
    • 産能大式業務フロー図による業務分析のドキュメンテーション
    • 産能大式業務フロー図の例

第7章 スペックパターン開発プロセスにおける行動と成果物

  • 業務分析における行動と成果物
    • 業務分析が勝負を決める
    • できる限り少人数で臨む
  • 要求定義における行動と成果物
    • 要求定義に入る前に
    • 要求定義で行う6つの作業
    • 最初のスペックパターンを作成する
    • 要求定義でいったん仕事を区切る
  • システム設計における行動と成果物
    • 設計に入る前に
    • 設計で行う3つの作業
    • 仕様変更ゼロを目指す
    • ドキュメントのパフォーマンスを考える
    • 仕様策定者の責任,プログラマの責任
  • 実装における行動と成果物
    • 臆病だから実装が楽になる
    • 実装段階の作業サイクル
    • プログラミングを行って,使う人の承認を得る
  • テスト,稼働,運用・保守における行動と成果物
    • テストにおける行動と成果物
    • 稼働に向けての行動
    • 運用・保守における注意点

著者プロフィール

深沢隆司(ふかざわたかし)

(株)イマジンスパーク代表取締役。陸上自衛隊少年工科学校第25期生。PMP。対空戦闘指揮装置の修理要員として自衛隊に勤務。退職後,SEとしてソフトウェア開発に携わり,一部上場企業や官庁での基幹システム開発等で仕様策定,プロジェクトマネジメントに従事。独自の手法で成功に導く。「使いやすさ,作りやすさの両立と仕様変更ゼロの実現」がモットー。著書に,『SEの教科書 成功するSEの考え方,仕事の進め方』『デスマーチよ! さようなら!』(いずれも技術評論社)がある。

著書