中原一行 | 2 失敗のタネを育てない

第2回目は、開発を成功に導くために失敗のタネを見つけておくこと、そのタネが育たないよう自分の主観を交えお客さんに提案していくことの大切さが語られます。

naka_2

既存の製品を勧める場合もあれば開発を勧める場合もある。認識のズレだったり、後で失敗につながることがあるとすれば、どんなことですか?

お客さんが予算と納期を重視しすぎた場合は失敗することが多い。その状態で要望を全部実現しようとすると、ある程度出来ている製品をベースに、となることが多い。そうするとその結果、やりたいことができなくなって、最終的にカスタマイズでいろいろ手を加えてってやっちゃうと、当初よりも予算も期間もかかってしまうのでプロジェクトとして上手く行かなくなってしまう。

結果的にそういうところに落ち着きやすい。

落ち着きやすい。期間をきちんと取らないといけない。

お客さんにそいういう話すると、「納期が、予算が」って出てくると思うんです。それにはどうやって対応していますか?

そういう時は、ある程度妥協しないとその予算、その期間では作れないので「どこまで妥協します?」と。ただ、本当に必要な機能は担当者と現場レベルでズレていることもあるので、お客さん側のコミュニケーションとか、ステークホルダーとして誰が最終的な決定権を持ってるかとかが大事。

お客さん自身は、できるようになることを具体的にイメージしていない場合もあるんですね。

実際になにができるといいか明確じゃない場合が多々ある。例えば、市販のものはいろいろと出来るように機能が多いけど、実際に求めているのはピンポイントでこれとこれ、オプションでこういう機能があればいいっていうのがほとんど。 その場合「こんないっぱい余分な機能がついてこの金額ってどうなの」という話になって、だったら作った方が良くないですかって。うちとしてはゼロから作った方がいいですよって提案を最近はよくするけど、お客さんとしてはパッケージ製品を入れてカスタマイズとかを選ぶ傾向がある。もちろんそれぞれ長所短所あるけど。

既存の製品にそれだけの魅力がある、ということですか?

既存製品はパッケージ製品として出てるし、ベンダーが有償でサポートしてるから会社として安心感がある。あとは例えば経理だったら、経理のパッケージには業務上必要な機能が最初から盛り込まれている事が多い。経理のシステムをゼロから作ろうってなったとき、経理のことを全部わかってる人が設計してってのはなかなか難しいのでそこは大きい。それで結局、経理のシステムを入れてみるんだけど、使ってく上でその会社独自の業務フローとか業務仕様をカスタマイズで入れて、となりがちで、パッケージ前提だとそこがなかなか難しい。

それは結局ゼロから作っているのに近いか、むしろ少し遠回りしているような。

ちょっと遠回りして。ゴールが100だとした場合、製品入れると最初から50、60まで行けるんだけど、その先が遠い。

平均というか。

最初の立ち上がりが早いのはある。

既存の製品は早く進むけど、そこの会社で求めてるところまでは行きにくい。

最後のゾーンが、結局お客さんが日々の運用で使うところとか、かゆいところに手が届かないところだったりするので、60%できてるからいいじゃないですかっていっても、お客さんは「いやいやそこが一番欲しいところ」となることが多い。

その段階まで来て初めて「ここが欲しい」って分かったり。

そうそう。あとは、お客さんといい関係が築けてれば、同じように同業はいっぱいいるから、大きい案件はうちだとゼロからがいいと思うけど、この予算と期間だったらあっちの方がいいですよっていう時もある。うちは新規開発だけじゃなくて、運用開発や保守もやったりするか、最初細かい案件から関係を作っていって、後々広げてというのもあるし。

案件って大きいですね。作るだけじゃなくて運用とかカスタマイズとかいろいろあるわけで。入り口で中原さんのところにくるけど、その会社にとってゼロから作るんじゃなくて既成品を使う方がいいとしたら「こっちの方がいいですよ」とか。作る案件じゃなくても、できることが生まれる場合もある。そういう仕事の全体像が見えるようになったのはいつぐらいですか?

仕事の全体像が見えるようになったのは、フリーランスになってからかな。会社員でエンジニアやってたときもある程度は見えてたけど、エンドユーザーであるお客さんへの対応は、会社員の場合は会社経由だったり他の営業の人がいる方が多いし。

あいだに人がいて、中原さんがいて、会社があって。そこからあいだに人がいなくなって。

なくなって、完全にフリーになって。最初は友人経由とかで、「こういう案件あるんだけどできる?」って相談から始まって。「あ、できるよ」ってやったり。その過程で、自分で判断してきた。

できるかできないかは、どういうもので判断していったんですか?

できるできないは、まずは自分の経験から、できるできない。お客さんに呼ばれて、一番お客さんが聞きたいところって、お金とかの話じゃなくて、「それってできるのできないの」ってのが一番大きい。できないことは「これできないです」って言った方がお客さんも安心する。お客さんも営業の人を呼んでいろいろ相談して「ちょっと会社に持って帰ります」ってよりも、その場で「できないです。こうしたらどうですか」って言ってくれた方が信頼関係が生まれる事が多い。お願いしたい内容を知ってるなって思ってくれるので、そこで関係を作っていて。で、うまくこっちのフィールドで戦えるようにする。

できそうなフィールドになるんですね。できない案件からスタートしても、できそうな方向に徐々にずらしていく。

「こういうのどうですか、ああいうのどうですか」っていって、実現できそうな方向へもっていく。RFPの流れでいうと、基本お客さんがやりたいことを全部そのまま作っていたらいいシステムはできないので、ある程度作る側としての主観を入れる。

主観を入れる。これがいいものですよっていう。

「これ使いにくいですからやめましょう」とか、「その機能いらないですよね」とか。

欲しいものを全部やるのがいいわけではない。

お客さんがこれをしたいってなったときに、「それはなんのためにあるんですか」っていう元々の動機の部分から話すと、「こっちの方がいいですよね」ってなる場合もあるし。

お客さんは動機をわかってたりします?

わかってないことが多いと思う。最初はたぶんそこがあって、いろいろ会社内で話をして、こういうシステムを作ろうってなるんだと思う。結局あの機能この機能ってなったときに、逆に手がかかっちゃうから、「あんまり業務削減にはならないですよ」って。

お客さんが望んでるものって大きく分けると何種類くらいあるんですか?今のお話からは工数削減とかがあるんだと思うんですが。

一番多いのは費用対効果の面でいうと、工数削減。人力でやってるものをある程度自動化したいっていう。あとは、新しいサービスをやりたくて、っていうのもあるけど、うちにくる話の多くは工数削減かな。

人力でやってるものは何で、それをどのくらい自動化できるかってのが中心になってくるんですね。それに対してできるできないってのがあったり、予算とか納期があって、RFPが出来上がると。その次がWBSだと思いますが、RFPは大体どのくらいの時間で終わりますか?

案件や業種の規模にもよるけど、対象範囲が広いと数ヶ月〜半年かかることもあれば、もっと単発でウェブサイトでこういうのしたいとかで1週間くらいでまとめるときもある。向こうから話を聞いて叩き台つくって、何回かやりとりしてとなると、短くても大体1週間くらいはかかると思う。

これをやる時間て、フリーの最初の頃と比べて短くなりました?

そこは・・・、そんなに変わってないかな。

そうすると、大事なものにかかる時間は、最初のころから大きく変わらない。やることの中で順番にやっていくこととか、必ず決めなきゃいけないことも変わらない。

そーだね。大体システムを作る上で考えなきゃいけないことは一緒。ただ、何年かやっていくにつれて、経験が増えるので、こちらから出る主観的なものの量は増えて来てる。よりこうした方がいいですよ、ああした方がいいですよってのは、前よりは言えるようになっている。

提案の量や内容が増えている。

具体的にできるできないって言える幅が広がっている。

失敗しやすいケースについても幅は広がっていますか?経験が重なっていくと、RFPがこう進むと詰まる、進みにくいとか、想像しやすくなりますか?

だいたい失敗プロジェクトかどうかは、お客さんがどこまでわかってるかってのが大事で、お客さんが「自分も作ってる」っていう感覚を持たせるのが大事。その人が全然知らないでこちらに丸投げって状態だとその人もよくわからないし、あくまでその人がわかってる形で進めていくのが失敗しないプロジェクトというか。

丸投げじゃなくて、関わってもらう。

関わってもらって、かつレビューであったりとか。お客さんを巻き込んでしまうっていうのが必須かな。

巻き込んで一緒にやるっていうのがスケジュールに入ってるんですね。

レビューとか確認のお客さんの確認期間とか。

こういうのってメールと電話両方だと思うけど、どっちが多いですか?

ログが残るようにしないといけないから、基本全部メールかな。電話するときもメールしてから電話しないと、後から分からなくなるし。