第9回 訪問が「受注」につながらないと無意味、受注の極意を学ぶ
この連載ではSEから営業職に転向した人に向けて、SEの強みを生かした「ロジカルセールス」の進め方を筆者の経験とノウハウを基に説明しています。 前回（商品訴求に「笑い」も大切、スベっても気にするな）までで、アポの取り方（第2回、第3回）、初回訪問の心得（第4回）、環境準備（第5回）、会社説明（第6回）、商品説明（第7回、第8回）を取り上げました。 いよいよ営業折衝の「クロージング」に向かいます。ターゲット顧客への営業活動が受注につながらないようでは意味がありません。営業は受注のために働いているといっても過言ではありません。 訪問を終えるにあたり、どうすれば相手から受注できるのでしょうか。今回はこの点についてお話しします。 営業折衝の結果が「受注」 「商品を説明するのは得意ですが、受注に話を持っていくのがどうも苦手です。お客さんに『注文ください』とはなかなか言いづらいのですが…」 よく、こんな
第8回 商品訴求に「笑い」も大切、スベっても気にするな
この連載ではSEから営業職に転向した人に向けて、SEの強みを生かした「ロジカルセールス」の進め方を筆者の経験とノウハウを基に説明しています。 前回（受注につながる商品説明、価値を絞り込んで印象付け）はターゲット顧客への初回訪問時の商品説明を取り上げました。商品の機能や特徴といった「価値」を顧客のニーズに合わせて絞り込み、印象付けるテクニックを使うことが大切だとお話ししました。 今回はその続きです。商品説明での間接価値の使い方や、前回ご紹介していないテクニック、顧客の絞り方を説明します。 商品説明に役立つ間接価値 顧客に提供する価値には、顧客の直接的なメリットにつながる「直接価値」と、顧客のメリットにつながる可能性のある商品に関わる情報である「間接価値」があるというのは、この連載で何回かご説明しました。詳しくは第5回をご覧ください。 中でも間接価値は多様で種類もたくさんあり、説明する際の使い
第7回 受注につながる商品説明、価値を絞り込んで印象付け
この連載ではSEから営業職に転向した人に向けて、SEの強みを生かした「ロジカルセールス」の進め方を筆者の経験とノウハウを基に説明しています。以下の営業シーンについて、採るべきアクションや、その背後にあるロジックを解説しています。 アポイントメント 訪問（環境準備、会社説明、商品説明） クロージング 値引き対応 第2回（「アポ取り電話地獄」から逃れる方策は？）と第3回（ストーリーとテクニックを駆使してアポ取り名人になる）でアポの取り方、第4回（客先訪問は「初回」が勝負、絶対にやるべきことは？）で初回訪問の心得、第5回（普通の営業折衝で受注は困難、テクニックを生かそう）で環境準備、第6回（「会社説明」を侮るのは禁物、やり方次第で受注確度は上がる）で会社説明について説明しました。それぞれについて、ぜひおさらいしてみてください。 会社説明まで終わり、いよいよ受注したいと考えている商品の説明に入りま
第11回 プロマネのこんなアサインは「トラブルのもと」
プロジェクト管理に関する本や研修やセミナーなどは実に多い。そして「プロジェクト管理はこうだ。システム開発はこうだ」などと色々と語られている。だが、中小規模のプロジェクトと大規模なプロジェクトのやり方の相違点や注意点については、ほとんど言及されていない。 すると、それを学んだ多くのSEはプロジェクトの規模に関係なく「プロジェクト管理やシステム開発はこうやるもんだ」と往々にして一律に考える。事実、そう考えてプロジェクトをやっているSEは少なくない。これはIT企業の経営者や営業なども、しかりである。 だが、筆者の経験からみると、それには少なからず疑問を感じる。それは、大規模プロジェクトをやったSEが中小規模のプロジェクトをやると、往々にしてトラブルを起こすからだ。また、中小規模のプロジェクトをうまくやっていたSEが大規模プロジェクトをやる場合もトラブルを起こすケースが多い。それで多くのIT企業が
ユーザーに遠慮するSEはバカになる
「利用部門から機能追加や画面変更などの改修要望があったとき、人手に余裕があれば、具体的な内容を確認してそのまま受け入れてしまうSEが多い」。先日、あるITコンサルタントA氏に取材したとき、こんな話を聞いた。 システムの保守開発において、改修要望をそのまま受け入れることの何がダメなのか。A氏によると、利用部門にとって本当に役立つ改修にはならないことがあるという。 「利用部門が上げてきた改修要望の背景には、業務やシステムを改善したいという目的がある。その目的を聞いた上で、ITの専門家として最適な解決策を示すべきだ。利用部門からの要望は、自分たちで思い付いた解決策にすぎない」とA氏は指摘する。 端的な例を挙げよう。グループウエアのスケジュール管理画面で「他の社員のスケジュールに会議予定を登録する際、既存の社員選択ポップアップ画面（部門別のツリー構造タイプ）は使い勝手が悪い。よく使う社員名を登録し
第9回 「今の仕事をしていて大丈夫か」と悩む若手SEへの三つの助言
SEにはいろんな仕事をしている人がいる。大規模プロジェクトで仕事をしているSEもいれば、小規模プロジェクトを担当しているSEもいる。また保守の仕事をやっているSEもいれば、販売活動をしているSEもいる。 そしてプロジェクトをやっているSEには、要件定義を行っているSEもいれば、アプリケーションの設計やプログラムの開発を担当しているSE、ネットワークを担当しているSE、OSを担当しているSEなど、いろんなSEがいる。また、担当している顧客は大企業から中小企業まで様々である。そしてSEが関わっているシステムやIT製品には、仕事によって先進的なものから古いものまでいろいろある。 そんな仕事をしているSEは、ビジネスと顧客のために日ごろ懸命に頑張っている。だが、彼ら彼女ら全員が全員、自分がやりたい好きな仕事をやっているわけではない。気が進まない仕事をやっているSEもいれば、与えられた仕事を仕方なく
第7回 ITだけにかじり付くSEは、いつか“落ちこぼれる”
SEは年齢と共に成長しなければならない。すなわち、SEは20代、30代、40代、50代とその年齢相応の仕事ができなければならない。そうでないと日ごろイキイキと働けないし、会社から見ると給料を上げるわけにはいかない。 こんなことを言うと、20代、30代半ばくらいまでのSEの方は「そんなことは当たり前ではないか」と思うだろうが、SEの世界ではそれが当たり前とは言えない。事実、それで苦労しているベテランSEが日本のIT業界には少なくない。 SE人生は30代半ばまでで約4分の1（25％）、それ以降が4分の3（75％）である。多くのSEは30代半ばまでの4分の1ではどんどん成長し、毎日イキイキとモラール高く働く。しかし残りの4分の3もそのまま成長すれば良いが、必ずしもそうではない。どんどん成長してリーダーシップを発揮し、イキイキ働いているSEはもちろんいる。だが、そうでもないSEも少なくない。 そん
第6回 （続）チームワークに弱いSEは第一線には不要
前回（チームワークに弱いSEは第一線には不要）に引き続き、今回もSEのチームワークについて書く。前回は概略、次のようなことを述べた。 今のITの世界には、膨大な数のシステムや製品がある。するとシステム開発や提案活動は、アプリケーション、OS、ネットワークなど各分野に強いSEがチームを組んで行わないと、質の高い仕事はできない。また、難しいトラブルや設計などで仲間が困っていれば、それに強いSEが飛び込んで助けないと、お客様に迷惑をかける。今のSEという職業は、本質的にこのような職業である。 また、SEのチームワークが良いと、若手SEの早期戦力化が図れるし、中堅・ベテランSEを幅の広いSEに育てることができる。だが、今も昔もIT業界のSEのチームワークは決して良いとは言えない。それはジョブアサインのやり方や、SEの仕事に対する考え方・価値感がバラバラであることに起因する。 おおよそ、このようなこ
第5回 チームワークに弱いSEは第一線には不要
サッカーやラグビーなどスポーツの世界では、選手のチームワークが極めて重要である。選手個々人が優れた技術力を持ち、お互い連携し助け合いながら自分のポジションの役割を果たす。そして一丸となって、勝利に向かって突き進む。そんなチームは強い。 第一線のSEの世界も同様である。SE一人ひとりが高いスキルを持ち、お互い連携し助け合い、切磋琢磨しながら一つのゴールに向かって仕事をする。そんなSEチームはしっかりした仕事をする。生産性も高い。 だが、現実のIT業界のSEのチームワークは、今も昔も決して良いとは言えない。ある意味でSEのチームワークは、IT業界の永遠の課題とも言える。 日本のIT企業では「プロジェクトがトラブルに陥る」「SEが育たない」と当たり前のようによく言われる。筆者は、それらは全てSEのチームワークと無関係ではないと考えている。そこで今回は、このSEのチームワークについて述べる。 SE
技術者はSEになるな、「何でも屋」になれ
今回の「極言暴論」のタイトルを見て、「何を言っているんだ。こいつ」と思った読者も多いはずだ。前回の記事では、「何でも屋」としてのSEがプロジェクトマネジャーの役割まで担うことの弊害を説いたはずなのに、舌の根も乾かぬうちに奇妙な主張をするとは（関連記事：技術者をプロジェクトマネジャーにするな）。私が読者でも、そう呆れてしまう。 だが実は、同じ「何でも屋」でも、前回と今回の話では前提が違う。前回のような「何でも屋」としてのSEが活躍するのは、これまでのウォーターフォール型の開発プロジェクトの世界だ。いわゆる基幹系システム、つまりバックヤード、間接業務などの比較的要件がはっきりしているシステムをスクラッチで作るような従来型のシステム開発を想定している。 一方、今回暴論しようと思う話は、ビジネス直結のシステム、つまり新ビジネスの創出やビジネスモデルの変革に取り組む際のシステム開発を前提にしている。
業務やアプリを知らないSEの四つの弱点
SEはピンチに陥った時にどんな姿勢・態度でSEマネジャーと相談すれば良いか。「切り開け！」シリーズの前回（ピンチに強いSEは「どうしたら良いでしょうか」と言わない）はそれについて述べた。今回は第4回を書く。 アプリケーション軽視の状況が長年続く 顧客は営業や工場、人事・経理など、いろんなシステムを開発する。その目的は企業の競争力の強化や生産性の向上などを図るためである。コンピュータはあくまでもそのための道具である。顧客にとってはアプリケーションが先で、コンピュータはあくまでも後である。 そのようなシステムを受注して開発するIT企業には、顧客の業界や業務、アプリケーションが分かるSEが不可欠である。ITに強いSEばかりでは、まともなシステム開発はできない。特に元請けのIT企業にはこのことが要求される。これには誰しも異論はないと思う。 だが、筆者には日本のIT企業やSEはアプリケーションをあま
ピンチに強いSEは「どうしたら良いでしょうか」と言わない
今年から「SEは自らの手で明日を切り開け！」シリーズを書いている。第1回（SEは20代でSE人生の8～9割が決まる）は、SEは20代にどんな仕事をしたか、どんな先輩や上司と仕事をしたか、そのSEの生い立ちがSE人生を大きく左右すると述べた。第2回（20代にマルチで仕事をしたSEは早く成長する）では、SEは若いうちにマルチで仕事をすることが重要であると述べた。 連載には、多くの賛同のコメントを頂いた。コメントの中には「納得がいかない」というものも2、3あったが、いずれにしても多くの読者の方々が何か感じていただければ幸いである。そこで今回は第3回を書く。 問題にはケースバイケースの対応が要求される SEは仕事をしていると、いろんな問題にぶつかる。例えば、システム開発で要件が増えそうになった、プロジェクトのスケジュールが遅れた、コストがオーバーしそうになった、難しいバグにぶつかった、また顧客の部
SEはこんなSEマネージャーにはついてこない
この「SEマネージャーよ逞しくなれ！」の連載も丸1年を迎える。これまで、SEが抱えている問題を解決するためにSEマネージャーがやるべきことを色々と書いてきた。第一線のSEマネージャーは趣旨を理解して、ぜひ“SEの体制図と技術偏重の問題”に取り組んでほしい。また将来SEマネージャーになろうと思っている方も、SEマネージャーになったらぜひこの問題に挑戦してもらいたい。それを願って、これまで1年にわたってこの連載を書いてきた。そうでないと、かなり高い確率でSEマネージャー自身がSE時代に味わった苦労を後輩のSEに味わわせることになる。
なぜ日本のユーザー企業はIT企業に体制図や人月を求めるのか
日本の多くのIT企業は、システム開発などを売り込む際に「提案しているプロジェクトはこのSE体制で行います。予定人月は〇〇人月です」とユーザー企業に体制図や人月を提示する。こんなビジネスのやり方は、もともとメインフレーム時代に買い手の顧客が「このシステムを契約すればSEを何人つけるのか」と問い、売り手のIT企業は「このシステムを買っていただければSEを○○人つけます」と答えた当時のビジネスのやり方からきている。 そしてサービス時代になった今でも、この慣習が続いている。あたかも“SEをモノ扱い”したビジネスのやり方である。筆者はこんなビジネスのやり方が、日本のSEの「技術偏重・ビジネス意識の乏しさ」や「受身的な姿勢・顧客との壁作り」などを招いていると考えている。このため、これまで、「IT企業は顧客に体制図を出すな。SEの人月の提示や常駐をやめろ」としつこく言い続けてきた。それは、SEがこんな状
少数精鋭のSE集団作りを目指せ
日本のSEは、日夜頑張ってシステム開発などの仕事をしている。そして会社を支えている。だが、多くのSEが営業や会社はSEを分かっていないなどと結構不満を持っている。しかし、SE自身も技術偏重、受け身意識、ビジネス意識の希薄さなどの問題がある。そんな状況がIT業界では30年も40年も続いている。 筆者はIT業界で生きてきた人間として、この問題を何とか解決したいと思い、長年、IT業界の方々に問題提起をしてきた。たぶん15年ぐらい、日経コンピュータやブログや講演などで、それを多くの方々に訴えていると思う。これはある意味で筆者の執念でもある。それは「IT業界のSEは伝統的なSEの世界から脱皮し、技術者としての誇りと当事者意識を持ってイキイキと働いてほしい」「そうなれば、SEは必ず顧客に頼りにされ顧客と一体感も増す。するとプロジェクトはうまくいくし、技術者として顧客の相談相手にもなれる。もちろん、IT
SEマネージャーの約半分はひとりでは顧客に行けない
前回、第一線のSEマネージャーの方にぜひ行ってほしい4つの行動について述べた。その行動とは以下の4つである。 顧客を一人でぶらっと訪問する 部下がやっている仕事やプロジェクトを自分でレビューする 営業と積極的にビジネスの話しをして販売活動に強くなる 社内の支援部門やパートナー企業に顔を出す これらは、上手くできるかどうかを別にすれば誰にでもできる事柄である。足があれば顧客にも行けるし、パートナー企業にも行ける。口があればSEや営業と話ができるし、仕事のレビューもできる。 SEマネージャーは、この4つの行動を継続してやっていれば必ず顧客や営業・SEに信頼されるようになる。その中心となるのが、“顧客を知る”ために行う「一人でぶらっと訪問」である。それは、SEマネージャーは顧客が分かっていないと、ほかの3つの「SEがやっている仕事やプロジェクトのレビュー」や「営業とビジネスの話をする」「社内の支
コレができないSEマネージャーは信頼されない
前回、SEマネージャーのチェックリストについて説明した。きっとSEマネージャーの方は自己評価をされたと思う。また、読者のSEの方や営業の方も「あのSEマネージャーはこれは○だがこれは×だな」などと評されたものと推測する。 いずれにしても第一線のSEマネージャーは、程度の差はあっても顧客や営業・SEと信頼関係がないことにはSEマネージャーの職務の「ビジネス目標の達成と部下の育成」を全うすることはできない。もちろん、SEが長年抱えている技術偏重、ビジネス意識の薄さ、仕事に対する受身姿勢、営業に対する不満などの問題は解決できない。そのためには、自己評価で×や△が多いSEマネージャーの方は「自分はどうすれば良いか」を、ぜひ真正面から考えてほしい。 「忙しい」とか「話は分かるがそれは理想論だ」などと言って逃げないでほしい。SE部長の方は、部下のSEマネージャーがそうならないように前回のチェックリスト
優秀だった若手が30代になって優秀ではなくなる訳
部下のシステムズエンジニア（SE）を巡り、役員や事業部長とSE部課長が次のようなやり取りをする場面を目にしたことはないだろうか。 「20代の頃バリバリやっていた吉田君（仮名）、最近も元気かね」 「実は伸び悩んでいます。入社して15年目、年齢相応の成果を出してもらいたいのですが」 「困ったね。もう一人、中村さん（仮名）も目立っていたが」 「彼女も30歳を超えてから壁に突き当たっていますね」 「・・・」 「彼はできる」「彼女は優秀」とかつて言われた若手が、30代になるとパっとしなくなるという話をよく耳にする。どうしてなのか。 理由は色々と考えられる。同一の開発現場にずっと常駐させてきたから、知らず知らずのうちに本人は飽きているのではないか。後輩をなかなか配属できず、30代になっても現場で最年少のままだからか。顧客の要請で長年使ってきた開発言語やデータベース管理システムを急に変更したため、従来の
かつて、私の隣にSQLの魔女がいた
今日プロジェクトの打ち上げがあったのだが、とあるサプライズ……三ヶ月前に寿退社した先輩との再会に思わず涙ぐんでしまい、ひどくばつが悪い思いをしている。今も顔の火照りが抜けてくれない。アルコールは抜けたのに。彼女はかつてSQLの魔女と呼ばれていた。 今から遡ること一年前、私は辞令を貰い、二年目にして事業部ごと変わるという波乱をようやく乗り切って、業務系のSEの仕事内容、特にWebのアプリレイヤーについてOJT形式で学んでいた。そこで先生にあたる方として付いたのが、ちょうど手待ちだった先輩である。初めてお会いした時の先輩に対し、私は正直ちょっと物足りなく感じていた。 初日に行ったPCのセッティングでは、これやってと先輩から資料を渡されたのだが、外部にネットが繋がらない。先輩に相談して弄ってもらったのだけど繋がらず、今日は社内ネットで我慢して、と言われてから二日後、資料が古かったことが判明。 与
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SEにとって技術は必要条件だが十分条件ではない