「問題解決勉強会」という社内勉強会をしました。
以前、社内のSlackでこの記事が話題になりました。
この記事では掘り下げていませんが、 「問題を切り分ける力」を掘り下げていくと、以下の様になると思います。
- 問題の原因の仮説を立てる
- 仮説を検証する実験計画を立てる
- 得られた結果から問題を切り分ける
この「1. 問題の原因の仮説を立てる」というのは、
経験と知識が求められて、新人エンジニアには難しいところだと思います。
じゃぁそのへんの知識共有する会をしましょう！
ってことで、レク形式の社内勉強会を開催しました。
題して、「問題解決勉強会」
その第一回を5/24に実施しました。
概要
WEB開発チーム、インフラチーム、アプリチームで混合チームを作成し、
出題される障害に対してチームごとにどれだけ可能性を挙げられるかを競い合う大会。
実地方法
- オープニング
- 乾杯
- 出題
- シンキングタイム(15分)
- 回答発表&議論(1チーム5分)
- 優勝チームの発表
目的
弊社ではWEB開発チーム、インフラチーム、アプリチームとチームが分かれています。
それぞれ別の観点からお題の障害の原因となる事象を挙げていくことで、 自分が思いつかなかった観点の可能性を学ぶことができます。
また、同じ案件以外だと絡みが生まれにくいチームを横断するコミュニケーションが発生することで、 困った時に頼れる人脈も作れると良いなと思っています。
ルール
基本ルール
お題の障害が発生しうる原因となる仮説をチームごとに出し、
どのチームが一番多くの仮説を出せるかを競い合います。
今回はGoogle Slideを用いて、1チーム1ページのスライドを作成して、 作成後に仮説をプレゼンするような形式で発表しました。
お題について
今回のお題で出したのは
- サーバ構成
- いつデプロイしたか
- いつ障害が報告されたか
- どういう処理が行われるシステムか
みたいな感じでした。
この辺は割とフレキシブルに変更していいと思います。
解答発表と議論
解答発表時にチーム内で思いついた仮説を発表します。
他のチームはその仮説に質問・指摘ができます。
もしその指摘で無効と判定されたらその仮説は無効になります。
質疑応答が終わった時点で一番残ったチームの勝ちになります。
仮説の議論について
よくあったのが、言い方が違うけど同じ仮説という指摘でした。
例えば、
「DBの負荷上昇による障害」と「バッチ処理により負荷が上昇した」 という２つの仮説があった場合、 「バッチサーバが死んでもWEBサーバが生きていれば表示はされるのでは？」 みたいな質問が来ます。 ここで、「バッチ処理によりDBの負荷が上昇した」と答えた場合 重複する仮説としてどちらかが消えることになります。
こんな感じのやり取りを続け、仮説に対して議論していきます。
あとは、課題で判明している内容と矛盾していないかを議論していきます。
弁が立つ人が応答すると結構生き残る事が多かったりします。
実際にやってみた感想
個人的に面白かった仮説
障害自体が誤認説
「ユーザーからの連絡で発覚した」という書き方だったので、 そもそも障害が発生しているかどうかは未確定な状態でした。
なので、そもそも障害自体発生していないのではないかという方向で仮説を立てていて面白かったです。
攻撃説
AWSのadmin権限を乗っ取られた場合の攻撃の話やDNSハイジャックの話などがインフラチームの人から上がり、 開発チームが思いつきにくいところの仮説がたくさん上がって興味深かったです。
参加者に好評でした
まず、感想を聞いた参加者の全員が「良かった」って感想で、
ほぼ全員に次回はいつですか？って聞かれました。
このリアクションでほぼ成功かなとおもいます。
また、「自分が思いつかない仮説があって勉強になった」という意見も多く、
楽しく学べる会できたのかなと思います。
他にも、今回参加できなかった人も「次は参加する！次いつやるの？」みたいな意見が多く、
参加者から楽しさが伝わってるみたいです。
次回予定
6月にもう一度同じお題で、参加できなかった人中心に開催する予定です。
というわけで、問題解決勉強会を実施しましたが、 気になる方はぜひやってみてはどうでしょうか。
もしかしたらそのうち一般公開して行うかも知れませんので、 そのときには告知すると思うので、参加してもらっても良いかも知れませんね。
JJUG CCCに参加＆登壇してきました。
先日5/18に開催されたJJUG CCC Spring 2019で
エンジニアのチームマネジメントについて登壇してきました。
つづいて丹野さんのセッションです
— tatsu (@tatsu_ev) May 18, 2019
開発リーダー1年目。メンバーのスキルアップのためにやっていること。#jjug_ccc #ccc_g2b pic.twitter.com/4h68xXbOB8
タイトルは ”開発リーダー1年目。メンバーのスキルアップのためにやっていること。”
資料はこちらになります。
なぜ登壇したか
”新米リーダーが、なんでマネージメントについて登壇してるの？”
って思う人が多いと思います。
実は、”内容については素人”っていう登壇は結構重宝されるものです。
(そんなLTがJJUGかNode界隈で昔あったような気がします)
例えば「Javaの初心者が分からないところについて」の登壇をした資料は 教える立場の人からするとかなり貴重な意見だったりします。
そんな感じで新人マネージャーとして
- 取り組んでいる所（80％）
- 解決できたところ（20％）
みたいな割合で発表して、 数年後にどれだけ解決したかみたいなアンサー登壇できればいいかなと思って申し込みました。 (CfPの締切は2月末だったので)
ただ、申込み以降にマネージメントの成果と思われることが思ったよりも早く出てきたので、 盛り込んでいった結果、 解決できたところの割合が増えていい感じの登壇内容になったと思います。
また、エンジニアンのためのマネジメントキャリアパスを読んで 自分の施策を理論として体系化したものと比較して資料に落とし込みました。
まぁ、直感的にやってる施策の概念に名前がついていただけなんですけどね。
質疑応答
質疑応答の時間を考えずに資料を作ってしまったので、質問は個人質問になってしまいました。
なので、ここで共有しておきたいと思います。
質問：自身の心理的安全性はどうやって確保しているか
この質問なんですが、リーダーのプレッシャーとどう向き合うかみたいな意味で捉えてしまって以下のように答えました。
「仲間を頼ることで、自分が休んでもなんとかなるみたいな状況を作ることで楽になります」
しかし、もしかしたら、
メンバーの立場からチームの心理的安全性を確保していきたい
と言うような意図の質問だったのかなと思って それについてもここで答えたいと思います。
一番大事なのはとにかく話す機会を作ることだと思います。
普通に中の良い人と行くランチに別のメンバーを誘ってみるとか、
会社の近くで美味しいご飯屋を見つけたらそれを切り札に。
また、美味しいご飯屋を先輩に聞くのも話すきっかけになります。
お酒が得意ならチームの飲み会を主催するとか。
その辺のコミュニケーション活性化についてはリーダーに相談してみて、 リーダーを味方につけてしまうのが手っ取り早いかもしれませんね。
質問：輪読会の時間確保について上司をどう説得したか
※なんて答えたか忘れちゃったので、改めて回答します。
業務時間中にやることについては、 話半分ぐらいで「いいよいいよ」って言われたと思います…
そもそも、そこについて話した記憶がないです。
仕事に使うスキルの勉強は本来仕事に含まれるはずです。
そこが仕事に含まれる会社なので特に問題になってません。
そこはリーダーが守るべきポイントかなと思っています。
あとはスケジュールの調整になると思いますが、 そこは自分がリーダーなので勉強込みでスケジュール調整するだけです。
ちなみにうちのチームは基本的に残業してたら帰れーって言います。
リリースタイミングなどの都合で、どうしても間に合わない場合は輪読会自体を延期します。
無理して決めた週にやる必要はないので。
感想
まず、現在社内的にも成功しているチームとして一緒に働いているチームのメンバーにお礼を言いたいと思います。 (月曜日の夕会でも言ったけど）
登壇の感想をみてみると、
JJUGのアンケートでは85％が良かった以上(回答数20人)
Twitterの感想もかなり好感触で発表自体も成功したのではないかなと思います。
中には
このチームで働いてみたいと思った。
というものがあって、リーダー冥利につきるコメントでありがたいです。
あと、Twitterの感想で驚いたのはグラレコをしてくれている人がいました。
開発リーダー1年目。メンバーのスキルアップのためにやっていること を聞いてきたメモ #jjug_ccc #ccc_g2b pic.twitter.com/WerI0lfro7
— Nakayama san (@nakayama_san) May 18, 2019
これはありがたいし、素晴らしいと思います。
当日は定員210人のところ、満席になるまで来ていただいてありがとうございました。
ゆるキーVo3参加してきました。
自分が自作キーボード界隈に飛び込んだばかりですが、
なんと狙ったようにキーボード関連のミートアップがありました。
なんてことをイベント前日に知り、
満員でしたが補欠に申し込みました。
ちなみにこういうイベントは当日いけなくなる事がよく発生するので、
数人オーバーでも繰り上がり参加出来ることが多い
ので補欠が数人であれば参加登録しちゃうのおすすめです。
予想通り当日には補欠から繰り上がっていました。
- ゆるキーとは
- 当日の様子
- 個人的に好きなキーボード
- LT大会
- ゆるキーに参加してみて
- 自作キーボード界隈のコミュニティについて
- ものづくりの現場
- まとめ
Lily58 Proのディスプレイ表示(OLED)を改造してみる
自作キーボードLily58 Proの光らせ方
みなさん、自作キーボードというのをご存知でしょうか？
知らない方はこちらの記事を参照 qiita.com
簡単に言うと、 「欲しい商品がないなら作ってしまおうぜ」 っていうジャンルです。
ちなみにこの画像のキーボードは普通に作成した場合は光りません。
このキーボードの動画をTwitterに上げたところキットの作者に驚かれました。
LEDをバックライトで実装しているのすごい…
— ゆーち (@F_YUUCHI) March 17, 2019
- 経緯
- 制作方法
- 材料・費用
- 必要な材料
- 工具
- LED加工
- 組み込み
- 抵抗の取り付け
- 配線
- その他写真
- 今後の野望
- 材料・費用
Insta360 ONE Xをスキー・スノーボード撮影に使ってみた感想
いきなりですが、
Insta360 ONE Xを購入しました。
※この記事はアフィリンク多数です！筆者に収益が入るのが気に食わない人は商品名でググってください！
概要
- Insta360 ONE Xすごい
- デメリットはあるがアクティビティをやるなら買いだと思う
- スキー・スノーボードの撮影は楽しい
今回レビューするのはこのカメラです。
スキー・スノーボードの撮影は楽しい
そもそもなんでカメラなんか持っていくのかって思う人もいるかもしれません。 以前は自分もそう思っていたと思います。
でも、いざ撮影して動画を作ってみると
- 自分の滑りをチェックできる
- もっとうまくなりたいと思うようになる
- 行ってない人にも動画を見せながら話題にできる
というメリットが有りました。
ちなみにそのときに作った動画がこちら
YOZORA in yuzawa park short ver
その年の滑りが残るので、上達具合が見られてみんなの向上心が高まって 次、行くときのモチベーションになったようです。
アクションカメラAKASO EK7000
今まではAKASO EK7000という安いアクションカメラを使っていました。
お値段8000円以下で、オプションパーツもたくさんついてくるので、入門にはいいと思います。 ただ、手ぶれ補正がないのでそのままだと下の動画のようになってしまいます。
かなりブレがひどいですね。
そこで、この動画に動画編集ソフトでデジタル手ぶれ補正（ワープスタビライザー）をかけて、安定化させて利用していました。
手ぶれ補正かけたのが下の動画になります。
だいぶ安定しますが、動画の画面サイズが小さくなってしまいます。
そのため、補正前は画角に収まりきっていた場合でも手ぶれ補正をかけたときにフレームアウトしてしまう場合があったりします。
個人的には、もう少し高い手ぶれ補正付きのカメラを買うのが良いかもしれません。
こんなのです。（使ったことないですが…）
あると便利なオプションパーツ
とりあえず手持ちで撮影するのは難しいと思うので、 自撮り棒はあったほうがいいと思います。
雪山のカメラ撮影をやったことある方にはおなじみかもしれませんが、 寒い場所だとバッテリーがヘタります。 なので、
- 自撮り棒
- ヘタリ防止用の保冷パック
- 予備バッテリー(3個ぐらいあると良い)
- モバイルバッテリー
の4つがあると便利です。 普段は、保冷パックに予備バッテリーとモバイルバッテリーを入れておき、 バッテリーがヘタったら交換する感じにしています。
だいたい1日の撮影でバッテリー2個使い切るかどうかっていう状況なので、 余裕を持って3つぐらいあると良いと思います。
ただ、撮影した動画を非圧縮で受け渡すときにカメラとスマホのバッテリーをガンガン消費するのでモバイルバッテリーも持っていってます。 もちろん、モバイルバッテリーからカメラのバッテリーへの充電もできるので、その点でもあると良いです。
ちなみに使っているのはこの商品です。
Insta360 ONE X
前置きが長くなりましたが、やっと今回買ったInsta360 ONE Xの話になります。
Insta360 ONE Xは一言で言うと360度カメラです。
ただ、このカメラはアプリがすごい。
- 鬼のような手ぶれ補正機能
- アプリで対象を指定しての画面追従機能
手ぶれ補正も強力なのですが、Gセンサー＋画像解析を組み合わせたターゲット追従機能がすごいです。
Insta360 ONE Xを使って撮った動画が次の動画です。
生憎の天気で写りは悪いですが、こんな感じで常に被写体を画角に収めながら手ぶれ補正をかけることが出来ます。
また、スマホのアプリでトリミング、ターゲット追尾などの加工ができるので 撮影して編集して切り出してその場でシェアというようなことも出来ます。
メリット
恐ろしいぐらいの手ぶれ補正
まずはなんと言っても、手ぶれ補正の凄さ。 意図的に振り回してもある程度までならなんとかなってしまいます。 しかも、360度撮影しているため、手ぶれ補正をかけたときの画面サイズの縮小がない これだけで十分選択肢に入ります。
画角を気にしなくて良い
普通のアクションカメラは撮影中に対象を追っかけながら、 画角を考えて撮影するためどうしても滑りに集中出来ませんでした。
また、カメラのブレをなるべく減らすために気を使わなければなりませんでした。
Insta360 ONE Xでその悩みから開放されたのはすごく大きいと思います。
具体的に挙げると、
- 難易度の高い斜面でも安定して撮影可能
- 撮影対象に寄ることに集中できる
というメリットがありました。
SmartTrack
Insta360 ONE Xで撮影した動画は360度動画なのですが、そこから普通の動画に切り出す際にカメラアングルを指定しなければいけません。
ここですごいのが、SmartTrackというアプリの機能で動画の編集時に対象を指定すると勝手にその対象が中央に来るように画角を調整した動画を作成出来ます。
SmartTrackについては公式動画をみるとわかりやすいかもしれません。
自分が撮影した動画もSmartTrackで追従させています。
デメリット
バッテリーが弱い
電池の持ちはAKASO EK7000より悪く、 ４～５時間滑る中でバッテリー2個で運用しましたが、
途中で足りなくなってしまい、途中で撮影中止してモバイルバッテリーから充電していました。
リフトに乗る時間、リフトに並ぶ時間などがあるので実際にカメラを回した時間は20分前後でしたが、ちょっと足りないかなという感じです。
バッテリーは3～4個あったほうが良さそうです。
給電しながらの撮影も出来ますが、雪山だと基本的に防水カバーをつけての撮影になると思うのでその際は給電できないので注意が必要です。
2019/02/13 追記
低温用バッテリーがあるようなので、 スキー・スノーボードの場合はそちらを利用すると多少長持ちするようです。
謎の停止
原因不明なのですが、回したはずのカメラが気がつくと停止してシャットダウンされる問題が有りました。 原因として考えられるのは
- 操作ミスでビデオモードになっていなかった
- 低温でバッテリーの電圧が下がってしまった
- 振動で勝手にOFFになった
が考えられますが、不明です。
オプションパーツが高い
AKASO EK7000のような低価格商品じゃないので、そこそこオプションパーツの値段が張ります。 本体価格＋1~1.5万円ぐらいは見積もったほうがいいかもしれません。
映像が思ったより遠い
映像をみると微妙に距離が遠いなと思いました。
他のアクションカメラも広角レンズなので思ったより距離が遠くなりがちなのですが、Insta360 ONE Xではさらに想定より遠く感じました。
おそらく一番「画が映える」距離は２～３ｍだと思われますが、 並走するには近すぎ、自撮りするには遠い微妙な距離な気がします。
長めの自撮り棒を用意するのがいいかもしれないです。
あると便利なオプションパーツ
こちらも同様に
- 自撮り棒（1ｍ以上のものがあると良さそう）
- 防水ケース
- 予備バッテリー(3個～4個あると良い)
- モバイルバッテリー
自分は先程の３Way自撮り棒を使って撮影しましたが、 長さに不満があったので長めの自撮り棒を用意すると良いと思います。
防水ケースはスキー・スノボの撮影では必須だと思います。 なければSDカード挿入口やUSBの口がむき出しになってしまいます。
自分の場合防水ケースは品薄のため買えなかったので、やむなく潜水ケースを買いました。 ただ、潜水ケースのほうが高く画面表示がとても見にくいので、防水ケースのほうが良さそうです。
予備バッテリーはたくさん欲しいところです。 防水・潜水ケースを利用すると給電撮影ができないのでバッテリー頼みになります。
モバイルバッテリーについては先程と同様 現地で予備バッテリーを充電したり、スマホにデータを移す時に利用することになるでしょう。
ちなみに、このダンボーのモバイルバッテリーはUSBが２つあるのでカメラのバッテリーとスマホのバッテリーを同時に充電できておすすめです。
この自撮り棒は次回利用予定。
Insta360 ONE Xは買い？
買いだと思います。
上ではデメリットをたくさんあげましたが、それでもメリットのほうが大きいと思います。
まず、360度カメラの可能性として、 たとえばキッカーの頂上に挿しておけばジャンプの前後が取れたり、 みんなで滑る時に全員を撮影するということも可能です。
また、自分はスキーでの撮影ですが、 スノーボードで普通のアクションカメラを使って撮影する場合、 安定してフレームに入れるのはかなり難しいと思います。
その点気にしなくていいので360度カメラでの撮影っていうのは撮ってもらいやすいというメリットもあります。
その上で、強力なアプリの補助があり、手軽に運用ができるInsta360 ONE Xを選ぶのは十分有りだと思います。
また、今までアクションカメラを使ったことない人は、ぜひ安い物でも良いので一つ買ってみると良いと思います。
いい感じの動画が取れたときの被写体の人も撮影者もテンションがあがって、 またそれを残せるというのは素晴らしいことだと思います。
ただ、撮影の際は周囲の安全に気をつけましょう。
最後に、いつもボード誘ってくれて動画を使っても良いって言ってくれた友人に感謝！
去年の振り返りと今年の目標(2018)
あけましておめでとうございます。
今年もよろしくお願いします、
というか今年こそは記事書こう。
去年の目標
JavaScriptのフレームワーク習得
Vue.jsは趣味程度に少しだけ触りました。
習得出来たかと言われると微妙なところですが、50％ってところでしょうか。
ゴールが不明瞭なタスク設定だなと反省しました。
Java Api読破
業務でJavaを使わなくなってしまった（一部使ったけど）ので、優先度下げます。
技術情報の発信を月一以上
すみません。
年間で2本だったので、2/12なので、16％ってところでしょうか。
サーセン。
去年やったこと
転職
前職では、Javaのサーバをオンプレで作ってましたが、
PHPでサーバをクラウドで作成したり、 お客さんの要望にあわせてクラウドの構成の設計したり クラウド上に環境構築したり、 いろいろやらせてもらっています。
身につけた技術
PHP
ある程度は書けるようになってきました。
古いバージョンのPHPのレガシーコードをいじってた頃は
「Javaで書きてー！」という感想でしたが、
PHP7触ってると、どっちでも良くなってきました。
ただ、IDEの補間はやっぱJavaのほうが強力なのかなと思います。 その代わり、細かい所に手が届く関数が沢山用意されているなぁという印象です。
Google Cloud Platform
結構大きめなプロジェクトの構成を0から設計させてもらいました。
- Cloud Storage
- Compute Engine
- App Engine
- Cloud Dataflow
- BigQuery
- Cloud Functions
- Logging
での開発経験が積めました。 今年中に認定資格取りたいと思います。
ShellScript
今の会社に入って最初にお願いされたのがGitのリリースシェル
それからなんだかんだ使う事が多かったので、
人並みには使えるようになったつもりです。
というか、あまり複雑な処理をやる場合は言語選定で外しますが…。
Node.js
主にCloud Function向けのスクリプトを書きました。
ただ、そこで作ったモジュールを再利用した結果データ整理などを行うスクリプトが全て ShellScriptとNodeで出来てしまいました。
コールバック地獄からPromiseに置き換えて、その後asyncで書くという
非同期処理パラダイムを一通り経験できてよかったと思います。
Electron
趣味で触ってます。
メイン画面を立ち上げたらあとはWEBサービスと同じ感覚で触れますね。
ただ、サブ画面とかを立ち上げるときはまたElectronの世界に連れて行かれます。
Mocha & Chai
こちらも趣味で導入しました。
JavaScriptのユニットテストを今まで出来ていなかったのですが、 やっと出来るようになりました。
正規表現
簡単な正規表現なら何も見ずに書けるようになってしまいました。
特に()と$1（マッチングのグループ化ができる）にはお世話になってます。
$1を覚えてからは大抵のことはVSCodeで出来るので、エクセルいらずになりましたね。
カンファレンス
JJUG
春、秋両方でLTしました。 秋のLTはGCPのCloud Dataflowについてです。
LTに収まらずにオーバーしてしまったので、 どこかでロングバージョンを発表できればいいなと思ってます。
東京Node学園祭2018
などが聞けて面白かった。
ただ、英語のセッションが多くてしんどかったです。
GitHub
ID作ってしばらく放置していましたが、活動し始めました。
DateTimeParser
QiitaのJavaアドベントカレンダー向けの解説用コードを公開しました。
Johari
デスクトップ向けの画像整理＆閲覧用のアプリ作り始めました。
とりあえず、ローカルの画像ファイルに
- 画像一覧の表示
- 画像にタグ付け
- 画像DBの作成
などが出来ます。 将来的には、ソートしたり画像の保存先を管理したり ムフフな画像をこっそり管理したり… 出来たら良いなと思ってます。
しかも、これHTMLで表示しているので、 例えばS3、GCSに画像を置いて一元管理するとか… WEBページにしちゃうとか… 夢は広がります。
まだ、開発者向けという段階で、機能も乏しく完成度も低いです。 これからってところですね。
今年の目標
GCPの資格取得
クラウドアーキテクトを取得したいと思います。
技術情報の発信を月一以上
がんばる
Johariをある程度形にする
ざっくりとした目標ですが、ゴールは 「一般公開出来る状態にすること」です。
必要なのは
- 配布ページ
- ドキュメント
- 適切なエラーメッセージ
を揃えることだと思います。 ある程度の機能ができた段階で、この3つを用意できれば完了かなと思います。
この3つを今年は頑張っていこうと思います。
