Annexソフトウェア技術系を中心に掲載していきます。最近は自分の情報Indexと化しているかも。フリーコメントは「コメント&足あとBox」カテゴリー記事にて歓迎します。[提案・要件開発]対大手企業のシステムインテグレーションの受注活動ではRFPをベースに提案書を作成していく、そうした流れが一般的ではないでしょうか。ところが肝心のRFPが適切なものでなかったり、提案書も分量だけが多く実のないものになっていたり、そんなことが多々あるというのが実態ではないかと思います。本書はそうした状況を少しでも改善できるようにと書かれたもの、だと思います。これが教科書として手元にあったら、「あの時もっといいものができていたんじゃないかな」とか「もっとまともな対応ができたんじゃないかな」なんて思うことがたくさんありました。・・・RFPがちゃんと存在しているケースってどれだけあるんでしょうね。確かに大企業では用意されることが多いように思いましたが、そうでないケースも多々あったように思います。大企業以外では文書化されたRFPがないことのほうが一般的?ではないかとも思えます(そもそも受注の仕方がまったく違うのかもしれませんが)そんな環境でどれだけ役にたつのか、ちょっと疑問に思う点もありますが、知っていて損はない内容です。2.0」の日本語版発売開始IIBA日本支部のサイトで発売しています。2.0日本語版が年内に出る?!IIBA日本支部代表理事のインタビュー記事がITProで掲載されています。BABOKの必要性はその記事を見てもらうのが一番だと思いますので、ここでは言及しません。ポイントは記事の最後のほう・・・。IIBA本部との契約がまだ完了していないとのことですが、年内になんとか出るか??期待して待っちゃいましょうか。[提案・要件開発]私は個人的に、SIerが生き残るにはITコンサルティングサービスが必須であると考えています。この本の最初の部分を読んでますますその考えが強まりました。ITコンサルティングができなければどういったところで生き残るのだろう??そのように感じました。この本ではITコンサルティングを行うための基本的なキーワードが述べられています。この本だけでITコンサルティングができるとは思いませんが、少なくとも何をしなければいけないのかはわかると思います。自分はコンピュータサイエンスだけで生きていくんだ!!という方は別としてSIerに勤務されている方はぜひこの本でITコンサルティングの必要性を感じてください。虎の巻1ここで紹介されている案件進捗管理というのは、よくわかりますね~。この案件進捗をしっかりと押さえて、かつ次のアプローチをコントロールしていかないとなかなか効率的な受注活動につながらない。この記事ではそんな案件進捗管理を行ううえでの注意事項が述べられています。営業担当の方には当たり前かもしれませんが、後方支援しているSE部隊との思惑が違ったりすることもあり個人的には重要性を痛感しています。虎の巻2営業スタイル。今までの営業のやり方で正しい部分もいくつもありますが弊害になっている部分もあります。天下り・癒着などは問題外ですが、縦割り型や引きこもり型、そして二度手間営業などはあちこちで思い当たるところがあるのではないでしょうか。した部分は従来の営業と新たなSFAという武器を活用して向上していくことができると思います。[提案・要件開発]ITベンダーにとってはこれからのビジネスを考え直さなければならないうねりです。変化するユーザー企業の姿勢。ユーザー企業とITベンダーとで何かをやったとしても、結局一番業務をしっているのは「現場」の方。何をどうすべきかの課題を把握しているのは「現場」の方なのです。システムの要件定義は現場の方の声が反映されていなければならない。結局ユーザーが要件をまとめるしかないのです。そこでさらに開発までユーザー側で考えられたらITベンダーは何をすればいいのでしょう?今までのビジネスのやり方では生き残れないことは明白です。私の回答は以前から申し上げているとおり「ビジネスインテグレーター」という道。セールスプロセス改善:オファー合戦をしないセールスは交渉だ、といいつつ交渉がうまい人はそれほどいませんよね。低位の交渉術でなんとか受注をしようとしている。そんなセールスはなかなか成果がでないでしょう。そこで提示されているのがオファー合戦をしないセールス。うん、なるほど、と思わせる内容です。この記事を見つつ思い出したのがこちらの本。事前準備で半分以上が決まる、そういった内容が記事の内容と似ているなと思いました。交渉といっても相対した場だけが交渉ではないんですよね。敗者のシステムを分ける根本原因は何か。それは情報システム部の”思い”です。中・長期ビジョンを持ってシステムを構築しているのか、それともその場その場の対策だけで乗り切ってきてしまったのか、それが勝者・敗者を分ける部分です。したことからこの本ではターゲットを情報システム部門の担当者・管理者・CIOとしています。これだけの内容を顧客情報システム部門にしっかり握られたら私たちSIerは結構大変かも。どこまで理解していて、どこが自分たちが提案できる部分なのか理解するうえでもSIerにもこの本は必要かもしれません。SIerが海外発注をしますが、その方針について発注側から問われたりします。単価を下げるため、などと答えてしまうと「技術の空洞化はないのか、海外発注部分はブラックボックスにならないのか」など受注側の技術力を問われる質問を受けてしまいます。受注側としては技術の空洞化を防ぎつつ、戦略的に海外発注をしていることをしっかりと説明しなければなりません。情報システム部門・SIerがこの本の内容のレベルで話ができるのなら、最適化という面でも有益な議論ができるのではないかと想像します。難しいかもしれませんが、チャレンジしてみてはいかがでしょうか。プレゼン編」プレゼン編といってもいきなりパワーポイントの使い方とかではありません。最初に来るのが「エレベータ・テスト」というのがGLOBISらしいところ。「エレベータ・テスト」ときいてピンとこない方はぜひ読んだほうがいいです。いろんなことが知りたい、という方は「マッキンゼーのテクニックを盗め」、「考える技術・書く技術」、「実践!問題解決法」などを参考にするとよいとおもいます。あとは本格的なプレゼンテーションについては「パワープレゼンテーション」などがよいかと。「ユーザーがはっきりしない」と”ユーザーが決めて”くれる”ものと考えている方はつまずく人に入ります。そもそもユーザーは要求をまとめたり仕様化する(=要件)ことを本業とはしていません。基本的に要求・要件を決めて”くれる”と期待するのは無理なのです。した要求・要件を決める能力を持つべきなのは誰なのか?それはそれを必要とする人、それを生業とする人、つまり(IT)ベンダー側となります。成功するためには要求開発のような考え方が必要だと思います。ユーザーの要求・要件をまとめる上で参考になるのがコンサルティングファームが活用している手法ではないでしょうか。そんな理由からこのブログではコンサルティングに関する書籍を取り上げることが多くなっています(例えば『マッキンゼーのテクニックを盗め』)。『要求仕様のまとめ方』、『ソフトウェア要求』なども参考になります。BPMなども活用するとよりよいのではないかと最近は思っています。[提案・要件開発]「アイデアのちから」の具体性/抽象性に陥るのはなぜか:設計図と機械というところを読んでいて『これってソフトウェアでもよく当てはまるな~』と思ったことがあります。内容は設計者が図面を引き、製造者が実際に機械でものを作る想定です。ここで設計図どおりだと製造時にちょっとした問題が発生します。設計者はそれをきいていきなり図面を見渡し、原因を考えます。製造者が期待していたのはそんなことではなく、実際の現場でのちょっとした差異を修正したかっただけなのです。設計者が実際の問題を見ればすぐに解決したのにいきなり図面という抽象的なものに走ってしまうため解決策が余計に複雑になってしまったというものです。この本ではこれを『知の呪縛』と呼んでいます。設計者をソフトウェアの要件定義や基本設計、製造者を顧客に置き換えると要件定義のときになかなか話が進まないというものに似ていませんか?ソフトウェアの世界では全体を抽象化して考える傾向があります。要件定義の時からそうした思考が働きます。その抽象化したレベルで顧客と話すとどうもうまくいかない。ソフトウェア設計者が『知の呪縛』にとらわれてしまっているようです。実際の現場を見て、そしてそれを踏まえた具体例を示しながら説明すれば実はうまくいくのではないか?ということになります。私たちが具体的に話をすれば顧客はわかりやすいのではないか?そんなことを反省させられる内容でした。この『知の呪縛』を解消する方法として、言葉は明記されていませんがどうも「ペルソナ」という手法が使えそうです。担当者Aが何をやる、それを上司であるBが承認するというような形で現実に即した人物像を互いに描くことで、話がより具体的になりわかりやすくなるようです。これも「アイデアのちから」から学んだことですね。Dieで、直訳しようとすれば定着/焼付けになると思います。実際、本書の中では”記憶に焼き付く要素”という単語が主体になっています。『他人の意識・頭の中に残るアイデアとはどのようなものか』ということを解説しています。そのポイントはSUCCES(s)として表現されます(最後のsはおまけで英語のsuccess/成功に掛けたものになっています)。物語性これらの要素が揃ったものが他人の意識・頭に焼きつくものになります。「アイデアのちから」もこのSUCCESsを意識したタイトルになっているのではないでしょうか。素晴らしい発見、イメージも相手に的確に、しかも覚えてもらわなければ良いものにはなりません。英語のサブタイトルの通り死に行くアイデアになってしまいます。生き残るアイデアとするためにSUCCESsを意識していきましょう。..おはようございます。Q&Aこの広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。