Scrum Developers Night! Online 〜2nd〜に参加した
tsumugでスクラムに取り組んでいて、他の組織がどういう取り組みをしているか気になったので勉強会に参加した。オンライン版は2回目の開催。
実は1回目にも参加したのだが、途中参加だったので進め方がよくわからなかった。今回はいろいろな人と話して、いくつか持っていた疑問を解消したり、自分の中で納得の出来る答えが得られるものがあった。
進め方は次のような感じ。
- 自己紹介
- テーマを出し合う
- チームに分かれてテーマをディスカッションする
私のいたチームでは、アジャイル開発の技術的なtipsをどう身につけているのか、Devチームのスキルが属人的な場合にスクラムを機能させられるのか、の2つ。
アジャイル開発の技術的なtipsをどう身に着けているのか
いくつかの会社の方とスクラムの取り組みについてディスカッションした。
スクラム自体はけっこう古いプロセスなので、10年〜15年くらい前に流行ったテスト駆動開発であるとかエクストリーム・プログラミングのエッセンスを取り込んでいる・取り込むと良い結果が出るようだった。次の書籍が紹介されていた。
- 作者:ＫｅｎｔＢｅｃｋ,ＣｙｎｔｈｉａＡｎｄｒｅｓ
- 発売日: 2017/07/14
- メディア: Kindle版
Clean Agile 基本に立ち戻れ (アスキードワンゴ)
- 作者:Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ,角 征典,角谷 信太郎
- 発売日: 2020/10/16
- メディア: Kindle版
例えば、チームにおけるストーリー達成のゴールとして、ユニットテストが存在する、コードベース全体が壊れていないことを確認するようにすると、リグレッションテストを通じてシステムが一定の品質に維持されやすい。
リモートワークでZoomやVSCodeを使用して、リモートモブワークやペアプログラミングを実施している組織もあった。環境に依存するけど興味深い取り組みだと思う。
アジャイルのプラクティスとして以下のページが紹介されていた。各線の色はSubway map to agile practiceにあり、DevOpsやXPの取り組みである、ということが書かれている。
こうした取り組みはリードエンジニアが引っ張っていく事が多いようで、自分で良いと思う取り組みを決め、チームに導入して、仕事を進めていけるエンジニアの価値は高いと感じた。
また、ガッツリとコンサルを入れて全社的にスクラムを導入している組織もあって、そこまでするものかと驚いた。経営陣の理解がないとこういうことは出来ない。
なぜスクラムは取り組めるのに、ペアプログラミングに取り組めないのか
スクラムそのものは導入できるのに、ペアプロやテストファーストなどの取り組みが出来ないのは何故だろう、という話題が出た。
私の考えとしては、スクラムは開発プロセスだが、ペアプログラミングはプラクティスという違いがあるというもので、参加メンバも同様に感じているようだった。
開発プロセスを支えるツールはたくさんあるものの、プラクティスを支えるツールは少なく、また、エンジニアのスキルや経験に依存するという点で、スクラムチームには優れたリードエンジニアが必要である。
最終的にはDevチームが自己組織化して、同じ価値観でプラクティスを実践できるようになると良いのだろう。
Devチームのスキルが属人的な場合にスクラムを機能させられるのか
私はいまハードウェアの開発をスクラムで進めようとしているが、属人的なスキルに偏りがちで、チームとして機能させるのが難しいと感じている。
例えば、電気のエンジニアが1名、FWのエンジニアが1名など、お互いにカバーできる領域がない場合、助けを求められても力になれることが少ないし、スクラムチームとしてうまく機能するとは言えない。
非常に専門性の高いスキルが求められ、かつ、チームメンバーが少ない場合には顕著になってしまう。これはチーム編成時にスキルマップを作ることで分かる。
スクラムとして機能する単位までチームを分解する（電気担当チーム、FW開発チームとか）必要がありそうだし、1つのチームですべてを実現するのであれDevチームに十分な人員が必要なのだろうと思う。
端的に、お金に制限があり、スクラムを機能させるために十分なチームを作れないこともある、という理解をした（悲しい現実…）。
ハードウェア開発固有の問題として、外部のブロッカーが多いことも上げられた。
例えば部品を発注してから届くまでに数週間かかったり、問い合わせに数日待ったり、こうしたケースに対応するためカンバンに 外部Waiting などのステータスを設ける対応をしている組織があった。これは取り入れたい。
ちなみに、ハードウェアスタートアップとして、SpaceXの開発スタイルはアジャイルらしくブログエントリが上がっている。
製造業アジャイルのコミュニティもあるそうなので今度参加してみる予定。
beyond-hardware-agile.connpass.com
その他
スクラムマスターの進め方にはそれぞれ個性があることを改めて実感した。セミナーを受けたときの講師はJoe Justiceで、ことあるたびに Relax, Happy, Fun! を繰り返しておりスクラム自体そういうものかと思っていたが、実はそうではないらしい。
エンジニアリングの経験有無でハンドリングの仕方も変わる。デイリースクラムで出たDevチームのタスクブロッカーについて、Devチーム内で解決出来るようにディスカッションを促すことが 一般的だが、スクラムマスターにエンジニアリングの経験があれば解決アプローチを指示したり、名指しでメンバーをアサインすることもある（私はときどきやります）。
ちなみに、世の中には成果の出ないDevチームを見捨てて、全員別のメンバーに置き換えて進めるドライなスクラムマスターも居るらしい。
まとめ
ハードウェア開発におけるスクラムのディスカッションにおいて、私のチームは（組織や人の良し悪しは別として）ヒューマンリソースが不十分であろう、ということを認識できたのは良かった。
直近改善はできないものの、今後もアレンジしながら取り組んでいきたい。なぜなら、ハードウェア開発で大きく失敗すると経済的な損失がとんでもないことになるので、スプリントで小さく取り組み、小さく失敗できる状態にするほうがいろいろな意味で健全だから。
興味本位で参加した勉強会だったが、今後の助けになりそうな知見が多く得られた。参加者の方々は前向きだし、様々な取り組みをしているのでアドバイスも参考になる。機会があったらまた参加しよううと思う。
