認定スクラムマスター研修を受けた

1/24〜26の3日間で認定スクラムマスター研修を受けてきました

なぜ受けたのか

前々から受けたいとは思っていたけど仕事での経験や知見を積んでから…と思ってました。
でもどこかのタイミングで「きっといつまで経っても十分と思えるときは来ないんだろうな」と漠然と思うようになりました。
それならさっさと受けて自身の学びと発揮価値を増やしたほうがいいと考えて次に開催されるタイミングで受けようと決めていました。

それで11月の頭に1月の研修の開催が告知されたのでそれに申し込んで受けました。

研修の雰囲気

研修は講義とワークショップの形式で行われました。
講義も質疑応答でも語り口は穏やかだけど言葉の節々から様々な経験を経ていることが感じられました。

また研修用のslackでは講師が常に研修でわからないところや実務での困りごとまで様々な質問に答えてくれてとても学びになりました。

学んだこと

事前課題としてスクラムガイド2020を読んでおくというのがあり、一通り目を通したし普段の実務でもある程度はやってるし、経験や手札の数はともかく知識面は大丈夫だろうと思っていたけど全然そんなことはなかったです

古い知識のままであったこと、知ってはいたけど背景を理解できていなかったこと、読んだはずなのに自分で勝手に補完して勘違いしていたことなどなどいろいろありました。
ちゃんと時間を取って人から聞くの大事。

2020からはゴール志向になったことをスクラムガイドから読み取れていなかったなというのが結構大きい学びです。

ワークショップはタイムボックスが厳格に適用されるのでタイムボックスを守ることの大切さを身を以て学ぶことができます。
あと練習は大事というのも自分にとっては大きな学びでした。

所管

教えてもらえばもらうほどワークショップで経験すればするほどスクラムマスターやばいな…という気持ちでした。
自分ができるだけでなくそれを周囲にいい感じに適用させていくことの難しさに加えて自身も日々学びながら変わっていくことの大変さよ…。

研修したらいろいろ勉強できたり身についている状態になっているといいなと思っていたけど、学んだことの数倍さらに学ぶことが見えてきて山の高さに絶望しているみたいな…。

ただそうなるくらい学べたということで本当に有意義な研修でありました。

認定試験

研修最終日の夜に受けました。

他の方の研修の記事とか読むと受けられるタイミングが何日か遅れるみたいなのを多く見かけましたが、自分が今回受けた研修では研修終わりの頃にはメールが届きすぐに受けられる状態になっていました

ちゃんと準備してから受けようか迷ったものの、どうせ2回までは受けられるしテストもよくわからないままやっても仕方ないなと思いさっさと受けました

一応、手元にスクラムガイドとアジャイルソフトウェア開発宣言を準備して臨みました。

いくつか不安な問題はあったものの基本的には苦労せず答えられたと思います。

無事合格できました。

前述の通り、これ取ったからと言ってなにか大きく変わったとは思えない（むしろ絶望が増した）けどひとつの学びの証という意味ではちゃんと取れてよかったです。

これで「研修とかを受けてない」という自分自身の言い訳もひとつ消したわけだし、改めて日々頑張っていこうと思いました。

2021ふりかえり

仕事納めました@29日

今年は2度目の異動を経ての今の部署となりましたが、現在のところ次の異動はなさそうです。

今年頭に「お前のフロントエンド力が必要だ*1」と言われて異動してきて、前半はガッツリとNext.jsでのフロントエンド開発に携わっておりました。

TypeScript,Next.jsといったデファクトスタンダードとなりつつある環境での開発はめちゃくちゃ体験がよかった。
また、自分を引き抜いてくれためっちゃできる上長とガッツリ組んで開発したことでこれまで自分が点で理解してきた知識が実践を経て繋がる経験を出来たのはとてもよかった。

しかし後半に入ってその上長がさらなる上の組織に引き抜かれてしまう。
まぁめっちゃ優秀だったし仕方ないよね…と思いつつ、既存のサイトの保守やってたチームと合流してこちらも同じくアテにされていたチームビルディングとかをやっていく。

ちょくちょくブログに書いていたけどなかなか苦労しつつという感じだった上に上長が抜けたこと*2で技術的に難し目（特にフロントエンド）のタスクが自分に集中するようになってしまった。
それで根を詰めることになったせいか、仕事終わるとヘロヘロになるような状態になってしまったのがここ最近。

ふりかえりとかにパワーを割けなくなってしまったがそれをカバーすることも出来ず（それもまた問題だけど）というのが現状でなかなかしんどい状態。

冬休みで体調整えて巻き返したい。

今年後半通じて少なくとも自分の開発力やフロントエンド側の知識は自分の関係するところで相対的に見て低くはないらしいということがわかった。
もちろん自信持って高いとか言える人はそういないとは思いつつも必要以上に卑屈になってはいけない位置ということは理解した。

ただ、かといって自分が重たいものばかり投げ込まれると普通にしんどいしチーム全体としての限界がここになってしまうので対策しないといけない。

「目の前の成果」を重視した結果だと思うので今のままでいいのかを改めて問うて全体としてのレベルアップを目指す。
一部、自分は困ってないから、自分はできているから（関係ない）というメンバーからも知識を引き出していけるようにする。これは直近の課題。

あとは自分がこれらの熱量を維持できる状態を作らないといけない。
体力とかもっとなんとかしないといけないかも。

技術側に寄せればいいと思うかもだけど、上記と矛盾するかもだけど自分が技術全振りではやっていくのは無理だと思ってるので上手くバランス取ってやるしかない。

2022年、しんどくなりそうだけどがんばっていく。

*1:超意訳

*2:代わりに来た新しい上長はガッツリマネジメント寄りの人

コードレビューをボトルネック化させないタスクの進め方

普段開発を行っているときコードレビューをすると思います。

しかしコードレビューの指摘と修正が繰り返されいつまで経ってもマージできないということが往々にして発生します。
レビューに何を求めるかはチームや組織によってまちまちですが、少なくともレビューの遅延が原因でマージやリリースが遅れるような状況は健全ではありません。

自分が入ったチームで行って効果的だったのは、実際に手を動かす前にタスクを全員で見る時間を作ることです。
もう少し具体的には開発の方針を決めてしまうことです。設計と言ってもいいかもしれません。

チームで開発をしていると言ってる割にこれをやっていないチームは意外と多い印象です。
各エンジニアがそれぞれ領域を持っているけどレビューはやらないといけないのでレビューだけ他のエンジニアにしてもらう…とか。

設計をどのくらいまでやるかはチーム内のレベル感に寄ると思います。
新しく入った人がいたりルーキーみたいな人がいるときはスケルトン作るくらいまでやってもいいかもしれません。

というかレビューが爆発してるパターンのときは大抵の場合、よくわからないけどそれらしいものを作ってレビューに出してそこで初めて設計レベルの指摘をされてほぼ全作り直し…というようなパターンが多いので、チーム内でその領域に詳しい人と一緒に全部作るくらいのことを最初はやってもらうくらいでもいいと思っています。

年数とか関係なくその部分のことをがわからないならわかるようにして、全員の前提知識を増やしてあげることが大切です。

スクラムフェス三河2021

参加してました。体調がアレだったので流しながら見てたりしてたので特に自分の中に残った部分だけ。

www.scrumfestmikawa.org

POはチームに口出ししてはいけないというやつを体感した話

今のチームでスクラムを始める時、多少時間はかかってもプランニングはやりきりましょうということをメンバーに対して話していて、合意も得ていた。

しかしPO（=事業部長）が無駄なMTGやってませんかと言ったことで一部のメンバーが過敏に反応して時間内に収めることを優先しようという動きを始めてしまった。

既存の考え方はなかなか変わらない。
MTG時間=無駄な時間という一般的に正しいと強く信仰されている言葉と、事業部長という立ち位置の人の発言というのがかなり大きかったのだと思う。

一応、この状態でもうまくいくならいいかと見守っていたものの、やはりプランニングが形骸化し始めている*1軌道修正をはかりたいところ。

POに対して「開発チームのプロセスに口出ししてはならない」というのが言われていますが、こういうことだったんだなーと初めて理解できました。
ある意味経験を得られてよかった（笑）

*1:各タスクやる人が見積もりしてねとか

なぜプロジェクトは予定通りに終われたのか

2月から関わっていたプロジェクトが無事に終了した。

タイトルでは予定通りと言っているが、実際には自社開発サービスのリプレースなので何かあったらリリース延期とかは出来る状態。
とはいえ、当初目標と定めていた6月末リリースを無事に終えられたので予定通りと言ってもいいと思う。

開発体制

• エンジニア2人とデザイナー1人の3人チーム
  • デザイナーもReact、TypeScript結構書ける
  • エンジニアはcss書けない
• RailsアプリからフロントエンドをNext.jsにリプレース
  • TypeScriptとGraphQL
  • NxとRelay（この記事では触れない）

目標を達成できたのはなぜか？

小さいチーム

• 人数が少なかったので意志決定と情報の共有のコストが少なかった

メンバー全員ある程度のスキルが揃っていた

• 全員がReact,TypeScriptおよび周辺の開発知識は一通りあった
• ただ、cssはデザイナーしか書けなかったためそこが少しネックになった
  • その時間を使ってエンジニアはリファクタリングやCI整備を進められた

フィードバックループ

• 毎日夕会を行いその日に起こった困りごとはその日に潰せていた
• 自分以外の2人は毎日出社していたため密なコミュニケーションを取っていた模様（自分は週1出社）*1

フェーズごとの設計

• 段階的にリリースを行うことになっていたため、フェーズごとにおおまかな設計を行った
  • 一つ前の開発で問題だったことをフィードバックして予め設計時に決めるなどの改善も行った
• ここで決めたことと今動いてるシステムを迷いなく作業ができる
  • 自分だけリモートでコミュニケーションが少なくなっても進められる状態だった

社内システムである

• 既存システムがあるのでそれを見ればよかった
• 再現が厳しいものはビジネス側と交渉して落とし所を探ることが出来る
  • 社内だからというだけでなくお互いの要求を並べて尊重できる組織文化があったこと

個人の感想

ある程度スキルと経験の揃った人がきちんと予定通りに終わらせるためにどうすればいいか考えて動いた結果、というのが正直なところ。

あとは社内システムなので融通を効かせられるのも大きい。
実際に納期延ばしてとかこれやめにしてとかは言ってないけどいざとなったら相談できるのと、無理な仕様が来ても難しいと言える関係は安心感がある。

自分としては「React,TypeScript,Next.jsわかるよね？」ということで招聘されたので無事に役目を果たせてホッとしているところ。

*1:今は出社は任意だが2人は家の事情等で出社を選択していたらしい

スクラムのMTG時間を削れと言われた

1週間のスプリントで毎週1時間ずつレトロスペクティブとプランニングをやっている。

スクラム1ヶ月ほどやってみてメンバーはそこそこいい感じの手応えを感じていたっぽいところ、上司からこの取組についてフィードバックがあり「メンバーのやりやすいようにやってくれて構わない」と言ってくれつつも遠回しにMTGを削って効率化しろという指摘をされた。

自分としてはまたいつものかと思いつつも「予定としてのMTG時間だけ削ってもその分だけ見えないところに分散するだけですよ」みたいなことを言って一応この時間の確保は続けさせてもらうよう話をしていた。

しかしその週のレトロスペクティブで時間を減らそうという話が出てしまった。
その週、レビューが爆発してリリース出来ないタスクが発生していて今後どうするという話をしていて当事者たちは「プランニングで厚目に見たい」という意見だったが他の人は「時間が増えてしまうので関係者だけでやればいいのでは」という意見だった。
まるで自分たちは関係者じゃないみたいな物言いでショックだった。同じチームなのに。

それとMTG時間を減らすことが目的になっていたのと、何よりそうなった原因が上司からの命令だったというのが情けない。
始めるときに1時間って長いって言われがちだけど〜みたいな話をして納得してもらったはずなのになー。まぁ1ヶ月経てば忘れるか。。。

ちなみに、自分は毎回1時間全部使い切れとは思ってない。
早く終われて作業にかかれるならそれに越したことはない。
ただ、現実問題が起こっている状況でコミュニケーションを削るのはありえないというのが自分の考え。

試してみればよかったのだろうか。

MTG30分削れば儲かるのか？を率直に聞いてみればよかったのだろうか。

ここまで書いてみて、実はMTG時間短縮云々じゃなくてメンバーに対して疑念が出来てしまったところがしんどいのかなと思った。

ここまでやってきたときに協力的っぽい感じがしたのは自分に関係があるところだったからなのか、目に見えやすかったからなのか等々考え始めてしまってしんどい。

混乱期に突入したのかなと思えばまぁ前進してる感じはするのでいいけど、このままだと形骸化して崩壊しそうなのでなにか手を考える。
すぐに悪くなるものへの対策はしやすいけど長期間に渡って効いてくるものは納得してもらうのがなかなか難しいね。

とりあえずモヤモヤを溜め込んでしまったのでここで吐き出しておく。