Cloud Automator のAPI を呼び出すCLI をgolang で作ってみた #cloudautomator #golang #swx
知ってますか？
Cloud Automatorというサービスがあるんですが・・・知ってますか？
簡単に言うと 画面からのカンタン操作でAWSの運用を自動化 することが出来るサービスかなーと。画面から操作できるのは大変便利なのですが、大量の定型処理を行う場合にはやっぱりしんどいですよね・・・
しかし、最近Cloud AutomatorのAPIが公開されました。
Cloud Automator API
https://cloudautomator.com/api_docs/v1/api.html
APIはあるけど・・・
APIが公開されていれば、プログラムの中から使えるから画面からの操作じゃなくてもなんとかなる！と、現実はそんなに簡単ではないのでなかなか難しいところもありますよね。
じゃーターミナルでcurlを使って頑張ればいいじゃないか！と、思うじゃないですかー
・・・黒い画面大好きな国の人でもちょっと大変という感想がっ！
SDKとかCLI何かがあれば多少は違うのかなぁーと思いつつ、Cloud Automatorのサービススタンスとしては、CLIは難しいラインなのかなぁーとも思いつつ
そこで
仕事で考えるからややこしい話になるんだなぁーと気がついた ＆ 最近議事録や予定調整などしていて、コードも書いてなければAWSも触れてないと気がついたので、せっかくだから公開されているAPIドキュメントを見ながらCLIを作ってみることにしました。
CLIを作るにあたって、身近なCLIを参考にするのが良さそうなので以下の2つを色々見てみました。
自分が使うだけなので、手元のMacとAmazon Linuxで動けばいいのでPythonって選択肢もアリでしたが、やっぱりここは仕事では書く機会がありそうもない大好きな言語であるgolangで作ってみようかと。
golangにはcobraというちょー便利なパッケージがあるので、もちろんこれを利用して作っています。
他にも色々と便利なパッケージがあり、今回は
なんかを利用しています。
また、上記のようにgolangのパッケージをまとめているサイトがいくつかあるので、こういうサイトを利用して必要なパッケージを検索出来るのはありがたいです。
とりあえず
自分用ということで作っていて、とりあえず動くところまではできた感じです↓
golangのクロスコンパイルでMac/Linux/Windows用のバイナリファイルは作りましたが・・・MacとLinuxは動くのは確認しています。Windowsは動かなかったらゴメンなさいw
インストールとか操作については、README.md＆ヘルプコマンドの表示で何とかしていただければ・・・
分かりにくいところ
Create Job のAPIで受け取るパラメータのrule_valueとaction_valueが直感的ではないので、少々分かりにくいかもしれません。
Cloud Automator API
https://cloudautomator.com/api_docs/v1/api.html#ジョブ-post
上記のAPIドキュメントを確認すると、rule_valueとaction_valueについてはobject型の値を渡さないといけないようです。
object型はJSONになるのですが、CLIでJSONは結構大変なので今回は以下の例のように対応しています。
$ ./ca job create \ --name "ca job create exsample" \ --aws-account-id 1 \ --rule-type cron \ --rule-value hour=2,minutes=0,schedule_type=weekly,weekly_schedule=monday,friday \ --action-type create_image \ --action-value region=ap-northeast-1\ ,specify_image_instance=identifier\ ,instance_id=i-xxxxxxxxxxxxxxxxx\ ,generation=1\ ,image_name=exsample-ami\ ,description="Job Create Exsample Cloud Automator CLI"\ ,reboot_instance=true\ ,additional_tag_key=name\ ,additional_tag_value=exsample\ ,add_same_tag_to_snapshot=true\ ,trace_status=true\ ,recreate_image_if_ami_status_failed=true
–rule-value hour=2,minutes=0,schedule_type=weekly,weekly_schedule=monday,friday
“APIのパラメータ名=値” の形で指定して、パラメータ同士は",“で繋いで表現してください。また、配列を表現する場合は”APIのパラメータ名=値,値,値“のように値を”,“で繋いで表現してください。
作ってみて
- golang はやっぱり楽しいねーもっと使えるようになりたい
- 各種パッケージで色々できるのは楽でいい
- SORACOMさんのCLIはAPI定義からSDKなんかと一緒に自動生成みたい
- 手で組んでも作れるけど、同じようなコードになっていくから自動生成は幸せになれそうで素敵
Cloud AutomatorのAPIも確か API Blueprintを使っていたはずなのでワンチャンあるかも？
API Blueprint | API Blueprint
https://apiblueprint.org/
- object型をCLIで表現するのに困った
- AWS CLIの引数指定の仕方を参考にしてみたが、APIパラメータを知らないと使えない感じもするので悩ましい
- 自分用に作ったのでテストがなかったり、コメントだらけのソースだったりすのでなんとかしたい
- Circleci2.0を使ってみれたのはよかった。速くてすばらしい
- Codeshipも気になるので時間があるときに使ってみたい
- golangで作られたツールのリポジトリを見ると、AppVeyorを利用してWindows環境でテストとビルドをしているところも多いみたいなので気になる
- 使ってみたかったslideshipをやっと使えた
- Markdownでサクサク書けるのは便利
- 簡単に作れるので使っていきたい
- APIドキュメントが間違っている可能性？
Cloud Automator API
https://cloudautomator.com/api_docs/v1/api.html#ジョブ-patch
- API定義からAPIとドキュメントが生成されていない？
- ドキュメントだけ間違っている場合は、このドキュメントを元に作っているので間違った仕様になってしまう
- 上記の場合だとedit処理なのに、id意外も必須とされている・・・
まとめ
- 楽しいのはやっぱり大事だよね
- 手を動かして作っていかないと知らないことも多くなってる
- 自分用でもちゃんと最初からテスト書こう
- もうちょっと頑張ろうと思った
以上になります
Microsoft Azureオンライントレーニングをやってみた #microsoft #azure #mooc
AWSは好きで触る機会も多いのですがここのところ他のサービスやプロダクトはなかなか触る機会がありませんでした。
これではイカン！と思い今回は時間を作って Microsoft Azure を触ってみました。
なぜAzureか？
先日のGoogle Cloud Nextに参加して、時間があるときに触るならGCPだなーと思っていたんですが・・・
みんな大好きガートナーのマジッククアドラント2017年版のIaaSでAWSに続き2位がAzureだと。
加えて、AWS技術者のためと記載があるオンライントレーニングがあるとのことだったので触ってみる事にしました。
オンライントレーニング
Microsoft Azure を触ってみるとは言っても、何か急いでやることがあるわけではないので今回はマイクロソフト社が用意している無料のオンライントレーニングを利用してみました。
Azure Training Courses | Microsoft Learning
https://www.microsoft.com/ja-jp/learning/azure-skills-training.aspx
たくさんあるオンライントレーニングの中から、
AWS の専門家のための Microsoft Azure というわかりやすい名前のものにチャレンジしてみました。AWSはSAアソシエイトしか持ってないので全然専門家ではないのですが・・・
AWS の専門家のための Microsoft Azure | Microsoft Learning
https://openedx.microsoft.com/courses/course-v1:Microsoft+AZURE213x_JPN+2017_T2/about
当然この他にも無料で受講できる多数のオンライントレーニングがあり、今回利用したオンライントレーニングと同様に日本語化されているものも多いので、ご興味ある方は一度見てみることをおすすめします！
次はオンライントレーニングを受講するために必要なアカウントを取得していきたいと思います。
microsoft learning accountの取得
AWS の専門家のための Microsoft Azure | Microsoft Learning
https://openedx.microsoft.com/courses/course-v1:Microsoft+AZURE213x_JPN+2017_T2/about
上記オンライントレーニングサイトで利用するアカウントになります。登録はもちろん無料で入力項目も多くないのですぐに登録できると思います。
登録が完了したら今回受講するコースのAWS の専門家のための Microsoft Azureを選択して受講ができるようにします。
このトレーニングサイトはOSSで提供されているOpen edXというプラットフォームを利用してAzure上で動かしているようですねー
無料のAzureアカウントの取得
上記のサイトから登録すると
- ¥20,500の無料クレジット付与
- 30日間の完全無料期間
- 無料期間中の支払いはなし
の状態でAzureを使い始めることができるようです。 クレジットの付与とか期間限定での全サービス無料はすごく良いですねー
30日間の期間が終了しても無料枠が設定されているサービスは複数あるので、継続利用ができるのは助かりますね。
登録するにはクレジットカードが必要になります。これはサイト上にも記載がありますが課金のためではなく、ID認証に使用されるようです。
また、登録確認のコードがSMSで送られてくるためSMSを利用できる電話番号が必要となります。
もしMicrosoftアカウントを持っていない場合には、まずMicrosoftアカウントの取得が必要となります。
ホーム - Microsoft アカウント
https://www.microsoft.com/ja-jp/msaccount/default.aspx
登録が終了してAzureポータルにログインすると、クレジットが付与されていることを確認することができます。
以上でアカウント関係の準備が終わったので、次はいよいよ本題であるオンライントレーニングを進めていきたいと思います。
オンライントレーニング 実践編
オンライントレーニングサイトにログインして、今回受講するAWS の専門家のための Microsoft Azureを選択します。
あとはCourseタブを選択して、ドキュメントを順番に読み進めていくことでトレーニングを進めることができます。 ドキュメントはモジュールと言われる単位で章に分けられていて、各モジュールごとに1つのテーマを学習できるようになっています。
取得したAzureアカウントを利用するような部分はラボと呼ばれていて、基本的にはドキュメントに沿って自習していく形になります。
また、説明の動画が用意されていることがあり、動画自体は英語ですが動画横に字幕として日本が表示されているので、個人的に英語に弱いのでとても助かりました。
オンライントレーニングの最後には最終評価として、これまでのトレーニングで得た知識をチェックする選択式の質問があります。
すべての質問に回答すると、最後にスコアが表示されます。 オンライントレーニングの終わりに任意回答のアンケートがあり、それですべてのオンライントレーニングが終了となります。
オンライントレーニングの詳細な内容については、受講して体験してもらうのが良いと思うので、ぜひチャレンジしてみてください。
まとめ
個人的によかったところと、もうちょっとカイゼンしてもらえたら嬉しいなーと思ったところを記載してみました。
よかったところ
- ドキュメントが細かいところまで詳しく書いてある
- 関連するドキュメントなどにリンクされている
- モジュール単位で分割されているので、知りたい情報や学習したい部分がわかりやすい
- 最後に理解度を試せるのは良い
- Azure Active DirectoryやAzure Resource Managerなど、知らないことも多く勉強になった
- Azure Resource Managerが便利で素敵
- AWSとAzureの比較があることで理解しやすい部分もあった
もうちょっとカイゼン希望
- アカウント取得がちょっと面倒くさい
- オンライントレーニングならSandbox的なところで出来ると嬉しい
- 日本語化がおかしなところがある
- Azureのアイコンとサービス名を覚えるまで大変
- 最終評価で間違った問題だけを見られるとか工夫が欲しい
- もっと言うと間違った問題の正解がわからない
- 間違った問題の正解を表示するか、モジュールのどの部分を学習しなおしするのかリンクなりで案内してほしい
- 復習を行うときに便利だと思う
- CLIの実行がWindows OS前提っぽい？のはちょっと残念
- Linux仮想マシンへの接続は、Windowsより若干面倒に感じる
- Windowsと同じぐらい簡単に出来ると嬉しい
とにかくドキュメント量が多く質も素晴らしいので、丁寧に読んだりリンクされている先まで読んだりしているとなかなかの時間がかかります。
このコースを最大限に活用するため、各モジュールの学習に平均 3 ～ 4 時間をかけることをお勧めします。
と、最初に書かれていたので平均合計時間は 3 ～ 4 時間×6モジュールで18～24時間かかる想定のようです。
で、実際にはどのぐらい時間がかかったのか？という所ですが・・・今回は細かく計測してないので正確ではないのですが、だいたい20時間前後ではないかと思います。
最初の方は細かくドキュメントを追っていたので思ったより時間がかかった印象で、慣れてきた中盤は引っかかる部分だけ読み込む形になり、Azure Active DirectoryやAzure Resource Managerなどの全然知らなかった項目で、また時間を使った感じになりました。
進め方は人それぞれかと思いますが、AWSの考え方と似ている部分があったり、以下のようにAWSとの比較をしてくれている資料が出てくる部分があったりとしますが、比較で覚えるのではなくAzureが持っている特徴を理解していくのがいいのかなぁーと感じました。
自分のペースで進めていけるので、トータル時間はそこそこ必要ですが無目的にAzureを触るよりは断然お勧めできます。私個人としてはAzure Active DirectoryやAzure Resource Managerのモジュールは大変勉強になりました。
もしAzureアカウントを取得するのが面倒であれば、一旦オンライントレーニングのアカウントだけでも良いので取得して、まとめられた豊富なドキュメントを読んでみるのがいいのではないかと思いますので、ぜひお試しください！
以上になります。
社内のLT大会で「期待値コントロール」について話してみた #swx #lt
今所属しているサーバーワークスでは毎週金曜日にLT大会を開催しています。
発信力強化と発表に慣れるために基本的には全員が発表対象になっています。
今回はLT Advanced Generation ! と称して3チームに分割されて対抗戦として発表することになっています。
これまでの社内LTに関しては以下を見ていただければ、雰囲気をわかってもらえるかと思います。
決まりごと
- テーマは
仕事のはなし - 持ち時間は5分
- 発表後に投票により順位付けされる
- 全員が最低1度は発表する
チーム対抗戦で発表に投票で順位付けされるのがあるので、好きに発表できるわけじゃないのが難しいところ・・・
過去の発表資料や動画を確認すると自由な人もちらほらいらっしゃいますがw
今回は
今回は技術ネタが間に合わなかったので、個人的にはあまり話す機会のない少しエモい話しをしてみました。
発表中は
さて、今回の発表中は エモい という言葉を聞いたことがない/使ったことがないという方が数名いて、ちゃんと説明しなかったために伝わらなかった部分があったので、次の機会にはもうちょっと丁寧にいろいろ伝えないとダメだなぁーと
まとめ
- 慣れないテーマで話すときはいつも以上に資料も話も丁寧に
- 意識していろいろやることは重要
- LTのネタ集めは計画的に
宣伝
LTを含めてサーバーワークスのことが気になったら、お気軽にお問い合わせください。オフィス見学もできますので是非お越しください！
以上になります。
LambdaのLogをCloudWatch LogsからKinesis Firehoseを利用しAthena＋QuickSightで可視化する際に知っておくべきこと #aws #jawsug
タイトルでは
知っておくべきこと と書きましたが、簡潔に結論を書くと 仕様のドキュメントをちゃんと読めば問題なし となります。ドキュメント読むの大事ですね。
そして普段からちゃんと読んでる人はハマらないので、なんの気づきもない可能性があります。
実現したいこと
みんな大好きLambdaですが、Lambda関数の数が多くなり出力されるLogの量が多くなってくると、CloudWatch Logsのマネジメントコンソール上での検索が大変になってきました。
CloudWatch Logsのマネジメントコンソール上では、ログストリーム間のイベントを横断検索することはできますが、ロググループ間の横断検索や検索結果の直感的な可視化などを行うことができません。
これを構築と運用の手間をなるべくかけずに実現して、Lambda関数から出力されたLogを普通に検索して可視化したいわけです。
Lambda関数をまたいでLogを検索する必要がない！という場合は必要ない仕組みになります。
実現方法
実現するにために以下のサービスを連携して利用することを考えました
具体的にはAWS Lambdaから出力されたLogがAmazon CloudWatch Logsに蓄積されるので、Amazon CloudWatch Logsのサブスクリプションを利用してAmazon Kinesis Firehoseにリアルタイムで出力しAmazon S3に蓄積する。
Amazon S3に蓄積されたLogをAmazon Athenaでクエリを投げられるようにしてAmazon QuickSightにて可視化を行う。
他の実現方法
上記の方法以外で以下のサービスを使えばもっと手軽に実現できます
- Amazon Elasticsearch Service
Amazon CloudWatch Logsのサブスクリプションを利用してAmazon Elasticsearch Serviceにリアルタイムで出力し、Kibanaにて可視化を行う。
ただしAmazon Elasticsearch Serviceはストレージの容量が無制限ではなく、必要があれば設定や操作をしてストレージを管理しなければならないため今回はこの方法を選択しませんでした。
用途が合えば非常に手軽なのでこちらを選択するのもアリかと思います。
Amazon CloudWatch Logs
Data sent from CloudWatch Logs to Amazon Kinesis Firehose is already compressed with gzip level 6 compression, so you do not need to use compression within your Firehose delivery stream.
Amazon Kinesis Firehoseとの連携の場合はすでにgzipで圧縮された状態で送信されるとは知りませんでした・・・ ドキュメントをしっかり読んで理解していれば、今回悩むことはなかったかもしれません
ここまでがAmazon CloudWatch Logsについて知っておくべきことになります
Amazon Kinesis Firehose
- Amazon Kinesis FirehoseでAmazon S3に転送されたデータには改行がなく1行
- Amazon Kinesis Firehose Data Transformationを利用して改行を追加する
Amazon Kinesis Firehose Data Transformationを利用しなければ改行が追加できないのちょっと残念な感じがします・・・
AWS IoT ルールアクションでFirehose アクションを利用する場合にはseparatorの指定が可能で、これによって改行をした状態でデータが蓄積されます。この機能を通常のAmazon Kinesis Firehoseで利用出来たらいいなぁ
ここまでがAmazon Kinesis Firehoseについて知っておくべきことになります
Amazon Athena
- Amazon Athenaで利用するには1行1レコードの形式にする必要がある
- Amazon AthenaでGZIP圧縮されたファイルを読み込むには、ファイルの拡張子を
*.gzにする必要がある - 実際にGZIP圧縮されたファイルでも拡張子が正しくないと読み込めない
- このためAmazon Kinesis Firehoseの設定で
"CompressionFormat" : "UNCOMPRESSED"として出力されたファイルは拡張子が無いため正しく読み込めない - Amazon Athenaで利用するためには、Amazon Kinesis Firehose Data TransformationにてAmazon CloudWatch Logsから連携されたデータのGZIP解凍を行い、Amazon Kinesis Firehoseの設定で
"CompressionFormat" : "GZIP"とし拡張子の*.gzが付与される形でAmazon S3に出力する必要がある
Amazon Athena のパフォーマンスチューニング Tips トップ 10 | Amazon Web Services ブログ
https://aws.amazon.com/jp/blogs/news/top-10-performance-tuning-tips-for-amazon-athena/
ファイルの拡張子が*.gzでないとGZIPファイルを読み込んでくれないのはやっぱりちょっと残念な気が・・・S3オブジェクトのメタデータでContent-Typeを見て処理してくれるとかあるとステキなんだけどなぁ
ここまでがAmazon Athenaについて知っておくべきことになります
Amazon QuickSight
- Amazon QuickSightのSign upを行えるのはIAMアカウント or Rootアカウント
- Roleベースログイン、フェデレーションユーザーには未対応
今回利用していたアカウントがフェデレーションユーザーだったため、処理状態が変化せずに困りました・・・
フェデレーションユーザーでログインしていることは、システム側がわかっているはずなのでフェデレーションユーザーではNGというエラーメッセージが出てくれれば良いのになぁ
ここまでがAmazon QuickSightについて知っておくべきことになります
Amazon S3
- AWS CLIの
aws s3 cpコマンドでのファイル取得とマネジメントコンソール上からのダウンロードでのファイル取得では差異が出ることがある - ブラウザーの機能で
*.gzファイルを自動で解凍してしまう事がある
利用していのはGoogle Chromeでしたが、このように自動解凍しているとは認識していませんでした・・・ 結果的にS3上のファイルとローカルにダウンロードしたファイルで状態に差異が出ることになり、大いに悩む原因の１つになりました
cp — AWS CLI 1.11.74 Command Reference
http://docs.aws.amazon.com/cli/latest/reference/s3/cp.html
ここまでがAmazon S3について知っておくべきことになります
手順
- AWS Lambda関数から必要な情報をログに出力する
- Amazon CloudWatch Logsにログが出力されているロググループを確認する
- そのロググループに対してサブスクリプションとしてAmazon Kinesis Firehoseを指定する
- Amazon Kinesis Firehoseはマネジメントコンソール上では指定できないため、上記のようにAWS CLIを利用して設定した
- Amazon Kinesis FirehoseのDelivery Streamは別途作成する必要がある
- 前述したようにCompressionの設定はGZIPとして、拡張子の*.gzが付与されるようにする
- Data transformationをEnabledとしてLambda関数を指定する
- このLambda関数も別途作成する必要がある
- blueprintのkinesis-firehose-process-record-pythonを利用すれば簡単に作れる
- Amazon S3の指定バケットにAmazon Kinesis Firehoseからファイルが出力されていることを確認する
- ファイルの拡張子は*.gzで、内容はAWS CLIのaws s3 cpコマンドを利用してローカルに取得して１行に１レーコドとなっているかを確認する
- Amazon AthenaにてAmazon S3の該当バケットをTableのData setに指定して新しいテーブルを作る
- 作成したテーブルに投げたいクエリを作成する
- Amazon QuickSightにSign upしてない場合はSign upする
- この際ログインしているアカウント種別によっては処理が先に進まなくなるので気をつける
- Amazon QuickSightにてデータソースにAmazon Athenaを選択し、作成したクエリーを選択すればデータが読み込まれ可視化される
これでAWS Lambdaのログを一元化して可視化することが出来るようになりました。料金には注意が必要ですが、性能や容量に関しては大きな心配はないのではないかなーと。
Amazon QuickSightはAmazon QuickSightだけ閲覧可能なユーザーなんかも作成可能なようなので、より柔軟にデータを見てもらうことができようになるのかなーと
また、各サービスがそれぞれ独立していても利用可能なので例えばAmazon QuickSightの調子が良くない場合でもAmazon Athena利用して確認するといったことも可能となるため、汎用性も高まる気がします。
まとめ
AWS Lambda→Amazon CloudWatch Logs→Amazon Kinesis Firehose→Amazon S3→Amazon Athena→Amazon QuickSightと長い連携でしたが、当初の目的通りに可視化することができました。
最初からしっかりとドキュメントを読んでいれば、余計な手間や迷惑をかけずに実現できていたと思うので、今後は詰まったら基本のドキュメントをしっかり読み込むようにしたいと思います。
一方で今回詰まった部分は、AWS側の標準機能として存在するば迷うこともないのになぁーと思うところもあります。 特に、Amazon Kinesis Firehoseの改行付与と拡張子付与に関しては標準であっても良いかと思いました。
また、Amazon QuickSightのSign upのように、そもそもログインしているアカウント種別でNGの場合はエラーメッセージにその旨出て欲しいです・・・さすがに設定中の状態が延々と続くのはちょっと・・・
ヘルプドキュメントのリンクと共にエラーメッセージに出ていれば自分で原因に気がつけます。
AWSは進化も変化も速いのでこう言った細かいところの改良が進んでいくのを楽しみにしています！
AWSサポート
今回も大変お世話になったAWSサポート。利用する立場が違うと評価も違うのかもしれませんが、エンドユーザーとして利用することが多いので毎回非常に助かっています！いつもありがとうございます。
以上になります。
東京のチベットで開催されたビルディットさんのイベントに参加してきた #ビルディット #八王子8Beat
東京のチベットと呼ばれるw 八王子にある コワーキングスペース八王子8beat で開催された 株式会社ビルディット さんのイベントにお邪魔してきました。
とは言え
すでに主催のビルディットの中の人が書いているので、そちらを見てもらうと詳細と雰囲気がよく分かるかと！
と、これだけだともう終わっちゃうので・・・簡単にですが私もメモ程度のまとめを
参加してみて
写真を撮っていいのか確認し忘れたため、特に画像もなく箇条書きのメモになりますが・・・
- 今回の主催であるビルディットの富田さん
- ビルディットさんの会社設立の思いは熱くて素敵です！
自社プロダクトと案件開発の2輪- 2輪による相互循環と相互成長はちょーアリだと感じる
- 自分の少ない経験でも前職はずっと2輪だったし、現職も2輪にしようとしてる
- エンジニア/デベロッパーとしても楽しそう
- 思いを形にして継続しながら成長している姿はすごい
- ネクステージのCTO 西原さん
- ネクステージさんは
観劇三昧というアプリで演劇の配信を行っている 演劇パスという演劇チケットアプリもある- グッズ販売を行っている実店舗も2店舗ある
- 私は演劇に縁のない生活なので全然存じ上げず・・・
- 西原さんが1人でサービスを立ち上げた時期から、その後のカイゼンの道のりのお話
- 良いループが回り始めている
- 今後もまだまだカイゼンは進めていく
- 後で少しお話をさせていただきましたが、演劇のコンテンツ提供側と一緒に演劇を盛り上げていこうという仕組みと思いは素敵です！
take-space | Let’s make idea to real!
http://www.take-space.com/
- FabLab浜松を運営している竹村さん
- そもそもFabLabとは何なのか？
- デジタル工作機器を使えるスペース
- この理念とフォーマットで作られたFabLabが全世界にある
オープンソースハードという形でハードもオープンソース化- そうしたものをFabLabにある機器を使って作る
- 最近はBioでも同じ流れがきている
- なのでBioLabも始めている
- 中国の深センへ視察に行ってきたレポート
- IoTなどで需要が高まってるハードのプロトタイピングができるのは凄い
- 個人的にはソフトウェア開発者だと、やはりハードはハードルが高いと感じる
- なのでこう言った取り組みで身近になるのは嬉しい
- ハードのクックパッドみたいな場所があって、作れる人は作るしダメなの人は作れる人に依頼できるようなものがあれば、私個人は嬉しいなぁー
- ロカラボの代表 荒井さん
- オフショア開発についての勘所
- オフショア開発はいいイメージがない？
- 依頼する側が気をつければ防げることも多い
- 一番大きいのは依頼を受ける側が日本の商習慣に明るいかどうか
- 日本語ができる＝日本の商習慣に明るいではないので注意
- 現地には優秀な人がたくさんいる
- なので勘所をちゃんと知って依頼すればとても頼りになる
- 自分たちで難しい場合はノウハウのあるロカラボさんにお願いするのが良いのではないかと思いました
- 今後様々な働き方や考え方が出てくるなかで、こうした海外の優秀な方々とも仕事をする機会が増えるのかなぁーと
- そうなると、私のようなおじさん・・・おじいちゃんはもっともっと気を引き締めていかないとなぁ
- 高専キャリア教育研究家として話すという菅野さん
- 企業にも所属しているが今日は高専キャリア教育研究家
- 最近雑誌に載ったりインタビューを受けたりで後日会社で怒られるw
- 高専出身のすごい人たちがたくさんいる
- 現在の高専生も当然素晴らしい人たちがたくさんいる
- この人たちにどんなキャリアを提供できるのか？を考えている
- 今までやってきた取り組みで人と人を繋げてきた
- 今後も輪を広げる活動を続けていく
- 若者と企業、教育機関と企業を繋げる仕掛けとか面白そうだし素晴らしいと思いました
まとめ
ビルディットさんの事業報告会ということでしたが、ビルディットさんのお話を始めいろいろと新しい話が聞けたのは非常に勉強になりました。いやー知らないことを知れるのはやっぱり楽しいです。
主催のビルディットさん、ありがとうございました！ 新しいオフィスにも遊びに行きます！！
そんなビルディットさんは人を募集しているそうなので興味がある方は是非！
またbuilderscon tokyo 2017にスポンサーとして参加されるそうですよ。これは楽しみです。
以上。
「駅すぱあと」で有名なヴァル研究所に会社見学に行ってきた #駅すぱあと #ヴァル研究所 #swx
会社のBlogにも書きましたが、駅すぱあとの会社に見学に行ってきました。
な… 何を言っているのか わからねーと思うが ・・・中の人の懐の深さで今回の見学が成り立ったのは間違いないかとw
きっかけは
ヴァルの中の人達が テレワーク を試験的に導入しているという話をしていたので、サーバーワークスのオフィスに遊びに来たらいいよ！
とお誘いして実際に↓のように遊びに来てもらいました。
その際に今度はこっちからオフィスを見学しに行っても良いか聞いてみると・・・快くOKをいただきました。いやーもう２度と来るんじゃないとかでなくて良かったっすw
せっかくなので
見学に行くのに私1人で行っても意味がないので、せっかくだから社内のSlackでゆるーく募集をしてみました。
嬉しいことに10人近く手が上がり、ヴァルの予定を確認しつつ多くの人が参加できるように日程を調整しました。しかも、手を上げてくれたのは駅すぱあとに興味があるという人たちが大半というね。素敵。
サーバーワークスのビジョンは クラウドで、世界を、もっと、はたらきやすく なので、クラウドを利用している人たちが「はたらきやすく」なるのはビジョンとズレていないと個人的には思うのです
実際に
見学に行った部分は会社のBlogを見てもらうとして、まだ１年経ってないですが久しぶりに社内を見た簡単な感想を
- 久しぶりというよりお邪魔しますという感想
- 物が多く感じる
- デスクトップPCが沢山
- アナログのカンバンは見ようとしないでも目に入るのは便利
- バリューストリームマップが沢山
- 相変わらずズレてる気がするところはそのまま
- なんでも楽しんでるところは変化？進化してる印象
- 一緒に行った人たちが意外なところで驚いたり興味を持っていた
- 純粋に外からみたらそんな感じなんだなぁーと思った
- さすがに沢山の会社さんの見学を受け入れてるだけあって、各部署の皆さんも説明に慣れててすごい
- 部署ごとの工夫は一種の新しい文化の始まりなのかもしれない
- 今後リモートワークを始めとした要求の変化で、現状がどう進化するのか気に成る
などなど。実際に色々と変化がありどんどん変わっていってるんだなぁーと実感しました。また、外ではなかなかお会いすることができない人たちもみなさん元気そうで、気軽に声かけてもらえて良かったです。ありがとうございました！
見学後に
見学後日にヴァルの中の人と、サーバーワークスの中の人にそれぞれゆるーく「見学どうだった？」と聞いてみたところ・・・両方ともから好印象が！！
サーバーワークスからは
- 全部アナログで管理していたけど、アナログの良さもあって驚いた
- 1Fに置いてあったゲームみたいな物も作っていたとは知らなかった
- もっと駅すぱあとのことを聞いてみたい
- 開発だけでなく他の部署もカンバンを使ってカイゼンに取り組んでるのがすごい
- 営業の部署が見れなかったのが残念
- バリューストリームマップが便利そうだけど作るのが大変そう
- そこかしこに鉄道を感じられるものがあるのは良い
- 達成感やメンバーの状態も可視化しているのが素敵
- サーバーワークスしか会社を知らないので、こういう別の会社を見れて良かった
ヴァルの中の人からは
- 普段の見学と客層が違った
- おかげで違う視点で見学する人がいることがわかった
- 質問や疑問点も今までと違う感じになる気づきがあった
- 宣伝のつもりで入れた「RODEM」や「駅すぱモール」への興味があって良かった
- 「RODEM」は近いうちに説明に行きますw
- 「駅すぱモール」は是非鉄道車両体験乗車を購入してくださいw
- 手法や運用ってことよりも、内容を気にしている
- これがきっかけで違う客層の人にも楽しんでもらえるようにカイゼンしていきたい
お互いに得るものがあったのは良かったなぁーと。 しかもこの見学後にヴァルの中の人から偶然だけどジャスト100社目だよ！と まじかw 真面目に偶然で特にピタリ賞とかはなかったけど何か得した気分でしたw
そして懇親会に
見学当日の終了後にはヴァルの中の人が懇親会的なことまで準備してくれました。あざまっす。 これは私のミスなのですが一緒に行ったメンバーが忙しいこともあり、任意で軽く飲みに行きましょうーとしていたところ、まさかのヴァルの中の人＋私だけという状況にw
しかし、そこに気遣いの女神が降臨！ どんまいこ（@mnakajima18）パイセンが急遽参加してくれました。マジあざまっす。素敵！! ・・・というかこういうところが愛されるわけですねーなるほど勉強になります。
懇親会ではあの部署今どうですか？とか、サーバーワークスってどうよ？とか、まー相変わらずぐだぐだなお話をしましたw
しかし、せっかく両方ともに見学もしたし、勝手知ったる元中の人なのでこのまま終わりではなくて、お互い成果を残して終わっておきたいとの共通意識をこの呑んでる場でしたはずwなので、今後も成果を出すためいろいろとよろしくお願いします！
手始めに、今回の見学に行けなかった社内の人たちから2回目はないのか？？ と嬉しい問い合わせも貰っているので、近いうちにまた遊びに行きます！ よろしくお願いします。
まとめ
相変わらずゆるーくお願いして、ゆーるく進めた割にはいろいろと気づきになる部分が多く良い機会になったと思います。
他の会社さんでも「見学受付てるよ！」という場合はお声掛けもしくは、教えていただけると大変嬉しいです。
また、「サーバーワークスの社内見に来たい！」というのもお気軽にどうぞ！ 事前に声がけいただき私でよければ、いつでもご案内します！
ヴァルの皆様、今回は本当にありがとうございました！
今回グッときた１枚
とある部署で見た テレワーク心得 なる箇条書きの紙。内容は大したことないが テレワークの日は会社に来ないで１日テレワークすること と言ったような趣旨のことが書かれている１文がありグッときましたw
何で テレワーク なんですかね？ってところは一体どこに・・・・ヴァルの中の人カイゼンの継続楽しみにしています！
以上。
社内のLT大会で話してみた #swx #lt
今所属しているサーバーワークスでは毎週金曜日にLT大会を開催しています。
LT Next Generation ! と称して、今回は社内の全員が発表する事になっています。
決まりごと
- テーマは
仕事のはなし - 持ち時間は5分
- 発表後に投票により順位付けされる
- 全員が最低1度は発表する
だいたい上記のような項目が主だったところです。
困るのはこの 仕事のはなし という縛り・・・
入って1年未満でやってる事はそんなに無いという現実ががが。
しかし、過去の発表資料とか見ると 仕事のはなし is 何？ って気もしますがw
今回は
会社のBlogでも紹介してもらってますが、今回はネタが思いつかない＆前の週にやろうと思ってたネタが出るというね・・・
発表中は
さて、発表中の社内slackを見てみると・・・
総合すると
うちやまさん- 採用基準が
芸人!? - まったく同じ番組を見ている人を発見w
- 大石さんのプレゼンに感化されてる説
と、まぁーいろいろ書かれてましたw 5分しかないLTですし、伝えたい事が伝わればそれで良しだと個人的には思うのでネタでもなんでもOKかと。
まとめ
- 普段からネタになることを用意しないと大変
- レギュレーションは・・・という気もするが細かいことは気にしないw
- 急遽のネタだったが社内にも番組知ってる人がいてよかった
- おすすめの番組があったら教えてください
以上になります。
