ひさしぶりに

ブログを書こうと思ったけど、書くことがないことを書いておく。

というわけで前の投稿から５年くらい経ってますけど私は元気です。

心の傷を抱えたエンジニアたちに捧げる #vgadvent2013

この記事はVOYAGE GROUP　エンジニアブログ : Advent Calendar 2013 の12日目の記事になります。

そろそろ折り返しですね。クリスマスまであとすこし。がんばっていきましょー

どんなエントリにするか悩みました。僕。

みんなエンジニアらしく技術を使って面白いエントリをたくさん書いているので、それに習って僕もエンジニアの端くれとして、技術的なエントリにしようと思っていた時期が俺にもありました。

ですが、会社のAdvent Calendarらしく会社の紹介をしたいと思います。

VOYAGE GROUPで働くエンジニア達のなんとなくの雰囲気が伝わればと。

心に傷を負ったことがありますか？

エンジニアたるもの、心に傷を負ったことが1つや２つありますよね？

たとえば

• bugを出してサービスに影響を及ぼしてしまった。
• 本番データを誤って消してしまった。
• イケてないコードを書いたせいでマサカリがとんできた。

などなど。

皆さん、胸に手を当てて考えてみてください。

あんなことこんなことが思い浮かんでダウナーな気分になり、向こう一週間は仕事をする気がなくなってきたことだと思います。

そう、エンジニアという生き物は心の傷と常に隣り合わせでストレスフルな状況に身を置いているのです。

心の負った傷、どうしてます？

心に傷を負ったままだと、この果てしなく続くエンジニア坂を登り続けることは出来ません。 そんなとき、様々な方法でみなさん傷を癒している（もしくは放置している）かと思います。

• ぐっすり眠ってすっかりわすれる
• 引きこもる
• やけ酒する

ですが、自身の努力だけでは癒せない傷のときはどうでしょうか？

そんな時はみんなで傷を舐め合うとか、癒やし合ったりしたいものですね。

心の傷を癒やす会

前置きが長くなりましたが、弊社ではこの重大な問題について組織的に解決すべく新しい取り組みが始まりました。

それが「心の傷を癒やす会？」です。

すべては心に傷を負った青年の心の叫びから始まった

ある日、心に傷を負った青年が青色のSNSでのつぶやいたことが発端でした。

彼はとても優秀なエンジニアなのですが、その日たまたま思いもよらない事故に遭遇しました。

当然、まわりのみんなも、「しかたないよねー」という雰囲気で彼を責めたりすることは一切なかったのですが、とても真面目な彼は心の傷を負ってしまい、自責の念に耐えかねて、SNSでつぶやきました。

「また新しい心の傷をおった」

その投稿への弊社CTO小賀のコメント

「美味いもの食いに行こうぜ！」

話は一気に加速しました。

群がる傷心のエンジニアたちが、CTOの奢りと聞いてあれよあれよと集まってきます。

もう趣旨とかどうでも良くなっている感は否めません。

以下がそのときのSNSでのやりとりのキャプチャです。

※本人の了承を得てキャプチャ及び写真を掲載しています。

この乗るしかなかったビッグウェーブに僕も便乗して投稿しました。

若干社内とは関係のない人も便乗してきていますが、そこはご愛嬌。

圧倒的スピード開催、「心の傷を癒やす会？」

弊社にはCREEDという経営理念があります。CREEDを地で行く、いや歩くCREEDといっても過言ではない小賀CTOが圧倒的スピードで、奢り熱の冷めやらぬその日のうちに予定を立ててくれました。

後の「心の傷を癒やす会」誕生の瞬間である。

こちらは当日の様子。青年が小賀CTOに慰められているのがよくわかります。

この後、ぞろぞろと他の参加者も混じって、それぞれの心の傷を晒しあったり、舐め合ったりして楽しく過ごしました。

翌日、彼の部署にいってみると、そこには心の傷が癒えた青年の元気に走り回る姿が。

傷つくことを恐れない未来へ（後日談）

それ以来僕は心に傷を負った時は大小関わらずとりあえず小賀CTOにメンションを飛ばすようにしました。

お陰でどんなチャレンジも怯むことなく取り組むことが出来るようになりました。

「僕には癒す場所がある」そう思うだけで、僕はいつでも前を向いていける。

※ちなみにこの会はまだ開催されておりませんが、きっと新年早々、ピンキリのキリの寿司を用意して僕の心の傷を癒してくれると今から楽しみにしています。

まとめ

だらだらと書いてしまいましたが、要は何を伝えたいのかというと、

• 誰しもが持っている心の傷を組織的にサポートする文化があるVOYAGE GROUPはとても素晴らしい会社
• 自分の殻を破って勇気を出して一歩踏み出すことで、世界は変えられる
• 小賀CTOにとって、おごりはむしろご褒美

ということでした。

最後に

いかがでしたでしょうか？

弊社で働くエンジニアの雰囲気が少しでも伝われば幸いです。

そんなハートフルなVOYAGE GROUPでは絶賛エンジニアの募集をしています。

http://voyagegroup.com/crew/recruit/career/

心の傷を癒やしたいエンジニアのみんなー！あつまれー！

明日は 期待の若手iOSエンジニアの @DayBySay くんです。僕も彼の若さとアグレッシブさを見習いたいと思います。

【読了】図解 問題解決力が身につく!論理的な考え方

図解 問題解決力が身につく!論理的な考え方

最近はマンガばかり読んでサボっていました。息抜きは大切と思い長い息抜きをしてました。

きっかけ

最近仕事で、問題を洗い出したり、問題を課題化するような取り組みが多かった。問題を課題化する過程で自分自身のロジカル・シンキング能力の低さが露呈して、うまく問題発見であったりその課題化ができなかったので、ロジカル・シンキングなるものをちょっと勉強してみようとおもったのがきっかけ。

この本を選んだ理由

技術書はかれこれ何十年も買っているので、本を選ぶ基準はある程度決まっていたり勘所がわかったりするのだけど、この手の本はどういうものがいいかわからなかった。なので以下の観点で本を選んだ。

• 薄い
• 簡単そう
• 絵が多い
• 安い
• とっつきやすそう

本書の内容

本書は以下の7章で構成されている

1. 論理的な考え方を身につけよう
2. 体系的にとらえる思考法
3. 発想を広げる思考法
4. 分析力を高める思考法
5. 解決策を見つける思考法
6. 説得する思考法
7. 図解する思考法

1章は導入で、考え方とか心構え、論理思考の効能？などが書かれている。

2章以降はそれぞれの章で完結していて、論理思考をする上でのテクニックやフレームワークの紹介が例を用いて紹介されている。

オススメな読み方

基本的には章毎に完結している内容なので、特定の章だけ読んでもそれなりに理解できる。ただ、1章だけは共通の考え方とか心構え的な内容なので、始めに1章を読んでおいたほうが良いと思う。僕ははじめから最後まで通しで読まないと気がすまないタイプなので、通しで読んだが、内容が難しくないのでさらっと読めるとはいえ、まぁ本を読むことってそれなりに時間を取られてしまうので、時間がない人は1章だけ読んで、その後気になる章を読めば良いと思う。

感想

内容的には薄く広く、初心者向けという感じの内容で、さらっと読めるし、なんとなーく雰囲気をつかむには良い本だと思う。できているかどうかは置いといて、普段から考えていたり、意識していたりしていたことが書かれていたので、物足りない感はあったものの、とはいえフレームワークとか図とか情報の整理の仕方とか、新たな気付きがあったのも事実なので、入りとしては良かったのだと思う（深入りするかどうかはおいといて…）。

とにかく、この手のスキルや思考法とかは技術書と違ってすぐに覚えたりできるものではなく、日々意識して使ったり考えたりしていかないと身につかないものだと思うので、日々精進して地味に継続していこうとおもう。

他にも僕のような素人にもわかりやすいオススメの本があればどなたか教えてくださいませ。

便りがあるのは？

たまにはなんてことないことを。

昨日の帰り際、実家の祖母の携帯から電話があった。埼玉で発生した竜巻は大丈夫だったのかと。
うちは埼玉に近いと行っても竜巻が発生したのとは反対方向の所沢側の方なので、全然影響はなかった旨を伝えたら、安心して眠れるといってた。いつものことながら電話はだいぶ長くなってしまい、道玄坂を下り切るくらいまで話してた。今度はいつ帰ってくるのか？東京は暑いけど大丈夫か？などといういつもの他愛もない会話。

祖母は大正生まれでもうだいぶいい歳。だけど毎回家の電話じゃなくて、携帯電話でかけてくる。
あたらしい（といっても古いガラケーだけど）ものを積極的に使おうとするところを僕は尊敬しているし、普通にすごいなとも思う。

便りがないのは元気な証拠というけれど、この歳になると便りがあったほうが元気な証拠。昔はいちいち電話をかけてくる祖母にイライラとさせられたものだけど、この歳になり、僕も祖母の長くなる話を随分と楽しめるようになった。
末永く元気に健やかに人生を謳歌してもらいたいものです。

【読了】Team Geek

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

暦の上ではディセンバー、でもハートはサバイバー。

あまちゃんを見たことがないけど、今から見たら負けだと思いながら、久しぶりにブログを書きます。

なぜこの本を読んだのか

なんとなくインターネッツを徘徊していたら目に止まったのと、そもそもどんな内容かよくわかっていなかったけど、角さん訳ってところできっと面白いだろうと思って勢いで買った。（角さんには実際にお会いしたことはない）

どんな本？

googleで働いているBraian Fitzpatrick(ブライアン・W・フィッツパトリック)という方と、Ben Collins-Sussman(ベン・コリンス・サスマン)という方が、これまで会社組織、OSS(主にSubversion)などのコミュニティの中で、様々な体験・経験を元に「人とうまくやっていく」ための振る舞い方や考え方を、体験談を踏まえ解説している。プロジェクトを成功させるためには優れたコードを書くだけじゃだめ(もちろん優れたコードは素晴らしい)で、メンバー全員で協力する必要があるから、なんかうまくやっていこうよって話。

よかったところ

各章ともになるほどなーって思うことはあったけど以下のあたりが参考になった。

HRT (Humility, Respect, Trust)

謙虚(Humility)・尊敬(Respect)・信頼(Trust)の頭文字を取ってHRT。こんな単語を聞くと、自己啓発的な何かを想像して、嫌悪感や拒否感を覚える。僕たちはエンジニアなのだから、素晴らしいプロダクトを作ることが重要だし、優れたプログラムを書くことに集中したいと考えている(はず)。本書では、HRTはそんな胡散臭い自己啓発的なものではなくて、本当に成し遂げたいもののために必要だと言っている。人間関係の力を過小評価せず、人と働くということにきちんと向き合い、僕達が成し遂げたい目標に向かって、「うまいこと」やっていくためのHRTという考え方や、それにそった行動が大切なんだと。「うまいこと」というなんかずる賢い感じがするが、本書を読むと、そういうことではなく、気持ちよく働くためにHRTを使ってよろしくやっていこうよと言っていることがわかる。だから、嫌悪感や拒否感は一旦置いといて、まっさらな気持ちで一読すると良いと思う。

船にはキャプテンが必要

どういうリーダーであるべきか、良いリーダー、悪いリーダー、アンチバターン、良いパターンという内容。
「サーバントリーダー」という言葉が挙げられている。サーバント、すなわち執事・召使いということなんだけど、リーダー、マネージャの仕事は、チームを「管理」するのではなく、執事や召使のように(いいすぎ？)チームに奉仕することだということらしい。もちろん奴隷のように働くってわけではなくて、プロジェクトがゴールに向かうために、メンバーが気持ちよく仕事できるように、技術的な側面と人間関係的な側面の両方を宜しく解決するって感じらしい。
マネージャになりたいエンジニアって僕の周りには少なくて、生涯現役！できればマネージメントなんて煩わしいものに関わらずに、良いプロダクトを作ったり、コードを書き続けていきたいと思っているエンジニアは多い。（別にそれ自体は悪いわけではないし、むしろ本能に忠実で良いし、僕もそっち側だとおもってる）
でもそういう人も意図せずにリーダーになったり、マネージャになってしまったり、またそういう能力が求められる場面に出くわしたりすることが往々にしてあるものなので、そういった状況になった時のために読んでおくと良いのではなかろうか。

組織的操作の技法

組織の中でうまく立ち振る舞って、自分たちが成し遂げたいことを達成するためのテクニックが書かれている。
こんなことを書くとずる賢い感じがするかもしれない。けど、自分の腕一本で行きていけるような天才ハッカーならともかく、そうではなく、かつ会社組織の中で少なくとも人との関わりの中で仕事をする人であれば、自分が気持ちよく働くために必要な労力であり、努力なんだと僕は思ってる。
本書では、少ししか紹介されていないが「昇進」というものについても触れられている。「昇進したら給料はあがるかもしれないけど、めんどくさい仕事がふえるだけでしょ？今の給料でそこそこ満足しているし、だったら昇進なんかしないで、今のまま仕事できればいいよ」という人は少なからずいるんじゃないだろうか？でもその仕事はいつまで続けることが出来るのだろうか？移動や組織変更みたいな外的要因によって簡単に職や立場が危うくなる。だから自分の運命がコントロールできるポジションにつく必要があるという内容。
僕は自分が働きやすい環境を作るのは自分にしかできないと思っている。待っていてもそんな環境は手に入らない。やりたいことだってそう。やりたいことがないなら、楽しそうな話を持ちかけてもらえるようにするにはどうしたらいいだろうか。最近はそうでもないけど、今の会社に入社した当初はそんなことをよく考えていた。結果的に他の人に力を借りることになるかもしれないけど、自分で考え動き出すことが大切だと考えている。
ちょっと長くなってしまったが、やりたいことができないとか、楽しく働けてない、上司とそりが合わないとかそんなような不満を抱えている人には本章はおすすめできると思う。

まとめ

結構当たり前的な内容だったり、既に実践というか取り組んでいる内容もあったが、総じて良かった。勉強になった。
もちろん全部が全部できるわけではないし、やり切るのは正直難しかったり、今の会社やチームでは当てはまらないこともあった。
OSSみたいなコミュニティで活動したことがない僕だけど、会社組織というコミュニティには(おそらく)あと数十年は属するはずなので、その中で人と働く上での考え方や行動の仕方はエンジニアでなくとも、マネージャでなくとも参考になるし、勉強になることが多いのではないかと思う。なので、タイトルに騙されず？に、少なからず人と働く機会がある人は、一度読んでみても良いのではないでしょうか？とりあえず僕はエンジニア以外のマネージャ職の人に薦めてみようと思ってる。

【読了】HTTPの教科書

HTTPの教科書

なぜこの本を読んだのか

僕は昼休みに読書しているのだけど、お昼休みだから時間も限られている中でガッツリ勉強って感じの本だと途中で切れなかったり、飛び飛びになりたくない（毎日お弁当を食べているわけじゃないからね！）のでさらっと読めそうな本を選ぶ。
なんとなく目についたのがこの本で、本屋でペラペラみたらさっくり読めそうだったのと、基礎の復習によさそうだったから読むことにした。
仮にもweb業界で働いているので、まぁ読んでみて損はないかなと。

よかったところ

• 書籍名のわりには基本的に柔らかい文章で読みやすい
• 挿絵がゆるふわなので、難しく感じない
• HTTPヘッダーのフィールドの意味とか覚えていられないので、6章はリファレンスとしても使えそう。
  • その反面、かなりの数のフィールドを紹介しているのでちょっとしつこく感じる
• webのセキュリティの話もさわりを知るのにちょうどいい難易度
  • 興味が出たら徳丸本を読みましょう！

    • 体系的に学ぶ 安全なWebアプリケーションの作り方　脆弱性が生まれる原理と対策の実践

まとめ

httpの仕組みとかを体系立てて学んだことがないのであれば、取っ掛かりとしてはとても良い本なのではないかな。
例えばエンジニア経験なしで入った会社で、とりあえず情報処理技術者の資格取れとか言われている人は、読んでおくといいと思う。
ある程度経験がある人には、復習としてさらっと読むのが吉。挿絵とかがゆるふわなのでホントにさらっと読めるけど、説明もわかり易くきちんと書かれていると思うので通勤のお供として読んではどうだろうか。

【読了】Java言語で学ぶリファクタリング入門

Java言語で学ぶリファクタリング入門

むかーし、読んだ本をお昼の読書タイムを利用してもう一度読んだ。

なぜこの本を選んだのか

1. 前の本を読み終わって、次に読む本がなかったので、手頃そうな本を探したらこの本が見つかった
2. コーディング、設計能力の伸び悩みを感じていた
3. 感覚になっていたリファクタリングをもう一度体系立てて学びたい

1はただのトリガーで、2,3は前々からなんとなく頭の片隅で思っていたことだったのでせっかくだから読みました。結構古い本なのだけど（初版は2007年！）、この手の話は、基本的には昔から考え方は変わらないから今読んでも全然ためになると思う。あと、実はリファクタリングRubyエディション（既読）と悩んだんだけど、リファクタリングRubyエディションはRubyだから書けるやり方だったりRubyだから綺麗になるリファクタリングも多かった気がする？ので、普段使っているPHPに活かしやすいほうがいいなと思って、こっちを選んだ。（そういえばPHPがメインのリファクタリング本って見たことないですね！）

どこがよかったか

リファクタリング本は大抵言えることなんだけど、流れとしては、手法の説明、例題のビフォーアフター、アフターにするためのプロセスを各手法について説明していく。良かったところは以下。

• よく使いそうな手法をピックアップ
• ビフォーアフターと過程のクラス図
• 手法のメリット、デメリット

よく使いそうな手法をピックアップ

リファクタリングの手法は星の数ほどあるけど、よく出くわしそうな場面で使えるものを重点的に説明している。僕のような3歩歩くと忘れてしまう鳥頭にはうってつけ。ちなみにその他の手法は巻末の付録でカタログとして掻い摘んで書かれているので、それはそれで助かるんだと思う。

ビフォーアフターと過程のクラス図

コードで書かれるより絵のほうがわかりやすい事多いですよね。リファクタリング本は大抵クラス図で説明してくれるので、この本も多分に漏れずそのやり方を踏襲しているんだけど、ちょっと複雑な手順の手法に対してはその過程のクラス図を書いてくれているので、過程をイメージしやすい。リファクタリングは最終的にどうなるとよいかってことよりも過程が大切だったりするので。もちろん最終形も重要。

手法のメリット、デメリット

デメリットが書いてあることが精神衛生上良い。こうするといいよ！っていう内容で、これが正義！っぽく書かれてしまうと、僕のような三下エンジニアには、心のなかで芽生えた疑問が握りつぶされてしまうので、素直にデメリットを書かれると、やっぱりそう思うよね！みたいな自信に繋がって地味に嬉しかったりするのです。あとは、自分の中でコレがいいと思って信じて疑わなかった事に、新たな発見を与えてくれる。良い事よりは悪いことのほうが発見感が強いと思う。

まとめ

個人的にあると嬉しいと思ったところは、テストについても触れてあると尚わかり易かったかもしれない。リファクタリング->コンパイル->リファクタリング...ではなくて、リファクタリング->テスト->リファクタリング...の流れがLLの多い僕的にはしっくりくるし、リファクタリング、テスト、デザインパターンは切っても切れないものだと思っているので。

とはいえ、この類の本は、進歩の激しいこの業界でいつ読んでも勉強になるので長く使える。あと、それでもやっぱり忘れてしまうので、定期的に読みなおそうと心と星に誓った。