Re：YammerでHubotを利用する（環境構築編２）
前書き
ご無沙汰となりました。iPXのabikoです。
またしても大分間が空いてしまいました。
一体何時から続いているのか、というHubot記事ですが、今回と次回を2本立てでお送りして一旦〆たいと思います。
さて今回の記事は...
前回の環境構築編も一年も前の記事となり、現在ではサーバを立てるまでの画面遷移など諸々が様変わりしています。
その環境構築について見ていくと、終わりが見えないので前回記事終了時点「Amazon EC2が起動しておりSSH接続ができている」ところから話を進めます。
前回の記事
Re：YammerでHubotを利用する（環境構築編１） - iPX社員によるブログ
前々回の記事
社内で利用するYammerにbotを作りたかった（環境構築編） - iPX社員によるブログ
実は今回、Hubotのインストールに大苦戦しました。
過去インストールできた方法が通用せず、エラーばかりだったんですね。
そのエラー達への対処は横に置いておき、最終的にインストールできた方法をご紹介していきたいと思います。
エラーで？マークが出ていた私を救ってくれたはサイト様はこちら。
AWS EC2でNodeを動作させる
上記のサイトではEC2の起動から、Node.jsによるHTTPサーバの作動まで、とても丁寧に紹介されております。
※少々昔の記事なので現在と多少の違いはありますが、かなり参考になるかと
Hubotのインストールのための準備
基本的には前述のページどおりに進めていけば準備完了です。
コマンドを実行して環境を整えつつ、必要なものをインストールしていきます。
# システムアップデート $ sudo yum -y update # 開発ツールのインストール（コンパイラやらGitやら） $ sudo yum -y groupinstall 'Development Tools' # nvmのインストール $ git clone https://github.com/creationix/nvm.git ~/.nvm $ source ~/.nvm/nvm.sh # Node.js のバージョン一覧の表示 $ nvm ls-remote v0.1.14 v0.1.15 ・・・（略) v10.11.0 # Node.jsのインストール（2018/10/08 時点の最新版：v10.11.0） $ nvm install v10.11.0 $ nvm use v10.11.0 # バージョンの確認 $ node -v v10.11.0 $ npm -v 6.4.1
nvmのパスの設定（source ~/.nvm/nvm.sh）は今回のセッションでのみ有効です。
次回以降はログイン時に自動で設定されるよう、~/.bash_profileに下記を加えます。
# nvm if [[ -s ~/.nvm/nvm.sh ]] ; then source ~/.nvm/nvm.sh ; fi
いざHubotをインストール
以降はこちらのページを参考に進めました。（前回も参考にさせて頂きました）
Hubot を Amazon EC2 にセットアップして Yammer に投稿する
# インストール $ npm install -g yo generator-hubot ・・・（略） Everything looks all right! + yo@2.0.5 + generator-hubot@0.4.0 added 839 packages from 300 contributors in 27.223s # 初期設定 $ mkdir YAMMERBOT $ cd YAMMERBOT $ yo hubot ? ========================================================================== We're constantly looking for ways to make yo better! May we anonymously report usage statistics to improve the tool over time? More info: https://github.com/yeoman/insight & http://yeoman.io ========================================================================== No _____________________________ / \ //\ | Extracting input for | ////\ _____ | self-replication process | //////\ /_____\ \ / ======= |[^_/\_]| /---------------------------- | | _|___@@__|__ +===+/ /// \_\ | |_\ /// HUBOT/\\ |___/\// / \\ \ / +---+ \____/ | | | //| +===+ \// |xx| ? Owner abiko ? Bot name YAMMERBOT ? Description A simple helpful robot for your Company ? Bot adapter yammer create ・・・（略） _____________________________ _____ / \ \ \ | Self-replication process | | | _____ | complete... | |__\\| /_____\ \ Good luck with that. / |//+ |[^_/\_]| /---------------------------- | | _|___@@__|__ +===+/ /// \_\ | |_\ /// HUBOT/\\ |___/\// / \\ \ / +---+ \____/ | | | //| +===+ \// |xx| ・・・（略）
はじめは匿名での使用統計の送信有無を聞かれます、今回は n としています。
その後の必要情報の入力ですが、Bot name（任意の名前）とadapterの項目以外はEnterキーで飛ばしてしまって大丈夫です。
間違えてしまっても後から修正できますのでご安心ください。
修正するには作成したディレクトリ配下のpackage.jsonファイルを編集します。
また、adapterの項目をEnterで飛ばしてしまった場合は次の方法でインストールできます。
$ npm install hubot-yammer
ひとまず起動する
$ ./bin/hubot [Mon Oct 08 2018 12:35:35 GMT+0000 (Coordinated Universal Time)] WARNING Loading scripts from hubot-scripts.json is deprecated and will be removed in 3.0 (https://github.com/github/hubot-scripts/issues/1113) in favor of packages for each script. Your hubot-scripts.json is empty, so you just need to remove it. [Mon Oct 08 2018 12:35:35 GMT+0000 (Coordinated Universal Time)] INFO hubot-redis-brain: Using default redis on localhost:6379 [Mon Oct 08 2018 12:35:35 GMT+0000 (Coordinated Universal Time)] ERROR hubot-heroku-keepalive included, but missing HUBOT_HEROKU_KEEPALIVE_URL. `heroku config:set HUBOT_HEROKU_KEEPALIVE_URL=$(heroku apps:info -s | grep web.url | cut -d= -f2)` YAMMERBOT> YAMMERBOT ping YAMMERBOT> PONG
ワーニングなど目に付きますが、ひとまず返答が返ってくるところまで動作確認ができました。
Yammerと連携するためのトークンの取得
前述のページの通りに進めると接続に必要なトークンが取得できます。
Hubot を Amazon EC2 にセットアップして Yammer に投稿する
発言者になる予定のユーザでyammerにログインした状態で、下記URLにアクセスします。
https://www.yammer.com/client_applications
「新しいアプリの登録」を押した先の入力項目を埋め、作成されたアプリ項目の「このアプリケーションの開発者トークンを生成する」を押します。
現れたトークンをメモ帳などにコピペしておき、情報取得は完了です。
入力例
値のメモ
Yammerと連携する設定
環境変数に情報を設定していきます。
今回は投稿用のグループとしてHubotグループを作成しました。
# アクセストークンは先ほどメモしたトークンを設定 $ export HUBOT_YAMMER_ACCESS_TOKEN="xxxxxx-xxxxxxxxxxxxxxxxxxxxx" $ export HUBOT_YAMMER_GROUPS="Hubot" $ export HUBOT_HEROKU_KEEPALIVE_URL="https://www.yammer.com/api/v1/users.json"
いざ、起動して確認！
$ ./bin/hubot -a yammer -n "YAMMERBOT" ・・・（略） groups list : Hubot groups_ids list : 11178894
./bin/hubot -a yammer -n "Hubotの名前"
で起動できます。
では反応を見てみましょう。
Hubotグループにて、「YAMMERBOT ping」と発言してみます。
すると・・・
無事、返信がありました！
長い道のりでした。
因みに
ここでもまた大苦戦したんですが、Hubotはデフォルトで自分自身には返答しない仕様とのこと。
永久ループを防ぐためだと思いますが、Hubot用アカウントを用意できない、という方もいるのではないでしょうか。（私がそうです）
この問題は環境変数の設定で回避できますので、よしなにお使いください。
$ export HUBOT_YAMMER_REPLY_SELF=1
次回
このあたりで力尽きたので、次回までしばし休憩です。
次回で一旦〆になります。
Hello Warldをするところから始まり、簡単にスクリプトに触れていきたいと思います。
それではまた、お会いしましょう。
食欲の秋・飲酒の秋・戦争の秋
食欲・・・おいしいものいっぱいの季節
飲酒・・・酒、進みますよね。
戦争・・・そう、戦争。時には身を潜め、時には全速力で走り抜ける。運動ではなく戦争。
こんにちは。iPX MEU郡です。
少し仕事とは離れて・・・
私の愛銃”L96 AWS”スナイパーライフルです。
そうです、サバゲ―な季節です。
サバゲ―で使用されるガンを、総称してトイガンと呼びます。
サバゲって何なん？って方多いと思うのでざっくり紹介します。
１．トイガンの種類
トイガンは、内部にエアシリンダが搭載されていて、その圧縮空気を開放してBB弾を発射します。
圧縮させる方式によって、大きく分けて3種類あります。
①エアコッキング
②電動
③ガス
①エアコッキング
トイガン内部のエアシリンダを圧縮させる操作を、手動でスライドさせて、空気を圧縮させるタイプです。
スナイパーライフルやショットガンがこれに該当します。
さらに、スナイパーライフルのような、レバーを引くタイプをボルトアクション。
ショットガンのようにスライダーを引くタイプをポンプアクションと呼びます。
②電動
エアシリンダの圧縮操作を、モータの力でシリンダをスライドさせて、空気を圧縮させるタイプです。
アサルトライフル、サブマシンガン、マシンピストルがこれに該当します。
電動なので、連射させるガンは大体これです。
③ガス
エアシリンダの代わりにガスタンクを搭載させて、ガスを注入・圧縮させるタイプです。
ハンドガンが多いですが、アサルトライフルやスナイパーライフルも少数存在します。
エアと比べて圧縮率が高いので、エアより勢いがあります。オートマチックハンドガンは、発射時の反動を利用して、次弾を装填しているのですが、ガスの勢いでこれを再現されています。溜まりませんね＞＜
しかし、「ガスが消耗品」「温度の影響、気温が低いとほとんど圧縮しない⇒弾出ない」とデメリットもあります。
２．場所
いったいどこでやっているのか・・・意外と気軽にできますよ～
①場所
②定例会
③貸し切り
④いるもの
①場所
フィールドと呼んでいるのですが、大きく分けて室内フィールドと屋外フィールドがあります。
室内フィールドは、その名の通り室内です。大体狭いので、ハンドガンくらいがちょうど良いです。
都内でも遊べるのは、大体室内フィールドです。気軽な感じとイメージしていただければｗ
屋外フィールドは、千葉とか埼玉とか、大体車がないと行けないようなところにあります。
ライフル系とか、思い切り連射したいときは、屋外じゃないと厳しいですね。
①定例会
フィールド主催で月１くらいでやってるイベントです。参加人数に制限がなく、自由に参加できます。不特定多数の方が参加してます。
受付時にチーム分けされるのですが、友達と来たときは、友達と同じチームに振り分けてくれます。
ルールの進行とかもフィールド側でやってくれます。
フィールドによっては初心者講習をやってくれるところもあります。
③貸し切り
友達どうし声かけて、人数を確保できるなら貸切るのもアリだと思います。
その際は、ルール進行などを自分たちでやらなければなりません。
④いるもの
どうでしょうか。興味でてきましたか？
行ってみたいけど、何がいるのか・・・大丈夫です。手ぶらで遊びにいけます！
フィールドにレンタルセットがあります。
「ガン、フェイスマスク、ゴーグル」は必需品で、服装は自由です。動きやすい服装でおｋ。実際、スポーツウェアでやっている方も多いです。
あとは汗かくので、着替えは持って行ったほうがいいかもしれませんね。
さてどうでしょうか。秋。戦争ですよ。
ダイエットはじめました(偽)
10月から・・・。
お久しぶりです。何故か大食い担当になってしまっている三浦です。
大学くらいまでは別に大食いキャラではなかった筈なんですけどねぇ・・・(´・ω・｀)
健康診断が数年連続で下から2番目の判定だったり、体重が3ケタに近付きつつあることからそろそろ危機感を感じて参りました。
で、タイトルに戻りますが、初めてダイエットを真剣に考え始めました。
ちょいちょい運動をするようにしたり、コンビニ弁当減らしたり。
野菜嫌いの超偏食家なので、少しずつ食べられる野菜も採り始めたり。
急速に痩せられるとは思っていないので、それなりに時間をかけて痩せられたらな、と思ってます。
10月から。
続きを読むプロジェクトマネジメントする側になって・・・
現在PMとしてアサインされ、徐々に頭角を現してきている寺田です。
自分で言うのもなんですけど（笑）
今回は私が現在も進行しているプロジェクトのマネジメントについて、
実体験から得たものを自分なりに記載したいと思います。
プロジェクトマネジメントって？
アサインされる前からネットの記事を見るや、本を購入して勉強する等してはいましたが、
そもそもプロジェクトマネジメントとは何でしょう。
これは上記より得た情報の一部ですが、「マネジメント≠管理する」ではないようです。
ではマネジメントとは何をする事なのでしょうか？
それは「プロジェクトをゴールへ導く」
これ1点に尽きます。
では具体的には何をしていくとゴールへ導く事ができるのでしょうか？
以下に記載していきたいと思います。
管理「も」仕事
管理するだけが仕事ではないという事ですね。プロジェクトが上手く回るためには全体を把握している人が必要です。
マネジメントする人はただその位置にいるだけなのです。
でもこれ「も」仕事ですから全体を把握するための情報収集が不可欠になります。（自分が理解していないと回せませんからね。）
管理手法である「WBS」においても全てのタスクが詳細に出ていなければ作れませんし、前後関係を考えた構成は組めません。
どんな手法であれ、全体把握が可能な管理手法を探して、それを遂行する事でプロジェクト全体を管理します。
プロジェクトを円滑に進めるための影の努力
プロジェクトを進める上で重要な要素になるのが、指揮系統、自社の人間関係、会社間の信頼度等の対人間における部分です。
プロジェクトメンバー間で揉め事というのは少なからず発生するものです。
また仕事を頂いているクライアントや協力会社の方との間での揉め事も発生は避けられないものです。
人間ですからね。
まずプロジェクトを始める前に「体制図」を作成して、指揮系統を固めるのが定石ですが、
私が途中から進行しているプロジェクトには指揮系統が定まっておらず、この「揉め事」が
自社内と自社とクライアントの2か所で勃発していました。
まず現状把握に努め、そこから問題点を洗い出し、どこが問題なのか考えたところ、
言葉の齟齬がある事、その齟齬から認識の齟齬が発生している事
お互いに身勝手な行動を取っている事
がこのプロジェクトの進行の妨げになっている事が明らかでした。
円滑に進めるためには「協力」が不可欠になるため、
まず「協力」が出来る体制作りを心掛けました。
そのためには
プロジェクトの全貌を理解する。
発生するタスクを理解する。
参画しているプロジェクトメンバーとそのスキルを把握する。
参画しているメンバーの意見を聞く。
という課題があり、これを日々の中で吸収していく必要がありました。
中でも参画しているメンバーの意見を聞くについては力を入れ、
それぞれが抱えている不満や言い分を取りまとめた上で、
プロジェクト進行の上で身勝手な行動を取るものには「叱責する」
態度を改めるまでは「接し方や言い方に変化をつける」
自社間・自社とクライアント間においての情報連携において「間を取り持つ」
等を実施しました。
その結果現在は自社間の連携、クライアントとの連携が前に比べるとスムーズに
なった印象を受けます。
円滑進めるためにはこういった「影の努力」が必要になります。
マネジメントする人間は常時これを意識しておく事が大切だと私は思います。
リスクマネジメントの大切さ
プロジェクトをマネジメントする上で日々考えておく必要があるのが「リスク」です。
「リスク」とは未知のもの全てを指します。
悪いリスクと良いリスクがあるという事です。
悪いリスク
いかにリスクが顕在化する前に「軽減」「転嫁」できる体制を整えておけるかが、
プロジェクト内での工数に大きく影響してきます。
現在進行しているプロジェクトにおいても、このリスクは多数存在し、
一部はこの「リスク」を事前に話合っておいた事で、
「軽減」しつつ「転嫁」する事に成功しています。
軽減は具体的には自社の工数が減る事を指し、
転嫁はクライアントで対応する方針に出来た事を指します。
結果的には自社で受ける作業が減った事になり、工数に余裕が
出たため、プロジェクトメンバーに無理をさせる事が減るのです。
これはデカい。
メンバーのストレス軽減にも繋がりますので、「リスク」を
感知しておくことは大切です。
良いリスク
現在進行しているプロジェクトでもありました。
元々ひいたスケジュールとは別に、クライアント側の都合で引かれたスケジュールがあり、
一旦はこれを「悪いリスク」と判断の上、クライアントとの打ち合わせを実施したのですが、
このスケジュールを守り切れるならば、もともと考えていたタスクの内、
検証フェーズの検証レベルを下げても良いとのお達しがあり、
工数を大幅に削減する話になりました。
こういったリスクは話の持って行き方次第では、プロジェクトがいきなり軽度なものに転換する
事が考えられます。
ただ、今回の場合はですが・・・。
なかなか良いリスクって転がっていないものですね・・・。
まとめ
プロジェクトをゴールへ導くためには全体を把握する事、日々管理していくこと、
そこに転がるリスクを感知して良い方向へ持って行く事が最低限必要であるという内容で
書かせて頂きました。
考えるべきこと、実践しなければいけない事はまだまだありますが、
それは次回以降にしたいと思います。
日々勉強ですがゴールに導けたら、その時喜びを感じる事が出来るのだと
言い聞かせながらこれからも精進していくつもりです。
毎日アンテナ張ってると疲れますけどね。ボーリング行きたい・・・（笑)
