matobaの備忘録

育児しながら働くあるエンジニアの記録

Jira Softwareを使い出した。

そういえばJira Softwareを使い出した。個人で。

個人でものすごくゆっくり開発しているアプリケーションの開発を管理しようと思って。

もともと、BitBucketにプライベートリポジトリを作って、そこでちょろちょろやってたけど、もうちょっといい感じのプロジェクト管理ツール欲しい気持ちだった。

というか、一人で開発してるのに開発中のアプリケーションが複数あるという微妙な状況になっているのもあり、複数のプロジェクトを横断的に課題管理できるツール欲しかった。

今のところ、Jiraでスクラムモードみたいな奴を使ってる。

割といい感じな気がしている。

流れとしては、

気になった時に、バックログを積み上げる。 ポイントで見積もる。 スプリントにする。

みたいな感じ。

いいなと思うのは、バックログを積み上げた後に、スプリントするものを選ぶこと。そして、スプリントが始まったらバックログは見ない。スプリントの最中も、ボードを見ていて、同時に複数のストーリーが着手されたら危ないことがわかる。

特に僕の場合は、作業をしていると「あ、あれもやりたい」「これもやりたい」みたいなのがたくさん見えてきてしまって、混乱するから、それらをバックログに詰めて、今は見えない状態になってるのは精神的に安定する感じがある。

後、開発速度を上げたい気持ちから、知らず知らずのうちに、ついつい複数のタスクを並列化してしまうことがあるけど、これも良くない。

ボードを見ていると、複数のタスクが進行状態になっているのはよくないことに気付きやすい。開発速度というか、スピードに乗って進められるような仕組みなのがいいように思ってる。

あと、Jiraはバーンアウトチャートとかいろんな観点でレポートを出力できるみたいなので、いろんなレポート見ながら、自分の開発速度を、ふむふむ、とかしたいと思ってる。

djangoのミドルウェアってなんなんだと思った

djangoのミドルウェアってなんなんだ。って思った。

とりあえず書いてみた。

こんな感じ。

class MyLoggingMiddleware(object):
    def __init__(self, get_responce):
        self.get_responce = get_responce
        print("MyLogging Middleware init")

    def __call__(self, request):
        print("pre-call:{}".format(request))
        responce = self.get_responce(request)
        print("post-call:{}".format(request))
        return responce

ここを参考にした。

Middleware | Django documentation | Django

なんとなく、書いてみたら雰囲気分かった。

python manage.py runserver で動作を確かめた。 よく分かってないけど、 __init__ が2回呼ばれてる様子だって、それの理由はよく分かってないけど、とりあえず、 __call__ の雰囲気はわかった

ソースはgithubにおいた。

github.com

数理最適化の話を聞きました

社内の勉強会で数理最適化の話を聞いた。

そこで数理最適化と機械学習は何が違うの?って話があった。

  • 機械学習は、過去のデータを使って問題を解く。
  • 数理最適化は、モデルを使って問題を解く。

みたいな話を聞いた。

この話を聞いて、

『あー、機械学習って、確率と統計だし、確かに新しい問題とか未知の問題は解けないよなあ。』とか思った。

あと『数理最適化だと、解きたい問題があって、それに対する理論を作るから、データがなくてもできるなあ』とかも思った。数理最適化は、理論で問題を解くようなイメージで理解した。

改めて聞いたことを振り返りながら書いていく。

まず、数理最適化には、3つの重要な要素があるらしい。で、その3つの重要な要素は、

  • 変数
  • 目的関数
  • 制約条件

らしい。

名称が数学っぽくて、理解のオーバーヘッドになってるので、個人的な理解で言い換えると、

  • 変数は、変えられること。
  • 目的関数は、価値観のバランス。
  • 制約条件は、変えられることの中で倫理的にやって良い範囲。できる範囲。

みたいなイメージ。

  • 変数を洗い出す時は、何を変化させられるのか、を考える。
  • 目的関数を考える時は、変えられることの変えやすさを、考える。
  • 制約条件を考える時は、変化させられるのかことで、まあやったとしてもここまでかなー、と言うのを考える。

と言うのが今のところの個人的な理解。

この変数と目的関数と制約条件を元に問題がといていく。

この変数、目的関数、制約条件を元に問題を解いてくれるソフトウェアをソルバーと言うらしい。

class Solver:
    def __init__(self, 変数, 目的関数, 制約条件):
        pass
    def solve(self):
        pass

僕のイメージはこう言うイメージ。

それから数理最適化には、典型問題と言うのがあるらしい。

よくわかってないけど、典型的な問題だと思う。『これは、〇〇問題だね!』的な使い方をすると理解した。

多分、デザインパターンとかアーキテクチャパターンとか、みたいな何かなのかなと思って話を聞いていた。

典型問題には、比較的簡単な計算コストが低い問題もあれば、計算コストが高い問題があるらしい。

O(NN)の問題を解くのは無理です。みたいな話。

はい。

典型問題はたくさんあるらしいけど、すぐに理解するのは難しそうだなあという印象を受けた。

あとは、Qiitaに参考になる記事がたくさんあるよ、という話も聞いた。

個人的な感想としては、面白いし、もっと勉強したいなと思った。

機械学習は、データを使うことを前提としていて、ボトムアップなアプローチだけど、数理最適化は、知恵を使うことを前提にしていて、トップダウンなアプローチ。みたいな印象を受けた。

どっちがいいとかじゃなくて、バランスよく使えるようになりたいなあ、という気持ち

アジャイルな理想日の見積もりの話

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

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

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

今回は、5章を読んでいて思ったことを書く。

5章は、「理想日による見積もり」について書いていた。

理想日について考える前に、理想時間と現実時間について説明されていた。

理想時間とは、何かをするのにかかる時間のうち、周辺の作業を差し引いたものらしい。 それに対して、現実時間は、実際にかかる時間らしい。 誰かに見積もりを聞かれた時は、現実時間を答えるのが、良さそうという話も書いていた。

一般的に、理想時間の方が簡単で正確に見積もれるということも書いていた。 なぜ、現実時間の見積もりが難しいかというと、怪我とかアクシデントとか、偶発的な出来事で変化したり、チームの流儀や環境の影響を受けて、変化するからだという話。

スポーツ、例えば、サッカーとか野球の試合時間も同じように現実時間の見積もりが難しい。ロスタイムがどれくらいあるかとか、アクシデントがどうとかが説明されていた。ただ、テレビはスポーツを放送するときに放送時間を決めてそこに収めてくるという話が書いてあった。

そして、テレビがどうやっているのか、という話も説明されていたけど、インタビューとかコマーシャルを使って、時間を埋めたり、延長したりしていると書いてあった。

ただ、それに視聴者は驚かないという話もしていた。なぜ驚かないかというと、変化することを知っているから。しかし、ソフトウェアの開発では、締め切りが伸びると驚く。なぜ驚くかというと、ソフトウェアの開発でスケジュールが変化することを知らないからという話を書いていた。

なるほどなあ。

スケジュールはあくまで雰囲気だという話なのかなあ。よくわからん。難しい。

どっちにしても、スケジュールを守るように努力はした方がいいと思う。ただ、必ずスケジュール通りにならないということは理解しておいた方がいいんだろうなあ。と思ったりした。

それから本の中にソフトウェアの開発が伸びる理由は、まず見積もりの段階で、準備、割り込み、知らなかったことが出てきた場合の時間、などを見積もっていないからだと書いてあった。

あと、作業を担当ごとに細かく見積もるのはやめようという話も書いてあった。 なぜ細かく見積もるのをやめた方がいいかというと、細かく見積もりをしたら、それのメンテナンスや管理コストが膨らむし、それに見合うだけの成果が得られない、かららしい。

なるほど。

で、理想日で見積もる場合は、担当を分けずに、ストーリーで見積もった方がいいという話を書いていた。

ストーリーかー、

ふむー。難しい。

で、ここからは僕の感想がメイン。

難しいなあと思う理由について考えてみると、例えば、ストーリーを見積もって、それが1ヶ月かかります。という話になったとして、それって、いつ遅れているとか、進んでるということがわかるのかなあと思った。

スケジュールを計画してる一つの理由が、どれくらいで終わりそうかの目処を立てることだと思ってる。早く終わったら別のことをやりたいし、時間がかかりそうなら、別のことはできないなとか考える。

作業を分けずにストーリーで考えた方がいい、という話が書いてあったけど、ストーリーの単位で進める場合、ストーリーが終わりそうか終わらなさそうかというのは、何を指標にして考えたらいいんだろう。

んー、これまで、作業の数がどれくらい終わったか。というのを使って測っていたりしたけど、そうじゃなくて、全体の雰囲気で測ればいいのかな。

いや、ストーリーをどれくらい実現できているか、なのかな。

いやいや、ストーリーは実現できているかどうか、のTrue/Falseだから、一つのイテレーションで一つのストーリーが消化できるとして、達成できたかできなかったかになるのかな。

だとすると、ちょっと困ることがありそうだなあとか思う。

だって、一つのイテレーションが終わらないと、そのイテレーションでストーリーが実現できたかどうかわからないと、計画の立てようがないんじゃないかなあ。

と思ったけど、よく考えたら、イテレーションの中で、ストーリーが終わってもいいのか。

んー、毎日、計画をアップデートする必要なんかなくて、イテレーションの単位がスケジュールというか、全体の計画を見直しする機会ということになるのかなあ。

どうなんだろう。

よくわかんないなー、とぼんやり考えていた。

追記

もしかして、チケット駆動開発のチケット、という単位と、ストーリーという単位は、似てるのかもしれないなあ

hgflowとかgitflowとか

先日、Mercurialを使っているプロジェクトに関わった。

その中で、「hgflowを使って〜〜」みたいな話を聞いた。

hgflowって何だろう、と思って聞いたら、なんかプラグインがあるらしい。

それで調べてみた。

サクッと調べたら、以下のサイトが見つかった。

www.sakito.com

ブランチの切り替えとかマージを補助してくれるツールの様子。

あと、いくつか記事を見ていたら、git flowというツールもあるということに気づいた。

あー。

git flowというワークフローがある、というのは知っていたけど、それを補助するツールがあるのを知らなかった。

github.com

多分これだと思う。

便利そう。

いい笑顔ですね。

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

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

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

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

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

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

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

例えば、

  • ストーリーAは3ポイント
  • ストーリーBは8ポイント
  • ストーリーCは6ポイント

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

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

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

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

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

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

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

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

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

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

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

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

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

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

新しい本棚を買った

新しい本棚を買った。

本棚はニトリで買った。

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

買ったのはこれ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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