うさぎ組

ソフトウェア開発、チームによる製品開発、アジャイル、ソフトウェアテスト

お気に入りの生産性あげるための工夫（アプリとかブラウザ拡張とか）

オススメのものを列挙するよー。

1日の過ごし方

大切にしているコンセプトは「もっているものを最大に使いこなす」ということで、手を使える時間はプログラミングとか、たまにしか手を使えない時間は電子書籍か動画、耳しか使えない時間は音声ってつかいわけています。なので、手が空いているときはできるだけものを作るようにシフトして生活している。

  1. 起床したら気になる記事をInoReaderとかはてなブックマークから検索して、Pocketに共有。
  2. シャワーあびたり身支度する時間、通勤で歩いている時間、などはPocketで共有した記事を音声読み上げで聞く。
  3. 音声読み上げできなかった記事は、空き時間に目視で確認。（大抵は業務時間の隙間とか）
  4. 気になったソースコードはPCのChromeでSourcegraph for GitHubを使って確認して、必要そうだったらcloneする。
  5. 手が動かせる時間ができたら、いろんなものを動かしてみる。

実践している時間はバラバラなんでよくわからない。

InoReader

いろんなブログとかRSSで購読するためのWebサイト、スマートフォンアプリ。 スマートフォンで見て気になったらSlackとかPocketとかはてなブックマークに共有しています。 PCブラウザで見るときはショートカットキーが使えて便利。

www.inoreader.com

Pocket

Webページをまるっとスクレイピングして保存できるWebサイト、スマートフォンアプリ。 Androidで音声読み上げを入れれば、記事を読み上げることができる。 これで、シャンプーしながらとか歯を磨きながらでも勉強できるようになりました。神ツールだと思った。

getpocket.com

Sourcegraph for GitHub

GitHubのコードをブラウザ上でIDE的に見ることができる。 なんとコードジャンプもできてまぢ便利。神ツールだと思った。

chrome.google.com

ポモドーロテクニック

25分毎に1度休憩するというテクニック。 で、これはお手製ツールを使ってやっています。25分過ぎると、アプリが全画面表示になって作業を強制的にストップするようにしています。 結構便利です。集中して仕事したいときはかならずポモドーロテクニック使っていますねー。

Chrome拡張で便利なのはStrict Workflowっていうプラグインかな。25minの間はTwitterとかが見れなくなります。（どのサイトを見れないようにするかはカスタマイズできます）

chrome.google.com

ブラウザ上で英単語翻訳

ブラウザで表示している画面で、ダブルクリックした英単語とか選択した英単語を日本語に翻訳してくれる拡張をつかっています。 いろいろあるんですが、最近は、速訳！英辞郎®英和辞書っていうやつを使っています。 ページの翻訳はChromeでそもそもできるんでね。

chrome.google.com

スクラムとかアジャイルのワークショップ 2017.05 版

毎月スクラムに関する勉強会を開催していて、そこでワークショップをやることがあります。 また社内で勉強会をやることもあります。 そこでいままで実施したワークショップの一覧があるといいなぁとおもったのでまとめておきます。 yattomさん、みほらぶさん、角さん、たかえすさん、川口さんありがとう!!!

nagoya-scrum.connpass.com

カンバンゲーム

www.slideshare.net

www.slideshare.net

バルンガ

www.slideshare.net

紙ヒコーキ

dev.classmethod.jp

振り返り

speakerdeck.com

↑の中で次の5つを実施 * +/Δ * Circle of Question * Value Stream Map * KPT * SMART Goal

プロダクトオーナーの意思共有

d.hatena.ne.jp

フィアレスジャーニー

www.slideshare.net

download – Fearless Journey

mocha-cocoa.blogspot.jp

スプリント期間と見積もり

speakerdeck.com

happylilac.net

プログラミング言語雑感 2017春

まえおき

kyon_mm のスキルでは。。。っていうだけで、皆さんがどうなのかはしりません。

Groovy

こまったらまずこれで検討するやつ。(.NETと比較して)どこでも動いてよい。IntelliJ IDEA + Gradleでつかっておけば問題ないやつ。

GrabやGradleの恩恵がすさまじく、可搬性の高いスクリプトやアプリケーションの開発にもってこいですね。くわえて、Spockっていうすばらしいテスティングフレームワークがあるだけで採用したくなる。Groovy自体も漸進的型付きなかんじがあって、そこそこに静的な型検査ができるのもいいなーとか。

WebアプリケーションつくるときはさいきんはRatpackっていうフレームワークでつくることがおおいですが、ガチな運用したことがないので結局はGrailsがいいっていう場面はあるのかもなーっていう見解。

C#

Visual Studioと.NET Frameworkから離れなければとりあえず安定している。いつも不満なのは、Visual Studioで出来る操作をMSBuildでやるにはどうしたらいいのか調べるのに苦労しています。誰かサクサク知る方法を教えてください。

async/awaitの変換回りはかなり気色悪い(褒めている)とかあるんですが、(LangExt っていうライブラリをつかえば)そこそこつかえるかなぁとはおもっています。 いつも不満なのは、ASP.NETとかADO.NETとかそういうやつですよ。(あれー)

F#

.NET Frameworkでアプリケーションつくるときの第一候補とする言語。C# とかいう言語では最近REPLができたそうですが、F# は古来からありますよ! みんなでレッツF# !

F# はアクティブパターンがつかいやすくてマヂ神! ってかんじですかね。タイププロバイダーとかいうおもしろ機能はいろいろ使いこみたいんですが、まだ使いこなせていないです。 あ、あと弊社? で開発している FQC っていうコンパイラの後ろ部分(IL生成部分)があるので、こいつへのPullReqとかおまちしております。

ほかの言語

よくわからん。とりあえず、言語仕様書とGetting Startよめばなんとかなるだろという雑な扱い。 Javaは最新の言語仕様書読めていないし、C++はそもそもたいしてしらないです。言語仕様書がうすい言語は勉強しやすくてよいですね。(そうだろうか。。。)

Erlang

最近勉強しているのは、CoqからErlangの生成とかできるのではーと妄想して調べていたら、PPLでそんな話があったとかで、やっぱりそうなるよねー!っていう話をステーキたべながらしていた。 Erlangカッコイイなーってあこがれこそあれど、なかなかたくさんのコードを書こうとすると、なれがたりていないです。。。(静的型検査がないやつで、たくさんのコードを書くことにそもそもなれていないってだけです)

JavaScript

JavaScriptは僕にはむずかしいので、Vue.js でいいかんじにやっておしまいです。Vuejsの日本語ドキュメントすばらしい。課金したい。 一時期は、AltJSで生成すればなんとかなるとかおもっていましたが、JavaScript書くほうが楽な場面そこそこあるなーっておもっていました。 それもWebAssemblyでなんとかなるのかもーっていう夢がひろがってよいですね。

Java

Groovyを実行する基盤のやつ。ヴァルハラ〜。各プログラミング言語とかビルドツールがJava9にスムーズに対応できるのか不安。

OCaml

なごやで公用語のやつ。プログラミングの基礎っていう書籍でつかわれているしね。

いまだに自分はプロダクトにしろツールにしろ仕事でつかったことがないので、いつかつかってみたいとおもって幾年ってかんじです。 Emacs以外でいいかんじにつかえるIDEがほしいです。JetBrainsさんつくってくれませんかね。

Scala

東京で定番化?流行?しているらしい。個人的にはGatlingつかわないWeb企業ほぼないとおもっているので、Scala書いたことないWeb系の人いるほうが希少なのではーくらいにおもっている。

VDM++

形式的な仕様に憧れてさわってみたりしているものの、「おれがつくったほうがもっといいDSLつくれそう」というサイクルをとおして振り出しにもどる系の言語です。もう最近はVDM++でいいんじゃないだろうか。。。っていう気がしなくもないですが、B-Methodとどっちにすればいいんだーってなやんじゃいます。

ふりかえり

JetBrainsさんがいないと生きていけないです。

Java女子部でSpockの入門ハンズオン講師しました。 #javajo

Groovy Spock

Java女子部というコミュニティで2017/03/25に半日間のハンズオンでSpockというテスティングフレームワークの使い方を教えてきました。 Javaはだいたい書けるけど、Groovyとかよくわかりません！みたいな人に最低限のGroovyの使い方とSpockを教えるみたいな感じです。

javajo.doorkeeper.jp

すすめかたはだいたい次のような感じです。

  1. GitHubからソースコードをダウンロードしてもらう
  2. kyon_mmがスライドで概要をつたえる
  3. kyon_mmがIDEでサンプルコードをひらきながら解説する
  4. 参加者がサンプルコードのテストが失敗している部分を通るように直す
  5. kyon_mmがテストが通るようにコードを記述するのデモする
  6. Groovy/Spockの基本については2 - 5を繰り返す
  7. 解説がおわったらペアプロでTDDライクにSpockをつかいながらコードをかいてもらう

いわゆるKoan形式とか4clojureみたいなかんじといいますか、テストが通るように修正することで機能を学んでいくっていう感じです。

speakerdeck.com

github.com

スライドに誤解をまねくような表現がないように配慮したつもりですが、もし違っていたらツッコミもらえるとうれしいです。 Groovyの解説はJava8のまま書いても動かないところを中心にしました。

また、当日サンプルコードがいくつか間違っていたので修正したものをGitHubにあげています。

正規表現のところに // によってエスケープがなんたらというテストを最初書いてしまっていて、 動かなかったのは、文字列としてであって正規表現でのテストではなかったためです。現在のGitHubのmasterでは文字列のテストに移してあります。すみませんでしたー＞＜

全体的には自分の知識が再整理されたとか、TDDとはなんだーとか、自動テストの考えかたとかいろいろ興味をもってもらえたのがとても勉強になりました。 呼んでいただいたJava女子部の皆様には感謝です。特に声をかけていただいた、あやさんありがとう！ Java女子部はもっと怖い人のいるところだとおもっていましたが、みなさん優しかったですし、楽しい人達でした。 参加者のみなさまからも楽しかったと言ってもらえたので、やってよかったなーっておもえました。

今後も関わるのであれば、Java女子部でF#をつっこむのは難しいでしょうし、GatlingとかBetamaxとかGebでしょうか。

GroovyとかSpockまぢべんりな子なので、ぜひ使ってみていただけると嬉しいです。 また、スライドやGitHubはご自由に使っていただいて構いません。みなさまでSpockを愛でる方向で。

Enjoy Spock!

うさみみが2016年に読んだオススメ書籍と振り返り

仕事

社内他チームをマネジメントしたり、Breaking Scrumしたりと挑戦しました。たのしかったです。 セミナーや新卒研修などにも携わり。ヴァル研究所様とお仕事できたのは素晴しい経験になりました。 また、 enPiT という文科省と各大学の連携でやっている「（僕から見ると）イケてるITエンジニアの卵つくろうぜプロジェクト」に関わらせていただきました。大学院生の教育に関われる日が来てよかった。これからも積極的にかかわりたいです。 株式会社オンザロードというか、僕へのお仕事の依頼はいつでもWelcomeなので kyon.mm あっとまーく gmail.com まで。

講演

1月に「15分単位でメトリクスとってるスクラムチームあるんだけど、質問ある？」っていう発表をしてから、ちょこちょこ発表をしました。

(意外と発表してた)

セミナー

3ヶ月に1度くらいのペースで、Git Boot Camp Premiumというセミナーを翔泳社で開催しています。ちなみにオンサイトでも開催できるのでいつでも依頼してください。(他のものでも) 2017年からはもっと他のセミナーも増やそうかと計画中です。

私生活

幸せでした。家族に感謝ですね。

その他いろんなこと

すみませんでしたああああああ＞＜

2017年にやりたいこと

  1. きょんくんがいないチームにBreaking Scrumを導入したい。（きょんくん流 Breaking Scrumの導入事例になってみたいチーム募集しています）
  2. F# かOCamlかGroovyで仕事したいので、仕事ください。
  3. 形式手法導入したい。

読んだオススメなやつ

ここから下は基本的にどれも素敵な書籍なんですが、そこから更に好きなやつを選ぶなら、

  • Joy, Inc
  • SOFT SKILLS
  • なぜ人と組織は変われないのか ― ハーバード流 自己変革の理論と実践
  • グッド・マス ギークのための数・論理・計算機科学

ですね。まぁ、好みも問題かも。

IT系にいるならよんでほしいやつ

SOFT SKILLS ソフトウェア開発者の人生マニュアル

SOFT SKILLS ソフトウェア開発者の人生マニュアル

組織とかチーム

ジョイ・インク 役職も部署もない全員主役のマネジメント

ジョイ・インク 役職も部署もない全員主役のマネジメント

なぜ人と組織は変われないのか ― ハーバード流 自己変革の理論と実践

なぜ人と組織は変われないのか ― ハーバード流 自己変革の理論と実践

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

カンバン仕事術

カンバン仕事術

トヨタのカタ 驚異の業績を支える思考と行動のルーティン

トヨタのカタ 驚異の業績を支える思考と行動のルーティン

ザ・トヨタウェイ(上)

ザ・トヨタウェイ(上)

ザ・トヨタウェイ(下)

ザ・トヨタウェイ(下)

チームワークの心理学: エビデンスに基づいた実践へのヒント

チームワークの心理学: エビデンスに基づいた実践へのヒント

自衛隊メンタル教官が教える 心の疲れをとる技術 (朝日新書)

自衛隊メンタル教官が教える 心の疲れをとる技術 (朝日新書)

数学的な

圏論の歩き方

圏論の歩き方

グッド・マス ギークのための数・論理・計算機科学

グッド・マス ギークのための数・論理・計算機科学

記号論理学: 一般化と記号化

記号論理学: 一般化と記号化

アルゴリズムとかデータ構造とか

Purely Functional Data Structures

Purely Functional Data Structures

教育

幼児教育の経済学

幼児教育の経済学

「学力」の経済学

「学力」の経済学

ネットワーク

擬人化でまなぼ! ネットワークのしくみ

擬人化でまなぼ! ネットワークのしくみ

さいごに

みなさまありがとうございました。ほんとうに。来年はもっとブログ書きます。

Gitを5年間教える側にまわって気付いたこと

Git Advent Calendar 2016 - Qiita の記事になります。 本記事では自分がGitを教えたことで気付いたことをまとめます。 ゆえに「Gitに入門したい人」に向けたものではありません。が、多少のエントリーポイントは示しますので参考になるかとは思います。 コミュニティ、有償セミナーで5年間Gitを中心としたバージョン管理システムを教えてきた経験の話です。 ただ、Git, GitHubなどのデベロッパーではないので、彼等の思想とは異なるかもしれませんが、そこは一人のGitの講師として見てもらえれば。

命名の混乱とユーザー層

Gitのコマンドは名前から理解しにくいことで有名です。 git rebase --intractive などは典型です。 例えば、branch という単語が示す内容はあまりにも違っています。 VCS毎に branch の意味が違うことも難しくしていますが、加えてGitの場合には branch (枝)というメタファーと実態の乖離が大きく、理解するまで時間がかかったという人もいるようです。 (ちなみにMercurialでは同等機能は bookmark となっており、Mercurialはbranch(枝)とbookmark(しおり)の両方で管理することができます)

そして、ユーザー層?スキーム?が様々であるため、GUIツールではあまり対応がとれないような言葉になっていることもあります。 GUIツールで困ったときに違う単語で調べる必要があり、加えてGitのコアユーザーはコマンドラインで使うため、GUIツールのトラブルシューティング情報は少なめになっています。 もちろんこれらを乗り越える人もいますが、自分の経験ではあまりいませんでした。 乗り越えないままに使うことはできるけど。。。という感じでしょうか。 ので、トラブルが起きたときにはGitで解決をせずに別の方法(ファイルのバックアップをどこかからもってきたり、新しくリポジトリをcloneしなおしてから、コピペしたりすること)で解決している人もたくさんいます。 別にそれ自体は悪くないですが、Gitの学習という意味では大きな壁になっています。

そういった意味で、自分が大切にしているのは Git公式の Pro Git というページです。 Git - Book

このページを読んで理解できるのであれば、それなりにプログラミングや、VCSに精通しているとおもいます。 ですが、なんとなくで使える程度の人や、パパっとワークフローがわかればいい人にはちんぷんかんぷんなページだと思います。 ここにある概念を大切にしながらGitを使う開発プロセスのトレードオフを伝えることが大切だと思っています。

Gitの概念を日本語でうまく表現している書籍は次の2冊だと思います。出版時期は少々古いのですが、あまり古びた内容でもありません。

入門Git

入門Git

実用Git

実用Git

バージョン管理、統合の戦略が広まっていない

Gitを教えていていつもぶつかるのは、そもそもSCM(Software Configuration Management)の戦略が知識としてもあまり広まっていないということです。 GitはSCMを支える重要な要素ですし、様々な戦略を取れるようにGit自身は多数の機能を提供しています。 この何年かで、「ローカルでGitを使うときの作法」「Pull Requestによるレビュープロセスの確立」「Infrastructure as a Code」といった知見は広まってきましたが、バージョン管理を活用したチームやプロダクトのプロセス品質を上げるという方向についての議論はあまりされていません。 というよりは、ずっと課題だと思う(ソフトウェア構成管理という単語がずっと使われている事情からそう思う)わけですが、流れとしては「SCMの戦略」よりも「SCMを中心として少しでもよくなってきている開発の改善力を中心にもっと範囲を広げよう」という感じだと見ています。 大切だと思いますし、そうすることで無駄が減る(部分最適をする前に全体を見ることが出来ることによって余計なことをしないで済む)こともあります。 ですが、Gitを活用したSCMの戦略が貧困なままでは、ビジネスのボトルネックになるばかりです。

一例としては、 Jenkins + GitによるIntegrated Workflow + Gateway CheckInを実践することができます。

www.slideshare.net

また、SCMという広い意味では次も参考になります。

qiita.com

「何を編集しやすく、何を実行しやすく、何を統合しやすく、何をレビューしやすく、何を組合せやすく、何をスケールアウトしやすく」それぞれのトレードオフや理想を達成するためにGitを利用することは多くの場面で大切です。

ただ、そういったSCMの戦略がわかっていない、関心がない人もたくさんいますし、必要ではない人もいます。 (もちろんわかっている人もたくさんいますが、割合の話ですね)

まとめ

  • Gitの概念、コマンドを覚えるのは苦労しやすいポイントであり、反復練習か、Gitを使わないという選択肢を見つける必要がありそう。そして、それに耐えられない人がGitをなかなか使い始められなかったり、Git使っています() みたいな状態になってしまっている。
  • Gitを使うことで、どのような理想的な開発プロセスにしたいのか。というSCMの戦略に関心がない人や、そもそも知識が共有されていない現状があることを踏まえて、Gitの使い方を教える必要がある。

自分の教えかたを2,3年毎に大きく変化させることでいくつか気付きがありましたが、大きいこの2つについて紹介しました。 では、これらをどうするのか? という話ですが、前者は Gitカルタ という形でコマンドをさわらずにGitの操作をイメージで掴めるようなゲームとして教えています。

codezine.jp

後者については、事例をはさみながら教えていますが、いまのところGit Boot Camp Premiumというセミナーでは最初のほうだけを教えるに留まっています。 ので、更に拡充して2017年はコミュニティ、有償セミナーを開催しようと思います。おそらく別枠で開催する感じがいいかなぁと。

おまけ

弊社、基盤チームではGitからの脱却を目指して新しいVCSの設計を始めています。いつ完成するのかはわかりません。いろいろ不満なのでね。。。

組織（チーム）を成長させるための参考書籍

概要

マネジメントやプロセスの方法論自体をどのように適用、変化させるのか。 というのは、方法論自体を知る必要があるのはもちろんのこと、どんな組織にしたくて、どうすれば成立できるのかということを考える必要があります。 それらを引っ張るものが、理想や価値観であり、それらを明確につくる能力も大切です。

というのをあるTweetの具体例から入って話しているうちに、参考書籍を紹介しておこうという流れになりました。 ので、ある程度抽象的なやり方っていうんですかね。組織に変化をもたらす方法っていう感じですかね。

Twitterの流れ

togetter.com

参考書籍

ザ・トヨタウェイ(上)

ザ・トヨタウェイ(上)

ザ・トヨタウェイ(下)

ザ・トヨタウェイ(下)

トヨタのカタ 驚異の業績を支える思考と行動のルーティン

トヨタのカタ 驚異の業績を支える思考と行動のルーティン

「タレント」の時代 世界で勝ち続ける企業の人材戦略論 (講談社現代新書)

「タレント」の時代 世界で勝ち続ける企業の人材戦略論 (講談社現代新書)

トヨタの強さの秘密 日本人の知らない日本最大のグローバル企業 (講談社現代新書)

トヨタの強さの秘密 日本人の知らない日本最大のグローバル企業 (講談社現代新書)

エクストリームプログラミング

エクストリームプログラミング

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?

IMPACT MAPPING インパクトのあるソフトウェアを作る

IMPACT MAPPING インパクトのあるソフトウェアを作る

アメリカ海軍に学ぶ「最強のチーム」のつくり方: 一人ひとりの能力を100%高めるマネジメント術 (知的生きかた文庫)

アメリカ海軍に学ぶ「最強のチーム」のつくり方: 一人ひとりの能力を100%高めるマネジメント術 (知的生きかた文庫)

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

HARD THINGS

HARD THINGS

ワーク・ルールズ！―君の生き方とリーダーシップを変える

ワーク・ルールズ！―君の生き方とリーダーシップを変える

蛇足 : 方法の反対は目的ではない

最近勉強していて当たり前？のことを知ったのですが、方法の反対を意味する語は目的ではないという。 目的のために方法があるだけであって、反対という意味ではないというか。 ロランバルトという思想家？の著書をいくつか読んでいるのですが、彼の考え方は非常に刺激的ですので、興味がある方は読んでみてはどうでしょうか。 （ちなみにこのような解釈における方法の反対は教養になります。方法は目的を価値とするけど、教養は縛られるものがないという意味）

というのをこういった方法論とか組織論とか価値とかビジョンを勉強して、自分で考えているときにそういったことを考えていないとまさしく無縄自縛っていう感じになってしまってよくないなぁと。 っていうのを考えるためには哲学とか言語の勉強が役に立っています！