深沢隆司の作品一覧
「深沢隆司」の「SEの教科書【完全版】」「炎上知らずのDXプロジェクトマネジメント～業務システム開発 七つの鉄則」ほか、ユーザーレビューをお届けします！
- 作者をフォローする
- フォローすると、この作者の新刊が配信された際に、お知らせします。
作品一覧
-
炎上知らずのDXプロジェクトマネジメント～業務システム開発 七つの鉄則
ビジネス・実用
3.01巻2,640円 (税込)◆手戻りコストを大幅に削減し、プロジェクトを成功へと導く◆ 曖昧な要件定義、度重なる仕様変更、それに伴うプロジェクトの遅延や炎上、現場の疲弊や顧客の不満など……。DXによる業務のIT化・効率化が進められる中、開発プロジェクトがなかなか上手くいかないという悩みを抱えている方は多いかもしれません。プロジェクトの舵取りを担う部門の担当者やリーダー、マネジメント層が、解決の糸口が見えない現状に危機感を抱くことも少なくないはずです。 本書では、著者が長年のシステム開発・プロジェクトマネジメントに従事した経験に基づき体系化した手法である「スペックパターン開発プロセス」を軸に、DX・業務システム開発プロジェクトを成功に導くためのノウハウを解説します。 科学的な手法による正しい計画作成から始まり、顧客の要求をしっかりと掴む会議運営と議事録作り、データベース化による仕様管理、上流工程での徹底的なユーザーテスト実施、生成AI時代も見据えた画面量産体制の構築などを、7つの鉄則として整理しました。スペックパターン開発プロセスの本質を理解することで、顧客・開発サイドの双方が満足できるWin-Winの業務システム開発プロジェクト実現に繋げられるでしょう。 ■目次 第1章 なぜ日本のIT投資は利益を生まないのか 第2章 第3の選択肢としての「スペックパターン開発プロセス」 第3章 【鉄則1】正しく計画せよ～誤解されたWBSと、失われた計画作成～ 第4章 【鉄則2】議事録は発言録ではない！ 決定事項を記録せよ～会議法＆議事録術～ 第5章 【鉄則3】仕様書は書かずに「出力」せよ～開発プロセスの心臓部 「仕様のデータベース化」～ 第6章 【鉄則4】上流工程で成功を確定せよ～ソフトウェア製造ライン設計術～ 第7章 【鉄則5】テストは最初に、徹底的に実施せよ～実装と品質保証の自動化・工場化～ 第8章 【鉄則6】仕様と計画を完全支配せよ～内製化とベンダー共創の新しい形～ 第9章 【鉄則7】工場は小さく始めて大きく育てよ～開発プロセスの導入と体制構築～ 第10章 業務システム開発におけるAIの活用 Appendix スペックパターン開発プロセス標準実施手順書 ■著者プロフィール 深沢隆司：株式会社イマジンスパーク代表取締役。陸上自衛隊少年工科学校第25期生。防空指揮装置の修理要員として自衛隊に勤務。退職後、プログラマー、仕様策定者、プロジェクトマネージャーとしてソフトウェア開発に従事。小規模システムから上場企業、官公庁の大規模基幹システムまで、幅広いプロジェクトに携わる。現在は、中小IT企業・DX内製化企業を中心に、プロジェクトマネジメントおよび業務システム開発の実務支援、コンサルティング、研修を提供。日本のデジタル競争力向上に貢献している。 -
SEの教科書【完全版】
ビジネス・実用
4.11巻1,738円 (税込)※本書は2009年に発行された書籍の電子版になります。 【業務システム開発のNo.1取扱説明書！】 SEの仕事の成否を分けるのは、コミュニケーションとマネジメントだった！ 業務システム開発の本質は「人」にあるということをいち早く見抜き、20年以上にわたって開発プロジェクトを次々に成功させてきた著者が、その成功の秘密を公開する、SE必読の書。続編『SEの教科書2』とあわせて改訂・再校正した完全版。 ■こんな方におすすめ ・これからSEになろうと考えている大学生 ・SEに転職しようと考えている人 ・SEになりたての人 ・SEとして楽しく仕事をしていきたい人 ■目次 ●第一部 成功するSEの考え方、仕事の進め方 第1章 SEの仕事は「人」が9割 第2章 失敗の原因はコミュニケーション不足 第3章 マネジメントが成否の鍵 第4章 コミュニケーション重視の会議術【準備編】 第5章 コミュニケーション重視の会議術【実践編】 第6章 プロジェクト初期段階の仕事術 第7章 成果物作成の仕事術 第8章 顧客業務分析の仕事術 第9章 設計・実装・テストの仕事術 第10章 プロジェクト運営の仕事術 第11章 業務システム開発は「伝言ゲーム」 ●第二部 成功するSEのプロジェクト計画・運営術 第12章 名ばかりプロジェクトマネジメント 第13章 誤解がプロジェクトを破綻させる 第14章 上流工程はすべて計画活動 第15章 本当の計画、名ばかりの計画 第16章 ネットワーク図による計画作成術（アナログ式） 第17章 ネットワーク図による計画作成術（デジタル式） 第18章 ネットワーク図による計画の最適化 第19章 IT業界が日本を救う ■著者プロフィール 深沢隆司（ふかさわ・たかし）：(株）イマジンスパーク代表取締役。陸上自衛隊少年工科学校第25期生。PMP。対空戦闘指揮装置の修理要員として自衛隊に勤務。退職後、SE としてソフトウェア開発に携わり、一部上場企業や官庁での基幹システム開発等で仕様策定、プロジェクトマネジメントに従事。独自の手法で成功に導く。著書に、『デスマーチよ！ さようなら！』『いちばんやさしいPMBOK の本』（いずれも技術評論社）、『ベースラインで成功する プロジェクトマネジメント』（日本実業出版社）など多数。
ユーザーレビュー
-
-
-
-
Posted by ブクログ
確かに、そんな経験あるある、という内容が多く、膝を打つ場面もあり、とても読みやすい物でした。SEを3,4年やっている人にはうってつけかも。
特に、「成果物だけ立派でも、メンバーの体や心を壊したりしていては、PMではない」という部分はとても共感します。自分も、これまでの業務経験の中で、そういうPMを複数見てきたので。
また、当然の事ではあるけど、「顧客に提供するのは、システムではなく、システムを使った結果のサービスである。」という意識は大切だと思う。
究極のところ、顧客の立場にたつって事だけど。
□SE/PMとは
使う側と作る側のコミュニケーションの橋渡しがSE/PM。
SE/PMの仕事は、コミュニケーションが全て。
PMは、成果物と、プロジェクトの２つを作らないといけない。
プロジェクトを作る=プロジェクトを成功させる。
成果物だけ立派でも、メンバーの体や心を壊したりしていては、PMではない。
プロジェクトの成功=プロジェクトのステークホルダ全員が「よかった」と思える状態。
□顧客とは
顧客に提供するのは、システムではなく、システムを使った結果のサービスである。
プロジェクト憲章の時点では、「システム」という単語を使わず、システムを使い続ける事に
よって顧客が得られる「利益」を定義する。
そしてその利益は、費用対効果が無いといけない。
□プロジェクトに失敗する原因
目標達成のために必要な情報を、知らないままor伝えないままにする。
→その原因は、
・知らないと言えない
・知らない事をばかにする、怒る
・説明を面倒臭がる
→その解決策は、
相互に理解した事を確認する。
自分や相手のポジション、知らない事、知っている事を把握する。
□仕様の策定方法
細かい所は、後から問題になってきて、しかもユーザーの不満をうみやすい。
細かいだけに、後から直しずらい。
→最初から詳細な仕様を作る。
(それが無駄にならない事が確認できた時点で)
委託契約の場合、手間がかからないほど利益が多いので、なぁなぁにしてしまいがち。
□コミュニケーションの基本
明るく話す！！
詳細に話す
事前に練習/レビューする。
□会議の実践術
・ホワイトボード活用法
→収集がつかなくなった時に、ホワイトボードに向かい、意見のありそうな人に、何を書きましょうか、と聞く！
すると、自然と話しが進んで行く。
・議事録
その場で作成し、声に出して読み上げる。
会議=プレゼンである。
最初に目的があって、その目的の方向へ引っ張っていく事。
□プロジェクト初期段階の工夫
最初のコンタクト時に、質問シートを渡そう！
・案件の目的
・最も求められている事
・別案件での苦い経験
・心配事
・組織構成
・現場見学の可否
・資料提供の可否
業務内容を、顧客よりも深く理解する事！
顧客業務分析
設計書の前段階の文書。要件確認よりも前。
最も重要な工程。徹底的に確認する。
→できれば、業務の現場を見る。実際に作業を行う。
顧客の放つ、用語の意味する内容を、詳細に理解する。
業務分析結果を、顧客にレビューしてもらう。
業務内の、今回の要求のスコープを明確にする。
顧客には、夢も含めて全てを話してもらい、実現可否は要相談とする。
プロトタイプを作る目的
・見せた時のリアクションを見る！
・開発側の理解を深める
スケジューリングのコツ
スケジュール最適化を行うタイミングをスケジュールする。
変更管理方針を、はじめから確定しておく。
□プロジェクト運営中の問題
責任追及が始まったら、プロジェクトは破綻する。
実作業者が、正しい行動ではなく、「怒られない」ための行動をしてしまうのは、より上位の人間の責任。
皆が同じ程度に悪い状況だから、自分の状況も許される、という意識がプロジェクト内に芽生えると、最悪の信号。 -
Posted by ブクログ
ネタバレ「業務システム」の開発について
基本的なことを広く書いている。
良い点は、「IT」の個別要素技術云々ではなく、
作りに入るまえの「業務システム」のデザイン部分が書いてある点。
重要だと理解してたけど、改めて言及してもらった、
という部分は以下。
・顧客業務の徹底理解をスタートダッシュで行う。
徐々にとか、設計レビュー時に説明されてる、とか、
やっているとあらゆる面で差が出る。
・顧客業務の理解について承認を得る。
・前提条件は自分で確認する
→PMBOKの「リスク特定プロセス」のツールと技法にある
「前提条件分析」
・前提条件は確定要素、リスクは不確定要素
・どんなに簡単でも可能な限り早く具体的実装を行い判断
・バーチャートよりもプロジェクト・ネットワーク図
（PMBOKでもこっちを利用）
・失敗PJの根源は、計画や計画活動に対する理解不足
