「現場の車窓から:新入社員研修トレーナー・トレーニーの現場」で登壇してきました!!

2018年9月1日に開催された、DevLOVEさん主催の「現場の車窓から:新入社員研修トレーナー・トレーニーの現場」というイベントで登壇してきました!!

f:id:kumatira:20180903012230j:plain

イベントについて

このイベントは、新人研修を経て配属される中で悩みを抱えているトレーニー(新人)と、同じく研修をする中で悩みを抱えるトレーナーが、各々の現場のモヤモヤを持ち寄って話し合うというものです。

詳しい内容や他の登壇者の方についてはこちらを見てください。

devlove.doorkeeper.jp

自分の発表

私は「カイゼンの次は、文化の共有 ~新人からのお願い~」というタイトルで話してきました。入社、配属と新しいチームにジョインする機会が多かったこの半年ですが、その中で感じていたモヤモヤを整理し、トレーナーの皆さんへの提案という形で発表しました。

世の中のあらゆる組織にはそれぞれの内側だけで通じるコミュニケーションプロトコルのようなものがあると思います。効率性やチームビルディングの観点からそれ自体が悪いとは全く思いません(むしろそれが良いものならば、好んで使います)。

しかしそこに新たにメンバーとして入る人からみると、心理的な障壁になり得ます。ならばそれを明示的に示し、共有することが必要です。自分たちの文化を説明するのはなんとも気恥ずかしいですが、やってみると大きな効果を生むと思います。

詳しい内容はこちらのスライドをぜひご覧ください!!

補足

ちなみに今所属しているチームのメンバーは、ここに書いてあることを有形無形にたくさんやってくれています!! ここで述べたようなことを思ってくれる人がもっと増えれば、もっと楽しく働けるな〜と思った次第です。

新人も輪に入れて欲しい!!

スライドに書いた通り、ここでいう「文化の共有」は決して押し付けになってはいけません。既存のメンバーが話し合いながらその文化を作ったように、新人もその話し合いの輪に混ぜてもらい、さらなるカイゼンを進めるのが良いと思います。

考える力の育成はより本質的なところで

また見方によっては「新人の考える機会を奪っている」ようににも見えます。しかしすでにチームメンバーが心地よいコミュニケーションプロトコルがあるならば、それに乗らず0から新人が考えるというのも悪手でしょう。考える力は開発やビジネスなど、より本質的なところで発揮したいと思います。

登壇について

まとまらないので箇条書きで

  • うまくいってよかった!!40人近い人たちが自分の話を真剣に聞いてくれるのはやはり嬉しい。
  • でもう〜ん。むずい。もっと練習すればよかった、
  • 時計をみる余裕が無かった。途中で「あ、速すぎる・・・」となったが時すでに:osushi:。時間をうまく調整するは次のトライ。
  • 話の本筋自体はまあまあ説得的に作れた気がする。ただ話したいことが多すぎてちょっとぶれた部分もあった。もっとスライド作りに慣れればカイゼンするかな?
  • 最初にちょこっと冗談を入れると自分も会場もちょっと緩む。うん仕込んで行こう次からも。
  • Googleスライドめっちゃずれる・・・。次回からkeynoteの導入を検討中。

まとめ

今回の発表は、「自分がモヤモヤしていることを、『チームの課題として解決しませんか』という提案に持っていく」ことを目標にしていました。今後もこのスタンスで社内外に発信していけたら嬉しいですね。

登壇資料を上げた何気ないツイートが思ってたより拡散されました。

継続的にアウトプットするの大事。

ではおやすみなさい

Mackerel Meetup #12 Tokyo に行ってきた 講演メモ&感想

2018年8月2日に開催された「Mackerel Meetup #12 Tokyo」に行ってきました!!

f:id:kumatira:20180803010834j:plain

mackerelio.connpass.com

(講演メモは私の判断で一部を抜粋したものです。また聴きながらとった部分もありますので、乱筆ご容赦ください。)

全体の雑感

(細かい講演の内容に関する感想は後述)

  • 7月からの業務で初めて触り、「わからない部分が多いけど便利そう」と思っていたサービスだったので、会社アドレス宛に届いたメルマガでこのミートアップを知り即申し込んだ。
  • 今日までずっと「mac"h"erel」だと思っていた。。。今日のイベントでしっかり「mac"k"erel」と覚えた。
  • はてなの方は、他の社内エンジニアの方をはてなIDで呼んでいて面白い文化だなぁと感じた。
  • (正確に数えたわけではないが)参加者の9割方が男性だった。フロントエンドの勉強会などとは違った印象を受けた。
  • 1番目に登壇されていたPMの松木さんが話されていたミッション・ビジョン・バリューに沿ってmackerelが作られていて、またそれに共感するユーザーが使っているということを強く感じた。

講演

200週連続新機能リリースとこれから

Mackerel 株式会社はてな プロダクトマネージャー 松木さん

スライドはこちらから

  1. 自己紹介
  2. 200週連続リリース
    • 毎週リリースは継続するけど、毎週新機能はこだわらなくなる
  3. Mackerelのこれまで
    • 2014年 β公開、正式リリース
    • 2014/4 エイプリルフールとしてつけたカラーテーマ機能が今では色覚サポート機能に
    • 2016年 AWSインテグレーション・LINE Notify
    • 2017年 CRE創設、Mackerel サーバ監視[実践]入門」出版、アラートグループ機能
  4. ユーザーと共に作る
    • MackerelのOSSはいっぱい!!
    • クリティカルな機能が外部のコントリビューターからコミットされることも
    • github上は(日本人同士だけど英語の練習と思って)基本は英語でお願いします
  5. 今後どうなるのか
    • 2018年
      • アラートグループ機能
        • 「サービス・ロールの勝利」
      • コンテナ正式サポート
      • カスタムダッシュボードv2を開発中
      • 異常検知
    • これから
      • ミッション・ビジョン・バリュー(内容はスライド45ページから)にのっとって、進化を続けていきます
  6. 仲間も絶賛募集中

感想

  • リリースの歴史を追っていくうちに今、知っているmackerelが出来上がっていく感じがして面白かった。200週連続リリースは伊達じゃない(現在203週連続リリース中らしい)
  • エイプリルフール企画としてつけたカラーテーマ機能が、今では色覚サポート機能へ発展しているという話があった。最初は遊び要素でも、それもサービスに大事な要素になるという好例だった。「まず実装(やってみ)る」大事。
  • 知識のなさ故に新機能の説明をあまり理解できなかったが、カスタムダッシュボードは良さそうだと感じた。今でも十分見やすいけど・・・
  • mackerelのMMVを初めて知った。MMVと実際のサービスのお互いがしっかりと噛み合っていて、納得感があった。

機械学習を用いたMackerelの異常検知機能について

Mackerel 株式会社はてな アプリケーションエンジニア 吉田さん

  1. 自己紹介
  2. サーバー監視の困りごと
    • サーバー監視初心者の場合
      • クラウドが出てきて自分でサーバーを立てるようになった。
      • サーバー監視はわからない。
      • 本質的にはアプリケーションコードの開発に集中したい。
    • サーバー監視玄人の場合
      • インフラ周りの知識豊富。
      • 見なければならないサービスが多く、多忙。
    • 複数条件を考慮した障害の早期発見
      • 人間が複数のAND条件を網羅するのは困難
        • 「cpuの使用率は高くない」かつ「メモリ使用率が高い」とか
    • 機械学習を用いた異常検知が解決する課題
      • インフラ知識がなくても低コストで監視ルールが作りたい
      • 人間が列挙するのは困難な複数条件を考慮した監視がしたい
  3. 異常検知によるアラームの実例
    • 複数のメトリックからの複数条件に基づき、異常検知アラートが発報
    • 障害が起こる前に異常検知アラートが発報
      • 人間が設定した監視条件はそのとき発火していなかった
      • 原因になったメトリックをルールに設定することで、人間のドメイン知識と機械学習の組み合わせのサイクルに入れる。
  4. 異常検知とは
    • 代表的な問題設定→外れ値検知
  5. 異常検知のアリゴリズム
  6. サービス/ロールさえしっかりと設定されていれば使えるようになる。

感想

  • 機械学習?監視ツールと関係あるの?」と思っていたがめっちゃ関係あった。吉田さんの説明は門外漢でもとてもわかりやすかった。
  • インフラ周りは一種の職人技のように感じていた。職人技を機械学習によって誰にでも開放すれば、自分のようなインフラ初心者は大助かりになると共に、社会全体でもリソースの有効活用ができそう。
  • 「人間と機械学習の組み合わせで監視の質を向上する」という考え方が一貫していたのが印象的だった。人間が得意なことは人間が、人間が苦手なことは機械がやればいい。
  • アラートの質が向上するのはすごいと思ったが、実際の障害が起こる前の芽を見つけるのは「未来かよ」となった。(異常がないのが一番だけど)どんなパターンを異常として見つけてくれるのかちょっと楽しみでもある。

トレタのインフラ運用を支えるMackerel

株式会社トレタ インフラエンジニア 山田さん

  • 自己紹介
    • トレタの全サービスのインフラエンジニア
    • 飲食店向けの顧客管理台帳などがサービス
  • 運用環境
    • IaCで進めている
    • Blue-Green Deployment
    • immutable
    • アラートモニタリングはMackrelに集約している
    • ビルドから監視開始も自動化
      • mackerelのnameをわかりやすい名前に変更している。デフォではプライベートIPがわかるだけだが、サーバーの属性やパブリックIPも付与して、障害対応時に少しでも手数を減らしている。
      • 監視状態の監視
    • 今後は「リソースが過剰だよ」というのをMackerelで検知したい
  • 最近使い始めた
    • ダッシュボードのグラフがあることで、営業さんともグラフを見て話せるようになる
      • 超人気店のスパイクなどを見てお店とコミュニケーションが図れる
  • 期待
    • vuls
  • 最後に
    • エンジニアを募集しています

感想

  • よその会社さんのインフラ構成をちゃんと聞くのは初めてだった。業務で携わって1ヶ月だが少しわかる単語が出てきて嬉しい。
  • mackerelの機能に加えて、細かな(でも効果抜群な)工夫が随所に施されていて為になった。mackerelのnameを変えて見やすくするのは、明日からできるかもしれない。
  • リソースが過剰であることもmackerelで取ろうとしているとのこと。確かにクラウドに移行し、従量課金されていくことが多いので非常に重要な取り組みだと感じた。
  • 人気飲食店の予約時のスパイクやばすぎ

フルマネージドホスティングの運用監視にMackerelを導入した話

アイテック阪急阪神株式会社 主事 森本さん

スライドはこちらから

  • 自己紹介
  • 抱えている問題
    • ユーザーへの障害通知のタイムラグ
      • 営業を通じ、手動で連絡していた
      • 混在している監視システム
      • 校下校システムのメール送信が滞ったことがあったが大混乱
    • 度々起こる監視設定ミス
      • 監視設定間違い、アラート送信設定間違い、サーバ構築者が監視依頼を忘れていた
  • Mackerel導入理由・工夫

    • それぞれの課題を総合的に解決できる
    • 監視サーバーの保守が不要
    • セキュリティ要件の厳しい顧客のネットワーク環境でも導入できる
    • 障害情報ページへのリアルタイムの反映
    • 自作ダッシュボードを作って、抱える大量のオーガニゼーションをまたがった検索
    • 顧客への通知メールのカスタマイズ
  • 監視している例

    • CDNの転送量監視
      • 従量課金のサービス、一定量を超過すると高い
      • 公共交通機関Webサイト→大雨の時にスパイクした
    • 登録ホスト数
  • やってくれると嬉しい
    • 外形監視をMackerel本体でやってくれると嬉しい
  • まとめ
    • 何よりエージェントインストールで自動的に監視が始まる安心感
    • APIが豊富にあるので大抵のことはできる
    • 運用監視を任せることでサービス提供に集中できる

感想

  • 先ほどのトレタ山田さんの事例とは打って変わり、「しんどそう」なお話が多かった。サービスの特性上、監視自体も大変そう
  • その中でmackerelがそれらの課題を総合的に解決できたというストーリーは納得感があった。
  • 自作のダッシュボードかっこいい!!そして便利そう。これは外に出してもウケルと思った。
  • こちらのスパイクもやばすぎ・・・

以上です。 元気があれば懇親会に行きたかった・・・

「オブジェクト指向でなぜつくるのか」を読んだ

会社の先輩に借りた「オブジェクト指向でなぜつくるのか」を読み終わったのでその感想を書きます。

読んだ本について

読んだのはこちらの本です。

オブジェクト指向でなぜつくるのか 第2版

オブジェクト指向でなぜつくるのか 第2版

↑のリンクは第2版ですが、私が読んだのは2004年に出版された第1版でした。こちらの著者の方のページで説明されている通り、私の読んだ第1版から、現在最新の2版では内容が結構変わっているようです。本記事はあくまで第1版を前提とした内容で書いています。

感想

全体

タイトルや表紙からは堅めな技術書の匂いがしますが、実際はそれに反して初心者が読むことを前提とした説明がなされていました。サンプルコードや図もこれでもかというぐらい載せられており、出先でもサクッと読み進めることができます。

さて書名にもなっている「オブジェクト指向でなぜつくるのか」という問いですが、結局自分の中でしっくりとくる答えは見つけることはできませんでした。ただ「なぜオブジェクト指向が作られたのか」については、読む前よりも理解が深まったような気がします。これは大きな収穫でした。

本書の内容は大きく2つに分けることができます。 プログラム技術としてのオブジェクト指向を説明した1~6章と、そこから派生したソフトウェア設計手法としてのオブジェクト指向を説明した7章以降です。 特にプログラミング技術という文脈でのオブジェクト指向について知りたかったので、前半はしっかりと2,3度、後半はさらっと1度だけ読みました。

前半部分

本書では一貫して、「オブジェクト指向が現実世界をそのままソフトウェアに表現する技術である」という(よく為されがちな)説明とそこから派生する例え話を「間違い」と批判しています。(38ページ) よく初心者向けの本で使われる「犬がクラス、ポチやハチがインスタンス」みたい例え話のことですね。

そういった例え話をたくさん聞いて「で、実際にどうコードにするの?」とモヤモヤしていた私にとって、「現実世界との対比は、例え話と割り切るのがコツ」(58ページ)という本書のスタンスは、ある意味、目から鱗でした。

その前提の元、以下のような内容がありました。

  • オブジェクト指向が産まれるまでの経緯。
  • オブジェクト指向の三大要素
    • クラス・ポリモーフィズム・継承
    • サンプルコードが多くあり、「こういう時に」「こうすれば」「こう嬉しい」ということを確認しながら三大要素を理解することができました。
    • この辺も言語仕様として知っていても、自分の手で書けないという状態から一歩進むのに有意義だと思います。
  • オブジェクト指向プログラミングのメモリの使い方
    • プログラムの実行中、メモリがどのように使われているのか解説します。著者曰く「プログラマのたしなみ」だそうです 😩
    • 専門的な勉強をしたことがない私にとって、とっつきにくい部分ではありましたが、図をたくさん使って説明してくれているので、「あー確かにメモリの節約になっている」ということを理解することはできました。

再び全体

後半部分は前述の通りさらっと読んだので、「そういうのがあるんだね」ぐらいの理解でした。必要になったらまた戻ってきたいと思います。

マイナス点も少し上げます。

  • たとえ話は混乱の元になる、という論調ですが、本書内でも時たま変な例え話が出てきます。そして大抵はてなマークの浮かぶ例え話でした。まあそれだけ例え話がリスキーなんだと思いました・・・
  • 前後半はある意味全く異なったレイヤーの話でした。突然違う話が始まり、私は最初「ん?理解できない!!」と混乱しましたが、後から考えるとそれもそのはずという感じです。初めて読む方はお気をつけください。

全体として、「オブジェクト指向に変な理解をせず、1つのプログラミング技術として捉えるべき」という思いが底流していました。 機会があれば次は最新の版を読みたいと思います!!

Qiitaに「駅名のインクリメンタルサーチができる検索窓をVue.jsで作る」を投稿しました

タイトルのままです。
2度目の投稿です。

qiita.com

Vue.jsと「駅すぱあとWebサービス フリープラン」を使い、駅名をインクリメンタルに検索できる検索窓をつくる方法をまとめました。

記事を追って実装していくとこのような検索窓ができます。 f:id:kumatira:20180702000411g:plain

ぜひご覧ください。

Vue.jsを触り初めて数ヶ月が経ちましたが、データドリブンな感じがとても気に入っています。 その便利さをVue.jsに初めて触れた方(数ヶ月前の自分)にも直感的に伝えられるよう、この題材を選びました。

複雑なことを考えなくともデータと見た目が一致するのは、実装の際のストレスをとても軽減させます。

Qiitaに「クリックすると色が変わるアイコンをHTML/CSSで簡単に作る」を投稿しました

タイトルのままです。

初めてQiitaに投稿しました。

 

qiita.com

 

 

クリックすると色が変わるSVG画像を、HTML/CSSでつくる方法をまとめました。

記事の手順を全てこなすと、下のCodePenのようなものが完成します。

 

See the Pen change_icon_color_result by kumatira (@kumatira) on CodePen.

 

ぜひご覧ください。

【まつもとゆきひろ氏特別講演】若手エンジニアの生存戦略 に行ってきた感想&講演内容メモ

Rubyの生みの親Matzことまつもとゆきひろさんの講演「若手エンジニアの生存戦略」に行ってきました。

f:id:kumatira:20180623170712j:plain

supporterzcolab.com

講演中や後に感じた雑感と、取っていた講演メモをまとめます。聴きながら書いたメモなので乱筆はお許しください😃

感想

  • 去年の同じ時期に開催され話題になっていたので、ぜひ行きたいと思いイベントページが開かれた瞬間応募した。
  • サポーターズのオフィス&会場きれい!
  • 最初に「メタ戦略」を持つことの重要のお話があったが、非常に納得。うまく行った事例、というか事例とまで行かない日々の小さなできごとについて、全く同じ条件が回ってくることはまずないので、そこからエッセンスを取り出すことの必要性は「KPT」などの振り返りフレームワークでもなんども語られている。
  • 今回聞いたMatzのロールモデルもメタ戦略を作る材料にしなきゃいけない。
  • というかそうしろと言っていた気がした。なので自身のメタ戦略を話す時に「まあ答え合わせになっちゃうんですけど」と半笑いだったのかなと
  • 「リアル世界でチートを使う」という表現は、「そんな表現があるのか」と驚いた。割とみんな「Don't work hard ,work smart」じゃないよねと最近思っていたので、「リアル世界でチートを使う」という表現はいろんなところで使っていきたい。
  • 「20代エンジニア」という対象層が広かったためか、目新しい話はそんなになかった気がするが、自分の持っている思考やモヤモヤを言語化した言葉をたくさん知れたのでよかった。
  • たくさんの人のメタ戦略を聞いて、そっから自分のメタ戦略をどんどんアップデートしていきたいと思った。
  • 「しんどい所からは逃げろ」が一貫していた。質問で「周りがしんどいことをしていたらどうすればいい?」と聞いたら「逃げろ」だけ教えてくれた。わかる。
  • アウトプット大事!ただそれを恐れてしなくなるのは人間の本能だという話を聞いて、安心感を感じるとともに、自分のモヤモヤの理由を言語化できた。そして「本能に従うことにそんなに価値はない」そうなのでどんどん出していきたいと思った。
  • ということで、帰り道の駅のベンチでPC叩いて書いてます

講演内容

とりあえず聞いたことを全部書いたのでめっちゃ長文になりました。見出しだけをどんどん読んでいくと話の筋がわかると思います。

サポーターズ楓さん挨拶

自己紹介

  • 地方やエンジニアに課題感
  • エンジニアすごいのに恵まれてない!
  • (勝手に)皆さんのキャリアを応援しています!

    サポーターズ紹介

  • 過去2年で1億円以上の交通費を支給
  • 1日2回勉強会やってます

    サトアズ(@satoazu_sp)の紹介

  • pythonとgoをやってます
  • Tシャツも売ってるよ

今日の目的

  • matzのご尊顔を拝もう
  • エンジニアとしての生き方、勝ち抜き方を考える
  • 何かを始めるきっかけにしてください

Matzさん講演

Matz自己紹介

  • フルネームが長いので英語圏ではmatz
    • ニックネームじゃなくてファーストネームを読んでもらったらぞわぞわする
    • ドイツ系だとMatzという苗字がある
    • rubyを作った人です」
  • いろいろ賞をもらいました。日本で一番有名なプログラマー
  • 政府IT総合戦略本部委員
    • 首相会議に行って話しているが、あんまり意見が採用されているような気がしない・・・
    • 松江市の名誉市民

生存戦略

  • 生き残るには「死なないことが一番」
    • IT業界は「大変な働き方」をする人が多い
    • なので一生懸命働いちゃう→「たやすく絡みつく死の鎖」
    • 命が危ない
  • 誰にでも適応できる生存戦略はない
    • 具体的な方法はあまりないが、学ぶべきことはある
    • 成功した経営者にアンケート
      • X IQ、学校の成績、コミュニケーション能力
      • パターン認識能力が高い人が多い

パターン認識≒抽象化

  • 抽象化が大事
    • 毎回違う状況に対して適用できるのは何かを感じ取る
    • 「メタ戦略」→共通のパターン戦略
    • 「メタ思考」→メタ的な考え方を中心にする
    • 人間の強み
  • 抽象化の強み
    • 具体的なものは寿命が短い
      • アプリ解説書VSアルゴリズム解説書
      • アプリ→言語→OS
      • 抽象度が高いものほど寿命が長い
  • 抽象化が万能ではない
    • アーキテクチャ宇宙飛行士
    • どこまでも高みに行って話が通じなくなる
    • 抽象化のモレ、例外が生まれる

ロールモデル

今日はロールモデルとしてここでお話ししているかもしれないが、真似することは無理です

  • 環境が違う(インターネットがない時代だった)
  • バタフライエフェクト(映画みてね)
  • 過去のことを話すが完全に記憶している訳ではない→バタフライエフェクトで役に立たない
  • Matzの経験からパターンを引き出すことが今日の課題

昔の話

  • 12歳でボードマイコンに遭遇
    • プログラミングを理解するには至らなかった
  • 15歳でポケットコンピュータ
    • 初めてのプログラミング
    • 限られたプログラミング環境→すぐに辛くなる
  • 高校の時にPascal入門
    • コンパイラが20万する時代
    • 脳内でコンパイルして楽しんでいた
    • ローカル変数、ユーザー定義関数、再帰に出会う→プログラミングはいろんなことができるんだ
    • プログラミング言語自体に関心を持つようになる
      • 周りにプログラミングの話ができる人がいない
      • 自分で作れたらいいなーと思ったけど、作り方を調べるのが大変
  • 大学→ここは天国か

就職

  • 通勤が苦痛で東京で働きたくなかった
  • 浜松に就職→職住近接
  • 同期200人居たが、コンピューターサイエンスを専攻して居た人は6人
  • 社内システムを作って居た
    • 「どうあるべきか」を決められる
    • どう実装するかも裁量が与えられていた
    • 大掃除の時にスーツじゃない服を来て行っても問題なかった
    • 怒られて説明して風穴を開けようと思ってTシャツとジーンズで行った
    • でも誰も触れてくれない

ここからパターン認識をしてみると

  • 鶏口牛後
    • 大きな組織に追従することはあんまり意味がない
  • 我慢の価値
    • 「頑張って」は英語に訳せない
  • 頑張ることをよしとする社会にいる
  • 「みんながやっているから我慢」はあまり理由にならない
  • 目的のある我慢
  • 納得できない理由で我慢を押し付けられることは結構ある

プログラマ三大美徳

  • 怠惰 全体の労力を減らすために手間を惜しまない←もっとも大切
  • 短気 コンピューターが怠慢な時に感じる怒り
  • 傲慢 人様に対して恥ずかしくないプログラムを書こうとする気質
  • 普通ならこっちだよね
    • 勤勉
    • 美徳
    • 寛容

上から下まで勘違い

  • 社会的な圧力
    • 「我慢」に価値
    • 苦痛に耐えることに価値を見出す構造に無自覚
    • 労働は我慢ではない
    • 報酬は価値の対価
  • 理不尽は拒否しなければならない
    • 理不尽への我慢は死につながる
    • でも我慢に鈍感になってしまう
    • そしていつか「致死量」を迎え死ぬ→ダメ絶対
  • ポジティブ思考
    • みんながやらないやってもいいこと
      • 「ずるい!」って言われるが・・・
      • ゲームでは裏技と言われる
      • リアル世界でチート使えたらいいよね
        • 少ない苦痛
        • 少ない我慢

リアル世界でチートを使う

  • 空気を読まない
  • 成果をあげる
    • 成果を上げていれば無理は通る
    • Don't work hard ,work smart
  • 価値観にアプローチする
    • 上司に付き従うことが無価値であることを説明する
      • 会社が嬉しい価値は0
      • 上司が喜ぶだけ
  • 社会的圧力を自覚する
  • 理不尽に対して声をあげる
  • 扱いにくい部下でもいいよね
    • 言った方がいいことも多い
  • win-winな関係を築く
    • 長く続く関係はwin-winかno deal(取引しない)
    • 場合によっては逃げること

メタ戦略を考える

  • 我慢に価値を置かない
    • 社会的圧力に負けない
  • 自覚的・自発的になる
    • 本能は現代社会の持つ問題、圧力を感じ取ることができない→自覚的になる必要
    • いつもするのはめんどくさいが、要所での判断は自分の判断で行わなくてはならない
      • 脳内のプログラム、社会的圧力に流されない
  • 自分を知る
    • Matzがどうかではなく自分がどうか
    • 自分がどういう状態か、どういう環境について知っていれば百戦危うからず
  • 継続すること
  • 勘「こっちに行くと幸せになれそう」は大事
  • 社会的圧力に対する鈍感さ
    • 「空気を読める」ことは自分を苦しめることもある
    • 時たま捨てましょう
  • 思い込みに自覚的になる
    • 思い込みってキャッシュみたいなもの
    • 無効化が効かないキャッシュ
    • 昔(=そのキャッシュが作られた時)は意味があったかもしれないが
    • バグ原因の95%は思い込み
  • プログラマーの仕事は問題把握から始まる生産性向上
  • 同じ原則を人生にも適用→プログラマーは人生の勝ち組

コントロール意識

  • けなす、叱ると生産性は容易に下がる
  • コントロールできないと感じる(=強制される)と生産性低下
  • コントロール意識→物事、道具を自分がコントロールしているという意識
  • プログラミングの醍醐味の1つは万能感(=コントロール意識)
  • コンピューターをコントロールして価値を産むべき
  • コンピュータの奴隷になりがち
    • 犬のアルファシンドローム
    • 人間の場合は逆アルファシンドローム
      • 他人に従わなくてはいけないと思い込む
      • コンピューターのために仕事をしている?
  • 意識的に「コンピューターの主人だ」と自覚する
  • 自分の人生の主人公は自分
  • 人間の本能に従うことに価値はない

インプット・アウトプット

  • インプットは必要だが、差別化の要因にはならない
  • 外に出す
    • 恥ずかしい、面倒
    • youtuber見て「あんなの誰でもできる」と思う
    • でも心理的障壁が邪魔をして99%の人はやらない
    • 心理的障壁(思い込み)を超えた人
  • アウトプットして他人に評価される人が成功する
    • クオリティはとりあえず棚上げ
    • 人間の可塑性にかける
      • 人間は置かれた状況によって変われる

心理の怖さ

  • プログラマは機械に向かっているけど
  • 問題解決を待っているのは人間
  • 大抵心理的な問題を解決している

質疑応答

  • プログラマ35さい定年説
  • 注目している言語は
    • エリクサ
      • 分散
    • 自分はstreamを作っている
  • アウトプットについてどうやって羞恥心を乗り越えたのか
    • 昔はインターネット人口が少なかった→注目されづらかったので今の方が怖い
    • 慣れ、場数
    • 狭い範囲のアウトプットを繰り返してなれていく
      • 小さい勉強会
  • 理不尽に耐える人への対処は (My question!!!)
    • 言って伝える
    • 自分に近いところの人、組織がそうであるなら逃げろ
  • 最近技術書以外で読んだ本は
    • だいぶ本を読むのは減った
    • ライフハック
    • 巨神化計画
    • 火星の人
      • 結局問題解決の本
  • アメリカ人エンジニアには当てはまるけど日本人エンジニアには当てはまらないことって何?
    • 組織の違いが大きい
    • 文化的な違い
  • どんなロールモデルを持ってる?
    • ラリーウォール
  • 上司が今日みたいな話をしてくれるが、変化についていけない
    • 我が道を行っていたのであんまり葛藤は感じなかった
    • 逃げろ
  • 意識的にしてきたことはあったか?
    • 自分の思ったこと感じたことを外に出すようにしていた
  • 自分はデータサイエンスを深くやっているが、終わる時がくるかもしれない。深く狭く?広く浅く?
    • データサイエンスがすぐなくなることはない
    • 世の中には状況によってすぐに市場がシュリンクするものはある
    • そういうことが起きるということを頭の片隅に入れておくことは大事
  • 中堅になった時に関わる要素は
    • 体力です
    • 自分のバリューがどのドメインにあるか考える
  • 自分のマーケットでの価値が変わると思うがどうやってその状況をキャッチしているか
    • RSSリーダーを活用してニュースサイトやブログを片っ端から見て傾向を感じる
  • 他の人にもコントロール意識を持って欲しい
    • 上司は何もしないのが一番
  • 今20代なら何をしている?
    • ゲームにハマっていた
  • 今Matzが持っている目的目標は?
    • 継続することがテーマ
    • 地位、やりたいこと、年収からすると上がり
    • OSSに関わる後進のロールモデルとなりたい

以上

会場入り口の黒板です f:id:kumatira:20180623170402j:plain

※ 随時加筆修正します

「公共交通ナビサービスの開発現場のリアル」に行ってきた。

5/18日にDevLOVEというコミュニティが主催していた「公共交通ナビサービスの開発現場のリアル」という楽しいイベントに行ってきました!!

devlove.doorkeeper.jp

そのイベントでの雑感と講演のまとめを書きます。

雑感

会場がきれい!ナビタイムさんのオフィス1階にあるイベントスペースが会場でした。今月オープンしたばかりだそうで、色々なイベントに便利そうだなと思いました。

同じナビサービスを運営する2社から講演者がでるということで、業界的な話とアジャイル的な話の両方を期待していきましたが、結果どちらも聞くことができ大満足な講演会でした!!

特に吉尾さん(3番手の発表)と小田中さん(4番手の発表)の発表では、とても具体的なアジャイルプラクティスが紹介され、メンバーでない私もまるでそこに参加しているような感覚を覚えると共に、実際のイメージを持つことができとても勉強になりました。マネージャーのお二人がとても嬉しそうにその成果を発表する様子が印象に強く残っています。

全ての発表を通じて、円滑で健全で活発なコミュニケーションが多くの問題を解決する様子を見ることができました。なかなか実行することは難しいですがスクラムなどのフレームワークにも頼りながら、明日からでも頑張ってみたいです。

ちなみに最後のパネルディスカッションの際のグランドルール「質問じゃなくて意見表明でもいいですよ」はとても感動しました!そうそうこういう時、まとまってないけど絶対クリティカルだと思う感想を抱いて、でも言っていいのか迷っているうちに時が過ぎるよね。。。と思って聞いていました。

以下は講演とパネルディスカッションの内容です。 ※正確に表現することを心がけていますが、聴きながら取ったメモですので曖昧な記述や誤った記述が含まれるかもしれません。ご容赦ください。

講演内容

オープニングトーク

  • ナビタイムと「駅すぱあと」のヴァル研究所が同じイベントにでるって、なかなかやりにくかったんじゃないですか?
  • ナビタイム社内では割とスムーズでした。
  • ヴァル研究所もですよ。ちょっと社内がざわついたけど。
  • 会場は今年のGWにできたらしく、きれいですね。

株式会社ナビタイムジャパン 村川さん

<テーマ>「ナビタイムの働き方改革
※諸事情*1でトップバッターのヴァル研究所 下村さんが順番繰り下げ

第1の課題「サービスを出せていない」

2007年まで順調に新規サービスを生んでいたナビタイムだが、2008年ごろ新しいサービスが出なくなってしまった。

  1. 要因:何をするにもコストがかかりすぎる
    • 階層構造が厚く、かかりすぎる調整コスト
    • 「意味がない」「決まらない」会議多数。階層構造ゆえなんども開催される定例。役職者のパフォーマンスは低下
  2. 解決策
    • 技術ごとの部ではなく、サービスをもつPJ*2を創設。
    • 部長以外の役職を廃止し組織をフラットに
  3. 結果
    • 会社がフラットになりました。
    • PJは評価教育を切り離し、サービス開発に専念できた。PJ内に様々なロールの社員がおり、能動的な開発。開発速度が向上。
第2の課題「事業 VS ACTS(研究開発)」

事業を行なっているPJと研究開発の間で相互理解が不足してしまった。

  1. 解決策
    • ジョブローテーションを充実させ、横断的な知識を持つゼネラリストを増やした。
    • 全PJの報告会を誰でも質問、資料全公開なオープンな場にするなど、コミュニケーションの活性化に努めた。
  2. 結果
    • プレスリリース増加(≒新規サービス増加)
    • 有料会員数増加
    • 残業時間削減(平均13時間)

株式会社ヴァル研究所 下村さん

<テーマ>「駅すぱあとの開発現場 - 維持する30年とは」

駅すぱあとの歴史
  • 1988年発売 首都圏版 当時、ヴァル研究所の本流ではなかった
  • バブル崩壊で経費の削減が求められた時、定期分割機能がヒット
  • 当初はデスクトップアプリとエンジンが一体だった。mac対応をきっかけにエンジンを分離、他の商材でも活用するようになる。
Cで実装
  • コアエンジンはスピードが命であり、Cで実装している。
  • Cで直接使うのは面倒なので、バインディングを多く作った。
増え続ける機能

最初の開発者は3名だった。30年続いているソースリポジトリ。「ソース腐ってんじゃないの?」。当時はバージョン管理もなかったが、今はgitに移行中

  1. 機能的にも増えてきた。
  2. テストコードがろくになかった
    • ノウハウが溜まっている検査チーム(QAチーム)が助けてくれた。が、テスト実行に12時間
    • 次にインフラチームが助けてくれた。Azure使って並列化、自動化し、50分でできるようになった
    • どちらも別チームから「越境」に助けられた。
    • 現在は本体にも単体テストを追加
  3. 日々のメンテナンス
  4. ダイヤ改正、臨時ダイヤ、新しい料金体系、新規路線などは外部からの情報で常にメンテナンス
    • サポート、ユーザーレポート、エゴサ
    • 実地調査や事業者からのデータ
まとめ
  1. モブプロ、モブワークで知識を広めている。
  2. 「越境」するチームの力に支えられてきた。

株式会社ヴァル研究所 吉尾さん

<テーマ>「駅すぱあと バス制作だってアジャイル・プラクティス!」

バス制作チーム

吉尾さんがリーダーを務めるバス制作チーム

  1. バス社局からもらったデータを駅すぱあと用データに変換するバスデータの保守部隊
  2. 半数がプログラミング経験なし
課題

吉尾さんが配属された当時、全ての業務は非効率で辛いものになっていた。

  1. 状況
    • 多数のバス社局からそれぞれの多種多様なデータ形式で送られてくる。
    • 新規バス対応にアサインされた人の流儀が横行し、工数短縮のため保守もその人が行う。
    • 負荷はばらつき、チームの予実対比もない状態。これで毎月の改正に対応
    • 属人化が凄まじく「チームではなく『個』の集団」
アジャイルプラクティスを実践
  1. 朝会
  2. KPTでふりかえり
    • Problemには事象ではなく真因を
    • Tryには精神論<やり方改善<仕組み改善 「頑張る」だけはNG
    • Tryはふせんで表明することで有言実行を推進
    • Tryはカジュアルなカイゼンに繋がった。これによりカイゼンが常態化するようになる。
  3. ペア作業
    • 属人化解消が目的。
    • それまでの担当者の手順に「なんで?」「わからん」というツッコミが入り、レビューの側面も
  4. 星取表
  5. カンバン
    • 目的は「メンバーの状態」「タスクの状況」「タスクの属性」の見える化
    • 朝会のコミュニケーションツールにもなっている。
  6. スプリント
    • 計画会議で始まりふりかえりに終わる、一定の時間枠を繰り返す。「終わり」を決めることで恒久的な作業にメリハリがつく。
    • DONEのみが成果であり価値
    • 見積もりにはプランニングポーカーを使用。徐々に感覚値の精度が向上し、現在では2ヶ月先まで見通せるように。
    • バーンアウトチャートを使った進捗の共有
  7. 全てはコミュニケーションに繋がっていた。
結果
  • 対応バス社局数が増加、4/1改正対応数も改善、作業時間は減少
  • 吉尾さん指標で作業効率は3年で160%に!!
  • これからもたゆまぬカイゼン

株式会社ナビタイムジャパン 小田中さん

<テーマ>「ナビタイムR&D部門がたどるカイゼンのキセキ」

自己紹介
  1. ACTS ルートグループ責任者
  2. ACTSのミッション
    • 新価値提供(知って使ってもらう)
    • 品質改善
最初のチーム「R&D部門」
  1. ゴールからずれるチームメンバー
    • スキルが高く、突き詰める研究者肌な開発者たち
    • その性格ゆえに、気になることがゴールからずれ、試行錯誤で堂々巡りする。
  2. デイリースクラム・スプリントレビューで高頻度に軌道修正
    • スクラムはR&Dと相性いいのか?→スクラムは不確実さと向き合うもの。研究開発にぴったり!
    • スクラムをちょっと入れたみた。
    • 計画段階にがっつりプランニングし、あとは各メンバーがイテレーティブに
  3. 結果
    • ゴールからのズレがなくなった。
    • 最初に出なかったことは後回しになってしまった。
    • ふりかえりシートの不備から、Problemがたくさん並ぶだけになってしまい、プロセスのカイゼンが進まず。
第2のチーム「チャットボット開発」
  1. タスクが無限に増える
    • スキル、開発速度共に申し分ないプロフェッショナルたち
    • それゆえ、周囲からタスクをどんどん積まれてしまう。
  2. 必要なものにフォーカス
    • ユーザーストーリーやPDCAサイクルを作り、ログとユーザーボイスで正確性を担保
    • プランニングは各メンバーに委ねた。
  3. 結果
第3のチーム「乗り換え経路探索エンジン開発」
  1. チームの目標達成進捗がよくない
    • 若手が多い
    • 個人のタスクが膨大
  2. 「よろしいならばスクラムだ」
    • 「うちに合わなそう」「興味はあるけど・・・」というメンバー達にスクラムとは何か、なぜかを説明。
    • インセプションデッキをみんなで作り、意識を統一
    • 数百件の溢れる優先度不明なタスク達。全タスクを確認して優先度をつけ*3、低優先度のモノはお蔵入り。
    • ヴァリューストリームマッピングと「ペインキラー」でリリース工程を圧縮。自動化できるところは徹底して自動化。
  3. ようやくスクラム開始
    • スクラムの完全導入すると、個がチームになった。
    • 終電後ルート機能をイテレーティブに改善。目標を達成し、社内で表彰された。
まとめ
  • フォーマルなスクラムは強力。型を少し崩してチームに最適化するのもあり。
  • スクラムに懐疑的だった社員が「やりながらカイゼンしていけばいいよ!」
  • スクラム経験者同士のハンガーフライトを実施した。
  • R&Dと事業側、エンジニアとデザイナーが繋がるところをみた。つながりをどんどん増やしていきたい

パネルディスカッション(抜粋)

質問だけでなく意見表明もウェルカム!

スクラムを導入するのは大変?」
  • 小田中さん「超大変」「足かけ2年ぐらいかけた」
  • 吉尾さん「開発の時はマッチョにやっていた。朝会などやりやすいところからやれば良い。」
「朝会とリモートワークは相反するのでは?」
  • 吉尾さん「ハングアウトを使った。」
  • 小田中さん「slackのGeekbotに昨日やったこと今日やることを投げて共有」
「どんな人を採用しているのか」
  • ナビタイム
  • ヴァル
    • 新卒→鉄道や経路探索
    • 中途→鉄道好きが意外と多くない
  • 「似てますね(笑)」

以上

*1:下村さんが転倒、発表用PCがリブート、プロジェクターが不調とトラブルが続出

*2:プロジェクト

*3:狩野モデルも使ったとのこと