リモートワーカー必見！ペアプログラミングからPC環境整備のサポートまで幅広く使えるツール ScreenHero とは
リモートでペアプログラミングをしていたりすると、よくこんな事ありませんか？
- チャットに操作して欲しいコマンドを貼り付けている
- 相手の操作が遅くてムダな時間が多い
- 「いや、そうじゃなくて。まずxxxして！」とよく言っている
- Skypeなどの画面共有ツールがよく落ちる、解像度が悪い
このような経験がある人は、何も言わずにとりあえずscreenheroを試してください。
"リモート同士の人たちが、お互いのPCで共同作業を効率的かつ気軽にできるようになるツール"です。
機能をテキストで説明するよりも、実際に見てもらった方が早いと思うので、まずはプロモーション動画をご覧ください。
１人がもう１人のPCにscreenhero越しで接続し、そのPCで共同でXcodeをマウスで操作して画面を作っていくというストーリーです。
Screenhero — Collaborative Screen Sharing
動画をみてもらうとわかると思いますが、ペアプログラミング以外にも活用シーンはいっぱいあります。
- PCの使い方がわからないママをサポートをしてあげる
- 環境構築で苦戦しているエンジニアを助けてあげられる
- デザイン作成のペア作業ができる
- ドキュメントの同時編集ができる
- エクセルの同時編集ができる
screenheroを使うことで、待ち時間を減らすことができ、さらにできる人がぱっと操作することでイライラすることが無くなるはずです！
これで快適なペア作業ができるようになりますね！
ただ、このツールは2015年の2月頃に企業向けのチャットツールであるSlack社が買収したことで、将来的には"Screenhero"の機能が"Slack"に統合されていくようで現在、招待以外での新規登録ができないようです。
ぜひ使ってみたいということであれば、facebookか本記事のコメントにご連絡いただければと思います。
それでは、快適なリモートワークをEnjoy！！
あわせて読みたい
リモートチームでうまくいく マネジメントの?常識?を変える新しいワークスタイル
- 作者: 倉貫義人
- 出版社/メーカー: 日本実業出版社
- 発売日: 2015/12/17
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
JAWS DAYS 2015 で『DevOps が普及した今だからこそ考えるDevOpsの次の姿』というタイトルで講演してきました！
JAWS-UGによる東京でのビックイベントである JAWS DAYS 2015 の DevOpsセッションでスピーカーとして登壇させていただきました。
発表内容はタイトルの通り、
『DevOpsが普及した今だからこそ考えるDevOpsの次の姿』
です。
さっそくですが発表スライドを公開します。
発表風景を代表の倉貫が撮影してくれてました。
発表時間ギリギリになってしまうだろうと思っていたのですが、だいぶ早口で説明していたようで、結果的には15分近く時間が余ってしまうという失態をしてしまいました。
ですが、皆さまの質問のお陰で時間いっぱいセッションを続けることができてホッと一安心でした。
ついでに１年前のJAWS DAYS 2014にて発表した時の資料も公開しておきますね。interu.hatenablog.com
当時OpsWorksを利用している方は少なかったのですが、今日のイベントではOpsWorksだいぶフィーチャーされてましたね！みんながOpsWorksを活用して運用負荷が減っていけば幸せなエンジニアライフを過ごせるかもしれないですね。
ふりかえりの「Keep」は褒めるためのもの？Keepも改善のインプットとして考えよう
ソニックガーデンでは頻繁に「Keep＝よかったこと」「Problem＝悪かったこと」「Try＝次に試すこと」の３つのフレームワークで考える「KPT」による ふりかえり を実施しています。
継続的に個人・組織をカイゼンしていくためのフレームワークなので、問題を炙りだしてその解決策を考え次へのチャレンジを実践していくところ（ProblemとTry）にフォーカスされがちですが、今回はあまり注目されていないKeepを少し掘り下げてみます。
ここからは毎週末に実施している弟子とのふりかえりを例に話をすすめていきます。
KeepがなぜKeepなのか？
よくあるふりかえりのKeepに
- 予定通りタスクを進められた
- 意識を変えれたのでうまくいくようになった
などが挙がります。
うまくいったことは素晴らしいことですね。良いことなのでいっぱい褒めてあげましょう！
ただ、褒めるだけで終わってよいのでしょうか？
うまくいったのには理由があるはずです。過去の自分と今の自分の行動で何かしらの変化があったから、うまくいくようになったのではないでしょうか。
そのため、自分自身（レビューイ）の"行動にどんな変化があったのか"が分析できていない場合はそれを掘り下げていきましょう。
例えば、"予定通りタスクを進められた" について、ソニックガーデンの弟子 @regonn とふりかえりで一緒に掘り下げてみたものを思い出してみると以下のようなものがありました。
以下、 変化を掘り下げた結果 → 今後Keepの内容 という具合に書いておきます。
- タスクの粒度を小さくした
→ タスクの粒度が大きすぎると途中で混乱するため、１つのタスクは１時間以内で終わる粒度まで分解するように
- タスクの見積もり時に不明点を考えた
→ 不明点を事前に調査してからタスクにとりかかるように
- タスクをやっていく順番を変えた
→ 依存関係を考慮し、待ち時間が発生するものは早めに着手するように
- 分からないことを自分で解決しようとするのをやめた
→ 30分考えてもまったくわからない場合、抱え込んでストップするくらいなら有識者を頼るように
- タスク実施 → レビューNG → タスク実施 → レビューNG が無くなった
→ タスクを依頼される際にアウトプットの認識合わせをするように
- ブラウザのタブを開き過ぎないようにした
→ 目的のタブやウィンドウをすぐに探せるように、気が散るキッカケを削減するように
このようにKeepの内容を深堀りすることで、Keepすべき内容も変わってきます。
改善できたことのポイントも明確になりましたよね。
@regonn の成長だけでなく、今後 @regonn が弟子教育を担当するようになった場合にも、このふりかえり内容を伝承していくことができるようになり、結果として個人のふりかえりが組織の成長につながるようになりますね。
以上のように、行動にどんな変化があったのかに注目して掘り下げて考えることで、異なったKeepがみえてくる場合もありますので、Keepを単に褒める場として考えるのでなくカイゼンのインプットとして捉える意識をもって取り組んでみましょう。
楽しくITの仕事をするために身につけてほしい基本的な考え方 〜 脱チェックリスト方式 〜
ソニックガーデンは小さな組織ではありますが、その中には新卒の社員もいます。
ちなみに来年度も１名新卒メンバーがJOINする予定になっています。
若手を採用するにあたり早く能力の高いエンジニアになってもらいたいという想いから、入社１年目のエンジニアにはコードレビューと同様にワークレビューも実施しています。
ワークレビューって具体的に何なの？と思われるかもしれませんが、これは毎週末実施する"ふりかえり"を通じて社会人／エンジニアとして常に成長できるようにするための仕組みです。
詳しくは『自律的に現場を改善できるチームをつくるための「ふりかえり」の進め方 〜 KPTと進め方のノウハウ | Social Change!』に書いてあるのでぜひご一読ください。
今回はその"ふりかえり"であった出来事を１つ紹介しようと思います。
弟子（新人）が仕事をいろいろやっていくと必ずミスをします。
そんな時は毎週のふりかえりで、
- そもそもそれは本当に問題なのか？
- 問題なら何が原因の本質か？
などを一緒に考えていきます。
そして問題の本質が見えてきたら、次回、同じことを繰り返さないためのTRY（トライ）を考えます。そのときの解決策として、"チェックリストをつくって、最後にそのチェックリストと照らしあわせて確認する”というTRYが出てきたりします。
が、この考え方で仕事をやっていっても楽しくないと思いませんか？
ミスをしないためにチェックリストをいっぱい作り、都度増えていく沢山のチェックリストと照合するという単純作業。いつの日かこのチェックリストに沿って確認することが仕事の目的となり、仕事の本質を見失ってしまうかもしれません。
では、どうすればよいでしょうか。
例として、家庭ゴミを取り上げてみます。
東京のゴミ分別は4種類ですが、神奈川のとある地域では10種類のところがあるようです。分別数を増やしたことでリサイクル率が向上し、ゴミ処理施設の稼働に余裕ができることで新規に処理施設を作らずに済み効果があったらしいです。
自治体視点では効果があったようですが、ゴミの分別数が増加したこと正しい分別をしていないゴミも増えたそうです。その対策として自治体は、監視スタッフを配置し、正しい分別ができてないゴミが頻繁に捨てられているところを見回り、正しい分別ができてないゴミがあった場合にはそのゴミ袋を開封し、誰のゴミかを特定し該当者に警告するそうです。
この仕組み、ゴミ分別というチェックリストを増やし、さらには見回りというチェックリストを増やし、ダメならゴミを捨てた本人に指導するという、チェックばかりの仕組みですよね。
そのため、自治体の成果としては良い結果になるかもしれませんが、
- ゴミ分別数が増えると、家庭での仕分けが大変になる
- 違反者は指導されると良い気持ちではいられない、分別の仕組みが複雑なのが悪いと思ってしまう
- 監視員が違反者に通知する際は、いざこざになりそうなので積極的にはいきたいとは思わない可能性
という負のスパイラルが発生しがちです。
負のスパイラルが発生すると、その仕事が嫌になってしまいますよね。
理想としては、”ゴミ分別を気にしなくてもリサイクル率が向上する"がありがたいはずです。
それを実現するためには、ゴミ分別場でゴミの仕分けを行い、リサイクル効率をあげれば良いですよね。
このようにチェックリスト方式で確認項目を増やしていってガッツで乗り切るというようなつまらないやり方ではなく、問題の本質を捉えて三方良し的になる仕組みを考えれるようになると、仕事も楽しくなっていきます。
そのため、"チェックリストをつくって、最後にそのチェックリストと照らしあわせて確認する”というようなTRYが出た場合は、本当に解決したい問題は何かを弟子と共にもう一度考え直すようにしています。
考え方を少し変えるだけで仕事が楽しくなる、楽しい仕事がモチベーションにつながる。
そんな仕事を自分で作れるエンジニアになりたいですね。
※人命を扱う仕事など小さなミスが大きな事故につながるシーンでチェックリスト方式は有効と考えています
OpsWorksで機能追加された環境変数を試してみて気づいた注意すべきこと
2014年8月のアップデートでOpsWorksのApps層の設定項目に環境変数が追加されました。
ということで、新しい環境を整備する際にこの機能を試してみたところ、想定と異なる動きをしていたので、その挙動についてかんたんに解説しようと思います。
HerokuなどのPaaSでは環境変数をセットすると、cron実行時などでも環境変数を参照できます。しかし、OpsWorksのApplication Layerの環境変数機能では、2014年10月時点ではそれができません。
というのも、WebServerに環境変数がセットされ、それがアプリケーションに伝わる仕組みだからです。
WebサーバとしてApache+Passengerを利用している場合は、Apacheの設定ファイルにSetEnvが追記されそちらがアプリケーションに伝わります。
Nginx+Unicornの場合も同じで、下記のようにUnicornの設定ファイルに追記され、そちらRailsアプリケーションに渡されます。
https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/unicorn/recipes/rails.rb#L49
この仕組みでもアプリケーションが稼働し始めた際には問題なく動きますが、Deploy Hookなどで環境変数を参照したいときやCron実行時に環境変数を参照したいときなどに参照できないという不都合が生じます。
Herokuに慣れていると、セットした環境変数はrails consoleやrake実行時にもセットされるためそれが当たり前だ思ってしまいますが、OpsWorksの現仕様ではそうなっていないので注意が必要です。
OpsWorksのインスタンスにログインしてdeployユーザに昇格してみてexportコマンドを実行するとわかりますが、OpsWorks側でセットした環境変数を参照することはできません。
※Herokuの場合はheroku run bashで接続してexportを実行するとユーザ環境変数にセットさていることがわかります。
よくよくリリースノート（AWS OpsWorks Supports Application Environment Variables）を読み返してみると、確かにApplication Environment Variablesをサポートしたと書いてあるので、Application層=Webサーバの環境変数を利用した仕組み、と読み取れはしますね・・・。
ただ、Apps層でdeployイベント発動時にセットされるRAILS_ENVについては、deploy hook実行時にも参照できるようになっていたので、その点が誤解を招いた結果になってしまったんですね。。。
今回、私が本機能を利用しようとした本当の目的としては、githubなどのソースコード管理システムに渡したくない情報、すなわちIAMのクレデンシャルの情報(AWS Access KeyやAWS Secret Key)をOpsWorksの世界に閉じ込めたいというところでしたので、いまいち利用シーンがフィットしないということになってしまいました。
AWSのセキュアな情報を同じServicerの機能（OpsWorks）に閉じ込めることは、セキュリティ的に見ても価値があると思いますので、ぜひこの点は改善してもらえたらと思います。
もっというと、Configureイベント発動時にdeplyユーザの環境変数にまでセットしてもらえると大変助かります。cron実行時にも参照できますし。ただ、セキュリティとの兼ね合いも検討しないといけないというのはわかりますが。。
ということで、みなさんもOpsWorksの新機能である環境変数を試される場合は、この点を考慮しておくとスムーズに検証できるかと思います。
そして、これからのOpsWorksの発展にも期待していますので、AWSのエンジニアの方々、よろしくお願いします。
『約10年、最新版のRailsに追従してきた運用ノウハウをビール片手に聞きましょう！』というイベントで発表してきました
6月末頃、Rails/Rubyのバージョンアップ作業を開始したときに、Railsアプリケーションを長い間運用しているサービスってなかなか聞かないよな〜と思って、Facebookで下記のような投稿をしてみました。
すると、「AWSを活用してる現場リーダーやCIOをお招きしたトークイベント」でパネルディスカッションをさせていただきました のイベントでお世話になった小山田さんがすぐさまトークイベントを持ちかけてくださり、今回、
約10年最新版のRailsに追従してきた運用ノウハウをビール片手に聞きましょう！ - Web系な人のキャリアカフェ | Doorkeeper
というイベントでお話させて頂くこととなりました。
当日は、社内SNS『SKIP』のサービス開発／運用でやっている取り組みを例に、Rails,RubyなどのバージョンアップからOSのアップデートを実施する際の取り組みについてご紹介させていただきましたので、その資料をこちらで公開します。
資料だけでは伝わらない点も多々あるかと思いますので、その際は右下に表示されている「この記事の感想を送る」にてメッセージいただけますと、出来る範囲で返答させていただきます〜
最後に
イベントの企画から当日の司会進行までいろいろご尽力いただいた小山田さん、どうもありがとうございました！
