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

会計監査と数字の着眼点

note で300円で販売している記事をみかけた。監査法人に勤めていた公認会計士が勝手にレビューしてみた的な記事になる。

• Colabo3期間会計報告レビュー

タイムラインでみかけたことをきっかけに私も過去3年分の会計報告を眺めたり、社内コミュニティで時事問題として取り上げていたので関心があった。経営者として他社の財務諸表をみる機会は私もあるので、会計士さんがどういった数字の見方をするのかの視点はとても勉強になった。現時点で不正をしているという話ではなく、会計報告からみえる数字だけを追いかけても経費の数字のいくつかに不可思議なところがあるという会計士からの指摘だった。ヒアリングすれば解決するかもしれないしそうじゃないかもしれない。一方で国や都からの少なくない金額の助成金 (税金) を受け取っているので会計報告に不明瞭なところがあるのであれば、精査して説明責任を果たす必要はあるだろうというのは一般的な共通認識ではないかと思う。

スクラム雑談

【三宮.dev オンライン】語り合おう！スクラム開発雑談会！ に参加した。常連のメンバー3人で話し始め、途中から主催者の先輩が加わって、sier のマネジメントのしんどい話しみたいものになって、最後はフロント／バックエンドの技術談義とかハックバーどうよみたいな話しになって、まさに雑談イベントみたいなものになった。ニフティのスクラム という本があるよと教えてもらって無料なので読んでみた所感をつぶやいたりもしてみた。あるイベントでも スクラム雑談 をしていて気付いたことの1つに、スクラムうまくいかない話しの大半は、スクラムというガイドライン上に洗い出された組織の課題を議論するようになるのではないかと思う。組織の課題の洗い出しにスクラムは使えるが、スクラムをやれば組織の課題を改善できるわけではないとわかってきた。

教えてもらったので斜め読みで目を通した / ニフティ | ニフティのスクラム #技術書典 https://t.co/Jh8QlGX4aX

— Tetsuya Morimoto (@t2y) September 18, 2022

0時に寝て7時に起きた。あまりよく眠れない。新しい施設のサービスインで社員さんは忙しそうなので画面のバグ修正をしたりレビューの検証をしたりしていた。

スクラムイベント

Scrum Developers Night! Online #11 に参加した。過去にストーリーポイント運用がうまくいってないという話題を書いてきたけど、他の組織やチームだとうまくいっているのか、どんな感じなのかを聞いてみようという意図で参加した。他のスクラムやっている人たちの話しを聞いてみたかったんだけど、割とこっちのやり方や運用を聞かれるような展開になったのでこちら側の話しが主になってしまった。相談してわかったことなどをざっくりまとめる。

• ストーリーポイント運用の方法自体は間違っていない
  • ストーリーポイント運用とは別のところに課題があるようにみえる
• スプリントで決めたことをできないのは問題
  • 1週間の見積もりすら合わないのだからそれ以上の期間の見積もりはあわないのは自明
• プランニングやリファイメントなどでタスク分割や見積もりの精度をあげないといけない
  • 大きな機能の見積もり後にタスクが増えるような精度が問題
• スプリントがある週の実稼働時間を考慮して見積もりしていないのは問題
  • 休みがあったり社内イベントがあったり実稼働時間によってベロシティはブレるはず

全体として総括すると、ストーリーポイント運用以前に、チームの問題が大きいのだろうと他の人たちと話していて実感した。スクラムの実践についての細かい改善点はあるものの、それ以上にチーム事情によるものや体制の問題の方が大きいということに気付いた。

0時に寝て3時に起きて2時間だらだらしていて6時に寝て7時半に起きた。ここ1週間ほどこういう寝方が続く。

運用対応の続き

昨日からまだトラブルが続いているらしく運用対応がてんやわんやになっている。私は本番環境のログもデータもみれないから社員さんから伝え聞く分しか状況がわからない。そのため、現状の運用でうまくいっているのかと思ってたら、たまたま他の要因が重なって発生しているのかもしれないけど、大きな障害に発展しているのかもしれない。従来の正しいと思われていた運用ツールにも誤りがあったらしく、これまでの運用は正しかったんやろか？という懸念も出てきた。スクラムマスターからも、既知の課題を放置してトラブルが常態化して運用対応に工数を割いて他の仕事ができなくなっているのではないか、仮説の検証をちゃんとやってないんじゃないかとかツッコミが入ってた。PO が未熟と言ってしまえばそうなのだけど、スクラムの悪いところは問題が起こっても責任の所在を曖昧に終わらせることがうちのチームでは多々ある。責任の所在をちゃんとふりかえらないと、再発防止やその対応に誰も責任をもたないという状況が発生する。今回のふりかえりがどうなるのかは来週にならないとわからない。ちゃんと反省してチームとしてふりかえりできるかどうかも観察してみようと思う。

次のお仕事探し

以前から勝手に私が応援している地元の会社の求人情報をみかけた。それは正社員しか募集していないのだけど、ダメ元で業務委託を雇っていないか問い合わせてみるかを迷っていた。そこで地元のコミュニティの知人が、地元の会社の中の人を知っていると話していたことを思い出して、その知人に業務委託で雇っているかどうかを試しに聞いてもらえるかを尋ねた。快く聞いてくれて、直接つながって問い合わせてくれて本当にありがたい。そしたら業務委託は採用していないらしいのだけど、一応は経歴はみるかも？といった返事だった。じゃあ、ダメ元で採用情報のページから応募しようかと考えていたら、その知人経由で経歴がわかるものがあったらそれでいいという話しになって linkedin と会社の事例紹介の url を転送してもらった。普通に応募するなら履歴書と職務経歴書をファイルで送らないといけない。仮に不採用になっても url を送るだけの手間しかかかっていない。わずか1時間ほどのやり取り。そう思うと人材求人プラットフォームに登録して、定型的な資料を用意して、手続きをとって、先方からの返信を待つといったワークフローはなんと無駄の多いことかとか考えたりしていた。

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

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。先日の勉強会で聞いた mvp の考え方 について気になったので相談してみた。はらさんと相談していて mvp とは一般論としてこうだと語ることはできないということが理解できた。大事なのは mvp でやりたい目的であって、その目的によって mvp が何になるかは変わってくる。

• コンシューマー向け (toC) と業務向けの (toB) でアプリケーションは全く異なる
  • toC 向けはニーズや要件がまったくわからない
  • toB 向けはニーズや要件が明確にわかっている
• mvp が何になるかは目的によって異なる
  • toC 向けはニーズや要件を把握するのが目的になる場合がある
    • PMF (Product Market Fit) という概念もある
  • toB 向けはニーズや要件に合致するものかどうかを確認するのが目的になる

あと フリーランス協会 という団体があるのを教えていただいた。フリーランスは会社員と比較して守られていない箇所がたくさんある。例えば、取引先とトラブルになって損害賠償が発生するとかがある。うちの会社に限って言えば、役員は基本的に労災保険の適用外になる。この仕組みを見直そうといった取り組みや制度があるという記事もみかけたりはする。そういった保険やら福利厚生やらいろんなものをパッケージングして比較的安い金額で提供してくれるらしい。はらさんによると、なぜ○○協会といった団体がたくさん作られるかというと、団体では受けられるが、個人では受けられないサービスがあるからだという説明をされていた。

むきなおり

チームで改善のための会議があった。会議のホストがいなくて、誰も何も準備をせずに会議が始まり、課題は何なのかを会議中に相談して決めるみたいな、これまでもそうだったようにだらだらした会議の始まり方をした。私はすぐにいなくなる人間なのであまり今後の方針についてはコメントしないようにしている。議論の行方だけを聞いていた。ストーリーポイントとベロシティの運用が混乱をもたらし始めていて、PO がベロシティは納期の対する進捗度合いを把握するために計測していると発言していて取り返しがつかなくなっているように感じた。いつまでに何ができかるかの期日を出さないといけないという使命感からストーリーポイントをスケジュールと同視ことから抜け出せていない。周りの知人と話したり、私自身の解釈としてもストーリーポイントとベロシティで把握できるのはチームの成熟度や成長の度合いだけになる。1年前よりもベロシティが増えているのであればチームは成長したと言える。言わばたったこれだけのことしか分からないし、成長の度合いに関すること以外に使うべきではない。

ストーリーポイントの誤解と誤用は、特にプロセスがチームから部署、企業へとスケールして行くときに、時間をかけて増幅されていきます。これらの誤解と誤用を正すのは、時間と労力を要します。

ストーリーポイントを使うのをやめよう で書かれているように、ストーリーポイントという抽象化された数値が独り歩きして、自分たちの都合のよい指標になると考え始めている。この記事によると、これが周りに広がっていくにしたがって混乱が増幅していくように書かれている。いま正にそういう雰囲気をみていて実感した。

1時に寝て6時に起きた。夜中に3回ぐらい起きたかな。夜あまり眠れない。

リーン思考を学ぶ勉強会

スクラムマスター主催の勉強会があった。スクラムマスターは折に触れてリーン思考が大事という発言をするので気にはなっていた。リーンという概念はトヨタ生産方式から触発されている。リーン思考はフロー効率の方を重視するらしい。

• フロー効率: 価値を素早く提供する
• リソース効率: リソースが遊び無く稼働している

どちらも効率の話しをしているが、なんの効率をあげるかが異なる。i/o におけるレイテンシとスループットの関係に似ている。レイテンシを上げればスループットは下がるが、スループットを上げればレイテンシは下がるという反比例の関係となる。おそらくフロー効率とリソース効率の話しがトヨタから出ているのであれば、工場の稼働率の話しとも関連があると考えられるのでお互いにトレードオフの関係が成り立つのではないかと推測する。リーン思考は小さく作って育てていくことを指していて、同義語として mvp, イテレーティブ、バーティカルスライドなどがある。スクラムは戦術であり、リーン思考を実践するのは戦略となる。リーン思考を具体的にどう実践するかは自分たちで考える必要がある。あとは用語や概念の詳細な説明が主だった。リーン思考のメリットとして次があげられていた。

• 早いタイミングでフィードバックを得られる
• 早く作るとリスクを早期発見できる
• 小さい状態でフィードバックをもらった方が手戻りが少なくなる

一方でリーン思考の概念はパラダイムシフトを伴うので難しいと説明されていた。難しい背景は次になる。

• ウォータフォールはリソース効率を重視する考え方である
• 産業革命の時代に科学的管理法としてウォータフォール的な考え方が広まった
  • 工場でのモノヅクリにはうまくいった
  • ソフトウェア開発ではあまり適用できない

また MVP（Minimum Viable Product）の意味を理解する。そして、なぜ私はEarliest Testable / Usable / Lovableを好むのか。 の考え方の例としてこの記事のスライドを引用していた。これはこれで理解できるけれど、これはプロダクトアウトの考え方であって、業務アプリケーションはまた違うのではないかと私には懸念に思えた。自分たちのプロジェクトにとってどう実践していくかが重要になるが、そういった話しはとくになかった。プロダクトオーナーからも現状とリーン思考の概念とのギャップや違和感を感じて質問していたようにみえた。

リーン思考は難しくてなかなか実践できないといった説明があったところに私は違和感を感じた。リーン思考とは無関係にそもそもプロジェクトマネジメントは難しい。現実のプロジェクトマネジメントは生きものなのでケーススタディや教科書通りの論理でできるものではないと私は考えている。現実のプロジェクトにおける、ヒト・モノ・カネ・情報の4つを考慮した上で意思決定を適切なタイミングで行うことに正解はない。歴史に if はないので重要な意思決定を下してそれがどんな結果になろうと、別の意思決定をしたときの未来を知ることはできない。うまくいかなかったときにできることはそのふりかえりだけで、リーン思考を実践できていないという考え方はやや責任転嫁しているようにも受け取れた。

1時に寝て7時に起きて午前中はだらだらしていた。午後からオフィスでちょっと作業して夜はドラクエタクトしてた。

スクラムの悪いところ

金曜日に メタバース雑談会 に参加してチームビルディングや課題管理の雑談になった。そのときに課題管理やスクラムの概要を話してみたけど、多様なメンバーだといま一つ手応えがなくてコンテキストを揃えないと組織論の話しは難しいなと思えた。コンテキストが共有できていない状況ではあまり雑談に向く話題ではなかった。そんな中でスクラムの悪いところを考える機会が最近多いので簡単にまとめてみようと思う。もちろん、スクラムにはよいところもたくさんあって世の中に普及しているのはそれがためだと思う。よいところはすでにあちこちで言われているだろうから、あえて、ここでは悪いところを整理してみようと思う。

• 心理的安全性のないチームではぬるま湯と化す
• プロダクトオーナーに超人を要求する
• スクラムイベントが時間とともに形骸化していく

スクラムが悪いのではなくチーム (組織) が悪いということもできるが、スクラムを1年近くやっていて陥っているのでスクラムの影響は大きいと考える。

心理的安全性のないチームではぬるま湯と化す

スクラムでは個人の責任を問われることはなく、名前の通り、チーム一丸となって課題に取り組むことを意図するプラクティスなので、悪く言えば、個人の怠慢が問われることもまずない。ここでいう怠慢は悪意をもったものではないとしても 社会的手抜き を容易に発生させる。個々のメンバーの責任を減少させると必然的に裁量も減少してしまう気がしている。ある課題がうまくいかなくても自分の責任とは言えない状況であればそのまま放置してチームが解決してくれるのを待つという選択が合理的になるケースが出てくる。これは人間の習性として抗いがたいと私は考えている。楽をしたいのが人間だと思う。必然的に楽な方に引き寄せられていく。克己心とまで言わなくても自分を律して課題に取り組んでいないとスクラムの枠組みではいくらでも楽をしてしまえる。業務としてその品質や納期に一定の厳しさをもっていないチームは簡単にぬるま湯と化してしまう。

プロダクトオーナーに超人を要求する

以前、こみやさんと話していたときに出た話題。スクラムはすべての責任はプロダクトオーナーが負うことになっている。プロダクトオーナーは開発者でないことが多いと思われる。建前としては開発がうまくいかないことの責任をすべてプロダクトオーナーが負うことになるが、これはフェアとは言い難い状況もある。はらさんと話していると、プロダクトオーナーは無茶苦茶な要求を開発者にしてしまいがちなのでそれをなだめたり指導したりするポジションとしてスクラムマスターがいるという話しも聞く。うちのプロダクトオーナーは人格者でまったく無茶な要求をしない。おそらく現場出身の方なのでシステムに疎いことは周りも理解していて開発責任を問われていないのではないか推測する。プロダクトオーナーに責任が集中している割にスクラムマスターが盾になることで開発への口出しは制限される。またスクラムマスターも業務上の責任をなんら負っていない。スクラムマスターの助言を遂行する責任はすべてプロダクトオーナーに求められる。スクラムは業務の役割分担としてプロダクトオーナー、スクラムマスター、開発リーダーの三位一体のような構成を取るものの、責任をプロダクトオーナーに押し付けつつ、プロダクトオーナーの権限を奪う構成ともみれる。

スクラムイベントが時間とともに形骸化していく

スクラムに不慣れなチームがスクラムガイドに書いてあることを実践していくには少し時間がかかるし、スクラムマスターのようなスクラムガイドを熟知しているメンバーに指導を仰ぐのは理に適っている。しかし、半年もやればスクラムガイドの手順やワークフローをメンバーは習熟する。実際にうちのスクラムマスターはふりかえりのファシリテーション以外にやることがないとちょくちょく発言していて、実際にデイリースクラムも半分ぐらい休んでいる。ファシリテーション以外で業務のイニシアティブを取ることはない。スクラムマスターがドメイン知識を身につけるべきかどうか、私はまだわからないが、うちのスクラムマスターはドメイン知識を習得していないので業務の話にはまったく入ってこれない。少し前に ゾンビスクラム という言葉を教えてもらったが、スクラムイベントのいくつかはただこなすだけの業務になりつつある。うちのチームのスプリントの実態やストーリーポイント運用は私からみたら課題だらけだが、ダメなところも含めてその予定調和に慣れてしまって複雑で難しい問題を改善しようとしていないように私からはみえている。

2時に寝て5時に起きて7時半に起きた。夜も眠れなくなってきた。

ストーリーポイント改善への再考

プランニングしていたときに調査チケットをスパイクにしようという話題がでたときにストーリーポイントを割り振るかどうかという話しになった。スクラムマスターは5ポイント割り振ればよいと以前話していた気がする。そのときは時間がなかったから反論しなかったけど、ポイントと工数は別だからそれはよくないと反論した。割り当てたストーリーポイントに対して「○○さんならどのぐらいの時間でできますか？」と質問しているのがすでにおかしい。便宜上、ストーリーポイントはベロシティを計測して時間にマッピングされるかもしれないが、ストーリーポイントを直接時間にマッピングし始めると、担当者の個人差で大きく運用が変わってきてしまう。ストーリーポイントとスケジュールのアンマッチな部分を実際のスクラム運用でどう改善するのか？をつぶやいていたら、みずおちさんが返信してくれた。

うーん、なるほど。。文脈によって色々ですが基本的に3か月以上先の見積もりについては妄想のようなもので、当てられないのではと自分は考えてますね。当てられるとしたら、何の技術的挑戦もないプロダクトなんだろうなと思ってしまいます。

— Mizuochi Keita 水落啓太 (@mizuochikeita) August 9, 2022

見積もる期間をなるべく小さくしてスケジュールを提示しないというのが戦略として正しいと思う。

あと実際には、打ち合わせの日程調整やレビュー待ちなどの待ち時間もあり、ストーリーポイントの複雑さや開発の工数だけでなく、リードタイムの概念もある。スケジュールは納期が決まっているけれど、リードタイムが伸びてしまったときに納期は伸びてくれないのでそのギャップもなにかしら反映する必要はあるが、ストーリーポイントではチケットの依存関係やリードタイムの遅れを反映することはできない。

リファレンス

• スクラムにおける技術的スパイクの進め方

0時に寝て6時に起きた。夜中に暑さと気分の悪さで起きるのが常態化してきた。今日は珍しく4つの会議が重なって喋りつくして後半バテた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。前隔週を1回飛ばしたので話題がたくさんあった。

• スクラムの話題
• もてなしだけではもう食えない -ホテル経営学の本質と実践-
• 起業プラザひょうごさんの内覧

もう1年近くスクラムをやっているのでスクラムの弱点や欠点なども少しずつみえてきた。しかし、はらさんと話していると、はらさんが実践してきたスクラムと私がやっているスクラムにはいくつか違いがある。同じスクラムというガイドに沿っていても、実際は組織やプロジェクトの内容によって大きな乖離が生じるというのも事実のように思える。プロジェクトのサービスインに伴い、大きなふりかえりやストーリーポイント運用の見直しを経てわかったことを雑談しながら理解を深めた。主には次の3つにまとめられる。

• スクラムマスターの限界
• スクラムと心理的安全性
• ストーリーポイントという信仰

PO でも開発者でもないスクラムマスターはプロジェクトが経過する時間とともに貢献度が減っていく。ヒト・モノ・カネ・情報というプロジェクトのリソースのうち、もっとも変動するのは間違いなくヒトである。プロジェクトの初期とマイルストーンの区切りにおいてヒトだけが経験を経て大きく成長する。成長しないヒトがいるとすれば、それはそのヒトがさぼっているか、プロジェクトにマッチングしていないと言える。普通のプロジェクトマネジメントにおいて成長しないメンバーなど存在しない。大きなふりかえりによって、驚いたことにスクラムマスターだけがそうじゃなかった。安西先生の言葉を借りるとこうだった。

まるで成長していない ………

PO も開発者も日々の業務からドメイン知識を深めていき、大きく成長しているのに「ただ観ていただけ」のスクラムマスターは全くメンバーの話しについてこれていない。それが上辺だけの浅いふりかえりで終わり、総括はおろか、今後の改善の施策もまとめられないという結果になった。ファシリテーションをスクラムマスターが担っているからそうなってしまう。また過度に感情に配慮したふりかえりをするとネガティブな事実や結果を直視しようとしない。関係する誰かが責任を感じたり嫌な思いをさせる可能性はあるが、それらを認めないと次の改善の施策をたてられない。これは日本の会社ではよく起こることに思える。うちのチームは仲が良いだけのぬるま湯チームになっていてゾンビスクラムにも近付きつつある。

もう1つ、スクラムをやらなくてもよい背景の1つとして、チケット駆動開発と業務のワークフロー最適化の話題をつぶやいてみた。

チケット駆動開発の優れているところの1つとして、課題管理システムを中核にして業務のワークフローを明確化できるところにある。業務の始まりから終わりまではどんな会社でも何らかのワークフローがあって、その手順をメンバーが理解することで業務というものが成立する。

— Tetsuya Morimoto (@t2y) August 5, 2022

神戸市さんと雑談

Kobe x Engineer’s Lab という取り組みを担当されている職員さんとその運営会社の担当者と面談した。前から三宮.devのすみよしさんから話しを聞いていたので、そのつてで面談の依頼がきたと思っていたら、全然違う知人からの紹介だったので驚いた。ざっくばらんにエンジニア不足の社会問題の解決のために「神戸市として」どんな施策があるか、コミュニティはどう運営すればいいか、これまでに彼らがやってきたことの成果などを聞きながら雑談していた。エンジニア不足という社会問題と地域性は相性が悪い。私から意見したことはこれらかな。

• コミュニティはコントロールできない
• (個人や有志の) コミュニティとお金は相性が悪い

前者について、私自身、プログラマーのコミュニティと深く関わってきたことから、彼らがこの1-2年やってきたことの課題感はいくつか類推できる。コミュニティを中核に、自分たちの意図した目的を達成するのは相当に難しい。コミュニティに人を集めるにはコンテンツが必要になる。コンテンツのないコミュニティに人が集まることはない。多くのケースでコンテンツは主催が提供する。主催がコンテンツを作れなければ人を集められない。そして、コミュニティに人を集めるのも大変な労力だが、集まったとしても多様な集団の行動やモチベーションなどを、他人がコントロールして導くのは難しい。個人や有志のコミュニティは、主催が負担のないレベルで長く続けているうちになにか起きるかもしれないといったふわっとした願望で取り組むのがよい。コンテンツを提供し続ける主催の熱意は不可欠だが、必要以上にがんばり過ぎると燃え尽きてしまってやはり続かない。コンテンツと持続性の2つが優れたコミュニティを運営する上で最初にぶつかる課題かなと私は思う。

エージェント会社と雑談

次のお仕事探しに新しいフリーランス向けのキャリアエージェントの会社と面談してみた。11月開始だと9月中旬ぐらいに出てくる案件になり、いまから探していても時期があわないといった話だった。職務経歴書をまだ提出していなかったせいか、なんとなくマッチングしていない雰囲気がした。そのキャリアエージェントの会社が扱っている案件と法人としての私の働き方があっていないのかもしれない。手応えがなかったので別のキャリアエージェントの会社とも話しつつ次のお仕事を開拓していくことに決めた。

23時に寝て何度か起きながら7時に起きた。なんか体調が悪い。

ふりかえりとむきなおり

毎週火曜日はふりかえりの日。今週もスプリントゴールは未達に終わったわけだけど、未達が普通で稀に達成できるのが常態化しつつある。悪く言えば ゾンビスクラム 状態と言えるのかもしれない。サービスインのゴタゴタも解消したので PO からもツッコミがあってスプリントゴール達成できない問題が再燃した。私からみたらこんなところか。

• スプリント初期は前スプリントの残タスクをやるのが常態化している
• メンバーにやる気と実力がない
• コミュニケーションコストが高くてオーバーヘッドが大きい (スクラムイベント、確認や待ち時間など)
• フルタイムで働いていないメンバーがいる (ちょくちょくメンバーも休暇をとる)
• スプリントが1週間と短過ぎる

その議論をしている中でスクラムマスターが むきなおり をしようといった結論になった。私は用語を知らなかったので調べてみた。

この3点を満たしながら、事業をふりかえって、行きたい方向へとむきなおることが今回の合宿の狙いでした。ただふりかえるだけではなく、あるべき姿との差から、今後の方向性を決めることを、特に「むきなおり」と名前付けしています。ふりかえり、むきなおる。今回の合宿はギルドワークスの今後の方針と向き合うための機会としました。

事業をふりかえって、行きたい方向へむきなおる

ふりかえりの結果から方向性を変えることを呼ぶらしい。私はまったく理解できていないのだけど、普通のふりかえりをして改善するときは何と呼ぶのだろうか。ただの言葉遊びじゃない？という気もする。また後日、そのためのイベントをするそうなのでそのときに理解を深めてみる。

3時に寝て7時に起きた。一昨日からやっているリファクタリングが佳境なので1時ぐらいまでコードを書いてた。コミットするときにソースコードを自動整形したらリファクタリングと関係ないところに diff がたくさん出てしまって、数十箇所は diff と突き合わせながらフォーマットを手で直さないといけない状況になった。量が多かったので不満が溜まってコミットしたときに課題管理にこんなコメントをした。

ソースコードがフォーマットされてないから自動フォーマットするとリファクタリングと関係ないところに差分が出るからそれを元のフォーマットに手作業で戻す作業を1時間ぐらいしてた。帰りたい。

2022/07/29 00:33:45

翌朝に来た PO がたまたまコメントをみかけてデイリースクラムで質問を受けて恥ずかしかった。変なコメントしてごめんなさい。

ストーリーポイント見直し大会

導入前からもいまもずっと私は一貫してこのプロジェクトでストーリーポイントの運用は不向きではないかという姿勢をとっている。ストーリーポイントを嫌っているわけではなく、論理的にうまくいかない課題をどうやって解決して運用にのせるかの施策が何もないのに盲目的に運用しているところに懸念をもっている。私の懸念を解決する施策を誰かが責任をもって進めるなら反対することない。2時間という時間を設けていたのでストーリーポイントの是非も含めての見直し大会だと私は考えていた。しかし、そうではなかった。始まって30分ぐらいは見直し大会をどう進めるかの会議の進め方を議論していた。この時点では私はこの会議にやる気をなくした。誰もなにも準備してなく、ただ2時間という時間をとっただけの会議だった。次の1時間で直近の実際のチケットをもってきて、内容を説明してみんなでポイントを付けていく作業をしていた。その後の30分はプランニングポーカーやって遊んでただけ。ストーリーポイントの運用の見直しという視点は何もなくて、いまの数値はデタラメだから正しい数値がつくリファレンスストーリーを作り直せばいいというだけだった。誰も責任をもってないので時間を潰すだけの会議だったと思う。

ちょうど10月末でお手伝いを終了することを伝えたのもあって、プロジェクトから去る開発者があれこれ大勢側に疑義を申し上げるのもどうかという思いもあって、これ以上はストーリーポイントの運用に口出ししないことに決めた。おそらくチームというよりは組織としてどうしてもストーリーポイントを運用したい動機が別の理由からあるようにみえた。ストーリーポイントさえ付けておけば、プロジェクトのスケジュールがどうなっても誰も責任を追求されなくて責任者は楽なんだろうと推測する。

一方で、協力会社の若い開発者がチケットの内容を説明していて、何度か「コピペしただけ」という説明の仕方をした。私は違和感があって気になっていた。本人は悪気なく大した工数ではなかったと伝えたかったのだと思う。開発作業の説明でコピペしただけと発言して恥ずかしいという感覚もない。仮にコピペしたコードを扱うとしても、そのコードの拡張性や保守性を考慮して抽象化することはあるだろうし、論理にあわせて修正するからまったく完全なコピペなどあり得ない。この発言をプロの料理人に例えたら「既成品をレンジでチンしただけ」と言っているに等しい。推測だが、プロの料理人は仮に既成品を使ってもそのまま客に出すことはなく、必ずプロとしての付加価値をつけていると私は思う。プロの開発者として開発の姿勢に問題があることがわかってしまうのに加えて、ビジネスパーソンとしても適切な発言ではないことに気付いていないのが不憫に思えた。まともな会社で働いていれば、先輩に叱られたり指導を受けたりできるのが、そんなことすら知らずにキャリアを歩んでしまう懸念がある。このまま中堅になったときにどこかで失言して信頼をなくしてしまうのではないかと心配になった。

2時に寝て7時に起きた。前日はリファクタリングで0時過ぎぐらいまでコードを書いてた気がする。

内覧前に…

窓付きオフィスの空き をみつけて内覧依頼をしていた。昨日入居者が退去したということで日程調整して今日の13時から内覧を申し込みしていた。朝起きて楽しみにしていたら、午前中に電話が掛かってきて昨日たまたま申し込みがあって成約してしまったとのこと。もちろん内覧前に成約があることは承知しているのでそれ自体は仕方ないことだと理解している。タイミングがよすぎて陰謀論のように妄想していた。本当はもっと事前に決まっていたのに連絡するのを忘れてたとか、私の場合は同じ施設間の移動になるので利益だけを考えると外部からのご新規さんを優先されたとか、いくつかパターンは考えられる。妄想遊びはともかく、最低でも1ヶ月前には空き情報がサイトに掲載されるので十分な時間があるので他のお客さんが申し込む可能性は高い。私はそれも含めて縁があるかどうかを試していたところはあった。これは縁がなかったということで受け入れた。契約はできないけど、今後のために内覧だけさせてほしいとお願いして行ってきた。普通に内覧してよい部屋だった。空いていれば内覧後にすぐ申し込みをしていたので1日の差で希望が叶わなかった。とはいえ、すでに内覧したので次に空きが出ているのをみつけたら内覧せずに申し込みできる状態になったとも言える。もしかしたら、昨日申し込みした人も私と同じように事前に内覧はしていたが、なんらかの理由で申し込みできなくて今回は縁があったのではないかとも考えられる。いずれにしても、また次の縁があるときを待つ。

大ふりかえり大会

サービスインが落ち着いたのでお手伝いしている開発プロジェクトの大きなふりかえりイベントがあった。スクラムのスプリントが1週間単位なのでふりかえり自体は毎週やっている。ホストがスクラムマスターで、どんな風に数ヶ月分の大きなふりかえりをするのか興味があったんだけど、とくに目新しいことはなく、総論として期待はずれだった。毎週のふりかえりイベントの延長でしかなく、区切りとしての総括もなければ、次の開発に向けての改善や展望もほとんどなかったと思う。スクラムマスターは業務を理解していないのでまともにファシリテーションできなかったとも言える。みんながんばった、サービスインできてよかった、これからもがんばっていこうのレベル。

スクラムマスターがこのプロジェクトに参加したのは昨年の10月で、私が11月からお手伝いしているのでほぼ同期だということもわかった。その開発プロジェクト自体はその1年前ぐらいからやっていたのかな？現時点で2年ぐらい経っているのだと推測する。私がイニシアティブをとったところで評判のよかった項目はこれら。コメントを求められたので、開発者が開発しやすい環境を作った方が開発のサイクルが早くなって結果的にプロダクトの品質が上がるという当たり前のことを話した。

• 課題管理を backlog/github issues に分かれていた運用を backlog に一元化した
• backlog-github-integration-action の導入
• ビルド／デプロイのワークフロー改善

1つがっかりしたのが、ストーリーポイントを用いたバーンダウンチャートの実績 のふりかえり。ネガティブな結果が出ているのに、そのバーンダウンチャートがあったから間に合わないということがわかって納期を延期できたみたいなことを話していて呆れてしまった。導入当初、納期が守れなくて五月雨式に延期してしまう課題への対応として導入したはずだった。導入時に私は2回スクラムマスターにストーリーポイントで納期を見積もるのは誤った運用だと指摘した。しかし、スクラムマスターが他プロジェクトでうまくいっているからと強引に導入した経緯がある。そして納期をまったく守ってもいないのにその事実を真剣に総括しようとしない姿勢が不誠実だった。また翌日ストーリーポイント見直し大会をするという話しがあったからこの場は丸くおさめた。

スクラムマスターはポジティブな内容とネガティブな内容を交互にふりかえるようにファシリテーションしていた。あとネガティブ内容の厳しい指摘は意図的に避けているようにもみえた。おそらく担当者の心情を慮ったのだろう。人を責めるわけではなく、ネガティブな事実や結果と向き合って、組織として仕組みで次の改善につなげるというのは、私が言うほど簡単ではないのかもしれない。私は sier 時代にお客さんからも社内からも怒られるのが日常だったからいまの若い人たちよりはネガティブな事実に対する耐性が高くてギャップに映るだけかもしれない。