ながあきがんばって!

関西の中年AWSエンジニアブログ

【リモートワーク Advent Calendar 2015】在宅勤務で得られるもの、失うもの

リモートワーク Advent Calendar 2015の21日目のブログです。

自宅からオフィスまで片道約1時間。
普通に通える距離なのですが、
頑なに在宅勤務を続けているという贅沢なAWSエンジニアです。
本日は、在宅勤務を約1年近く続けて気付いた「得られるもの、失うもの」について書きたいと思います。

続きを読む

2015/2/7 JAWS-UG KANSAI特別編に登壇してきた話し

2015-02-07 JAWS-UG KANSAI特別編 「AWSを使い倒せ。AWSのフルマネージドサービス活用によるネイティブクラウドシステムへの誘い」の初心者向けセッションで、DirectoryService/WorkSpaces/WorkDocs(旧Zocalo)の紹介をさせていただきました。 皆様、当日はお疲れ様でしたー。

経緯

僕が初めてJAWS-UGに参加したのは、春のJAWS-UG三都物語2013です。 当時、IT業界に所属してはいたものの、インフラもクラウドも扱わない職種でした。 三都物語で登壇されていたスーパーエンジニアたち。この人たち、どんだけ技術知ってんの!?しかも、ほとんどの方が自分より若いw 当時は神のように見えました。 そして当日ハンズオンで初めて触れたEC2。とんでもない時代になっている!と、衝撃を受けたのを今でも覚えています。

インフラもクラウドも自分とは縁のない異世界の話しだと思っていましたが、 2014年にAWS業界に転職し、三都物語で登壇されていたスーパーエンジニアもまさかの同僚にw そして、2015年のJAWS-UGの場に自分も登壇しているわけです。 不思議なものです。 いやー、先のことはわからん。

発表

さて、今回担当させていただくテーマは初心者向けDirectoryService/WorkSpaces/WorkDocs(旧Zocalo)。

準備するのは、思ってた以上に難しかったです。 社外勉強会で、技術系のテーマで話しするのは初めてであること。しかも30分って、自分にとっては長い。。 どの層をターゲットにするか、自分にしか表現できないこと、サーバーワークスにしか出せないことは何か。 そういうことを考えながらも、テーマになっている3つのサービスの仕様も学んで、検証しないといけない。 空き時間を作っては、ちょっとづつ仕上げていき、「これでいくか〜」というレベルまで仕上がったのは当日の昼。これ、30分枠の内容なのか怪しいな。。そうこうしてるうちに、迫る出発の時間。

「電車の移動時間が使えるじゃない。そう、WorkDocsならねw」

WorkDocsにUPした完成したての発表スライドを、iPhone上で眺め、発表時間の計測も行いながら会場へ向かいます。 いやー、WorkDocs重宝しましたw pptもキレイに見せてくれますねー。 それにしても、準備がこんなに直前になったケースは初めてです。 いつも思うけど、スライド作るのもっと早くならんかなー。 あと、時間調整しながらも自然に進行できる技術も。

当日のスライドはこちら。

最後に

イベント終了後の懇親会。器用に移動して渡り歩くタイプではないので、近所の方とじっくり話しをすることができました。 そこで印象に残っているのが、ハンズラボさんのエンジニアの方の一言。

「仕事が楽しい!」

数年前の自分であれば、単純に「うお~~~、面白い会社で羨ましい、、」と受け取っていたのではないかなと。 でも、今の自分は「きっと今の環境に至るまで、前向きに努力し、自分で道を拓いてきた結果なんだろうな。これは祝福すべき素晴らしいことだな〜。」と思いましたね。こう思える自分は、ちょっと大人になったのかもしれません。

2013年のAWSとの出会いからもうすぐ2年になります。自分の環境は変わりました。その間何か劇的な成長を遂げたのかというと、全くそうは思えなくて、進歩も小さく毎日わからんことだらけですが、コツコツと日々精進していきたいと思います。

DevLOVE甲子園2014西日本大会で発表してきましたー!

久々にBlog書きました。転職後、初Blogです。

2014年8月23日、DevLOVE甲子園2014 西日本大会 で、発表してきました。 f:id:nagaaki46:20140824233146j:plain

経緯

自分にとって大きな選択(初転職)をしたこの時期に、いまいちど自分を見つめ直しそれを誰かに伝えるとことは最優先事項なわけです。が、、当イベントが募集開始されたときは、既に選手(発表者)が決まっており、参加者(観客?)枠しかありませんでした。 今を逃すと後悔するのはわかっていたので、@yohhatuさんにお願いしなんとか選手としてねじ込んでいただきました。

発表

当日のスライドはこちら。

(諸事情により、当日発表スライドから公開したくないページはカットしてます。ご了承ください。)

この手の会に集まる方々は、自分の目指す道のために何度も転職したり、起業したりとガンガン攻めてる方ばかり。というのが自分の印象です。 なので、「ええ歳のおっさんが初めて転職しました〜」なんて話しは、殆どの方には響かないんだろうなと思ってました。 しかし、そんな雲の上の方たちの武勇伝だけでなく、身近でごく平凡な人が一歩踏み出した事例はとても大切だと感じています。 自分の小さな一歩を見て「あー、あの人がやってるんだったら、自分にも出来そう。」って、一人でもきっかけを掴んでもらえたらと。

僕の話しを聞きに来てくださった方、セッション終了後やTwitterでメッセージいただいた方、本当にありがとうございました。 めちゃくちゃ嬉しかったです。顔には出ないんですけどね。

同僚たち

なんと今回は、新しい職場の同僚2名どんまいこ(@mnakajima18)、こばさん(@koba_taka)も自ら参加です。 今までの職場では、この手のイベントは一人参加が当たり前(誘ってもまず来ない。かつて誘って来てくれたのは2人だけ)だったので、嬉しくないわけがないでしょう。

20分枠なのに10分で終了してしまい、後半はAWS設計Q&A会になってしまった、こばさんのセッションw に、笑いを殺しながら参加(ごめんよ、こばさん)。でも、セッション終了後、こばさんの元にAWSをどう勉強したら良いのか教えてほしいと相談に来られた参加者が。こばさんのセッションが、一人のエンジニアの背中を押してあげたと言えるかもしれません。これが大事なんですよ、きっと。

そして、懇親会。どんまいの元気良すぎるLT(自分はどんまいLTは初見)。

どんまいLT終了後の会場の「サーバー○ークス」コールに、目頭が熱くなりました。ちょっとだけ。

最後に

強引に@yohhatuさんに参加相談したこと。 この一歩によって、普通の土曜日が自分史に残る貴重な一日になりました。

スタッフ、選手、参加者の皆さん、お疲れ様でした。 平日は東京滞在なので土日しか会えないのに、 その貴重な休日を使わせてくれた家族にも感謝します。 選手として参加できて幸せ者でした。 今後も、普通のおっさんが頑張ってる姿を見せていければと思います。引き続き、宜しくお願い致します。

AWSプロダクトシリーズ|よくわかる Amazon Redshift in 大阪に参加して来ました

 

2月21日 AWSプロダクトシリーズ|よくわかるAmazon Redshift in 大阪(大阪府)に参加して来ました。

参加メモのまとめです。
大体がAmazon Redshift (ペタバイト級の データウェアハウス サービス) | アマゾン ウェブ サービス(AWS 日本語)に記載されている気がしますが。


**************************************************************************************
AWSのデータ分析基盤は、Collect,Store,Analyzeの3要素で考えることができる。

■Collect(収集基盤)について
AWSのImportExportは、国内では提供されていない。よって、AWSのCollectはDirectConnectとKinesisの2つ。
Kinesisは、リアルタイム処理が売り。例えば、機械のセンサーから受けたデータを格納するとか。

■Storeについて
・Storeは、S3,DynamoDB,Glacier。
・S3は、何でも格納することができる。堅牢性が売り。

■Analyze(分析基盤)について
・Analyzeは、EMR,Redshift,EC2。
・EMRのspot pricingは、通常の時間課金よりも安価に利用することができる。

■本題のRedshiftについて
・petabyteクラスのデータを扱うことができる。
・$1,000/TB/Year!
・コンセプトは高速、安い、シンプル。
・クライアントからJDBC/DBCで接続する。PostgreSQLのドライバがそのまま使える。
・DW1はHDD。DW2はSSD。格納できる容量も違う。
・DW1にはXL(エクストララージと読む)と8XLがある。DW2はLと8XL。
※容量とお値段は、こちら(http://aws.amazon.com/jp/redshift/pricing/ )
・バックエンドのComputeNode,S3/DynamoDBは暗号化して格納される。
VPCがサポートされている。
・Redshiftのクラスタは3分以内で立ち上がる。
・バックアップは、手動を選択することで任意のバックアップ期間指定も可能。
・他のリージョンへのDR対策も簡単。
クラスタの健全性がAWS側で担保されているので、ユーザはアプリに集中できる。
・RemoteLoading。例えばMongoDBとSSHでセッションを張って接続することができる。
・COPY from SSH。かつては一旦S3にデータを置いて、Redshiftにロードする必要があった。
・監査ログも残せる。システムレベルとデータベースレベルの2種類。クラスタへの操作が全てS3に記録される。
・操作イベントは、SNSを通して通知を行うことができる。
・活用事例。既存オンプレDWHで拡張できないケースにRedshiftを併用もしくは移行。コスト削減とスケールできる柔軟性を獲得。
・データロードのソリューション。S3に並列Upload、DirectConnect、ELTなど。

上海出張記

f:id:nagaaki46:20140218223533j:plain

二泊の上海出張から帰って来ました。備忘録として、大切だなとあらためて思ったことをつらつらと。

◾足を運ぶということ
今やメールやビデオ通話だけでも要件は済ませられる時代です。でも、自分の眼で確認すること、直接会話をすることでしか得られないものもあります。相手の納得感や情熱など。また、その場にいることで、更に踏み込んでいくことも出来るわけで。

◾世界を知るということ
現地ではiPhone5S率がやたら高かったです。チョット見せてもらったところ、見覚えのあるアプリはLINEくらいでした。でここから何を想像したかというと、当たり前なことですが、現地でのビジネスモデルは全然違うんだろうなあと。文化、趣向、通信網、各種規制など、全く土俵が異なるわけですし。

◾歩き続けるということ
自分のコンテキスト(広い意味での環境。文化や環境など)と異なる方達の活躍や苦労って、普段なかなかわからないし、意識すらしてないこともあります。今回、自分なりの信念や目標を持って日々働いている現地の人と接することが出来、あらためて考えさせられました。
自分の方向性が正しいかどうかは誰にもわからないし、あまり周りがとやかく言うことでもないです。大事なことは、自分が信じて決めた方向に日々一歩づつでも進んでるかどうかですね。僕の歩幅はまだまだ小さいし、もっと広げられるはず。もちろん、随時方向修正しながら。

『前川企画印刷』さんにブロガー名刺を申し込んでみた

ここ1、2年、よく社外勉強会に足を運ぶようになりました。
そこで出会った方々への自己紹介の際、
「XX株式会社のZZです。」
という自分の名刺に、どうも違和感を感じるようになりました。
会社の名刺の情報からは、自分がどんな人なのかが掴めないのです。
仕方なく、名刺の裏にTwitterアカウントを手書きで記載してお渡しすることが増えました。
現在の業務上の肩書ではなく、辿れる情報をお渡ししておきたいと思ったのがブロガー名刺作成の動機です。
作成は、よく事例を耳にする『前川企画印刷』さんにご依頼してみました〜。
 
※名刺完成後、感想をアップデート予定です! 

認定スクラムマスター研修って、おいしいの?

はじめに

2013年10月28・29日に、JimCoplienさんの認定スクラムマスター研修を受講しました。永瀬美穂さん(@miholovesqさん。SCRUM BOOT CAMP THE BOOKの著者です。)も講師として参加されました。永瀬さんとは、2012年のSCRUM BOOT CAMP関西以来の対面となります。永瀬さんは、「(教えるためではなく)自分も学ぶためにやって来た」とのこと。このような姿勢が自己成長に繋がるんでしょうね。
さて、本研修は簡単にいえばスクラムガイドに沿った講義となります。ただ、本研修でしか得られなかった気付きや刺激もたくさんありました。自分の中で咀嚼しきれていないことも多々ありますが、備忘録の意味も兼ねて掲載しておきます。
 
 

認定スクラムマスター研修まとめ

・講義中に質問や意見をすると、内容に関わらずキャンディー等のお菓子を(投げて)もらえる。それを、うまくキャッチしないといけないw   #積極的な発言を評価するということでしょう。
 
・ソフトウェア開発は、製造ではない。

・開発方法論を確立していくことで、どんどん開発スピードが落ちてきた。

・やることが明確であれば、個人が主体的に行動することで早く実現できる。

・小さいチームは、コミュニケーションパスが小さくなる。

・大きな組織は効率が悪い。大幅に変える必要がある。

・レシピは組織毎に異なる。

・小さくやって成功できなかったら、大きくやっても失敗する。

守破離。まず型を学ぶことから。

Skypeの開発は、初期は4人チームだったが、現在は1000人。果たして、250倍パワフルなチームになっているだろうか。

・バグの80%は、要件の悪さから。プロトタイプをつくりましょう。コミュニケーションをとりましょう。プロダクトオーナーが熱意を伝えましょう。

・開発チームは、スクラムにおける豚である。

・開発者とスクラムマスターは兼任しないことが多い。
 
スクラムでは、バグを見つけたら今実施しているタスクをやめ、すぐに直す。4時間かけても直らなければ、プロダクトオーナーに伝え、プロダクトオーナーが対応方針を決める。   #4時間というのは厳密に決っているわけではなく、チームで決めることなんだろうなと思います。
 
・いまどれくらいバグがあるか?という話題は、スクラムではあり得ない。
 
・チームに主体性を与えることで、成長を促す。
 
・カンバンは、チームワークを壊す。
 
・日本語と英語での、"かんばん"の意味の違い。かんばん=ScrumBoad、カンバン=Kanban    #あくまでも、一般的にはということで。
 
・2weekという期間は、予測するのに長けている。
 
スクラムチームが、プロセスを変えて、ストラクチャを変える。これがスクラムの価値。
 
・プロダクトバックログはWHAT、スプリントバックログはHOW。
 
スクラムマスターは、スプリント中のタスクを全てDoneに持っていくのが仕事ではない。品質を保つこと、人に命令せず促そうとすること。但し、何を言っても命令に聞こえてしまう(かもしれない)。態度で示すこと。
 
・良いスクラムマスターは、複数のチームをみることができる。素晴らしいスクラムマスターは、一つのチームしかみれない。
 
スクラムマスターは暇じゃない!改善すべき種は沢山ある!
 
スクラムマスターが暇ならば、確認してみよう。ベロシティは上がっていっていたか?品質は完璧だったか?改善マインドがなかっただけではないか?

・複雑さのレベル。Simple、Complicated、Complex、Chaotic。
 
・Scrum of scrumについて。チーム人数が増えていくと、最初にあったチームを分割。服っすうチームでひとつのプロダクトバックログを共有。
 
・チームに女性が入ることで、チームの考え方に多様性が出やすくなる(ことが多い)。 
 
オブジェクト指向のゴール:(クラス構造や継承関係がどうこうではなく、)頭にあるイメージを、コンピュータ上にそのまま再現すること。
 
・事前のQCD計画の正しさは、誰も判断できない。
 
・計画通り≒良いプロダクト。
 
スクラムでは、計画を微調整していく。
 
・見積もりは、各自考えていることが異なるのが健全な状態。
 
・見積もりは、10秒でも機能する。
 
・見積もりに時間を掛けると、開発の時間が圧縮されることになる。
 
・見積もりは、プロダクトオーナーとのコミュニケーション。
 
・緻密≒正確。
 
・PBIのテストシナリオは、プロダクトオーナーが作成する。
 
・PBIのテストシナリオ≒Done条件。
 
・ソフトウェア開発は、10代の子供と同じ。予測はできるが、コントロールはできない。状況に応じて、方向修正していくことが必要。
 
・従来型の開発を行ってきた組織にとって、スクラムパラダイムシフトである。全く新しい思考でチャレンジしなければならない。
 
スクラムマスターは、権限を持たない。見積もりにも参加しない。命令もしない。
 
スクラムチームは、problem vs usの構図。問題は、誰かひとりのものではない。
 
・見積もりは天気予報と同じだ。コミットなんかできない。
 
・メンバーの休暇は、プロダクトバックログに入れておけばいい。
 
スクラムマスターは、牧羊犬である。
 
スクラムマスター同士の秘密の挨拶。   #これは、Coplienから直接聞いて下さいw
 
スクラムマスターとはw    #コプリエンが見せてくれた動画
 

 

スクラムガイドは、今でも改訂され続けている。スクラムの生成物の定義に、"スプリントゴール"なるものが新たに追加されていた。

  
・懇親会に参加しないのは、勿体無い。これから認定スクラムマスター研修に参加される方、是非懇親会にも参加を。その場こそが本番かもしれない。
 
・二日目最終日のチーム対抗ベロシティゲームの結果。各チーム、同じプロダクトバックログを3スプリント実施。スプリント毎に改善することで、ベロシティが上がるという事象(ちんもチーム、KUSHIチーム)。また、スプリント毎にプロダクトバックログを見積もりし直すことで、結果としてベロシティが安定してくるという事象(Hossy4チーム、倍返しチームなど)を体験。 

f:id:nagaaki46:20131029180830j:plain

 

これから認定スクラムマスター研修を受講する方へ

認定スクラムマスター研修は、基本(型。守破離でいう守。)を学ぶ場であり、素振りがメインの場ではありません。素振りの場を提供してくれるScrumBootCampやDevLOVE(僕の場合は、DevLOVE関西)、京アジャ(京都アジャイル)などの各種勉強会は、とても貴重な存在であると今回再認識しました。私は、事前に各種勉強会に参加していたお陰で、本研修でゼロから学ぶのではなく今まで蓄積してきた知識の再確認をすることができました。濃密な研修にするために、少しでも多くの体験をしてから研修に臨むことをオススメします。

 

認定スクラムマスター研修は、おいしかったのか?

「研修に参加し終えると、今の組織の文化が嫌になって耐えられなくなる。改善意欲の高い、成熟した組織に移りたくなる。」
本研修に参加するまでは、このように想像していました。
 
しかし、研修を終えた今はこう思います。
成熟した組織には、スクラムマスターは求められていないのかもしれません。
未成熟な組織だからこそ、スクラムマスターが必要なのです。 
改善する=組織の文化を変えることともいえます。
決して容易なことではないでしょう。
組織に新しい文化が定着するまで、3-5年の覚悟は必要かもしれません。
 
でも、今は選択の余地はないのです。
自分は赤いピルを飲んだのだから。
 
 
認定スクラムマスター研修がおいしいかどうか、それはきっとあなた次第です。