使うツールの悪い所を知り尽くさなければ良い提案はできない

on


コストや納期を別にするなら、スクラッチ開発は顧客の要件を何でも実現できてしまうけれど、ソリューションやパッケージベースの開発だとそうは行かない。ソリューションやパッケージそのものはレディーメイドだからカスタマイズを越えた開発は前提としていないから。


勿論、案件によってはカスタマイズを越えた個別案件スペシャルのアドオン開発をすることもあるけれどそれは顧客が十分なバジェットを用意しているとかそのアドオンを次期バージョンの目玉にするなどの政治的な判断があってのことで。


ソリューションでもパッケージベースの開発でも顧客に提案するとき、「良いところだけ」でセールスをしているのがほとんどなのではないのかなーって思う。単純な話だよね。魅力的な機能を並べて競うのだもの。「ここが良いんですよ！」と声高にセールする。


でも、顧客は機能を買うんじゃないんだよね。顧客は顧客の実現したい業務を手に入れたいだけなのですよ。


顧客の要件がソリューションやパッケージベースの持っている機能で実現できないとしたらどうするのだろう。「いや、うちのソリューションでは……。」というのだろうか。諦めてもらうのか、それとも、バカ高いアドオン開発を見積もるのか……。


ソリューションやパッケージベースの開発を担当するエンジニアは、担当するツールの良い機能を知ることは無論のことだけど、ツールが得意としない機能を良く知らないといけないと思うんですよ。それは、良い機能はそのソリューションに携わるエンジニアなら誰でも顧客の要件を実現することは容易いから。その領域には、機能を使うだけの「利用技術」のスキルしか求められないか。あーでもチューニングになるとツールの深層に入っていくのでその手前までなのか。


で、ツールで提供している機能では顧客の要件を実現出来ないことがあるわけです。建前上の製品仕様の壁があるから。そのときに、代替案を考える必要がある。


だって、エンジニアの存在価値は「顧客の要件を実現する」ことでしょ？


だったら、ソリューションやパッケージで用意していない顧客の要件を実現する機能をどうやって提供するかを考えられないといけない。「あー、そういった要件は仕様でできないんですよ。」なんていうエンジニアは向かない。じゃあ、それに必要なエンジニアのスキルは。


顧客の要件の本質を理解できること。それは、顧客が言っていることはあくまでも業務としての実現したいことなのであって、そのままITで実現したいことではないのですよ。それをあなただったらどう解釈してどう実装するか、を考える。仕様でできることは後でいい。仕様でできないことを如何に実現するか。制約だってある。法外なアドオン開発の提案なんて提案から降りたいと言っているようなものだし。

  • ソリューションやパッケージで出来ること出来ないことを良く知ること。
  • 顧客の要件の本質に辿り着くこと。
  • 全てを提案側のシステムで解決しようとしないこと。
  • 機能のシステム界面を柔軟に考えること。
  • 機能は機能として使うのではなく業務として使う発想をすること。
  • 全てをITで解決しようとしないこと。


ソリューションやパッケージベースの開発でツールを良く知っているエンジニアは、

「何をしたいの？」
「だったら、あの機能をこう使えばいい。」
「この業務は前工程の既存システムで充分なのでは。」
「ここでインタフェースを取らないとアドオンが高くなるから。」
「ここは手作業でやってもらえば。」


と、何でもやりますと言うお花畑は提案はしないのですよ。でも、一番現実的な実現できる可能性の高い選択肢を出してくれる。それは、ツールの悪い点を良く知っているし、それを隠そうとしないから。