patorashのブログ

方向性はまだない

1年間の育児休暇に入りました

育児

先日、次男が産まれました。産まれてからお知らせしようと思っていましたので、ご報告します。

今回私は、株式会社リゾームで男性初の育児休暇を取得しました。子供が2人になり、妻一人で同時に2歳児と新生児の相手は難しいだろうということで、育児休暇を取りたいという相談を会社でしてみたところ、OKをいただけました。

自分の中では、自宅でのリモートワークも検討したのですが、新生児が産まれたばかりの慌ただしい中でフルタイムのリモートワークは厳しいんじゃないかと考えました。そして、会社の制度として育児休暇があるので、男性でも育児休暇を取っても大丈夫ということを確認したかったというのもあります。総務の方や開発部の部長・リーダーと相談しながら、できる範囲の仕事量に抑えていけばいいんじゃないか？ということになり、育児休暇に入ることになりました。

育児休暇といっても、完全に1年間休みというわけではないようにしました（これは自分からの提案で）。完全に現場を離れて感覚がわからなくなっても困るので、余裕のある時に自宅からのリモートワーク、もしくは職場で仕事を時短勤務で行うようにしています（実際にはまだ運用してないですが）。

ハローワークから育児休業給付を受け取るようにするので、月ごとに最高でも50%(80時間)までしか働いてはダメなので、それを超過しないように働くことになっています。こう書くと勘ぐる方は50%ギリギリまで働きそうな想像をしそうですが、実際のところは、50%も働かないように調整することになっています（あくまでも休暇なので）。

弊社は働きやすい職場環境・制度作りにちゃんと取り組んでくれています。有給休暇も取得しやすいですし、それぞれの家庭の状況に合わせた勤務体系も可能なので、非常に助かっています。今回の育児休暇取得に関して相談したときも、こちらが疑問に思っているであろうことに関して、事前にわかりやすい資料をまとめていただきました（実際に受け取る給付金がどれくらいになるか等）。

リゾームでは一緒に働いてくれる仲間を募集しておりますので、もし岡山で働きやすい職場を探しているプログラマーの方がいらっしゃいましたら、弊社も是非検討してみてください。ご興味のある方は私のほうまでご連絡ください。ちなみに私の所属するチームはRuby(Rails)での開発ですが、他のチームではJavaやC#での開発を行っています。

www.rhizome-e.com

最後に

出産お祝いのウィッシュリストです。もしよろしければよろしくお願いします。

https://www.amazon.co.jp/hz/wishlist/ls/2G5R2ALFUU96G

頭で考える前にやってみた人がうまくいくを読んだ

読書

これも年始にブックオフで買ってきた本である。

頭で考える前にやってみた人がうまくいく

頭で考える前にやってみた人がうまくいく

ユダヤ人も華僑も凌駕する「ジュガール」の法則とあったのだが、ジュガールって何？と思って気になったので読んでみた。ジュガールとはインドの考え方で、シンプルな方法で最大限の成果を出すための心得みたいな感じだった。「なんだ、そんなことか」と思ってしまうようなことだが、視点の切り替えで最も早く効果の高い方法を出すことができた例が多かった。しかし、これがなかなかに難しい。その理由は日本人の「恥」とか「プライド」によってそういう視点に対する躊躇を生んでしまうからだった。

日本人の美徳が日本人を貶めている

この本にはよく書かれているが、日本人の美徳が日本人を貶めているという。恥ずかしがったり、譲ったり、すぐに謝ったり、遠慮したりなど。それが円滑に回るための文化というのはわかるけれど、それをビジネス、特にグローバルなビジネスに持ち込むと何もできなくなってしまうということだった。

基本的には恥とプライドを捨てろという話

日本の文化もあるので、恥とプライドを捨てて生活すると嫌な人になる可能性が高いので、プライベートとビジネスで切り替えてビジネスモードでは図々しいくらいになって行動したほうがよいという感じ。

言い訳しているうちは成功できない

嫌われたらどうしようとか、失敗したらどうしようという気持ちが働き、勝手に「相手の迷惑になるから」という言い訳を作り出して行動しなければ、何も起こらない。これはわかってはいるのだが、人見知りだとついつい考えてしまう。特に相手が著名人だとなおさらそうなってしまう。とりあえず声をかけていくということができればいいのだが、場慣れしていくしかないかなと思う。

ポジティブにもっていく思考法

印僑は不安を考えないというだけあって、不安を払拭するステップの紹介や、物事の進め方の順序の話など、日頃おそろかにしている部分の話が紹介されていた。プロジェクトの進め方についても、ストーリーを作る際に逆算して作るなど、自然な導入の作り方が紹介されていた。

また、身だしなみを整えて印象をよくすることの重要性など、すぐできることに関しても書かれていた。話すことよりも印象が大事というのは、確かにそうだなと思う。印象がよければ次に繋がることもある。いいことを話していても、嫌な人だったりすると素直に受け入れられないこともある。印象で言葉の重さも変わるのだ。

戦略的に行動する

すぐに行動するとあったが、闇雲に行動するのは非効率である。戦略を練り、それにしたがって行動に移すことで効率的に成果が出せるようになる。やはり大事なのは戦略・戦術であるなぁと思った。

気づき

自分が想像していた本とは結構違う内容だったけれど、発見は多かった。 インドの人目線の本は初めて読んだと思うのだが、

  1. 人の縁に乗っかれ
  2. 言い訳する前に行動しろ
  3. 考える前にやってみろと言ったが、戦略的に行動しろ

という感じだった。

「（言い訳を）考える前に行動しろ」であり、「戦略を考えてから行動しろ」という内容だった。もしかしたら、戦略を考えるということ自体が行動なのかなという気もする。戦略大事！！

これだけ！PDCAを読んで、なぜ自分たちのPDCAがうまく回らないのか理解できた

読書

これだけ! PDCA

これだけ! PDCA

これだけ！KPTを以前に読んだことがあったので、これだけ！PDCAも読んでみたかったところ、ブックオフに売ってあったので買ってみた。

なぜPDで終わってしまうのか？

現場でよくあるのは、PDで終わってしまい、CAにたどり着けないパターンである。この本でも冒頭でそのことに触れてある。なんでそうなるのか？それは、計画が計画になっていないからであるということだった。

偽物の計画

計画は本来、

  • 何を
  • 誰が
  • いつまでに
  • どうやって

実行するのかが明記されていなければならない。 ところが、計画らしきものには、

  • 何を
  • いつまでに

しか存在せず、誰がどうやって実行するのかがほとんど明記されていない。

つまり行動レベルにまで計画が落とし込まれていないため、行動できない。しかし、それっぽいものになっているので、その計画にはとりあえず満足してしまう。これこそが、自分たちのPDCAがうまく回らない原因だなぁ〜！と納得した。何か目標を立てたりした場合でも、いつまでに何をするはよく考えるのだが、だいたい計画倒れで終わっていた。これも、どうやってまでを考えずにやっていたせいじゃないかと思う。

それでも仕事は回る

悲しいことに、その計画らしきものでも、とりあえず仕事や家事は回ってしまう。しかし、それでは成長は見込めない。

評価制度と現場の乖離

成果主義になり、決めた目標の達成率を見られるようになったとき、目標を達成できていなかったら評価が下げられてしまうため、簡単な目標ばかりを設定するようになってしまう。また、効果が出るまでに長い時間のかかるものへの挑戦が減ってしまう。長い目で物事に投資することができなくなってしまい、成長度が低下していく。

全ての目標は目的に向かっていくためにクリアすべきこと

目的を見失ってはならない

目的を見失ってしまうと、手段の目的化に走ってしまう。本来は、会社のビジョンを達成するための目標として、Aに取り組むという視点なのに、気づいたらAに取り組むことが目的化してしまい、会社のビジョンを達成するためであるということが忘れられてしまう。なぜ、がわからなくなるので、Aに取り組むための意義が見いだせなくなり、意味がなくなったり、義務感で行うようになったりしてしまう。

本の中では、日報の記入が例としてあげられていたが、本当にあるあるだなーと思った。私も日報によって何に取り組んでいたか、どこでハマってたか、何に悩んでいるかなどの共有は価値があると思うのでやるべきだと思うのだけれど、目的の共有化ができていないと、ただの面倒臭い作業になってしまうだろうと思う。

PDCAは、まずCから始める

これは確かに！と思わされたのだが、まずは現状把握である。身の丈にあった計画づくりから入らないと、絵に描いた餅になってしまう。

通常業務がある前提で計画を立てる

どんなに立派な計画が出来上がったとしても、日々の業務は存在しており、それはちゃんとこなさなければならない。そしてギリギリの人数で業務に取り組んでいるところがほとんどだと思うので、まずは現状の振り返りから始めることが大事である。

事実を正しく捉える

人は問題になっていることを表層的に捉える癖があり、すぐに解決策を考えてしまうのだけれど、それでは根本的な原因を解決することができない。なぜ、なぜ、なぜ…と掘り下げて正しい事実認識ができるようになろう。

改善はスピード感が重要

問題を発見した場合は、早い段階で改善・処置をすれば、それだけ効果が出やすい。結果を厳しく受け止め、早いタイミングで修正していくことが大事。

目標にぴったりのKPIを見つける

問題を発見するには、KPI（重要業績評価指標）が大事で、それを設定していなければ問題にすぐ気付くことができない。改善はスピード感が重要なので、気づけなければ致命的なことになってしまう。逆にいえば、KPIがあれば振り返りが簡単になる。

成果に繋がるKPIでなければ負担が増えるだけ

安易に「これをKPIとする」とやってしまうと、効果的な振り返りが行えない。その数字を追いかけ続けなければならないという負担が発生するので、KPIは考えに考え抜いて、成果に繋がるものにしなければならない。

改善を妨げる「しがらみ」

しがらみには、以下の4つがあると著者は書いている。

  • 評価制度によるしがらみ
    • 情報共有をすると評価に不利になるパターンが存在したりするもの。
  • 組織構造によるしがらみ
    • 縦割による断絶や責任の押し付け合い
  • 習慣によるしがらみ
    • マニュアル化されている悪習に気づかない
  • 考え方によるしがらみ
    • うちの業界は特殊という決めつけなど

しがらみを打破するために

しがらみを打破するためには、関係者を巻き込んで会議を行い、目的・目標を共有することが大事であると書いてあった。かといって闇雲に会議を開いても、大勢の時間を消費する会議であるので、効果的な会議を行わなければもったいない。

本書でも大切なのは会議の目的であると書いてある。あれこれ詰め込み過ぎず、目的を決めて議論を尽くさなければ人は動かない。

PDCAでチームの基礎力を上げていく

本の中では、野球チームの話で語られていたが、当たり前のことのレベルを上げていくことが重要であるとあった。難しいことを当たり前だと思うレベルまで高めることができれば、強いチームになる。リーダーにはそこにこだわってもらいたいということだった。

気づき

するすると読むことができて、PDCAの肝部分はよくわかったのだが、タイトル通りの「これだけ！」というのが、これだけ？？？（いや多くね？）という意味でちょっとなぁ〜という感じはあった。PDCAというとついついPから入ろうとしてしまうのだけれど、まずCからというのは説得力があった。目的地の載った地図があっても自分の位置がわからなければ意味がないという話があったかと思う。

個人的にも時間をかけるのが面倒臭くなって「計画らしきもの」で終わっていることがたくさんあったので、ちゃんとした計画にまで落とし込んで、PDCAサイクルを回していけるようにしていきたいと思った。

これだけ! PDCA

これだけ! PDCA

DartのバージョンマネージャーDVMを入れてみた

Dart

Rubyのrvm, rbenvみたいにDartのバージョンマネージャーはないのかな？と探してみたところ、dvmがヒットしました。 dvmはpubパッケージとして公開されているので、dartのインストールが行われていないと使えません。

pub.dartlang.org

dvmのインストール

dartはすでにインストールされている前提で話を進めます。以下のコマンドを入力します。

$ pub global activate dvm

これで終わりです。一応、dvm helpを実行してみましょう。

$ dvm help
Manage multiple active Dart versions.

Usage: dvm <command> [arguments]

Global options:
-h, --help       Print this usage information.
-v, --version    Print out the latest released version of dvm.
-p, --path       Installation directory for the Dart SDK.
                 (defaults to "/Users/toyoaki/.dvm")

Available commands:
  help      Display help information for dvm.
  install   Download and install a <version/channel>.
  switch    Switches the `current` directory to <version/channel>.

Run "dvm help <command>" for more information about a command.

入ってます。

複数のバージョンのdartのインストール

とりあえず複数バージョンのdartを入れてみましょう。バージョン情報は以下のページから見れます。

www.dartlang.org

dvm自体にはまだバージョン一覧を取得する方法がなさそうです。

$ dvm install 1.24.3

終わったら、続けて違うバージョンを入れてみます。

$ dvm install 1.25.0-dev.16.4

とりあえずダウンロードは終わった模様です。

dvmのdartが使われない

1.25.0-dev.16.4を使うように指定してから、バージョンを表示してみました。

$ dvm switch 1.25.0-dev.16.4
INFO: Switching to dev/1.25.0-dev.16.4...
INFO: Done as "/Users/patorash/.dvm/current/dart-sdk".
$ dart --version
Dart VM version: 1.24.3 (Wed Dec 13 23:26:59 2017) on "macos_x64"

どうも使われてない模様…。dartのパスを調べます。

 $ which dart
/usr/local/bin/dart

dartのパスをホームディレクトリ以下の.dvm/current/dart-sdk/binに変更しないといけません。

homebrewのdartを削除

まぁいつでも入れ直せるだろうと思ってザクッと削除しました。

$ brew remove dart

その後、PATHに追加します。.bash_profileなりに入れましょう。

export PATH="/Users/patorash/.dvm/current/dart-sdk/bin:$PATH"

その後、source .bash_profileするか、ターミナルの再起動をするかをします。

これでdartへのパスが通ったかと思いきや、実行権限がなくて認識してませんでしたので実行権限を付与します。

$ chmod +x ~/.dvm/current/dart-sdk/bin/*

この後、dart --versionを実行してみましょう。

$ dart --version
Dart VM version: 1.25.0-dev.16.4 (Wed Sep 13 01:47:12 2017) on "macos_x64"

変わってます！では、また違うバージョンにしてからバージョン確認してみましょう。

$ dvm switch 1.24.3
Wrong script snapshot version, expected '47f19879b9cac7de1b33e7b7ea414c7a' found '3b70e6793a0fce902401bb759bc9762b'
INFO: Switching to stable/1.24.3...
INFO: Done as "/Users/toyoaki/.dvm/current/dart-sdk".
$ dart --version
Dart VM version: 1.24.3 (Wed Dec 13 23:26:59 2017) on "macos_x64"

ちゃんと1.24.3に変更できました。

まだ入れただけで実際にこれで開発をしたことがあるわけではないのですが、ひとまずはこれを使ってみようと思います。

2017年を振り返ってみる

日記

今年ももうすぐ終わるので、色々と振り返りをしてみようと思います。

仕事面

仕事は、

  • 営業の方とかサポートの方とはRedMineで課題を管理
  • 普段は基本的にChatworkで意見交換
  • 定例会でお客さんからのフィードバックをもらい、RedMineにチケットを書いて優先順位を決める

というやり方がずいぶん浸透してきたなというところです。どこもそうなのかもと思いますが、課題をすぐにExcelで管理したがるので、RedMineを使いましょうというのを口酸っぱくChatworkにも書いていたと思います（Chatworkに書かれた内容をRedMineのチケットに私が転記したりもした）。

私の担当しているサービスももう4年になるので、規模もそこそこ大きくなり、新しい技術を導入しづらくなったので流行している技術を試すのが難しくなっています。まぁこれは別に悪いことではないのですが、流行のキャッチアップができていないんじゃないかという焦燥感を感じることはあります。かといって、改善点がなくなったということはなく、日々サービスの改善に努めています。

主に今年やったことは、

とまぁ、書ける範囲だとこのくらいでしょうか。 特に、Elasticsearchのバージョンアップはずっと心に引っかかっていたのをようやくアップグレードできたので、終わったときはかなり嬉しかったです。

個人面

体重が圧倒的成長をしているので、そろそろ減量しないとなぁ…とは思っています。

そういえば、ももっこカード検索というWebサービスを作ってリリースしていました。岡山県のももっこカードという子育て家庭応援カードで、協賛店で掲示すると割引などのサービスが受けられるのですが、そのお店がどこにあるのかなかなかわからないので、自分のいるところから近いお店を探せたらいいなということで作っていたのでした。でも自分でも最近全く利用してないです。ただ、お店によってはすごく割引受けられるので、おすすめです。

新たな技術の習得として、Dartをやろうとしているのですが、まだまだ中途半端なので、Dartで何かアプリなり作ることを目標にしていきたいと思います。

すぐに興味が移ってしまい、成す前にやめてしまうことが多いので、個人的にもちゃんとタスク管理を行っていきたいなと思います。

来年やりたいこと

仕事

  • マテビューを効果的に使って高速化する
  • キャッシュの活用法に詳しくなる
  • 社内向けにREST APIを整備する
  • プレゼンしたアイデアのプロトタイプを作る

個人

  • DartでWebサービスを作る
  • postgresqlの資格を取る
  • 自分に何かあったとき用のドキュメント作成
  • 家のデスク周りの整備
  • ウッドデッキが欲しい
  • 英語の本を苦労なく読めるくらいになる

DartでFullscreen APIを実行する

Dart

Dartでhtml5のFullscreen APIを実行したいと思ったのですが、メソッドがあるにも関わらず、どうにも動きませんでした。

import 'dart:html' as dom;

main() {
  var canvas = dom.querySelector('#canvas--fullscreen');
  canvas.requestFullscreen(); // 動かない！
}

ベンダープレフィックスが必要

html5のFullscreen APIは、まだベンダープレフィックス(webkitとかmsとか)が必要な状態で、JavaScriptであっても単純には呼べないようです。JavaScriptだと、webkitRequestFullscreenとかのメソッドがあるのですが、Dartのdart:htmlパッケージには1つしかありません（requestFullscreenのみ）。

DartからJavaScriptのメソッドを呼び出す

リフレクションのような形になりますが、dart:jsパッケージを使って、ElementをJsObjectに変換し、callMethodメソッドを使ってベンダープレフィックスのついているメソッドを呼び出すようです。

import 'dart:html' as dom;
import 'dart:js';

/// フルスクリーンで表示します。
/// 
/// [element]のFullscreen APIを呼び出します。
/// [参考URL](https://stackoverflow.com/questions/29714889/how-to-request-fullscreen-in-compiled-dart)
void fullscreenWorkaround(dom.Element element) {
  var elem = new JsObject.fromBrowserObject(element);
  if (elem.hasProperty("requestFullscreen")) {
    elem.callMethod("requestFullscreen");
  } else {
    List<String> vendors = ['moz', 'webkit', 'ms', 'o'];
    for (String vendor in vendors) {
      String vendorFullscreen = "${vendor}RequestFullscreen";
      if (vendor == 'moz') {
        vendorFullscreen = "${vendor}RequestFullScreen";
      }
      if (elem.hasProperty(vendorFullscreen)) {
        elem.callMethod(vendorFullscreen);
        return;
      }
    }
  }
}

main() {
  var canvas = dom.querySelector('#canvas--fullscreen');
  fullscreenWorkaround(canvas); // 動く！
}

このあたりの処理もrequestFullscreenメソッドに実装してくれて透過的に扱えたらいいのになぁと思いました。

List.forEachでasync, awaitしたいならFuture.forEachを使おう

Dart

これはDart Advent Calendar 2017の15日目の投稿です。

qiita.com

カレンダーがガラガラで寂しかったので、メモ書きですが、参加しました。

今コツコツとDartでちょっとしたゲームアプリを作ろうとしているのですが、1秒ごとに処理を行いたいと考えていました。もちろんDartなので非同期で。

1秒ごとに処理がされない

最初はこれでいけるんじゃないか？と思って書いてみました。

main() {
  List<Foo> foos = []
  for(int i = 0; i < 20; i++) {
    Foo foo = new Foo();
    // なんやかんやで…
    foos.add(foo);
  }

  foos.forEach((foo) async {
    await new Future.delayed(new Duration(seconds: 1));
    foo.bar();
  });
}

こうすると、1秒ごとに20秒まで処理が行われ…ずに、1秒後に20個分の処理結果がドンと表示されました。 よくよく見ると、たしかにそうなるわなぁ…と思います。

これで1秒ごとに処理できる！

for inを使えばできるが…

for inを使えば、処理はできましたが、forはなんかダサイ…。しかもその処理の関数にasyncつけないといけなくなるのでいただけない。

main() async { // 上の関数にasyncつけないといけない
  // foosを作る処理は省略
  for(foo in foos) {
    await new Future.delayed(new Duration(seconds: 1));
    foo.bar();
  }
}

Future.forEachを使おう

これが一番綺麗でわかりやすいです。イテレータが渡される関数にasyncをつけるだけでよいので見た目もいいですね。

main() { // 上の関数にasync必要なし！
  // foosを作る処理は省略
  Future.forEach(foos, (foo) async { // こちらにasyncをつける。
    await new Future.delayed(new Duration(seconds: 1));
    foo.bar();
  });
}
参考リンク

api.dartlang.org