大きな会社ではないけど、素晴らしいものを作っている方たち

• インディーな感じだけど、とっても素晴らしいソフトウェアを作っている会社や団体、個人はたくさんある
• どれも作っている人の顔や考え方が見える感じで、親近感を覚える
• 僕がよく使っているものとかを書いておく

esa LLC

作っているもの

• markdown対応のドキュメントツールである https://esa.io/
• もう一つ、https://pplog.net/ も作っている

好きな理由

• デザイナーさんが、チームの中心にいらっしゃるからか、デザインがとってもいい
• もちろん、アプリケーションの使い勝手もよい
• pplogは、とても素晴らしい

Flask LLP

作っているもの

• http://flaskapp.com/ja/zones/ とかhttp://flaskapp.com/ja/standland/ を作っている
• 僕は、standlandを使っている。
• 健康系のiOSアプリが多い印象だけど、他にも色々作っている

好きな理由

• 必須アプリじゃないけど、同じことやるなら、iPhone純正より、こっちを選びたくなる感じ
• デザインとかキャラクターとかの感じが、そうさせるんだろうと思う
• どのアプリもFlaskな感じがする
• お二人でやられているようなので、色んな基準が明確なんだろうな

個人開発者(Takuya Matsuyama)

作っているもの

• https://www.inkdrop.info/ のみのよう。最近使い始めて、お気に入り。

好きな理由

• markdownが使えて、マルチデバイス対応なアプリケーションが欲しかった
• たぶん、作られている方と課題感が一緒だったのだと思う
• 今までsimplenote使ってたけど、なんか嬉しくなって、乗り換えた

NOTA Inc.

作っているもの

https://gyazo.com/ja が有名なのでは。最近だと、https://scrapbox.io/　も作っている。

好きな理由

• ソフトウェアのアイデアが独特
• 確固たる哲学があって、それがアプリケーションに反映されている感じ
• その考え方込で、アプリケーションを使いたくなる
• たぶん、インディーって感じではないけど

所感

• もっとこういう会社増えて欲しいし、ソフトウェアを選ぶときは、積極的にそういう選択をしたい

生産性高く仕事するための良い習慣の作り方

僕は、マネジャーの重要な役割の1つは、「チームの仕事を生産的なものにする」ことだと考えています。それについて書きます。

良い習慣を身につけ、生産的に仕事をする

生活はもとより仕事においても、多くのタスクは習慣的なもので溢れていると思っています。大抵は何かの繰り返しであり、イレギュラーに見えるものもよく紐解くと習慣的なものであると思います。

なので、良い習慣を身に着けていなければ、アウトプットもよいものにならないと思っています。では、どうすれば良い習慣を身につけられ、どうすれば実際の業務に反映することができるのでしょうか。

それを実行するために、僕が以前にマネジメントしていたチームでは、そもそも習慣とはどういう仕組なのかを『習慣の力』 という本に書かれている内容をもとに定義し、ツールとして、trelloとesaを使うことで、良い習慣を利用した業務フローを構築する取り組みをしていたので、それを共有します。

『習慣の力』とは

この本。とりあえず神本だから読んでみてほしいです。

習慣の力　Ｔｈｅ　Ｐｏｗｅｒ　ｏｆ　Ｈａｂｉｔ

この本によると、習慣とは「きっかけ→ルーチン→報酬 」のループであるとされています。そして、習慣を良いものするには、「きっかけ」と「報酬」はそのままにし、「ルーチン」の部分だけ変えていく必要があると書かれています。というのも、欲求とその報酬を変えるのは難しく、ルーチンである行動の部分を正しい物や代替物にすることが、良い習慣に変えていく方法であるとまとめています。

本には、個人や企業、社会活動などでの習慣の例などが取り上げられています。巻末には、午後についついドーナツを食べてしまうという習慣により、太ってしまうという著者の事例が取り上げられていました。「ついついドーナツを食べてしまう」という習慣を変更するために、欲求とは「気持ちを切り替えたい」であり、それを解決することの報酬は「リフレッシュした気持ち」と定義していました。そして、そのルーチンである「ドーナツを食べる」を「友人のデスクに行って喋る」に変更することで、太ることなく、午後もリフレッシュして仕事ができるようになったとされています。

業務における習慣

業務は習慣的なタスクで溢れていて、また、イレギュラーに思えることも、因数分解すれば、通常タスクの変化形であると思います。以下の意見には、僕も賛成しています。

いろんなイレギュラーパターンがあるわけですが、本当の「イレギュラー」なんてなくて、ほとんどのものが再発します。発生頻度が少ないものほど、対応に不慣れでオペレーションを乱すので、イレギュラー対応こそきっちり決めておく。http://tech.cunited.jp/post/158911521565/manual2nd

業務を生産的にするには、発生頻度の高いものはもちろん、頻度が低いものも、対応方針を決め、正しい習慣を作っておくことが重要だと思います。

具体的な方法

習慣における、「きっかけ」と 「報酬」 の具現化のために、trelloを使っていました。

trello.com

また、正しい「ルーチン」の定義のために、esaを利用していました。

esa.io

trello と esaの運用方法

trello は、backlog, todo, doing, waiting, done, master というリストを作成し、運用していました。 すでに習慣的なタスクとして認識されているものは、master に登録されています。masterのカードは、trelloのプラグインを利用し、必要になったタイミングで、todo リストに自動でコピーされるようになっています。

ルールとして、担当者は、todo を実施する時は、doing に移動してから、タスクに取り掛かる必要があります。そして、そのタスクの正しいルーチンは、esaに書かれていますし、もし書かれていなければ、原則的にはesaに記事を書いてから業務に取り掛かる必要があります。当然、esaの内容は、チームのナレッジになっていきます。実際には以下のような記事を作っています。

担当者は、タスクが終わったら、カードをdoneに移動します。もし待ちが発生するタスクであれば、waitingに移動し、関係者からの連絡を待ちます。突発的に発生したタスクは、backlog にカードを作り、適宜todo に移動します。すぐにやるべきものは、始めからtodo リストに記載してもかまいません。

上記の従って行動していると、カードは、master/backlog → todo → doing → (waiting) → done のように左のリストから右のリストに流れていくので、タスクが処理されていく姿が視覚的ににわかります。チームのメンバーは、常に整理されているタスクリストが手元にあり、視覚的にも業務が前進している状態を保つことができ、その事自体がタスクを処理する報酬として機能するようになります。

さらに

esaの内容は、ルールではなくプリンシプルが書かれているようにしたい

esa.io の内容は、もっとプリンシプルであって欲しいと思っています。ソフトウェアの操作を示した指示書や行動する前に読むルールのようなものも多かったです。。ソフトウェアを「どのように操作すべきか」は、それ自体で判断できる方が理想的だし、esaには、そのタスクの合格基準を示したプリンシプルが書かれたものであってほしいと思っています。最低限対応すべき基準や、どういう姿勢で行動するべきかなどの大枠を示したチェックリストさえあれば、本来、人は自律的に行動をしていくものと思っています。チェックリストについては、以下の本がとても参考になります。

アナタはなぜチェックリストを使わないのか？【ミスを最大限に減らしベストの決断力を持つ！】

報酬

報酬も、もっと顧客満足度やKPIの達成に紐づくようなものも加えていくべきと思います。

もっともっとコミュニティっぽく

『習慣の力』には、良い習慣を身につけるためには、「信じる力」は重要だとされています。自分より大きな存在である偉大な力への信頼を、コミュニティを通じて感じている人のほうが、良い習慣を身に着けられていると書かれています。 会社やチーム自体が、もっともっとコミュニティ的であり、ここに所属していれば、偉大なことを達成できると信じられる存在であることが、働いている人に良い習慣を身に着けさせ、良い行動を引き出していくのだと思います。

macOSのページ間スワイプを無効化する

osXのトラックパッドの2本指でのページ間スワイプ、ほぼ使わないくせに、たまに書いている内容とかを消しちゃうときあるので、無効化しておいたほうがいいですよね。

gyazo.com

メソッドを定義する

MyClassにインスタンスメソッドを定義する

class MyClass
  def self.add_method(m, &b)
    self.class_eval do
     define_method(m, &b)
    end
  end
end

MyClass.add_method(:greet){"Hello"}
puts mc.greet
#=> Hello

参考

http://amzn.asia/cNuFgVL

is_a? メソッド

obj.is_a?(Klass)

objがKlassまたはそのサブクラスのインスタンスかどうかを判定する。

arr = [1, 2, 3]
puts arr.kind_of?(Hash)
puts arr.kind_of?(Array)
puts arr.kind_of?(Object)
puts arr.kind_of?(Enumerable)

使い方

objがKlassをインクルードしているかを判定する時に使える。そのままだな。。。

module MyModule
end

class MyClass
  include MyModule
end

mc = MyClass.new
puts mc.is_a?(MyModule)
#=> trure

参考URL

http://ref.xaio.jp/ruby/classes/object/kind_of

sendメソッド

rubyのクラスマクロとか調べてたら出てきたので自分メモ用に書きます。素人ですみません。

object.send(name,*args)

• レシーバ(object)の持っているメソッドを呼び出す
• 第1引数nameには、メソッド名をシンボルか文字列で渡す
• メソッドに引数を渡したいときは、第2引数args以降に引数を並べる
• 戻り値は、呼び出したメソッドの戻り値が変える
• sendが再定義された場合に備えて、別名の __send__ がある

class MyClass
  def hoge(n = nil)
    n ? Array.new(n, "hoge") : "hoge!"
  end
end

mc = MyClass.new
mc.send(:hoge)
#=> hoge
mc.send(:hoge, 3)
#=> ["hoge", "hoge", "hoge"]

使いどころ

オブジェクトに渡すメソッドを動的に指定できる？とか？わかりません。

参考URL

http://ref.xaio.jp/ruby/classes/object/send http://ref.xaio.jp/ruby/classes/object/send http://blog.livedoor.jp/badrequest400/archives/2350825.html

【翻訳】TDD is Fun

@solnicが、DHHの例の記事へのカウンター的な記事をポストしてまして、自分のために読んでみたらよい内容だと思ったので、翻訳してみました。翻訳ミスとかあると思いますが、、、すみませんです。。。

TDD is Fun

Posted by solnic on Apr 23 2014

著 solnic 2014年4月23日

Today DHH published a blog post about TDD being dead (to him at least). It’s really not that surprising since from what I know (please correct me if I’m wrong) David’s experience is mostly based on building web apps with Rails. I get that, I really do. For me practicing TDD in a rails environment is much harder than when I work on my OSS libraries. There are many reasons why TDD in Rails is just a bit harder than it could be but that’s a big, separate subject. In this post I want to explain that TDD can be fun!

今日、DHHは (少なくとも彼にとっては) TDDが終わったことについてブログ記事を発表しました。私の知っているところでは (もし私が間違っていたら指摘してください)、Davidの経験のほとんどがRailsでのウェブアプリ構築に基づいているので、これは全く驚くようなことではありません。私にはよくわかりますし、本当にそうだと思います。私にとって、Rails環境でTDDを実践することは、自分のOSSライブラリで実践する時よりずっと大変です。RailsでのTDDがあるべきより少しばかり大変なのには多くの理由がありますが、それは大きな別の議題なのです。この記事では、TDDは面白いということを説明しましょう！

it’s not as strict as you think

There are many guidelines in TDD. That you should focus mostly on unit testing. That you should be using mocks and stubs in isolated unit tests. That you should have contract tests. And so on. That list can be pretty long.

あなたが考えているほど厳格ではない

TDDには多くのガイドラインがあります。「主に単体テストにフォーカスすべきだ」や「独立した単体テストではモックやスタブが使われるべきだ」とか、「contract testsを利用するべきだ」などです。そのリストはかなり長いです。

Those are guidelines, they make a lot of sense and personally I found them to be useful but for me, when it comes to the core of TDD…it’s this:

それらはガイドラインであり、それらは大いに意味があり、個人的には有用であると理解していますが、TDDのコアというのは…以下だと思います。

Write a test that describes expected behavior of your system and make it pass.

Yes, that’s it. That’s how your journey begins. It doesn’t have to be a unit test. It can be an integration test. It can be an acceptance test (which is great when building web apps!). You simply know what kind of test you are able to write at a given point in time based on your current knowledge. This knowledge will be expanding as you go through red/green/refactor cycles. You will see missing interfaces, you will be able to introduce new objects and test-drive them from the start because after few refactorings you will know, trust me, you will know how they should look like.

自分のシステムにおいて期待する振る舞いを記述するテストを書き、それをパスさせなさい

そう、これなんです。これが出発点ということなのです。単体テストである必要もありません。承認テストかもしれませんし、受け入れテストでもかまいません (それは、ウェブアプリを作る場合には、とても有効です!)。その時の知識に基づいて、その時点でどんなテストを作成できるかをあなたはよく分かっているはずです。その知識はred/green/refactorサイクルを通して、拡大していくでしょう。そして、足りないインターフェースを理解し、最初から新しいオブジェクトやテスト駆動を導入するでしょう。というのも、数回のリファクタリングの後に、あなたは分かるように、いや本当に、あなたはテストがどのようにあるべきか分かるようになるからなのです。

That’s how tests are guiding you, that’s how you’re designing your system based on the feedback of your tests. It’s a process, a journey that involves many small refactorings. You don’t stop after making your first test pass. You move on and discover missing pieces of the puzzle. It’s a lot of fun and it gives you great confidence that the code you just wrote works exactly like you want.

そのようにして、テストはあなたを導き、あなたはテストの結果に従って自分のシステムを設計するでしょう。それは、多くの小さなリファクタリングを伴うプロセスであり、長い工程なのです。最初のテストをパスしたからといって、止まってはなりません。どんどん進んで、パズルの足りないピースを探してください。それはとても面白く、あなたが書いたコードがまさに思いどおりに動く大きな自信を与えてくれます。

Unit testing

It seems like DHH confuses unit testing with TDD. Unit testing is part of TDD and it’s a very crucial part. Most of the nastiest, hardest to fix bugs exist because of a poor unit test coverage. That’s a fact.

単体テスト

DHHは単体テストとTDDを混同しているようです。単体テストはTDDの一部、極めて重要な一部です。たいていのバグフィックスが不快で大変なのは、単体テストのカバレッジが不十分だからです。これは真実です。

Some people are afraid of unit testing though and this is also not that surprising. It’s mostly because the cost of maintaining a big unit test suite is high. It’s very easy to spend a lot of time writing many small, focused unit tests that soon turn out to be obsolete and that hurts a lot.

一部の人が単体テストをいやがっているが、それもまたやはり驚くようなことではありません。というのも、大抵、大規模な単体テスト一式をメンテナンスするにはコストがかかるからです。すぐに使い物にならなくなり、苦痛うを伴う小さくて焦点の合わさった単体テストを書くことに多くの時間が簡単にかかってしまいます。

I think this happens because of two reasons:

• Writing unit tests too early
• Using mocks and stubs prematurely

私はこれには2つ理由があると思います。

• 単体テストをあまりに早くに書いている
• モックやスタブを使う段階ではないのに使っている

We’ve been told that a unit test excercises a unit in complete isolation from the surrounding environment especially its dependencies. That’s a really nice concept and it works very well. But…you really need to feel confident about what you’re doing before you introduce unit tests. This can be achieved rather quickly after 1 maybe 2 red/green/refactor cycles after making some higher level test pass. You will see missing abstractions and you will know what kind of an interface you want to have. That’s a great moment to start writing unit tests.

単体テストは、取り巻く環境、特にその依存性から完全に独立して用いるものだと教えられてきました。それはとてもよい概念で、とてもうまく働きます。しかし、単体テストを導入する前に、あなたが行おうとしていることに自信を持つことが必ず必要なのです。これは、上位レベルのテストが通った後、red/green/refactorサイクルを1,2回実施した後、かなりすばやく達成できます。足りないアブストラクションを理解し、どういう種類のインターフェースをもつべきか理解できるでしょう。そのときが、単体テストを書くべき時なのです。

There are also cases where you’re just prototyping something. This is really a bad moment for unit testing.

何かをただプロトタイピングしている場合があります。こういう時に単体テストを書くことは最悪です。

Another pain-point in unit testing that probably discouraged DHH is using mocks and stubs. If you do things “by the book” you would immediately start mocking dependencies and stubbing various method calls. For me it never works like that. Sometimes I would mock an interface as soon as I discover it. Another time I would just wait with mocking until I feel really confident that a given collaborator object shouldn’t be treated as an internal implementation detail. There are many guidelines here as well, learn about them and keep them in mind but don’t follow them strictly all the time.

たぶん、DHHのやる気を失わせたユニットテストの中での問題点は、おそらくモックとスタブを使うことでしょう。もしあなたが「型通り」に行おうとすれば、すぐに依存性をモックし始め、さまざまなメソッドの呼び出しをスタブすることでしょう。私は、これはうまく働かないと考えます。時々、私はインターフェースを見つけるとすぐに、それをモックします。別の場合には、ある共同して動くオブジェクトを内部の実装詳細として取り扱うべきでないということに、本当に自信が持てるまでずっと、モックを使うのを待つでしょう。多くのガイドラインがあり、それは学ぶべきですし、心に留めておくべきですが、それらに常に厳密に従う必要はありません。

It’s fun but it takes time to learn

You can’t buy a book about TDD and learn it in a month. It takes a lot of time and that’s why trying to be very strict about various TDD guidelines (especially the ones about unit testing) will be frustrating.

面白いが学ぶのに時間はかかります

TDDに関する本を買って、それを1か月で習得することはできません。長い時間がかかり、そのため、様々なTDDガイドライン (特に単体テストに関するものは) にあまり厳密であろうとすると、いらいらすることになるでしょう。

This doesn’t change the fact TDD is a lot of fun. Just be cool with it. If you manage to teach yourself to write tests first, you already gain a lot. Break the rules whenever you feel they are blocking you or slowing you down. If you broke a rule and ended up with problematic code you’ll at least learn why following that rule in a given context is a good idea.

TDDがとても面白いことを変えるわけではありません。ただ冷静であるべきなのです。とにかくテストがうまく書けるようになれば、あなたは多くを得ます。テストがあなたを妨げたり、遅らせたりすると感じたらいつでも、ルールを破るべきです。ルールを破って問題を持つコードになってしまっても、その文脈ではルールに従うことは良いことであると、すくなくとも学べるでしょう。

Chill out, doesn’t matter if you get things right during first or fifth attempt, the process is all that counts. Write a test, make it pass, look at the code and take it from there.

冷静になりましょう。最初か5回目かの試みの間で正しさを得るかは問題ではありません。プロセスがそのすべての論点なのです。テストを書き、それをパスし、コードを見て、そこからそれを続ければいいのです。