エンジニアが作るネットサービスのアイデアがしょぼいワケ【連載:えふしん】
2013/07/03公開
藤川真一(えふしん)
FA装置メーカー、Web制作のベンチャーを経て、2006年にpaperboy&co.へ。ショッピングモールサービスにプロデューサーとして携わるかたわら、2007年からモバイル端末向けのTwitterウェブサービス型クライアント『モバツイ』の開発・運営を個人で開始。2010年、想創社(現・マインドスコープ)を設立し、2012年4月30日まで代表取締役社長を務める。その後しばらくフリーランスエンジニアとして活躍し、2012年11月6日に想創社(version2)設立
若干釣り気味のタイトルですいません。今通っている大学院の授業で、漫画家の浦沢直樹さんをゲストに迎えた授業があった。内容は漫画のイノベーションの歴史だったのだが、学生の質問に対する浦沢さんの回答で、こんな話が出てきた。
・ プロデューサーとしての自分と、絵を描く自分は切り分けている。
・ 自分ともう1人が遊離した状態で見ている。
・ 自分が考えている時に、自分がやろうとすることにリミットをかけないことが大事。
「編集さんとの打ち合わせでアイデアをふくらませている時に、ものすごく壮大な絵を思い付いてしまうことがある。ただ、結果的に、その絵を書くのは自分なわけで、後で後悔することがある」とのことだった。
これは、今、1人でいろんなことを考え、自分でコードを書いている自分にとって衝撃的な話だった。本当に、その通りだ。
「エンジニアであること」が自由なアイデアを阻害する理由
通常のプロジェクトにおいて、エンジニアの役割は「アイデアを形にする人」である。最終的に、実現性に落とさなくてはいけない責任を担う。
だから通常、「不可能なアイデアを削っていく」のがエンジニアの仕事だ。
人から話を聞いた時に仕様という形で、実現できないものは削ったり後回しにしたり、簡略化したりする。要求仕様が意図するものをできるだけ壊さないようにしたいのは山々だが、チームのためにも実現できないモノを作るわけにはいかないので、どちらかというと保守的な思想で仕様を見る。
ここで、どれくらい実現性を担保したまま、深いところまで攻め込めるかというのがエンジニアの調整能力だと思うのだが、そうは言っても、必ずしも自分がコードを書くわけではないので、さまざまな阻害要因とのバランスを取る。
・ そもそも物理的、論理的に実現可能か
・ 予算、工数に対して実現可能か
・ 今いる開発スタッフや、外注スタッフによって実現可能か
・ 求められる納期に間に合うように実現可能か
かかわる人数が多ければ多いほど、「思っているほどうまくいかない」要素が増えていくので、その分のマージンを計算するのも大切な仕事だから、経験則としても保守的な方向に行かざるを得ない。
それは職業エンジニアとして悪いことではないと思うのだが、このような仕事をしてきたエンジニアが新しいネットサービスを考えたりする時の最大の問題点は、アイデアを考える時、例えば仕様の話を人から聞きながら、マルチタスクで「それって実現できるかな!?」ということを現実的な発想で考えてしまう癖があることである。
壮大なアイデアを思い付く横で、それが実現できないと思ってしまう自分がその段階で心にブレーキをかける。
結果、その繰り返しになってしまって、大きなアイデアが見つからない。
それは往々にして正しいのかもしれない。正しいのかもしれないが、本当に新しいものを作る時は、それだけではダメな時の方が多い。
技術的制約にしたがってしまうエンジニア
エンジニアが新しいことを考える時にありがちなパターンは、「●●という技術があるから、××というものが作れるんじゃないか」という考え方だ。
ところが、●●には△△という技術的問題や制約が必ず存在しているのだが、エンジニアは基本的に素直で賢くて良い子なので、「それは仕方ないこと」と素直に割り切ってしまう。
しかしながら、ユーザーニーズとしてそれだけでは足りない場合には、単純にその作ったものは、「受け入れられない」という結果に終わる。
コードを書く前に、「その制約を本当に受け入れてしまって良いのか!?」ということを考えて、それを乗り越えるものを作らないがゆえに起きる弊害だ。
特にライブラリで提供されているもの以上のアイデアを思い付かないし、チャレンジもしないという問題については、僕が通っている大学院の教授である古川享さん(元マイクロソフトの日本法人会長)もおっしゃっていた。
ユーザーベースでサービスを考える天才クリエイターたち
僕は以前、無茶で偉大な、世の中からは天才と言われるクリエイターと一緒に仕事をしていたので、肌感覚でよく分かるのだが、彼らは技術的制約で物事を考えない。
もしかしたら、あなたたちが無知で無茶だと思う、上司やお客さんも同じタイプなのかもしれない。
世の中を観察し、世の中の人たちにこういうのがあれば受け入れられるのではないか、というベースで物事を考える。また、実現性に落とす場合にも、デバイスやゲーム機などを眺めて、「これをこのように使ったら面白いのではないか?」と、エンジニアにはまったく思い付かない無茶なことを思いつく。
もちろん、それを実装に落とした結果、良いものができなければ負けるのは同じだ。ただし、このアプローチの場合は、アイデアに対して、エンジニアリングが負ける瞬間だったりもする。
成功した無茶なクリエイターの影には、必ずそれを支えるディレクターやエンジニアが存在している。そういう人たちが、壮大過ぎるアイデアを、どうにか現状の技術のギリギリで実現したものが、世の中を変える作品として評価される。
自分で自分のアイデアに対して、ブレーキを踏むことに慣れてしまったエンジニアは、彼らのようなものは作れない。
作品の根幹となる「大きいムード」を考える
ここまで書いたことはまったく他人のことを言っているわけではなく、客観的に見た時の、自分の弱点のことである。そもそもそれを克服したくて、今大学院のメディアデザイン研究科という学科に通っているわけなのだから、学生らしく、やはり先人の知恵から学びたい。
今日、授業でお聞きした浦沢直樹先生は、こうおっしゃっていた。
「作品を作る時は『大きいムード』を考える」
これは、つまり「世界観」のことだと思う。また、作品に対して「哲学」を持つということだし、もしかしたら、すでに「コンセプト」と言えるのかもしれない。このような世界を見つけいくためには、日常のあらゆることに関心を持ち、考え続けるのだと言う。
細かい人物描写をいきなり考えるわけではない。作品は7年間ぐらい続く作品を書かれるので、その後、頭の中で旅のようなことを続けていく、全体の世界観を描いていく中に、詳細仕様とも言える個々のキャラクターやストーリーは、その世界に生きているように、必然的に生まれてくるのだそうだ。
つまり、そういう世界観こそが、自分が「作品として実現したいもの」ということになるだろう。
『ボケて』を作ったゆーすけべー先生も、著書『Webサービスの作り方』に、
「哲学から考える」
と書いてある。
本書では、哲学のことを「個々人が持っている、特定の興味に対する揺るがない気持ちのこと」と定義している。彼は、僕と同じくデザイン思考を学んでいる人なので、僕が示していることと同じ考えだと思うのだが、いきなり技術から入らずに、一番大切なことを考える。次にアイデアを考えてから、技術を使って実現性を担保する設計フェーズに進む。この順番を間違えると、アイデアが小さくなってしまう。
今回の記事は、浦沢直樹さんの授業が終わった直後に、本当に気を付けなければと思ったことをここに書いている。冒頭に書いた浦沢直樹さんの言葉の言い換えと繰り返しになってしまうが、とにかくエンジニアは、アイデアを考える時に、実現性を担保しにいくのは、本当にエンジニアの性(さが)みたいなものなので、そこは意識して、自分に制約をかけないことが大事。
無茶でも、とりあえずやってみる。その先に新しい景色が待っているかもしれない、ということを信じて。