2016-02-07 天才美少女明智小衣ちゃんの話


ミルキィホームズの話ですよ。本放送も今やってる再放送も終わっちゃってますけど、一応ネタバレ的な話なので、そういうの嫌な人は閉じるボタンとか戻るボタンとかクリックしちゃってくださいね。

ハーバード大学を飛び級で卒業した、天才美少女明智小衣ちゃん。IQ は上がったり下がったり、上がりまくったり、下がりまくったりしてますが、とりあえず IQ1300くらいあるらしいです。

劇中では、「こころちゃーん、シャロですよー」、「こころちゃん言うなー!」というコントがメインで、あまり天才美少女っぷりを見ることはありません。ですが、探偵歌劇ミルキィホームズTDの第5話「キャロルの身代金」では、(珍しく?)天才美少女っぷりを見ることができます。

この話、天才子役でハリウッドスターのキャロル・ドジソン宛てに脅迫状が届きます。小衣ちゃんは情報をミルキィホームズにリークして、自分は静観を決めこみます。

(十津川)「いいんですかぁ?ミルキィホームズに任せてしまって」
(小衣ちゃん)「どうせ子供の悪戯でしょ、ヨコハマ署きっての超スーパーエリート、この明智小衣様の仕事じゃないわよ!」

実際に、この脅迫状はキャロル(子供)の自作自演(悪戯)でした。小衣ちゃんがあの時点で、どれだけの情報を持っていたのかは語られていないですが、おそらく全部分かっていたんですね。さすが天才美少女ですね。

と、言うわけで、ミルキィにまつわる小ネタでした。



2016-02-03 Otogiri 0.17 をリリースしてもらいました


標記の通りで、Otogiri 0.17がリリースされました。主な変更は、僕が出したこの p-r(insert/fast_insert returns last_insert_id #15)でして、 insert()fast_insert() の戻り値を、従来の(あまり使われていなかった) $dbh->execute() の結果から、 last_insert_id() に変更しています。

これは非互換といえば非互換ですが、元の挙動を当てにしたコードはおそらく無いと思いますし、何より、

$db->insert('table_1', $table1_data);
my $table_1_id = $db->last_insert_id();

$db->insert('table_2', { table_1_id => $table_1_id, other_data1 => 'hogehoge' });
my $table_2_id = $db->last_insert_id();

$db->insert('table_3', { table_2_id => $table_2_id, other_data2 => 'fugafuga' });
my $table_3_id = $db->last_insert_id();
...

みたいな感じで、自動採番してるテーブルにいっぱい insert するようなスクリプトが、とても書きやすくなったと思うので、便利になったんじゃないかなぁ、と思います。 よろしくお使いください。

(追記 2016-02-04)

これだけだと、どのくらい嬉しいのかが分かりにくいかも。上記のコードがこうなります。

my $table_1_id = $db->insert('table_1', $table1_data);
my $table_2_id = $db->insert('table_2', { table_1_id => $table_1_id, other_data1 => 'hogehoge' });
my $table_3_id = $db->insert('table_3', { table_2_id => $table_2_id, other_data2 => 'fugafuga' });
...

insert をいっぱいやるスクリプトだと、結構分かりやすくなって良いのではないかな、と思います。よろしくお使いください。



2016-01-20 答え合わせ


1/17 のエントリ、期待値の上限、もしくは「探偵オペラ ミルキィホームズ 2016 大!プロジェクト発表会」の話の続きみたいな話。

本日、探偵オペラ ミルキィホームズ 2016 大!プロジェクト発表会 というのがありました。ここで発表された内容と前回僕が「こうあったら嬉しいな」と思っていた内容の答え合わせです。発表内容の詳細知りたい方はこのへんご覧ください。

  • TV アニメ5期制作決定 (× : 残念)
  • みるみるミルキィ復活 (○ : めっちゃ嬉しい!)
  • ミルラジ 4人で毎週更新にアップグレード (× : 「これまで通り」とのこと。今後に期待)
  • 武道館ライブ(にかいめ!) (× : 今なら余裕で埋まると思うんですけどね。会場が取れないのかな。。。)
  • (上記と別に)ライブツアー発表 (△ : 2 days とは、ちょっと予想の斜め上でした。コレはコレでアリ)
  • これまで映像化されてなかった過去のライブの映像化 (△ : 明言はされなかったけど、過去のライブで VR 用のカメラ入れたからそれを使いたい的なことは言ってた)
  • ゲーム新作制作決定 (△ : まさかのパチスロ。斜め上だがこれは微妙)
  • (上記と別に)ミラクルガールズフェスティバルにミルキィ参戦 (× : みがるのイベントのシークレットとかで来たりしないかなぁ...)
  • ファンブックとか設定資料的なやつが発売 (× : たにはら先生の画集は既報なので)
  • 上記以外にアニメ準拠の新作書籍(「はじめまして」は出るからそれ以外の何か) (× : 「はじめまして」以外無かったので)

先日のエントリでは

上記のやつが 2,3 個くらいでいいので、実現してほしいな。

と書きましたが、みるみる復活だけで十分すぎるほど嬉しいです!あとまー、死ぬほど寒かったし、ミルキィさんも寒そうだったので、今度こーゆーのある時は室内にしてほしいな、と思いました。



2016-01-17 期待値の上限、もしくは「探偵オペラ ミルキィホームズ 2016 大!プロジェクト発表会」の話


例によって、ミルキィホームズの話です。

1/20 に探偵オペラ ミルキィホームズ 2016 大!プロジェクト発表会 というのがあるのですが、ここで「発表されたらいいなぁ」と僕が勝手に思っている妄想をひたすら羅列してみた。

  • TV アニメ5期制作決定
  • みるみるミルキィ復活
  • ミルラジ 4人で毎週更新にアップグレード
  • 武道館ライブ(にかいめ!)
  • (上記と別に)ライブツアー発表
  • これまで映像化されてなかった過去のライブの映像化
  • ゲーム新作制作決定
  • (上記と別に)ミラクルガールズフェスティバルにミルキィ参戦
  • ファンブックとか設定資料的なやつが発売
  • 上記以外にアニメ準拠の新作書籍(「はじめまして」は出るからそれ以外の何か)

まだまだ色々ありそうだけど、とりあえず思いついたのはそんなもん。

真相はモンチッチのやつとか、映画化に伴うなんかイベントとか新曲出るとか、そんくらいな気がしてるけど、上記のやつが 2,3 個くらいでいいので、実現してほしいな。



2016-01-08 ミルキィホームズの設定の話


あけましておめでとうございます。今年もよろしくお願いいたします。

さてさて、例によって例のごとく、探偵オペラミルキィホームズの話です。「アニメのミルキィホームズはゲームとかの設定を無視している」みたいな言説を割と見るのですが、これ多分だいたいあってるけど、そうでもない、という話。

アニメには全く出てきませんが、コーデリアさんには妹がいます。

本 blog でも何度か紹介させていただいている、アニメ・ゲームの前日譚的な小説(↓)に出てきます。

コーデリアの妹は病弱で、入院しています。そしてその後の小説の描写やアニメ・ゲームその他の派生作品に全く登場しないことなどを総合的に考慮すると、どうやら妹はコーデリアがホームズ探偵学院に入学する前に亡くなっているっぽい、というのが定説です。

さてさて、1期2話で、コーデリアとネロが喧嘩するシーンがありますが、コーデリアがキレたのは、頭につけてる花(花飾り?)を馬鹿にされたから、です。で、上述の小説の挿絵を見ると、この花は妹がいる時は付いてないんだけど、その後のホームズ探偵学院に入学してからは付いてます。どうやらこれは、「妹の形見的なモノ」である、ということが推察されるわけですね。そりゃキレるわけです。

このシーン、シャロはどうやらこれを知っているっぽくて、でもなんで知ってるかよく分かんないんですね。個室が割り当てられてた時代に、シャロはちょいちょいコーデリアのところに遊びに行っていて、紅茶でも飲みながら色々話してたのかもしれないですね。(妄想が捗りますね)

と、いうわけで、ミルキィの設定のちょっとした小話でした。なおこれ、5周目くらいにやっと気づいたので、他にもこういうの色々あるのかもなー、と思っていたりする次第。

そいえばこれ、盛大に間違えてた。1期2話ですね。。。



2015-12-31 2015年の振り返り


2015年も残すところあとわずかとなりました。ココに書いた記事を中心に振り返ってみようかと思います。

2015年は探偵歌劇ミルキィホームズTD から始まったようです。

おかげで、2015年1月期はほとんど本を読んでなかったり、勉強会にも顔を出してなかったりしてたようですが、まあこればかりは仕方ない。

昨日 Kichijoji.pm に参加したら「久しぶり」って言われて、「あれ?そうだっけ?」って思ったけど、 たしかに、はちぴー久しぶりだし、その前の技術系のイベントははてなのセミナー行ったくらいだから、たしかに久しぶりであった。

そういえば、今年すごく久しぶりに screen 試してみたら、ようやく実用までこぎつけることができました。

この記事が多分今年の一番の人気記事ですね。自分の苦労の軌跡のメモなので、なんで人気なのかイマイチよく分からないのですが。。。

そして今年は「最後の YAPC::Asia」でしたね。

そいえば、コピペ検出とかコードメトリクスをアレコレしていい感じに改善できるサイクルを作りたいなぁ、と色々考えていて、会社の blog の方で、Google の bugspots を紹介したところ、なかなか好評いただいたようで、なによりです。

bugspots の数値、毎月取得して見てはいるんですが、なかなか「知ってた」とか「なるほど」の先に行けていなくて、来年はもうちょっと何かできるといいなぁ、と思う今日この頃です。

YAPC 以外のイベントではミルキィはちぴーとか、吉祥寺、五反田の Perl 界隈を中心にいくつか参加させてもらっていた感じです。来年もよろしくお願いいたします。

毎年恒例、技術系 Advent Calendar では、Perl入学式 Advent Calendar 2015に 2 つほど寄稿しました。

と、いうわけで、ミルキィTDで始まり Perl 入学式で終わった 2015年だったようです。来年もよろしくお願いいたします。



2015-12-30 書評 Selenium デザインパターン&ベストプラクティス


End to End のテストを整備したいなー、と最近思っていて、Selenium とかの関連書籍を読んだり Web を調べたり色々していたのだけど、そしたら「とんでもない掘り出し物」を見つけたのでご紹介。

Selenium デザインパターン&ベストプラクティス

めっちゃいい本でした。久々の大当たり。

内容紹介はこんなことが書いてあるのだけど、これ説明がたぶんあんまり良くない。(書いてある事は正しい)

本書はSelenium WebDriverを使ったテストの構築方法やデザインパターン、メンテナンス性に焦点を当てた書籍です。
Seleniumを使った人ならわかるテスト時の取り入れるべき事柄や避けるべき事柄をパターン化してわかりやすく解説しています。
テストをリファクタリングする方法、自動テストプロジェクトにおけるSpaghettiパターン、テストデータについて、テストを安定させるコツ、さらにテストスイートを成長させるヒントなど、テスト自動化設計におけるポイントを幅広く紹介します。
ベストプラクティスだけでなく、アンチパターンも紹介しているため、失敗の原因を知り、適切な設計パターンを適用することができるようになります。

これだと、Selenium 興味ある人しか読まないと思うんだけど、ぜんぜんそんな事なくて、「テストコード書くすべてのエンジニア」が読むべき本だと思います。つまりこの本の本質は 3行目に書いてある

テストをリファクタリングする方法、自動テストプロジェクトにおけるSpaghettiパターン、テストデータについて、テストを安定させるコツ、さらにテストスイートを成長させるヒントなど、テスト自動化設計におけるポイントを幅広く紹介します。

の部分であり、要するに「綺麗で安定してメンテナンス性の高いテスト」の書き方が書いてある本なのです。題材が Selenium なだけで、「良いテストコードの書き方を示している本」なのです。

最初は ad hoc な「とりあえずハードコーディングでページにアクセスして、ポチポチして中身があってるか比較」みたいなテストから始まります。(Spaghettiパターンとして紹介されている書き方)。それをメソッド抽出などしてリファクタリングしつつ、テストデータを fixture にまとめて、最終的に綺麗なページオブジェクトにまとめていく過程が1章〜4章に書いてあります。ここだけでもめっちゃ価値があって良いです。(ページ数で半分弱)。

こういう「良いテストの書き方」や「テストコードを改善していく方法」を紹介している本ってあまりなくて、個々のトピックとしてテストのリファクタリングや fixture について触れているものは無くはないのだけど、「じゃあそれどうやってやるの?」っていうのが分からなくて、結局自己流になってしまいがちだったので、それが分かりやすく書いてあるのは本当にとても良いと思いました。

と、いうわけで、テストコードの入門書の一つとして、冬休み課題図書としていかがでしょうか。

なお、この本で扱っていないトピックとしては、「テスティングフレームワークの使い方」(一応 Test::Unit とか Cucumber とかの紹介はしているけど、この本は「なるべくそういうのから独立して書く」事にフォーカスしてる)とか「カスタムアサーション」(これもテスティングフレームワーク寄りの話か)みたいな、テストコード側のテクニックとか、「モック・スタブの使い方/作り方」(ちょっと触れてるけどあんまりない)あたりかな。

そういうの期待している方は別の本を探しましょう。(僕も知りたい)

ではでは。



2015-12-13 サブルーチンリファレンスの話


これは Perl入学式Advent Calendar13日目の記事です。実際に投稿できたのは1週間後くらいになってしまいました。。。すいませんすいません。いろいろバタバタしておりまして、投稿が遅れに遅れました。。。

こんばんは。東京でサポーターをしております、@tsucchiです。

昨日の記事は @magnolia_k_さんのPerl入学式に…参加したことがありません!でした。参加したことのない方にも評価してもらえるのって、ありがたいですね!嬉しいですね!

さてさて、僕は 昨年の Perl入学式 Advent Calendarで、リファレンスの使い方とかの話という記事を書きました。その中で、

リファレンスの使い道は大きく分けて 3 つくらいだと僕は考えています。

複数の配列を関数やメソッドに渡す
複雑なデータ構造を作る
関数やメソッドで引数を更新する

と書きましたが、忘れてた。完全に忘れてた。。。サブルーチンリファレンスのことを!

さてさて、Perl 入学式の第5回では、Mojolicious を使って Web アプリの作成を行いますが、ここで実は唐突にサブルーチンリファレンスが登場します。

get '/' => sub {
  my $self = shift;
  $self->render(template => 'index');
};

この sub ってなんだ???説明してないじゃん!、と唐突に気づいたのでした。というわけで、その落穂拾いも兼ねて、軽くサブルーチンリファレンスの説明をしようかな、と思います。

で、この sub って本当にどうなってるんでしょ? Mojolicious のコードを見てみましょう...と思ったら、これめっちゃマジックだな。。。知らなかった。

と、いうわけで、もうちょっと分かりやすい例で行きましょうか。

まずは、普通のサブルーチンです。

sub add {
    my ($arg1, $arg2) = @_;
    return $arg1 + $arg2;
}

引数を足し算するやつですね。こんな感じで使います。

print add(1, 2); # => 3

さてさて、この add()a とか b とか、ヘンな値を渡すとどうなるでしょうか?

print add('a', 'b') # => 0

この場合、値は0になります。んで、警告がでます。Argument "b" isn't numeric in addition (+) ...みたいな。

では、これをチェックしましょうか。

sub check_args {
    my ($arg1, $arg2) = @_;
    if ( $arg1 !~ /^[+-]?\d+$/ || $arg2 !~ /^[+-]?\d+$/ ) {
        die "引数は整数以外ダメですー";
    }
}

何を許容するかは実は結構難しいですが、とりあえず整数ならOKということにしてみました。こんな感じにすればいいのかな

my $arg1 = 'a';
my $arg2 = 'b';
check_args($arg1, $arg2); # => ここでエラーになる
add($arg1, $arg2);

チェックは add()でやってもいいですね。こんな感じです。

sub add {
    my ($arg1, $arg2) = @_;
    check_args($arg1, $arg2);
    return $arg1 + $arg2;
}

さてさて。「何を許容するかは実は結構難しい」と書きました。仮に整数としましたが、これって、要件に応じて「正の整数」だったり、「小数もOK」だったり、あんまりないかもしれないけど、「負の数だけOK」だったり、実は色々バリエーションがありえそうです。

と、すると、サブルーチンを呼んでいる外側からコントロールできると良さそうですね。

ここで活躍するのがサブルーチンリファレンスです。こんな感じで使います。

sub add {
    my ($arg1, $arg2, $check_subref) = @_;
    $check_subref->($arg1, $arg2);
    return $arg1 + $arg2;
}

引数にサブルーチンリファレンスをとる感じにしてみました。配列@arrayの時の要素1番目は$array[0]でした。で、このリファレンス

my @array = (1,2,3);
my $array_ref = \@array_ref;

の場合に1番目の値をとる場合は $array_ref->[0] となります。同じような感じで、サブルーチンリファレンスに渡ってきたやつを使って、渡ってきたやつを呼ぶ時は、$subref->() みたいな感じで呼びます。

全体としてはこんな感じ。

sub add {
    my ($arg1, $arg2, $check_subref) = @_;
    $check_subref->($arg1, $arg2); #ここで渡ってきたリファレンスがサブルーチンとして呼ばれる
    return $arg1 + $arg2;
}
sub check_args {
    my ($arg1, $arg2) = @_;
    if ( $arg1 !~ /^[+-]?\d+$/ || $arg2 !~ /^[+-]?\d+$/ ) {
        die "引数は整数以外ダメですー";
    }
}

my $arg1 = 'a';
my $arg2 = 'b';
my $subref = \&check_args; #これがサブルーチンのリファレンス
add($arg1, $arg2, $subref);

むずいですね。。。僕も結構ちゃんと理解するまで時間かかったんですよね。。。

逆に、Mojolicious の例みたいに、無名サブルーチンを使った方が分かりやすいかもです。

sub add {
    my ($arg1, $arg2, $check_subref) = @_;
    $check_subref->($arg1, $arg2); #ここで渡ってきたリファレンスがサブルーチンとして呼ばれる
    return $arg1 + $arg2;
}

my $arg1 = 'a';
my $arg2 = 'b';
add($arg1, $arg2, sub {
    my ($arg1, $arg2) = @_;
    if ( $arg1 !~ /^[+-]?\d+$/ || $arg2 !~ /^[+-]?\d+$/ ) {
        die "引数は整数以外ダメですー";
    }
});

add の第3引数は sub で始まるブロックになっています。これは Mojolicious で使っているのと同じやつで、無名サブルーチンというやつです。やっていることは先ほどのコードと同じです。チェックのサブルーチンが色々な所で使い回すものだったら、普通に定義して、リファレンスをとる方が良いでしょう(無名にしない、2個前のやつ)。そうでなくて、1回きりの使い捨てであれば、いちいち名前をつけるのも面倒なので、無名で良いじゃん、というのが1個前のやつです。Mojolicious のやつは、文法的にはこれと同じなのだけど、考え方はちょっと違っていて、「DSL」ってキーワードで色々調べてみるとちょっと世界が広がるかも。。。

と、いうわけで、結構難しいサブルーチンリファレンスのお話でした。

明日(?)は、@tomchaさんのPerl で○×ゲームをガチバトルする話みたいです。めっちゃレベル高いな。



2015-12-08 File::Basename の話。あるいはそこからの教訓的な何か


これはPerl入学式 Advent Calendar 2015の8日目の記事です。昨日は@papixさんの、「なぜGaiaxは新人研修の資料を全部Perl入学式に譲渡して「Perl入学式の教科書」として公開したのか?」と言う記事でした。いい感じに頑張っている企業の研修素材が公開され、自由に使えるのは本当に素晴らしいことだと思います。

こんばんは、東京でサポーターをしております、@tsucchiです。

先日、仕事で(多分)古いコードをリファクタリングしていたところ、こんな感じのコードを目にしました。

my @tmp = split '/', $filename;
my $file = $tmp[-1];

これは何をするコードでしょうか?

$filename に入ってくるのはファイル名のフルパスのようでした。つまりこれは、ファイル名のフルパスから一番末尾の部分をとってくるコードです。

例えば、ファイル名のフルパスが、/usr/bin/perl だったら $file には perl が入ります。

さてさて、実はこの処理をするには、タイトルにもある、File::Basename と言うモジュールの basename() という関数を使うのが鉄板です。すなわち、さっきのコードは

use File::Basename;
my $file = basename($filename);

と、書くことができます。

個人的な主観かもしれないですが、 basename() を使った方が分かりやすく、綺麗なコードになるんじゃないかなぁ、と僕は思います。少なくとも、最初のコードを見た時は、「ん?これ何だ?」と数十秒考えてしまったので、少なくとも僕にとっては最初のコードは分かりにくいし、思考が止まるので、こういうのやめてほしいな、と思いました。(なので、当該のコードは basename() を使うように修正しました。あとは細かいこと言うと、$file とか $filename と言う変数名はこれだと意味分からなくて最悪ですね...。それも直さないと...)

一方で、Perl入学式で学んでいる初心者の方にとっては、これは大きな違いではないし、重要ではない、とも僕は思っています。

昔、Perl Beginnersというところで LT した時にも触れたのですが(正解はひとつ!じゃない!!)、その言語のビギナーであれば、「赤ちゃん言葉」であってもぜんぜん良くて、やりたいことがちゃんと実現できていることの方がよほど大事です。

こういうの、多分どんなにプログラム沢山書いていてもあると思っていて、僕らみたいに普通に仕事で Perl のプログラムを書いていれば basename() の話は割と常識的で、知っているべきものだと思います。ですが、例えば、「自然言語処理の最新の論文で紹介されているアルゴリズムで使うべき変数名や関数名」とかだったら、たぶん僕がやったらめちゃくちゃな命名をしたり、使うべきライブラリや関数を使わずにコードを書いてしまう可能性は普通にあります。あるいは、僕がぜんぜん知らないビジネスのドメインの用語とかでも同じかな。マイナーであまり使われてないモジュールとか、自分が慣れてないモジュールの場合も思考が止まりそうですね。。。こういうの本当に微妙ですね。。。

と、いうわけで、この出来事の教訓は何でしょうか?

「ライブラリを使えば簡単に書けるものはそうすべき」そうですね。あるいは、「ライブラリを知らなくても、とりあえず問題を解決すべきコードは、それはそれで正しい」それもそうです。「コードを書く人、読む人はどこまで対象のドメインに対する知識を持っているべきか?」うーん、難しいですね。。。

結論なんて多分ないです。学ぶべきことは、誰にだって沢山あるのだと思います。

以上、ふと見かけたちょっとヘンなコードとそれにまつわるお話でした。

明日は@note103さんの砂場の話です。使い捨てみたいなスクリプトをどんな感じで管理しているのでしょうか。わたし、気になります。



2015-11-28 ふりかえりについて。あるいは Try が Try されない問題


ソニックガーデンさんの記事、「ふりかえり」を効果的にするための実践的なトライの出しかた 〜 TRYを掛け声で終わらせない を読んでいて、「よくまとまっていい記事だなぁ」と思ったのですが、「でもちょっと違うところもあるなぁ」と思ったので、その辺について書きます。

ふりかえりについて

僕のところでも、ふりかえりは実施していて、一般的な KPT でやっています。KPTについて、説明するのは面倒なので、先ほどの記事から引用させてもらいます。

KPTは、Keep/Problem/Tryの略で、「Keep=よかったこと」「Problem=悪かったこと」「Try=次に試すこと」を洗い出すシンプルな方法です。

僕のチームでは、1週間のスプリントで開発をしていて、火曜始まり月曜終わりなので、月曜のレビュー(スプリントレビュー)が終わった後に、ふりかえりを実施しています。

で、ふりかえりでは、Problem(問題や困ったこと)を中心に色々意見を出し合ったりして、Try を考えています。で、最後に実施したい Try を決めてふりかえりを完了させています。ちなみに時間は最大1時間、1週間スプリントなので、連休とかあってあまり作業時間が取れない時は短く終わることもあったりしますが、大抵目一杯時間使っています。

Try について、「Try が Try されない問題」

さて、前掲の記事にあるようなイメージで頑張って Try を考えたりしていたのですが、初めの頃は「Try が Try されない問題」が割とよく起こりました。ひどい場合だと、翌々週くらいに全く同じ Problem が出て、「あ...これ前も同じこと言ってね?」とか。。。

これを僕達のチームでは「Try が Try されない問題」と呼んでいます。

原因は大きく分けて 2 つだと考えています。

  1. 忘れる
  2. 課題が大きすぎて結果的に何もできなくなってしまう

人間ですからね。仕方ないですね。

あらためて、ふりかえりについて

スクラムにおいては、「ふりかえり」はチームを強くするために実施するプロセスです。冒頭、「ちょっと違う」と書いたのは、なんかこれって個人毎に実施する内容っぽくね?って思ったからです。(冒頭の記事はスクラムのプロセスとしてではなく、メンターとしてふりかえりを活用って書いてあるから仕方ないのかもしれないけど。)

結果的に一人しか作業できないタイプのタスクはもちろんありますが、スクラムチームを組んでいる限り、タスクであれば基本的にはチームの誰かがやれば良いし、ルールなら全員が守るべきものです。だから、ふりかえりからフィードバックされた内容は、個人のものではなく、チームとして取り組むべきものである、と僕達は考えました。

解決策っぽいこと

チームとして取り組むべきであれば、それはチームのタスクです。そこで、ふりかえりの内容(特にTry)を振り返るタイミングを、「次回のふりかえり」ではなく、「次回のタスクを決めるタイミング」に変えました。スクラムでは計画ミーティングの2部で、チームとして取り組むタスクの洗い出しと決定をします。

なので、ふりかえりの内容を計画ミーティング2部で振り返って、チームのタスクに反映させています。

計画ミーティングの冒頭では、以下2つのことをやっています

  • 前回の Try の確認
  • 今回の Try の確認

なぜ2回分?と思われるかもしれませんが、これは元の「課題が大きすぎて結果的に何もできなくなってしまう」問題に対応するためです。今回の分(直前のTry)は割とサクサクとタスクとして登録していくのですが、その中で残ってしまったもの(すなわち前回のTry)は、「実はそんなに深刻でないから放置された」ものか、「課題がでかすぎて何もできなかった」ものである可能性が非常に高いです。

そこで、前回の Try を確認しつつ、残った問題について、より細かいタスクに分割するとか、重要ではないから放置 or 削除する、といった事を決めています。

まとめっぽいこと

と、いうわけで、ふりかえりの確認を翌週のふりかえりではなく、直後の計画ミーティングでタスク決めするときに一緒にやるといいかも、と言うお話でした。僕は絶対こっちの方がいいと思うのだけど、ふりかえりとかKPTとかスクラムについて書かれた本を読んでも、「計画ミーティングでやる」っていうの見たことないのですが、どうしてなんでしでしょう、謎です。