2023年のふりかえり
2023年のふりかえりをしてみる。
掲げていたこと
2022年は自分の中で上手くいったと思えることが少なく、特にアジャイル関連においては今まで自分が培ってきたものがほとんど通用しないことがあった。
それを踏まえて、自分の中でアジャイルのプラクティスを自分の言葉に落とし込んで、他のメンバーに説明できるようにしたいと思っていた。
簡単に総括すると、一定は上手くいったと思えた。
以前のチームへ出戻り
2022年4月にプロジェクトの新規立ち上げに関わって9ヶ月。今年の1月からは別のチームへ異動した。
2022年からのチーム異動の動きを簡単に整理すると、以下のとおり。
- 2022年1月〜3月 ：Aチーム
- 2022年4月〜12月：Bチーム(新規PJ)
- 2023年1月〜3月 ：Aチーム
- 2023年4月〜 ：Cチーム(新規チーム) ※後述
Aチームに出戻った形となった。
元々別のチームに行こうと思ったけど、諸事情によってこうなった。
結果的には出戻ったことは良い経験になった。
今の自分と出戻ったチームでDiffを取れた
各プロジェクトチームでは、四半期ごとにリリースしたいユーザーストーリーの見積もりをして、過去のベロシティなどを参考にして、ざっくりバーンダウンチャートを引いてリリース計画を立てている。
私がAチームに出戻った時には、すでに初期のリリース計画は済んでいた。
その状態で、出戻って最初のプランニングに参加したとき、「今週は5ポイントの消化予定で考えているので、これらのストーリーをToDoに乗せます」という会話があり、そこに対して違和感を持った。
ToDoに乗せていたストーリーは、合計で5ポイントという量ではあるが、不確実性が高いものがほぼ無かったので、個人的には3日後には余裕で終わりそうな感覚だった。
それを伝えた時に、「でも計画では5ポイント予測なので…」という会話になり、そこで自分とチームのDiffが取れた気がした。
私も1年前だったら、同じことをやっていたと思う。
リリース計画時に引いたバーンダウンチャートによれば、今イテレーションは予測消化が5ポイントだから、優先度高い順に5ポイント分のユーザーストーリーをToDoに乗せて、はい終わり！ 解散！ みたいな
それは新規PJをやっていたBチームだと全く通用しなかったことを覚えている。
新規PJ、新規チームだったので、各イテレーションでどのくらい消化できるかは全く想像ができなかった。
なので基本的にはコミットメントベースな計画づくりだった。各イテレーションに何を終わらせなければいけないかというイテレーションのゴールを決め、それを満たす為のユーザーストーリーをToDoに乗せて動く。
なんとなく上の方にあったから、このストーリーをやってます、なんて言うと「計画に意思が籠もってない」とよく突っ込まれた。
そういったDiffを今までいたチームと取る事が出来て、より良い計画づくりはどうしたら良いのかと考えを深めるきっかけになった。
一応書いておくと、出戻った時のAチームがよくないプランニングをしていたわけではない（もちろんのびしろはあった）。
しかも上記で書いた違いがその場でパッと言語化できたわけでもない。
ここで言いたかったのは、何かしらの強い違和感を覚えた事が、自分にとって深堀りをするきっかけになった。
なので、環境を変える（しかも出戻りする）事は自分の成長の差分を知れるのと、それを深めることに良い影響を与えたと思っている。
※なお、出戻ったAチームに対して、今までのチームでやっていたことを取り入れようとして、ちょっとチームメンバーから怖がられてしまった為、もっと段階的に取り入れるとか、やりようは考えないといけないなと思った
新規チームの立ち上げ
4月からは私自身がチーム（以下、Cチーム）を立ち上げた。
私自身が一緒に働きたいと思うメンバーを業務委託面談で集め、アジャイルに関して知見がまだ少ないメンバーたちを成長させながらチームを作っていく試みだった。
プロジェクトの内容としては、いま既存である機能の多言語対応だったので、基盤さえ作ってしまえば後は横展開でいけそうなものだと思っていた。
結果として、当初予定よりはスコープも削り、さらにスケジュールも伸ばしてしまうなど、プロジェクトとしてはあまり良くなかったが、いくつか学びは得られた。
よりよいペアプロを伝えるのは難しい
スキル差のあるペアプロは難しい。
自分の知っていることを教えても、自分の伝えていることは単なる情報でしかなく、知識に結びつけられるかどうかは、また別の話になる。
結局その人自身の経験値によってしまうから。
人に教えることについて悩んでいた時に、「私たちはどう学んでいるのか」という本は参考になった。
基本方針としては本人にドライバーを握ってもらうことが大事である。
ではどうやってドライバーをもっと取ってもらうかを促すところには、以下の記事が参考になった。
参考にして、色々試行錯誤してみた結果は、スライドにまとめてみた。
状況が変わることでプラクティスが発揮されない課題
半年ほどやってみた結果、チームメンバーはペアプロやTDD、計画づくりといったアジャイルのプラクティスをある程度実践ができるようになってきた。
それでも状況が変わるとそれが上手く発揮できない、という経験もした。
10月になったら別のプロジェクトをやることになったのと、2名の新しいメンバーを迎えた。
新しいメンバーへアジャイルのことを伝えるのと、別のプロジェクトということで技術的に調査が必要だったということ。
状況が変わること、特に技術的にわからないことが多くてどう進めば良いのか、という状況が続くと、意識的にやっていたアジャイルのプラクティスがおざなりになる瞬間が度々あった（テストファーストになってない、ドライバーナビゲーターがちゃんと交代できてないなど）
意識的にはできるが、別の大きな課題があったときにそれが意識の外に追いやられる感じだと思う。
無意識にやれるようにするには、それこそ常に練習して、ふりかえりをしつづけることが大事だと思う。
アジャイルを体得するのに数年単位で掛かると話を聞くが、それはどんな状況下でも意思的・あるいは無意識的にアジャイルなプラクティスが実践できるか、ということなんだと、今は思う。
今後
ふつうのことをふつうに出来るチームを作っていきたい。
私たちはどう学んでいるのかを読んで、ペアプロにどう取り入れるのかメモ
新しいメンバーに対してペアプロ・モブプロを行っている。
メンバーが一人で自走ができるように、より良いやり方・考え方は無いかどうかを模索している中で、「私たちはどう学んでいるのか」という本を読んで、いくつか参考にできそうだったので、書いておく。
※まだ試してないので、あくまで机上の空論、アイデア状態
この本を読んで面白いと感じたところのメモ
※あくまでメモなので要約ではなく、個人の感想
知識は伝えられない
一番最初に度肝を抜かされたと思ったのが、知識は伝えることはできなくて、構築されるものというところだった。
私たちが伝えられるのはあくまで「情報」であり、その情報を元に個人の経験と組み合わせて知識を構築していくしかできないといった趣旨のことが書いてある。
有用な知識とは
この本では、有用な知識について、一般性・関係性・場面応答性の3つの性質があると書いている。
特に面白かったのは場面応答性で、ざっくり理解で書くと「必要なときに必要な知識が使える」こと。
たとえば、設計だと高凝集・低結合が良しとされているという知識を覚えていたとしても、普段コードを書くときにそれが実践できていなかったり、ただ一度きりしか使わないようなスクリプトで頑張って実践する*1といった事かなと思っている。
認知的リソースと状況のリソースの組み合わせ＝知識の創発
有用な知識には、場面応答性という性質があるとすると、その知識が使える場面の情報もセットになってしまうし、それを覚えておくことは不可能
知識をモノとして扱うものじゃなくて、個人が持っている情報や記憶という認知的リソースと、周りの環境という状況のリソースの組み合わせによって、ある目的に沿った知識を創発するという考え方＝コト的知識観
状況のリソースっていうのは、自分の周りのリソース。
たとえば、
- 自分が使っているPC、モニター、キーボード、ツール
- IDEに出てくるエラーメッセージ、警告
- 自動テストの成功・失敗の結果
- 周りのチームメンバー
本を読んで思ったこと
今まで自分はペアプロ中に一生懸命相手に、自分の知っている知識を伝えているつもりだったが、それらは単なる情報。相手にとっては知識の素材（リソース）を提供しているだけに過ぎないなと思った。
自分が100言っていることは30しか伝わらないみたいなことを社会人になってから、よく言われていたし、自分の体感でもあったけど、この本を読んで腑に落ちた。
近接項と点を打つ
6章の中で、近接項と遠隔項の話が出てくる。
自分なりにざっくりまとめると、
- 近接項
- 自分自身が体感できる情報
- コードを書いてエラーが出た、運用などの作業手順書を読んだ内容、他人から聞いた言葉など
- 自分自身が体感できる情報
- 遠隔項
- 近接項が生み出される原因
- エラーの原因、作業手順書の各手順の背景、他人が発言した意図など*2
- 近接項が生み出される原因
人は近接項から、脳内に内部モデルを作り出し、それが遠隔項に繋げることができると理解が進むという話。
（脳内の）内部モデル --- 近接項 --- 遠隔項
みたいな形。
よく現場では理解を進めるために「点を打つ」という言葉を使っていたり聞いたりするが、自分が考えていたのはこの近接項を増やすことに終始していたなと思う。
ペアプロ・モブプロをやっていると、いろんな情報が飛び交う。自分の知っていること・知らないこと、それらの近接項を処理するだけで手一杯になっていく。
ペアプロ中に使えそうなアイデア
主に新しく入ってきたメンバー相手（先生・生徒の関係性になってしまいがちなペアの組み方）*3
リッチな経験値を積む
知識は、その人の五感で得た認知的リソースと状況のリソースから創発される。
そう考えた時に、認知的リソースを増やす取り組みをする。
ペアプロであれば、ドライバーがメインになると思う。
キーボードを叩く（触覚）、コードを見る（視覚）、ナビゲーターの話を聞く・自分の実況を聞く（聴覚）
五感を駆使してペアプロができるようにして、いろんな視点から情報を得て身体化を促していく。*4
ナビゲーターであっても、いまのコードの状況を見る、相手との会話から状況を知る、相手の声音、表情から相手の状況を知る（楽勝な雰囲気なのか、それともわからなすぎてパニック状態なのか、疲れているのか）、自分たちがやりたいことを頑張って言語化していく。
たぶんナビゲーターは、状況リソースを的確に判断するための訓練になりそうだなと思った。
自分が意識できそうなものリスト
パートナーを状況のリソースと考えたときに、パートナーの状況への理解度を深め、いま必要な自分の認知的リソース（相手にとっての情報）を、どう伝えるか作戦を立てるかが肝要だと思う。
- ただやることを伝える、にしない
- 相手の状況に応じて、アクセル踏むときとブレーキを踏むときを使い分ける
- 相手の状況を言葉にする
- 相手が沈黙している時など、「黙ってるけど何か悩んでる？」などの問いかけて、こっちから見えている相手の状況を伝える。そこから、相手の状況・思っていることを引き出す。
- 状況のリソースを把握する
- 相手が沈黙している時など、「黙ってるけど何か悩んでる？」などの問いかけて、こっちから見えている相手の状況を伝える。そこから、相手の状況・思っていることを引き出す。
- 「わからない」の解像度を上げる
- パートナーがどう進めていいかわからない、となったときに、「やりたいことがわからないのか」「やりたいことはあるけど、コードの書き方がわからないのあｋ」「これからやろうとしている意図がわからないのか」などの分解をしていく
- ナビゲートする時は思考の流れを伝えるように
- ◯◯をやりたいから、このコードを書いて下さい
- ナビゲートの伝え方は、抽象度高めから伝え、手が止まるようなら抽象度を下げていく
- xxxClassを書いて、次にxxxメソッドを書いて〜という詳細をナビゲートするのは、最後。
- 沈黙が続くのであれば、沈黙が続く人にドライバーになってもらう
- 自然と言葉と手が動かす状況に持っていく
2022年をふりかえって
はじめに
普段は1週間とか3ヶ月単位ではふりかえっているけど、年単位でふりかえることをしていなかったなと重い、2022年、自分自身がやったことのふりかえってみる。
2022年はどんな年だったか
一言で言うと、自分が今まで積み重ねたものが通用しなかった年だった。
3月からプロジェクトを新規立ち上げするチームのメンバーとなった。この時に多くの経験をさせて貰った。
フロントはWeb Componentsに挑戦したり、バックエンドは今まで触ったことのないRustで書いたり。CI/CD周りも一から作ることが多かった。
チーム・アジャイルな動きに関しては計画の立て方が今までのような1イテ◯ポイントといったキャパシティベースの立て方じゃなくて、どのイテレーションまでに何を作らないといけなくて、それに向かってチームがどう成長させるかどうかを考えるといった、綿密な計画を引くという違いがあった
詳細については以下のスライドにまとめてLTで登壇した。
新規立ち上げは自分にとっては難しかった
いろんな経験が積めた一方で、苦い経験も多かった。
既存プロジェクトとどうしても違うところとして、意思決定の回数がとても多いと感じた。
新しく作るのでアーキテクチャもゼロから作る。言語・FWも自分たちで決める。必要なストーリーを出して、開発側のストーリーも含めて、どういう優先順位でやるか。細かいところだとチームの稼働時間や朝会、定例をどうするかなど、大小決めることが絶え間なくやってくる感じだった。
そうなると人間どうしても疲弊するので、細かい部分になると「こうでいいんじゃないか」みたいな発言をしてしまうのだが、それに対してチームメンバーからは「なんで？」と頻繁に問われる。「なんとなく・前のチームがこうだったから」みたいな理由を話すと「考えることを自ら放棄している」とフィードバックを受ける。
あらためてふりかえってみると、そのとおりだなとは思っていて、過去のチームの成功体験をそのまま持ってこようとしていても、いまのチームに必ずフィットするわけではない。だからこそ、テーラリングをするなど、考えることが必要だった。
2021年4月に、いまの会社に転職してきて自分が過去経験したアジャイル（スクラムでの開発）との違いにいい意味でギャップを感じた部分はあったが、今回はそれ以上だったと思う。
それこそ今まで培っていたものを見つめ直さないといけないと思うくらいには。
今後
2022年は自分の中で上手く動けずに悔しいなーって思うことが多かった。
特にアジャイルにおいては知識・経験は積めてきていると思ったので、このプラクティスをやる意義や他のプラクティスとの関連性の深堀りはまだまだ足りないと感じたので、新しく入ってきたメンバーにも自分なりの言葉で説明できるようになっていきたい。
技術的なところでは、何か得意な言語をちゃんと1個確立させたいと思う。
今まではPython、Kotlin、Rust触ってきたけど、この中だとKotlinが書き味が好きだったのでもっとちゃんと極めたいというのがある。関数プログラミングも何か一つやりたいとは思う。
よく読んでた本
最後に、2022年読んでて面白かった本をいくつかピックアップしてみる（技術書はない）
エッセンシャル思考
無駄を省いて大事な物事に集中をする考え方を説いている。
ビジネス価値の高いストーリーを優先的に着手して、素早くフィードバックを得るアジャイルな考え方にも通じる部分がある。
エフォートレス思考
エッセンシャル思考の続編で、少ない労力でより大きな成果を得るかについて書かれている。
遅考術
しっかり、よく考えるというのはどういうことなのか、と悩んだ時に読んだ本
システム1、システム2の思考モードの違いを説明していて、システム2を引き出す為にいったん思い浮かんだ思考にストップを掛けて一旦否定するなどの考え方について書いてある。
ふりかえりカンファレンスに参加してふりかえりを体験してきた
はじめに
4/10(土)にこちらのカンファレンスに参加してきました。
どれも面白いセッションで、明日以降にいろいろ使えそうなエッセンスがありました。
各セッションごとのふりかえりがある
「ワークショップでふりかえりを体験できるカンファレンス」というコンセプトだったので、各セッションの終了後にmiroを使ってのふりかえりの時間が用意されていました。
参加者はただ聞いているだけではなくて、実際にセッションで学んだ手法を活用しながらふりかえるので、とても密度の濃いです（クロージングあたりでは、体力も精神力もへとへとだった）
今回の学び
皆さんチームや状況に応じて手法を変えたり、その手法自体もカスタマイズや自作したりする方が多かった印象です。
ふりかえりが上手くいかない、というのも色々あって、
- 情報の収集がうまくいかない（なかなか意見が出てこない）
- 収集した情報からトピック抽出がうまくいかない
- アクション決めが上手くいかない
- そもそもふりかりが正しくできているかわからない
など、いろんな観点から皆さんお話をされていて、自分も「あー、わかるなぁ」って思いながら聞いてました。
一部手法は、組み合わせられそうだなって印象も受けました。
印象に残ったやつ
ファシリテーターとして文化を変えるアクションアイテムとの向き合い方 by 田中 亮さん
ふりかえりをやっていると、冗談のようなトピック（給与が上がって欲しい、など）が上がってくるけど、そのふりかえりの中で解決するためのアクションアイテムを作ることができない。→なので無視されがちになって、もったいない。
なので、いきなり解決するようなアクションアイテムを作ろうとせずに、小さな一歩になるような「火種」のようなアクションを考えると良いよ、というお話をされていて、「なるほど！」と思いました。
私は、ふりかえりであるトピックに対してそれを解決できるようなアクションを考えなければならない、みたいな捉え方をしていましたが、
上記の話を聞いて、すべてを解決しなくても、まずは小さなものからアクションを考える。まずはそこから始めるでも良いんだな、と捉え直せたのが嬉しかったです。
いつものふりかえりに「気になること（concerned）」を追加してみませんか？ by 河野 圭一郎さん
KPTをやっていると、「そもそも良い悪いって何？」ってなったり、メンバーによってはあまり発言が出てこないことがあって、
そこに、「気になること、モヤモヤしていること」を追加することで、普段発言しないメンバーも発言するようになったり、問題点ほどじゃないけど気になっていることを共有しやすくなるっていうお話を聞いて、ぜひ取り入れてみたいなって思いました。
また、他の方のLTで「お気持ち」などの感情にフォーカスした内容を出すとやりやすいっていうのも、明日から試しやすくて良いなって思いました。
今後ふりかえりで試したいもの
- KPCT、YWKT
- Okimotchiなどの感情を収集するアクティビティ
- ふりふり
おわりに
改めてふりかえりは奥深いものだな、と思いました。
自分が知らなかった手法を沢山知れましたし、
チームの状況に合わせてカスタマイズしたりするのも有りなんだと気づきも得られました。
特に感情にフォーカスした「お気持ち」や「気になっていること・モヤモヤしていること」などは、個人的にすぐにでも取り入れたいくらい、めっちゃ良さそうって感触があります。
学びの多かった、ふりかえりカンファレンスですが、来年も開催する予定とのことなので、今からとても楽しみです。
素敵なカンファレンスを開いて下さった運営の皆様、ありがとうございました！
ADRを試してみる
本記事は、 DDD-Community-Jp Advent Calendar 2020の24日目です。
はじめに
モデリング会では二週間に1回というペースでやっているので、どうしても前回までにしていた設計の内容を思い出すことが大変です1
そういった課題があったときにADRというものを知り、これはモデリング会のみならず普段の業務でも使えそうだと思い、試すことにしました。
ADRというのは
Architecture Decision Records の略であり、その名のとおり、アーキテクチャの決定の記録です。
詳しい説明はこちらの記事が参考になります。
-
私たちの記憶力が乏しいだけなのかもしれませんが…↩
「1年間続いたオンライン勉強会」秘伝のタレを公開します
本記事は、 DDD-Community-Jp Advent Calendar 2020の20日目です。
■ はじめに
この記事について
この記事では、1年続いたオンラインモブ開発のフォーマットを紹介します。
このフォーマットを紹介しようとした経緯ですが、2020年最後のモデリング会で 1年間を振り返っている中で、『せっかくDDDCJというコミュニティ内でやっているのだから、もっと実践したいという人を受け入れられる形にしたい』といった意見が出てきたのが発端です。
それに対して、「もうちょっとこの会として何をやっているのか、という透明性を高めるために、会としてのアウトプットを増やした方が良さそう」だと判断しました。
たとえば、今後モデリング会に参加したいもしくは、モデリング会のように自分が得た知識を実践する会を開くときに、いま私たちのやり方をフォーマットにしておくことで、何らかのヒントになるのではないかと考えました。 そこで1年続いた（もしくは辞めなかった）モチベーションを書いておくことにしました。
ちなみに、1年間の試行錯誤のお話は以下をご参照ください。
※ なおこの記事もタイトルもモブで書きました！
続きを読む勉強会での経験から1日スプリントを業務に取り入れてみた話
本記事は、 DDD-Community-Jp Advent Calendar 2020の18日目です。
はじめに
今回は勉強会から業務へ派生した話を書こうと思います。
モデリング会では、隔週2〜3時間モブでモデリングやコーディングをしていきますが、 その中で議論が白熱して空中戦になってくると「あれ、今日は何をしたんだっけ」となりやすいところが問題でした。
最近では30分のタイムボックスを意識し、そこでドライバーを交代したり、そこで一旦ふりかえってみて、軌道修正をするタイミングを作るようにしています。
モデリング会の進め方については、こちらの記事をご参照ください。
この勉強会でのタイムボックスを意識したことを社内で話したときに、リーダーが関心を示して下さり、程なくして「1週間から1日スプリントにしてみませんか」といった話になりました。
そのとき、どんな課題があって導入してみたか。
その結果どうなったのか、といった話を書いてみます。
続きを読む