０から創る難しさと制約の中で創る難しさ

「Back to the future」という映画をご存知だと思う。アメリカのごく普通の少年がタイムスリップして大冒険するという三部作で、あまりにも有名だろう。実は一番大好きな映画で、おそらく３０回近く観賞しているはずだ。「三部作でどれが一番面白いか」なんてことが議論されることがあるが、個人的にはあまりそういった区別をしようとは思っていない（ちなみに区別するなら１と２＆３の二つに区別すべき）。
さてBack to the futureを見たあとにいつも考え込むのが、

  • 制約の少ない中で、自由にモノを創る難しさ
  • 制約がある中で、最大のアウトプットを出す難しさ

の違いである。これは具体的にどういうことかを説明したい。

例えばストーリーを完全に自由に組み立てられる１に対して、２では「未来に行くところから始めなければならない」、「お父さん役の俳優が出演できない」、「主人公の恋人も未来に一緒に行ってなければならない」、「主人公の子供の事件に関する描写がないといけない」などという制約がどっさりと付いてくる。１では映画という芸術作品を創造することが可能だったのに対して、２＆３ではこれらの制約の中に数学的な最適解を出すことが求められていたはずだ。この二つの創造行為は、まったくもって違う能力が試される。
これはソフトウェアを製作する現場でも日々目にすることである。例えば新パッケージを製作するときには、自由にモノを創る難しさに突き当たることが多い。「生みの苦しみ」というやつである。これは概ね決断の苦しみであり、特に前例のない、または前例が調べられない状況であると「自分のやろうとしているやり方で正しいのか」、「いつか問題になるのではないか」という不安に苛まされて、前に進めなくなる状態になり苦しむ。だが動きは比較的自由である。
一方既に稼動しているパッケージに修正を加えるときには、「制約の多さから来る苦しみ」を味わうことが多い。例えば不具合を一つ直す場合にしたって「既存ユーザーがバグのまま問題なく使用している可能性」を考え出したりすると、おいそれと修正パッチも出せないのである。バグとはいかなくても「このUIは使い辛いな」と好意で直したのに、既存ユーザから「勝手に変えないで下さいっ！」と文句を言われた経験のある人は結構多いのではなかろうか。システムの裏側の動きを改善しようとしても、インターフェースとなるテーブルが変更の出来ないテーブルだったりして、プログラムも自由に組めないといった状況に陥り易い。これらが「制約の多さから来る苦しみ」の一例である。一方でこの状況は、決断を下すのは楽である。前例に従えば良いわけだし。
「どちらの状況で活躍できるエンジニアの方がエライ」という話をするつもりはない。エンジニアの風林火山分類じゃないけれども、エンジニアが力を発揮し易い状況は様々だからだ。無論多くの状況で結果を出せるエンジニアはエライ。その意味で０からBack to the futureという素晴らしい映画を創り上げ、制約の多いなかで２と３を良い映画に仕立てあげたこの映画の製作陣はエライのである。

バック・トゥ・ザ・フューチャー トリロジー・ボックスセット [DVD]

バック・トゥ・ザ・フューチャー トリロジー・ボックスセット [DVD]