天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

「スクラムマスターぶっちゃけトーク会 について聞いちゃうぞ」に参加してきた

distributed-agile-team.connpass.com

今週も分散アジャイルチームの会に参加してきたので、会の様子と感想を書いていこうと思います。

会の発端となったイベントのアーカイブ

www.youtube.com

会で印象的だったこと

以降では、上記Youtubeアーカイブを「ぶっちゃけ会」という名前で記載していきます。

ぶっちゃけ会のその後

ぶっちゃけ会としてしまうと、失言をさせようみたいなフォースが参加者で働きがちになってしまうので、「ぶっちゃけ」というのをタイトルにするのはやめようとなったそうですw

そのため、この会は最後のぶっちゃけがつくタイトルのイベントになってしまったようです。

受注前のスケジュール作り

受注前にスケジュールを作る際、まずは経験があってできるチームに見積してもらう(&スケジュールを作ってもらう)という話をぶっちゃけ会でされていたのですが、そこで話していた見積の実態についてぶっちゃけてくれました。

受注前に行う概算見積と実際の見積結果にどれくらいずれがあるのか、という部分をメインにお話してくれたのですが、新さんのチームでは大体1.5倍くらい(当初の見積もり±50%くらい)のずれに収まることが多いということでした。*1

受注前の見積では、エンジニアが見積しやすい単位でざっくりとPBLを洗い出したりTシャツ見積レベルで概算見積をして、後は着手してスプリントを実際に回す中でベロシティベースで見積をする戦略をとっているということですが、「開発前にもっとやるべきことがあったよね」という話になることがぶっちゃけ多いそうで、DAなどを参考にスプリント開始前に方向づけフェーズを設けるなどと言った工夫をされているということです。

スプリントゴール

ぶっちゃけ会ではスプリントゴールの設定が難しいという話が挙がっていましたが、この背景やより詳しい状況説明についてぶっちゃけてくれました。

発注側の顧客がPOになっていることが多いことや既存システムのリプレイスを担当する*2ことが多いという状況もあって、「ある程度固定化されたPBLを上から順にこなして欲しい」という話がPOからくる状況にぶっちゃけなりがちで、それ故にぶっちゃけ会で話していたような「GitのIssue(PBL) Aを終わらせる」といったゴールが生まれてしまうということでした。

スプリントの単位が一週間では短すぎる*3のではないか?という話がきょんさんからは出ていて、フラクタルスプリントはまさにスプリントの単位がビジネスが求めている単位と合っていない問題に対応した結果だということです。

PBLが全然変わらない状況はスクラムに向いていないという言説

既存システムのリプレイスなど、最初にある程度FIXされたPBLを上から順にやる状況に陥ったとして、それを理由にスクラムが向いていない状況だと話す人を見ることがあるけど、それはだいぶ曲解していないか?というお話をきょんさんがしてくれました。

スクラムをやっていないチームがいざスクラムをしようとなった際に、普段からスクラムで開発していないチームは全然うまくできないし、開発をしている以上様々な予期せぬ問題*4が出てくるので、スクラムのメリットは少なからず享受できるのではないか?そう考えると「最初にある程度FIXされたPBLを上から順にやる状況はスクラムに向いていない」という言説は曲解ではないか?というお話を聞いていきました。

スクラムをやめるタイミング

ぶっちゃけ会では、「スクラムが形骸化したらスクラムをやめるタイミング」という話を新さんはされていましたが、これは「スクラムをやめてもどうせ上手くいかないでしょ」という想いが根底にはあったということをぶっちゃけてくれました。

新さんとしては、形骸化しているタイミングは改善のチャンスだと捉えているということで、形骸化したときこそチームやプロダクトに向き合うようにしているということです。

お客さん選び

どういうお客さんと仕事したいか?というのを新さんはまだ言語化できていないという話を新さんがぶっちゃけてくれました。

全然変わる気もないし自分達に丸投げしてくるお客さんと、変わりたいんだけど自分達の力が足りずに変化が起きていないお客さんは一見すると同じに見えてしまうのが判断を難しくさせているということです。

スタートアップの変遷

キラキラした夢を持ったスタートアップが、徐々に平凡な企業になったりキャッシュを増やすための受託開発をしがちになってしまうという話をしていきました。

togetter.com

新さんの会社は勤続年数が長い優秀なエンジニアも多く、新さん自身も満足いくチャレンジができている一方で、「この会社に来て既に5年経っているけど、自分自身が歳を食ってチャレンジをやめていないか?」「自分自身が心から満足できるチャレンジをしているから今の環境を選んでいるのか?」というのを新さんは自問自答されているということです。

新さんの会社を転職していく方々も、スタートアップに転職するパターンが多いそうで、「もっとヒリヒリした環境で働きたい」というメッセージを言い残すという話もぶっちゃけてくださいました。

全体を通した感想

新さん節の熱い話が久しぶりに沢山聞けて、とっても楽しかったです。
常に自分自身に疑問を投げかけながら向き合い続ける新さんの姿は刺激的でしたし、チャレンジし続ける姿勢は素直に尊敬の念しかありませんでした。

また、生々しさがすごかったので記事での具体的な記載は省いちゃいましたが、後半にきょんさんが、具体的にこういう状況だったらどういう提案をどういう手順でするのか?というお話をしてくれたのもめちゃくちゃ勉強になりました。

*1:勿論、最初にした見積が当たることはない(=そもそもスコープが全然変わってくる)のは前提

*2:リニューアル前の機能は全て現状の踏襲を求められる

*3:ビジネス的に求めている機能の単位が1週間スプリントという単位と合っていない

*4:使用しているフレームワークのアップデートなど