久々に父と話した。出張で東京にきた時はいつも話をする。
人生にはいくつかの段階がある。そして、死というものから人は目を背けることはできない。死という瞬間だけにとらわれず、その人の人生そのものを大切にする。
誰かと過ごした時間というのは、定量的に測れない何かがある。昔の、僕らがまだ子供だったころの写真には、面影が残る。その瞬間にその人と過ごしている時間は、後から大切なものだと気がつくものだ。
人はどうしても社会的な生き物なのだと僕は思う。信頼することができるのは、幸せなことだ。最終的な結果がどうであれ、誰かを信頼し、また信頼される行いをしていくということは、本能的かつ人の本質的行動のひとつなのではないかと思う。
余談
普段から電子機器に触れることが増えている。データはかたちのないものなのだと父は言う。一瞬、データは冗長化可能で、半永続的なものだと思い浮かんだが、アナログな写真のもつ雰囲気には届かない。実態のあるものに儚さを感じるのもまた、人の特性なのかもしれない。
2011/05/25
チームでのものづくり
今日は研究室で作業した後、Trippieceのミーティングに行った。作業内容としては、Gitの原理を復習してwikiにまとめつつ、実装をしていた。来週は学会なのでその準備も並行して進めている。
ミーティングをしていて思ったのは、チームでのものづくりのやり方だ。今日はβ版へのリリースに向けた話し合いだった。要点をつかみつつ、どのような機能を優先して作っていくか。新しい機能はいくつも浮かぶのだが、話し合っていく中で絞り込みをかけていかなければならない。
新しいバージョンに進めるにあたり、機能の選定には以下のことに気をつけている。
オーソドックスなことであるが、全員でこれらを真に共有することは難しい。各々に思い入れのある機能もあれば、客観的に見ても評価し難い機能もある。その中で実現可能性を勘案し、いずれかの機能を実際に作ることを決めなければならない。広報的な視点も絡めば、ユーザビリティの視点も絡む。そして絡まってしまう。議論が入り組んでくればくるほど、論点を把握できなくなっていく。結局、本質的な部分から話題が逸れていってしまうと、サービスの質にも影響してくる。
エンジニアの立場として、あまり技術的な難しさを考慮しないようにしている。なぜなら、ストレートにメンバーが良いと思うサービスの形を実現することこそ、ユーザへの価値につながるからだ。逆に、技術的に難しいことであればあるほど、ユーザにとって新しい体験を生み出せる可能性が高いのだ。そして、技術的に難しいことを、ユーザフレンドリーに見せるということも忘れてはならない。技術的に難しいからユーザも理解し難いというのでは、サービスは前に進まないものだと思うのだ。
サービスを提供する僕らには、ユーザの体験こそ全てだ。それを実現できるチームを作りたいし、そういうチームで働いていたいものだと改めて実感した一日だった。
ミーティングをしていて思ったのは、チームでのものづくりのやり方だ。今日はβ版へのリリースに向けた話し合いだった。要点をつかみつつ、どのような機能を優先して作っていくか。新しい機能はいくつも浮かぶのだが、話し合っていく中で絞り込みをかけていかなければならない。
新しいバージョンに進めるにあたり、機能の選定には以下のことに気をつけている。
- ユーザにとって快適か
- このサービスで実現したいことにどの程度結びつくか
- ユーザにとってわかりやすいか
- インタフェースだけで解決する問題か、内部も変えなければならないか。
オーソドックスなことであるが、全員でこれらを真に共有することは難しい。各々に思い入れのある機能もあれば、客観的に見ても評価し難い機能もある。その中で実現可能性を勘案し、いずれかの機能を実際に作ることを決めなければならない。広報的な視点も絡めば、ユーザビリティの視点も絡む。そして絡まってしまう。議論が入り組んでくればくるほど、論点を把握できなくなっていく。結局、本質的な部分から話題が逸れていってしまうと、サービスの質にも影響してくる。
エンジニアの立場として、あまり技術的な難しさを考慮しないようにしている。なぜなら、ストレートにメンバーが良いと思うサービスの形を実現することこそ、ユーザへの価値につながるからだ。逆に、技術的に難しいことであればあるほど、ユーザにとって新しい体験を生み出せる可能性が高いのだ。そして、技術的に難しいことを、ユーザフレンドリーに見せるということも忘れてはならない。技術的に難しいからユーザも理解し難いというのでは、サービスは前に進まないものだと思うのだ。
サービスを提供する僕らには、ユーザの体験こそ全てだ。それを実現できるチームを作りたいし、そういうチームで働いていたいものだと改めて実感した一日だった。
2011/05/23
コードを書く時間
普段からパソコンの前にいる時間は長い。大体平均すると、1日13時間、1週間で約90時間程度は作業している。大抵の場合は集中しているので、あまり他のことに気をとられない。会話をすると集中力が一時的に遮られてしまうので、なかなか時間の管理が難しいところではある。そしていつも思われているのだが、四六時中実装しているように見えているらしい。実際は10%程度の時間しかコードを書いていない。
なぜか。手を動かす時間は30%ほどで、その3分の2はサーバや環境の設定をしている。意識しなくてもそういう割り振りになっている。残りの70%は調べ物をしたり、設計をしたり、資料を作ったり、本を読んだりしている。
コードを書いているときというのは思う存分集中できていて、かつ作るものがはっきりしているときだけだ。だから気分も高揚しているし、妙に頭の回転が速くなる。そして書き終えたらまた、次のことを考えている。考えているときは設計なり、次のタスクの切り分けをしている。
設計をする時間というのが実は貴重だ。設計には要件の定義から詳細設計まで含まれる。頭の中で作りたいものがフィックスされるまで、ひたすら考える。ただ考えすぎると逆に考えがまとまらないので、たまに離れる。このあたり、数学の問題を解くときの感覚に近い。受験勉強のときに、机の前でいくら悩んでも解けなかった問題が、家族と話しながら夕食をとっていて急にひらめく、といったことがあった。設計もしくはデバッグのときに、よくこういうことが起こる。だから、ふとした休憩時間にも、頭は動いている。
僕の本の読み方もこれに似ている。一度本を読むときは、考えすぎない。視覚からただ入れる。その次に気になるところを探す。単語単位でマインドマップ的に連想する。本の内容を想像していく。そして全部は読まない。気になったところだけ目を通す。そうすると後日必要な時に、その知識が勝手に浮かんでくる。実はこの過程が一番面白いし、自分のためになることが多い。
こんなことを書くのは変なことなのかもしれない。けれどこの感覚は自分のサイクルに取り入れられているし、何より効率が良いし、楽しい。だから時間を自分で管理できる環境にあるうちは、このサイクルをうまく回すことだけを考えている。そしてこうして文章を書いて頭を活性化させながら、また違う片隅でさっき書いたコードのチェックをしているのだと思う。現に、今ひとつ解決策を思いついた。完全に頭が休まるという状態がどんな状態なのかはしらないけれど、きっと完全に頭が休まるということはないのだろうと思う。休めば休むほど、実は考えているのではないかと最近は思うのだ。
なぜか。手を動かす時間は30%ほどで、その3分の2はサーバや環境の設定をしている。意識しなくてもそういう割り振りになっている。残りの70%は調べ物をしたり、設計をしたり、資料を作ったり、本を読んだりしている。
コードを書いているときというのは思う存分集中できていて、かつ作るものがはっきりしているときだけだ。だから気分も高揚しているし、妙に頭の回転が速くなる。そして書き終えたらまた、次のことを考えている。考えているときは設計なり、次のタスクの切り分けをしている。
設計をする時間というのが実は貴重だ。設計には要件の定義から詳細設計まで含まれる。頭の中で作りたいものがフィックスされるまで、ひたすら考える。ただ考えすぎると逆に考えがまとまらないので、たまに離れる。このあたり、数学の問題を解くときの感覚に近い。受験勉強のときに、机の前でいくら悩んでも解けなかった問題が、家族と話しながら夕食をとっていて急にひらめく、といったことがあった。設計もしくはデバッグのときに、よくこういうことが起こる。だから、ふとした休憩時間にも、頭は動いている。
僕の本の読み方もこれに似ている。一度本を読むときは、考えすぎない。視覚からただ入れる。その次に気になるところを探す。単語単位でマインドマップ的に連想する。本の内容を想像していく。そして全部は読まない。気になったところだけ目を通す。そうすると後日必要な時に、その知識が勝手に浮かんでくる。実はこの過程が一番面白いし、自分のためになることが多い。
こんなことを書くのは変なことなのかもしれない。けれどこの感覚は自分のサイクルに取り入れられているし、何より効率が良いし、楽しい。だから時間を自分で管理できる環境にあるうちは、このサイクルをうまく回すことだけを考えている。そしてこうして文章を書いて頭を活性化させながら、また違う片隅でさっき書いたコードのチェックをしているのだと思う。現に、今ひとつ解決策を思いついた。完全に頭が休まるという状態がどんな状態なのかはしらないけれど、きっと完全に頭が休まるということはないのだろうと思う。休めば休むほど、実は考えているのではないかと最近は思うのだ。
2011/05/19
伽藍とバザール
今日散歩していて、ふと思ったこと。僕が一人でつくったものというのは、ないのだということ。僕らはWebでアウトプットをするけれど、WebもネットワークもPCもOSもプログラム言語も、先輩方が作り上げてきたものだ。経済の渦中に技術はあれど、技術は人からしか出てこない。エンジニアとしての自分はもっとオープンでありたくて、ビジネスをする人間としての自分は隠したがる。でも、本当にありたいのは、オープンで居続けることだ。
一つのきっかけとして、毎日使い、改良を続けている設定ファイル集を公開することにした。僕の手のようなもの。
https://bitbucket.org/suzuken/dotfiles
もちろんこれからも毎日変わっていくし、他の人が使うには使いづらいところも多々あるかもしれない。でも自分なりのノウハウが、情報を必要としている誰かに届くことの方が重要だと思う。そして、僕はただ設定を書いただけ。今愛用しているツールが、もっと便利になれば嬉しい。それでいいと思う。
一つのきっかけとして、毎日使い、改良を続けている設定ファイル集を公開することにした。僕の手のようなもの。
https://bitbucket.org/suzuken/dotfiles
もちろんこれからも毎日変わっていくし、他の人が使うには使いづらいところも多々あるかもしれない。でも自分なりのノウハウが、情報を必要としている誰かに届くことの方が重要だと思う。そして、僕はただ設定を書いただけ。今愛用しているツールが、もっと便利になれば嬉しい。それでいいと思う。
2011/05/17
Trippieceプレリリースと、反省と。
5月16日付でTrippieceというサービスをローンチしました。
http://trippiece.com
2月末にジョインしたので、2か月半ほど関わっていることになります。サービスリリースまでにたくさんのプロセスがありました。実感としては、ようやくリリースするところまで来たけれど、まだまだ未熟すぎる、というところです。
Trippieceは「プラン」を中心に、ユーザに新しい体験をしてもらうことを中心としたWebサービスです。あるユーザがプランを提案すると、そのプランについてサイト上で話し合いながら、実際に行動に移していきます。今回のプレリリースでは、プランを提案し、話し合う部分が実装されています。僕はこの中でシステム周りのことをほぼ全て担当しました。サーバ管理、設計、実装といった作業が中心です。
サービスをローンチするために、メンバーとたくさんの話し合いを重ねました。一度作ったサイトを、全てボツにしてもう一度作りなおしました。作り始めてから、またサービスの方針が変わることもありました。しかし、自分たちで設定したローンチの日程を変更することはしませんでした。エンジニアの身としては、作るものを早く決めて、詳細な要件ができあがれば、後は実装するだけなのでその方が楽です。一度作ったサイトを破棄するのは、通常であればありえない判断なのかもしれません。
僕が今回リリースするにあたって大切にしていたのは、決してサービスの基礎設計・デザインに妥協してはならないということです。今回のプレリリースでは満足な実装を行うことができませんでした。そこにはディレクションや広報的な事情も絡んでいました。なかなか実装のフェーズに入れず、エンジニアとしては待つ時間が長かったというのも事実でした。しかし、サービスのコアコンセプトが固まり、メンバー間での納得が深まれば深まるほど、今後サービスとしての価値が高まっていくと考えているからこそ、敢えてその部分に時間を費やしました。なので、技術的に満足できていないところは多々あり、多くの方々にご迷惑をおかけしてしまったことも大変心苦しい部分ではありますが、プレリリースという形でサービスの種を公開できたことは、非常にプラスでした。
課題は山積みですが、使いやすく、多くの方に何か新しい体験をしていただけるサイトになるよう、努力していきます。
http://trippiece.com
2月末にジョインしたので、2か月半ほど関わっていることになります。サービスリリースまでにたくさんのプロセスがありました。実感としては、ようやくリリースするところまで来たけれど、まだまだ未熟すぎる、というところです。
Trippieceは「プラン」を中心に、ユーザに新しい体験をしてもらうことを中心としたWebサービスです。あるユーザがプランを提案すると、そのプランについてサイト上で話し合いながら、実際に行動に移していきます。今回のプレリリースでは、プランを提案し、話し合う部分が実装されています。僕はこの中でシステム周りのことをほぼ全て担当しました。サーバ管理、設計、実装といった作業が中心です。
サービスをローンチするために、メンバーとたくさんの話し合いを重ねました。一度作ったサイトを、全てボツにしてもう一度作りなおしました。作り始めてから、またサービスの方針が変わることもありました。しかし、自分たちで設定したローンチの日程を変更することはしませんでした。エンジニアの身としては、作るものを早く決めて、詳細な要件ができあがれば、後は実装するだけなのでその方が楽です。一度作ったサイトを破棄するのは、通常であればありえない判断なのかもしれません。
僕が今回リリースするにあたって大切にしていたのは、決してサービスの基礎設計・デザインに妥協してはならないということです。今回のプレリリースでは満足な実装を行うことができませんでした。そこにはディレクションや広報的な事情も絡んでいました。なかなか実装のフェーズに入れず、エンジニアとしては待つ時間が長かったというのも事実でした。しかし、サービスのコアコンセプトが固まり、メンバー間での納得が深まれば深まるほど、今後サービスとしての価値が高まっていくと考えているからこそ、敢えてその部分に時間を費やしました。なので、技術的に満足できていないところは多々あり、多くの方々にご迷惑をおかけしてしまったことも大変心苦しい部分ではありますが、プレリリースという形でサービスの種を公開できたことは、非常にプラスでした。
課題は山積みですが、使いやすく、多くの方に何か新しい体験をしていただけるサイトになるよう、努力していきます。
2011/05/15
合わせずに合わせる
今日はレコーディング初日だった。17:30入りで23:00まで。
スタジオで録音するのは初めてのこと。普段家で録音をすると、自分の音が自分の音でないように聴こえる。しかし、今日は自分の耳でいつも聴いている音に限りなく近い音で録音されているように感じた。レコーディングエンジニアってすごい。
マンドリンの音はオンマイクだと録りづらいらしく、音作りが難しいとのことだった。クラシックギターは比較的オンマイクで採音されていたようだ。テイクの後、その場で試聴し、録音のバランスを調整しながら進めていった。レコーディングでは何度も同じ曲を弾くことになるとわかってはいたものの、集中力がうまく持続できず、最後のほうは指のコントロールが思うようにいかなくなってしまった。普段の演奏会のように一度の演奏にすべての集中力を注ぎ込むのではなく、丁寧にバランスを感じながら弾いていくのは新鮮な経験だ。演奏会では目の前にいる方々に向かって弾くので、伝えるイメージをもちやすい。しかし、録音だと聴き手との距離感を見失いやすいように感じた。テイクの後の試聴で、自分たちが聴き手の立場を意識して、何を求められているかを神経を研ぎ澄ませながら感じなければならない。難しいけれど、演奏会本番とはまた違った面白さがあった。
今日演奏して感じたことは、録音においてはどうしても縮こまった演奏になりがちだということだ。音楽の自然な流れや呼吸を感じず、互いに合わせすぎてしまうときがある。ビードが重くなりすぎ、流れがとまってしまう。個人的には演奏会の場であれば、その場の流れに任せる気持ちになりやすいのだが、録音では慎重になりがちだ。合奏というのは不思議なもので、合わせようと意識するとかえって合わなくことが多々あるのだ。いい演奏になるときは、全員のイメージが共有されて、各自がある程度自由に弾いた時だ。そのほうが、なぜか結果的に合うのだ。
明日は9:30にスタジオ入り。集中して演奏したい。
スタジオで録音するのは初めてのこと。普段家で録音をすると、自分の音が自分の音でないように聴こえる。しかし、今日は自分の耳でいつも聴いている音に限りなく近い音で録音されているように感じた。レコーディングエンジニアってすごい。
マンドリンの音はオンマイクだと録りづらいらしく、音作りが難しいとのことだった。クラシックギターは比較的オンマイクで採音されていたようだ。テイクの後、その場で試聴し、録音のバランスを調整しながら進めていった。レコーディングでは何度も同じ曲を弾くことになるとわかってはいたものの、集中力がうまく持続できず、最後のほうは指のコントロールが思うようにいかなくなってしまった。普段の演奏会のように一度の演奏にすべての集中力を注ぎ込むのではなく、丁寧にバランスを感じながら弾いていくのは新鮮な経験だ。演奏会では目の前にいる方々に向かって弾くので、伝えるイメージをもちやすい。しかし、録音だと聴き手との距離感を見失いやすいように感じた。テイクの後の試聴で、自分たちが聴き手の立場を意識して、何を求められているかを神経を研ぎ澄ませながら感じなければならない。難しいけれど、演奏会本番とはまた違った面白さがあった。
今日演奏して感じたことは、録音においてはどうしても縮こまった演奏になりがちだということだ。音楽の自然な流れや呼吸を感じず、互いに合わせすぎてしまうときがある。ビードが重くなりすぎ、流れがとまってしまう。個人的には演奏会の場であれば、その場の流れに任せる気持ちになりやすいのだが、録音では慎重になりがちだ。合奏というのは不思議なもので、合わせようと意識するとかえって合わなくことが多々あるのだ。いい演奏になるときは、全員のイメージが共有されて、各自がある程度自由に弾いた時だ。そのほうが、なぜか結果的に合うのだ。
明日は9:30にスタジオ入り。集中して演奏したい。
2011/05/11
ソーシャル性
今日はジムに行って軽く走ってきた。更衣室で着替えていると、立派な上半身をしている人がドライヤーで髪を乾かしていた。僕も隣で髪を乾かしていたので、鏡越しに様子を観察していた。よく鍛えている人たちほど、自身の体をまじまじと鏡で見ていることがわかった。
ソーシャルなものはWeb上にたくさんある。ソーシャルな要素をサイトに散りばめることによって、他の人の目を気にし、自分をよりよく見せようとする気持ちが芽生えてくる。見栄を張るのだ。見栄を張る仕掛けを、作り手が組み込む。それにより、サイト上に個々の正確を出すことができるようにするのだ。
最近自分自身がはまりやすいのは、気軽に、時にその他のサービスと連携しながら、個性を主張できるサービスだ。限られた時間の中で、自分らしいことが簡単にできるサービス。そしてまた、インプットしたデータを外部の人に魅力的に感じてもらえるものほど、うれしさも大きい。
逆に、個性を出せないサービスは、情報を得るだけになってしまった。情報を得るだけのサービスは、その都度検索して必要なところだけ参照して用済みだ。特にそのサービスでなければいけないという理由はないのだ。もし、情報を提供することが個性を発揮することになるなら、そのサービスに対する視点はがらっと変わるのだ。wiki的ともいえる。
自分自身がどのサービスのどの点に魅力を感じているのかを整理して、自分の作るサービスに落とし込むことが大事だ。時間の許す限りこの部分は大切にしたい。
ソーシャルなものはWeb上にたくさんある。ソーシャルな要素をサイトに散りばめることによって、他の人の目を気にし、自分をよりよく見せようとする気持ちが芽生えてくる。見栄を張るのだ。見栄を張る仕掛けを、作り手が組み込む。それにより、サイト上に個々の正確を出すことができるようにするのだ。
最近自分自身がはまりやすいのは、気軽に、時にその他のサービスと連携しながら、個性を主張できるサービスだ。限られた時間の中で、自分らしいことが簡単にできるサービス。そしてまた、インプットしたデータを外部の人に魅力的に感じてもらえるものほど、うれしさも大きい。
逆に、個性を出せないサービスは、情報を得るだけになってしまった。情報を得るだけのサービスは、その都度検索して必要なところだけ参照して用済みだ。特にそのサービスでなければいけないという理由はないのだ。もし、情報を提供することが個性を発揮することになるなら、そのサービスに対する視点はがらっと変わるのだ。wiki的ともいえる。
自分自身がどのサービスのどの点に魅力を感じているのかを整理して、自分の作るサービスに落とし込むことが大事だ。時間の許す限りこの部分は大切にしたい。
2011/05/07
実践と学業の中で
今日は大学院の授業に3つ出席した。DB特論、OS特論、スマートメディアコミュニケーション論。今年はCS系の科目を多めに申請している。専門外の科目を、専門分野の先生に教えてもらえるのは純粋に面白い。
OS特論は仮想化技術についての講義だ。仮想化の発祥から、いくつかの方法論の比較を行う形で授業が進んでいく。仮想化のアーキテクチャについてはVMwareの利用経験があったのである程度は創造できていたものの、順序だてて説明されてると新たな発見がある。XenとVMwareのスタンスの違いや、Intel特有の構成などについても参考になる。VM上のメモリアドレッシングについては予想通りだった。物理メモリへのアドレッシングには一度VM上の仮想的なメモリのアドレスを把握してから、VMM側で物理メモリにマッピングするというのは想像していた。最近その辺りを直接物理メモリへのアドレッシングをしてしまう機能もあるとのこと。これも正常な進展だと感じた。
DB特論はRDBにおける非確定情報の理論的取り扱いに関しての議論だった。あるタプルの一項目が変数の場合、インスタンスはある制約のもとに予想される。その予想されるインスタンスの集合をrep(T)で仮定していた。また、L透過性の議論においては、インスタンス集合とテーブル全体の示す集合が等しいという命題に関して検討した。結論から言うと、タプル内変数があるとL透過性は導くことができないため、あまり有用な議論にはならなかった。
また授業内で、Coddの12の規則(http://ja.wikipedia.org/wiki/コッドの12の規則)が簡単に紹介されていた。この定義はもう一度見直しておこうと思う。
久々に授業を受けて思うのは、受け身の姿勢をとっている時間が長ければ長いほど、時間を無駄にしているということだ。これは事業を意識したり、仕事でアプリケーションを作り始めてから感じたことでもある。今目の前で展開されている論理が、実際にどのような場所で役に立つかが自分の中で明確になればなるほど、知識として定着しやすくなるものだ。実践しつつ、学ぶ。これが最も効率的な学習をするために必要な条件だと思う。だから今、学ぶ時間が貴重なものになっているし、事業を作ることとの相乗効果があがっていることを感じている。
OS特論は仮想化技術についての講義だ。仮想化の発祥から、いくつかの方法論の比較を行う形で授業が進んでいく。仮想化のアーキテクチャについてはVMwareの利用経験があったのである程度は創造できていたものの、順序だてて説明されてると新たな発見がある。XenとVMwareのスタンスの違いや、Intel特有の構成などについても参考になる。VM上のメモリアドレッシングについては予想通りだった。物理メモリへのアドレッシングには一度VM上の仮想的なメモリのアドレスを把握してから、VMM側で物理メモリにマッピングするというのは想像していた。最近その辺りを直接物理メモリへのアドレッシングをしてしまう機能もあるとのこと。これも正常な進展だと感じた。
DB特論はRDBにおける非確定情報の理論的取り扱いに関しての議論だった。あるタプルの一項目が変数の場合、インスタンスはある制約のもとに予想される。その予想されるインスタンスの集合をrep(T)で仮定していた。また、L透過性の議論においては、インスタンス集合とテーブル全体の示す集合が等しいという命題に関して検討した。結論から言うと、タプル内変数があるとL透過性は導くことができないため、あまり有用な議論にはならなかった。
また授業内で、Coddの12の規則(http://ja.wikipedia.org/wiki/コッドの12の規則)が簡単に紹介されていた。この定義はもう一度見直しておこうと思う。
久々に授業を受けて思うのは、受け身の姿勢をとっている時間が長ければ長いほど、時間を無駄にしているということだ。これは事業を意識したり、仕事でアプリケーションを作り始めてから感じたことでもある。今目の前で展開されている論理が、実際にどのような場所で役に立つかが自分の中で明確になればなるほど、知識として定着しやすくなるものだ。実践しつつ、学ぶ。これが最も効率的な学習をするために必要な条件だと思う。だから今、学ぶ時間が貴重なものになっているし、事業を作ることとの相乗効果があがっていることを感じている。
2011/05/06
仕事と職業
就職にあたって、多くの人が迷うことになる。様々な業界があるので、外部環境や内部環境を考慮しつつ、志望業界を絞っていく。その選択肢は多岐にわたる。
僕が就職するときに結論を導いたのは、自分がやりたいことを明確に文章化できたときだった。自分の仕事に対するスタンスとやりたいことを明確にして、後はそれを実現できる環境を選んだ。周りの友達からは「なぜ大企業に就職しないのか」ということも言われるのだけれど、その点については全くこだわりはない。そしてその観点から企業を選んではいない。やりたいことがあって、その環境が在ったのが、Web業界であり、ベンチャー企業だった。
多くの業界の知人がいるし、様々な分野で勉強に励んでいる友達もいた。学業が純粋に好きで、経済の正す立場に我が身を置くと決断する友達も入れば、マイペースに生活を維持して給料をもらいたいという観点から就職先を選んだ友達もいた。自分の友達という世界の中でも、小さな経済圏ができているようなものだ。だから周りの人がどこにいこうと、僕の決断にはあまり関係がなかった。そして、誰がどこに就職するかということに対して、あまり関心がなかった。僕が見ていたのは、その人が何をしたくて、仕事を選んだのかという点だけだ。
僕も最初は悩んだ。コンサル業界やSIer業界も見た。しかし、途中で足が止まってしまった。魅力を感じなかったからだ。その中で働いている人で、僕の目から見ても魅力的な人は少なからずいた。僕自身が働いているというイメージがあまり湧かなかった。自分のやりたいことを素直に感じるというのは、そう簡単にはできないことだ。どこか違和感を感じたとき、そこで立ち止まる人と立ち止まらない人がいる。直感的なものを大切にするには、自分の感情に素直に反応しなければならない。そこには、打算的な考えはない。今までの経験と、知識だけが影響するものなのだと思う。
良いと思うことを良いと素直に言えるだろうか。これは僕にとって難しいことだった。音楽でもそう、技術でもそう。答えのないことに自分なりの答えを出すことの難しさやもどかしさは、どんな尺度に置き換えようとしても表現し難い。僕の中で素直に良いと思うことは、「創り手としての創造力に従い、利用者にストレートに届くいいものを創ること。」だった。この感情が一番大切なものだった。
どうしても、些細なことや環境的なことを何度も計算してしまうことがある。けれど、一番大切なのは自分の考えに率直に身を委ねて、100%打ち込むことだと感じている。そのとき初めて覚悟ができる。これは音楽活動や起業の体験を通して得た、教訓の一つだ。
僕が就職するときに結論を導いたのは、自分がやりたいことを明確に文章化できたときだった。自分の仕事に対するスタンスとやりたいことを明確にして、後はそれを実現できる環境を選んだ。周りの友達からは「なぜ大企業に就職しないのか」ということも言われるのだけれど、その点については全くこだわりはない。そしてその観点から企業を選んではいない。やりたいことがあって、その環境が在ったのが、Web業界であり、ベンチャー企業だった。
多くの業界の知人がいるし、様々な分野で勉強に励んでいる友達もいた。学業が純粋に好きで、経済の正す立場に我が身を置くと決断する友達も入れば、マイペースに生活を維持して給料をもらいたいという観点から就職先を選んだ友達もいた。自分の友達という世界の中でも、小さな経済圏ができているようなものだ。だから周りの人がどこにいこうと、僕の決断にはあまり関係がなかった。そして、誰がどこに就職するかということに対して、あまり関心がなかった。僕が見ていたのは、その人が何をしたくて、仕事を選んだのかという点だけだ。
僕も最初は悩んだ。コンサル業界やSIer業界も見た。しかし、途中で足が止まってしまった。魅力を感じなかったからだ。その中で働いている人で、僕の目から見ても魅力的な人は少なからずいた。僕自身が働いているというイメージがあまり湧かなかった。自分のやりたいことを素直に感じるというのは、そう簡単にはできないことだ。どこか違和感を感じたとき、そこで立ち止まる人と立ち止まらない人がいる。直感的なものを大切にするには、自分の感情に素直に反応しなければならない。そこには、打算的な考えはない。今までの経験と、知識だけが影響するものなのだと思う。
良いと思うことを良いと素直に言えるだろうか。これは僕にとって難しいことだった。音楽でもそう、技術でもそう。答えのないことに自分なりの答えを出すことの難しさやもどかしさは、どんな尺度に置き換えようとしても表現し難い。僕の中で素直に良いと思うことは、「創り手としての創造力に従い、利用者にストレートに届くいいものを創ること。」だった。この感情が一番大切なものだった。
どうしても、些細なことや環境的なことを何度も計算してしまうことがある。けれど、一番大切なのは自分の考えに率直に身を委ねて、100%打ち込むことだと感じている。そのとき初めて覚悟ができる。これは音楽活動や起業の体験を通して得た、教訓の一つだ。
2011/05/05
技術は人のためにある
コンピュータサイエンスを学ぶ身として、新しいフェーズにさしかかりました。
今年に入ってからのこと。2月末からスタートアップの立ち上げに参画しました。3月末に登記が完了し、株式会社となりました。5月16日に初めてサービスをローンチします。
Webのエンジニアとしてまだまだ知らないことがたくさんありますが、新しいサービスを考え、会社を興すというフェーズは様々な体験が詰まっています。技術者としての私は、サーバの管理からクライアント及びサーバサイドの実装までほぼ全ての面について関わらなければなりません。現実的な問題も山積みです。しかし、最初から確信していることがありました。それは今でも変わりませんし、これからも変わることがない考えです。それは、技術は人のためにあるということです。
ベンチャー企業は、今までの経済性を崩すためにあるのだと思います。昔ながらの方法でできなくても、少し方法を変えれば可能なこと。少し形を変えれば、新しい面白さが見えること。利用者から見れば些細なことかもしれませんが、面白い少しの工夫を見いだし形にするためには、サービスの本質を見抜く必要が在りました。
「このサービスはここが価値だ」と、大切な部分を見抜くことこそ、僕らのようなシード段階の企業において最も大切なことです。しかし、それは大抵難しいことです。答えは一つではありませんが、私たちなりの形でそれを世の中に問えばいいのだと思っています。ベンチャーのメリットは、僕たちの頭で考えたことを実現するために、100%の努力を傾けられるということです。新しいサービスを創るというのは、そういうことだと思うのです。
技術者として身につけなければならないことは、これからたくさん出てくるのだと思います。創ることに妥協せず、地道に取り組んでいきます。
今年に入ってからのこと。2月末からスタートアップの立ち上げに参画しました。3月末に登記が完了し、株式会社となりました。5月16日に初めてサービスをローンチします。
Webのエンジニアとしてまだまだ知らないことがたくさんありますが、新しいサービスを考え、会社を興すというフェーズは様々な体験が詰まっています。技術者としての私は、サーバの管理からクライアント及びサーバサイドの実装までほぼ全ての面について関わらなければなりません。現実的な問題も山積みです。しかし、最初から確信していることがありました。それは今でも変わりませんし、これからも変わることがない考えです。それは、技術は人のためにあるということです。
ベンチャー企業は、今までの経済性を崩すためにあるのだと思います。昔ながらの方法でできなくても、少し方法を変えれば可能なこと。少し形を変えれば、新しい面白さが見えること。利用者から見れば些細なことかもしれませんが、面白い少しの工夫を見いだし形にするためには、サービスの本質を見抜く必要が在りました。
「このサービスはここが価値だ」と、大切な部分を見抜くことこそ、僕らのようなシード段階の企業において最も大切なことです。しかし、それは大抵難しいことです。答えは一つではありませんが、私たちなりの形でそれを世の中に問えばいいのだと思っています。ベンチャーのメリットは、僕たちの頭で考えたことを実現するために、100%の努力を傾けられるということです。新しいサービスを創るというのは、そういうことだと思うのです。
技術者として身につけなければならないことは、これからたくさん出てくるのだと思います。創ることに妥協せず、地道に取り組んでいきます。