一つの商品やサービスを作り上げる。これにはゴールはありません。ゆえに、現実問題としてリリース日から起算して各部門の納期を決めていかなくてはいけません。限りある製作期間でどこをゴールとするかを設定するわけです。
ただ、ここには「妥協」が入り込んでしまう余地を見逃さずにはおれません。限られた時間とリソースの中で出来る範囲内のことをやるので、やりたいことすべてを実現できるわけではないということです。それゆえに、ゴールの設定を見誤ると商品の魅力が削げ落ちてしまうこともあるわけです。とは言え、完璧を目指そうにもゴールは永遠に辿り着けないので、どこかでケツを決めなければいけない。
また、もう一つの問題があります。それは作り手たちの思考や感性のアップデートです。作っている最中やプロトタイプを触っている内にヒントやイマジネーションが降りてくることがある。
「こうした方がいい」「この機能を実装できれば、まったく新しい魅力が加わる」
そんなアイデアや発想が後から湧き出てくるわけですね。で、ここで頭の堅いプログラマーがいると、「仕様書にありませんでした」「次から完璧な仕様書をください」みたいなことを言う人がいるわけです。うん、言いたいことは分かりますよ。後から追加機能や修正が出てきたら面倒臭いですよね。でも、出てくるんですもの。アイデアが・・・
ただ、こういうものってしょうがないと思うんですね。というか、むしろ真剣に自分たちが作っているものに向き合っている現場ほど、ドラスティックな仕様変更が時折あったりする。最初の仕様で作ったプロトタイプを見てプロジェクトの長が一から作り直しを命じるみたいな。スティーブ・ジョブズなんかはそういうタイプの経営者ですよね。
・スティーブ・ジョブズが語った「情熱を持って働くチーム」の作り方
https://qore.info/3104/
別にスティーブ・ジョブズを見習っているわけではないですが、私が一人、あるいは少数メンバーだけでやっていた時期は自然とそういう流れでやってたわけですね。実際に作業をしていると、「この設定項目は理屈としてはA案が最適だが、B案の方が直感的に操作できるよね」といった発想は作っていく段階で気がつくことです。そういうものをデザイナー、プログラマーが各々作りながら手を加えていく。クリエイターたちが仕様書を勝手に最良案にアップデートしていくわけです。つまり、仕様書などあってないようなもので、あくまで指針を示す程度のものだったわけです。
もう一つ根本的なことを言うと、お客さんたちは作り手たちの感性、思考のアップデートを潜在的に望んでいるということです。新しいものであったり、驚くものであったりを望んでいる。そうしたものは理屈だけでは作れない。私たち作り手の感性から生まれるものだからです。そして、感性というものは必ず変化していくものです。流動的な感性を使うからこそ、モノが生き物のように息をするのです。そういう商品やサービスは魅力があるんです。
だから、最初から完璧な仕様書や手順書があり、みんながそのとおりに手を動かせば良いモノが出来るかと言うと、そんなことはない。革新的な商品やサービスを生み出している現場ほど、商品の本質的魅力に向き合っている人たちが集まっています。それは常にアップデートがあるということです。ゆえにモノづくりの現場は戦場のような場所なので、常に思考や判断が問われる場所でもあるんですね。
コメント