Posts for: #Postmortem

大きなふりかえりの資料作り

お風呂で fitbit を外してそのまま付けるのを忘れて寝た。たぶん3時前に寝て6時半ぐらいに起きた。

今日の運動は腹筋ローラー,腕立て,スクワット,散歩をした。統計を 運動の記録 にまとめる。

大きなふりかえりの資料作り

今日は丸一日ふりかえりの資料を作っていた。だいたい出来た。過去のスライドがあるのでその内容に沿って統計のグラフを作りながら、今回の開発の特徴や前開発との違いなどを比較していく。ノウハウが溜まっているので比較的簡単に作っていける。しかし、今回は2週間遅れ、新規メンバーの受け入れ失敗と、プロジェクトとして明確も失敗もあったのでその反省として、次の受け入れのときにこういう状況なら受け入れせず、開発からメンバーを外すといったクライテリアを作ることにした。今回の失敗は新規メンバーのために、ぎりぎりまで参加できるよう、待ったために結果的に中盤の機能開発の集中力を乱した。プロジェクトマネジメントの失敗としてしっかりふりかえりをしていく。

バランスボール

ジモティーで IGNIO のバランスボールを0円で譲り受けた。新品を買ってもそんなに高くないのかな?

椅子の代わりにもなるし、トレーニングのなにかにも使えるかもしれない。実家コワーキングスペースに置いておく用に譲ってもらった。県庁駅の近くの持ち主の自宅近くまで意味なく歩いて受け取りに行ってきた。おかげで7000歩、片道40分ほど歩いて今日の運動のノルマを達成した。もう1万歩歩くのは簡単になってきた。普段の生活に1時間ほど散歩の時間を設けると簡単に超える。バランスボールの空気がやや少なかったのでダイソーで空気入れを探してこようと思う。

創作天ぷらと創作そば

私の知る限り、三ノ宮で一二を争うおいしいお蕎麦屋さんに ISOGAMI FRY BAR がある。以前からお昼にはちょくちょくお蕎麦を食べに行ったりしていた。いまはダイエット中だから外食そのものをほぼ していない。ふと夜はどんなメニューがあるのかの下見に入ってみた。夜はお酒も出しているので、チャージ300円、ワンドリンク必須だという。料理は刺し身や前菜、サラダ、つまみ系の料理、創作天ぷらがあり、お蕎麦も基本のざる蕎麦から創作系の変わったお蕎麦もある。ちょっとよい居酒屋へ行くぐらいの金額にはなる。ここのお蕎麦はおいしいから割高でも私は気にはならない。

創作そばの彩り野菜の豆乳バジルそば。

創作天ぷらのバジル&トマト。

モチベーションを揺らすもの

0時に寝て2時に起きて6時に起きて7時に起きた。まぁまぁ普通に眠れた。

定例会議

いよいよこのマイルストーンを終えると、あと1つで機能開発の終わりとなる。いくつかの要因があって開発の進捗は遅れ気味になっている。メンバーがどうこうというわけではなく、私がうまく段取りを組めていなかったり、自身がマネジメントの業務をちゃんとまわせていないところが開発スケジュールの遅延につながっている。いまの状況は私が失敗したあのときのあれや、このときのこれから全体の進捗へ影響を与えているなとわかるぐらいにはマネジメントの動きが読めるようになってきた気がしている。読めるんだったら対応しろよというのはわかっているものの、モチベーションが足りなくて成り行きに任せていて成るようになっていないなといったところ。私のモチベーションが足らないところも含め、今フェーズの開発にはマネジメントの反省材料がいくつかある。

真面目にやった人を不当に咎める

昔から私はわりとワーカホリックだったので興が乗るとずっとお仕事をしていることが多かった。若い頃はやったらやった分だけ成果が出て評価されて、それはそれで楽しかったものの、30代になるとできて当たり前、成果のレベルがよほど飛び抜けていない限りは評価されることはなくなった。仮に10段階で例えると、若い頃は3しかできないと思っていた人が8ぐらいやると評価されやすいし、30代では8やって当たり前だと思われているから10やっても12やっても大差ないとみなされる。もはやお金のためにお仕事をしているのではないため、評価されなくても気にはならないし、いまは自分で契約の判断ができるので嫌なら契約を終了して別のお仕事を探せばよいだけという割り切りもある。

そんな中、昔からずっと思っていることが1つあって、真面目にやっている人たちを適切に評価しない上司が多い。要はなにも言わなくてもちゃんとやってくれているから放置するといった傾向がある。そして、さぼっている人たちや成果を出せていない人たちをかばう傾向がある。それはパフォーマンスが低い人たちを悪く言うと、さらにモチベーションを下げて、もっと悪くなるから励ますという意図があるのだと思う。しかし、その対応が度を過ぎると、真面目にちゃんとやった人たちのモチベーションを吹き飛ばしてしまう。その典型的な言葉が「みんながんばった」になる。実際は数人のコアメンバーが業務の大半をやっているのに上司は個々人の差異をなくしたがる。チームの一体感とか、空気を悪くしたくないとか、ハレーションを防ぐとか、いろいろあるのだろう。私は一緒に働いている人なら誰でも気付けるレベルの、みんながんばってないのに、そういった問題を指摘することもなく、なぁなぁで済ませるのをいくつもみてきて、これは日本の会社や組織で共通する傾向があると思う。なにを危惧しているのかわからないが、問題の本質に触れようとしないことが度々起こる。気付いたら対応しないといけないから気付いてないことにしたいと言い換えてもよいかもしれない。そういう状況をみると「またか」と思って私のモチベーションが落ちる。誰だって働きたくない。

私はよくやってくれている個人を、何度でも、よくやってくれていると明言して評する。がんばっていない人たちを咎めたりはしないが、がんばっていないのにがんばったとは絶対に言わない。状況によってはもっとがんばってほしいと言う。個人差があることを曖昧にしたりはしない。

メールの結合テストのツール

0時に寝て4時と5時に起きて6時に起きた。最近は4時から1時間ごとに起きたりする。メールの送信処理のリファクタリングのコードレビューが長く続いていてなかなかややこしい。

mailhog の web api を使って検索する

メール送信の結合テストに mailhog というツールを使っている。smtp サーバーとしてメールを受け付けて web ui でそのメールの内容を確認できる機能をもっている。さらに web api で任意のメール取り出すこともできる。パスワードリセットの一時トークンをメールで送信するため、結合テストで一連のパスワードリセットを検証するにはメールから一時トークンを取り出さないといけない。そこで mailhog の出番だ。

検索 api を使うと任意のメールをフィルターできる。例えば、送り先のメールアドレスで検索するときは次のようにリクエストする。

$ curl -s "http://localhost:8025/api/v2/search?kind=to&query=myuser1@example.com" | jq .

うちらのやり方はメールのメッセージ ID に意図した uuid をセットしている。メールのメッセージから指定した uuid を含んでいるかを検索することで任意のメールをフィルターできる。

$ curl -s "http://localhost:8025/api/v2/search?kind=containing&query=28c9391f-25a5-4a8f-9035-7b8d5ac2d0f4" | jq .

それを結合テストのテストコードから呼び出すようにユーティリティを作ると次のようなコードになる。

import (
	"github.com/mailhog/data"
)

type mmSearchResult struct {
	Total int            `json:"total"`
	Count int            `json:"count"`
	Start int            `json:"start"`
	Items []data.Message `json:"items"`
}

func searchMail(
	host string, kind string, query string,
) (*mmSearchResult, error) {
	q := url.Values{}
	q.Set("kind", kind)
	q.Set("query", query)
	u := &url.URL{
		Scheme:   "http",
		Host:     host,
		Path:     "/api/v2/search",
		RawQuery: q.Encode(),
	}
	url := u.String()
	slog.Debug("mailhog search endpoint", "url", url)

	req, err := http.NewRequest("GET", url, nil)
	if err != nil {
		return nil, fmt.Errorf("http create new request error. err: %s", err)
	}
	res, err := http.DefaultClient.Do(req)
	if err != nil {
		return nil, fmt.Errorf("http request error. err: %s", err)
	}
	if res.StatusCode >= 400 {
		return nil, fmt.Errorf("returned response code is %d", res.StatusCode)
	}
	var r mmSearchResult
	if err := convertBody(res, &r); err != nil {
		return nil, fmt.Errorf("failed to convert: %s", err)
	}
	return &r, nil
}

歯医者

17時から歯科検診へ行ってきた。歯科検診をしてくれた今回のスタッフはおそらく初めてだったと思うが、手際がよくていつもよりもストレスが少なかった気がした。うちのチームのメンバーは朝方なので8時過ぎにはだいたいみんな始業し始める。なので、朝よりも夜にいない方がメンバーにとってよいだろうと考えて、朝一 (9時) に歯医者へ行くよりも最終 (17時) に行くようにしている。

pycamp ふりかえり

先週末の Python Boot Camp のふりかえり。ここまでがスタッフのお仕事なので一般的な kpt でイベントのふりかえりをした。仕事じゃないし、大きなトラブルもなかったし、参加者の評判 (アンケートの内容) もよかったので概ねよい内容だったと思う。テキストの改善点は直接 issue に追加してほしいと言われたので報告した。是非も含めてスタッフに判断してほしいので私が直すつもりはない。

ふりかえり + チーム勉強会

22時から寝始めて何度か起きて7時に起きた。久しぶりにどっしりくるような夢をみたけれど、もう内容を覚えていない。

ふりかえりを兼ねたチーム勉強会

新しい開発に着手して初めてのチーム勉強会を行った。前の開発とチーム勉強会の運用を大きく変更した。ざっくり次が要項になる。

  • 前開発の postmortem 運用がうまくいかなかったので代替としてやってみる
  • 開発システム全体の機能が増えてきて、メンバーそれぞれがやっていることもバラバラになりつつある
    • 普段やっていることを他メンバーへ情報共有する機会とする
    • そのときのマイルストーンでやっていることをふりかえりする機会とする
  • 開発システムについて知りたいところや設計の議論などをしてもよい
    • メンバーが全員揃っていれば、どんな質問をしても誰かが知っているはず
  • そのマイルストーンでやったことを基本として他メンバーへ共有する
    • 内容は基本的になんでもよい、あまり準備せずに話せる内容でよい
      • 特定の issue の内容でも、マージリクエストの解説でも、機能や振る舞いの考察など
    • 知識やノウハウを他メンバーに共用する上で wiki やブログの記事などにしてもよい
      • 書くところがなかったらテックブログに書けばよい
  • 勉強会のために調査する時間が必要であれば、その調査時間も仕事の一環とする
    • 勉強会の準備も考慮して開発のスケジュールを各自で調整する
    • 業務で実装したことや調査したことを共有する機会にもなる

まだ合流前だけど、メンバーが新規に1人増える。2週間に1回の定例のみだと、新しいメンバーが既存のメンバーに追いつくための情報が足りないだろうと思って質問しやすい機会を設けようと考えていた。雑談時間とか、設計会議とか、そういう呼び方をしてもよいのだけど、私にとって違和感なく一番しっくりきて柔軟性も高いのが「チーム勉強会」になる。ふりかえりと情報共有と学びの場の3つを兼ね、チームビルディングにも応用しようという、まさに天才の所業ではないかw まだ始めたばかりだから言うだけ言っておく。また開発が終わったときに良し悪しのふりかえりはする。

今日のところは最初だったので前マイルストーンでやった issue をメンバーそれぞれ1つずつ内容を説明して共有した。私も mongodb の初期化ツールのマージリクエストが出来たばかりだったのでその背景や意図、工夫したところなどを紹介した。他のメンバーも背景やソースコードを紹介しながらみんなでわいわいできた。第1回目にしては活気があって情報共有という目的も果たせたし、よい感じの取り組みにみえた。このままうまく運用にのせていく。

プロジェクト管理のドキュメントや資料の更新

23時に寝て何度か起きて7時に起きた。

開発方法論/開発ガイドの更新

前回の改訂 から約4ヶ月ぶりに開発方法論と開発ガイドを改訂した。

  • 開発方法論: プロダクトで採用している開発方法論の概念をまとめる
  • 開発ガイド: 開発方法論を具体的に実践する方法についてまとめる

近いうち、チームに新規メンバーが入る。今回の開発を経て新たにわかったことや変わったところなどを更新するつもりで全体を読み直してみたが、大きく変わったところはなく小さいアップデートに留まった。開発方法論に 情報共有とコミュニケーションのレベル というタイトルで5段階のレベルについての考え方を追記した。この内容は私もまだ完全に言語化できているわけではない。「聞かなくてもわかる」という価値観の存在をまったく疑っていないが、その背景にあるコミュニケーションの在り方や人間関係や組織での運用についてまだ曖昧なところが多い。それも含めて考えるよい機会だと思ってうちのチームに向けた内容に整理し直してまとめてみた。もう2-3回ぐらいこのテーマで話しをしたりすると、より言語化できてもっとよいものができそうな気配は感じている。

fun/done/learn のカスタマイズ

昨年からふりかえりの手法として fun/done/learn という手法を採用している。2週間のイテレーションが終わったときに毎回このフレームワークを使って、やったことをメンバーに共有するといった用途のために使っている。大きな開発のふりかえりを行ったときにマイルストーンごとの fun/done/learn の個数の変化などもふりかえってはいるが、そこの統計値がなにかに役に立つようには、いまのところ、うちのチームでは思えない。

今回のふりかえりをしているときにメンバーから done はいらないのではないか?という意見が出た。この手法の発明者のオリジナルの記事 ファン・ダン・ラーン(FDL)ふりかえりボード と読むと、done = deliver だし、done しなかったことも含めてのふりかえりを実践していたことが伺える。うちらはやったことをふりかえるためのフレームワークとして活用しているため、done がデフォルトでプラス fun/learn が付くといった運用になっていた。その通りだなと納得して done に置き換わる、うちらの開発の運用にあうカテゴリを考えてみて give を採用した。ゴロがよいように fun/give/learn と呼ぶ。

give とは、このマイルストーンでやったことを形式知として、他のメンバーに共有可能な状態にしたという意図を表す。wiki を書いたりするのもよいし、テックブログを書くのもよい。暗黙知を形式知に変えるには少し手間暇がかかるのでちょうどよいカテゴリに思える。3つのカテゴリに属するときにもっとも価値が高いような運用にも向いている。そのためのボードも作って、これを jamboard の背景に設定してふりかえりをしている。何ヶ月か運用してみて、うまくいきそうだったら fun/done/learn の亜種としてどうだろう?といった提案のテックブログを書いてみたい。

ふりかえりのふりかえり、のふりかえり

深夜に1-2時間仮眠をとったものの、あまりうまく眠れなくて、3時に起きて準備して5時に家を出た。新幹線でも寝ていたが、夕方にはやはり眠くなった。

約4ヶ月間の開発のふりかえり

前回のふりかえりのふりかえりはここ 。2時間をとってこの約4ヶ月間の開発のふりかえりをした。

今回は2次開発というのもあって、メンバーも開発に成熟したし、1次開発でできなかったことのいろいろが改善できそうな見通しが立ってきたし、最高ではないものの最善ではあったんじゃないかと思う。私からみても十分によいものを提供できたと思う。8月の後半に私がテンパっていたのはなんだったのか?と思うぐらい、私が後半に詰め込んでやり過ぎたところもあったりはしたものの、それも終わってみればきれいにすべて回収できたのでよかったと思う。課題管理システムから情報を抜き出して1次開発のときと同じ指標の比較もしてみた。それによってメンバーのパフォーマンスが上がっていることも定量的に確認できた。これはまた会社のブログにもいずれ書きたい。これでメンバーも自信を付けて次の開発もがんばってくれるといいなと思う。今回はよい開発になったなと思う。

今回はいろいろ事情があって、私が東京へ出張してそのオフィスで1人でテレビ会議でふりかえりをするといったやり方になった。本当はこういう区切りになるふりかえりにもっと積極的に参加してほしい、オフラインで会議に参加してほしいと思う気持ちはある。それはそれで私の古い考えかもしれないし、メンバーからしてみたら、マネージャーがふりかえりにやかまして疎ましく思っているのかもしれない。若い人たちの考え方にあわせるという意味では、大きなふりかえりをテレビ会議で行うのも構わないのだが、オフィスで1人会議は私のテンションが上がらないことにも気付いた。先週から準備して資料を作って、わざわざ出張して会議をして、会議の場に誰もいないというのは、どう繕っても、私も出張せずにリモート会議した方が合理的だったと思えてしまう。その自分の中の違和感なのか反感に対して新しい答えを見い出さないとこの体制はうまくいかないと新たに思う一時でもあった。

大崎に泊まる

五反田のいつもホテルに泊まるのも飽きたので気分転換に大崎の ニューオータニイン東京 に泊まってみた。五反田から大崎は一駅の距離で川沿いを歩いていける。この川にかかる橋が夜はライトアップされていて散歩していて気持ちがよい。まだちょっと暑かったけれど、15分もあれば歩ける。宿泊プランを朝食付きプランにすると素泊まりに比べて500-1000円高くなる。それでもいつも泊まっているホテルの料金と比べて大差なかったので試しに朝食付きにしてみた。料理の種類の多い朝食ビッフェでとてもよかった。外食が多いと野菜が不足しがちになる。私はこういうところで基本的に野菜サラダを大盛りにしてたくさん食べるようにしている。その野菜の種類やコンビネーションのやり方が増えるほどアレンジする楽しみも増えて楽しい。これはいいなと思って今後もしばらく大崎に泊まってみようと思う。

半期に1回のふりかえり大会

少し寝ようかと思って横になった時間はあったものの、寝過ごすのが怖くて結局は新幹線の始発まで起きていた。この時期は4時を回り始めると徐々に外が明るくなっていき、5時は普通に明るくなっている。夏至も近い。

テックブログ公開

先日書いてレビューを終えた テックブログを公開した。

コンテンツは狙ってバズらない

私の言葉だ。多くの開発者が関心をもつ話題ではないけれど、仲間内では評判がよかったので拡散されると嬉しい、、、。と淡い期待を寄せていたが、そうでもなかった。工数をかけて丁寧に書いても関心をもたれないことはよくある。個々のコンテンツがバズらなくてもコンテンツは積み重ねることも大事なので私がよいと思う記事を今後も書いていく。

半年間の開発のふりかえり

2時間をとって半年間の開発のふりかえりをやった。課題管理システムから定量的な数字をみたり、定性的なのは、過去のマイルストーンのふりかえりのふりかえりをしたり、課題管理システムから特定の issue を取り上げて改善するにはどうしたらよいかなどを議論したりしてみた。

私もチームのファシリテーションに慣れてきて、自由に意見を求めるよりも、個人個人を指してどうですか?と尋ねる方が意見がわーっと出てきて議論が活発になることに気付いた。なにか議題があったら必ず当てられて意見を言わないといけないとメンバーも察してくれるようになっていると思う。そういう空気になってきた。そして、ちゃんと答えてくれるのでそれで問題ないと思う。大人しいというのか、消極的というのか、うちのチームのメンバーには意見を求められなければ言わないという姿勢が垣間みえる。これは開発の自律性とは反対にある価値観なのでなるべくそこから脱却して自分から議題に意見を言うようになってほしい。もしかしたら私が喋り過ぎなのかもしれない?

ふりかえりをしないチームは多いので何もしないよりはなにかしら 示唆は与えられた のではないかと思いたい。

第4期のふりかえり

今週は19時に帰ってきてそれから晩ご飯を食べて家でくつろぐという生活に戻ってきた。生活に余裕をもてるようになってきた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。先週はリリース前の余裕の無さからお休みしたので1ヶ月ぶり。今日の議題はこれら。

  • 第4期のふりかえり
  • デザイナーさん向けの発注や契約の話し

先週末にふりかえり資料の叩き台を作って洗練させた資料を説明していたら1時間ほどかかった。もう3年会社を経営したので財務や経営についてわかったことがたくさんある。会社の貯金もある程度貯まって財務が安定してきた。無知の無知が怖かったので創業以来、財務に注意を払ってきた。しかし、これから業務がプロダクト開発へ移行していくに当たって財務のことを気にかける必要はないと私は考えている。そんな油断をしていると足元をすくわれるのかもしれないが。

業務委託の契約の話をしていて、請負契約と準委任契約の違いについて話題になった。うちは創業以来、準委任契約でしか働いてきていない。ipa が公開している 情報システム・モデル取引・契約書(アジャイル開発版) でもアジャイル開発は準委任契約を推奨している。私も開発プロジェクトに入って柔軟に開発するスタイルを好むことから相性がよかった。うちの会社は準委任契約のメリットを十分に理解できている。

準委任契約のメリット

  • 成果物の取り決めがないので納期へのストレスや開発遅れに対するリスクが小さい
  • がんばって働けば人月単価の金額が毎月売上としてあがる

準委任契約のデメリット

  • 普通のサラリーマンと働き方がほぼ変わらない

はらさんと話していてとして請負契約の特徴として次のようなことが上がった。

請負契約のメリット

  • 請負契約の方が儲かる可能性がある
  • 自分たちが実際に作業しなくても協力会社に発注できる

請負契約のデメリット

  • 成果物ができないと売上が上がらず利益率が悪化したり、赤字になるリスクがある
  • 納品しないと売上が立たないので資金繰りが難しい

私の基本的な姿勢として協力会社に開発の業務を発注したくない。とくに品質レベルを知らない協力会社に発注することは100%ない。それは私が sier 出身なので他社へ開発を発注するときの難しさや管理のしんどさをよく知っているからだ。私が sier を辞めた理由の1つに自分がミスしたわけでもないのにお客さんに謝り続けるのが嫌になった。開発を他社へ依頼するとそこで発生した不具合やトラブルのすべての責任をもたないといけない。自分がミスして迷惑をかけて謝るのはなにも苦にならないが、他人がミスしたものを自分の責任として謝るのが当たり前の生活をやっていると、私の方がもっとうまくやれんじゃないかと考えてしまったりした。1人だと開発はスケールしないが、他人が品質の低いもの作ってしまうのと比べて開発の満足感が違う。

いずれにしても請負契約は双方に体力がないと資金繰りが厳しくなってお互いにリスクがある。

また資金調達の手段としてのクラウドファンディングは複数の側面があっていいんじゃないかという話題も少し盛り上がった。少し前に私もいとうさんのプロジェクトの応援のために支援した。800,000円という目標金額に対して残念ながら665,540円と未達ではあったものの、76人もの支援者がいることがわかる。私がクラウドファンディングのプロジェクトを作ってもおそらく支援者はよくて数人といったところだろう。いとうさんのメディア力であったり信用のすごさがわかる。クラウドファンディングやってますというのが支援することに関心がなくてもシェアするだけで開始前からマーケティングメッセージになる。そんなプロジェクトがあるんだというのを知ってもらうだけでも大きなことだと思う。

開発合宿の計画づくり

昨年度に workcation と称して行ってきたイベントを今年度も行う。いとうさんから2泊3日のようなちゃっちいイベントをワーケーションと呼んだりしないと教えてもらったので今年は開発合宿と呼ぶことにする。タグも新規に camp に付け替える。前回は6月という閑散期に行って空いててよかったのだけど、今年は最も賑わうという冬の繁忙期に行ってみたい。夏と冬だと情緒も変わるはずなので私にとってどちらがよいかも判断してみたい。身近な人たちから声をかけて、昨年は4人だったが、最大13名泊まれるそうなのでもう2-3人ほど増えてもいいんじゃないかと思ったりしている。まずは日程調整からしていかないといけない。

考えているとストリームが発生する

18時から20時半ぐらいまで寝て、それから晩ご飯を食べに出掛けて、23時頃に戻ってきてまた寝て、4時に起きて、6時に起きた。出張の初日は不規則な寝方になる。

定例会議とふりかえり

リリースまであと3週間。一部の開発がまだ完了していないことに大きなストレスと懸念を感じつつ、進捗はしているそうなのでその対応が完了するのを待つ。いまは日々の進捗や発生する事象に注意を配りつつ、メンバーは QA レベルのテストを、私は淡々とリリースの準備をしている。外部からアクセスできるプライベートなコンテナレジストリを docker hub でお金を払うか、自社で運用するかの決めの問題や外部向けにドキュメントを公開するための決めごとなどを確認したりしていた。

毎月のマイルストーン終了後にふりかえりをしている。今月は対応した issue のうち、70%超を私が fix しているのであまり話題がないかなぁとか思っていたけど、全然そんなことはなく、活発にふりかえりのコメント (付箋に書く) が出てよかった。当初は付箋に書いた内容に対して関心のあるものをメンバーに投票してもらっていた。そして、メンバーの関心の高いマークがたくさん付いたものから掘り下げて聞くようにしていた。最近は3人でふりかえりをやっているため、すべての付箋をみていっても10個未満程度、すべてヒアリングしても時間がちょうどよいので投票をやめた。そうすると、メンバーが自分のやったことや思ったことを他者へ話す機会になっていて、これは内省を促す意図でとてもよいことじゃないかと思うようになってきた。

ふりかえりをしない人やチームは成長しない

これは私の持論だ。うまくいかなかったときにふりかえりすると、当事者が嫌な気持ちになったりしんどかったり、責任を感じたりとネガティブなイメージから、私の経験則ではふりかえりを行わないチームの方がずっと多かった。こういう小さい積み重ねを継続的にやるのは後になってその人の価値観や成長に影響を与えるのではないかと最近は思う。うちのチームでは厳しく責任追及はしないのでメンバーが率直的にこれができなかったとふりかえることはできるようになっているとは思う。

ふとふりかえりをしていてこんな言葉が私の口から出た。

作業の進捗をストリームとして確認できると嬉しい、ストリームを眺めているとメンバーが考えているのかどうかが分かる

エンジニアリング組織論への招待 に次のような節がある。

「悩む」と「考える」の違い

「考える」は行動であり、「悩む」は状態なのです。考えているのであれば、それはメンターがその行動を見ることができます。しかし、「悩む」であれば、メンターは心の状態を観察することはできません。

悩んでいる状態は手が止まっていて、頭の中で思考がぐるぐる巡っていて、もやもやしている状態。考えているとは、課題を書き出したり、分解したり、調査したりと忙しく行動していると言える。当然、考えないと優れた品質のアウトプットは出せない。正に私がやっている課題管理も、そのための課題管理システムも考えていることを確認・監視するために有効な手法とシステムであることが伺える。チームのふりかえりをしながら、そういった話しをメンバーに共有したりしていた。

1週間を管理しようとしない

1時に寝て5時に起きた。ホテルのテレビを付けっぱなしで寝たら朝のニュースで起きた。なんとなくニュースをみながら7時ぐらいまでのんびりしてた。

1週間のイテレーションはナンセンス?

毎月行っているマイルストーンのふりかえり。今回で3回目なのでメンバーもだいぶ慣れてきた。11, 12, 1月と3ヶ月に渡って課題管理をメンバーに実践してもらいながら開発してきた。当初、開発のイテレーションを1週間で行うか、2週間で行うかの話し合いで短い方がいいんじゃないかとなり、あまり深く考えずに1週間のイテレーションで開発をまわしてきた。しかし、いまとなってはこれは開発のイテレーションとは違うものになっている。

最初の1ヶ月はメンバーにとって慣れないワークフローだから、1週間のイテレーションでこの issue をやる・やらないといった厳密な取り決めはしなかった。その後、徐々に慣れてきたのを見越して、定例会議のときに issue 一覧をみながら、メンバーに2-3個ぐらいの issue をアサインしたり、issue の優先順位付けを明確にしたりしてきた。必ず issue を完了させるという強い制約を課していないものの、だいたい毎週アサインしたものをメンバーは対応してくれていたので、マネージャーとしての私の視点からもとくに問題はないようにみえた。要はうまくまわっているのでそれ以上の管理をしなくてもいい状態だったと言える。

一方で、本来の課題管理のイテレーションとは異なる開発のワークフローになっていて、それがよいことなのかどうか、私自身にも明確な答えがなかった。それでメンバーに尋ねてみた。いまの1週間単位のイテレーション (開発のワークフロー) をどう思いますか?

メンバーからは、1週間の作業内容を厳密に決めなくてもいいんじゃないかという意見が出た。それは私の考えとも一致していたものの、開発のイテレーションを2週間に伸ばすことについて話しているときに、そうしたとしても、定例会議は毎週やりたいという意見が出た。要件確認や仕様共有のために重要だという。通常、イテレーションの成果共有のために定例会議とイテレーションの長さは一致している。仮にイテレーションを2週間にしたら定例会議は2週間に1回となる。しかし、メンバーの視点からはイテレーションを1週間にするか2週間にするかについて関心はないものの、毎週の定例会議で行っている情報共有は重要だという認識があった。

ここで開発のイテレーションと定例会議の頻度は別にあわせなくてもいいんじゃないかと考えるきっかけを私は得られた。スクラムもスプリントと会議体の頻度はセットになっているのでこの発想はなかった。ちなみにアリエル時代は1つのイテレーションが3ヶ月で定例会議もなかった。そして、うちのチームは1ヶ月のマイルストーンに対してふりかえりをセットにしている。これはもはやイテレーション開発の文脈でいえば、実質うちのチームはマイルストーンと呼んでいる1ヶ月が1つのイテレーションになっていて、1つのイテレーション内に4回の定例会議があるというイテレーション開発のワークフローになっていることに気付いた。課題管理の考え方やワークフローがもっと洗練されていくと、毎週の定例会議をやらなくてもよいようになっていくのが私の経験から自明である。しかし、うちの開発は私も含めて8割以上がフルリモートワークなので、メンバー全員の顔を合わせる機会を作るという観点から毎週の定例会議は大事な場にもなっている。

実際の開発のマネジメントをしてみると、私自身、分かっていなかったことや新たな発見があって、まだまだ自分自身も修行の身であることを実感する。ここでの結論としてわかったことは次の通りで、ロードマップにおける最初のフェーズが完了する3月末までは現状のワークフローを継続してみることに決めた。

  • 開発のイテレーションとして1週間は短過ぎて管理対象としてあわない
  • 開発のイテレーションと定例会議の頻度をあわせなくてもよい
  • フルリモートワークの場合、メンバー全員を集める目的は情報共有だけではない

初めてのマイルストーンふりかえり

0時に寝て何度か起きつつ5時に起きた。慣れないホテルでの就寝なのに昨日はバテバテだったから割と眠れた方だと思う。

ふりかえり

1ヶ月 (厳密には4イテレーション) をマイルストーンとし、マイルストーンを終えたらふりかえりを行う。前にスクラム開発で行っていたふりかえり手法をベースにしながらやってみる。ポジティブなふりかえり向けに fun/done/learn という手法がよさそうだったので採用してみた。ツールは jamboard を使った。

初めてやってみたので進め方そのものにいくつか反省があった。オフィスで大きいスクリーンに映してみんながみえるようにしながら jamboard にコメントを書き込んでいく同時作業が割と忙しかった。jamboard で付箋を書くときの操作性が微妙によくない。慣れの問題かもしれないけど、なにかあとひと押しの操作性が足りない気がする。

最初なのでやり方の例として私も付箋にコメントを書きながらやっていた。私が参加者の1人として振る舞うと進行が止まってしまって忙しくなることに気付いた。あとで付箋に対して「いいね」をつけて共有してもらうときに、私の役割が開発者としての振る舞いとファシリテーターとしての振る舞いが混ざってしまって、他の参加者がどう感じたかはわからないが、私自身がいま何をやろうとしているのか分からなくなるといった混乱をきたすことがわかった。ファシリテーターとしての私はメンバーの意見を聞いてまとめ役をしないといけない。しかし、開発者としての私が意見を発してしまうと、私の意見を私がまとめることになってしまい、その客観性を担保しているのかどうかが分からなくなってしまう。要は簡潔なまとめなのか、個人の意見なのかの見分けがつかない。ファシリテーターとして振る舞うときはメンバーとしての意見を言わない方が進行がやりやすくなることに気付いた。初めてやったときはこんなもんか。次回への反省につなげる。

やったことは、課題管理システムから自分が担当者の issue をフィルターして眺めればすぐに把握できるが、ネガティブなふりかえりの気付いたことや改善したいことを掘り返す方法がないことにも気付いた。マイルストーンが1ヶ月なのでどこかに記録しておかないと忘れてしまう。go のプログラミングにまだ慣れていないといった付箋がたくさんあったが、それ以外はもう覚えていないというのもあったと思う。忘れないための一時記録の仕組みを考えないといけないことに私自身が気付いた。