ネットの海の片隅で

技術ネタの放流、あるいは不法投棄。

Ruboty で TRPG をする

Ruby 思いつき gem

Ruboty pluginを書いたので簡単に紹介しておく。

使い方

1d100, 3d6 などの文字列を ruboty roll に渡すと、ダイスの出目と出目の合計値が出力される。

> ruboty roll 3d6
[2, 4, 5] => 11
> ruboty roll 1d100
[41] => 41

擬似乱数の生成は SecureRandom。

きっかけ

休日に何もやる気が起きなくて、クトゥルフ神話 TPRG のリプレイ動画を見ていたところ、無性に自分でもプレイしたくなり、「オンセをするときに Slack を使ったら便利なのでは？」という発想から、「とりあえずダイスを振るための plugin を書こう！」となった。

問題

ダイスロールする Ruboty plugin はできたけど、一緒に TRPG をやる友達がいない。

ruboty-tomodachi が必要。

価値のないものを高速につくらないために

気持ち

スピードとスピード感は違うし、素早くつくることと雑につくることも違う。

我々の仕事がコードを書くことではなく問題を解決することである以上、どんなに素早くつくるとしても誰のどんな問題を解決するのかは常に意識していなければならない。 その点について深く考えずに思いつきで「A すれば B できるようになる」というものをつくるのは素早いのではなく雑なものづくりだと思っている。

そもそも「〜できる」ということにはあまり価値がないと思っていて、「〜するようになる」「〜してしまうようになる」というように行動が変わるところまで意識的に持っていかなければならないと考えている。 *1

面と向かって他者の行動を変えるのだってめちゃくちゃ大変なのに、インターネット越しに画面だけでユーザーの行動を変えるということがそんなに簡単にできるはずがない。 だから、画面の向こうにいる人に対して何かしらのアクションを引き起こさせようと思うのであれば、その人が抱えている問題や欲求を可能な限り理解しようとした上でその欲求に従うものをつくらないといけない。

でなければ、「機能」はつくれたとしても行動を変えられない。

また、開発者はユーザーそのものではないので、どんなに時間をかけて考えたとしても、最終的には実際にリリースしてみないと本当に価値があるのかどうかはわからない。 しかし、それは問題や欲求について考えなくても良いという理由にはならない。

速度という点では、リリースと測定のサイクルよりもチーム内での対話の方が数段速い。自分の頭の中で考えるのはもっと速い。

仮説検証という点では、ちゃんと考えてもいないものに対して一体何を検証するというのか。南波六太の言葉を借りると「本気でやった場合に限るよ。本気の失敗には価値がある」。

リーンは雑な開発の言い訳じゃない。

以上、価値のないものを高速に作っても仕方がないというお気持ちでした。

*1:もちろん例外はある。強い欲求によってすぐに行動に繋がるケースはあるし、できるようになることそのものに一定の価値があるものもある。

スピード感のために品質を落とすということはチームの成長を諦めるということ

気持ち

サービスを開発していると、スピードが重視される。 そのこと自体にはまったく問題はなくて正当なことだと思っている。 ユーザーに対して一刻も早く価値を届けるためには必要なことだ。

そもそも、自分がいる Web 界隈ではこの点について異論のあるサービス開発者はあまりいないんじゃないかと思っている。

ただ、それを達成するための方法になると途端に意見が分かれはじめて、人によって重視することが全然違ってくる。

ある人は「スピード感が大事」と言い、ある人は「ちゃんと作ったほうがトータルでは速い」と主張する。

しかし、こういうときに意識される品質と速度についてのトレードオフは、実際には完全なトレードオフではないと思っている。

技術力のある人はある程度急いで作ったとしても一定以上の品質のコードを書くし、意図的に品質を落としたとしても速度はあまり上がらない。 逆に、技術力が高くない人が時間をかけて作ったとしてもその人の技術力以上の品質のコードは書けない。

では、品質と速度についてのトレードオフが意識されるとき、実際には何と何が秤にかけられているのか。

それは各個人ではなくプロダクト全体の品質と速度が秤にかけられているのではないか。 言い換えれば、プロダクトの品質を支えるために必要なメンバーの成長とその成長のために必要なフィードバックや学習の時間が秤にかけられているのではないかと思う。

先述の通り、個々人の速度は品質を上下させたところで大きくは変えられない。 しかし、レビューの工数を削減したり受けたフィードバックを反映する時間を削ったりすれば、PR をマージするまでの時間は大きく短縮できる。そして、結果として短期的な開発速度は向上する。

一方でレビューやフィードバックの時間やそれらを実際に適用してみるために考えて手を動かす時間を削ると、メンバー同士がお互いを高めあっていくことができなくなる。 すると、プロダクト全体の品質はいつまでたっても上がらず、チームも成長しないままになる。

現実世界はつらくきびしいので、チームの成長のために無限に時間を使うことはできない。しかし、価値を素早く届けるためには、それを可能にするチームを作っていくことも間違いなく必要なのではないか。 そんなお話。