分すべては提案活動から2008年秋以降,景気が急速に悪化し,多くの企業は設備投資を控えています。システム投資においても,経費削減に即効性が期待できるもの,システム導入しなければならない理由があるものを除き,買い控えをしているケースが多いようです。IT業界は不況の影響を大きく受けている業種の1つでしょう。過去を振り返ると,1990年代のバブル景気崩壊後の数年間も同じような状況がありました。バブル崩壊からIT業界が復活した経緯は,1995年頃からWindowsや電子メールシステムを始めとしたグループウェアが登場し,現在では当たり前となっているPCの導入やLAN構築等のインフラ整備をするお客様が増えはじめたことによると思います。オープンシステム(※1)が登場したのもこの頃です。お客様の立場からすると,ハードウェアベンダーに依存しなくても様々なベンダーとの取引が選択できる機会が広がり,より良い提案を受ける機会が格段に増えたのです。ITベンダーにとっては,これまでお客様から個別に受けていた提案依頼が複数のベンダーに出されるため,過当競争となりました。1990年代後半からこの競争が急速に加速していきました。私自身,会社対会社で永年付き合ってきたお客様が,別のベンダーに声を掛けて本気で提案依頼を受ける場面に遭遇し,「⁠これまで一緒に苦労してきたのに,そりゃないよ」と思うこともこの頃から増えました。ひとつひとつの提案で競合他社から受注を勝ち取ることは,競争相手が増えたことにより,一層大変になりました。2000年代に入り競争は更に激化していきましたが,ゆるやかながらも景気が右肩上がりだったため,各社は競って事業を拡大していきました。サブプライムローン問題に端を発した不況で需要は急激に落ち込み,本当の意味でお客様への価値を提案できるベンダーしか生き残れない時代を迎えています。提案力のないベンダーは市場から退場しなければならない時代がやってきました。今回は,提案活動におけるエンジニアのジレンマについて考えてみたいと思います。※11990年前半まではハードメーカ独自の仕様でシステム構築が行われていました。そのため,ハードウェアを採用して頂くことは長い間に渡って,その企業のシステムパートナーとして採用していただくことを意味していました。一度ハードウェアを導入したお客様に対して,他社にシステム構築を受注される(リプレースといいます)ことは比較的少なかった代わりに,エンジニアは自社独自のシステム仕様を理解する必要がありました。提案依頼に至るまでの道のり著者は主に製造業のお客様を担当しています。製造業のお客様の多くは,生産管理システム(※2)を導入するにあたり,半年~数年の間,システム導入検討を行うのが一般的です。一度ベンダーを決定すると比較的長く導入したシステムを利用するのも特徴です。そのため,案件が成熟する早い段階からお客様にアプローチを行い,案件化するまでに長い時間をかけて,お客様との信頼関係を構築するプロセスが大変重要となります(※3⁠)⁠。多額の投資を行う上,最低でも5年以上の長い付き合いを行うベンダー選定は慎重に行われるのです。実際,2週間以内に提案書を提出するようにといわれ,徹夜で何百枚もの提案資料を作成したにも関わらず,簡単に落とされた経験は何度もあります。※2生産管理システムは,工場で管理している生産計画や在庫を管理し生産を効率化するシステムのことで,効率のよい生産計画,正確な在庫把握,品物毎の原価を把握する等を実現することが目的です。企業の重要なシステムは基幹システムと呼ばれますが,多くの製造業にとって,生産管理システムは基幹システムです。基幹システムの出来によって,会社の競争力に大きな影響を及ぼします。※3突然,お客様から生産管理システムを導入するから提案するようにと頂いた引き合いは,十分に検討がされていないか,本命がすでにいる当て馬の可能性を疑った方がよいでしょう。営業とSEの立場の違い案件が成熟するまでのお客様との関係構築は,主に営業の仕事になります。営業はすぐに案件化するかどうかを見極めながら見込み客を探し,長い時間を掛けて,お客様との関係を構築していきます。苦労の末,見積依頼がお客様より出た際には,必死にお客様の見積依頼に応えようとするのは当たり前のことです。この時点で,執念も熱意もない営業は,受注はまず取れないと考えていいでしょう。種から育ててきた案件を刈り取る営業の醍醐味といえます。ある時,営業から永年狙いをつけていたお客様より,生産管理システムの引き合いを頂いたとの報告を受けました。商談になったお客様は,営業が実に5年間も定期的に通いつづけていました。見積を行いましたが,結論を述べると,そのお客様の予算とわが社が見積もりした価格には倍以上の大きな乖離がありました。お客様の話を聞けば聞くほど,簡単なシステム導入ではなく,それなりの費用が掛ることが分かってきたのです。その際,営業担当者は血相を変えて,システムエンジニアである著者に迫りました。「今回は,戦略受注でやりたい。「見積金額に合わせて機能を絞って提案できないか?それがプロの仕事だろう。機能が膨らめば別見積りで提案するから」まさに押したり引いたりで,営業担当者も必死に迫ります。システムエンジニアの立場では,受注が決まった後にお客様に迷惑を掛けないことがもっとも大切な責務です。一度トラブルが発生してしまえば,見積額はすぐに4~5倍に膨れあがります。約束した納期も守れなくなってしまいます。何とかしたい,しなければならないと思いながら,どうしてもリスクを考えてしまいます。営業とシステムエンジニアはお互いの立場を理解しながら,受注獲得に向けて大きなジレンマを産みます。幸いにして落とし所を見つけても,競合他社が普通では考えられないすごい提案をしてくることもしばしばです。負ければ,これまでの苦労はゼロになってしまいます。営業に引っ張られるように,どんどん提案はエスカレートし,最終的には値引合戦となっていきました。それでも,「⁠提案から降りよう」「⁠それなりの金額を提示して綺麗な形で落とされよう」と,口が裂けても営業にはいえませんでした。幸いにも,この注文は最終的に著者が腹をくくる形で,条件をつけて何とか受注することができました。後から必要となった機能追加に対しても別費用で頂くことができ,トラブルもなく無事稼動したことから成功したプロジェクトといえます。いつも,このようなケースとは限りません。過去に何度も同じような状況に直面し,受注活動に負けたり,受注後にトラブルが発生するケースの方が圧倒的に多く,「⁠いい所まで善戦はしたが,競合先が無茶をしたので一歩及ばず」が一番良い結果とさえ思う時期がありました。身に覚えのある方も少なくないのではないでしょうか?振り返ると,成功の要因はいくつかありますが,「受注をとると決めたら中途半端な対応をしなかった点」が最大の要因でした。そんなの当たり前と思われますが,相手の出かたを見ながら動きを変えると,なかなか明確な対応ができずに中途半端になり,良い結果を産まないものです。その証拠に営業担当者に押される格好でなし崩し的に受注した案件は,ことごとくトラブルになりました。受注をとると決めたら「営業担当者と一緒になって会社を説得し,全ての責任を背負う」ことがとても重要です。自分事にしてしまうのです。同様に,案件を降りると決めたら「営業をなんとしてでも説得する」ことです。私は本稿では紹介していない一つの出来事をきっかけに,そのような考えが持てるようになりました。自分がラストマン(※4)であるという自覚が持てた時に,エンジニアがとるべき行動は明確になるでしょう。そのスタンスが営業担当者やお客様からも理解され,ジレンマから多少なりとも解放されました。※4自分が最終責任者であり,助けてくれる人は他にいない人のことを指す。悩めるエンジニアへ2009年度以降は,更に競争が激化していくことが想定されます。苦労して獲得した見積依頼は,採算がとれるものだけではないでしょう。営業担当者と対等に会話するために,自分がラストマンである覚悟を持って行動指針を決めてはいかがでしょうか。著者プロフィール森平也寸志(もりひらやすし)システムエンジニア経験が18年。(システムアナリスト)などを保有。これまで数十人のプロジェクトマネージャから少人数での中小向けシステムの導入等の経験がある。過去には自身が担当するプロジェクトで数億の赤字プロジェクトも経験済み。SEがシステムを構築する際には,常に失敗との背中合わせである事を痛感し,お客様との関係や自社の営業との関わり方を日々考えている。2019」を開催しました。DAY1・DAY2の様子を注目セッションとともにお伝えします。LINEのエンジニア3名がイベントに先駆けて見どころを紹介します。コードの安全性・安定性を高める開発サイクル~テスト管理の効率を上げ,脆弱性診断を自動で行う~本連載では,連載「業務を改善する情報共有の仕掛け」を受けつつ,安全性・安定性を加えた開発サイクルについて考えていきます。若者世代から圧倒的な人気を誇るライブ配信&動画投稿コミュニティアプリ「MixChannel」(ミクチャ)の裏側(レコメンドシステムやサーバサイド開発など)について解説していきます。その他の連載CSS3アニメーションでつくるインターフェイス表現CSS3によるアニメーション表現を紹介していきます。その中でも,幅広い読者に応用してもらえるだろうインターフェイスを主なお題とします。MySQL道普請便り本連載では,MySQLを使ったアプリ開発・運用に関するノウハウをご紹介していきます。RecipeUbuntuの強力なデスクトップ機能を活用するための,いろいろなレシピをお届けします。JavaScriptセキュリティの基礎知識JavaScriptに関するセキュリティ上の問題はどこで発生し,どうすれば防ぐことができるのか?について解説していきます。〜システムをきちんと運用するための基礎知識システムは「作って終わり」ではなく,運用の中でさまざまな問題が発生します。問題の発生に備えて事前にどのような対応をしておくべきなのか,問題発生時に何をしなければならないのか,ポイントを解説していきます。きたみりゅうじの聞かせて珍プレーソフトウェア開発の現場で体験したトホホな失敗,思わずうなる珍プレーをきたみりゅうじ氏が四コママンガで紹介。Linuxのメンテナンスの傍ら,Linuxやオープンソースソフトと日々を過ごす著者が,その魅力とつきあい方を,エッセイ風味でお届けします。PRESS特別編集部員,さわやか笑顔のスーパーハカーはまちちゃんとネット大好き14歳わかばちゃんが,毎号,読者の皆さんから寄せられたおたよりを紹介します。皆さんの日頃の悩みにも答えちゃいますよ。]メールでのお知らせメールで次の案内をお送りしております。メールの配信を希望する方は,利用したい項目をチェックしてメールアドレスを入力し,[登録]ボタンをクリックしてください。UPDATES[ほぼ週間に1回]新刊メールマガジン[ほぼ週間に1回]電脳会議の各号案内[ほぼ1ヵ月半に1回]※変更する場合や停止する場合は,登録情報変更ページをご覧ください。※登録いただいたメールアドレスには,そのお知らせ以外,配信いたしません。Ltd.ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。