90パーセント終わりました、って何パーセント?

よくある進捗会議

その一

報告者「90パーセント終わりました」

二日後...

報告者「えーと、95パーセントという感じです...」

二日後...

報告者「えーと、97パーセントという感じです...」

その二

報告者「70パーセントくらいですね」

マネージャ「えー、もうほとんどできてる感じだったじゃん、
    あと何がそんな時間かかるの?」

報告者「えーと、あれとこれとこれと...うーん、
でも確かにあともうちょいなのかなぁ」
※なんか、まだまだ時間が掛かると言いづらい雰囲気に...

マネージャ「うん、明日の午前くらいにはできるでしょ、
だから90パーセントくらいかな (でないと困るし)」
※進捗を進めることに幸せを感じる...

二日後...

(略)

What is 90パーセント?

「90パーセント」って、何に対する割合でしょうか?

多くの人が、作業時間の総量に対する割合だと言うでしょう。それが一番ビジネス的に意味のあるものと思われてるだろうし、管理する側が聞きたいのはそれだし。

10時間の作業で、9時間過ぎたら90パーセントです。あと1時間やれば終わるはずです。でもなかなかそうはならない。結局そこから9時間かかった。つまり、全て含めて18時間の作業時間。最初の9時間を作業した時点では、50パーセントだったと言えます。

作業見積もりが甘かったと人は軽く言いますが、じゃあどうする、というブレイクダウンはなかなかされません。これほどまで、このありきたりのパターンが繰り返されるのには何かしらも仕組みが存在するはず、と考えます。

街中で、巨大なマンションやビルの建設をよく見かけます。ずっと長く工事してて、いつまでやってんだろうと。そして、あるとき囲いが外されて、建物の全体が見えるようになり、「おお、できてるなー、じゃあもうさすがにそろそろ完成か!?」って思ったことはありませんか?

でも実際は完成しません。そこから内装に入るのです。また、電気、ガス、水道などの配線、配管の細かい工事。壁や窓...とまあ専門ではないので細かいことわりませんが、よーく考えれば素人目にもやること一杯であることは想像できます。

「大きな枠組み」ができても、作ったものは誰かが利用するわけで、その利用ケース、つまりユースケースにフィットさせる微調整作業が必ず必要になってきます。

見た目がほとんどできてる?

なぜ人は 90 パーセントって安易に言ってしまうのだろう?

100行のプログラムを書くのに、90行書いたら... 90 パーセント?
作成中の画面を見て、見た目ほとんどできてる... 90 パーセント?

「10平方メートル作るのに、9平方メートルできたから、 残り1平方メートルなので 90 パーセントだ」

頭ではわかっていたとしても、ついついこういった思考に振り回されてしまってはいないでしょうか?時間ではなく、目に見えてる(限られた)「面積の分量の割合」が、ついつい進捗時の時間(のつもり)の割合にマージされてしまうと。

10行のプログラムを書くのに、それまでの90行よりも多くの時間を割く可能性はとても高いです。プログラムの経験が多い人であれば、行数なんてほとんど関係ないということを知っているでしょう。一行の修正に何時間も費やすことだってあるでしょう(普通です)。

「見た目ほとんどできてる」状態の画面から完成まで、それまでよりも多くの時間を割く可能性はとても高いです。ボタンを押した時の内部のDB処理、画面に動的な動きを実現するJavaScriptの実装、業務要件に合っているかどうかのテスト。画面実装の経験が多い人であれば、見た目や基本動作の作成なんて、全体作業の一部でしかないということを知っているでしょう。

さらには、作業というのは大抵簡易なものから着手することが多いです。簡易なものに着手して、その世界における地盤を固めて、最後に本丸を。特に意識せず自然とそのように作業を組み立てることもしばしば。これはこれで作業方法の一つで、良いやり方とも言えます。(厳密には手戻りしないために本丸の概念的な作業だけはしておきたい)

ただ言えることは、「面積の分量の割合」における最後の10パーセントは、魔法の効かないラスボスの可能性があるということ、そして、倒した後もさらに悩み深い問題を抱えて生き返る可能性があるということ。

問題解決が目的だから

最後の最後の

ユースケースにフィットさせる微調整作業

これが「作る」という作業のとても大事な要素でもあり、とても時間のかかるものでありながら、見た目の「面積」という意味合いでは1平方メートルにも満たない、10ミリ平方メートルくらいだったり、それどころか作業の結果面積が減る場合もあります。

でも、それがないと使い物にならない。どんなに立派なマンションでも、お湯がでなければ売れないでしょう。

「ものを作る」というのは、その背景に何かしらの問題があってそれを解決するために作るわけで、「もの」ができていることが重要なのではなく、問題を解決することが重要であり目的なのです。

(例外として、アート(芸術)は違うかもしれません)

ましてや、「どこまで作れば完成」というラインはとても曖昧なもの。

例えば、ある飲食店の広告のチラシを作るとしましょう。そのチラシを受け取る人の「ユースケース」は...

A. (配ってる人から)チラシを受け取る
B. チラシのデザインに惹かれて自らチラシを手に取る
C. チラシを見て、お店の雰囲気に惹かれて今度行こうと思う。
D. チラシを見て、お店のメニューを見て今度行こうと思う。
E. チラシを見て、お店の場所を知って機会があれば行こうと思う。

などなどあります。

まずは、受け取ってもらえないと話になりません。A を満たすためには、渡す人の素敵な笑顔も大事ですが、受け取ってもらいやすいサイズ、紙質を考慮する必要があります。その後のシナリオでは、一旦財布などにチラシをしまって、後でじっくり見ようというケースも考えられます。

B を満たすためには、インパクトのあるデザインにする必要があります。

C を満たすためには、お店の雰囲気に惹かれるようなデザインにする必要があります。しかしながら、思っていた雰囲気と実際の雰囲気がズレていて、不愉快な思いをさせてしまうっていう風にはなってはいけない。それを避けるためには、お店の実際の雰囲気、しかも良い部分を表現するする必要があります。というかお店側もそうあって欲しいと思うはず。ただ、B も同時に満たす必要もあります。

D や E を満たすためには、お店のメニュー情報や場所や電話番号を載せる必要があります。ただし、A も同時に満たす必要があり、スペースはとても限られています。また、情報が多ければ多いほど、B や C がやりにくくなるでしょう。

結局は、「ちょうどいい」を探すわけです。

論理的で明快な答えもないため、「作業はここまで」というラインもありません。ゴールが見えづらいわけですから、70パーセントなのか、90パーセントなのかもわかりづらいでしょう。実際、どこかで割り切って(9xパーセント)で完成とするしかない。

でも言えることは、「とりあえずこんな感じかなぁって一通り作ってみた」という見た目の「面積」が90パーセント埋まってる段階のものは、A, B, C, D, E の最適なバランスを得るまでに辿る道のりの割合においては、まだ70パーセント、いや50パーセントくらいかもしれないということ。

デザインの話だけだと思ったら大間違い。
プログラムはまだそれよりはわかりやすいかもしれませんが...

o 呼び出すプログラムがバグを起こしにくいメソッド仕様
o 呼び出すプログラムの環境にできるだけ依存しない作り
o ロジックの変更に耐えやすい汎用的な作り
o 誰が読んでもすぐにわかりやすい可読性の高い作り
o 極端なケースでもパフォーマンスが落ちない作り
o などなど

非機能要件的ながら、プログラマであれば誰もが重要であることを知っていて、間接的にエンドユーザや発注者にも利益がある要素。そして同時も、答えが明確にでないバランスを求められる要素。

そもそもプログラムの前に存在する、要件定義や画面設計などは、言うまでもなく広告のチラシ作りのような話が通用するでしょう。

少なくとも DBFlute の開発は、その繰り返しでした...今も

不幸の始まりはどこに?

もちろん、それぞれの作り手が、できるだけ効率良く早く作業して、早く作る努力は必要です。ただ、その努力は何か大事なことを「はしょってしまう」ことではありません。プロジェクトを成功させるためにも、自分を守るためにも、「面積」に踊らされずできるだけ目に見えない、作業結果が物理的な「もの」として現れない部分をケアする時間に意識を向ける。

管理する立場になったら、見た目に踊らされて作り手に進捗を押し付けない。ガントチャート上の進捗が進んで幸せなのはその日の自分だけ。明日の自分は不幸だから。

もし、人に作業をお願いする(発注する)立場になったら、見た目に踊らされて作り手に無理強いをさせない。ましてや、立場が強いからこちらの「変な要求」が通ってしまいやすい。

「変な要求」を「いやそれちょっと違いますね」と勇気を持って
指摘してくれる作り手(受注した側)なんてなかなかいないから。

その作ってもらったもので問題を解決したいのは自分(たち)。訴えて裁判に買っても互いに不幸なことには変わりはない。

おしまい

これは本当に自分も失敗の連続だったように思えます。これからも失敗するかもしれません。ごめんね、と周りの人に今から言いたい気持ちですが、失敗する仕組みをわかることで、少しでもそれが問題にならない程度に落ち着かせることができればなぁと。

レインボーバードランデブーにて、"Orquesta de La Luz" が心地よく流れてる中、思考をまとめて一気に書いてみました。