MyCSS

2014/04/17

AWS Elastic BeanstalkはImmutable Infrastructureそのものじゃないか はてなブックマークに追加

ちょっと遅くなってしまいましたが、第13回 JAWS-UG札幌 勉強会で発表してきましたので、ご報告いたします。なお、今回でこのシリーズは完結いたします(笑)



ちなみに先月の JAWS DAYS 2014 では、Immutable Infrastructureのトラックが常に超満員でして、通路にまで人が溢れおりました。また、東京方面ではImmutable Infrastructure Conferenceが開催される位、ちょっとしたイミュータブル祭りになっているようです(笑)しかし、その中であまりAWS Elastic Beanstalkについて話題が出てこない気がしたので、今回あえて発表させてもらいました。

まだサーバーにSSHでログインしてるのかい?

AWS Elastic Beanstalkは、まさしくBlue Green Deploymentをするためのサービスですし、そもそもEC2起動時にkey pair指定をしなくても良い=サーバーにログインしなくてもいいんじゃね?という事実が、イミュータブルっぷりを発揮しております。
※ちなみにスライドにもある通り、個人的にはkey pairを指定していますw でも個別のサーバーにSSHでログインする機会は滅多にありません。

Elastic Beanstalkがリリースされた2010年当時は、このkey pair指定をしなくても良い、という意味が全く分かりませんでした。当時はconfigで環境を自動構成する機能(公式ドキュメント)もなく、カスタムAMIをあらかじめ準備する必要がありました。しかし、カスタムAMIを作るという事は、そのAMI自体を管理して行かなければならない、という別のタスクが発生します。例えば、先日のHeartbleed Bugのような重大なセキュリティの問題が発生した場合、そのソフトウェアを最新版に更新した上で、再度AMIに保存し直す、といった作業が発生します。管理すべきものを増やしたくないのに、これでは本末転倒です。Chefなどのプロビジョニングツールも良いのですが、そこまで大げさじゃないんだよなぁ、という場合、このconfigがちょうど良い感じなんです。

ちなみにconfigではスクリプトも実行出来ちゃいます。ということは、要するに何でも出来るのですが(笑)configでは書ききれずにスクリプトを書いてしまう場合は、無理してElastic Beanstalkを使わずに、別のソリューションを使った方が良いと思います。(【参考】EC2 インスタンス上のソフトウェアのカスタマイズ

インフラの構成管理をある意味強制される

基本的にconfigはアプリケーションのソースコードの中に入ります。具体的には
$APP_ROOT/.ebextensions/*.config
という場所に入りますので、基本はgitやsvnなどのソースコード管理システムの中に一緒に放り込まれるでしょう。そうすると、インフラの構成もバージョン管理されてしまうという・・ まさにDevOpsな世界が自動的に出来上がりますw AWSはこの点を意識しているのかどうか・・よく解りませんけども、個人的には良く出来ているなぁ、と思います。

運用のベストプラクティス?

Amazonの長年の経験で培ってきたものがAWSにあるとすれば、まさしくサイト運用のベストプラクティスが詰まったものがElastic Beanstalkなんじゃないか?と思います。他のサービスに比べれば地味でパッとしないかもしれませんけども(笑)使いどころを間違えなければ、Elastic Beanstalkは初期学習コストも異様に低いですし、サイトの運用負荷を劇的に下げられる強力なサービスだと思います。

2014/02/13

リモート勤務は手段であり目的ではない〜「強いチームはオフィスを捨てる」を読んで はてなブックマークに追加

読書感想文シリーズ、その2です(笑)

強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」
ジェイソン・フリード デイヴィッド・ハイネマイヤー・ハンソン
早川書房
売り上げランキング: 179

すでにあちこちでレビューされているこの本ですが、これはリモート勤務歴2年4ヶ月の自分にとって必読の書(?)であり、ましてや以前はRuby on Railsのお世話になっていましたので、頑張って感想文を書いてみたいと思いますw

これはリモート勤務の本ではない

っていうか、いやいや、そんな事はなく、37signalsが自ら実践してきたリモート勤務について、とても歯切れよく、わかりやすく書かれた良著です。これからリモート勤務を導入したいと思っている個人や組織にとって、大変に説得力のある文章がたくさん詰まっていますので、読むべき一冊だと思います。もし、自分がクラウド移住をする時にこの本があれば、どんなに助かった事だろうな、と正直思います(笑)。この本に書いてある事、多かれ少なかれ、自分が通ってきた道が書いてあって、「あー、間違ってなかったー。やっぱそうだよねーw」的な思いで一気読みしました。

ただ、読み終えた自分の第一印象は、「これは(究極には)リモート勤務の本ではない」という事でした。

この本にも書いてある通り、仕事の質を上げ、かつ、個人の満足度もアップさせるための「手段」としてのリモート勤務は、すでに充分に出来る環境にあります。ただし、リモート勤務をする事が目的ではありません。目的と手段をはき違えてはいけません。

強いチームであるには

この本では、散々「コミニュケーション」について触れられています。一人で全てをやっている訳ではありませんから、当たり前なんですけど、リモート勤務の場合はむしろそれを意識的にやる必要があります。これは自分の実感から来るものでもあり、とても賛同出来るものです。ただ、これは、リモート勤務当事者だけの問題ではなく、一緒のチームで働いているオフィス勤務の人間にも言える事、というのが、意外に解りにくい部分でもあります。

例えば・・よくあるのがSkypeなどのWeb会議で話す時に、顔を映さない人。これが非常にやりにくいです。向こうはこっちの顔が映っているから別になんとも思わないのだろうけれども、これでは普通に電話で話した方が数倍マシです。ただ、こういった事は自分がリモート勤務を始めた頃にはあまり無かった事であり、何でなんだろうと考えてみましたが・・おそらく自分は本社にいない、という事に、本社側がすっかり慣れてしまった結果なんだと思います。

ほんと、しょーもない事なんだけれども、そのような事が積み重なってくると、だんだんコミュニケーションを取る事自体が「ストレス」になってきてしまう。それでは全く意味がありません。でも、よくよく考えてみると、じゃぁ常にオフィスにいれば、そこは大丈夫なのか?という疑問が沸々とわき上がってきます・・

皆さんの所でも、近くの人に伝えるべき要件をメールで済ましたりしていませんか?それで良い場合も多々ありますけど、内容によっては「メール送っておいたから後で見てね」くらい声をかけるのではないでしょうか?「メール送っておいた」というのが「相手に伝えた証拠」的な感じになってしまうと、そこから美しきすれ違いが発生致しますww

ただし、あくまで個人のコミニュケーションに対する考え方に寄る部分も大きいので、一概には言えない部分もあるでしょう。その点、四六時中オフィスに一緒にいて、同じ空気を吸っていれば「空気を読む」事によって知らず知らずに伝播させる事もある程度可能かもしれませんね・・ 実際、自分が出勤していた頃は、そこは無意識に感じ取れていた部分かもしれません。でも、空気はネットを超えられないので、長くリモート勤務をやっていると、その点が浮き彫りになってきます。そして、そこがどうしてもうまく行かないのであれば、リモート勤務自体、不可能なのかもしれません。


けれども、それって本当にチームでしょうか?


原著のタイトルは「REMOTE -Office Not Required-」ですが、邦題は「強いチームはオフィスを捨てる」です。このタイトルをつけた人はスゴいと思います。まさしくそういった事を色々と考えさせられる、素晴らしい一冊です。

2014/01/08

リモート勤務に付加価値を付ける〜「起業家のように企業で働く」を読んで はてなブックマークに追加

年末年始の読書課題(笑)として、こちらの本を読んでおりました。

起業家のように企業で働く
小杉 俊哉
クロスメディア・パブリッシング(インプレス)
売り上げランキング: 445

自分自身、東京の会社に勤めながら札幌で一人リモート勤務をしていますが、すでに2年が経過し、少しずつ考え方が変わってきた様な気がしています。その辺を少し整理したくて、この本を手に取りました。


リモート勤務に付加価値を付けたい
仕事は東京のメンバーと一緒にやっておりますが、支店がある訳でもない札幌で仕事をしている事に、もう少し付加価値を付けられないかという考えが湧いてきました。まぁ、端的に言うと「営業」ですね(笑)

私自身、職業はWeb系のエンジニアであり、本業の印刷に直接関連する仕事は殆どやっておりません。ただ、印刷に関する知識は少々ありますし(昔DTPエキスパートなんて持っていましたw)プリプレスの現場は経験しているので概ね解ります。本格的な見積もりなどは本社の営業がやってくれますので、要はお客さんの話を直に聞いて、ざっくり感触を掴み、それを本社に投げる、という役割です。
そもそも紙への印刷は自分自身の本業じゃないので、ある程度お客さん目線で見る事が出来ます。ですので、コスト的に厳しければ、昨今はネットを使った印刷通販がたくさんありますので、はっきりそちらをオススメする事もあります。これは客観的に見てもその方が良い場合もあるからです。結局価格競争だけをやっても消耗するだけですからね・・。


企業はプラットフォームだ
おかげさまで最近ようやく「あいつは印刷屋だ」という認識が広まりましたので(笑)お声掛け頂く事が少しずつ増えてまいりました。東京時代には殆どなかったことですが、札幌に来てから「付加価値」について考えるようになり、それなりに振る舞ってきた結果なのかなぁ、と思います。もちろん、本当の営業さんのようには立ち振る舞えませんが、常にPCのにらめっこして一日を過ごすよりはよっぽど健康的ですし、印刷会社所属のエンジニアだからこそ出来ることだと思います。まさに企業を自分のために利用して、でもそれが結果的に企業のためになる(なるといいですね(笑))、という事でしょうか。

ただ・・こういう事が出来るようになってきたのも、おそらくこの本に書いてあった事を知らず知らずのうちに実践していたからかなぁ・・という事に気がつきました。目次から拾ってみると・・
言われた事をやるだけで終わらない〜人と同じこと、今までと同じことをやっていたら、要らない人材になってしまう(25ページ)
これは自分の性格になものかもしれませんが・・言われたことは従いたくない的なww まぁ、冗談はさておき、弊社の場合はそもそも受託仕事が殆どないので、サービスを考える所から始まります。ですから、トップダウンで来るお題は「新サービスを作れ」であって「○×システムを作れ」ではありません。だから自然とそういう考えになって行ったのかなぁ・・と思います。良いのか悪いのかよく解りませんけどw
社内外のネットワークを作る〜社内外のリソースを上手く活用(104ページ)
昔は「印刷屋のdeveloper日記」というブログを書いておりました。このブログで技術的なことをちょこちょこ書いていたのがキッカケで、とある勉強会に誘われ常連になったのが「業界外」の人達と会うキッカケになりました。そもそもIT業界に居ないのにも関わらず、IT系のイベントや勉強会に参加して、たまに発表する度に「アウェイな感じ」をもっておりましたけど、それも最初のうちだけでしばらくすると慣れました。SI屋さん、インフラ屋さん、Web屋さん・・様々な「異業種」の人達の話を聞いて行くうちに、自分の立ち位置と取組んでいる仕事について考えざるを得ませんでした。また、とんでもなくレベルの高い会話もあれば、その程度なのか(失礼しました!)というものもあり・・要は外に出ないと解らないことがたくさんあるし、むしろ外に出て行くことで得られたものを社内にフィードバックしていく事でより自分のためになる、という事だと思います。
難易度の高い仕事を引き受ける〜リスクを取る(129ページ)
これこそ企業に属しているから出来る事だと思います。例えば新規システムを作る時、社内の開発体制を提案して自ら整えて使ってもらうとか、全く新しいフレームワークを導入するとか、クラウドにシステムを全部移行させちゃうとか・・。こういうことは当然大変な事ですし、基本的に「未知の世界」なので、失敗する可能性も大きいです。しかし、仮に失敗したとしても対外的にはそれは会社の失敗であり、せいぜい怒られて自分の評価が下がるだけです。そこを恐れるよりも、トライする事で自分の糧になる方がよっぽど大きいものになると思います。もちろん、そう言う事を受け入れてくれる風土をもつ組織じゃないと難しいですが・・。ちなみに私自身、あまり失敗したことがありません。これは自慢でも何でもなくて理由があります。難易度が高ければ高い程、失敗したときのリカバリープランも考えた上で用意周到に計画するからです。そういうオプションプランも会社のリソースを使えるので用意しやすいのではないでしょうか?
常に市場価値を意識する〜他社、別業界の人をライバルにする(160ページ)
非IT業界でITの仕事をする、というのは、ある意味常に緊張感を覚えながらやってきた様な気がします。若い頃は特にそうでした。自分のスキルは果たしてIT業界の人から見たらどう評価されるのか?という事を常に意識しながら仕事をしていました。ですから、ひたすら勉強しましたし、それを実戦で使ってノウハウを積み上げてきました。結果はどうなのか・・? 今ひとつ自分自身を客観的に評価出来ないのですが、少なくともエンジニアとして、今はサーバーだけでなく、自らを仮想化して東京から札幌にクラウド移住する所まで来ました(ここ笑う所です)。ただし、これらは技術を追い求めるだけではだめで、「以前はこうだったから」という所をぶち壊す所から始めないと物事が動きません。そこに説得力を持たせる戦略としては、ある程度社外からの「評価」を頂いて、それを会社に突きつけると言う手段があります。出る杭は打たれるのは宿命です。ですが、出過ぎた杭は、もはや打つ事すら出来ない、というのがこの世の常でありますww
表現力〜言えば良いというものではない(182ページ)
エンジニア同士の会話であれば、仕様書でやり取りするよりも、コードで会話した方が早いですよね(?)。ただ、それは世間一般には通じません。業界用語、専門用語はもってのほかで、文字すらダメです(笑)この辺は非IT業界にいるおかげで、ITの専門的なことを社内に説明する際にどうやってそこを伝えるべきか、かなり訓練された様な気がします。伝えるべき相手によって、絵を描いたり、例え話をしたり、キャッチフレーズを作ったり・・みなさんも、おじいちゃんおばあちゃんにインターネットの事を説明してみると、かなり訓練されると思いますw
この本全体を通して訴えている事、会社員であるならば、企業と言うプラットフォームをどんどん活用するべき、というのは、個人的にもとても同意出来ますし、今後はそうあるべきだと思います。働き方を考える上で、一つヒントを与えてくれる良い本だと思います。