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

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

naka_3

次にWBSについてうかがいます。WBSは、何を作るかの根本に関わる大事な要素で、極力細かい単位までタスクを分解するってことでした。この分解自体ある種の技だと思うんです。分解は、たとえばどういうレベルまで分解しますか?

分解は、まずは大きくフェーズ毎に、設計フェーズ、実装フェーズ、テストフェーズなんかに分ける。そこから、例えば設計フェーズだと、実際のハードウェア構成だったり、何の言語でどういう仕組みで作るのかとか、どういう機能が必要なのか、っていう感じで、1つづつ必要な設計作業の可視化をする。ただ、まずはRFPが大前提なので、その要件によって実際に何をどこまでやるかは決まってくる。

道具を揃えていくみたいな感じですか。

そうだね。RFPからWBSっていう順番があるんだけど、RFP自体を設計書のベースにする場合もあるし、簡単なメモ書きにのみにしておく場合もある。規模の大きいプロジェクトになると、RFPが出来た時点で成果物としてお客さんに納品することもある。RFPを作る仕事というか。

設計の段階でタスクが4つくらいあるんですね。

ざっくりと大きく分けてね。

たとえば実装の段階ってなるとどのくらいタスクがありますか?

実装の段階になると、あとは機能ベースになるので、画面数とか機能数で細かく分けていく。例えば、一つの画面に検索機能とか編集機能とかをつけてったり。機能ベースかつ、画面も絡んでくるから、それぞれ作るのにどのくらい日数が必要かを線でつなげていく。

このやり方でいけばこのくらいのサイズ感や細かさでできるっていうふうになっていく。そう出来るようになったのは、なんとなく全体像のイメージがあるからですか?

そうだね。あとは今までの経験で、これをやるとどのくらい日数かかるっていうのを前提とした見積もりを作る場合が多いので、新しいこととかちょっと難しいことだったらバッファーをつけたりとか。

まず時間の見積もりがあるんですね。やることと時間があって、時間がないほどやれることは少なくなっていく。そうするとやることが多いのに時間が少ない状況もあるかと思います。そういうときはどうします?

基本はスケジュールを引く段階では余裕を持って引くようにするけど、やることが多いのに時間が少ないっていう状況は、実際進めていくうえではあり得て、その場合は稼働を増やして体力勝負になるか、他に要員をアサインするか。

やることに対して時間がない。その場合、人を足していくとか、自分の時間を足すとか。やることに対して使えるリソースを増やしていくんですね。

時間や人を増やして進めるか、現実的なところでスケジュールを引き直すか。もしくは、その機能の実装自体諦めて違う方向に持っていくっていうのもある。

やらないって選択もあるんですね。

ある。誰も納得が行かない状態で進めてもうまくいかないしね。

やめどきもあると思います。どういうときが多いですか?

やめどきとして多いのは、まずは当初の想定以上に時間がかかっているときかな。作業進めてみて思ったよりも全然見込みが違ったりとか。

思ったよりかかる場合、どのくらいかかりますか。

全然倍以上とかもある。例えば改修案件なんかであるのは、当初の想定では2日をみてたけど、着手して詳細確認してみたら予想以上に複雑で全然終わらなくて1週間くらいかかるとか。その場合は正直にお客さんと共有してどうすべきか話しあって、だったらその方法での実装は辞めましょうって方向に持ってったりとかね。 ただ、中にはそこを納得してもらえない場合もあるので、その時は要調節。その場合は、ひとまずそのまま突き進むんだけど、それをやることで使いやすくなればいいけど、ならない場合はお客さんにもマイナスになる事が多い。結果複雑になってしまって、使いにくくなることもあるし。

使いやすくならない場合でもわかってもらえないことがある。

開発に着手する前にいろいろとドキュメントを作ったりするよりも、まずはやってみましょうよって。失敗をするというか、こうすればよかったねっていうのは、早い段階で気づかせてあげた方がいいので。いろいろあーじゃない、こーじゃないと相談しながらドキュメントを作って、その後完成して、実際に使ってみて完璧ですねってのはほとんどない。作って、出来上がると、これやっぱこうした方がいいねって絶対出てくるから。

動かしてみて気づくことがいっぱいあるんですね。逆に紙とか話し合いの段階だと見えないものがたくさんある。

そうだね。想像力だけで、打ち合わせの段階でそこまで予測できる人ってあんまりいないかな。

やってみないとわかってもらいづらいものなんですね。

そうそう。そういう場合は、実際わかりましたっていって、こうした方がいいですよってこっちから提案してあげるけど、その後の判断はお客さんであったり、他の関係者であったりとかだしね。

作って見て、こうしたほうがいいよとわかる。作ったものがない段階で言っても聞いてもらえない。

モックまでいって触ってみないとわからない。

モックを簡単に作って、見たときにこうすればいいんだってわかりやすいようにフィードバックしてあげられることも大事になってくるんですね。これって最初のころからそう思ってました?どっかのタイミングで無理だろ、みたいになりました?

最初からだいたいわかっていたけど、明らかな流れとしては、よく言われるウォーターフロー型っていうんだけど、上から順に設計、実装、テストと進めて納品してどうぞ、ってのがまだまだ業界的には多いんだけど、最近よくいわれるアジャイルとかだと、このスパンを短くしてPDCAを何回も繰り返すっていうプロジェクトの進め方もある。最近はそういうスケジュールの引き方をすることも多いかな。

一発で決めて動くんじゃなくて、そのプロセスの中に何回もこうやったらこうなりますっていうのがあるんですね。ちょっとずつ転がりながら進んでいって。その都度フィードバックする。ぐるぐるしながらやっていく。

そう。じゃないと、結局触ってみたらこんなんじゃなかった、ていうのが多くなりがちなときもあるし。もちろん規模感にもよるけど。

使ってみないと見えないこともある。細かくここをもっとこうしてほしいとか。使ってみないとわからないところ。

60-40でいうと、お客さんが最初のRFPでこれできればいいよって時点でだいたい60%ぐらいしかなくて。

60%までみえて。

そこをやって残りの40%が初めて出てくることもあるかな。当初見積作成時には要件に入ってませんでしたよって。お客さんにしてみると、それもこの期間で出来るんじゃなかったでしたっけ、ってなりがちだからドキュメント残しておく。

残りの40%を、実は意識していない段階から望んでるんですね。で入ってませんって。

エンジニアだと最初から40%が見えてるパターンが多いので、そこを踏まえて話をすることが多い。

エンジニアの人は基本的には40パーをみながら、お客さんがどうやったら40%を見てくれるかなって考えて。

もちろん60をどう実現するかってのもあるけど。その60%を進めて行ったときに出てくるだろう40%はなんとなく見えるので、早い段階でお客さんに言っておいたりとか。

先に言って、あとから言いやすくする。

極力これまずそうだと思うのは、リスクになるわけだし、早い段階で共有しておいたほうがよいからね。それはログを残してちゃんと言っておいたほうがいい。その上でお客さんが納得してそうするなら、何か問題が発生して振り返ったとしても、記録に残ってるわけだし。