0時に寝て6時に起きた。

ストーリーポイント再考

スクラムのふりかえりイベントでストーリーポイントの見直しをしようという話題が出た。この半年ほどストーリーポイントを使って実際に開発をやった事実から整理してみる。

• 開発者のタスクも非開発者のタスクも同じ尺度のストーリーポイントを設定していた
• あるチケットのタスクをやっていてチケット分割すると、最低でもストーリーポイントが1増えていた
  • 元チケットと分割したチケットのストーリーポイントの総数が同じであれば問題はないが、ストーリーポイント1が設定されたチケットを2つに分割するとそれぞれにストーリーポイント1をセットしても2倍になってしまう。タスク分割したのにストーリーポイントをゼロにセットするのもなんか違う
• ストーリーポイントの数値からバーンダウンチャートを生成した (みえる化)
  • このバーンダウンチャートで運用して実際に2回の延期が発生し精度が低いことがわかった
    • 納期の2週間前に延期することがわかった
    • シニア開発者の勘と経験の方が精度が高かった

これらの事実から私の所感をまとめてみる。

• 開発者と非開発者 (プロダクトオーナー) の業務を同じ数値で表して合算するのは論理的におかしい
• 複雑な業務の開発プロジェクトでストーリーポイントの数値を設定するのは難しい
  • 複数のマイクロサービスを担当
  • 複数の技術領域を担当 (インフラ、フロントエンド、バックエンド、要件定義)
• チケット駆動開発と相性が悪い
  • チケット分割は担当者がタスクを完了させやすい粒度や内容で分割すればよかったのがストーリーポイントを考慮すると複雑さが増す
  • チケットの粒度はチームで統一されているのが理想的ではあるが、現実的にそのような運用の統制が取れているのを私はみたことがない
    • チケットの粒度とストーリーポイントの合計に相関が出てしまい、それは個人差 (属人化) が生じやすい
• 安易なみえる化による弊害がある
  • ストーリーポイントは開発の状況を表す指標の1つではあるが、現実をすべて表しているわけではない
  • 多次元的なパラメーターからストーリーポイントというただ1つの指標を用いて2次元にすることで他の情報が欠落する
    • 偏ったデータによる意思決定に使われる懸念がある (その情報を外部に発信していればとくに)

ストーリーポイントによる運用をうまくまわすにはいくつか制約があるように私からは思えた。

• 開発プロジェクトのスコープや業務内容が一定の複雑さにおさめられる
  • 一定の制約や制限がないと論理的に説明可能な適切な数値を割り当てられない
  • 例) 外部要因に影響をうけない1つのマイクロサービスを開発する
  • 例) 開発者はフロントエンドだけの開発をする
• 開発者と非開発者のタスクは別で管理する (合算しない)

1時に寝て7時に起きた。

2つ目のサービスイン

スプリントの最終日が今日になる。しかし、今日はサービスインの作業でバタバタしているので主要な開発者は運用サポートしたり、PO もシステムの切り替え対応で fix したタスクの検証ができないといった理由でこれ以上タスクを進捗できそうにないことを容易に想像できた。スプリントゴールに掲げたタスクのうち、9項目中2つしか完了してないという状況だった。ちょうど夕方にスクラムのふりかえりもあったので、今回のスプリントは一体何なの？みたいな懸念から始まって、やる必要があるのかないのか曖昧な優先度設定はよくないという意見が出ていた。サービスインする週にスプリントをやるのもおかしいというのは前回も私はコメントしていたんだけど、今回も全く同じことが話題に出ていて、過去の失敗から学ばないチームになってた。

個人的に、開発のマネジメントにおいて、できもしない (やる気もない) 納期を設定するのが嫌い。私が古い人間なのかもしれないけど、納期が設定されてそれが大事なんだと認識したらどんな手段を使っても納期に間に合わせようとする。例えば、泊まりがけで開発したり、深夜早朝・休日に開発したり、大事なんだったら間に合わせる。しかし、労力を払って間に合わせたものの、他のメンバーやタスクはそうじゃなかったりして、遅れても何も起きないとがんばってやった人がしんどかっただけで終わる。過去にそういう状況を何度も経験してきてやる気をなくすことが多かった。

もてなしだけではもう食えない

第6章 営業予算の使い方

米国帰りのマーケッターという新たな登場人物。学部から米国の大学に留学すると米国史を英語で学ぶのが大変みたいな余談が出てくる。日本史は2000年を長く薄く勉強するが、米国史は200年しかないから内容が濃いのと最近の話だから史料も多く細かい史実を学ぶ必要があるという。全然、本題じゃないけど、歴史好きの私としてはおやと思えて楽しめた。いくら敏腕なマーケッターでも業務知識がないと空回りしてしまう。マーケティングの精度をあげるために必要ならば、その教育コストもマーケティング予算から捻出すべきだといった話しも出てくる。普段、会計システムに勘定科目を調べながら経費を入力している私にとってはなるほどなぁと、またまた本題ではないところで感心してしまった。

統計学のp値が5%以下ということは95%の確率でそのデータ上の差が実際に起き得る確率を表す。統計学は大事だとか、エクセルを駆使してデータ処理しろとか、そういう話題も出てくる。あとは古典的なマーケティングの手法として AIDMA モデルが紹介されている。基本的な考え方として知っておいたら役に立つときもあるかもしれない。

1. Attention (注目)
2. Interest (興味)
3. Desire (欲求)
4. Memory (記憶)
5. Action (行動)

例えば、Attention は情報誌に広告を出してみてもらうようなフェーズを指す。みてもらったら Interest に移る。口コミの内容で興味をもってもらうとか。興味をもってもらったら Desire として実際のサービスを体験してもらったりしてより強い欲求をもってもらう。一般論として Desire から Action へは間があくこともある。記憶させておいてそれを呼び戻すためのフェーズが Memory になる。最後の Action で成約を得て収益になるといった一連の流れを指す。

2時に寝て7時に起きた。今週はバテた。金曜日は非稼働日だけど、バタバタしているから普通に働いていた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今週はお手伝い先がサービスインでバタバタしていて議題の準備がほとんどできなかった。少し前に参加したアトラシアンさんのウェブセミナーのスライド資料が公開されたのでそれを眺めながら雑談していた。

jira の有料プランのサービスに jsm chat という halp の技術を活かした新機能が追加されたらしい。既存プランの延長上で使えるらしい。質疑応答のときに halp とは別プロダクトだと明確に回答していたので halp が今後どうなっていくのかの将来にはかなり懸念がある。チャットと課題管理システムの双方向連携という、slack や teams といったチャットサービスがよく使われるようになった昨今のビジネス事情にあわせたサービスと言えるだろう。

私も以前からその領域に課題意識をもっていたし、ベンチャーでは workstreams.ai も同様のサービスを提供している。満を持してというのか、(私にとっての) 課題管理システムのベースラインとなる jira にその機能が入ったことで競合製品も同様に機能拡張を提供していく気がする。1-2年後にはチャットと課題管理システムが双方向連携しているのが当たり前の開発スタイルになるのかもしれない。非開発者にとってはチケットを扱うよりも敷居が下がるのでそれは適切な世の中の変化だと私は考えている。

ゾンビスクラム

jsm chat と課題管理の話しをしているうちにスクラムの話題になった。Zombie Scrum Survival Guide という書籍があって形骸化したスクラムの特徴をまとめているらしい。ある記事で2021年から翻訳していると書いてあったので翻訳版が出版されたら読んでみようと思う。

• 「ゾンビスクラムサバイバルガイド」読んだ飼育係の日記
• ゾンビスクラムの4つの症状
• ゾンビスクラムを解決するための10の成功要因

ブログ記事の所感を読んだ感じだと、私がいま関わっているスクラムにも一部通じるところがあるなと思って関心がある。

うちのチームは1週間スプリントをもう1年近く続けているのだけど、これは検査が早い段階でできるというメリットがあるものの、開発のメリハリがないなぁとずっと思ってた。それはただ与えられたタスクを無理なくこなすだけというルーチンになってしまっているのと、昨今の労務管理を徹底する働き方改革？のせいか、残業・休出を一切やらない開発スタイルが開発者の自律性や意欲を削いでしまっているのではないかとも思う。もちろん「余白」があれば、業務時間内に好きなことをやったらよいと思うけれど、うちの場合は半分ぐらいのスプリントゴールが未達で、スプリントに達成できないタスクを盛り込むからスプリントゴール未達の状態で他のことをやるのが憚られる空気がある。もっとも好き勝手やっている私がそれを感じるのだから、若い開発者には相応のプレッシャーになっていると思う。結果として、指示されたタスク (プランニングで決めたこと) 以外のことはやらない雰囲気になってしまっている。試しに直近3ヶ月のスプリントバックログアイテムの種別のみで開発者のチケット登録した数をカウントすると次のようになった。

• 私: 66件
• 開発リーダー: 17件
• 開発者1: 14件
• 開発者2: 12件
• 開発者3: 1件
• 開発者4: 6件

これは課題管理システムに慣れていて、業務をタスク分解しながら作業していくというワークフローに私が最も習熟しているから、適度な粒度のチケットをいくつも作りながら作業をやっているという背景もある。しかし、いまやらなくてもいずれ必要なタスクも、業務をやりながら気付いたときに私は随時登録している。憚られる空気を感じている私が週4日労働で控えめにやっても3ヶ月でもこれだけの数が開く。要はゾンビスクラムだと開発者の自律性は期待できないという話し。

1時に寝て8時に起きた。昨晩はたくさん話してテンション上がって眠れなくてバテ気味。

serverless framework から cdk 移行の背景

木曜日はスプリントレビューがある。ステークホルダーが出席する唯一のスプリントイベントなので、大半はステークホルダーとの情報共有や質疑応答、プロジェクトにとっての大きい括りでの現状の共有になる。大半はお手伝い先の社員さん同士のやり取りで、協力会社の開発者は詳細が必要になったときだけ説明するといったイベント。前スプリントで 既存の lambda 関数を serverless framework から cdk へ移行 した。プロジェクトメンバーではないのだけど、業務のリーダークラスの方が cdk に関心をもって質問してくれた。聞くところによると、他プロジェクトでも cdk を使うようになってきているらしく、なぜいま移行しているのか？という質問だった。普段インフラ作業を孤独にやっているのもあって、業務の人が関心を示してくれたのが嬉しくて、変なスイッチが入っていろいろ説明した。serverless framework は2015年10月リリース、cdk は2018年7月リリースで、歴史的に serverless framework が普及して、その後に cdk が台頭してきたので実績や機能性から serverless framework が広く利用されている。但し、いま aws のインフラ管理をするのであれば、cdk は serverless framework 以上の管理ができることから cdk に一元管理した方がツールの学習コストを減らし、保守コストを下げることにつながるといった話しを丁寧に説明した。相手がそこまでの回答を求めていたかはわからないけど、関心を示してくれたことそのもので私が救われた気がした。

terapyon channel のコンテンツ公開

昨日の今日で公開された。ほとんど無編集だったのかな。web サイトのコンテンツ紹介の内容も手伝って夕方には公開された。

Podcast terapyon channel 「#58 もりもとさんの年1ゲスト会 マイクロ法人と開発ワークフローのカイゼン話ほか」を共有 https://t.co/aQfbuA6XrO #terapyon_channel

— terapyon (Manabu TERADA) (@terapyon) June 9, 2022

私の中ではいろんな話題を楽しく話せて充実感があった。一部にだけ関心をもつ人にも聞きたいところだけ聞けていいんじゃないかと思えた。基本的に自分の podcast を聞き直すことはないんだけど、今回は自分が充実感をもって話せたせいか、2回ほど聞き直しておもしろい話だなぁと自画自賛してた (笑) 。自分がよいものは周りもそう思うはずだと、ついつい先入観で考えがちだけど、全然そうじゃなかった。全くいいねがつかなかったので周りからみたら私の自己満足のコンテンツでしかなかった (笑) 。コンテンツあるあるだけど、狙ってコンテンツをバズらせるのは難しい。ブログでもがんばって書いた記事が全く読まれないことはあるし、手間暇かけずに軽く書いた記事がめっちゃバズったこともある。コンテンツがバズるかどうかは、最初にみた人たちが拡散するかにも依ってくる。いずれにしても、他者が関心をもつようなコンテンツかどうかは本人ではわからないというのは確かかな。

今期から会社のマーケティングも少しずつやっていく予定になる。自分がよいと思ったコンテンツに全く関心を示されないことは今後も多々あるだろう。作ったコンテンツを多くの人に見聞きしてもらおうと思ったらやることは1つだけで、当たるまでひたすら作り続けて、いつか当たるのを気長に待つという戦略しか、いまのところ思いつかない。

3時に寝て7時に起きた。ワーケーションの記事まとめで1時ぐらいまでオフィスにいたので帰ってきてから寝るのが遅くなった。

開発チームで設計の話し

昨日のスクラムイベントのふりかえりでスプリントゴール未達の話題があった。うちのチームはスプリントが1週間と短いのもあるけど、スプリントゴールが未達になることがままある。というか、メンバーも本当の意味でスプリントゴールを守ろうとしていない。守れそうにないと分かっても残業も延期もせずに最終日を迎えて未達で終わるだけでしかない。それはともかく、ゴールに含めるタスクの見積もりの精度が悪いのではないかという話題が出たときに、私の周りではプランニングにもっと時間を割いてがっつり設計までやるという話しを聞くので、うちらのプランニングはチケットを選択して適当に割り当てたストーリーポイントで曖昧な見積もりをしているのでそれが悪いのではないかという意見を上げた。そしたら開発者だけで設計のミーティングをやろうという話しになって、今日から毎週やっていくのかな。会議が増えて実務をやる時間が減るというデメリットはあるものの、チームとして学ぶ時間が少ないとは前から思っていたので、チームとして学びの時間を使ってメンバーのスキルを高めていくきっかけの1つとしてはよいかもしれないと思った。あるチケットで議論していて、本質的にはどうなるべき？という議論をして、直近のマイルストーンでは実装できないが将来的に対応するときのためにチケットを作っておいたりした。そういう1つずつの積み重ねが将来の品質をあげていく糧になる。開発者だけで設計という枠組で話すこと自体は大事な時間だとは思えた。

terapyon channel の収録

21時過ぎから terapyon channel の収録を行った。たまたまだけど、私は年に1回出演していて、今後もそのペースがいいなという思えた。6月は法人決算を終えて気楽になっているし、1年に1回なら近況報告として話題もたくさんある。前回からのツールのアップグレードとして iris というツールで収録した。これまではローカルで音声ファイルを録音して、終わった後に寺田さんへその録音ファイルを送信していた。iris を使うと、ブラウザだけでそれをやってくれるのでゲスト側の作業が減ってお手軽になる。ホスト側もゲスト側で録音に失敗するという最悪の事態のリスクを軽減できるので望ましいという。iris のホスト側の画面にはゲスト側の音声が録音されていることを表すインジケーターもみえるらしい。それが安心感を与えているとのこと。久しぶりに寺田さんと話して、podcast の収録というよりも寺田さんと普通に近況の雑談をしたぐらいの感覚でしかない。

2時に寝て6時に起きた。疲れていたからよく眠れた。

mvp（minimum viable product）で対応した

スクラムに限った話しではないと思うが、プロダクト開発をしていると mvp（minimum viable product）という言葉を聞くことがままある。昔ながらのイテレーション開発よりも、アジャイル開発の文脈でよく使われるように思う。というのは、短い開発期間でプロトタイプを作ったり、最低限の動く機能を作ったりすることをよしとする考え方があるから。昔ながらのやり方だと、イテレーション期間の中でそういった段階的な開発はするものの、外部からみたとき (もしくはマイルストーン) においてはそこそこの機能が提供されているので mvp といった言い方をすることはなかった。もしかしたらアルファとかベータとか呼んでいたかもしれない。最近ある lambda 関数の移行作業を行った。serverless framework でデプロイしていたリソースを cdk で一元管理する。その過程で既存のコードを読むと、ある id をハードコーディングで指定して FIXME がこんな感じに書いてあった。この id が指すリソースはその後なくなっており、本番環境で不要な処理が定期実行でずっと動き続けていたのと、本来は複数の id リソースに対して行うべき処理を実行していなかった。

# FIXME 対象 id 一覧を取得する。(Phase2までに対応します)
id = 'ABC001'

チームの開発リーダーはその存在を全く忘れていたし、このスクリプトを実装したさらに上位の開発リーダーからはこの処理の要否はよくわからないからチームで確認してという曖昧な返事が返ってきた。チームで確認したところ、この処理は必要だとわかり、この機に複数の id リソースに対して対応するようにした。何も知らない私が修正しても5分で対応を完了した。

mvp で対応したんで

このように実装者は話していたが、本当なのだろうか？と思えた。さらにこのスクリプトのエラーログのログストリームを監視して slack 通知する lambda 関数も移行対象で、コードの検証をしていたところ、slack 通知をするための lambda 関数が別途あり、その動作検証をしていたところ、その lambda 関数を呼び出す権限 lambda:InvokeFunction が足りないことに気付いた。これも実装者に問い合わせたところ、動作検証はやっていないし、過去に1度も slack 通知は発生していないという。状況証拠から考えると、権限が足りないために正常に動作していなかったと推測される。結果的に mvp で対応したという2つの lambda 関数は実運用で半年間、無駄にリソースを浪費して何の役にも立っていなかった。当然、引き継ぎも、課題管理システムのチケットも、ドキュメントも何ら残されていなかった。mvp で対応したという表現に開発で大事なものを誤魔化してはいないだろうか。

0時に寝て6時に起きた。調子よくて7時からオフィスで作業してた。なんだかんだで今日は主にお手伝い先のお仕事をしてた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日の話題はたくさんあった。

• スライドマスター作成のふりかえり
• 課題管理のためのメンタルモデルづくり
• スクラムの悪いところの共有
• 住民税の変遷について

会社としての発表のスライドを管理するために speakerdeck の会社アカウントを作成した。jjug の主催者のスライドチェックが完了したらアップロードしようと思う。google docs をそのまま公開するのと speakerdeck のどちらがいいかを検討した。google docs だと、スライド資料のノートまで公開されてしまうのでスライドだけなら speakerdeck の方がよさそうかなと判断した。

• https://speakerdeck.com/kazamori

スクラムの悪いところの1つとして、スクラムマスターが現状認識を誤っているときの是正方法がないという話題をした。スクラムマスターは po や開発者にアドバイスするのだけど、アドバイス自体が誤っているのではなく、アドバイスしている内容がプロジェクトの置かれている状況にあっていないというギャップに対しての、ふりかえりや是正の仕組みがスクラムに包含されていない。ある知人によると、スクラムマスターは超人でなければ務まらないという前提になっているのではないかという意見もあった。現時点でとくに結論はないのだけど、難しい課題だなぁと議論していた。

23時に寝て5時に起きて2度寝して6時に起きた。今年の連休はカレンダー通りに過ごすので月曜日と金曜日の飛び石のお仕事。

開発メンバーの加入

今日から開発者が新たに加わった。6月から正社員になるそうだけど、手続きの問題なのか、5月から1ヶ月間は業務委託として働くという。正社員の開発者がいないために要件定義がうまく進まず、外部の協力会社の開発者が遊休するといった状況があったのだけど、それが改善されていくかもしれない。聞くところによると、シニア開発者らしいのでこれからバリバリ活躍されるはず。一方で1つのチームの開発者が6人というのは中途半端なサイズにもみえる。2チームに分割した方が実際の作業はやりやすいかもしれない。

0時に寝て5時過ぎに起きた。

事例紹介

いまやっているお仕事の事例紹介の承諾をいただいたので掲載した。感謝。この事例紹介は私の自己満足なところも大きい。世の中に対して自社が貢献しているということを再確認するための手順の1つと捉えている。もちろん複合的に宣伝にもなるので自社にとってメリットもあるが、それ以上に自分に向けて書いているという思いがある。それはこれまで私にとっての、意義のない開発をし経験から、そういうお仕事はしないようにしようという戒めでもある。これまで組織の論理が自分の想いや方向性とズレてしまったときに退職してきたが、業務委託だと契約を終了できるので転職するよりは補正しやすいという側面もある。

• 事例紹介に星野リゾート様を追加しました

ふりかえり

スクラムのふりかえりで pull request のルール適用による成果について共有した。ルール適用前まで pull request のレビューに正社員のレビューを必須としていた。開発チームは協力会社主体であり、正社員は1人しかいなかった。そのため、レビュー負荷がその正社員に集中し、その人が多忙だと pull request のレビューが2-3日停滞するというのが常だった。そこで協力会社の approve でもマージできるような条件を設定したり、そもそも approve を必要としない pull request の条件を追加したり、pull request を作らずに main に直接コミットしてよい内容なども作った。ルール適用の前後で1ヶ月間のチームの平均値を比較した。

その結果、findy teams の pull request の作成からクローズにかかる時間が30%に短縮された。3倍近くクローズが早くなった。私個人の「1プルリクあたりの平均マージ・クローズ時間」においても 14.7h → 4.1h に短縮された。平均で1日待たないと approve をもらえなかったのがその日中にもらえるようになったと言える。ふりかえりで成果を共有したところ、わりと成果の大きさに驚かれたのに私が驚いた。経験が浅いチームの当たり前には価値基準や手順などに乖離があるんだろうなと思えた。私にとっては当たり前のことをやって、当たり前の成果が出て、当然こうなるって話しでしかないのだが、開発を数字でしか把握できない人たちにとっては斬新にみえるのかもしれない。

23時に寝て3時に起きて5時までだらだらしててそのまま起きた。

タスクがない

開発のロードマップ全体の計画が遅れているのに私のタスクが全くないみたいな状態になっている。昨日、開発のリーダーにタスクがないので適当なタスクをアサインしてくださいとお願いして、すぐアサインされるんだと思ってたら1日待ってもアサインされなかった。現スプリントのチケットはたくさんあるのにアサイン可能なチケットがないのか、アサインしなくても他の開発者で間に合うのか、その両方なのか、開発チームは5人いて、そのうち4人が外部の協力会社になる。私の感覚的には2人は余剰でタイミングが悪いとタスクがないみたいな状況になる。期限までにやらないといけないことは溜まっているのに。

workrooms 雑談

月に1回の はんなりPython メタバース会 #4 に参加した。workrooms で雑談会するのもだいぶ慣れてきた。毎月1-2回はやっている。Brave というプライバシーを重視したブラウザがよいみたいな話しがあって、とくに Brave Talk のビデオ通話がよく出来ているという話しがあった。課金しないと4人まで参加できて、$7/月でプレミアムプランになるみたい。コミュニティ用途なら zoom から Brave Talk に移行した方がよいとまで言ってたので、そんなによいものなのか、また後日触ってみたいと思う。

0時に寝て5時半頃に起きて6時半に起きた。

リーン思考

スクラムのふりかえりをしていて、スクラムマスターがふとスクラムっぽいものとスクラムとの違いの1つとしてリーン思考の有無をあげた。私がリーン思考というのを知らなかったので軽く調べてみた。

• リーン思考とモジュラー化を実現するための3ステップ

リーン思考とは？

リーンという考え方は、ムダを最小限に抑えつつ、顧客価値を最大化することです。そのためには、ムダを削除・削減させるような構造化された「働き方」と、それを継続的に改善し続けることが必要です。つまり、リーンな組織というのは顧客が何に価値を感じているのかを理解しており、継続的な価値向上に繋がるプロセスに注力するものです。繰り返しとなりますが、究極の目標は、ムダゼロな完璧なプロセスを通して、顧客に最大限の価値を提供することです。

引用しておいてなんだが、「リーン思考とは」と節を書いているのに直接な定義を最初に書かない文章は読みにくい。要約すると、リーンという概念を組織として理解していて実践していく考え方や心の動きをリーン思考と呼ぶのだろうか？スクラムマスターがリーン思考が足りないとか言っていたけど、あまりピンとこない。というのは、スクラムマスターは基本的に言うだけで実践はすべて現場に丸投げ。リーン思考が足りないというだけなら誰でも言えるが、日々の具体的な活動や実践にどう落とし込むのかを示さないので現場のメンバーにはあまり響かない。リーダーシップにもいろんなタイプがあると思うが、実践は実践力をみせつけてフォロワーがついてくる。とくに抽象的なよくわからない概念をビジョナリーが提唱するだけではなにも変わらない。

私自身がリーン思考を意識したことはないが、課題管理に関して開発のワークフローを最適化するというのはある種のリーン思考とも言える。チケットのワークフローが洗練すれば洗練するほど効率がよくなってイテレーションのサイクルが多くまわり、結果として価値が速くユーザーに届いたり、試行錯誤の改善が早くなる。キーワードとして一応は覚えておく。