Line 1: Error: Invalid Blog('by Esehara' )

または私は如何にして心配するのを止めてバグを愛するようになったか

>> Zanmemo

あと何かあれは 「esehara あっと じーめーる」 か @esehara まで

自分にとって、参加するスタートアップのCEOがコードを書けるかどうかは、それほど重要ではないんだと思う

 エンジニア、とくにWebエンジニアであったり、スタートアップに関わるようなエンジニアであると特にそうだが、ある人物の判断基準を「コードで書けるかどうか」で考えてしまう傾向にある。もちろん、なんらかの情報技術で世界に躍進するという野望を持っている場合、コードを書けて悪いことはないし、そもそもプログラミングとは如何なる行為なのか、ということを肌で感じておくことは、経験としてとてもよい。しかし、それは自分のようなポンコツエンジニアにとってはオプショナルなものなんじゃないか、と最近感じつつある。

 それは、幾つかの経験を経て見たときに、「元エンジニア」の人であったり、あるいはエンジニアをやりつつ、会社をやっている人達と話をしてきて、あんまりソリが合わないことを少しずつ感じているからだ。逆に、今お手伝いしている人とは、現時点では、自分としては不満無く作業が出来ている(もちろん、相手はどう考えているかはわからない)。そして、この辺りのズレというのは何処から来るのだろうと考えていた。

 あくまでも、ここからは零細の、6人程度のスタッフがいるスタートアップで、自社サービスを少しずつ大きくしていくという立場から考える。既に成長段階にあり、10人、20人のエンジニアがいるというベンチャーや、受託したり、あるいはSEで略されてしまうような「システム・エンジニア」の場合は当てはまらないかもしれない。

 正直なことを言ってしまうと、実は「ユーザーにとって価値を届けられるならば、ウォーターフォールだろうが詳細設計書であろうが何でもかまわない」と思っている立場だ。そして僕はたまたまPythonでメシを食っているが、本当に価値が届けられる言語がPHPなら、Rubyなら、喜んでそっちに移るだろう。

 ユーザーというのは、そのサービス、あるいはシステムに直接触れるユーザーのことだ(そして、受託開発の場合、これは委託したクライアントとはまたレイヤーが違う)。エンジニアにとって、エンジニアらしい「ユーザーへのたのしさ、つかいやすさ」を提供することのほうが、開発手法云々よりも優位にあると思う。

 そのように考えた場合、「アジャイル・リーン」だろうが、「ウォーターフォール」だろうが、ユーザーにとっては余り関係が無い。ユーザーは、もしそのサービスを愛しているのであるならば、単純に「こういう問題が出ているから、こういう風にできるようになったらいいな」とか「最近なんかこのアプリの反応が遅いんですけど」というような雑な捉え方になる。むしろ、ユーザーに対して、そういう風に雑に捉えられるようにサービスを整備することのほうがエンジニアにとって重要なのだと思う。いいアプリケーションというのは、後ろにあるシステムの事を意識させないということだと考えている。

 そういう風に考えるのが当たり前だと思っていたが、もう一つの、「エンジニア」の考え方というのがあるのに気がついた。「こういう機能が欲しいといったときに、まず仕様を確定することを目指す」タイプの人だ。

 なぜソリが会わないのかはなんとなくわかる。それは僕が「いや、その機能ってユーザーが使うときにどういう文脈で使われるものなんですか?」ということを言いたがる人間だからだ。それは自分が、機能というのは機能としてただそこに置いてあればいいものではないと考えているからで、必ずユーザーにとって、その機能を使うには使うなりの動機が存在している必要があると考えている。そうすると、「機能が豊富だとリッチだ」という立場と、ちょっと揉めたりする。あるいは余りにも些細な仕様(テーブルのカラムでどっちが右にあるのがいいのかとか!)だったりすると、退屈になってしまったりする。

 別に「仕様を作るな」と言いたいわけではない。初期において設計をきちんとしたり、開発の始めに仕様をある程度確定することは重要なことだ。しかし、いきなり機能ありき、仕様ありきになってしまうと、そもそもの大前提である「ユーザーに価値を届けるということ、そして価値を届けることを通じて企業を成長させる」という目的が何処かにいってしまう。

 さて、前置きが長くなってしまったが(ここまで前置きかよ!)、要するに、こういうことを考えていくと、実はCEO(経営最高責任者)が元エンジニアであるということや、あるいはコードが書けないとか書けるとか些細な問題であるような気がしている。だって、コードを書ける同士ですら、上に言ったような溝があるわけだ。むしろ、CEOが「どういう風にサービスを作りたいか」ということ、「どういう風にユーザーに対して価値を届けたいのか」ということ、そういう「モノを作るという価値観」について共有できることのほうが重要だ。

 単に計画的に物事を進めたいの?世の中の変化に対応してダイナミックに変化したいの?そして、これをやっているのは、将来何をしたいから?エンジニアに何を求めてるの?何が出来たらいいの?そういうことだ。

 「元エンジニア」という括りですら、いろんな立場がある。例えば趣味で自分のサービスを作ったり、上流工程から流れてくる仕様書を受けとったり流したりする立場であったり、あるいはスタートアップの泥臭い部分を嫌というほど味わった人間であったり。そしてハードウェアや組み込み、iOSアプリのエンジニアですら、「そういう風にされると困る」という部分は各人違うだろう。だから、コードが書けるということがいいわけではない。

 僕はこういうことを考えると、以前のところで、コードの書けるデザイナーの人が「これはモノ作りのやり方じゃない」ということを散々言っていたことを思い出す。僕はこのデザイナーの人とは個性が強すぎて反発することも多々あったけれども、そういう「何がサービスを作ることなのか、ちゃんと考えろ」という教えは、未だに大切に考えていこうと思っているし、そういう風に考えられるなら、実はコードが書けるかどうかはーー確かに書けることに越したことはないけれどーー、些細なことだ。