中原一行 | 5 動き続けるために

仕事の量が多いと、どうすればいいか見えにくいため、手が止まってしまうことがあります。タスクにはそれぞれ取りかかる手間、言い換えると初動負荷があります。この初動負荷は、タスクによって大きかったり小さかったりします。また、どのタスクの初動負荷が大きいと感じるかは、人によっても異なります。中原さんは、自分にとって初動負荷が小さいタスクを選び、そのタスクに集中します。その一方で、自分にとって初動負荷の大きいタスクは、そのタスクを得意とする人に任せます。長く仕事を続けていくためには、このような動き始めとその維持を考慮した仕組みが、重要だといえます。

naka_5


羽田野
ほっとくとどっちが強いんですか?
中原
ほっとくと全部めんどくさくなる。ほっとくと仕事しなくなる。いろいろやらないといけない。人ってオーバーフロー気味になると動かなくなる。忙しければ、動いてるときはいいんだけど、やることがいっぱいたまってると、どれから手をつけようかな、まいいやラーメンでも食べてってなるので、そこはシステマチックにやってかなかないと、仕事しなくなる。自分である程度仕事ができるので。家で仕事したり。いろんなものがある。プライベートもそう。仕事の優先順位が下がっちゃう。
羽田野
それを上げるようにしてる。仕組みとして。
中原
なのでオフィスに行ったり。モチベーションを保つためにだったりとか。
羽田野
他にもどうやって動く仕組みを整えてます?
中原
楽しくする。ゲーミフィケーション、ゲームじゃないけど、わかりやすく。ちょっと、自分が楽しいように仕事を持っていく。
羽田野
提案とかもそうですか?
中原
提案とかもそうかな。こういうのやる中でも、いろんなことがちょこちょこあって。お客さんと話すのもそうだし、ドキュメント作るのもそうだし。いろんなタスクが入ってる中で、ドキュメント作るの好きじゃないから、それを誰かに頼むとか。分業で、自分の負担に思うことをやってもらうとか。結構一番時間がかかる。やり始めれば早いんだけど、やるまでが時間かかる。やるまでの時間が短い人にお願いした方がいい。
羽田野
やり始めの時間が短い人もいるわけですもんね。
中原
言ったら、わかりましたってすぐやってくるとか。そういう人の方が、暇だけどなんかない?っていう人の方が言ったらちゃんとやってくれたり。
羽田野
動き始めるまでの初期電力というか動力が違うんですね。
中原
日々いっぱいいっぱいだったらめんどくさくなってくるけど、そろそろ仕事でもしようかなって思ってる人の方が、言ったら頑張るよって。加速が違うというか。
羽田野
待機状態の人の方が加速が早いかもしれない。日々いっぱいいっぱいだったら動力少ないかもしれないし。人のチェックもしているのはマネジャー人格ですね。
中原
人のリソース、その人のモチベーションとか、この人やってくれそうだなとか、この人が好きそうな仕事なにかなとか。
羽田野
好きそうな仕事も、その方が加速が早いとか、やってもらいやすいとか。
中原
若い人が成長するときは、自分が好きじゃないこともいっぱいやった方がいいけど、ある程度の年齢いくと、好きなことやった方が絶対いい。そういう仕事の仕事の仕方の方が長く続く。
羽田野
前はそう思ってなかったですか?
中原
若いときはなんでもやります、遅くまで働きますだったけど、もう家族ができて、プライベートとか仕事以外にもやることができたときに、そんな長い時間働けないし、この先どんどん歳をとると自分の稼働時間がどんどん短くなっていく。その中でさらに稼がなきゃってとき、同じことやってても全然だめだから、どうしようかなって。
羽田野
リソースは限られて、それがどんどん減っていくだろうと。得たいものはあるので、このリソースでもここを得るためには、ここの変換効率が大きい方がいい。で、ここを探している。人のリソースをうまく使っていったり、やらなくてもいいことはやらないとか、遠回りしそうなことはやらないとか。そのためにはあえて失敗することも必要だろうし、時間を管理するとか、仕組みによって自分の役割を変えていくとか。なるべくここにあるリソースを使わないような体制を整えていって、本当に必要なものに使っていく。そんな流れでしょうか。
中原
うん、そうだね。全然専門的なことじゃなかったけど、大丈夫だった?
羽田野
大丈夫ですよ。最初のころに気にしてていま気にしなくなったことってあります?
中原
最初のときよりも、ちゃんとお客さんに迷惑をかけられるようになった。人に力を借りれるようになった。
羽田野
最初のころは?
中原
最初は全部自分でやろうとおもって一人一所懸命頑張ったけど、一人だと限界があるから、助けてとか、これやってとか。あとは、お客さんとのやりとりで、ある程度、あえてお客さんとのコミュニケーションをとらなかったりとか。コミュニケーションの幅?ここまでやっちゃうとダメだけど、ここまでだったら許してくれるだろうって図太さが出てきた。
羽田野
大丈夫なところとダメなところをギリギリでみるように。
中原
このまま全部仕事してたら死ぬでしょって。忙しくて無理だけど、でもこのくらいはちょっとぐらい遅れてもいいよねとか、あんまよくないんだけど。心配して電話かけてくるけど、どうでもいい電話も多いのね。だから出なかったりとか。
羽田野
選別するように。前は全部対応していた。
中原
図太くなったというか、肝が据わったというか。死にはしないでしょっていうのは、前よりもちょっと。いいことか悪いことかはわからないけど、そうでもしないと会社経営は無理だと思う。
羽田野
これもここの無駄をなくしていく上で必要なことなんですね。ありがとうございました。

中原一行 | 4 自分を細胞分裂させる

多くの仕事を引き受けると、一人ではさばききれないレベルの負荷かかり、負荷を分散する必要にせまられます。しかし、そうした負荷は、「やり方の細胞分裂」を促す場合もあります。中原さんは、自分を2つに細胞分裂させ、負荷を分散しました。1つは、自分の中を分ける方法です。自分の中に幾つか役割を作り、やることの切り替えに関する負荷を分散します。もう1つは、自分の外へ分ける方法です。自分だけで仕事を抱えず、人に任せます。自分のやり方をこのように変えることができたのは、今までと違うやり方をしても、自分の期待通りか、それ以上の成果が得られると理解したことが、重要だったといえます。

naka_4


羽田野
こういう一連の流れっていうのはおそらく経験重ねていくなかで、やりとりが蓄積されてできる部分もあると思うんですけど、これって人に教えるときはどうしてます?
中原
どうしようかなって。経験によるところも多いので。手っ取り早いのはまずはOJTでこういうことをやっているって。見えるところは見せて共有する。一緒に打ち合わせいくとか。見えないところにはこういう知識があって、こういうことがあるからああいう発言になったんだよって言葉で説明するし。
羽田野
一緒にいて、見てもらう。
中原
ほんとはこの辺をなにか図式であったりとかドキュメントとして残していけるといいんだけど。っていうところですね。
羽田野
聞いてる中でいろいろと基準があったり、そこに至った背景がいろいろあるんだろうなって思うんですね。たとえば時間の見積もり、大体これってこのくらいでできるっていうのって、作業工程一つ一つの大体の見積もり時間を直感的にやってそれを積み上げるていると思うんですね。経験がない人ってこの見積もりがわからないので、このくらい?みたいになる。ある人ほどここが分割してるし、ここを抜いたらもっと早くなるってわかると思う。何に対してどういう単位なのか、わかりづらい部分もありますね。いま聞いてると、たとえばRFPってどのくらいかかりますかとか。案件によって違うんでしょうけど、WBSってどのくらいですかって。2日が2週間に伸びるのって、どのタイミングのどこにアンテナ張られているのかって。
中原
いま話をしてて気づいたのは、時間を見積もったときに、この作業がどのくらい時間かかっててのは、なんとなく感覚的にはある。エンジニアやってると誰しもある感覚。だけど、新人とか若い人にはわからないのかもしれない。
中原
経営者がよくいわれるのは時間を全部つけておけって。作業するときに、ちょっと面倒だけど一個一個に何分かかってるのか計測していって、データとしてもっていて。より的確な見積もりが、経験のない人でも共有できるように。
羽田野
時間感覚を養うのって一個一個の作業にかかってる時間記憶の蓄積だったり。そういう意味でもいいんでしょうね。面談の技術を教えててもそうなんですけど、1時間だいたい面談やるんですけど、何分ころになに話してたかベテランの人は覚えている。経験が少ない人ほど覚えていない。人の話がどのくらいになると何分、自分がどのくらい話すと何分と把握するのも技術でしょうし。そういうのがわかってくるっていうのは、ある種の仕事全体像が見えたりとか、気持ちに余裕ってほどではないにしても、自分を客観的に見えるタイミングにいたってはじめてできることかも。自分を客観視できるなみたいな、ひいてみれるなって感覚になったタイミングはどのくらいの時期からですか?
中原
フリーでやり始めて、複数の案件を回し始めてから。職人とマネジャーっていう2つの見方ができないと。自分で物を作ってて、ちょっと遅れ気味ですと。職人とマネジャーがほんとは別であればマネジャーがそれを把握して、いまちょっと遅れている。お客さんと調整して、全体的に遅れてるんですって話をして、マネジャーが作ってる人にどういう状況なのって確認するのは当たり前。でも自分で作ってマネジャーやってると、それめんどくさくなるから。コミュニケーションが少なくなったりする。そうなったときに、これはよくないなって第三者的な視点で、作ってる人の言い分としてはこうだけど、マネジャーの言い分としてはこうだろうなって。
羽田野
見てるもう一人がいるんですね。
中原
全体を俯瞰してる人格が。ほんとは時間を分けて作業する、たとえば朝一番早い時間ではマネジャー的に動いて、午前午後は職人として動く。1日のスケジュールで。
羽田野
1日の中でそれを分ける。
中原
時間帯で、自分の仕事を分ける。
中原
全体を俯瞰してる人格が。ほんとは時間を分けて作業する、たとえば朝一番早い時間ではマネジャー的に動いて、午前午後は職人として動く。1日のスケジュールで。
羽田野
いつぐらいから?
中原
それはいつぐらいからかな。会社にしてぐらいからかな。フリーランスのときからやりはじめて。自分で全部やらなきゃいけなくなると必然的にそういうふうになっていくので、最初はあんまり仕事がないけど、徐々に増えていくとさばききれなくなっていくので。そのタイミングは、フリーランス1年半くらいかな。それくらいで法人化したので。
羽田野
法人化して。こういうことをやらざるを得なくなる。
中原
自分でやろうっていうのを諦める。最初全部自分でやった方が120パーくらいでできるって思ったけど。結局抱え込んじゃうと一人でやると70くらいしかできない。だったら人にお願いして。
羽田野
その判断に至るためには、無理だなって経験が必要でした?その前の段階の中原さんに話したら、あそうか、って切り替わりました?
中原
経験がないとなかなかそうならないので。たとえば本読んだり勉強してできるかっていうと、なかなか身にはつかない。
羽田野
無理だと思う経験が必要なことかもしれないですね。失敗じゃないかもしれないけど。
中原
限界をわかったりとか、こうあるべきってのができなくなったタイミングとか。まずは限界のポイントが必ずなにかしらあるので。
羽田野
限界のポイントを経験して、一人でやっても70くらいにしかならない。
中原
だったら、人にお願いして60くらいできれば、最後の10パーくら自分でやるの方が全然効率がいいし。
羽田野
タスク・スイッチングっていう、たとえば割り切りですよね。タスクって一つのタスクもそうですけど、役割によって変わると思うんですね。職人としての人格とマネジャーとしての人格をどう切り替えているのか、やり方の一つとして、時間帯で切り替わっていくようにしていて。それは切り替えを忘れてしまうとか、どっちかの人格によりすぎるのを仕組みとして防いでいるんですね。

中原一行 | 3 認識の差を埋める

第3回目は、認識の差とそれを埋める仕組みについてです。お客さんとエンジニアは、持っている知識や経験が違っています。そのため、認識に差があることが前提となります。お客さんに役立つシステムを作るには、その差をどう埋めるのかが、語られます。

naka_3

hr />

羽田野
次にWBSにいきたいと思います。これが何を作るかの根本に関わる大事な要素だと思い、極力細かい単位までタスクを分解するってことだったんですが、この分解自体ある種の技だと思うんです。分解は、たとえばどういうレベルまで分解しますか?
中原
分解を、まずは大きくフェーズに分けて。最初の設計フェーズ、実装フェーズ、テストフェーズとか。そこから設計フェーズでなにを考えなきゃいけないのかってとこで、RFPとか実際のインフラ、どういうハードウェア、サーバー環境でやるのか、どういう言語で作って、どういうソフトウェア使って作るのかっていうのの選定があるので。まずRFPがあって、そこらへんの要件によって諸々決まってくる
羽田野
道具を揃えていくみたいな感じですか。
中原
っていう順番があって、一通り終わって、設計書にする場合もあるし、簡単なメモ書きにする場合もあるし。規模の大きいプロジェクトになると、その時点で成果物としてRFPをお客さんに納品することもある。それでいくらって。
羽田野
設計の段階でタスクが4つくらいあるんですかね。
中原
大きく分けて。
羽田野
たとえば実装の段階ってなるとどのくらい?
中原
あとは機能ベースになるので、画面数とか機能数で細かく分けていく。一つの画面にたとえばe2Rだとオートドゥがどうとかアクション時オートドゥとか。機能ベースかつ、画面も絡んでくるから、それぞれ作るのにどのくらい日数が必要かを線でつなげていく。
羽田野
こういうふうなやり方でいけば、このくらいのサイズ感、細かさでできるっていうふうになっていくのは、なんとなく全体像のイメージがあるからですか?
中原
そうね、あと今までの経験で、これをやるとどのくらい日数かかるっていうのを前提とした見積もりが多いので、ちょっと新しいこととかむずかしいことだったらバッファーをつけたりとか。
羽田野
時間の見積もりがまずあるんですね。やることと時間があって、時間がないほどやれることは少なくなっていく。そうするとやることが多いのに時間が少ない状況っていうのも場合によってはあります。そういうときってどうします?
中原
やることが多いのに時間が少ない場合は、基本はスケジュールを引く段階では余裕をもってだけど、実際進めていくうえではそういうことはあり得る。体力勝負になるか、他にアサインするか。
羽田野
単体としてやってるやることに対して時間がない。人を足していくとか、自分の時間を足すとか。やることに対して使えるリソースを増やしていく。
中原
時間とか人とか増やすしてやるか、諦めるか。諦めて違う方向に。
羽田野
やらないって選択もあるんですね。
中原
逆にそれをグタグタすることでみんなが納得しないこともあるし。
羽田野
やめどきもある。どういうときが多いですか?
中原
やめどきとして多いのは、想定以上に時間がかかっているとき。で、あとは作業すすめて思ったよりも全然見込みが違ったりとか。
羽田野
思ったよりかかる場合、どのくらいかかりますか。
中原
全然倍以上とか、2日とかみてたけど全然おわらなくて1週間くらいかかるよとか。だったらやめようって。お客さんの場合には、そこを納得しない人もいるので、要調節というか。納得しない場合は、1週間かけてやめずに続ける。ただ、それをやったことで、こっちもリソースを使う。作ったことで使いやすくなればいいけど、ならない場合はお客さんがマイナスになる。
羽田野
そうならない場合にわかってもらえない場合もあり、あえて一緒に失敗するというか。
中原
とりあえず最初はやってみましょうよって。失敗をするというかこうすればよかったねっていうのは、早い段階で気づかせてあげた方がいい。いろいろああじゃないこうじゃないってやって、出来て使ってみて、あーよかったすごいよく出来てるねってのはほとんどない。作って、出来上がると、これやっぱこうした方がいいねって絶対出てくるから。
羽田野
動かしてみて気づけることがいっぱいあるんですね。逆に紙とか話し合いの段階だと見えないものがたくさんある。
中原
打ち合わせの段階でそこまでわかってる人ってほぼいないから。これいいですねって決まってスケジュールひいても、結局は一緒だろうし、使えないものとか、意味ないですっていうもので話が決まったちゃうパターンが多い。
羽田野
やってみないとわかってもらいづらいものなんですね。
中原
そういう場合は、実際わかりましたっていって、こうした方がいいですよってこっちからあげるけど、後の判断はお客さんであったり、他の関係者であったりとか。
羽田野
作る見る、こうしたほうがいいよ。これがない段階でいっても聞いてもらえない。
中原
モックまでいって触ってみないとわからない。
羽田野
ここを簡単にわかりやすく作って、見たときにこうすればいいんだってわかりやすいようにフィードバックとしてあげられることも大事になってくるんですね。これって最初のころからそう思ってました?どっかのタイミングで無理だろ、みたいになりました?
中原
最初からだいたいわかっていたけど、明らかな流れとして、よく言われるウォーターフロー型っていうんだけど、順番に設計して作ってテストして納品してどうぞ、ってのが多い。製造業とかいまでもそう。でも最近よくいわれるアジャイルとかだと、このスパンを短くして何回も繰り返すっていうプロジェクトの進め方。そういうスケジュールの引き方。要はWBSとかを最初から作るって。
羽田野
一発で決めて動くんじゃないくて、そのプロセスの中に何回もこうやったらこうなりますっていうのがあるんですね。ちょっとずつ転がりながら進んでいって。その都度フィードバックする。ぐるぐるしながらやっていく。
中原
じゃないと結局はさわってみたらこんなんじゃなかったていうのが多くなりがちなときもあるし。
羽田野
使ってみないと見えないこともある。細かくここをもっとこうしてほしいとか。使ってみないとわからないところ。
中原
60-40でいうと、お客さんが最初のRFPでこれできればいいよって時点でだいたい60パーぐらいしかなくて。
羽田野
ここまでみえて。
中原
そこをやって残りの40パーが初めて出てくるから。最初に支払ってもらった金額に入ってませんでしたって。この期間でできるんじゃなかったでしたっけってなりがちだからドキュメント残しておく。
羽田野
ここまでを実は意識していない段階から望んでるんですね。で入ってませんって。
中原
エンジニアだと最初から40が見えてるパターンが多い。こういうことやりたいんですって60話をしたとき、このままだとここ大変そうだなとか、ここどうするんだろうなっていう先の40パーセントが見えてくることが多いので、そこを踏まえて話をすることが多い。
羽田野
エンジニアの人は基本的にはここをみながら、この人たちがどうやったらここを見てくれるかなって考えて。
中原
もちろん60をどう実現するかってのもあるけど。その60を進めて行ったときに出てくるだろう40はなんとなく見えるので、早い段階でお客さんに言っておいたりとか。
羽田野
先に言って、あとから言いやすくする。
中原
極力これまずそうだと思うのは早い段階で言ったもの勝ちだから。それはログを残してちゃんと言っておいたほうがいい。その上でお客さんが納得してそうするなら、こちらには非はないし。

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

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

naka_2


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