「セールスとエンジニアのためのIT提案戦術」 [提案・要件開発]
対大手企業のシステムインテグレーションの受注活動ではRFPをベースに提案書を作成していく、そうした流れが一般的ではないでしょうか。ところが肝心のRFPが適切なものでなかったり、提案書も分量だけが多く実のないものになっていたり、そんなことが多々あるというのが実態ではないかと思います。
本書はそうした状況を少しでも改善できるようにと書かれたもの、だと思います。これが教科書として手元にあったら、「あの時もっといいものができていたんじゃないかな」とか「もっとまともな対応ができたんじゃないかな」なんて思うことがたくさんありました。
ただ・・・RFPがちゃんと存在しているケースってどれだけあるんでしょうね。確かに大企業では用意されることが多いように思いましたが、そうでないケースも多々あったように思います。まして大企業以外では文書化されたRFPがないことのほうが一般的？ではないかとも思えます（そもそも受注の仕方がまったく違うのかもしれませんが）
そんな環境でどれだけ役にたつのか、ちょっと疑問に思う点もありますが、知っていて損はない内容です。
本書はそうした状況を少しでも改善できるようにと書かれたもの、だと思います。これが教科書として手元にあったら、「あの時もっといいものができていたんじゃないかな」とか「もっとまともな対応ができたんじゃないかな」なんて思うことがたくさんありました。
ただ・・・RFPがちゃんと存在しているケースってどれだけあるんでしょうね。確かに大企業では用意されることが多いように思いましたが、そうでないケースも多々あったように思います。まして大企業以外では文書化されたRFPがないことのほうが一般的？ではないかとも思えます（そもそも受注の仕方がまったく違うのかもしれませんが）
そんな環境でどれだけ役にたつのか、ちょっと疑問に思う点もありますが、知っていて損はない内容です。
- 作者: 木村 哲
- 出版社/メーカー: 日経BP社
- 発売日: 2012/05/17
- メディア: 単行本（ソフトカバー）
BABOK 2.0日本語版発売！！ [提案・要件開発]
要求分析の知識体系「BABOK 2.0」の日本語版発売開始
IIBA日本支部のサイトで発売しています。
お待ちかねの方いらっしゃるのでは？？
IIBA日本支部のサイトで発売しています。
お待ちかねの方いらっしゃるのでは？？
BABOK 2.0日本語版が年内に出る？！
IIBA日本支部代表理事のインタビュー記事がITProで掲載されています。
BABOKの必要性はその記事を見てもらうのが一番だと思いますので、ここでは言及しません。
ポイントは記事の最後のほう・・・。
「今年は、日本語化したBABOKのバージョン2.0を書籍の形で出版するつもりです」
だって！！ IIBA本部との契約がまだ完了していないとのことですが、年内になんとか出るか？？
期待して待っちゃいましょうか。
IIBA日本支部 ： http://www.iiba-japan.org/
「この1冊ですべてわかる ITコンサルティングの基本」 [提案・要件開発]
私は個人的に、SIerが生き残るにはITコンサルティングサービスが必須であると考えています。
この本の最初の部分を読んでますますその考えが強まりました。ITコンサルティングができなければどういったところで生き残るのだろう？？そのように感じました。
この本ではITコンサルティングを行うための基本的なキーワードが述べられています。この本だけでITコンサルティングができるとは思いませんが、少なくとも何をしなければいけないのかはわかると思います。
自分はコンピュータサイエンスだけで生きていくんだ！！という方は別としてSIerに勤務されている方はぜひこの本でITコンサルティングの必要性を感じてください。
この本の最初の部分を読んでますますその考えが強まりました。ITコンサルティングができなければどういったところで生き残るのだろう？？そのように感じました。
この本ではITコンサルティングを行うための基本的なキーワードが述べられています。この本だけでITコンサルティングができるとは思いませんが、少なくとも何をしなければいけないのかはわかると思います。
自分はコンピュータサイエンスだけで生きていくんだ！！という方は別としてSIerに勤務されている方はぜひこの本でITコンサルティングの必要性を感じてください。
- 作者: 克元 亮
- 出版社/メーカー: 日本実業出版社
- 発売日: 2009/03/26
- メディア: 単行本（ソフトカバー）
INSIGHT NOW: 「BtoBのできる営業組織」 [提案・要件開発]
INSIGHT NOW ： BtoBのできる営業組織 虎の巻１
ここで紹介されている案件進捗管理というのは、よくわかりますね～。
この案件進捗をしっかりと押さえて、かつ次のアプローチをコントロールしていかないとなかなか効率的な受注活動につながらない。
この記事ではそんな案件進捗管理を行ううえでの注意事項が述べられています。営業担当の方には当たり前かもしれませんが、後方支援しているSE部隊との思惑が違ったりすることもあり個人的には重要性を痛感しています。
INSIGHT NOW ： BtoBのできる営業組織 虎の巻２
営業スタイル。今までの営業のやり方で正しい部分もいくつもありますが弊害になっている部分もあります。
天下り・癒着などは問題外ですが、縦割り型や引きこもり型、そして二度手間営業などはあちこちで思い当たるところがあるのではないでしょうか。こうした部分は従来の営業と新たなSFAという武器を活用して向上していくことができると思います。
ここで紹介されている案件進捗管理というのは、よくわかりますね～。
この案件進捗をしっかりと押さえて、かつ次のアプローチをコントロールしていかないとなかなか効率的な受注活動につながらない。
この記事ではそんな案件進捗管理を行ううえでの注意事項が述べられています。営業担当の方には当たり前かもしれませんが、後方支援しているSE部隊との思惑が違ったりすることもあり個人的には重要性を痛感しています。
INSIGHT NOW ： BtoBのできる営業組織 虎の巻２
営業スタイル。今までの営業のやり方で正しい部分もいくつもありますが弊害になっている部分もあります。
天下り・癒着などは問題外ですが、縦割り型や引きこもり型、そして二度手間営業などはあちこちで思い当たるところがあるのではないでしょうか。こうした部分は従来の営業と新たなSFAという武器を活用して向上していくことができると思います。
変化するユーザー企業の姿勢 [提案・要件開発]
ITベンダーにとってはこれからのビジネスを考え直さなければならないうねりです。
変化するユーザー企業の姿勢。
ユーザー企業とITベンダーとで何かをやったとしても、結局一番業務をしっているのは「現場」の方。
何をどうすべきかの課題を把握しているのは「現場」の方なのです。ですからシステムの要件定義は現場の方の声が反映されていなければならない。結局ユーザーが要件をまとめるしかないのです。
そこでさらに開発までユーザー側で考えられたらITベンダーは何をすればいいのでしょう？
今までのビジネスのやり方では生き残れないことは明白です。
私の回答は以前から申し上げているとおり「ビジネスインテグレーター」という道。
皆さんはどう思われますか？
変化するユーザー企業の姿勢。
ユーザー企業とITベンダーとで何かをやったとしても、結局一番業務をしっているのは「現場」の方。
何をどうすべきかの課題を把握しているのは「現場」の方なのです。ですからシステムの要件定義は現場の方の声が反映されていなければならない。結局ユーザーが要件をまとめるしかないのです。
そこでさらに開発までユーザー側で考えられたらITベンダーは何をすればいいのでしょう？
今までのビジネスのやり方では生き残れないことは明白です。
私の回答は以前から申し上げているとおり「ビジネスインテグレーター」という道。
皆さんはどう思われますか？
INSIGHT NOW: 「オファー合戦をしない」セールスプロセス改善 [提案・要件開発]
INSIGHT NOW!の記事です。セールスプロセス改善：オファー合戦をしない
セールスは交渉だ、といいつつ交渉がうまい人はそれほどいませんよね。
でもいまだに低位の交渉術でなんとか受注をしようとしている。そんなセールスはなかなか成果がでないでしょう。
そこで提示されているのがオファー合戦をしないセールス。うん、なるほど、と思わせる内容です。
で、この記事を見つつ思い出したのがこちらの本。3D交渉術。事前準備で半分以上が決まる、そういった内容が記事の内容と似ているなと思いました。交渉といっても相対した場だけが交渉ではないんですよね。
セールスは交渉だ、といいつつ交渉がうまい人はそれほどいませんよね。
でもいまだに低位の交渉術でなんとか受注をしようとしている。そんなセールスはなかなか成果がでないでしょう。
そこで提示されているのがオファー合戦をしないセールス。うん、なるほど、と思わせる内容です。
で、この記事を見つつ思い出したのがこちらの本。3D交渉術。事前準備で半分以上が決まる、そういった内容が記事の内容と似ているなと思いました。交渉といっても相対した場だけが交渉ではないんですよね。
- 作者: デービッド・A・ラックス/ジェームズ・K・セベニウス
- 出版社/メーカー: 阪急コミュニケーションズ
- 発売日: 2007/09/27
- メディア: ハードカバー
「勝者のシステム 敗者のシステム こうすればできる IT投資の適正化」 [提案・要件開発]
勝者のシステム 敗者のシステムを分ける根本原因は何か。それは情報システム部の”思い”です。
中・長期ビジョンを持ってシステムを構築しているのか、それともその場その場の対策だけで乗り切ってきてしまったのか、それが勝者・敗者を分ける部分です。
そうしたことからこの本ではターゲットを情報システム部門の担当者・管理者・CIOとしています。
しかしこれだけの内容を顧客情報システム部門にしっかり握られたら私たちSIerは結構大変かも。
どこまで理解していて、どこが自分たちが提案できる部分なのか理解するうえでもＳＩｅｒにもこの本は必要かもしれません。
例えば、ＳＩｅｒが海外発注をしますが、その方針について発注側から問われたりします。
単に単価を下げるため、などと答えてしまうと「技術の空洞化はないのか、海外発注部分はブラックボックスにならないのか」など受注側の技術力を問われる質問を受けてしまいます。受注側としては技術の空洞化を防ぎつつ、戦略的に海外発注をしていることをしっかりと説明しなければなりません。
しかし、情報システム部門・SIerがこの本の内容のレベルで話ができるのなら、最適化という面でも有益な議論ができるのではないかと想像します。ちょっと難しいかもしれませんが、チャレンジしてみてはいかがでしょうか。
中・長期ビジョンを持ってシステムを構築しているのか、それともその場その場の対策だけで乗り切ってきてしまったのか、それが勝者・敗者を分ける部分です。
そうしたことからこの本ではターゲットを情報システム部門の担当者・管理者・CIOとしています。
しかしこれだけの内容を顧客情報システム部門にしっかり握られたら私たちSIerは結構大変かも。
どこまで理解していて、どこが自分たちが提案できる部分なのか理解するうえでもＳＩｅｒにもこの本は必要かもしれません。
例えば、ＳＩｅｒが海外発注をしますが、その方針について発注側から問われたりします。
単に単価を下げるため、などと答えてしまうと「技術の空洞化はないのか、海外発注部分はブラックボックスにならないのか」など受注側の技術力を問われる質問を受けてしまいます。受注側としては技術の空洞化を防ぎつつ、戦略的に海外発注をしていることをしっかりと説明しなければなりません。
しかし、情報システム部門・SIerがこの本の内容のレベルで話ができるのなら、最適化という面でも有益な議論ができるのではないかと想像します。ちょっと難しいかもしれませんが、チャレンジしてみてはいかがでしょうか。
勝者のシステム 敗者のシステム こうすればできる IT投資の適正化
- 作者: 坂口 英弘
- 出版社/メーカー: ソフトバンククリエイティブ
- 発売日: 2006/01/31
- メディア: 単行本
GLOBIS.JP : プロフェッショナルスキル入門 プレゼン編 [提案・要件開発]
GLOBIS.JPの記事、「プロフェッショナルスキル入門 プレゼン編」
プレゼン編といってもいきなりパワーポイントの使い方とかではありません。
まず最初に来るのが「エレベータ・テスト」というのがGLOBISらしいところ。
「エレベータ・テスト」ときいてピンとこない方はぜひ読んだほうがいいです。
もっといろんなことが知りたい、という方は「マッキンゼーのテクニックを盗め」、「考える技術・書く技術」、「実践！問題解決法」などを参考にするとよいとおもいます。あとは本格的なプレゼンテーションについては「パワープレゼンテーション」などがよいかと。
プレゼン編といってもいきなりパワーポイントの使い方とかではありません。
まず最初に来るのが「エレベータ・テスト」というのがGLOBISらしいところ。
「エレベータ・テスト」ときいてピンとこない方はぜひ読んだほうがいいです。
もっといろんなことが知りたい、という方は「マッキンゼーのテクニックを盗め」、「考える技術・書く技術」、「実践！問題解決法」などを参考にするとよいとおもいます。あとは本格的なプレゼンテーションについては「パワープレゼンテーション」などがよいかと。
「上流工程で成功する人、つまずく人」 [提案・要件開発]
本書でも書かれていますが要求・要件について
「ユーザーが決めてくれない」
「ユーザーがはっきりしない」
と”ユーザーが決めて”くれる”ものと考えている方はつまずく人に入ります。
そもそもユーザーは要求をまとめたり仕様化する（＝要件）ことを本業とはしていません。基本的に要求・要件を決めて”くれる”と期待するのは無理なのです。
ではそうした要求・要件を決める能力を持つべきなのは誰なのか？それはそれを必要とする人、それを生業とする人、つまり（IT）ベンダー側となります。
このように要求・要件はユーザーは決められないものだ、ITベンダーが「開発」していくものだとしているのがOpenThologyの要求開発。上流工程で成功するためには要求開発のような考え方が必要だと思います。
また、ユーザーの要求・要件をまとめる上で参考になるのがコンサルティングファームが活用している手法ではないでしょうか。そんな理由からこのブログではコンサルティングに関する書籍を取り上げることが多くなっています（例えば『マッキンゼーのテクニックを盗め』）。
『要求仕様のまとめ方』、『ソフトウェア要求』なども参考になります。
さらにBPMなども活用するとよりよいのではないかと最近は思っています。
「ユーザーが決めてくれない」
「ユーザーがはっきりしない」
と”ユーザーが決めて”くれる”ものと考えている方はつまずく人に入ります。
そもそもユーザーは要求をまとめたり仕様化する（＝要件）ことを本業とはしていません。基本的に要求・要件を決めて”くれる”と期待するのは無理なのです。
ではそうした要求・要件を決める能力を持つべきなのは誰なのか？それはそれを必要とする人、それを生業とする人、つまり（IT）ベンダー側となります。
このように要求・要件はユーザーは決められないものだ、ITベンダーが「開発」していくものだとしているのがOpenThologyの要求開発。上流工程で成功するためには要求開発のような考え方が必要だと思います。
また、ユーザーの要求・要件をまとめる上で参考になるのがコンサルティングファームが活用している手法ではないでしょうか。そんな理由からこのブログではコンサルティングに関する書籍を取り上げることが多くなっています（例えば『マッキンゼーのテクニックを盗め』）。
『要求仕様のまとめ方』、『ソフトウェア要求』なども参考になります。
さらにBPMなども活用するとよりよいのではないかと最近は思っています。
- 作者: 荒井 玲子
- 出版社/メーカー: 技術評論社
- 発売日: 2009/01/24
- メディア: 新書
- 作者: 山岸 耕二
- 出版社/メーカー: 日経BP社
- 発売日: 2006/03/02
- メディア: 単行本
抽象化のわな [提案・要件開発]
「アイデアのちから」の具体性／抽象性に陥るのはなぜか：設計図と機械というところを読んでいて
『これってソフトウェアでもよく当てはまるな～』
と思ったことがあります。
内容は設計者が図面を引き、製造者が実際に機械でものを作る想定です。
ここで設計図どおりだと製造時にちょっとした問題が発生します。設計者はそれをきいていきなり図面を見渡し、原因を考えます。しかし製造者が期待していたのはそんなことではなく、実際の現場でのちょっとした差異を修正したかっただけなのです。設計者が実際の問題を見ればすぐに解決したのにいきなり図面という抽象的なものに走ってしまうため解決策が余計に複雑になってしまったというものです。この本ではこれを『知の呪縛』と呼んでいます。
設計者をソフトウェアの要件定義や基本設計、製造者を顧客に置き換えると要件定義のときになかなか話が進まないというものに似ていませんか？ソフトウェアの世界では全体を抽象化して考える傾向があります。ですから要件定義の時からそうした思考が働きます。その抽象化したレベルで顧客と話すとどうもうまくいかない。ソフトウェア設計者が『知の呪縛』にとらわれてしまっているようです。
でも実際の現場を見て、そしてそれを踏まえた具体例を示しながら説明すれば実はうまくいくのではないか？ということになります。
もっと私たちが具体的に話をすれば顧客はわかりやすいのではないか？そんなことを反省させられる内容でした。
また、この『知の呪縛』を解消する方法として、言葉は明記されていませんがどうも「ペルソナ」という手法が使えそうです。担当者Aが何をやる、それを上司であるBが承認するというような形で現実に即した人物像を互いに描くことで、話がより具体的になりわかりやすくなるようです。これも「アイデアのちから」から学んだことですね。
『これってソフトウェアでもよく当てはまるな～』
と思ったことがあります。
内容は設計者が図面を引き、製造者が実際に機械でものを作る想定です。
ここで設計図どおりだと製造時にちょっとした問題が発生します。設計者はそれをきいていきなり図面を見渡し、原因を考えます。しかし製造者が期待していたのはそんなことではなく、実際の現場でのちょっとした差異を修正したかっただけなのです。設計者が実際の問題を見ればすぐに解決したのにいきなり図面という抽象的なものに走ってしまうため解決策が余計に複雑になってしまったというものです。この本ではこれを『知の呪縛』と呼んでいます。
設計者をソフトウェアの要件定義や基本設計、製造者を顧客に置き換えると要件定義のときになかなか話が進まないというものに似ていませんか？ソフトウェアの世界では全体を抽象化して考える傾向があります。ですから要件定義の時からそうした思考が働きます。その抽象化したレベルで顧客と話すとどうもうまくいかない。ソフトウェア設計者が『知の呪縛』にとらわれてしまっているようです。
でも実際の現場を見て、そしてそれを踏まえた具体例を示しながら説明すれば実はうまくいくのではないか？ということになります。
もっと私たちが具体的に話をすれば顧客はわかりやすいのではないか？そんなことを反省させられる内容でした。
また、この『知の呪縛』を解消する方法として、言葉は明記されていませんがどうも「ペルソナ」という手法が使えそうです。担当者Aが何をやる、それを上司であるBが承認するというような形で現実に即した人物像を互いに描くことで、話がより具体的になりわかりやすくなるようです。これも「アイデアのちから」から学んだことですね。
ペルソナ作って、それからどうするの? ユーザー中心デザインで作るWebサイト
- 作者: 棚橋 弘季
- 出版社/メーカー: ソフトバンククリエイティブ
- 発売日: 2008/05/30
- メディア: 大型本
Webサイト設計のためのペルソナ手法の教科書 ~ペルソナ活用によるユーザ中心ウェブサイト実践構築ガイド~ (DESIGN IT!BOOKS)
- 作者: Ziv Yaar
- 出版社/メーカー: 毎日コミュニケーションズ
- 発売日: 2008/02/23
- メディア: 単行本（ソフトカバー）
「アイデアのちから」
本書の原題は
Made to Stick Why Some Ideas Survive and Others Die
で、直訳しようとすれば
定着／焼付け
になると思います。実際、本書の中では”記憶に焼き付く要素”という単語が主体になっています。
「アイデアのちから」というタイトルを聞くとどうやってアイデアを生むかという内容を期待する方もいるかと思いますが本書では、
『他人の意識・頭の中に残るアイデアとはどのようなものか』
ということを解説しています。
そのポイントはSUCCES(s)として表現されます（最後のsはおまけで英語のsuccess／成功に掛けたものになっています）。
S : Simple 単純明快
U : Unexpected 意外性
C : Concrete 具体的
C : Credible 信頼性
E : Emotional 感情に訴える
S : Story 物語性
これらの要素が揃ったものが他人の意識・頭に焼きつくものになります。
「アイデアのちから」もこのSUCCESsを意識したタイトルになっているのではないでしょうか。
素晴らしい発見、イメージも相手に的確に、しかも覚えてもらわなければ良いものにはなりません。
英語のサブタイトルの通り死に行くアイデアになってしまいます。
生き残るアイデアとするためにSUCCESsを意識していきましょう。
- 作者: チップ・ハース
- 出版社/メーカー: 日経BP社
- 発売日: 2008/11/06
- メディア: 単行本（ソフトカバー）
たーとる さん
-
nice! 475
記事 4429
テーマ パソコン・インターネット
プロフィール
ブログを紹介する
携帯版URL
