お客様の要求は何か!?

システム化に限らず、最も重要な工程は要件定義です。

要件といえば、「機能要件」と「非機能要件」とに分けることが一般的ですが、プリセールスとして動いている段階で、要件定義の前に「要求定義」と言う確認フェーズを作ります。ただ、プロジェクトではない段階ですから、別に「えー、今回の会議では貴社からの要求を取りまとめさせて頂きます」なんて事は宣言しません。

このフェーズ、言ってみれば「繰り返し」が発生してきます。どんなに早くても3ヶ月、経験的には契約を含め1年以上程度のセールス期間で、お客様が求めている…抱えている課題は少しずつ変化していきます。これはウォーターフォールを経験されている方なら多かれ少なかれ理解していることですよね。その原因には法令改正や担当者の異動もありますが、中にはお客様が買収されてしまうことで時には「あ、うちの出番、無くなったんじゃね?」と言うこともあるんです。


その逆で「あ、最初は製品Aだけでいけると思ったけど、Bも含めた提案の方がフィットするね」とかと言う事もあり、ここら辺が「プリセールス屋」の勘所だと思うのですね。そこで「要求」をまとめていく作業が契約後のプロジェクトにはとても大切になってくるのです。

で、ここまで書くと「うちのSEでも同じようなことをやっているよ」と言うご意見が減ってきたんじゃないでしょうか?

よくある提案書作成でも「これはスコープ内?」と悩むようなことを当て推量で判断してしまうと、禍根を残しますから重要性や実装の可否をわきまえて一覧にしていきます。先程も書いたように3ヶ月〜の期間を使わないとステークホルダーの顔が見えてきませんし、それだけの時間を使って信頼性を醸成する必要があると思っています。が、SEを無償で一年以上使える状況を日本のSES会社は許していないのではないでしょうか?
また、通常、日本のIT会社の場合、提案フェーズの担当者が契約後のプロジェクトメンバーに変身する体制が一般的だと思います。短期間の提案フェーズで一気呵成にプロジェクトに持ち込めれば営業コストと言うオーバーヘッドも掛かりませんし、提案を作った張本人たちが実装に入るので、お客様にも安心感が生まれるかもしれません。が、一方で
1 契約が取れても、長期のプロジェクトで発生する変化に耐えられない
2 前例踏襲の提案を繰り返しやすく、お客様の個別事情に対応できない
と言う事象に見舞われるのですね。

逆にコスト面では有意でも、契約後のリスクを内包し(1)、契約に至らない商機損失リスクが前提(2)という欠陥があるのです。
逆にプリセールスのプロたちが必ず気を配るのが「僅かでも存在する差異の確認」です。私の場合、前回・今回の打ち合わせでの空気の違いも含めて、違いがあるかどうか、その違いをポジティブに動かせるかどうが案件対応で最も気うところです。
当然、空気の違いが自分の「人間性」に関するところもありますし、一見、それが解決できれば良いと思うこともありますが、実際に仮説設定をしてみたり、あるいは色々な関係者の情報を手繰ってみると、以外に組織としての動きが見えてくる事があります。

例として、私自身の経験から
1. CIOを交えた打ち合わせでは大人しかったA課長。2回目の打ち合わせで詳細に入るよう任されました。そして2日目の打ち合わせ。A課長はマシンガントークで提案しようとしていた製品を腐します。で、その裏にあったのは、同じような製品をその会社で検討していたと。A課長は製品検討の先頭に立っていて、既に内心、別製品の導入に傾いていた。そこへノコノコと現れて競合の説明をしたら、以外に自分が良いと思っていたものよりも便利そうだと感づいた。そこで2回目の打ち合わせで以後の取引関係を壊しても仕方ないくらいコテンパンに叩き潰しにきたと…。
2. 提案も中盤に差し掛かったと思ったころ、お客様の担当者が異動。新たにBマネージャーが担当されるとなった。ここから提案フェーズは急速に沈没。第一段階は、既に前任担当者から申し入れられていた海外での会議の調整状況を伝えたところ「あれ?宿泊費とエアチケットはウチの持ち出し?」。(はい、うちにはあなた様が満足するようなホテルやビジネスクラスを「おごる」ような予算はありません)。第二段階はプロジェクトの概算見積を出したと「あれ?御社、ライセンスの他にエンジニアにもコストを払えって言うんですか?」(はい。うちのエンジニアは付録じゃないので有償です)
まず、このマネージャーになった時点でお客様内では該当する課題への予算配分が激減していたそうです。ところがBマネージャーとしては、前任者以上に居丈高になる個性があり…かつ、接待を受けると言う(どうやら)彼独自の文化があるとは別ベンダーさんに伺いました。
3. これは良い例ですが…。提案で中々、先に進めなかった案件。毎度、打ち合わせ内容を踏まえて検討資料を微修正し続けていたら、ある日、担当のCさんが「何でこれを先に言ってくれなかったの?」と。(いや、前回からほとんど変更してないんですけど?)提案対象のシステム化の「締め切り」が近づいていた一方で、二股・三股かけていたCさんにはベンダーを決定する「基準」が判っていなかったようです。で、こちらから営業に「Cさんの上司にコンタクトして、このままだとウチ以外もカットオーバーが間に合わなくなると伝えて」と依頼しました。その直後、Cさんの上司が検討資料や提案書を見比べたそうです。そして「こちらの内容で進めたら?」と私の検討資料を見て一言…。ただ素直になれないCさんは従来の検討資料に不備があったと言い訳作りをしたかったらしいのです。まぁ、お話が前に進めば、こちらは問題ないのですが…。
4. 長い長い提案活動に入り、競合先も出揃っていた時期。担当者のDさんから「ちょっと、こんなことできる?」と簡単な相談が。Dさんの勤め先の親会社で採用が決まったソフト・システムなどがズラーっと並んだリストを見せられました。機能的なことをさっくりと聞き、直後にGoogle先生と相談をしてみると…。うーん、どうやら自社が提案している製品では厳しい。と言うか、提案の方向性を変えてリストにあったシステムと同居させないとDさんが欲しているレベルにはならない。そこで、2度・3度、Dさんの上司などを交えて打ち合わせをし、上がった要求水準に合わせた提案に切り替えるべきか、それとも今のままで走るべきかを嗅ぎ取るようにしてみたのです。で、上司の方曰く「これ、時々だけど親の社員も触れるだけに、見た目が違うのは使いづらいと思われるかもね」との一言→言質ゲットです。そこで既にあった提案を残しつつ、全く違う提案を織り込みながら「メリット・デメリット」の比較表を大慌てで作成。その傍らでリストにあったベンダー各社ともコンタクトを取りながら、ソリューションを定義してみたと。
 プロジェクト費用も跳ね上がり、更に実装の難易度も高くなったのですが、プロジェクトメンバーや各ベンダーさんの頑張りで見事にカットオーバー。更に色々なWebニュースにも取り上げられたようで、メデタシメデタシでした。

何れも、担当者の言動の「表面」では理解しきれない背後の動きがあり、それに対して何をすれば良いかがポイントでした。契約に行き着かなくても、無駄なワークが抑えられれば、別の案件に注力できるのですから。こうして、無駄は省きながら、適切な提案や動きをするには、手前味噌ですが経験がモノを言うのかと思います。

こんな事を考えながら提案をまとめて行かなければ、本当は中々良いシステムにはならないと思うのですよ。