フィードバックをもらい続けるために！ / Scrum Masters Night! Online 〜第3夜〜に参加した

2020/08/07 に開催された【Dev向け特別セッション開催！】Scrum Masters Night! Online 〜第3夜〜に参加しました。日々スクラムと向き合い学んでいますが、いろんな方と話すといつでも新しい発見がありおもしろいなーっと思います。今回のScrum Masters Night! もそんな場でした。日常に少し変化をつけるという意味でも勉強会はとても良いきっかけになります。

smn.connpass.com

今回は特別セッション「スクラムを実践する上で "設計" をどのように考えるか」とOSTの2本立てでした。OSTはテーマが15個以上も出ていて盛り上がっていましたよ。今回も新しい発見があったのでさっそく現場で活用していきます。それでは、内容のまとめていきます。

今回の内容

「スクラムを実践する上で "設計" をどのように考えるか」
OST

「スクラムを実践する上で "設計" をどのように考えるか」

株式会社Odd-e Japan CTO 金井様

Developerの視点から考えるべきこともある
イテレーティブなマネージメントはイテレーティブなエンジニアスキルがないと痛みを伴う
BDUFのマインドセットを持っているとフィードバックの数が下がる
- BDUF(Big Design Up Front)：最初から大きな設計が効率的であるという考え方
- 大きな設計に慣れている人がスクラムを実践すると2、3スプリントでコードがつぎはぎ状態になり品質が落ちる
インクリメンタルな設計の発想を持ちましょう
- インクリメンタルな設計は「リファクタリング」
- 「リファクタリング」は危険でコストもかかるため、安全にできる環境が大切
  - TDD、XPとか

Q&A

・NoCodeな環境ではTDDなどが難しいですが、どう考えますか？
TDDも一つのプラクティス。実践して合わないと判断したのであれば、その現場では正解です。大切なのはスプリントごとにフィードバックがもらえるモノが作れていることです。

・プロダクトの特性上、手戻りコストが大きい場合のアプローチはありますか？
インクリメンタルな設計が向かない領域もあります。考え続けることが大事。今決めるべきことと後でもよいことがあると思います。

・イテレーティブなマネージメントとイテレーティブなエンジニアスキル。どちらから学びをスタートするのが良いと考えますか？
イテレーティブなスキルの習得は簡単ではないので、実験できる場で試す方がよいです。イテレーティブなエンジニアスキルは単独で学べるため始めやすいと思います。

まとめ

まず、思ったのがイテレーティブとインクリメンタルってなんだっけな？です。正直、この違いを分かっていなかったので調べました。以下のブログが分かりやすかったです。

どちらも少しずつ作るのですが、少しずつの作り方が違います。インクリメンタルは完成度の高い部品を繰り返しを作ります。例えば目を描いて、次に鼻を書いて・・・っと作っていきます。イテレーティブはラフ画を描いて、徐々に全体を仕上げていきます。インクリメンタルは完成するまで全体像が見えませんが、イテレーティブは早い段階で全体像が見えます。

今回の発表はイテレーティブなマネージメントにはイテレーティブなエンジニアスキルが必要だということです。納得ですね。例えば、スクラムを実践する場合はXPのプラクティスも一緒に採用しないと苦しい開発になってしまうよっていうお話です。平鍋さんも「ライトウィング」と「レフトウィング」という表現でマネージメントとテクニカルな2つの攻めが必要だと書かれています。

すでにレガシーなコードを抱えているプロダクトはTDDなんて夢のまた夢って思ってしまいますが、TDDが唯一の解ではないと思いますので、毎スプリントフィードバックを貰えるモノを安全に作り続けるにはどうすれば良いのかっと悩み続けたいですね。

今回、登場した言葉「インクリメンタルな設計」を始めて知ったのは牛尾さんのブログです。スクラムに興味を持っているとピープルマネージメントによりがちですが、それと同じぐらいエンジニアリングのテクニックも重要ですね(耳が痛い)。
simplearchitect.hatenablog.com

OST

ソフトウェアエンジニアからスクラムマスターに転身するときに気を付けることとかアドバイスとか

ソフトウェアエンジニアからスクラムマスターになったとき
- プロダクトへの貢献が直接的から間接的に変わる
- チームを見ることが増える
スクラムマスターをしてる自分は、コードを書いてる自分と違ってどういう価値を出せてるんだろうと悩む
スクラムマスターになったとき、意地でもプロダクトのコードは書かない
- チームに任せて成長を促す
今、SMに感じている価値を考える
開発メンバーやPOからフィードバックをもらって成長する
- フィードバックくれと言っても貰いにくい
- SMから開発チームに相談して、フィードバックもらえる。

スクラムがソフトウェアの分野から登場しているので、ソフトウェアエンジニアからスクラムマスターに興味を持つ人は多いと思います。私もそうです。

その場合の有利な点はソフトウェア開発が分かることだと思います。スクラムマスターの責任に開発チームの成長があります。ソフトウェアエンジニアの気持ちが分かったり、技術が分かる点でソフトウェアエンジニアからスクラムマスターになることはメリットだと思います。

しかし、同じくピープルマネジメントも大切になるので、そちらは改めて学びなおす必要がありますね。利点を活かしつつ、チームの能力を最大化する知識を学んでいくと信頼されるスクラムマスターになれるかなって思いました。

フィードバックを欲しがる人は活躍しているという話もありました。とても参考になりました。ネガティブフィードバックってお願いしても貰えないことも多いです。他人の行動を批判的に表現することは勇気とパワーが必要ですよね。そこで、相談形式で意見を引き出す方法は良いと思いました。「僕はここが出来てないと思うんだけどどうかな？」素直に分からないや困っていることを相談して、自身の足りないことを聞きたいと思います。