スクラムガイドの「勇気」ってなんや？
どうも。鳩胸になりたい文鳥です。
最近スクラムガイドを読み直したのですがハッとすることがありましたので記事書いておくことにしました。
かなり前にスクラムガイドを読んだ時に「正しいことをする勇気」って言葉があるのは知ってたんですが、最初読んだ時は「仕事なんやから正しいことやるのは当たり前やん？なんでそんなんわざわざ書いてんねん」くらいに思ってたんですが読み返して色々考えてみると、これがとても沁みたという話です。
↓ダラダラ書いてるけどあんまり内容はないです。時間ない人はまとめだけ読んでください。
AIと開発
開発していると、AIのおかげで開発がスムーズになったことを実感します。実装に悩むことや実現方法を形が見えると「これ！イケるで」みたいになりがちだと思います。
サクサク進むのですが、どんどん開発を進めているうちに、「あれ？これって本当に正しい方向なのかな？」って後から不安が湧いてくることあるんですよね。ありますよね？おれだけ？
ある程度開発が進んだ段階で「あれ、これもしかして間違ってる？」みたいな感じになった時、どうするかって話を知人としたときに
「遅いとか早いとかよりも、正しいことをやるのが一番大事」って言われまして、このシチュエーションってスクラムの勇気のことなのでは、となりました。
動くものができた！と、ついつい安心しがちな私ですが冷静に考えると、「一見それっぽく動くこと」と「使用通り動くこと」と「使用通り動いてそれが課題解決として正しいこと」は別物。
実装が早くなるということは1スプリントの成果物が大きくなるということであり、間違ったままゴリゴリ進んでいくと、本来立ち止まって問い直すべきタイミングがどんどん後ろにずれ込んでいっちゃうリスクもあると思っています。
また、それっぽく動くが故に問題に気づきにくいっていう側面もあると思います。
AIのおかげで開発スピードは上がってるんだけど、その分、本当に価値があるものを生み出せているのかっていう「価値検証」が追いついてないこともあるかもしれない。結果として、「正しく動くけど、実は間違ったもの」を作ってしまうリスクもある訳か。とか思うようになってきました。
スクラムのプロセスで「正しいこと」を見極める対策
スクラムの中でできる具体的な策をいくつか考えてみました。
-
スプリント前の「ディスカバリー」を強化する
スプリントを始める前に、「何を作るのか」「なぜ作るのか」を徹底的に話し合い、本当に価値のあるものなのかを深く掘り下げて確認する時間をしっかりとって目的意識を一致させることが大事かなと思います。ここで「これで合ってる？」っていう違和感を潰せるだけ潰しておくことは不可欠だと思います。のちの工程が早く進む分ここのベクトルの向きを正確にゴールに向けることは最近の開発ではとてもコスパのいい行動なのではと思いました。 -
スプリントレビューで「価値」を問い直す習慣をつける
完成したインクリメントをただ見せるだけでなく、実際に触ってもらうことが大事だと思います。「これって本当にユーザーにとって価値があるんやっけ？」「当初の目的に対してどうだった？」と、チームやステークホルダーと一緒に価値そのものを問い直す時間を持つのが大事かなと思います。テクニック的には細かいバリデーションや仕様を実装仕切る前に、動くものを早く見せてコンセプトレベルのズレがあれば早い段階で失敗させることが成功につながるのかなとかも思います。 -
レトロスペクティブで「違和感」を共有しやすい雰囲気を作る
チームメンバーが「これ、ちょっと違うんじゃないかな」と感じた時に、気兼ねなく言える場を作ることが「課題解決として正しいもの」を作るのに必要なのかもしれません。 -
AIの提案も「ユーザー視点」で厳しくチェックする
AIはあくまでツール。最終的な判断は私たち人間が行うべきです。AIはなぜ作るのかのコンテキストは持っていません。 -
エンジニアも事業戦略を深く理解する
以前にも書いた『エンジニアが事業戦略を知っている必要がある』というブログ記事で触れたように、AIがコーディングを高速化する現代において、エンジニアは単に言われたものを作るだけでなく、事業全体の目標や顧客のニーズを深く理解することが不可欠です。事業戦略が浸透しているエンジニアは、目の前のタスクが本当に価値あるものなのかを判断し、技術的負債を生みにくい設計をしたり、より良い代替案を提案したりする「勇気」を持つことができる気はします。作業を始めてからでないと気づけない問題を拾うタイミングとしては開発者の違和感が最速のタイミングということになると思います。https://qiita.com/morry_48/items/274bdc42ac2e94f8ecdc -
期待値コントロール
ソフトウェア開発って、家を建てたりする建設業みたいに、最初に全部決めてから工程を進めるものとはちょっと違うと思ってるのですが、それは「作りながら、本当に良いものを探していく」という性質があるということになるとおもっています。
だから、動くプロトタイプが初めてできた時点では「ようやく課題が見えてきたり、もっと良いソリューションがひらめいたりするスタート地点」だったりする世界線になってきていると思います。動くものがあると、「もうリリース間近だ！」って思われがちで自分もそう思ってしまうのですが、開発に関わる人たちがそこは冷静に「抽象度の高い案件はシステムが動いてから品質を高めていくフェーズ時間がかかるという共通認識を持つことが大事かなと思います。リリース後に改善できる場合もありますが、本番運用しながらの修正には一定コストがかかるので、ここでの気づきが実は一番コスパよく価値を高められるのではと思っています。このタイミングでリリースを急いで妥協したものを出すのは富士山に登って景色を見ずに降りてくるようなもの
この「作りながら決めていく」というプロセスへの理解があると、途中で仕様が変わったり、開発が少し遅れたりしても、それが「柔軟な対応」や結果的にそれが顧客に対して最も求めているものを最速で出す方法という意識を持つことができる気はします。
以前に『Cursorが市場を席巻している理由をちょっと考えてみる』というブログ記事でも触れたように、その一方で、人間同士の情報のやり取りや、異なるコンテキストを持つ部門間での意思決定のコストが相対的に上がり、これが新たなボトルネックになりつつあります。
コンテキストが遠ければ遠いほど予定変更に対する説明のコストなども上がるので、期待値をうまく調整しながら同じ方向に向かう仲間としての意識を醸成することが大事とも思います。
心理的安全性と「勇気」
ここまで考えてみると、「正しいことを言う勇気」って、一人で抱えたりするものではなくて、チームの中で「これってさすがに変じゃない？」とか「もっと良い方法があるんやない？」って、みんなが普通に安心して言える環境があってこそ、自然と生まれてくるものだと思います。
勇気を持つことも大事やし、他の人に勇気を持たせることも大事というか。
心理的安全性があるからこそ、「普通にプロジェクトの途中で間違ってることはよくある」と思えるし「正しいこと」を追求できる。スクラムで「勇気」がコアバリューの一つに挙げられているのは、そういうことやったんかなってなりました。
まとめ
①動くものへの安心感が、思考を止める
②チーム・関係者も「もう形になってるからOKっぽい」と油断しやすい
③異変に気づいた時にはフェーズが後半になっていて納期意識が先行しやすくなる
的なみたいなものに対して
「本当にこの機能でユーザーは満足するのか？」という問いを、開発が進んだ後でも持ち続けられること自体が、プロダクトに対する真摯な姿勢＝矜持の表れという風に考えて良いかなと思います。
ただ実際の開発の現場では色々なものを背負っているが故に
- 設計が進みすぎていて「今さら変えられない…」と感じたり
- 周囲も「もう手遅れ」と思っていて、疑問を口に出す空気じゃなかったり
- 自分一人だけが違和感を抱えているようで不安になったり
そんな現場の「静かな圧力」の中で、その圧力を認知する余裕もなく、その時感じた違和感は心の中にそっとしまい込んでたことが過去にはあったなぁと思います。
本来アジャイル（スクラム）は途中で気づいたことを活かすためのフレームワークです。
たとえスプリントの途中でも、ユーザーの本当のニーズに気づいたなら、それを反映させるためにプロダクトバックログを見直すことは大歓迎なはずです。
「計画を壊す声」ではなく「価値を高める声」である可能性も大いにあります。
早く気づけば早く気づくほど正解にたどり着くのは早いし、「失敗」の傷も浅くなります。
こんなことを考えているとスクラムガイドが5つの価値基準をのうちの一つに
スクラムチームのメンバーは、正しいことをする勇気や困難な問題に取り組む勇気を持つ。
を掲げている理由も納得できる気がしてきました。
これらの価値基準がスクラムチームや⼀緒に働く⼈たちによって具現化されるとき、経験主義のスクラムの
三本柱「透明性」「検査」「適応」に息が吹き込まれ、信頼が構築される。
この一文も最初には読み飛ばしてしまっていましたが、ちゃんと考えると身に沁みてきます。
最後に
みなさんはスクラムの価値基準「勇気」をどのように解釈していますか？
以上。