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