SIerがアジャイルしたければ技術者自身がセールスを

技術者自身がコンサルティングセールス〜クロージングするのが、技術者にとって理想的な仕事を獲得する最良の手段だと思います。そのために、まず何から始めればいいか。
技術者には商談・提案に必要な専門知識が十二分にありますから、これ一冊を読めば、第一歩としては十分でしょう。最初は営業マンについて商談に同席することから始めればいいと思います。

Powered by POPit


「営業」で大変なのは「目の前にいるお客さんから受注すること (セールスプロセスのクロージングまで)」ではなく、「目の前にお客さんを連れてくること (マーケティングプロセスの商談獲得まで)」です。

マーケティングは技術者が「ついで」に上手くやれるほど簡単ではありません。専門家に任せましょう。しかし、セールスは技術者自身がやってはどうでしょうか。

※日本語の「営業」ではセールスとマーケティングが区別されていないので厄介。いったん異なる職能と考えたほうが良いと思います。両方出来る人もたくさんいますが。

なんのために自分でセールスするのか。それは、見積以前の「契約形態」から技術者が主体的に関与して設計できる、ということです。例えば、アジャイル開発をやるなら、契約形態が大事です。請負契約がいいのか、準委任契約がいいのか。

このような取り組みを「いち技術者の努力ではどうにもならん組織マターだ」と考えるか、「自分に出来ることから少しずつやってみよう」と考えるか。

SIerには営業マンが要らないということか? そうかもしれません。組織として必要なのはマーケティング機能です。セールスは技術者自身がやればいい。

まずは営業担当者に「新規案件の最初のオリエンから同席させてくれ」と頼んでみることから始めるなら、ノーリスクでしょう。移動時間込みで1回当たり3時間ほどだとして、それすらやらず、技術に引きこもる技術者は、変化を祈るだけでしょうか。主体的にできることは、あるはずです。

アジャイルは死んだのか (arclamp.jp アークランプ)

「開発者のためのアジャイル」では死んだも同然

 僕は単純にアジャイルがダメだなんて言うつもりはありません。しかし、いまの「開発者のためのアジャイル」という位置づけでは、アジャイルは死んでいるも同然です。

 そもそもアジャイルが個人の幸福感やワーク・ライフ・バランスの文脈で語られるのは間違いでしょう。それらは組織マネジメントの問題であり、開発手法の問題ではないからです。この混同は現場への責任転嫁です。

 アジャイルは企業戦略のための手法であり、ビジネスのための手法だと位置づけるべきです。より実益があるものだと。だからこそ、「アジャイルが目 指すべき最適化とは何か」を開発手法だけでなく、契約などマネジメントまで含めて検討を進めなくてはいけません。いま世界で起きているリーンのムーブメン トは一つのヒントになるでしょう。


もし、技術やシステム開発の全体を理解した営業マンがいるならば、技術者は営業マンに任すことができる。とはいえ、それも技術者自身がセールスプロセスを理解した後がいい。「できないから任せる」のと「できるけど任せる」のは違います。もちろん「できる」の程度は専門家と同じではないでしょう。だとしても「まったくできないから任せる」のと「できるけど、もっとできる人に任せる」のでは、雲泥の差。

今回の「技術者がセールスプロセスに最初から関わるべし」という提言には、個別の契約における実際的な効果だけでなく、技術者がセールスを学ぶ (学習効果) という意味もあります。いったんセールスプロセスを自分でもできるくらい理解した技術者は、技術も理解した営業マンに、セールスプロセスを委ねておいて、 具体的な企画・提案の段階から参加すればいい。

そういう技術者は「営業のせいで」などとは言わんでしょう。いざとなれば自分が商談を引き取ってしまえばいい、と考えられる。「セールスは奴ら営業の仕事。知る必要もない」というのは論外です。そうして待っているだけでは、いつまでも技術者にとって良い形の案件はやって来ないでしょう。主体的に働きかけて変えることができる。技術に引きこもっていては、いけない。

まずは技術者がある程度までセールスを「できる」ようになること。アジャイル云々はそれから。

この提言を実践する段取り:セールスプロセスの最初から同席したいと営業マンに頼んでおく (最初は「見学」でもいい)。事前に商談の作戦について打ち合わせをしてから臨む。顧客と営業マンのやりとりを見てセールスを学ぶ。専門的な話題で営業マンを助けて発言する。顧客に信頼されるコミュニケーションとはどういうものか考えて実践する。商談の内容が、どういう見積書や契約書になるのかを理解する。

こういう経験を経て、案件毎に適切な契約形態、見積方式、プロジェクト体制について主体的に提案できる技術者、というものが現れてくると思うのです。私自身、セールスの経験を通じてシステム受託開発というビジネスの全体像を理解しました。

システム受託開発は「ものづくり」の前に「ビジネス」という経済活動であるはずです。技術者は、技術者である前にビジネスマンであるはずです。その原点に立ち返ってビジネスの全体を理解するうえで、セールスという場から得られるものは大きい。

SIerのビジネスを変える上では、技術者の参加が重要です。主体的に自分から働きかけるか、諦めるか。技術に引きこもる技術者か、主体的にビジネスする技術者か。マインドがビジネスマンかどうか。技術者がビジネスマンでなければ、アジャイルは厳しいでしょう。顧客と商談し続けるわけですから。要件や仕様のやりとりが商談に含まれてしまいますから。

ゼロベースはSIerではなくて、Web制作会社やコンサルティングファームのような仕事をしています。ですから、SIerにとって「外野の意見」として聞き流すのは簡単だと思います。しかし、これは受託ビジネスの本質論であって、「商材」の違いは、あまり関係ないと思います。

トラックバック(0)

トラックバックURL: http://zerobase.jp/mt/mt-tb.cgi/436