昨年の今頃、積読になっていた「イノベーションの神話」を何気なく読んでいたのですが、とてつもなく面白くて。
「イノベーション」という言葉に抱いていたイメージを思いっきり破壊されたのでした。
それ以来、私のなかで「イノベーション」は
枯れた技術の水平思考で
価値観や考え方を一変させてしまった
プロダクト・サービスに与えられる称号
だと思うようになりました。
起こそうとして起こすものではなく、結果として起きたこと。なんですよね。
iPhoneだって3GSか4あたりを境にして一変したと思うのですが、それ以前は「へっ、なんだこのオモチャ」だったのではないかなーと思うのです。
それこそ、iPhone以前はWillcomのWindowsを積んだPHSに未来を感じていたひとが相当数いたと思うのですよ。自分もそうでした。
携帯電話/PHSとWindowsの組み合わせだったのですよ。異種配合だったのですよ。
でも、いまとなっては、あれはイノベーションでもなんでもなかったのだよなぁと思うわけです。目の付け所は、よかったですよね。
では、イノベーションは起こせるものではないかというと、そうでもないと思うのです。
それこそ「天の時、地の利、人の和」だと思うのです。
いま流行りの機械学習だって、3年くらい前は、まだバズワードにもなっていなかったと思うのです。
それこそコンピューティングリソースを潤沢に使えるようになったからDeepLearningがバズって一昨年あたりから一気に話題になったわけです。他にもいろいろと要素はありますが、そういう「タイミング」って大事だと思うのです。
場所もそう。ジョブズもザッカーバーグもアメリカではなく、ラテンアメリカだったら上手くいったのかという話です。
それに加えて、最後は人。どれだけ良いアイデアを思いつこうとも、共同創業者や協業できる会社がないとうまいこといかないこともあるでしょう。
タイミングも、場所も大事。でも、それは環境。なかなかコントロールできるものではないです。唯一コントロールできそうなものは、人でしょうか。
身内のなかだけで「価値観や考え方を一変させる」なんて天変地異でも起きない限り無理なわけです。外からの血を入れたりする必要があるのではないかと思うのです。アウトサイダーって大事なのですよ、きっと。某紅白歌合戦出場歌手も、アメリカ生まれのハーフということでアウトサイダーだって公共放送で言ってたし。
そのうえで、アイデアはアイデアのままでは意味がなく、形にすることが必要だし、その形にしたものが受け入れられないといけない。 そのためにはクオリティだって大事だし、営業だって大事だし。それこそ「無理を通して道理を蹴飛ばす」くらいの情熱あるいは狂気がないとブレイクスルーなんて起こせないと思うのです。ムラサキノホノオを吐く巨大不明生物を描ききるような、ね。
そんなわけで、輝かしい「イノベーション」と呼ばれるものの裏には泥臭い作り込みや、血生臭いライバルとの争いがあったりして、しんどい展開しかないと思うわけです。
気がついたら一時期そういう狂気を帯びながら、どうにかして突破口を作ろうとするようなこともしていたので。
なので「イノベーション」として語られる美談なんて、ただの神話。そんな神話を崇めるような風潮に食傷してしまったのでした。
いまは、なんかもうイノベーションとかどうでもいいし、ついでだから、SIerとWeb系の比較とか、アジャイルとウォーターフォールの話ももういいかなって。
単純に、自らの情熱を傾けられる仕事に、得意なことで関わりつづけられれば、それで十分幸せなのだろうなぁと思う今日このごろです。
その一方で対象顧客を知るために、その方々がいそうなイベントなどに足を運ぶのが、初手としてよいかもしれないと書きました。
ですが、イベントによっては全く別次元の場所もあれば「お隣のコミュニティ」な場合もあります。
ということで、最近首を突っ込んでしまったイベントの告知が目的の半分を占める話題です。
非IT業界な方々からすると、技術周りのキーワードは暗号でしかない。というのは、ある意味そうでしかないです。
エンジニアが、全く関わったことのない他業種の専門用語を聞いてもわからない。という話です。
ですが、一般化しつつあるようなキーワードでも、全く関わっていない方々からすると、やはり暗号でしかないようです。
「アイデアソン」「ハッカソン」「ワークショップ」「クラウドファンディング」etc...
どの言葉も、わからないひとはわからない。
正直な話、その界隈ではカタカナ語を禁止して会話したほうがいいのではないかと、最近とみに思います。
こんな状況で、下手に意識高くカタカナ語を連発しつつ案件を進めると、周囲の理解が得られないまま進行して詰むことになります。
こうしたカタカナ語が普通に通用する世界であるならば、まだ救いはあります。
エンジニアでなくても、WebデザイナーやITが絡むイベントや事業を企画される方ならば当たり前のカタカナ語。
そうしたイベントや事業に興味を持たれ参加される方ならば「ワークショップ」くらいは普通に通じます。
「ユーザーストーリー」などのプロダクトオーナー向けキーワードも、概念をきちんと伝えれば理解していただけることでしょう。
なにせ、業務側にいる方々は、普段の業務でこうしたことは考えているはずなので。
さて、こうした話で出てくる業務側に近いひとと関わる際に気をつけろと言われる話のひとつに「技術の無償提供はNG」という話です。
相応の時間と金額をかけて磨いてきた技術です。無償で見返りなしに提供するのはNGということは至極当然ですし、私も同意見です。
ですが、「こうするといいのではないか」という相談くらいは乗ることもできるのではないでしょうか。
私たちも、「このサービスどうだろう」という相談をしたい機会がありますので。
そして、こういう相談をゆるくできそうな場としてカタカナ語が通じる「お隣のコミュニティ」がよいのではないかと思います。
3.11以降、一部のエンジニアがこうした領域で活動をはじめました。
Qiitaのプロダクトマネージャーである及川卓也さんなどが有名ですね。
同じような想いから立ち上がった団体の一つにCode for Japanがあります。
「シビックテック」をキーワードに、自分たちが住む地域の課題をテクノロジーを用いて解決する活動をしているところですね。
普段の業務ではなかなか関わらない団体でもあります。また、こういう場こそ「無償」というキーワードを気にしてしまう場所でもあります。
ですが、お互いに「これどうだろう」と懇親会の場で話をするくらいであれば、エンドユーザーを知るための機会としても有益なのかもしれません。
明日、2016年11月19日〜20日にかけて、このCode for Japanのイベントが神奈川県横浜市金沢区総合庁舎で行われます。
エンドユーザーさんの感覚を知る機会としていいかもなぁと思って頂けましたら、ふらっと遊びにきてくださいませ。
個人的には、先ほど行われた前夜祭、Tokyo MotionControl Networkさんとのコラボイベントが楽しかったです。テクノロジーとエンジニアリングおいしいです。
]]>数ヶ月前に、某カンファレンスの実行委員会に顔を出したとき、こんな会話がありました。
「開催地の行政から後援を得たいねぇ」
「いいね！それでこちらは何か用意しなきゃいけない？」
「講演枠とかあると良さげな感じみたいですよ」
「それはいいのだけど、エンジニアにウケる話でないと、聴講者少ないよねぇ」
「あー、わかる。エンジニアにウケる話で、行政も関わる話って何があるかなぁ」
（以降、雑談的にディスカッション）
以前お仕事をしていた現場で、こんなやり取りがありました。
「先日お話した件、今回はプロトタイプを作ってきました」
「おお、ありがとうございます。どういうものでしょうか。」
「はい、今回は...」
「なるほど、いいですね。ところで、こういう製品があるのだけど組み合わせられる？」
「おっ、それはこちらも気にしていたやつです。面白そうですね。そちらの方向で検討してみますね。」
新規事業や新規プロジェクトが失敗した話としてよく聞くもののなかに「顧客が求めていないものを作ってしまった」があります。
ブランコの絵でおなじみのやつですね。
では「顧客が本当に必要だったもの」は、どうやって探せばよいのでしょう。
サービスデザイン、カスタマージャーニーマップ、ユーザーインタビューetc...
いろいろと方法論が挙がってきますね。
どの方法論も、先人たちの知識が凝縮されたものです。適切なタイミングで適切に使えば、絶大な効果を発揮することでしょう。
その一方で、最近感じることとして「対象顧客を代表するようなひとが、チームのなかにいるのが一番早いのではないか」というのがあります。
「エンジニアにウケる話は、エンジニアにしかわからない」という話です。
では「理想はそうなのだけど...」という方は、どうすればいいのでしょうか。
対象顧客がいるイベントなどに足を運ぶのが、初手としていいのかもしれません。
■意味：原典とだいたい同じ。慌てるとかえって悪い結果を招く。
■解説：
コラムニストちゃとらんさんの「SEの格言・迷言・ことわざ集」を読んでいて、自分も思い付いたので書いてみました。
今回は「慌てるエンジニアはバグレポートの貰いが多くて苦しむ」ということを頭の片隅に置いてもらえればいいなと思います。
さて、プログラマやSEといった仕事をしていると、慌てるケースって結構ありますよね。例えば、
などといったイベントごとのときは、多かれ少なかれ慌ててしまうものではないかと思います。
僕は夕方に突然「このバグレポートの対応、明日リリースしなきゃいけないんだ！」なんて言われたときには慌てましたね。
では、こういった慌てるイベントが発生したときに、人はどういう振る舞いをするのでしょうか。
緊急バグ対応でミスをしてしまったときの僕の振る舞いを振り返ってみると、
といった振る舞いをしていました。こうした振る舞いが、周りに迷惑をかけてしまうのですよね（自戒。自戒。自戒）。
僕に限らず、こういうことってあると思うのです。
慌てているときは視野が狭くなって、普段やらないようなミスをしてしまうのではないかなと。
「落ち着け！」と言われたとしても「こんな状況で落ち着いていられませんよ！」なんて言ってますます慌てることもあるのではないでしょうか。
こんなとき、どうすればいいのでしょう。
「銀の弾丸などない」と言われるくらいですから、「こうすれば絶対に大丈夫」なんて方法はないでしょう。
きっと、プッチ神父が素数を数えるように、自分なりに慌てずに済む方法を見つけるしかないのでしょう。
例えば、状況を紙に書いて整理するというのはどうでしょうか。
僕にとっては、頭のなかにあることを整理するために紙に書き出すことが一番性にあっているので、やらなければいけないことを紙に書き出すようにしました。
こういった形で紙に書き出して対応したときは大抵ミスをせずに済んでいたように思います。
一方で、ミスをするときは大抵この「紙に書き出す」というプロセスを忘れていたときでした。
自分が「あ、慌ててるな」と感じた時には「慌てるエンジニアはバグレポートの貰いが多いんだ！」と心で叫び、自分なりの慌てずに済むプロセスを回してみてはいかがでしょうか。
]]>しかし、「なんなんだこの展開……。セキュリティ破られてるじゃん。」と、放送を見ていて残念に思った一人です。
その後、Twitterや、防御側のネットエージェントさんのブログを見て「攻守共にちゃんとやっていたんだな。むしろ問題は編集の方なのかもしれないな。」と、多くのITエンジニアと同じように残念に思った一人です。
「あれは編集が悪いんだ！」と言うのは、簡単なことでしょう。 しかし、システムの作り手としては、僕らも同じような過ちを犯すケースがあることを思うと、なんだか単純に批判をできないのではないかと思うのです。
■あの企画に「監修役」はいたのだろうか？
「ほこ×たて」の放送内容を一人思案して思ったことは、「この企画にセキュリティの知識を持っている人が「監修役」と参加していたのだろうか」ということでした。
「きちんとした知識のある人が『監修役』として参加していたら、ああいう見せ方はしていなかったのではないか」「監修役が入れば、セキュリティの専門用語も誤解なく一般の人にわかりやすく伝えることができたのではないか」「セキュリティの企画の前にやっていた電動アシスト自転車の企画のように、3つのステージの説明ができたのではないか」「料理の鉄人のような、解説付きのコンテンツにできたのではないか」「演出の仕方を変えるだけで、セキュリティの啓蒙にもなるし、エンターテイメントとして楽しめる企画になったのではないか」。そんなことを考えてる中で、僕は「これってエンジニアの仕事にも言えることなんじゃないの？」と思ったのです。
■「監修役」が不在だと……
システム開発が失敗すること。失敗の定義にもよりますが、かなり多いですよね。「システム開発が成功した割合なんて3割しかないんだ」なんて話も耳にしたことがあるくらいです。
そうしたシステム開発の失敗理由もさまざまあるでしょう。チームのスキル不足とか、タイトすぎるスケジュールとか。 こうした失敗理由の中の一つとして
「監修役がいなかった」
というのもあると思うのです。「監修役」……分かりづらいですね。言い方を変えます。
「ドメインエキスパートがいなかった」
あるいは、
「業務の専門家が関わっていなかった」
これでどうでしょうか。思い当たる節のある方、きっといることと思います。
例えば、生産管理のシステムを構築するという話があったとします。しかし、社内には生産管理のシステムを手がけたことがある人がいない…… 小さな会社であれば、ありえない話ではないでしょう。「経験はないけど請け負う」なんてことも、きっとどこかであることでしょう。
生産管理システムの開発を始めました。チームメンバーは、いろんな本を頼りに業務知識を蓄えて開発に臨みます。しかし、顧客は開発会社に丸投げの姿勢。もう、嫌な予感しかしてこないでしょう。でも、これに近いケースってまったくないわけじゃないと思うのです。それこそ、裁判沙汰になったようなプロジェクトとか……。
そう考えたとき、僕は「あの放送内容を単純に批判することはできないな」と感じたのです。
■「監修役」のいる世界
大事なことは、
ということだと思っています。
直接かかわる人でなくてもいい。その周りの人とか、違う部署の人とか、友達とか。専門家でなくとも、率直な意見を聞けるひとがいるだけで、作ったものはより良くなっていくように思います。もちろん、専門家がいるともっと良くなっていくことでしょう。
SIという仕事で言ってみます。ASPのシステムならポンと使ってもらうだけですが、それ以外だと、何かしらのカスタマイズを行ったパッケージを使ったり、ときにはフルスクラッチで開発して、お客さまの要望に合わせます。そうしたお客さまの要望に合わせるところにこそ、お客さまには専門家としてしっかり関わってほしいなと思います。現状や将来の方向性を一番分かっているのはお客さまなのですから。
そして僕らは、そうしたお客さまの望む方向に進むために、プロとして、ITという手段で支える…… こんな関係ができたとき、僕らにとってはお客さまが「監修役」、お客さまにとっては僕らが「監修役」になって、お互いに高みを目指していけるのでしょう。
「ほこ×たて」のあの対決ではセキュリティの先生が予想屋として出演されてました。あの方がもし「監修役」をやっていたら面白いコンテンツになりえたかもしれません。
同じように、先ほどの生産管理のシステムの例でも、会社じゃないところで工場勤めのひとがいて少しでも話を聞けたら、ちょっとはいいシステムになるのかもしれません。
]]>■信頼貯金が減ると、やる気が減る
エンジニア仕事に限らず、どんな仕事をしていてもやる気が下がるときはあるでしょう。例えば……
ほかにもいろいろあるのですが、あまり毒を吐いてもいけないので……。
こうした「やる気が下がるトリガー」のなかに、実は成長の鍵があったりするのですが（お客さまが回答返してくれなかったら……を解決できたら、ヒューマンスキルは間違いなくレベルアップするでしょう）、直面しているときはやる気が落ちますね。
こんな現象が続くとやる気が削られて、しまいにはどこか遠くに行ってしまうわけです（インフラエンジニアすごろく的には「SAN値」が削られて「農場」に行ってしまうわけです）。
では、なぜやる気が下がるのか。振り返ってみると、こうした現象に遭う度に相手に対する信頼を失っていくのではないかなと思うのです。
相手に対する信頼を失っていくと「どうせ何言っても変わらないんだ……」「ずっと遅いマシンを使って仕事しつづけるんだ……」といって魂が濁っていきます。魂が濁ると相手に対する振る舞いも悪くなっていきます。その繰り返しで、自分も相手も信頼貯金を失い、魂が濁っていきます（そして「魔女化」してしまうのは、まどマギをご存じの方なら分かるでしょう）。
では、こうした魂の濁りを解消してくれるものはあるのでしょうか（「グリーフシード」ってやつですね）。
■信頼貯金が増えるとやる気が増える
今度は逆にやる気が増えるときを考えてみたいと思います。
例えば、
といったところでしょうか。
あえて「いいね」と表現してみたのですが、この「いいね」とは「認める」ということ。お客さまから自分の仕事を認めてもらえる。先輩や同僚から自分の能力を認めてもらえる。抱えていた悩みが解決して自分で自分を認める。こんなときに「明日も頑張ろう！」と思っていたのではないかなと思うのです。
こうして自分の働きが認められることで相手への信頼は高まり、もっと頑張ろうと思うようになる。そのやる気がいい仕事につながってより認められる。その繰り返しのなかで仕事は楽しくなっていき、自然とスキルもついてくるのではないかなと思うのです。
この流れは、横山哲也さんの「したいこと」より「できること」でも語られていましたね。
■自分の想いに従って「やろう！」と決める
とはいうものの「いいね」をもらうためには、やっぱり結果が必要になります。なにもしてないのに「いいね」なんてもらえるわけないです。
では、「いいね」をもらうための第一歩はどうすればいいのか。それはダニエル・ピンクが「モチベーション3.0」で書かれていたように「金銭的報酬」といった外部からの動機付けでなく「自分の内面から湧き出るやる気」といった内部的動機付けに従うのがいいのではないかと思います。
僕にとっての「自分の内面から湧き出るやる気」は、「自分のできることで誰かの役に立とう」というものでした。
例えば、先に挙げた「トラブルを解決して……」というときは、「自分のこれまで学んだことが、このトラブルを解決するのに役立てられる」と思って、現場に向かって仕事をしていました。「自分のやった仕事に対して……」も「難しい機能の実装が……」というときも同じで、「あのとき勉強したことが役立てられる」という気持ちで仕事をしていたように思います。
「自分のできることで誰かの役に立とう」という部分は、人それぞれ違うものになるでしょう。
この「自分の想い」に対して素直になって行動を始める。「自分のハートに火をつけ」周りから薪をいただくなかで、やる気は高まっていくのだろうなと思うのです。
]]>このイベント、楽天が英語化を進めていることもあって、今年は全編英語で講演を行うというチャレンジングな試みをされています。「面白そうだなぁ。でも英語かぁ。自分には苦しいなぁ。」と思っていた折、マナスリンクの野口さんに声をかけていただき、カンファレンスのレポートを書かせていただく機会をいただきました。
今回は、日本国内なのに全編英語で行われた異色のカンファレンスに、英語弱者がレポートを執筆するまでの話を書いてみたいと思います。
当初は全編英語なんて知らなかった
このレポートを書くというお話をいただいたのは、XP祭り2012というイベントの懇親会の席上でした。当初お話をいただいたときは、全編英語でやるということ知りませんでした。「英語なのは主要なセッションだけなんだろうなぁ」と勝手に思い込んで、「いいですよ！」と気楽な気持ちで引き受けました。ですが、他のレポーターの方とお話をするうちに全編英語で行われることに気付きました。
「英語弱者な自分に、全編英語カンファレンスのレポートなんてできるのだろうか」とすごく不安になりました。ですが、英語弱者な自分でも、一時期英語ができていた時期がありました。大学時代のある時期に、英語の授業を週数コマとっており、その間だけは英語に浸かりきっていたため普通に英語が使えていたのです。あのときと同じように、1カ月英語に浸かりきればなんとかなるだろう。そう考え、1カ月英語に浸かりきるべく行動を開始しました。
とにかく英語に耳を慣らした
この1カ月間でやったのは、
といったことでした。
なかでも効果的だったのは「Voice of America」という英語ニュースサイトの「Special English」というPodcastでした。このPodcastは
「英語を母語としない人々に向け、平易な語彙と文法を用いた上で、通常の3分の2の速さでアナウンサーが語る」(Wikipediaより転載)
というものです。
久しく英語に触れていなかった自分にとって、ネイティブの英語は聞き取れる状態ではありませんでした。ですが、「このPodcastのスピードなら聞き取れる！」という感じでしたので、まずはこのPodcastを毎日聞くようにしていました。
そうやって2週間ほどが経った後、Voice of Americaと平行してBBCのPodcastを聞きはじめます。こちらも、しばらくしてところどころ理解できるようになりました。
また、Skype英会話の体験セッションを受けたのも、刺激になりました。2回受講したのですが、1回目は思いどおりにしゃべれず。しかし、2回目ではなんとかしゃべれる状態になりました。大学時代に英語に浸かりきっていた際に、スピーキングをやっていたおかげなのでしょうか。昔の感覚がちょっと戻りました。
一方、Skype英会話をやってみたことで気付いたこともありました。ボキャブラリが圧倒的に不足しているのです。ここが、今の自分にとってのボトルネックとなってるのだと気付きました。
全編英語のカンファレンスに挑む
そうして1カ月英語に浸かって挑んだ楽天テクノロジーカンファレンス。前日夜遅くまで作業をしていたせいで、大事な日なのに思いっきり朝寝坊をやらかしてしまうありさまで当日を迎えました。そんな形になってしまい、泣きたくなる気持ちで電車に乗って向かっていく途中、楽天の三木谷会長の基調講演をUStreamで聞いていました。するとどうでしょう。三木谷会長の英語が理解できるのです。もちろん分からない単語も出てきます。しかし、話の筋は分かる。「これならレポートできる！」という手応えを感じ、会場である楽天タワーに向かいました。
しかし、英語の壁は高いものです。楽天タワーに到着し聴講したJeff Patton氏の講演がまったく理解できなかったのです。ネイティブの英語を理解するまでのハードルの高さをあらためて痛感しました。
一方、そのあとで聴講した楽天トラベルの渡辺さん、NRI Americaの中村さんの講演はなんとか話の筋が理解できました。さすがに全編英語の内容を翌日に書き起こす自身はなく、当日一気に原稿を起こしました。
結局のところ、日本人英語なら理解できるが、ネイティブ英語は理解できない。それが、僕がこの1カ月で到達した英語力でした。
海外カンファレンスに挑戦するためにやるべきこと
「いつかAgile Conferenceのような海外カンファレンスに行ってみたい」――XP祭り2010でITコミュニティに触れて以来、ずっと胸に抱いていることの一つであります。一方、これまで何度か海外スピーカーの講演に触れる機会があったものの、英語では理解できないし、ましてや懇親会で楽しくおしゃべりするなんて夢のまた夢。そう思ってきました。
ですが、今回楽天テクノロジーカンファレンスのレポートに挑むなかで、やるべきことが見えてきました。
1つ目はボキャブラリを増やすこと。Skype英会話を受けるなかで、ボキャブラリさえ増えれば、英語を聞いて話せるようになるだろうという実感がわきました。
2つ目はネイティブの英語に触れる時間をつくること。日本人英語はもとより、第二外国語が英語となっている方の英語とネイティブの英語は、明らかに違うのだと知りました。
まずはSkype英会話などで英語に慣れ、その後ネイティブの英語に触れるようにする。その先に、海外スピーカーと懇親会でおしゃべりし、いつかは海外カンファレンスを楽しめるようになるのだろうと感じました。
海外カンファレンスに挑戦するまでの道を見付けられた今回の楽天テクノロジーカンファレンスレポーター体験。お話をいただいたマナスリンクの野口さん、北村さんにあらためて感謝を申し上げます。
ちなみに書いた記事はこちら。ぜひ読んでいただければと思います。
楽天トラベルを支える10%Rule 〜あの日の熱気を取り戻せ！ – 楽天TC2012 レポート(8)
壁を壊せ！ 〜組織の「仕方ない」文化を打破するためのプラクティス – 楽天TC2012 レポート(9)
インクリメンタルな組織変革 〜楽天テクノロジーカンファレンスで感じた組織変革のあり方 – 楽天TC2012 レポート(10)
今回はまるっきり宣伝なのですが、この勉強会で「こんな話をしてみようかな」と構想している内容を予告として、コラムを書いてみたいと思います。
■どんな話をするの？
いま考えているのは
について話してみようと思っています。
「勉強会に行ったら人生が変わった」では、以前書いた僕はコミュニティの人々と旅をした をベースに、僕が勉強会を通してどう人生が変わったかについて話をしてみたいと思います。
記事の方は自分史な感じになっていますが、今回は勉強会で体験したこと。DevLOVEというコミュニティで体験したダイアログや何度も機会を頂いたLTについて。そしてそれらがどのようにして人生を変えていったのかについて話してみようと思います。
「勉強会で学んだこと」では、僕が勉強会に通う中で学んだこと・感じたことについて話をしてみようと思います。ここでは「勉強会に行ってこの技術を学んだよ」というトピックは話しません。コミュニティの人々と出会い触れ合うなかで、彼らから学んだ精神について話せればと思います。
例えば、ITコミュニティ秋祭りで登壇されたこしばとしあきさんから学んだ「加点評価」といったことや、和田卓人さんから学んだ「学びの在り方」について。そして、それらを通して自分の考えがどう変わっていったかについて話してみたいと思います。
「勉強会の歩き方」では、これから勉強会に参加しようというあなたに「こうやって勉強会に参加してみたらいいですよ」という話をしてみようと思います。
勉強会初心者にとってはワークショップがあることがとても大事であること。懇親会に出た方がいい理由。勉強会レポートの大事さ。そうしたことを、僕自身がさまざまな勉強会に参加した経緯や、その際に気をつけていたことなどを通して話せればと思います。
■ワークショップやるよ！
勉強会初心者にとってワークショップがあることはとても大事です。実際、僕自身も初めて勉強会に参加したときにワークショップがありました。それに参加したところから、勉強会に通うようになりました。
そうした経験から「ただ話を聞くだけでなく勉強会を体感してほしい」「参加者同士で仲良くなってもらいたい」と思い、ワークショップの時間を設けていただきました。こちらも、僕がファシリテーターをさせてもらいます。今回はアジャイル系コミュニティで以前に行われたワークを再現できればと思います。何をやるのかですって？ それは当日までの秘密ですw
■皆さんのお越しをお待ちしております！
というわけで、私が講師をさせていただく「勉強会初心者のための勉強会 2012秋の陣」は、10月27日14:00から、アイティメディアの会議室で行います。
みんなで一緒に勉強会を味わってみましょう！
]]>立つ鳥跡を濁さず 辞める者がキレイに去るさま、ってワケだが、ない話だよな
ヨルムンガンド（8巻） 高橋慶太郎
ずっと前に見かけた、マンガでのひと言である。このひと言がずっと僕の心に刺さっていた。だけど、ある人の異動話を聞いて、意外とそうでもないかもしれないと思い始めた。
自分の場合
前職から転職をしたときの話である。自分が転職活動を始めた2010年の冬、サービスを立ち上げようとして1年が経過しようというのに一向に立ち上がる気配がない。皆、仕事に対して閉塞感を感じている。「いくらやっても無駄だ」——そうしたあきらめの空気が開発ルームにただよっていた。
そうしたなかで自分が最初に転職した。周りからはうらやましがられた。
その数カ月後、前職で一緒に仕事をしていたうちの2人が転職をする。リーダーも1年後には転職した。
聞くところに後から入ってきた人もいるとは聞いた。しかし、聞こえてくるのは、相変わらずの芳しくない状況。自分が起こした転職というアクションが引き金となり、携わっていたメンバーがどんどん去っていったのではないか。自分が与えた影響はどれほど大きかったのだろうか。上の言葉の言葉に触れ、自分の行動を振り返ったとき、「立つ鳥跡を濁さず」の難しさを痛感した。
とある担当者の話
そんな転職から2年が経ったある日、自分がコミュニティ活動をする中でお世話になっていたある企業の担当者が、この9月で異動になるという話を聞いた。その話を聞いたとき、その周囲にいた人たちに衝撃が走った。「やだー！」と叫んだ人もいた。
やはり「立つ鳥跡を濁さず」はない話なのかーー僕はそう思った。だが、その異動話の先には、きちんと未来があることに気が付いた。
今年度に入ってから、その異動する担当者の仕事が、後任となる新人さんの仕事になっていった。自分が普段接するのも、その後任の人になっていった。
その後任の方が、仕事を覚えた。「ひととおり任せられるだろう」ーーそうした判断ができたから、ずっとお世話になっていた人が異動できるようになったのではないか。
異動自体、本人の希望なのか、会社の意向かは分からない。だけども、この異動で2人ともさらに成長する機会を得るチャンスが巡ってきたのだ。そう思うと、良い離れ方ができたのだろうなと感じた。
跡を濁さずではない。希望を用意するのだ。
立つ鳥跡を濁さず 辞める者がキレイに去るさま、ってワケだが、ない話だよな。飛んでいった鳥は周りにいた者の心に混乱を残す。なぜ去ったか理解できない者には、鳥は裏切り者に見え、自分も飛びたくても飛ぶわけにはいかない者は、鳥をやたらと羨む
僕の場合は「思いっきり濁しているじゃないか」という誹りを受けても仕方ないだろう。間違いなく「裏切り者」と思われただろうし、「転職できたのか」とうらやましがられただろう。
では、異動する担当者はどうだろうか。「裏切り者」という誹りはないだろう。「いいなぁ」とうらやましがられることはあったかもしれない。異動に際して、周囲には少なからず混乱や衝撃もあっただろう。しかし、その先には担当者や後任の人、ひいては会社にも成長・発展という希望が待っているのではないか。
転職と異動を同列に語るのは、無理があるかもしれない。だが、自分が数年間働いた場所を去るという点においては同じである。そうとらえてみたとき、転職であっても異動であっても、去り際にとっては「立つ鳥跡を濁さず」よりも「希望を用意する」ことの方がもっと大切ではないのかと感じた。
異動する担当者の方には今後の活躍を、後任の方には一緒に盛り立てていくことを願わずにはいられない。
]]>仕事を早く進めるために必要なこと。それは迷いをなくすことだと思う。
迷いをなくすことで大きく2つの利益がある。1つは迷って悩んでる時間が省けることだ。その分、精神力も消費しないで済む。もう1つは、正しく判断できることだ。思考がぶれないので、その分判断の精度は増す。
迷いは精神的なものとして片付けられることが多い。しかし、迷うには必ず原因がある。原因が必ずあるので、細かく解析していけば必ず解消できる。迷いを随時解消していけば、ストレスが少なく迅速に仕事が進むようになる。それができれば理想的だ。
では、どうすれば迷いを払拭して仕事を進められるのか。それに想いをはせたとき、「熟慮断行」という言葉が浮かんだ。
先人が成し遂げた熟慮断行による勝利
「坂の上の雲」という歴史小説がある。司馬遼太郎が書いた日露戦争の話だ。2009年から2011年にかけて、毎年年末にNHKでドラマも放送された。
その「坂の上の雲」の主人公に秋山真之という人がいる。日露戦争において、日本海軍の参謀として活躍した人だ。
彼は、日露戦争においてロシアの海軍を迎え撃つに当たって戦略を練りに練って、それを実行し、ロシアの海軍を撃滅する。それに当たって、彼は世界中の戦略に関する書物を読み漁り、研究に研究を重ねたという。ドラマでも、彼は入院中に日本中世の水軍の書を読み、訪ねてきた女性にその話をするというシーンがある。
ありとあらゆる戦略を学び、その要点を把握したうえで最良の戦略を立案し実行した。そんな秋山真之が揮毫した書が彼の出身地である松山にあるのだが、そこに書かれていた言葉が「熟慮断行」である。
システム開発における「熟慮断行」
そうした「熟慮断行」という言葉が、Anubisさんの言う「迷いを払拭する」ために必要ではないかと感じた。
では、僕らはその「熟慮断行」を行うために何ができるのだろうか。
これは僕の持論ではあるのだが、
ということが必要になるのではないだろうか。
システム開発をお願いしてきた顧客はいまどういった問題を抱えているのか。それをどうやって解決するのか。まずはそうしたビジョンを定める。
次に、そのビジョンをどうやって業務の形にしていくのかを決める。必要な業務は何か。それをどうやって回すのか。
そして、その業務ではどういったデータを扱うのかを決める。
当たり前といえば当たり前のことであろう。もちろん、こうした「ビジョン」「業務」「データ」をしっかりデザインしても実際に作る段階で、これが足りないというものは出てくるだろうし、「業務」や「データ」をデザインする段階でも、いろいろと意見は出てくるだろう。
しかし、その「上の概念」が定まっていれば、ぶれずに進んでいけるのではないか。そして、その「上の概念」を決めるところに「熟慮」が必要であり、実際に決まったら、その概念を実現させることを「断行」する。そうしたことが必要ではないかと思うのだ。
不安を払拭するために、確信を持つこと
先に紹介したAnubisさんの記事では、こうも書かれている。
不安は放っておくと増大する。不安が多いと迷うようことも増える。こういう状況で仕事をしていると、大きく作業効率を落としたり、突然の大失敗につながりやすくなる。
そんなことで、迷いに対してアプローチを行うことは、業務を円滑に進めるうえで重要ではないだろうか。もちろん迷いに対してアプローチするには、迷ってる人に対して大きく関わることになる。労力もそれなりに必要だ。しかし、それだけの価値はあるはずだ。
業務の進捗を管理するように、不安や迷いを管理してはどうだろうか。確かに管理をしにくいものではある。しかし、ノウハウを積んでいけば、いろいろな対処方法を編み出すこともできるかもしれない。決して無理ではないはずだ。
その、不安や迷いを管理するためには、確信が必要になると僕は思う。もちろん、確信というものは、すぐ得られるものではない。だが、熟慮を重ねて得た結論を基にして進む。その結果を確認して次へ進んでいく。そうしたことをくり返していくなかで確信は深まっていくであろう。そして確信が深まるほど、不安や迷いが出てきてもすぐに進むべき道を見いだせるのではないだろうか。
]]>そんな自分と同じように、きっと多くの方が「技術用語を使わずに話しなさい」と言われたのではないでしょうか。若手エンジニアの方々は今まさに言われているかもしれませんね。
また、相応に経験のあるエンジニアでも、後輩に技術を教える際に「どう伝えればいいのだろう」という悩みがある——そんなことを、勉強会の帰り道で聞いたことがありました。
そこで今回は、技術用語を使わずに話せるようになるための練習法について書いてみようと思います。
練習相手は美容師さん
僕は、技術用語を使わずに話す練習を、美容師さんを相手にしてやっています。
なぜ美容師さんを相手にしていたのか。それは、美容師さんが
という理由からです。
一般人にどうやって話すか
一般人の方にITの話をする場合、僕は「相手がイメージしやすいものに例えてみる」ことを心掛けるようにしています。自分の持っているイメージを抽象化して、相手にとって分かりやすいイメージに対して具象化する。そうやって話すと、実際は違うものの、本質的な部分のイメージは伝わるのではないかと思うのです。その例を2つほど挙げてみます。
まずは自分の仕事について話す場合です。初めての美容師さんと話すことになる際、きっと話に出てくるのは自分がどういった仕事をしているかだと思います。あなたは自分のやっている仕事をどうやって伝えますか？
あなたが有名企業にお勤めならば、社名を出せばきっと分かってくれるでしょう。また、有名企業でなくてもBtoCなWebサービスを提供していたりすれば、それについて話せば分かってくれるでしょう。ですが、中小企業で業務システムの受託開発をしている場合などは、どうやれば分かってもらえるのでしょうか。
「そこにあるレジのソフトを作るような仕事をしている」
そうやって僕は答えてみました。実際のところ、やってることは全然違います。ですが、相手に分かるイメージで答えてみようと考えてみたら、このような形になりました。
2つ目の例は勉強会について取り上げてみます。今年のゴールデンウィークのときに、奈良で行われた「鹿駆動勉強会」に行く話をすることがありました。ゴールデンウィークを翌週に控えたころに美容室に行った際にこの話をしたのですが、時期も時期でしたので、「今年のゴールデンウィーク、どこか行かれるのですか」といった話題からこの話になりました。
IT勉強会のような文化は、他の業界ではほとんどありません。学習意欲の旺盛なビジネスマンの間では、似たような文化もあるようですが、一般には知られていないでしょう。ましてや、「鹿駆動勉強会」はライトニングトークスが主体で、コミュニティ活動に積極的に参加するような人たちが集まる勉強会でした。そうした勉強会のことを、どうやって伝えたらよいのでしょうか。
「ITエンジニアたちの技術自慢大会を奈良の能の舞台でやる。そういうイベントが来週あって。そこで、話をしにいくんだ。」
僕はこんな感じで表現してみました。「自慢大会」という表現もまた、ちょっとずれている感じはあるでしょう。ですが、「ITエンジニアが集まって技術の自慢大会をする」とイメージが湧きやすいと思いませんか？
美容師さんに話すのがいい理由
そうやって、一般の人にITを話す練習をするのに、なぜ美容師さんが向いているのでしょうか。僕はこう考えます。
1つ目は、美容師という仕事が僕らの仕事に似ているということ。美容師さんの仕事は、お客様の要望を聞いて、その要望に対して完成像をイメージして、いい感じに仕上げてくれる。どちらかというとデザイナーに近いポジションではありますが、そうした仕事のやり方は、僕らの仕事に似ていると思うのです。
もう1つは、彼らは話のプロでもあるということ。美容室に行って髪を切ってもらうのに、カットだけでも30分はかかります（駅ナカの10分カットとかは別ですが）。その間、美容師さんはお客さまと話をしています。それを美容師さんは1日何時間も。仕事のときは毎日それをやるのです。話術のレベルが高くなるのは当然のことといえるでしょう。
細かい技術の話、設計や実装の深い話などはもちろん分かってもらえないでしょう。ですが、いま自分がやっている仕事、学んでいること、これからやりたいこと。そういったことの概要をうまく例えてみれば、自分の意図していることは十分話せるのではないかと思うのです。
練習の成果
そうやって、美容師さんに自分のやっていることを技術用語を使わずに話すことを数年やってみました。そのおかげで、実際の仕事においても、お客さまと話をする際になるべく技術用語を使わないで話せるようになりました。
また、プログラムを書いているときでも、どうやって書けば読みやすくなるか・分かりやすい言葉になるかを考えられるようになりました。
実際のところ、こうしたITを分かりやすく伝える技術は一朝一夕では身に付かないでしょう。きっと、数年はかかると思います。ですが、それこそ今日からできて、新たに費用を掛けずに、日常のなかでちょっと意識をすれば練習できるのです。
技術用語を使わずにお客さまと話をしなければいけない。後輩に技術用語を分かりやすく伝える必要がある。そんなあなたに、この練習法を今日からちょっと試してみてほしいなと思います。
]]>僕は、この業界に入ったときにVisual Basic.NET(VB.NET)を学んで以来4年間。いまも腐れ縁が続いている。5.0や6.0とはお付き合いしたくないなぁと感じているところである。
■若き日のMS嫌い刷り込み
かつて「がんばれ！！ ゲイツ君」というWebコラムがあったことをご存じだろうか。
多分、僕くらいの年代の人は知らない人のほうが多いのではないかと思うのだが。
あの記事の内容についてはよく覚えていないが、あのコラムのお陰で「Windowsなんて……」という思想が自分に根を張っていたように思う。
そうしたなかで、最初の会社で触った言語がVB.NETであった。「なぜ……」と思いながらも、仕事だと思い勉強を始めた。
■やればできる子。なのに情報がない。
そうしてVB.NETを学んでいく中で、「VB.NETでも十分プログラム書けるじゃないの」と感じた私はVB.NETを軸にデザインパターンやUMLなどを学んでいく。
UMLに関しては、Java系の本で学んだ後、VB.NETで唯一のUML本・Visual Basic .NETで学ぶUML （すでに絶版。amazonマーケットプレイスでは値段が高騰）を経て、またJava系の本で学んでいった。
デザインパターンも同様である。結城浩さんの増補改訂版Java言語で学ぶデザインパターン入門を経て、現アークウェイの中西さんによるVB.NETとC#でデザインパターンを使って学んでいった。
しかし、VB.NETで学べたのもここまで。テスト駆動開発についてはMirosoft.NETでのテスト駆動開発を使って勉強したが、サンプルコードはC#。「Effective Javaのような本を……」と求めて見つけたのはEffective C#。
そうしたC#やJavaの本、果てはRubyやTitanium Mobileで学んだ知識までもVB.NETでのアプリケーション開発に投入していく日々がいまも続いている。
■限界に達する。
そうやって学んでいったものの、限界というものはある。
VS2010から登場したMolesやPexといったテスティングフレームワークはC#が前提。ASP.NET MVCも、ネット上の情報はC#。
かといって、BasicなASP.NETではjQueryのようなモダンな仕組みを使うのにも苦労する現実。
そうした現実に直面するなかで、僕自身VB.NETを取り巻く環境の限界というものを感じてしまった。
■Visual Basicだって捨てたものじゃない。
Ahfさんは記事のなかでこう書いている。
しかし、それでも私は Visual Basic ユーザーにもっと表に出て、もっと声を出してもらいたいと考えるのです。自分自身が Visual Basic に慣れ親しんできていたことも大きいですが、今現在の Visual Basic は決して当初想定していた現場側のユーザー層に留まるものではなく、先進的なことも十分に対応ができる状態となっています。今後主流となる非同期プログラミング技術も十分利用が可能なのです。今までは C# といろいろな差がありましたが、ここ数回のバージョンアップでそれもかなり埋まってきており、構文の差などかなり範囲は狭まってきています。
（中略）
多くの人が多くの声を上げていくこと、それがお互いにとってよりよい方向へ進むために必要なのではないでしょうか。それはただのメモでもいいでしょうし、利用していて不満に感じたこと、「面倒だからこうやってやったぜ」なハック的なもの、さまざまな形があると思います。
どのような形でも構わないので、まずは少しだけ今までやっていなかったことをやってみるのは、自分たちの仕事だけに留まらず多くの方面にプラスの影響を醸し出してくれるものと信じています。そうして多くの人の声が出てくることで、さらに Visual Basic はより良い方向へと進化を続けていくものと思います。プログラミング言語を作ることができるような頭の良い人たちが考えるのですから、当然それを利用する側である自分たちが思うベスト・ベターな方向とは異なる道へ踏み出すこともあるでしょう。
まさしくそうなのだ。多くの人が多くの声を上げていったからこそ、JavaやPHP、Rubyといった言語は発展してきたのだ。一方VB.NETの技術者の多くは何かを発信してきただろうか。
きっとそれは自分にもいえることであろう。私自身、VB.NETの技術者として何かを発信してきたのかと自戒せざるを得ない。
■VB.NETに罪はない
僕自身、持論としていることがある。「言語に罪はなく、扱う人に問題がある」というものである。
VB.NETは今も進化を続けている。C#と比べると一歩遅いかもしれない。だが、それでもオブジェクト指向での開発は十分にできるし、他言語で生まれた手法はいまもC#, VB.NETに取り入れられている。かつて嫌い刷り込みをしてしまったMicrosoftに対しても、その刷り込みはほとんど残っていない。むしろ、いろんな場面で感謝をしているくらいだ。
一方、そうした新しい手法・よりよい手法を学ぼうとしている人はどれだけいるのだろうか。
世の中に不満があるなら自分を変えろ、それが嫌なら耳と目を閉じ口をつぐんで孤独に暮らせ。
（攻殻機動隊 STAND ALONE COMPLEX）
という言葉があるが、VB.NETを扱う人々は、孤独に暮らす人々が多過ぎるのではないか。
そうしている間に、心ある人々は自分を変え、言語を変え、この世界から姿を消していってしまっている。そう思えてならない。
]]>人生とは、あなたが出会う人々であり、その人たちとあなたが作るもの。 だから、待っていないで作りはじめなさい。 人生は短い。 情熱を身にまとい、自分の夢を生きよう。 THE HOLSTEE MANIFESTO
僕は、勉強会と出会い、そこに集う人々と会う中で、エンジニアとしての人生を歩み始めることができました。
初めて勉強会に参加したときから、もうすぐ2年が経とうとしています。その2年で、僕の人生がどう動いていったか。それを書いてみようと思います。
■冴えなかったコミュニティ参加以前の自分
小学校のころ、成績は良い方でした。ただ運動は苦手。いじめられタイプというかいじられタイプというか、そんな子どもでした。
中学に入ってから、いじられの度合いよりもいじめの度合いの方が増してきました。それだけが原因ではないのでしょうが、おそらくストレスが原因で自律神経失調症を患いました。結果として、学校に通えなくなります。
そんな状態だったので、通っていた高校も不登校児などのわけありな人たちが集まっていました。勉強も中学のあたりからやり直し。「こんなんじゃない」と思いながら3年間過ごしていました。
大学はサークル・学生会の活動をしていました。でも周囲にいまいち馴染めずにいたように思えます。コミュ障というか、馴れ合えなかったというか、そういう自分だったのでしょう。
そんな中、いろいろと忙しくなった大学4年の4月ごろに体調を崩しました。後にうつ病であることが分かります。
結局就活ができないまま卒業した後、縁あって前職の会社に就職。そこは人材派遣や客先常駐という言葉で揶揄されるような会社でした。しかも、どこかの現場に出される前にリーマン・ショックが起こって案件がなくなり、自社に引きこもることになります。
そこで研修サービスを立ち上げると言われたものの、「能力なくて無理でしょ！」と反発していました。それでも頑張っていたけど結局2年で辞めることとなります。
■勉強会にのめり込んだ日々
そうして現職に移ったタイミングで初めての勉強会に参加します。XPJUGが主催する「XP祭り2010」でした。そこで選んだセッションは、アジャイルUXのワークショップ。
同じテーブルで手を動かす人がいたのが幸いして、その後の懇親会ではぼっちにならずにすみました。そうやって同じテーブルで手を動かした人のうちの1人は、このあともいろいろなところで関わることになりました。
次に門を叩いたのは、懇親会で話したワークショップの講師が関わっているすくすくスクラム。ここに参加したことがきっかけとなって、本格的にアジャイルを学び始めます。この当時は、そうやって知ったアジャイルを組織で取り入れたいと思い、職場の人にいろいろと話をしていました。ですが、結果としては玉砕。いま思えば、ある意味、熱に浮かされた状態だったので、仕方のないことだったのかもしれません。
とはいえ、その後もアジャイル関係の知識は継続的に勉強を進めていきます。そうやって得た知識は、単独で進められる仕事に対して使っていくようになりました。
そして、自分にとってのホームとなったコミュニティ、DevLOVEと出会いました。勉強会参加以前に独学で学んでいた設計技法の実践者が講演をされることをTwitterで聞きつけて参加をします。思えば、ハードすぎる内容でありました。あのとき聞いた話を、いまどこまで理解しているかは怪しいところであります。ですが、そうやって新しい知識を仕入れていくことが快感でした。
だからでしょうか。あの当時のDevLOVEは月に何本もの勉強会を開催していました。自分はそれらに足しげく通っておりました。また、このころから、勉強会の内容をマインドマップでまとめて公開することを始めました。これが思いの外評判を集め、以来いくつかの勉強会では今でもマインドマップの人と認知されています。
そしてここまでくると、もう一参加者としては留まれなくなるものなのでしょうか。DevLOVEのある方に背中を押されて、初めてのLTを体験します。2010年の年末のことでした。
■格の違いを思い知らされる
そのLTを体験した夜、DevLOVEのスタッフに誘われ参加をします。参加をしたのはいいのですが、できたことは、当日の手伝い。それはそれでいいのでしょう。ですが、自分で企画を出したくとも、出せるネタがなくて悔しい思いをしました。
あるとき、DevLOVE内でやっていた開発プロジェクトを覗く機会がありました。そこで、「こんなものを作りたい」と熱く議論を交わしていたのですが、自分に何ができるか考えたとき「自分は何もできない」ということを痛感しました。
使ってる言語が違う。設計の能力なども、明らかに上。当然といえば当然のことで、当時の僕はまだ3年目。明らかに積んできた時間が違いました。
そうやって、鼻っ柱を折られ、悔しさを感じていくなかで、「勉強会に参加するよりも、まず自分で学ぶ時間を作らなければ」と思うようになりました。寒風吹きすさぶ、2011年冬のことでした。
■独学と勉強会と発表と
転機となったのは、2011年3月11日。東日本大震災でした。テレビの報道に嫌気が差し、交通も麻痺して出社不可能となったときに始めたのがHead First Railsの写経でした。1週間かけて写経を行った後、写経ではなく、自分のコードを書きたいと思うようになります。そこで書いたのがTwitter Bot。当初選んだ構成でうまく行かなかったところをTwitterで質問して助けられたりしました。
また、Rubyのコードを書く時間を作ろうと思って参加したのが、黙々とコードを書くのが主体の勉強会であるyokohama.rbでした。
初心者として勉強会に参加しつつ、独学を進めていく。そうやって学んでいく中で、2012年の7月、DevLOVEで行われたRuby初心者向け勉強会で発表する機会をいただきました。
「あの発表を聞いて、Rubyに触れてみました」そんな声も聞けました。
「自分の経験は誰かの学びたいという想いを駆動させる。」それに気付いて、それから4カ月ほど、LTができると聞きつけた勉強会でLTをして回っていました。
何度かLTをするなかで、スライドのクオリティが上がっていきました。その経緯をまとめて、2011年の12月には、DevLOVE Pubという電子書籍に取り組むコミュニティで出したLTの同人誌に寄稿をさせていただきました。
また、このころ、コードに対する興味はRubyからiOSに移りました。Objective-Cを独学で学びました。ですが、結局どう書けばいいのか分からずに挫折をします。だけども、自分でアプリを作りたいという想いは消えませんでした。
年が開けて、今年。2012年1月。エンジニアとして、開発についてコミュニティで語れるような軸を作ろうと思い、Titanium Mobileを学び始めます。ここでもRubyを学んでいたときと同様に勉強会に参加しつつ独学をしていくスタンスを取りました。
横浜へなちょこiOS勉強会とTitanium meetup tokyoに参加しつつ、アプリを作っていき、無事公開。そこに至るまでの経緯を横浜へなちょこiOS勉強会で発表させてもらいました。
■2周目の学び・2周目のコミュニティ活動
こうやって、アプリを作ったりLTをしていくうちに、あれも作りたい・これも作りたいというアイデア、あれを話したい・これを伝えたいというアイデアが湧いてくるようになりました。
その自分の想いに従って、再びRubyを学び始めました。そろそろ1つWebサービスを作ってみようかと企んでおります。
いまここでコラムを書いているのも、この自分に想いに従ってのことです。「自分の経験は誰かの学びたいという想いを駆動させる」これを信じて、これからもコラムを書いていこうと思っています。
アジャイルから始まった僕のコミュニテイ人生。開発系コミュニティを経て再びアジャイルに戻ってきてもいます。ずっと行きたいと思っていたアジャイルサムライ道場は今年に入ってから横浜の地で参加。すくすくスクラムにも、再び参加するようになりました。
1年間、いろいろなことを経験して貯めた経験値が多かったのでしょうか。昨年の今ごろと比べると、理解の度合いが増していることに気付きました。
LTのクオリティも上がっているのではないかと感じています。ここで書いているコラムや、2012年4月に京都のプログラマーズナイトというイベントでやった初めてのDJ。それらの経験が、表現者といしての力を引き上げてくれたように思います。
それらを通して得た気付きを、改めてDevLOVE PubのLT同人誌に盛り込みました。8/12のコミックマーケット82 東地区“U”ブロック－04b DevLOVE Pubブースにてその同人誌、「ライトニング・トークス 脅威のプレゼン さあ、プレゼンに目覚めよう」の頒布を行います。
■僕はコミュニティの人々と旅をした。そして……
「高校デビュー」「大学デビュー」といった言葉があります。ですが、僕はそれができなかったように思います。だからこそでしょうか。いまになってようやく「コミュニティデビュー」を果たせたのかもしれません。
それができたのも、技術に対して真摯に向かい合う人々と出会い、共に深めていけたから。成長意欲が人一倍強い自分にとって、最高の出会いとなりました。
そうして、コミュニティの人々と旅をしていく中で、非常に多くのものを得られました。これからも、コミュニティと共にありたい。そう願っています。
僕の例は極端かもしれません。ですが、僕と同じように、コミュニティに出会って人生が大きく動いた人も多くいると思います。
これを読んでいるあなたが、今の自分の人生に閉塞感を感じているようならば、勉強会などこれまで自分が触れてこなかった人々の集まりに行ってみてはいかがでしょうか。
それで、もしその勉強会が合わなければその先に行かなくてもいいのです。肌に合えば何度も通いましょう。
そして、自分の想いのままに巻き込み巻き込まれていってください。
そうやって起こした行動の1つ1つが、あなたの人生を動かしていくと信じています。
May community members be with you. コミュニティの人々と共にあらんことを。
]]>ときにチャンスは一度しか訪れません。しっかりつかみなさい。 - THE HOLSTEE MANIFESTO -
そのチャンスをつかみにいったからこそ、今の自分がある。そのチャンスはどこに転がっていたか。＠ITに転がっていた。
本日7月2日、アイティメディアさんがオフィスを移転しました。オフィス移転、誠におめでとうございます。今回はアイティメディアさんのオフィス移転を祝して、お祝いというより応援になるのかもしれないのですが、そんなコラムを書かせてもらいます。
きっかけは＠IT
僕がいま、あちこちのコミュニティに顔を出して、こうやってコラムを書いている。そのきっかけとなったのが、＠ITのNUnit入門 Test Firstのススメ ［NUnit 2.0対応版］という記事でした。
この記事に出会ったのは、エンジニア1年目の頃。前職で「単体テストやりなさい」と言われ、どうやればいいのか調べていたらこの記事に出会いました。
この記事がきっかけとなり、僕はTDDやアジャイルについて勉強を始めることとなりました。
オブラブの記事や、＠ITのNAgile記事を何度も読んでいました。そのなかでアジャイルの考え方に心酔していきます。
もし、この記事を読んでいなければ、僕はコミュニティに参加することもなかったでしょう。いまこうしてコラムを書いていることもなかったと思います。
転職も＠IT
前職の事業方針に嫌気が差した僕は、2年目にして転職をすることとなります。このとき、最初に登録した転職エージェントは＠ITの転職サービスで見つけたものでした。職務経歴書も、＠IT自分戦略研究所（自分研）の記事を参考にしていました。
自分研の記事で学んだこと。それは、どうやって自分の経験をアピールするかでした。開発経験も実績もない。そんな自分がどうすれば自分のやってきたことを伝えられるか。
そうした状況で学んだ経験の書き方は、おそらくこのコラムに生かされているのだと思います。
結局、転職自体は人のコネで移ることとなりました。ですが、自分研で得た知識があったからこそ、転職を果たせたのだと思っています。
コミュニティでの立ち位置を見つけたのも＠IT
現職に移った同時期に、僕は初めてコミュニティへの参加をしました。コミュニティに参加した当初は、そこで出会った人々の知識・熱意・行動力にただただ圧倒されてばかりいたように思います。
いま振り返ってみると、その当時、僕はまだ何も分かっていませんでした。エンジニアとしての振る舞いであったり、目的・ビジョンの重要性であったり。しかし、そんな僕でもコミュニティの人々と接し、また幾度かのプレゼンの機会を通して、そういったことを学んでいきました。
その最中に出会ったのが、エンジニアライフのコラムニストの方々でした。昨年のITコミュニティ夏祭りに、僕はDevLOVEというコミュニティからライトニングトーカーとして参加しました。ここでエンジニアライフのコラムニストの方々や自分研の編集者さんと出会います。その後も、粕谷さんをはじめとするコラムニストの方々とはTwitterでのやり取りを通して交流をしていきました。
今年の始め頃、僕が粕谷さん・組長さんとTwitterで話していた際に「コラム書いてみたいんですよね」と言ったところ「書いてみましょう！」と言ってくれました。その後押しがあったからこそ、僕はこうしてコラムを書くことができています。
僕は、このコラムを書いていくなかで、ようやくコミュニティのなかでの自分の立ち位置を築くことができました。
経験や技術力ではコミュニティで活躍している先輩方には到底かなわない。新しい技術を話を耳にしたり、自分で独学をしていくなかで、改めて自分の力不足を痛感する。だけども、そのなかで思索を深めていき気付いたことが多くある。ならばそれを伝えよう。
そうしてコラムを書き始めたことで、ただ「周りに追いつき追い越せ」とするのではなく、コラムニストとして自分の立ち位置を確保した上での学びができるようになりました。
チャンスをつかむために必要なもの
思えば、僕がいまこうしてコラムを書いているのも、多くのチャンスをつかみ取ってきたからなのでしょう。
上司の無茶ぶりに応えようとした。
エンジニアとして誇りをもって仕事をするために転職をした。
コミュニティの人として、価値を提供しようとした。
そのための行動のなかにチャンスがあり、知らず知らずのうちにそのチャンスをつかみ取っていたのだと思います。
その行動を起こせたのはなぜか。僕は「勇気」「熱意」「真剣さ」だと思っています。
前職で上司の無茶ぶりに応えられたのは、「何とか形にしてみせる」という「真剣さ」があったから。
転職ができたのは、座して死を待つより、未来をつかみにいこうとした「勇気」があったから。
ITコミュニティ夏祭りでLTができたのは、自分が得た感動を伝えたいという「熱意」があったから。
そうやって、いろいろなものに挑戦したからいまの自分がいる。そしてそれを支えてくれる人がいたからこそ、いまの自分がいるのだと思います。
すべてのエンジニアにエールを贈る
僕の「いま」があるのは＠ITのおかげでした。これからも、＠ITのお世話になるのでしょう。僕に限らず、多くのエンジニアが＠ITに支えられているのではないかと思います。だから僕は、＠ITにこれからも世のエンジニアの人生を駆動させる存在であって欲しいと願っています。
そして僕も、コラムニストとしてすべて心あるエンジニアに向けて、エールを贈るコラムを書いていければと思います。
＠IT編集部の皆様、読者のみなさま、コミュニティでお世話になっている皆様、これからもどうぞよろしくお願いします。
]]>いままでJavaとWebアプリの知識だけでそこそこごまかしが効いているけど、そろそろ賞味期限切れなのでモバイルアプリの知識を習得しないと老害化してしまう
これは、とある勉強会で知り合った方が今年の2月ごろにツイートしていたものです。それを読んだとき「それならば新しいことに挑んでみましょうよ！ 」と思って、1つのWeb記事を紹介しました。 今日はその記事を通して、未知の世界へ旅立つ・新しいことに挑戦する意義について書いていこうと思います。
■コンフォートゾーンから飛び出せ
「コンフォートゾーン」という言葉があります。意味は「心地良い空間」。そこにいると高いパフォーマンスを出せるそうです。使い慣れたプログラム言語とフレームワークで仕事をしていたり、気の合う仲間たちと仕事をしていたりするような状況でしょうか。ですが、自分や組織をさらに成長させるためには、この「コンフォートゾーン」から抜け出す必要があるそうです。
それが書かれているのが「ほぼ日刊イトイ新聞」の「適切な大きさの問題さえ生まれれば。」という連載です。
ぼくが若い人たちによく言うのは、 ぬるま湯に慣れてしまうのはよくない、 ということですね。 やっぱり、いったんベンチャーと名乗って、 さらにそこに集まってきた人がいる以上は、 ステップアップしていってほしいんです。
なにか自分のやりたいことがあって、 その好きなことをやって過ごしていると それを喜んでくれるユーザーの方が集まってくる。 でも、ここで完結しているだけだと、 そのつぎへ進むのに、足りないんですね。 英語でいうと「コンフォートゾーン」 という言葉があるんです。 「Within the Comfort Zone」とかね、 要するに、自分が非常に居心地のいい場所にいる。 そこそこ利益が出て、 20人くらいの社員に給料も払えて、 ある種のユーザーからは喜ばれている。 だけど……ということですね。
ここではベンチャー企業に向けて語られています。ですが、僕らエンジニアの自分戦略にも、この考え方は当てはまるだろうと僕は考えています。
■コンフォートゾーンから抜け出そうとした
3年間、.NETでプログラムを書いてきた。本だって何十冊も読んだ。そのおかげで、相応に仕事はできるようになった。いまのままでも十分やっていける。でも、いまはスマホアプリ隆盛の時代。数多の綺羅星が輝くWeb業界もある。勉強会に参加する中で、圧倒的なスタンド能力を持つエンジニアに出会ってきました。
そんな状況に触れる中で、「僕もあの人々と同じように活躍したい」という憧れを抱きました。また冒頭のツイートをした方と同じように「このままでは老害化していく」という危機感を感じました。
もちろん、このまま.NETの技術を磨いていくことは必要。だけど、それ以上にまだ見ぬ世界に触れてみたい。その想いがあふれだし、昨年の夏ごろから僕はスマホアプリの勉強を始めました。
■失うものなど何もない
昨年夏にObjective-Cを使ってのiPhoneアプリ開発を学び始めたものの、すぐに挫折。その後Titanium Mobileを使ってアプリのリリースまでこぎつけられました。そこで得られたコードの書き方が、いま仕事で書くコードの書き方にフィードバックされています。
iPhoneアプリの開発を学ぶ中で、今まで足を運んだことがなかった勉強会にも参加しました。まったく知り合いがいない状況でぼっちになりかけたこともありました。ですが、実際に作ったアプリが自分の看板となり、楽しくお酒を飲み交わせました。
そうやって、いろいろな勉強会に参加するなかで多くの人と出会いました。その人達のTwitterを見ていたら、技術のトレンドの流れとでも言うべきものが見えてきました。
このゴールデンウィークでは、コラム「雲（クラウド）の隙間から青空が見えた」の粕谷大輔さんがきっかけで京都の「プログラマーズナイト」というイベントに参加。初めてDJに挑戦しました。これも「勉強会の仲間ならば、きっと受け入れてくれるだろう」という信頼があったからこそできたことだと思っています。そこで得られた感覚は、ライトニングトーカーとしての振る舞いにフィードバックされつつあります。
「失うものなど何もない。挑戦するからこそ得られるものの方が圧倒的に大きい」いま、僕はそう感じています。だから、いろんな人に「未知の世界へ行ってみようよ」と呼びかけています。
我々は芸人。芸事のためにスキルを磨く。
新しい知識や技術を学ぶ場合、独学や勉強会に参加するまでならば間違いなく失うものはないでしょう。それまでに積み重ねてきた経験は生かせますし、新しく学んだ知識や技術は今の仕事へもフィードバックしていけるでしょう。
新しい知識や技術を仕事に持ち込む場合、少なからずリスクは出てくるでしょう。ですが、そのリスクを取らずにいまのままの仕事をしていくこともリスクになりえます。どちらのリスクを取るかは人それぞれなのでしょう。
昨年の6月ごろでしょうか。僕の尊敬するエンジニアの方がある勉強会でこんなことを言っていました。
我々は芸人。芸事のためにスキルを磨く。
そう。私たちは芸人。それぞれの持つ技術＝芸を使って世の中に価値を提供する芸人なのです。ならば、恐れず、面倒がらずに芸を磨いていきましょう。未知の世界に旅立ち、見聞を広めて、帰ってきましょう。そのチャレンジが、私の、あなたの、血肉となるのですから。
]]>