第2回目は、開発を成功に導くために失敗のタネを見つけておくこと、そのタネが育たないよう自分の主観を交えお客さんに提案していくことの大切さが語られます。既存の製品を勧める場合もあれば開発を勧める場合もある。認識のズレだったり、後で失敗につながることがあるとすれば、どんなことですか?中原お客さんが予算と納期をあまりに重視するために、そこをけちった場合は、絶対失敗する。お金をかけないようにすると、違う製品のカスタマイズとかになっちゃうから。やりたいことができなくなって、最終的にいろいろ手を加えてってやっちゃうと、当初よりもお金も期間もかかってしまうので、あまり使い物にならなくなる。結果的にそういうところに落ち着きやすい。期間をきちんと取らないといけない。羽田野お客さんにそいういう話すると、納期が、予算がってでてくると思うんです。それにはどうやって対応していますか?中原そういう時は、ある程度妥協しないとその予算、その期間で作れないから、「ここまで妥協します?」って。お客さんは「いいです」っていうんだけど、実際に全社導入とかで他の部署に見せると、「全然使えない」ってなって結局ポシャるとか。お客さん側のコミュニケーションとか、誰が決めるとか、ステークホルダーとか。羽田野お客さん自身は、できるようになることを具体的にイメージしていない場合もある。実際になにができるといいか明確じゃない場合もあるし。明確だとしても、市販のものはなんでもできるものが多い。実際に求めているのはピンポイントでこれとこれ、オプションでこういう機能があればいいっていうのがほとんど。その場合、こんないっぱい余分な機能がついてこの金額ってどうなのって?だったら作った方がいいんじゃないって。うちとしてはゼロから作った方がいいですよって提案を最近はよくするけど、お客さんとしては違う製品入れてカスタマイズとかを選ぶ傾向がある。既存製品は製品として出てるし、ベンダーが有償でサポートしてるから会社として安心感がある。あとはたとえば経理だったら業界の必要な機能が最初から盛り込まれている場合がある。経理のシステムを作ろうってなったとき、経理のこと全部わかってる人が設計してってのはなかなか難しいので。経理のシステム入れてって、でも「うちの会社はあーでこーで」、「いやそれできません」ってなるし。羽田野それは結局ゼロから作っているのに近いか、むしろ少し遠回りしているような。中原ちょっと遠回りして。ゴールが100だとした場合、製品入れると最初から50、60まで行けるんだけど、その先が遠い。最初のドーンみたいのは。既存の製品は早く進むけど、そこの会社で求めてるところまでは行きにくい。最後のゾーンが、結局お客さんが日々の運用で使うところとか、かゆいところに手が届かないところだったりするので、60%できてるからいいじゃないですかっていっても、お客さんは「いやいや使えない」って。羽田野その段階まで来て初めて「ここが欲しい」って分かったり。中原お客さんはモノを見ないと想像できないから、説明しても難しいから、あえて一回失敗させてみたいな。失敗すれば明確にわかりますよね。中原お客さんといい関係が築けてれば、同じように同業はいっぱいいるから、大きい案件はうちだとゼロからがいいと思うけど、この予算と期間だったらあっちの方がいいですよって。他にもコンサル入れてたりするから、そっちに決まったりとか。うちは細かい保守運用案件とかやって、一番最初の話じゃないけど違うので案件作ったりとかっていうのもある。作るだけじゃなくて運用とかカスタマイズとかいろいろあるわけで。入り口で中原さんのところにくるけど、その会社にとってゼロから作るんじゃなくて既成品を使う方がいいとしたら「こっちの方がいいですよ」とか。作る案件じゃなくても、できることが生まれる場合もある。仕事の全体像が見えるようになったのは、フリーラランスになってからかな。会社員でいてエンジニアやってたときもある程度は見えてたけど、実際のエンドユーザー、お客さんと直でやるってのは基本的には。会社経由だったり他の営業の人がいる方が多い。間に人がいて、中原さんがいて、会社があって。間に人がいなくなって。中原なくなって、完全にフリーになって。最初は友人経由とかで、「こういう案件あるんだけどできる?」って相談から始まって。「あ、できるよ」ってやったり。自分のなかで判断していった。羽田野できるかできないかはどういうもので判断してったんですか?中原できるできないは、まずは自分の経験から、できるできない。お客さんに呼ばれて、一番お客さんが聞きたいところって、お金とかの話じゃなくて、「それってできるのできないの」ってのが一番大きくて。できないことは「これできないです」って言った方がお客さんも安心する。お客さんも営業の人を呼んでいろいろ相談してちょっと会社に持って帰りますってよりもその場で「できないです。したらどうですか」って言ってくれた方が信頼関係が生まれる。知ってるなって思ってくれるので、そこで関係を作っていて。うまくこっちのフィールドに引きずり込む。羽田野できそうなフィールドになるんですね。できない案件からスタートしても、できそうな方向に徐々にずらしていく。「こういうのどうですか、ああいうのどうですか」っていって、実現できそうな方向へもっていく。RFPの流れでいうと、基本お客さんがやりたいことを全部そのまま作っていたらいいシステムはできないので、ある程度作る側としての主観を入れる。これがいいものですよっていう。「これ使いにくいですからやめましょう」とか、「その機能いらないですよね」とか。欲しいものを全部やるのがいいわけではない。中原お客さんがこれをしたいってなったときに、「それはなんのためにあるんですか」っていう元々の動機の部分から話すと、「こっちの方がいいですよね」ってなる場合もあるし。羽田野お客さんは動機をわかってたりします?中原わかってないことが多いと思う。最初はたぶんそこがあって、いろいろ会社内で話をして、こういうシステムを作ろうってなったんだと思う。結局あの機能この機能ってなったときに、逆に手がかかっちゃうから、「あんまり業務削減にはならないですよ」って。羽田野お客さんが望んでるものって大きく分けると何種類くらいあるんですか?今のお話からは工数削減とかがあるんだと思うんですが。多いのは費用対効果の面でいうと、工数削減。人力でやってるものをある程度自動化したいっていう。あとは、そうだな、工数削減と、あとは、よくあるのは、えーと。工数削減がなんだかんだいってそこに基本落ち着く。やってるものは何で、それをどのくらい自動化できるかってのが中心になってくるんですね。それに対してできるできないってのがあったり、予算とか納期があって、RFPが出来上がると。案件の規模にもよるけど、製造業だとに三ヶ月かけることもあれば、ほんとにコンサルとかもっと単発でウェブサイトでこういうのしたいとかあれば1週間くらいでまとめるときもあるし。むこうから話をきいてたたき台つくって、何回かやりとりして、大体1週間くらいかかるかな。羽田野これをやる時間て、フリーの最初の頃と比べて短くなりました?中原そこは・・・、そんなに変わってないかな。羽田野そうすると、大事なものにかかる時間は、最初のころから大きく変わらない。やることの中で順番にやっていくこととか、必ず決めなきゃいけないことも変わらない。大体システムを作る上で考えなきゃいけないことは一緒。何年かやっていくにつれて、経験が増えるので、こちらから出る主観的なものの量は増えている。した方がいいですよ、ああした方がいいですよって前よりは言えるようになっている。提案の量や内容が増えている。具体的にできるできないって言える幅が広がっている。失敗しやすいケースについても幅は広がっていますか?経験が重なっていくと、RFPがこう進むと詰まる、進みにくいとか、想像しやすくなりますか?中原だいたい失敗プロジェクトっぽくなったりとか。お客さんがどこまでわかってるかって。お客さんが「私が作ってる」ってのを持たせるのが大事。その人が全然知らないで丸投げって状態だとその人もよくわからないし。その人がわかってる形で進めていくのが失敗しないプロジェクタというか。丸投げじゃなくて、関わってもらう。関わってもらって、かつレビューであったりとか。お客さんを巻き込んでしまうっていうのが必須かな。巻き込んで一緒にやるっていうのがスケジュールに入ってるんですね。中原レビューとか確認のお客さんの確認期間とか。基本全部メールで、ログが残るようにしないといけないから。電話するときもメールしてから電話する。あとから分かんなくなる。