1日1%成長するブログ

毎日成長するために仕事/プライベートで得た学びをアウトプットするブログです

Vimiumを使っているとスプレッドシートでEscキーが反応しなくなる

スプレッドシートを間違って全画面表示にしてしまうと、 メニューバーが表示されなくて非常に困ったことになる。

f:id:masaru_furuya:20171021232327p:plain

Escキーを押せば治ると書いてあるのだけど、自分はなぜか反応しなかった。。

Vimium blocking 'escape' shortcut in google spreadsheet · Issue #49 · guyht/vimari · GitHub

そんな時見つけた記事がこちら。

Vimiumを入れていると、スプレッドシートのEscキーが反応しないらしい... 拡張機能で無効にしたら無事Escキーが反応し、メニューバーを表示することができました。

今日の1%

困った時は英語で検索すると、何かしら解決策が見つかる。 今回の場合は「spread sheet escape is not working」で検索したら、うまく行きました。

HubotでSlackに毎日目標を通知するbotを作る (環境構築編)

Hubotとは

Hubotの構成

f:id:masaru_furuya:20171021080753p:plain

なぜbotにHubotを使うのか?

  • Hubotを使えばメッセージの受信・送信やチャットツールとの連携などbot実装に必要な最低限の機能を自分で実装せずで済む
  • CoffeeScriptJavaScriptで書けるので、学習コストも低い
  • Herokuで運用すれば無料で使えるので、サーバー代もかからず手軽
  • npmも使うこともできる

Hubotでできること

  • スクリプトも書けてAPIサーバーとの連携もできるので、プログラムでできることはなんでも出来る

  • 実装例

    • シフト表の投稿
    • デプロイの実行
    • GithubのPRブランチの作成
    • Githubのレビュワーのランダムアサイ

データの永続化

  • Hubotはデフォルトだとメモリ上に情報を保持するのでHerokuの再起動が走ると消えてしまう
  • 永続化のためにはbrainという仕組みを使う。FileやRedisに保存したりする。あとは外部のAPIサーバーヲ使うとか。
  • ここら辺は模索する

モジュールインストール

  • npm install -g yo generator-hubot

Hubotの雛形作成

$ mkdir hogehoge
$ cd hogehoge
$ yo hubot

? Owner masaru
? Bot name daily-goal-reminder
? Description A simple helpful robot for your Company
? Bot adapter slack
   create bin/hubot
   create bin/hubot.cmd
   create Procfile
   create README.md
   create external-scripts.json
   create hubot-scripts.json
   create .gitignore
   create package.json
   create scripts/example.coffee
   create .editorconfig

動作確認

$ ./bin/hubot

daily-goal-reminder> daily-goal-reminder ping
daily-goal-reminder> PONG
daily-goal-reminder>

Slack側の準備

  • 以下のURLからHubotを登録します
  • HubotはSlackと連携できるアプリの1つです

https://my.slack.com/services/new/hubot

アイコンを設定する

  • 好きなアイコンを設定したりできます

f:id:masaru_furuya:20171020231722p:plain

Hubot側の準備

$ export HUBOT_SLACK_TOKEN=[設定画面に記述されたAPIトークン]
$ ./bin/hubot --adapter slack

動作確認

  • ローカルのPCでhubotを起動した状態でSlackにボットを招待して話しかけると返信してくれる

f:id:masaru_furuya:20171020232421p:plain

Herokuとの連携

  • Herokuでbot用のアプリを作る

Heroku用のCLIをインストール

$ brew install heroku/brew/heroku

Herokuにログイン

$ heroku login

Herokuにプッシュ

$ git init
$ git add .
$ git commit -m 'first commit'
$ heroku git:remote -a [アプリ名]
$ git push heroku master

console.error(`a bug known to break npm. Please update to at leastエラーがでる

  • package-lock.jsonが依存関係で悪さをしているぽい
  • 名前を変更してプッシュしたら通った

Herokuの環境変数にSlackトークンを登録

$ heroku config:add HUBOT_SLACK_TOKEN=[APIトークン]

ここまででHeroku上でHubotが動くようになっている

Herokuの起動設定を行う

定期的にpingしてsleep防止

Herokuのfreeプランは30分以上アクセスがないとスリープするので、 NewRelicのアドオンを入れて定期的にpingします。

qiita.com

Process Schedulerのインストール

さらにfreeプランでは1日6時間は必ずスリープさせないといけません。 そのため使わない時間帯はスリープさせるようにします。FreeプランでOKです。

f:id:masaru_furuya:20171021071010p:plain

Overviewからアドオンをクリックします。

f:id:masaru_furuya:20171021071219p:plain

APIキーを求められるのでManage Accountからコピーします。

スリープさせても良い時間のwebのdyno数を0に設定します。 選択したい範囲をドラッグすると一括で設定ができます。

f:id:masaru_furuya:20171021072418p:plain

Herokuのタイムゾーンを東京にする

Herokuのデフォルトタイムゾーン協定世界時(UTC)です。

heroku run bash
$ date
Fri Oct 20 XXXX UTC 2017

アドオンを使う時にタイムゾーンがずれていると困るので、東京に設定します。 環境変数にTZを追加すると上書きされます。

今日の1%

毎日通知する系のBotはHubotで作るのが楽。 でも毎回設定するたびに手順を調べ直していたので今回手順をまとめました。

アジャイル・スクラム開発とは?

スクラム開発の要素

  • プロダクトの要望を優先順位ごとに並べかえ、その順に機能を作る
  • 固定の短い期間(1〜4週間程度)の間隔で開発を区切り、その中で計画を立てる
  • プロジェクトの状況や進め方に問題がないか、メンバー同士で毎日確認し合う
  • 作っている機能が正しいかどうか、定期的に確認の場を設ける

メリット

  • 早めに軌道修正できる
  • 短い期間ごとに開発を区切りその単位で計画を立てていくため作業の工数見積が比較的正確になる
  • 短い期間で最大限の成果をあげる

役割

  • プロダクトオーナー

    • プロダクトの責任者
    • 投資利益(return on investment: ROI)を最大化することに責任を持つ
    • プロダクトに必要な機能を見極め、優先順位順にリストアップし次のスプリントで何をするかを決める
  • スクラムマスター

    • プロジェクトを円滑に進めるための調整役
    • スクラムを説明し効果的な実践を促す
    • 開発メンバーを守ったりして負荷がかかりすぎないようにする
    • 開発メンバーとの兼任の場合もあるが、プロダクトオーナーとは役割が全く違うので兼任はしてはいけない
  • 開発メンバー
    • 実際に開発をするメンバー

スプリントの流れ

  • プロダクトバックログを作る

    • 最初のスプリント開始前に用意する
    • 顧客目線での機能リスト
    • Trelloやホワイトボードやスプレッドシート等に顧客と話し合いながら優先順位をFIXさせる
  • スプリントプランニングミーティング

    • スプリント内で何を作るのか、どれくらい作るのかを決定する
    • スプリント(1-2週間が一般的)内に優先順位順にバックログから棚卸ししたタスクをタスク管理ツールに入れる
    • ツールはTrello, Zenhub等
  • デイリースクラム

    • チームの状況を共有するためのミーティング
    • 毎日5-15分程度の時間で昨日やったことや今日やること、そして行っている問題などを報告する
  • スプリントレビュー

    • スプリントの最終日にはプロダクトオーナーが成果物を確認する場を設ける。必ず動くアプリケーションを使って確認することが重要
  • スプリントレトロスペクティブ(振り返り)

    • スプリントの良かった点、改善すぺき点、そしてその要因と改善策などを各メンバーで議論しあい、次回のスプリントで活かす

今日の1%

プロダクトバックログの優先順位決め➔スプリント毎のタスク決め➔レビュー➔振り返りのサイクルを回すことで、短いサイクルで顧客のフィードバックを受けて本当に必要とされるものを作っていくのがスクラム開発。この全体像を理解していると、クライアントを導きやすい。

仕事が任されやすくなるために毎日意識すべきこと

前提編

良い仕事は良い人間関係から。

明るい挨拶を必ずする

職場で出会った人には必ず挨拶をする。素知らぬ顔をしないこと。 無視された人のことは必ず相手は覚えてます。そして無視するたびにあなたに対する親密度が下がります。

苦手だと感じる人ほど自分から話しかけるように心がける

働いていると、苦手だと感じる人が必ず出てきます。

でも自分で苦手意識を相手に持っていると相手もそれを感じ取って、壁を作られてしまいます。 これを繰り返していると非常に気まずくなりますね。

なので自分からこの人のことが好きだ!と思って話しかけることが大事ですね。

心がけ編

仕事のミスは自分でリカバリーする

自分で犯したミスは自分でリカバリーするという前提で考えること。 必要に応じて人の力を借りるのは大切ですが、あくまで自分が責任を持つと決めることが大事ですね。

仕事に対する労を惜しまない

仕事を頼まれた時にイヤイヤにやらずに、喜んで取り組むこと。 とはいえ、余裕がない時に人から仕事を頼まれると嫌な顔をしてしまいがちなので、 人から仕事を頼まれても大丈夫なようにタスクの予定を立てる時にバッファを設けると良いですね。

周りのために動く

自分にとって利益になるかどうか?ではなく、人やチームのためになることに積極的に動くこと。 人は人のことをよく見てます。自分のためだけにしか動かない人を人は信頼しません。 常にチームや組織にとって利益になるかどうかを判断軸に考えるようにしましょう。

他人を頼る

面倒くさい仕事ではなく、重要な仕事を他人に任せて信頼感を与えること。 自分の担当している仕事を分解して、人に頼めるものがないか?を考えましょう。 自分以外の人でも頼める仕事は積極的に頼っていきましょう。

有言実行する

自分で言ったことは最後まで責任を持ってやり抜くこと。 有言実行することが当たり前になると、どんどん物事が前に進んでいきます。

実践編

期限は厳守が基本

仕事は期限を守ることによって、初めて価値が生まれます。 期限を守ることは当たり前という意識を持ちましょう。

前例を探す

期限を守るためには全て自分ではやらずに、前例を上手く使いスピードアップを意識しましょう。

確認、連絡、報告 (かくれんほう)を行う

自分で情報をあつめ、やり方を上司に提案し、OKをとったら着手しましょう。 そして困ったら即連絡し、解消して仕事を進めましょう。そして完了したら必ず報告し、次の仕事に取り掛かりましょう。

上司の指示を待つのではなく、自分で提案して進めていくプロアクティブな仕事を心がけましょう。

イベントに積極的に参加する

一緒に働いているメンバーとの仕事以外の交流に積極的に参加しましょう。 普段は話せないことが沢山話せて仕事がより円滑になります。

出来たら自分がイベントを企画すると、より多くの人と仲良くなれます。

常に全体の目標を意識する

組織としての全体の目標を常に意識して今自分が何をするべきかを考えて仕事をしましょう。

自分に自信を持てる要素を増やす

自分に自信がある人は意見を堂々と発言することが出来ます。 そのため、自分に自信がない人は自信がない要素を出来る限り無くせるように努力しましょう。 筋トレするとか、ファッションセンスを磨くとか色々人によってやるべきことはあるはずです。

人の悪口を言わない

人の悪口を言う人は人からの評価が自然と下がります。人の悪口を言っている暇があったら、 自分で何とかしようという意識を持ちましょう。

一緒に働く人に関して情報収集する

一緒に働くメンバーのことをよく知っていると、コミュニケーションも捗ります。 何に興味関心があって、何を大切にしているのかを深く知るようにしましょう。

今日の1%

人に頼られる人というのは、生まれ持った才能ではなく毎日の信頼の積み重ねが出来ている人。 集団に貢献しつつ、自分の仕事はきっちりこなすそんな人を目指す。

価値の高い人材とは経営者目線で必要なことを考え、実行できる人

日本全国で400万近い会社がある中で「なぜ自分たちの会社が必要なのか?」を考えることはとても有益だと思います。 自分たちの存在価値は何か?誰に何の価値を提供するのか?これが見えていれば自分たちがやるべき仕事も見えてくると思います。

経営者目線で考えるとは

上記で挙げた自分たちの会社の存在意義は経営者層が本来考えるべき内容です。 経営者は常に考えを巡らせているはずですが、多忙なので出来ないことがとても多いはずです。

そこで現場の人間が積極的に考え動いてくれれば大助かりです。 結果価値が非常に高く評価されるようになるでしょう。

求められること➔自分がコミットできることの順番で考える

会社で仕事をする時、自分が得意なことや好きなことから考えてしまいがちですが まず会社に求められていることから考えるようにしましょう。

そして、その求められることも経営レベル➔部署レベルとブレイクダウンしながら考えられるとなお良いと思います。 次に求められることが見えてきたら、自分がコミットできることを決めてそれを仕事にします。

ここで重要なのはこのプロセスを自分一人で考えず、経営陣や上司と一緒に話して決めるということです。

会社を選ぶ時は

転職などで会社を選ぶ時は、その会社が何の価値を社会に提供していて将来どんな世の中にしていきたいのかを重点的に見るようにしましょう。そこが共感できて、自分がその会社で具体的にどんな仕事をして貢献できるのかが見えていれば、それは幸せな転職になると思います。

今日の1%

  • 価値が高い人材とは、自分たちが社会に提供する価値を認識し、そのために具体的な貢献が出来る人
  • 価値認識➔自分の役割がイメージできていない状態で会社を決めてはいけない
  • 自分で考えるだけじゃなく、経営層の人間と密にコミュニケーションをとって仕事をしていくのが大事

ソフトウェアエンジニアが価値を出すためには毎日どうやって過ごせばよいのか?

f:id:masaru_furuya:20170921201744j:plain

最近仕事をいかに楽しむか?をテーマに色々考えてます。もうかれこれ6年近くエンジニアをしてきているので、ただコードを書くことだけに楽しさを感じられなくなってきたんですよ。

特にフリーランスをやっていると、基本的には手離れの良い作業系の仕事が任されることが多いので自分で仕事を楽しくする工夫を考えるのは必須だと思ってます。

楽しい = 価値を出しているという仮説

価値を出すためには、言われたことだけやってるだけじゃダメなんですよね。それならコードを自動で書いてくれる機械でもあったら、それでいい。

顧客に価値を出すために自分からガツガツ行動しないといけない。 自分で主体的に考えて行動するってこと自体、やりがいがあって楽しいんですよね。

だから結果的に楽しい = 価値を出している状態なんだと思ってます。

そもそも価値って何?

ではそもそも価値って何でしょうか?

自分は価値とは何かの課題を解決することと定義しています。

また価値の種類にはプロフィットコストの二つがあります。 利益を生むものと、時間・費用といったコストを削減するものです。

セールスの新規顧客獲得はプロフィット面の価値、エンジニアの業務効率化ツールの開発はコスト面の価値と言い換えることが出来ます。

価値を出すとは?

価値を出すとは、自分ではなく他人の課題を解決することです。

自分の場合は価値を感じると表現しますよね? それは人やサービスに価値を出してもらった結果というわけです。

なので、価値を出すには相手の課題解決がありきだという前提があります。

ここが理解できておらず、自分は何でこんなに頑張っているのに評価が低いんだ…と嘆いている人は他人の課題をどれだけ解決して価値を出しているのかを省みた方がいいです。

まあ自分も人のこと偉そうに言えないから、この記事を書いて自念しているのですが笑

価値の総量を意識する

価値の総量 = 頻度 ✖️ 大きさ

その人が出している価値には総量があって積み重なっていくものだと思います。 言い換えると信頼残高と言えるかもしれません。

例えば新入社員やインターンが雑務を任されるのは、この頻度を増やすためです。

新人がいきなり大きな価値を生むことは出来ないので、いろんな人の小さな課題解決を積み重ねていくことで価値の総量を増やしていくというわけです。

価値の頻度を高めるには?

ここがエンジニアにとって重要だと思ってます。何故ならエンジニアの仕事はすぐに価値を出せる性質のものじゃないからです。

開発に1か月、成果測定に1か月…と結果が出るまで数ヶ月かかることも珍しくありません。なので、日頃の細かいことで価値を出していくのが大事なのだと思います。

例えば、

  • 開発スピードを上げて、1日に何個も重要なタスクのプルリクエストを出す

  • ミーティングでは事前に内容を把握し着地点を考えておきそのためのファシリテーションを行う

  • 開発メンバーで困っている人がいたら積極的にフォローする

  • 職場の近くの美味しいお店をサーチしてメンバーに共有する

  • 飲み会を企画して他チームとのコミュニケーションの場を作る

  • 他チームに課題ヒアリングしてすぐに解決できることは対応する

とかetc

開発に限らず、複数アイデアは考えられると思います。 自分は現在進行形でここは課題に感じている所なので、改善していこうと思っています。

価値の大きさを高めるには?

価値の大きさを高めることは以下の2つの方向性に分類できると思っています。

  1. 自分で仕事の価値の大きさを高める

  2. 価値の頻度を高め、価値が大きい仕事を任せてもらいやすい状況を作る

1は一見つまらなそうな仕事でもその背景を知り、価値を出すために能動的に行動していくことです。開発の仕事でもこの開発はどんな価値を提供するのか?を常に意識するのは重要なのと同じです。

そして長期的に見て非常に効果が高いのは2です。価値の頻度を高める過程で自分を評価してくれる人は必然的に増えるので、結果的に大きい仕事を任せてもらいやすくなります。

今日の1%

自分で価値を高めること以上に価値を出す頻度を増やすことが重要。 そのために開発以外の領域でも幅広く価値を出して、大きな仕事のチャンスを得られるようにする。

Webアプリ開発プロジェクトの開発開始までに行う5つのステップ

1. 企画書を作成する

プロジェクトの目的と何をするか?を説明する資料

一人で企画を考える場合とチームで考える場合だと、 やり方が全く異なるので、企画段階の話は別記事でまとめたいと思う。

2. ワイヤフレームを作成する

企画書でやることが決まったら、次は画面一覧と各画面に表示する項目と用途を記載する。

画面が決まっていないと開発は進めようがないので、 開発の前にここは必ず決めておかないといけない。

メンバー全員でホワイトボードに図を書きながら書くような場合もあるし、 PMがスプレッドシート等で作成して揉んでいくような進め方になると思う。

3. 工程を細分化する

ワイヤフレームが決まったら作るものは大体決まるので、次は工程を細分化する。 Webアプリの開発だと大体、要件定義、共通設計、デザイン、コーディング、JavaScript、サーバーサイド、テスト、フィードバック修正の流れになるかなと思う。

工程に分けたら、それぞれの工程で漏れが無いようにタスクを分割していく。 これをスプレッドシートに記入して一度チームメンバーに一つずつ共有していく。

懸念事項なども記入したら、これをイシューかチケットに登録して 今後のコミュニケーションを出来る場所を用意する。

4. マイルストーンを決める

工程を細分化しても、そのままだと各担当のタスク量が多すぎて、ざっくりとした見積もりしか立てられない。 なので各画面/機能毎にいつまでに作るか、全体の大まかなマイルストーンを最初に決める。

これによってメンバーもタスクの優先順位が立てられやすくなる。

ここのマイルストーンの立て方がアジャイルウォーターフォールだと違うのかなぁと思っているので、調べて別の記事にしたい。

5. 見積もりを立てる

マイルストーンが決まったら担当者で見積もりを立てる。厳しそうだったら相談してもらう。

今日の1%

  • 1エンジニアやデザイナーとしてプロジェクトにジョインした時も、 プロジェクトマネージャーの視点を持って仕事をすることによって、スピードも質も向上させることが出来る