アジャイルなストーリーポイントを使う見積もりの話

アジャイルな見積もりと計画づくりを読んでいる。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

今回は、第４章を読んだ。

第４章は、「ストーリーポイントによる規模の見積もり」について書いていた。

ざっくりと説明すると、開発する単位をストーリーという単位に分けて、それに対して規模を表すポイントをつけ、イテレーションでチームが消化するポイント（ベロシティと呼ぶ）を元に、スケジュールを導出する見積もりの方法の話が書いてあった。

例えば、

• ストーリーAは３ポイント
• ストーリーBは８ポイント
• ストーリーCは６ポイント

みたいな感じでポイントをつける。そして、すべてのストーリーのポイントを合計する。合計ポイントが１００ポイントの状況で、チームのベロシティが５なら２０イテレーションかかる。というふうに考える。

本のどこに書いてあったか忘れたけど、一回のイテレーションは、期間で区切られていて、一回の期間は、一週間とか二週間とか何だと思う。

この本の中でも書いていたけど、アジャイルな見積もりの特徴は、「規模を見積もって、期間を導出すること」らしい。

僕はこういう〇〇技法を聞くと、とりあえず試しながら考えてみたくなる。

ソフトウェア開発の話なのにソフトウェアでなく、音楽制作に転用してみるとか、個人的な用事に転用してみるとか、とりあえずやることがいくつかあって、スケジュールを見積もりたいと思ったらこの方法を使ってスケジュールをイメージしてみる。

じゃあ色々気になることが見えてきたりした。

まず、この見積もりの技法は、プロジェクトに複数のメンバーが専任になってない限り、効果が半減すると思う。

なぜかというと、この見積もり技法では、チームの過去のベロシティによって未来のベロシティの予測精度が高くなるから、見積もりの精度が上がっていく、という前提がある。

なのに、プロジェクトに複数のメンバーがいて、それぞれのメンバーが専任ではない限り、ベロシティが変化していく。

ベロシティが変化していくと、スケジュール見積もりの精度が上がらない。

それでも、ストーリーポイントを使った相対的な作業量見積もりは、生きると思うので、意味はあると思う。

あと、メンバーがある程度、専任というか固定で進める何かの場合、ベロシティは、そんなに上がらないけど下がりもしないように見えていて、すごい効果がありそう、というか、予測精度が上がっていきそうな感じがある。

それから、個人的に長い目で見てやっていた音楽制作にこの話を当てはめて見たら、一つ一つのイテレーション単位が長い割に、ベロシティが低い、という見積もりになってしまった。

なんていうか、本気出したら、ベロシティが数倍に上がるような状況になってしまって、この見積もりってなんか意味あるのかな、みたいな感じになった。

新しい本棚を買った

新しい本棚を買った。

本棚はニトリで買った。

Webで品揃えを見て、いい感じのやつを探して、寸法を測ってから買った。

買ったのはこれ。

本棚(グレン BS18120) | ニトリ公式通販 家具・インテリア・生活雑貨通販のニトリネット

買う前は、本が溢れているので、大きな本棚が欲しいと思ってたくらいだったんだけど、買ってみると予想より良かった。

区画がたくさん分かれてるけど、１つ１つの区画に『この区画は、最近読みたいと思ってる技術系の本を入れよう』『ここは、悩んだ時に読む本にしよう』『ここは、たまに見返したい本にしよう』みたいな感じで整理できていい。

家に大きい本棚は２つあるけど、新しい本棚がきたことで、前からある本棚は、アーカイブする前の本棚で、この本棚は一次キャッシュみたいな雰囲気になった。

ちなみに家から溢れた本は、今のところ、サマリーポケットと言うサービスで預けてる。アーカイブ。

読んだ本はとりあえずおいといて、将来的に家を自分の読んだ本でいっぱいにしたい気持ちがある。

僕は、何か新しい事をはじめる時に、その分野で気になる内容を扱った本を数冊買う癖があって、それらを流し読みしてから自分で考えつつ進めていくような状況になってる。

だから、自分の読んだ本の山は、自分がどんなことに関わったのか、自分がどんな情報に囲まれてきたのか、とかまあ自分に関する流れというかなんかを示す何かになってる。

爺さんになって、やること無くなって隠居するかな〜と思ったら、ふむふむ、しながら眺めて、本でも書くかなあ。とか思ってる。

ただ、今のところ、それまで読まないような気のする本も邪魔さが目立つ本はサマリーポケットに預けてる。例えば、新卒の就活本とかまあ読まないよね。

今のところ、50冊を月々250円で預かってもらってる状態。だから、一冊5円で一月預かってもらってる。

預けていて、読まないなら、キャプチャして売ればいいのでは？と思うかもしれないけど、将来的に家に本の壁を作って、ふむふむ、とやりたい僕としては、とりあえず所有しておいときたい気持ちがある。

一度売って買い直すパターンを考えるにしても、仮に一冊中古で送料込み600円で集められるなら、12年保管した場合と費用が同じだなあ。量が多くなってきたら、スケールメリットが聞いて、保管方法がほにゃらら、みたいな感じ。まあ、さすがに本当に要らないと思う本は処分していきたい。

話は戻って、ニトリで買い物する時に気になったシステムの話がある。

それはWebで在庫が見れるんだけど、家から取り置きの依頼をしようとした。多分、全店舗の問い合わせ電話を統括するコールセンターにかかった。

そこで、取り置きの依頼をすると、店頭の在庫情報とはタイムラグがあって、店頭の販売員から折り返し連絡させると言われた。

タイムラグがあるってことは、Webで見てる在庫管理システムと店頭の販売システムが違うのかなあ。バッチで連携してるのかなあ。とか思ってた。

ただ、実際に店舗に行ってみて、確かに家具とかモノって、店で買うために持って歩かれてるケースがあるから、Webだけ見て在庫ガードしたら、めんどくさいケースになりそうだなあ。と思った。

あと、コールセンターが中央集約してるのは良さそう。現場が問い合わせ電話に忙殺されないし。

それから店舗に行ったあと、諸事情により待ち時間があったので店員の動きを見てたら、店員がしきりにPCを見てる印象があった。なんか業務通知がPCで来るのかなあ。

小売店もいろんなところがシステム化されてるよなあとしみじみ思った。

こんなにシステム化されてたら、新参の会社が参入しようにも、システムにかかる初期投資が厳しすぎて、参入障壁がなかなか高そうだなあと思った。

まあ、世の中の商売はだいたい参入障壁が高いんだろう。

投資信託をはじめた

今日の午前中の成果報告をします！

• 投資信託の説明を受けた。
• 投資信託の口座を作った。
• 投資信託は難しいと思った。

投資信託をやったことなかったんですが、何事も経験かなあ、みたいな感じではじめました。

某銀行は、土日に相談できる様子だったので相談してきた。

ちなみにスケジュールはWebで予約できた。 電話じゃなくて良いのはありがたい。

とりあえず、お金が関わるからなのだろうと思うけど、いろいろ手続きが大変な感じだった。

新しい事を始めたときはいつもそうだけど、わからない単語が多い。

わからない単語が多いと、煙にまかれた気分になるので、１つ１つ確認していった。

まあ全ての単語を理解することはいきなり無理なので、個人的に大切なところを重点的に聞いた。

特に重要だと思ってるは何かというと辞め方。

はじまりのある事は必ず終わりがあるので、どうやったら辞められるのかを詳しく聞いた。

あと、やめる条件はもう少し詳しく検討しようと思ってるけど、今のところは期間で区切って考えるのがいいかなーという感じ。

今のところ、いろんな数字があるなあと思いながら見てて、それを自分がどう思うとか、どれくらい見れるかとか、何が気になるとか、いろいろやって見てわかる部分が多いので、失敗してもダメージが少ない状態にして、勉強したいなあという気持ち。

いい感じに考えたい

帰り道で仕事とお金についてぼんやりと考えていた。

自社サービスの開発に関わる仕事をしていると、そういうことを考えたくなるんだろうなあと思う。

何をどれだけやったらいくらもらえる、ってわかってると、それにどれくらいのエネルギーを割くかを考えられると思う。

んだけど、自社サービスだと、やった結果として、いくら出てくるか、がなかなかわからない感じがあるなあとか思ってる。

まあでも、音楽にしても同じで、何かを創り出す時はその創り出しているのが良いのか悪いのかがなかなか見えないものだと思う。

いわゆる、生みの苦しみ、なんだろうなあとか思ったりしてる。それを楽しめるようになると強そう。

そういう風に新しいものを作ってる時、どんなものを作るか作らないか、何をどこまで出すか、いつ出すか、どう出すか、クオリティは？とか、いろいろ考えることがあるし、その辺りを間違えると、今までやってきたことが無駄になるかもしれない、みたいなのもあって、いろいろ難しい。

とはいえ、考えてもよくわからないところもあるし、考えすぎてもメンタル的にあかん感じがするので、いい感じに考えるのが大切なんじゃないかなあという身もふたもない事を考えた。

相談について難しく考えすぎる

今日はダラダラと考えてることを書く。

今日は会社でメンタルヘルス的な研修を受けた。

その中で『精神的な健康を保つために相談した方が良い。相談できる人はいますか？』みたいな話を聞いた。

相談できる人か〜、、、、相談できる人、というか相談にのってほしいという話をしたときに相談にのってくれる人は、周りにたくさんいるような気がするなあ、と思った。

ただ、実際に、相談するとなるとどうしたらいいんだろう、と思うところがあった。

ただ単に僕の相談スキルが低いというのはあるんだけど、そもそも、相談ってなんなんだろう。と思ってるところがあって、どうやって相談すればいいんだろう、と思ったりする。

相談とは、、、相談、難しい。

で、その研修の中で、講師の方が言っていた話が気になった。それは、『相談しなくても、相談の機能を果たす何かをすれば良い』という話。

なるほど、相談の機能。

相談の機能とは、、、

一気にソフトウェア感出てきたなあ、と思った。

というわけで、研修終了後に、相談の機能って何なのか、を質問してみた。

話を聞いていると、相談の機能は、「問題解決のヒントを得ること」「問題が明確化すること」に聞こえた。

なるほど。ふむふむ。こういうことかなあ。と僕は思った。

機能１：「問題解決のヒントを得ること」 INPUT：問題 OUTPUT：問題解決のヒント

機能２：「問題が明確化すること」 INPUT：悩み OUTPUT：明確化された問題

うーん、ただ、これだけ聞くと、ちょっと相談するのは気がひけるとも思った。まず「問題解決のヒントを得ること」って、『本読む』、『インターネット調べる』『自分で試して見る』とか、「人に相談する」以外にも、いろんな方法があると思っている。

同じように、「問題が明確化すること」って、 『一人で文章書く』『思考を紙に書き出す』、『思考のフレームワークを使って考える』、とかいろんな方法があると思ってる。

その中で、「人に相談する」というのは、相談する相手の時間を使う。個人的には、時間って、人生の中でかなり重要なリソースだと思っていて、他の人のそれを気軽に消費するのは、なんか違和感あるし、失礼だなあ。と思う。

じゃあ、相談しなくていいの？っていうと、それはちょっと違うなあと思うし、なんとなく相談したほうがいいと思う気持ちがあって、どうしたらいいかなーとか思う。

例えば仕事だったら、相談することで、もっといい感じのやり方が見つかるのかもしれない。スピードアップするかもしれないし、罠にハマるのを回避できるかもしれない。そもそも僕１人で考えたことは、『ぼくのかんがえたさいきょうのすすめかた』みたいな何かでしかないので、他の人の意見をとりいれたい気持ちがある。

で、そう思ってるときに、僕はとりあえず相談したい人に『最近、こんな感じでやってるんですが、どうですか？』とか『今のこれを、どう思いますか？』とか聞いたりする。

ただ、これの質問は、聞かれる立場からすると、けっこう困りやすい質問のようで『どうですかって何なの？』『どう思うって、どういうこと？』みたいな話が返ってくる。

今気づいたけど、僕はこういうふわっとした質問を学生時代からよく人にぶつけるけど、『ふわっとした質問が困る』という回答は仕事をはじめてから一気に増えた。覚えていく限り、1番最初に困ると言われたのは、大学院の時に社会人を経てドクターに戻ってきた人と話をしていた時だった。

多分、仕事じゃなかったら適当に答えたらいいけど、仕事だと回答に責任がうまれると思って、無責任な回答するのは嫌で『困る』って話になってるのかなあと思った。

個人的には、無責任な回答をされても僕の意見として採用するかどうかは僕が考えることだし、その回答がもとで失敗しても、『誰々がこういったから』みたいな理由はおかしいと思うので、無責任な回答でいいんだけどなあ、と思っていたりする。

あと、関連してなんで相談したいと思ってたんだっけ。とか考えていた。考えてると、そもそもの話として、人に相談せずに進めると、後でしんどい状況になりやすいよなあとか思った。

ホントに困ったときに、１人でやってると他の人に相談しようにも説明しないといけないことが多すぎたり、専門的になりすぎて、聞いてくれる人がいなかったりする。

ていうか、やっぱり１人で考えるより２人３人で考える方が楽だし、楽しいと思っている。あと、いろんな人に頼れるだけ頼って、頼った後は、『お世話になってます、ホニャホニャ』って思いながら、感謝する流れの方が健全だし文化的だと思う。

だから、やっぱり人に相談した方がいいと思う。

とはいえ、人にダラダラ話するのもあれだということを考えてると相談するって何をどうすればいいかなーと思うときがある。

そんな話を考えてたら、今日は『とりあえず情報を発信すると良いのでは。』と聞いたのを思い出した。

そういうわけで、思ったことをとりあえずブログに垂れ流そうと思った次第です。

gitで派生元を変えるrebase

gitで「派生元間違えた！」って時とか、別のブランチの修正内容が欲しいなあって時は、git rebaseの--ontoが使えることを学んだ。

そのうち同じことを考えそうな気がするので、未来の自分に説明を書いておく。

結論だけ言うと、

$ git rebase --onto t2 t1 t3

と実行すると、t2ブランチに、t1ブランチから生えているt3ブランチをrebaseできる。

詳しく経緯を書いて説明する。

最初はmasterブランチだけあるところからスタートした。

そして、リリースブランチ「t1」を切った。

そこから、トピックブランチ「t2」を切った。

もう一つトピックブランチ「t3」を切った。

それぞれで普通に開発を進めた。

途中、「t3」で「t2」のコミットが欲しくなった。

git rebaseして、t3ブランチをt2ブランチから生やした。

あとは、普通に開発を進める。

注意

ただし、rebaseしたあとは、t2を捨てると、t3も捨てることになると思う。（やったことないけど）

Pythonで一時的に使うディレクトリを作るときはtempfileが便利

Pythonで一時的に使うディレクトリを作るとき、 tempfile を使うと便利だなーと思ったのでメモ。

>>> import tempfile
>>> temp_dir = tempfile.mkdtemp()
>>> print(temp_dir)
/var/folders/3p/vnx8dmc96293_5trfs0lmcsw0000gq/T/tmpn2lqo9r0

使った後は、 shutil で消しちゃったりします。

>>> import shutil
>>> shutil.rmtree(temp_dir)

詳しくは、ドキュメントで。

11.6. tempfile — 一時ファイルやディレクトリの作成 — Python 3.6.3 ドキュメント

11.10. shutil — 高水準のファイル操作 — Python 3.6.3 ドキュメント

追記

公開した後で思ったけど、そもそも、消すのなら、tempfile.TemporaryDirectory を使う方がよさそうと思った。

追記２

tempfile.TemporaryDirectory は、Python3.2から追加されているので、Python2系の時は使えない。