モノづくりは加点で楽しくなる

ここのところ、若いエンジニアとシステム開発を進める機会がちょくちょくあったりする。ところが、作る過程を楽しむということが彼らには難しいらしい。

作る工程を料理で例えるなら、、、なーんにも考えずに、とりあえずスーパーに行って適当に野菜を買って、「ありあわせ」のもので即興で作ってしまう。こういう工程をとる人がいる一方で、カレーライスを作る！と決めたら、「レシピ通り」に食材までも事細かに決めてからスーパーに行き、レシピと何一つ違わない手順をなぞる。より厳密に計画を遂行する人もいます。

いずれも、料理を作るという工程ですが、どちらが正しいか？（どの工程を辿ったほうが美味しい料理ができるのか）なんて誰にもわかりません。もしかしたら全然別の要素の方が大事で、食べてもらうお客さんとのコミュニケーションだったり、コンディションのほうにより影響する、なんてこともあるかもしれません。

完成品しか見たことのない時代

ところが、最近の仕事って、どうしたって納品時の完成度を（作る前から）求められるわけです。。。するとエンジニアは余計なことに神経を使って、上手くいかなかったときの保険やら免責やらばかりに気をとられるようになります。

つまり、モノづくりのモチベーションが「不安」に起因しているんですね。計画を立てることが「よりよいモノづくりにつながるから」そうするのではなく、「不安だから」事前承認を受けてこのプロセス通りにやりましたっていう「免責」をもらう。そのために綿密な計画を練ろうとするのです。そんなことを繰り返しているのだから、ほんとうに不幸でしかありません。

毎朝仕事に行きたくないとベッドにしがみつく理由は、仕事内容そのものにあるのではなく、「不完全なあなた」が「完璧な結果」を求められる市場の不条理を心が拒絶しているからではないでしょうか。その「不安」から逃れるようとしている。

モノを作る側も、作ってもらう側も、、、「完成品と交換する」価値観に浸かりすぎているんでしょう。。。言い換えれば、納品は100点満点が基準。だから成果は「減点方式」になるんです。これ必ずそうなります。

システム開発は、誰がやっても同じ結果が得られるような機械作業ではなく、再現性の極めて低い属人的なむしろアートに近い側面があります。試行錯誤の末に育てていくものでもあります。だから納品時が完成ではないんです。バグだってある。バグがない方が不自然なのです。ところが、納品 = 100点満点を絶対とする考えに固執しすぎると、どうしたって減点からのスタートになってしまう。思ったものと違うと叱咤されたりする。

いろんなプロセスがあっていい

料理人にもいろんな料理のプロセスがあるように、エンジニアにも状況や開発の規模に応じて、いろんな工程が許されてもよいのではないか。即興で開発しようが、大まかな目標だけを据え置いて開発を進めようが、厳密に完成品をイメージできるまで細かく設計図に落とし込んでから進めようが、そこに正解はありません。

完成品を製造することが目的なのではなく、本来は眼の前のタスクに精一杯取り組むことで、「現状を少しでもよりよくする」ことが目的であるはず。ですから、むしろモノづくりに対する姿勢は本来「加点方式」でしかありえないと、わたしは思います。この本来の目的がすっかり忘れ去られてしまっているようです。現状がよりよく改善されていく様子は本来とても楽しく、開発する側と、それを使う側とで一体感を伴うものなはず。そんな感覚を、みんなで味わうことのできる環境を整えてあげられたらなぁ。。。そんなことを若いエンジニアと話していて思った。

りなる