木村哲の作品一覧
「木村哲」の「セールスとエンジニアのためのIT提案戦術（日経BP Next ICT選書）」「遅延ゼロのプロジェクト・マネジメント講座――納期に追われるプロマネとリーダーが読む本」ほか、ユーザーレビューをお届けします！
- 作者をフォローする
- フォローすると、この作者の新刊が配信された際に、お知らせします。
作品一覧
-
ビジネス・実用
4.01巻2,508円 (税込)ITプロジェクトはその約75％に問題があると言われています。本書は，昨年まで大手メーカーやSIベンダで人気を博したマネージャー向け研修を書籍化したものです。納期の観点から，プロジェクト運営のあるべき姿，やるべき行動，さらに目から鱗のヒントを現場に則した形で解説します。PMBOKの教科書的な説明では語れない，明日から役に立つ発見が満載です。 -
ビジネス・実用
-1巻1,738円 (税込)※この商品はタブレットなど大きいディスプレイを備えた端末で読むことに適しています。また、文字だけを拡大することや、文字列のハイライト、検索、辞書の参照、引用などの機能が使用できません。 問題解決の思考法とノウハウ、失敗談、具体的なテクニック等を紹介します。 自作オーディオや電子工作を始める方、自力で設計・製作をしたいと考えている方、将来エンジニアを目指す方には必須の知識であり、必ずや次へのステップを踏み出す一助となることと思います。 -
ビジネス・実用
-1巻3,080円 (税込)ITベンダーに勤めるセールスエンジニア、営業担当者には必読の提案術マニュアル。 「既存顧客を奪われてしまった! 」「当て馬として扱われていないか?」「提案書を書くのに疲れた...」など様々なシーン別に、実践的で具体的な戦術を伝授する。 顧客アプローチから契約まで、提案力を向上させる秘訣が満載。 ≪目次≫ 【序章】 RFPに関する諸問題 低品質なRFPの流行 【第1章】 システム提案の基礎 ＜1-1＞ システム投資の流れを理解する ＜1-2＞ RFP（提案依頼書）とは ほか 【第2章】 RFI/上流工程戦術 ＜2-1＞ 既存顧客を持つベンダーの課題 ＜2-2＞ 既存ベンダーのための顧客戦術 ほか 【第3章】 RFP読解戦術 ＜3-1＞ RFPの構成と内容 ＜3-2＞ RFPを読む ほか 【第4章】 提案戦術 ＜4-1＞ 提案書の作成ガイド ほか 【第5章】 競合戦術 ＜5-1＞ 競合ベンダーを知る戦術 ほか 【第6章】 見積もり戦術 ＜6-1＞ 見積もりの方法 ほか 【第7章】 プレゼンテーション戦術 ＜7-1＞ プレゼンテーションの目的 ほか 【第8章】 評価と選定の裏側 ＜8-1＞ 選考基準は何か ＜8-2＞ 一次選考、二次選考 ほか 【終章】 何のためのRFPと提案書なのか Win-Winの関係を生むための要 -
ビジネス・実用
4.51巻4,180円 (税込)要求定義の「正しい手順」を提示し、圧倒的な支持を得た不朽の名著の改訂版。 「基幹系」と「情報系」、それぞれのシステムでの要求定義の手順を具体的かつ実践的に解説します。 筆者の豊富な経験に基づいたケーススタディとそのまま使える豊富なドキュメントサンプルで「いつ」「誰が」「何を」「どのように」「なぜ」やればよいかがわかります。 ≪目次≫ 【序章】 問題提起 ■要求定義の担当者はプロ集団ではない 【第1章】 要求定義を学び直す 1-1■良い要求定義とはどんなものか 1-2■良い要求定義を阻むものは何か 1-3■開発プロセスの中でどう位置付けるのか ほか 【第2章】 要求定義の手順を知る─基幹系システム編 2-1■基幹系システムのプロセス・マップの考え方 2-2■［プロセス1］ 戦略と目的を確立する 2-3■［プロセス2］ スコープを設定する ほか 【第3章】 要求定義の手順を知る─情報系システム編 3-1■情報系システムのプロセス・マップの考え方 3-2■［プロセス1］ 戦略と目的を確立する 3-3■［プロセス2］ スコープを設定する 3-4■［プロセス3］ 対象ユーザーを洗い出す 3-5■［プロセス4］ 現状を把握する ほか 【第4章】 要求定義のトラブル・シューティング 4-1■思い通りに進まない原因を潰す 4-2■トラブル・シューティング一覧
ユーザーレビュー
-
Posted by ブクログ
ユーザサイドの要求定義について、全体像とプロセスを例示しており、非常にわかりやすい内容だった。
現実的にRFP段階でここまで実践できている企業は少なく、
システム開発の要件定義で実施する事が多いだろう。
(システム開発の要件定義として見てしまうと、抜け漏れがあるように見えるため、本書の対象範囲に注意が必要。要求定義、という言葉事態が誤解されやすいところではあるが…）
本書の説明する業務内容は、一般的にはユーザ企業/コンサルティング会社/現行システムベンダーといった組織が関わる箇所になると思われる。
要求定義プロセスの中では、ユーザヒアリングからの新業務設計が非常に難しく、特に基幹業務の刷新 -
-
-
