90パーセント?「90パーセント」って、何に対する割合でしょうか?多くの人が、作業時間の総量に対する割合だと言うでしょう。それが一番ビジネス的に意味のあるものと思われてるだろうし、管理する側が聞きたいのはそれだし。10時間の作業で、9時間過ぎたら90パーセントです。あと1時間やれば終わるはずです。結局そこから9時間かかった。全て含めて18時間の作業時間。最初の9時間を作業した時点では、50パーセントだったと言えます。作業見積もりが甘かったと人は軽く言いますが、じゃあどうする、というブレイクダウンはなかなかされません。これほどまで、このありきたりのパターンが繰り返されるのには何かしらも仕組みが存在するはず、と考えます。街中で、巨大なマンションやビルの建設をよく見かけます。長く工事してて、いつまでやってんだろうと。あるとき囲いが外されて、建物の全体が見えるようになり、「おお、できてるなー、じゃあもうさすがにそろそろ完成か!?」って思ったことはありませんか?でも実際は完成しません。そこから内装に入るのです。電気、ガス、水道などの配線、配管の細かい工事。壁や窓...とまあ専門ではないので細かいことわりませんが、よーく考えれば素人目にもやること一杯であることは想像できます。「大きな枠組み」ができても、作ったものは誰かが利用するわけで、その利用ケース、つまりユースケースにフィットさせる微調整作業が必ず必要になってきます。頭ではわかっていたとしても、ついついこういった思考に振り回されてしまってはいないでしょうか?時間ではなく、目に見えてる(限られた)「面積の分量の割合」が、ついつい進捗時の時間(のつもり)の割合にマージされてしまうと。10行のプログラムを書くのに、それまでの90行よりも多くの時間を割く可能性はとても高いです。プログラムの経験が多い人であれば、行数なんてほとんど関係ないということを知っているでしょう。一行の修正に何時間も費やすことだってあるでしょう(普通です)。「見た目ほとんどできてる」状態の画面から完成まで、それまでよりも多くの時間を割く可能性はとても高いです。ボタンを押した時の内部のDB処理、画面に動的な動きを実現するJavaScriptの実装、業務要件に合っているかどうかのテスト。画面実装の経験が多い人であれば、見た目や基本動作の作成なんて、全体作業の一部でしかないということを知っているでしょう。作業というのは大抵簡易なものから着手することが多いです。簡易なものに着手して、その世界における地盤を固めて、最後に本丸を。意識せず自然とそのように作業を組み立てることもしばしば。これはこれで作業方法の一つで、良いやり方とも言えます。(厳密には手戻りしないために本丸の概念的な作業だけはしておきたい)ただ言えることは、「面積の分量の割合」における最後の10パーセントは、魔法の効かないラスボスの可能性があるということ、そして、倒した後もさらに悩み深い問題を抱えて生き返る可能性があるということ。問題解決が目的だから最後の最後のユースケースにフィットさせる微調整作業これが「作る」という作業のとても大事な要素でもあり、とても時間のかかるものでありながら、見た目の「面積」という意味合いでは1平方メートルにも満たない、10ミリ平方メートルくらいだったり、それどころか作業の結果面積が減る場合もあります。それがないと使い物にならない。どんなに立派なマンションでも、お湯がでなければ売れないでしょう。「ものを作る」というのは、その背景に何かしらの問題があってそれを解決するために作るわけで、「もの」ができていることが重要なのではなく、問題を解決することが重要であり目的なのです。(例外として、アート(芸術)は違うかもしれません)ましてや、「どこまで作れば完成」というラインはとても曖昧なもの。ある飲食店の広告のチラシを作るとしましょう。チラシを見て、お店の雰囲気に惹かれて今度行こうと思う。チラシを見て、お店のメニューを見て今度行こうと思う。チラシを見て、お店の場所を知って機会があれば行こうと思う。受け取ってもらえないと話になりません。満たすためには、渡す人の素敵な笑顔も大事ですが、受け取ってもらいやすいサイズ、紙質を考慮する必要があります。その後のシナリオでは、一旦財布などにチラシをしまって、後でじっくり見ようというケースも考えられます。満たすためには、インパクトのあるデザインにする必要があります。満たすためには、お店の雰囲気に惹かれるようなデザインにする必要があります。思っていた雰囲気と実際の雰囲気がズレていて、不愉快な思いをさせてしまうっていう風にはなってはいけない。それを避けるためには、お店の実際の雰囲気、しかも良い部分を表現するする必要があります。いうかお店側もそうあって欲しいと思うはず。同時に満たす必要もあります。満たすためには、お店のメニュー情報や場所や電話番号を載せる必要があります。同時に満たす必要があり、スペースはとても限られています。やりにくくなるでしょう。結局は、「ちょうどいい」を探すわけです。論理的で明快な答えもないため、「作業はここまで」というラインもありません。ゴールが見えづらいわけですから、70パーセントなのか、90パーセントなのかもわかりづらいでしょう。実際、どこかで割り切って(9xパーセント)で完成とするしかない。最適なバランスを得るまでに辿る道のりの割合においては、まだ70パーセント、いや50パーセントくらいかもしれないということ。デザインの話だけだと思ったら大間違い。非機能要件的ながら、プログラマであれば誰もが重要であることを知っていて、間接的にエンドユーザや発注者にも利益がある要素。同時も、答えが明確にでないバランスを求められる要素。そもそもプログラムの前に存在する、要件定義や画面設計などは、言うまでもなく広告のチラシ作りのような話が通用するでしょう。開発は、その繰り返しでした...今も不幸の始まりはどこに?もちろん、それぞれの作り手が、できるだけ効率良く早く作業して、早く作る努力は必要です。その努力は何か大事なことを「はしょってしまう」ことではありません。プロジェクトを成功させるためにも、自分を守るためにも、「面積」に踊らされずできるだけ目に見えない、作業結果が物理的な「もの」として現れない部分をケアする時間に意識を向ける。管理する立場になったら、見た目に踊らされて作り手に進捗を押し付けない。ガントチャート上の進捗が進んで幸せなのはその日の自分だけ。明日の自分は不幸だから。人に作業をお願いする(発注する)立場になったら、見た目に踊らされて作り手に無理強いをさせない。立場が強いからこちらの「変な要求」が通ってしまいやすい。「変な要求」を「いやそれちょっと違いますね」と勇気を持って指摘してくれる作り手(受注した側)なんてなかなかいないから。その作ってもらったもので問題を解決したいのは自分(たち)。訴えて裁判に買っても互いに不幸なことには変わりはない。おしまいこれは本当に自分も失敗の連続だったように思えます。これからも失敗するかもしれません。ごめんね、と周りの人に今から言いたい気持ちですが、失敗する仕組みをわかることで、少しでもそれが問題にならない程度に落ち着かせることができればなぁと。心地よく流れてる中、思考をまとめて一気に書いてみました。「デザイン」じゃなくて「デザイン脳」です。既存のシステムがあるとします。再開したディズニーシーにはてなブログをはじめよう!jfluteさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。