わすれっぽいきみえ

みらいのじぶんにやさしくしてやる

読む本をどうやって見つけてくるのか

そういえば社会人として働き始める前からよく人に「どうやって本・映画を見つけてくるの?」と訊かれることに気がついた(おそい)。もちろん訊かれたそのときに無視せず答えてはいるけども、文章としてちゃんとまとめたことがなかったので、どうやって見つけるか習慣の話を書く。どのソースを当たっているかは書かない。

みたもの、きいたもの全部自分に関係があると思っている。直接私に向けられたものではなくても、自分の目に入ったら耳に入ったら自分に関係がある。突き詰めると自分に関係のないものは存在しない。すべての関係あるものの中から選ぶ。これが基本。

大事なことは「私はプログラマーであってデザイナーではない。だからデザインの話は関係ない」と考えるのではなく、「プログラマーだけどデザインの話が聞こえてきた。なんかデザインの話が私に関係あるのかもしれない」と考えることだ。「でもまぁ今はいいかな」というのは選ばないことにした、ということに過ぎない。

みたものきいたもの全部が自分に関係していると考える基本ができていたら周囲の何気ない情報が意識しなくても勝手に入ってくるようになる。喫茶店で誰かが『ミッション・インポッシブル』の話をしてて、なんだろうと振り返ってみたらその喫茶店にあるデカいモニターで『アイアンマン』がやってるなんてことはザラにある。その人たちの間で話が膨らんでったのか単にその人たちが映画タイトルを間違えてるのかはわからないけれども、そこから「そういや最近映画観てないな。最近何やってるんだろう」とか「この映画の原作マンガってどんなのなのかな。どのくらい映画と違うんだろう」とか探す・選ぶきっかけにつながる。

だからたまたま本のセールがやってることを知ったら何があるのか探してみる。本を見てみて読んでみようと思うものがなければ買わなければいい。本を見繕うより大事なことがあるなら、そのことに時間を割けばいい。ただそのときにいつも「本を見繕う時間がない」といきなり判断するんじゃなくて「これは何かのチャンスかもしれない」と考える基本がやっぱり重要で、「私には時間がない。だから本は探さない」というのは「私はデザイナーではない。だからデザインの話は関係ない」と言ってるのと一緒だ。

「どうやって本・映画を見つけてくるの?」と訊いてくる人の多くは「それにつながる重要なソースを知ってるんでしょ?」というつもりで訊いてくる。でもそうじゃない。初めから重要なソースがあるんじゃなくて普段から探してるから見つかる。これを言うと「ケチくさい」とか「教えてくれない」とか不平を言う人がいるんだが、本当に習慣が間違ってる。でもこの基本の習慣を身につけるのは難しいから楽してソースをあたろうとすることも気持ちとしてはわかる。私も「どうやって見つけてくるの?」という質問をすることはあるので、本当は耳が痛い。

いいものが見つかるソースを知ってるということも大切だが、正直私はあまりそういうソースを持ち合わせていないつもりで、「たまたま見聞きした何かをどう考えるか」について「全部自分に関係ある」と考えるようにしているから見つかるんだとしかあんまり言えない。それにいいソースを知ったところで、そこから読もう・探そうというモチベーションがなければ結局探さない。そんな風になるくらいなら「最近読んだ本の中でオススメのない?」と直接本のタイトル聞く方がまだマシだと思う。私は人からオススメの何かを聞かれる時、逆に「最後に読んだのどんなやつ?」とか「どういうジャンルがお好みでしょう?」とかまず聞き返すことが多い。

自分に関係があると考える習慣が完璧だとは思ってないが、その習慣がある程度はあるからなんかよさげなものが見つかるんだろう。初めから好きなものはほっといても目に入るから、好きかどうかは別として全部関係ある、例外はないと考える習慣は大事だと思う。よくどうやって興味を持つかが重要ですと本か何かで聞くけども興味が持てないから困ってるんだろ!と思うことも多いから、私はどうやって興味を持つかは深く考えないことにしてる。見たから手を出しました、っていう条件反射だ。見たんですけど気持ち悪いんで手を出しませんはアリ。ちゃんと選んでるから。でも基本の習慣が行き過ぎると全部欲しいと考える習慣につながるので、そこは今後の課題だと思う。

そんなことを考えながら以下の本を読んだ記憶があるけど、もう売っちゃいましたw(内容もあまり覚えてない)

フランス人は10着しか服を持たない~パリで学んだ“暮らしの質

フランス人は10着しか服を持たない~パリで学んだ“暮らしの質"を高める秘訣~

スニペットツールClipy便利

チームメンバーと話しながらPCいじってたときにメンバーの一人が何気なくスニペットツールを使ってて
「なんですかそれ!?」
と聞いたら教えてくれた。

clipy-app.com

ググるとちょいちょい記事が上がっている。

kimikimi714.hatenablog.com

ここで記載した簡単なタイトルとか毎回コピペすんのダルすぎるのでClipyのスニペット編集を開いて

f:id:kimikimi714:20170630161734p:plain

適当なショートカットキーを設定しつつこんな感じで登録すると

f:id:kimikimi714:20170630161634p:plain

こんなポップアップが出るようになって 1 pr を選ぶとぺって貼れるようになる。

便利。

ルフレッドにもあるらしいんだけど、そっちは使ってない。そっちのが便利と思ってる人もいるのかなー。

『第16回 Scrum Masters Night!』に参加した

smn.connpass.com

に参加してきた。スクラム関連の本は読んでたけど、これを実践・導入するのにはあまりにも知見がなさすぎたので勉強会で実践している先輩方からもっと話を聞いてこようと思った。

一旦参加者全員が話したいことをバーっと付箋に書いてホワイトボードに貼り付けて、自分が話したいテーマが書かれた付箋に1人2つまでシールを貼っていく。シールが多かった順に上から6つ選び、その中のどれかを自分で選んで、テーブル席で各自議論するという形式だった。

で、私が選んだテーマは『チームの生産性を上げるには?』。
生産性を上げるためにどんなことをスクラムでやってけばいいんだとか生産性が上がるってどういう状態なんだとかがよくわかんないなと思ったので、そのテーマの議論に参加することにした。

そのテーブル席ではファシリテーターの方が「『課題感』、『対策案』を付箋で各自出せるだけ出してみましょうか?」と言って開始したので、実際に付箋に書かれて出されたものを以下にざっと書く。

テーマ: チームの生産性を上げるには?

課題感

  • チームが成熟してくるとプロジェクト開始当初とストーリーポイントの内容が変わってくるはずだけど、その違いはどう測る?
    • どのタイミングでストーリーポイントの見直しを行うべきか
  • そもそも生産性って何?
    • ベロシティ/コスト = 生産性?
    • 生産性 = スピード?
    • ベロシティが上がったら生産性も上がったと言えるの?開発スピードが上がることだけが生産性向上と言えるの?
    • 数字にならない(なってない)ところで生産性が上がってたりもするのでは
    • 部署全体でKPIを改善すると言ってるけど、どんなKPIを設定すればいいの?
  • そもそも『生産性を上げましょう』ということがチームの命題となっている?

対策案

  • 生産性向上のKPIになりえるもの
    • story pointが特定スプリント内で計画的に消費されてく状態
    • デプロイ回数(頻度の方が正しそう)
    • pull request差し戻し回数
    • dev環境upから本番環境upまでのリードタイム
    • スクラムに充てる時間
      • 開発を進めたいのであってスクラム自体に時間を大量に充てるのは間違ってる
      • ある実働時間のうち、どのくらいの時間をスクラムに充てるのかは指標になりえる
  • 収益とコストとベロシティの関係を見える化する
  • スターマップの充実

目的

  • ベロシティ計測は計画性の担保
  • モチベーションアップ
  • ステークホルダーへの説明の材料

解あり?

  • 生産性を上げるために課題となっていることは何?
  • ベロシティ計測のツールに何を使ってる?

結論

  • そもそも生産性を上げるなら、生産性が上がった状態というのを定義してあげる必要があって、定義する役目はPOが負っている。POは生産性を上げるための定義をした上でチームと合意を取る必要がある
  • ベロシティは上げるものではなくて安定させるもの。ベロシティがずっと上がり続ける状態はそもそも異常な状態で、ベロシティは今の我々の実力で何がどのくらいの時間で終われるのかを示すための指標。その指標がブレブレだと見積もりが破綻していることを表してるので、まずは安定させることを第一に考える。
    • そのうえで成熟したチームになるとベロシティを測るために使用していたストーリーポイントの中身がプロジェクト開始時期よりも濃いものになっているはずで、ここは定期的に見直していく必要がある
  • トーリーポイントが振られてないチケットが存在すること自体は問題ではなくて、チームのベロシティを計測するのに値するチケットをスプリントに入れることが重要。もし混乱するのであれば、異なるスプリントを作るなりしてチケットをベロシティ計測のものと分離するのも一つの方法。
    • ただしその方法を取ると本来ユーザーに価値を届けるために進めているスプリントがチーム開発のやりやすさを優先させたスプリントに変容してしまう可能性があって、運用に注意が必要になる。
    • 勉強会が始まる前に社内の先輩とちょっと話した感じでは、ある期間にやろうとしていることを同一スプリント内で回す必要はないよねという話は出ていた。(単に見せ方の問題も含まれてるかも)
  • 一個のチケットに振られたストーリーポイントが異常に大きい場合はタスクを細分化するための調査チケットを別に切る運用をしている
    • これはすでにうちのチームでもやってる
    • あるチームでは8ポイント以上、あるチームでは5ポイント以上だと細分化が必要という感覚値らしい。この辺も結構うちのチームでの実感値と近かった。

大体こんな感じでお話が進んだ。

社内チームでやってきたことは間違ってなかったんだな!と思う瞬間があったのは良かった。一方で本当に悲しいことに、ここで議論する以前の問題がチーム開発で発生しているなーと思う部分もあった。

またこの日の勉強会で、アメリカではスクラム開発で戦闘機を半年で作るらしいことを聞いた。戦闘機を開発するプロセスをちゃんと知らないので内心それが本当に早いのか遅いのかよくわからないけど、なんかすごい気持ちにはなった。戦闘機を作るプロセスに必要なものがある程度わかっていて、熟練のスクラムマスターとかがいたら半年ってそんなに変な数字じゃない気がするけど、新しく研究開発した戦闘機を半年で作るって話なら相当に早い気がする。背景が知りたい。

f:id:kimikimi714:20170613004614j:plain