営業vs.開発の対立をなくす、「SE＝営業＝PM」という理想形：SEの未来を開く、フルスクラッチ開発術（5）（1/2 ページ）
プログラムレス開発が全盛の中、フルスクラッチ開発こそ、顧客のためになり、SEにとっても強みとなると主張する企業がある。彼らはなぜあえて今、このような主張をするのだろうか？
プログラムレス開発と「持たないシステム」が主流となりつつある今、フルスクラッチは「1つの有効な選択肢」となり得るのか？
プラムザの代表取締役 島田徹氏、取締役 内藤洋史氏との対談シリーズ。前回までに、以下のテーマを議論してきた。
- フルスクラッチには、ニッチだが確実な市場があること
- フルスクラッチはリスクが大きそうだが、逆に小さいこと
- エンジニアにとってはストレスレスであること
- エンジニアの世界が広がるということ
今回のテーマは、「フルスクラッチ開発を可能にする営業」。システム開発の現場では「営業と開発の対立」がしばしば問題になるが、フルスクラッチではなおさらである。それをどうやって解消しているのか。
エンジニア・営業・PMの三位一体
――はじめに前回のおさらいをしたいと思います。フルスクラッチ開発ではエンジニアの世界が広がっていく、という話でした。理由は2つ。
1つは、長く使える技術を深く身に付けられるということ。もう1つは、フルスクラッチでないと開発できない案件なので業務理解が深くなるということ。
これらが達成されることで提案力が高まり、周辺業務の開発案件も持ち込まれるようになるからでした。
島田氏 そのとおりです。そして、それはエンジニアの市場価値が高まることでもあります。
――今回は、営業の問題を考えたいと思います。私がフルスクラッチでの開発をしていたころ、営業と開発の間でさまざまな問題がありました。
先に営業がお客さんと話をしてくる。いい案件があるというので、マネージャの私が同行して話を聞くと、お客さんの要望がまったく聞けていなかったり、お客の予算では実現不可能な話をさもできるかのように希望を持たせていたり。最悪の場合、この両方だったりします。私が行く前からすでに、トラブルの種があるわけです。
一方、パッケージ販売は定額だし、カスタマイズのメニューがあり、予算関連でもめることは少ない。「結局できなかった」というもめ方をすることはあるでしょうが、予算や工期が足りなくて実現できないのは、フルスクラッチでも同じです。
フルスクラッチの方が、営業的なリスクが大きいと思うのです。今回は、このあたりについて、突っ込んだお話を伺いたいと思います。
内藤氏 お客さんから見ると、営業とエンジニアが支離滅裂なやりとりをしているように見える状況ですね。営業が無理な約束をしてきた場合、開発にしわ寄せが来る。それを避けようと開発が突っぱねると、今度は営業がニッチもサッチもいかなくなる。
島田氏 まさにデスマーチの原因です。営業の話に踏み込む前に、プラムザの体制について話しましょう。プラムザでは、エンジニアの職種をSEとプログラマに分けています。SEは、営業とプロジェクト・マネージャ（PM）を兼ねています。つまり、「SE・営業・マネージャ」の三位一体です。
――なるほど、それは理想形ですね。私はマネージャでしたが、営業と対立する場面が多く、そのストレスは馬鹿になりませんでした。
SE＝営業であることのメリット
島田氏 SEは、設計者であると同時にPMとしてプログラマを守らないといけない。と同時に、営業としてお客さんにも喜んでもらわないといけない。これはなかなか大変ですが、設計上の工夫で実現できます。
――どういうことですか？
島田氏 前回、議論になった「仕様変更」を例に取りましょう。確かに、まともにすべて受けていたら大変なんです。そこは営業としてある程度、リスク分を見込んで見積もりを出します。ただ、多くのプロジェクトでは、そのリスク分を使い果たして、赤字になるのではないですか？
――おっしゃるとおりです。リスクを積むといっても、価格競争があるので、そんなに多くは積めません。
島田氏 本人は営業としても苦労しているので、もうこれ以上の価格の上乗せは無理とはっきり自覚するわけです。そうなると、後は設計上の工夫で乗り切るしかない。
例えば、物販のシステムで業務フローを起こす段階で、お客さんが「1つの受注に対して配送先は1個」と言っていても、データベース上は複数持てるように作っておき、アプリケーションの実装で1個にしておきます。実際のところ、最後の最後で「やっぱり複数の配送先を持てるようにしてほしい」という要望が出ることが多いんです。
リリース直前でデータベースを修正すると大変なことになりますが、アプリケーションを修正するだけなら簡単です。こういう工夫が、自然にできるようになる。
内藤氏 「仕様変更」の発生しやすい個所があるわけです。そうしたところについては、最後まで何度も確認します。
島田氏 要件定義の段階でお客さんに念を押すと、「ほぼ100％大丈夫です」という答えが返ってきますが、実際はそんなことはありません。お客さんが気付きにくいところがあるからです。こういう部分の実装を後に回しておくと、やがてお客さんの方で気付いてくれる。
私たちから「複数の配送先にしましょう」という提案はしません。そこはやっぱりお客さんが決めることだから。だけど、長年の経験で、そうなりそうな予感がするので、先回りしておくわけです。
内藤氏 そういうリスク回避のための先回りがぴったりはまると、大きな達成感がありますね。こうした知見は、他のプロジェクトにも生かせます。
島田氏 プラムザには、開発上のリスク回避のためのノウハウがたくさんありますが、これは「三位一体」体制の大きな効果です。ノウハウの蓄積が、プラムザのエンジニアの世界をどんどん広げており、これは私たちがフルスクラッチにこだわっているおかげだと思っています。
内藤氏 また、こういう工夫の積み重ねで「プログラマを守れた」と感じた時は、PMとしての醍醐味も大きいですね。
――まさに技術が分かっているからこそできるマネジメントですね。
SEと営業を分けること自体が無理、という発想
――SEがPMであり営業でもあるということですが、営業のやり方について詳しく聞かせてください。
島田氏 プラムザでは、新規開拓・マーケティングといった営業は外部に委託していますが、その先の初回訪問以降は、すべてSEに営業をやってもらっています。また、どうしても既存顧客から案件が取れない時は、保守を担当しているSEにも積極的に営業サポートをしてもらうようにしています。
――黙って口を開けていても、仕事は来ないというわけですね。実は私も「SEが営業しろ」と教育されて、自ら動いていたのですが、それはバブルが弾けて仕事がなくなったからです。いわば、緊急避難的な対応でした。そのため、その後に来たITバブル期に育った中堅には、この方針は徹底されませんでした。プラムザは、どうして徹底しているのでしょうか。
島田氏 私自身が、フリーランスのプログラマから始めて、自分自身で仕事を取ってきたので、「営業とエンジニアを分ける」という発想がなかったからでしょう。技術が分からない人間が、見積もりなどできないし、お客さんとの交渉もできません。「分けること自体が無理」だというのが私の考えでした。
Copyright © ITmedia, Inc. All Rights Reserved.