Archive for 2011年6月

「シンセシス」展をみてきた

6月 26, 2011

パンフレットを持ってこなかったことが悔やまれる。
先週、東京都現代美術館で開催されている名和晃平の「シンセシス」展へ行ってきた。

それぞれ綺羅びやかだったり、幻想的だったり作品群が構成する世界観にすっかり魅せられた。
たとえ、触れることができず、十分な魅力を伝えてくれないにしても、すこしでもその世界観を感じ取れるのであれば、パンフレットでももって帰ってくればよかった。

美術作品は、実物よりも写真のほうがよい、と言われるものがある。

たとえば、有名なレオナルド・ダ・ヴィンチの『モナ・リザ(ラ・ジョコンダ)』などがそう言われる。
劣化を防ぐために照明が十分に当てられず、盗難防止用のガラスケースにおさめられた作品を見ると、ガッカリする人が多い。

私の周囲でも、「小学校の美術の教科書で見たほうが綺麗だった」という人がいた。

一方で、名和晃平の作品は、真逆だ。
実際に見ないとその魅力を十分に味わうことはできない。

下記のURLから作品を見てもらえばわかるとおり、非常に綺羅びやか作品なのだ。
宝石やシャンデリアを思わせる作品群は、写真からでもつたわる綺羅びやかさに目を奪われる。
が、展覧会で直接、目にする作品群からはさらなる魅力を感じ取ることができる。
http://www.mot-art-museum.jp/koheinawa/

その世界を支える「セル」という概念を、名和晃平は下記のように説明している。

細胞や小部屋、ユニットといった、一つの単位のことですね。それが組み合わさって世界全体がつくられている、というイメージです。
http://www.beams.co.jp/andmore/interview/inteview-with-kohei-nawa-1.html

Scumという作品群は、動物やロボットの機械の表面にビッシリと白いカビ、苔ようなものが覆っている。
PixCell-Deerという作品群では、キラキラと光るビーズが鹿を覆っている。

白いカビやビーズは、その1つ1つが「セル」という最小の単位であり、それが密集することで非常につよい生命力を感じた。

それは幻想的で、ナウシカの腐海を思わせる世界観だった。
腐海では人間の活動は停止するが、腐海で生きられる生物もいる。
ある生命の停止がある生命の活動を支える世界。

それは、食物連鎖で支えられる現実の世界と同じだが、名和晃平の作品をつうじて感じる世界は幻想的だ。

そして、その展覧会の世界観は単純に、Webや本などで写真を通じて鑑賞しても味わうことはできない。

ぜひ、幻想的な名和晃平の世界を美術館に足を運んで感じてほしい。

今の会社を去ることにした。

6月 15, 2011

6月30日(木)をもって現在の会社を去ることにした。

新卒で入社して5年間、大変のお世話になった会社で、ビジネスパーソンやエンジニアとしての良識と習慣を身につけることができた。

会社で学んだことは、別の機会に書くとして、今回は転職活動そのものについてメモがてら書いてみたい。

自分のためのものなので、だらだらと書く。

きっかけ

もともと転職願望があった、というか、今の会社で働き続けるということに現実味がなかった。

もちろん、5年で辞めること言うこと考えていたわけではなかったが、定年まで1つの会社で働き続けられるとは思っていなかった。

また、入社時にも、「いつでも、どこへでも行けるように、自分を鍛えておきなさい」と言われていたため、「いつかは別の会社に行くかもな」という漠然とした意識を持っていた。

本当に転職活動に携わり始めたのは、今年の1月にはいってからだ。

僕自身は、今の会社の仕事を楽しんでいたため、転職への意欲は全くなかった。
ただ、周囲の人たちが転職への意欲を燃やし始めた時期だった。

しかし、その人たちも転職への漠然とした不安や「どうやって転職をすすめればよいのか」という疑問を抱えており、一方で、オープンに相談ができずにもやもやしていた。

そのため、転職活動中の人たちにたいして、転職経験者の人たちの経験談を語ってもらう、という場を、これまた周囲の人たちに協力してもらって作った。

このときに聞いた話は、僕の転職に大きな影響を及ぼしていて、
・社長がプログラマをしている会社に入社したい
・自分で何でもやれる会社に入社したい
と思わさせるようになり、今回、入社予定の会社さんは、この2点を満たしている。

そして、この場が終了したあと、参加者から、「こんどは転職エージェントの人の話が聞いてみたい」という要望があった。

たしかに自分も聞いてみたいな、とおもったため、エージェントの人とつながりをつくろうとして、実際に転職サイトに登録することにした。

活動開始

転職サイトは主に2つの使い方がある。

1つは、実際にサイトを運営している会社のエージェントにあって共同で転職活動を進めてゆくという形。

もう1つは、スカウトというか、情報を登録しておいて実際はエージェントに会わずに、転職情報のみをもらうだけの形。

僕の動機は、エージェントの人に会うことだったので、前者を選択して3人ほどのエージェントに会うことにした。

具体的な会社名は挙げないけれども、どの会社のエージェントの人も話していると大変、勉強になった。

エージェントの人に会う前には、今までのキャリアについてや、今後、どのような会社で働きたいか、という要望をまとめるシートをまとめる必要がある。

嘘にならない程度に、今までのことや今後のことを書いたつもりだったが、エージェントの人たちにあって質問されると、自分のいままでの仕事や今後の仕事にたいする考えの底の浅さを痛感した。

職務経歴上は、プロジェクトマネージャ(PM)などの管理者として高く評価されたが、プログラマとしての価値はほとんど評価されなかったからだ。

これは衝撃的だった。

オープン、Web系の技術経験が不足しているのはわかっていたから、評価されないと思っていた。

とはいえそれは、10必要なところが、5とか3とかしか持っていないと思われる、という程度の認識だった。

しかし、そうではなくて価値ゼロ、だった。

もちろん、エージェントの人は面と向かっては言わない。

ただ僕が書いた経歴からは、「プログラマとして」という転職の話は出てこなくて、PMとして管理者、コンサルタントとして、という話ばかりだった。

嬉しくもあり、残念なことだった。

PMも管理者も決して嫌は仕事ではないけれど、オープン、Web系の現場にほとんど携わらないままなりたくない、と思っていたからだ。

なにより、「知らないことであっても、やらせてもらえたら、自分だってそこそこできる」という自負めいたものがある。

しかし、職務経歴書という紙の上では、いままので実績を表現することはできても、「これからこれができる」というポテンシャルを表現することは不可能に近いようだ。

とはいえ、こんなことを考えながらも、このときは「勉強なるなぁ」と他人ごとのようにも思っていた。

なぜなら、僕がこのエージェントの人たちに会っていたのは、自分の転職のためだ、という意識がなかったからだ。

3月11日

ただ、3月11日に僕の意識がかわった。

大きな地震を経験したあと、「今、死んだら満足か」という疑問を抱くようになった。

考えていると、「もっと実際に手を動かしてサービスを作るエンジニアになりたい」という思いが強くなった。

たしかに、プログラムを書くことだけにこだわり続けることは大きなリスクかもしれないが、プログラムが書けないままPMや管理者など、人に仕事を頼む側に回ることはさらに大きなリスクだ。

開発現場でエンジニアの人たちにプロダクトに集中してもらうためには、多くの問題から彼らを守る必要がある。

多くの問題の中には、政治なども含まれるが、エンジニアリングによって、救える部分も多い。

政治が開発現場に及ぼす影響は大きいが、しかしながら、エンジニアリングの問題は政治では解決できない。

そうは考えながらも、自分のキャリアを考えたときに今評価されているところ伸ばすことも重要だと思っていた。

くわえて、3月11日以降に会ったエージェントの人からも、「業務アプリケーションをつくるエンジニア」と「Webサービスをつくるエンジニア」は違いますよ、と言われていた。

そして、業務アプリケーションをつくるエンジニアとしてなら今の経験を活かした活躍が期待できるし、入社先の会社も評価してくれるだろう。

しかし、Webサービスをつくるエンジニアとしては、あなたは経験が不足しているし、書類の審査に通るのも難しいだろう。

と言われていた。

僕は、エンジニアとして業務アプリケーションであろうが、Webサービスであろうが、大きな違いはないだろうと考えていた。

そして、なぜ、業務アプリケーションかWebサービスかという二者択一を迫られるのだろうか、と納得をしていなかった。

しかし、高橋征義さんの「IT業界なんか、ないんだよ」というエントリ、そして、そこで紹介されているJole Spolskyの「5つの世界」というエントリを読んで、この二者択一が的はずれでないと考えるようになった。

そして、僕は、
・人にもっとうまく仕事をしてもらうようになるか、自分でもっとうまく仕事ができるようになるか
・業務アプリケーションをつくるエンジニアか、Webサービスをつくるエンジニアか
という2軸で自分のこの先のキャリアを考えることになった。

結局、もっと手を動かせるエンジニアとしての成長を実感したい、そして、僕はこれを作った、といえるようになりたい、という思いが強くなった。

そして、業務アプリケーションをつくるエンジニアとして今後とも働くことは、僕の将来像からは外れるようになった。

面接

4月初旬頃から、エージェントの方に薦められた会社を含めて面接の応募するようになった。
とはいえ、仕事の都合がつかなくて面接の約束がつかなかった。

また、なかなか応募条件にあう会社はなかったし、条件にあった会社との面接する機会は得られなかった。
やはり、エージェントの人がいうことは間違っていないな、と思った。

会社の条件は以下のとおり。
・開発やテストなどのフェーズに固定されず仕事ができそうな小さめな会社
・エンジニア(作る人)にたいして理解がある会社、できれば社長がプログラマの会社
・Web系の開発に携われる会社

結局、本格的に面接を受け始めたのは、ゴールデンウィーク明けからだった。
はじめて面接を受けたのは、5月10日だった。

最初の面接はかなりグダグダで、話したいことも話せず、聞きたいことも聞けず、という感じだった。

このときうけた会社は、条件で言うとWeb系開発という点しか満たしていなかったので仕方なかったかもしれない。

社会人としての経験があると、面接に出てくる人も仕事を抱えていると知っている。

また、そんななか面接を行うことは大変だと知っているので、面接してくれた社員の方には申し訳ない気持ちになった。

内定

内定をくれたのは、2回目に面接に行った会社だ。
この会社は、僕が考えていた条件をすべて満たしていた。

面接時には、今までの経験について聞かれて、すべてについて正直に答えることできた。
気になる点についても聞くことができた。

そして、その場で「うちの会社に来てください」と半分内定ももらった。

他の人たちがこういう状況でどのように反応するかわからない。

話し足りないとミスマッチが起こるかもしれないと心配するかもしれない。

労働条件とか細かく相談してから、決断するかもしれない。

ただ、僕は独り身であるため、細かい労働条件を特に気にする必要がなかった。

なによりも、面接の時に社長とお話ししていて、自分を取り繕わずに話せたし、その僕に入社てくれといってもらえたのだから、悩む必要はなかった。

これからさき、細かい点でお互いにミスマッチをかんじることあるだろうけれども、それはきっとどんなに面接をしてもなくすことできない。

とくに能力的には埋めるべきミスマッチが多そうなのだけれど、それはやりがいあることだと思った。

面接を受ける数も、内定をもらった会社も多くない。

これはエージェントの人からもらったアドバイスに反する。

たいていは、複数の会社に内定をもらって、入社先を選択できるようにしましょう、といわれる。

ただ、選択もなにも、自分の条件とほぼ合致する会社から内定をもらったので、もう1社の対抗馬を用意して比較する必要はなかった。

ということで、僕が面接を受け始めてから2週間程度で転職活動が終了することになった。

最後に

転職活動はかなり、コストが高い。
お金だけでも、
・プリンタ 1万円
・写真 3千円
・交通費 1万円
はかかっている。

仕事を抱えながら行う就職活動は、精神的にもきつい。
今の仕事を抱えつつも、転職に意識が向きがちだ。

幸い僕はなかったが、面接の予定に間に合わせるために、会社を早退する必要も出てくるらしい。

こうした状況で、現在進行形で携わっている仕事をやりこなすことは非常に難しい。

だからこそ、転職活動をはじめると一気に終わらせないと、経済的にも精神的にもキツイ。

そうなると、そのキツさから逃れるため「早く決めたい」とアセってしまう。

転職活動がこうした状況にあることは、あまりありがたくない。

もうすこしオープンに、企業とエンジニアが長期的に関わりあえる場があるといいなと思う。

今後ともやること

転職時期には業務経歴書を作成していたが、これからも定期的に更新してゆこうと思う。

常に転職の準備をしていたいというわけではなく、自分の仕事の内容をふりかえる良いきっかけになると思ったからだ。

転職活動中は月に1度業務経歴書を更新していたが、その月にどんな成果を残したか、という視点で自分の仕事をふりかえる効果がある。

良い習慣だと思うので、今後も継続してゆきたい。

役に立った本

いかは、転職活動をしている時期に読んでいて、参考になった本だ。
リンク先はAmazonにつながる。

・『選択の科学
選択するということにまつわる人間の心理的な側面について説明してくれる本。

このなかでのインフォームド・コンセントに関する人間の反応が転職に関する僕の反応につながるなぁ、と思った。

この本を読んだおかげで、転職エージェントの人に相談しようとおもったし、エージェントの人の言葉に過剰反応せずに済んだ。

・『小さなチーム、大きな仕事
37Signalsという開発チームが仕事や会社にたいする考え方を書いた本。

自分の理想とする働き方について考えさせられた。

ちいさな会社に入りたい、自分で開発の色々なフェーズに携わりたいと思うきっかけになった。

良い仕事は、優れた小さなチームから生み出されると信じている。

・『売れるもマーケ当たるもマーケ
タイトルどおり、会社のマーケティングに関する本。

しかしながら、会社を個人のキャリアに読み替えても通じる内容だった。

この本を貫いている1つの考え方に、「ゼネラリストは弱者である」というものがある。

僕は、その弱者のゼネラリストであるという自覚がある。

今後どのように、ゼネラリストである自分がキャリアを積み立ててゆくかという点について、考えるヒントが詰まっていた。

ピクト図解で先のビジネスモデルを考えた@DevLOVE

6月 14, 2011

2011/06/11にDevLOVE主催のピクト図解勉強会「世界の構造を描き出せ!!」に参加した。

もともとピクト図解については、本を読んで知っていたものの、読んだ当時はあまり魅力を感じていなかった。

「ふーん、なんかUMLっぽいなぁ」という印象で、「実際につかってみよう!」と思うまでには至っていなかった。

ところが、今回、講師をしてくださった@Akapon2010さんにお会いし、実際にピクト図を描くと実に面白かった。

4,5人の参加者がいれば、小さな新聞記事で、2,30分ぐらいはビジネスモデルについて盛り上がることができるからだ。

そして、DevLOVEのなかでも興味のある裏方さんが多かったため、勉強会を開いてみよう、と思い立った。

そんな経緯があり、今回は裏方チームとして少々コミットの量を増やし、ピクト図解勉強会を開くに至った。

ピクト図解を描くことの魅力は、「手軽に」コミュニケーションを整理しながら発展させられることだ。

システム開発においては、もともと図を使って思考や話を整理するUMLというツールがある。

そのため僕自身は、図を描くこと良さを実感している。

とはいえ、UMLは用途に合わせて使用する図自体が多く、それにともなって描き方のルールも多い。
そのため、コミュニケーションをとるための図を描き方を覚えるのにかなり訓練を要する。

なによりも、受託開発の場合には、UMLの図はお客さんとのコミュニケーションに使えない、という場面が多い。

UMLは開発者のためのものであり、お客さんがUMLの図をくもなく読めるという場合は、極めて少ない。

そのため、お客さんとその図を使ってコミュニケーションするためには、お客さんの訓練が必要になる。
その点、ピクト図解はおそらく1、2回ぐらい一緒に描けば、すぐに理解してもらえる図なのだ。

なぜ、ピクト図解は手軽で理解しやすいのか。

まず、ピクト図解には登場するエレメントとルールが少ないからだ。

どんなエレメントやルールがあるのか、というのは本を読んでご確認をいただくとして、UMLに比べたら雲泥の差がある。

それにはもちろん理由がある。

ピクト図解がビジネスにおける交換の形態を整理することフォーカスしているからだ。

ビジネスにおいて発生する交換を、誰が(Who)、誰に(Whoom)、なにを(What)、いくらで(Howmuch)、3W1Hという少ない要素で整理しているからだ。

ビジネスで発生する様々な事柄をすべて表現できない代わりに、ビジネスのモノ(サービス)とカネの交換にフォーカスをして思考と話を整理する手段を与えてくれる。

こうしたシンプルなルールだからこそ、誰にでも使える。
誰にでも使えるから、誰と話すときにでも役に立つ。

受託開発をしているとお客さんのビジネス、どのようにお客さんが稼いでいるか、にたいする理解は必須だ。

ピクト図解であれば、お客さんと話しながらビジネスへの理解を深めることができる、という期待がある。

ピクト図解でビジネスモデルを描くもう1つの利点は、論点が定まりやすいことだ。

モデルを書くとかならず、粒度が問題になる。

今回のワークでは、おもに会社間のものとお金の交換に注目した。
この視点は「社長」の視点だ。

ただ、この粒度でピクト図で交換のモデルを描いたとしても、自分の役に立つとは限らない。

たとえば、システム開発の場合であれば、システムを提供するユーザーの部門がどのような部門とつながっているか、どのような情報やモノやりとりされているか、が知りたくなる。

つまり、「ユーザーの視点」の視点での交換の情報が知りたくなる。
そのためピクト図にかぎらず、図を描くときには知りたい情報が表現できる視点を決める必要がある。

ピクト図でもこうした視点を定める必要がある点は、一緒だ。

そのため、今回は「社長の視点」で抽象的の高いビジネスモデルについてはなしましょう、などと話の前提を整えることができる。
また、図があるとその図を指し示しながら、この点のこのことについて話しています、と明示できる。

図も持たずに話ときよりも、視覚的に話している内容を表現できて話しやすくなるし、描くエレメントとルールが少なく使いやすいので、ちょっとした手間で済む。

ちょっとした手間で、論点を明示して話し合いができるので、意見の交換がしやすくなるのだ。

最後にピクト図解の中で1つの手法、ダイアグラム発想法により思考のフレームワークが提供されている点も便利だ。

なにより、自由に発想するという難しさから解放されるのが便利だ。

現状のビジネスモデルを考えた後、そのさきの理想のビジネスモデルを考えるのは難しい。
考える道具をもたず、考える道具から作り出す手間がなくなるのは、うれしいところだ。

なおかつ、その思考法がピクト図でも表現できるように紹介されているので、発想を図示できる。

現状のビジネスモデルをピクト図解で描いたあと、とりあえずフレームワークを当てはめて描いてみて、無理やり新しいことを考えることもできる。

考え方とその表現方法がセットになっている点が、非常に便利でコミュニケーションに役だつフレームワークになっている。

僕自身はまだ、ピクト図解が有効になる場面を把握できていない。

1人よりも複数人のコミュニケーションのために役立つような気もしているし、議論の発散よりも収束に適しているような気がしている。

なお、ピクト図解は板橋悟さんという方の『ピクト図解』という本で、その考え方や利点を学ぶことができる。

というか、この本の内容を実践する場が、ピクト図解勉強会という場だった。

興味をもっていただいた方は、本を手にとっていただきたいとおもう。