どうも。鳩胸になりたい文鳥です。
アジャイル開発について考えてみた。
誤解されている部分や時代の変遷とともに合わなくなってきている部分があるなと感じます。
手段の目的化もあるなぁと思ったりします。
大学院でソフトウェア開発の歴史、プロジェクト推進やスクラムについて学ぶ機会があったので絡めて残しておきます。
とにかく「無駄を省くこと」
これに尽きる。
言葉のイメージから、
「たくさん機能が作れるんでしょ？」とか
「開発が早くなるんでしょ」
みたいなイメージが持たれることがあります。
はっきり言ってそんなことはない。
私の頭にあるイメージを書き記す。
このブログにまとまりはない。
速攻戦術が流行っている。
戦術が将棋のように高度化した現代サッカーで一番トレンドとも言える速攻戦略。
自陣から相手のスペースを見つけて一気に雪崩れ込み比較的少人数で、そのまま直線的にゴールに襲いかかる。
少し古いがベルギーVS日本のワールドカップをイメージする人も多い。
実に直線的で美しい。
世界最高峰の舞台でこんな直線的な攻撃がなぜ成立するのかというと相手をつり出していたり、実はかなり緻密な戦略があったりする。
こんなこと言うと元も子もないが選手の脚が早くないと成立しない。
単にスプリント能力だけではない。
90分走り続けられるだけの体力と全力疾走しながら瞬間瞬間で変わる状況変化に応じて、味方のスペースを潰さずに、自分の走り抜けるスペースを確保して、そのスピードでボールを正確に扱う技術が必要である。
まとめると
が必要である。
どれが欠けていても成功しない。
仮に
が試合したら現役選手が勝つのは言うまでもない。
戦術理解していても実行能力がなければ、速攻戦術を体現することはできない。
高校サッカーで優勝するチームが速攻戦術を取り入れた場合はそこそこ早いだろうし、おじさん草サッカーのレベルだと…
要は、戦術を100%理解したとてパフォーマンスレベルは個人のフィジカルに依存する部分が大きい。
シンプルを実現するには、高度な技術が必要だし、シンプルを実現できても個人個人が持つ最大速度を上回ることはない。
そんなもの
また、速攻戦術は素早いから速攻戦術なのであって、「遅い速攻戦術」みたいなものはない。
パスがズレると減速するし、敵が戻る前に攻め切るから早いのであって敵（障害）が多い状況では直線的に進むことはできない。
また、自分がボールロストの直接的な原因になりたくないと言う気持ちを選手が持ちすぎるとパス成功率の高い横パスを選択するようになる。
これはデータ上は直接的には失敗にカウントされないが、敵が陣形を整えてスペースを埋める時間を作ることになるので得点機会を損失している。
ボールポゼッションとパスの成功率を過剰に重要視してKPIを置いてしまうと横パスが増えて攻撃が停滞して相手にとって怖さがなくなる。（昔の日本代表みたいな）
プロダクト開発はサッカーではない。
ゴールの位置が変わることもあるし、ピッチの整備も自分たちでする必要がある。
しかしゴールあっての開発である。
ゴールのないプロダクト開発はプロダクト開発ではない。
しかし業務臭われすぎると目下のタスクにばかり目が入って、ゴールを見失うことはある。
新型コロナ感染対策として緊急事態宣言が発令され、多くの企業がオフィスへの出社を控えることに。請求書の受け取りや処理のために出社しなければならない経理担当者の声にも注目が集まっていました。当時はニーズ調査を始めるタイミングでしたが、緊急事態宣言をきっかけにその必要もないくらい課題が明確になったので、全員が「このコンセプトでいく、機を逃さなければ絶対に売れる」と合意しました。そして「ゴールデンウィーク明けには絶対にローンチする」と決め、開発を始めました。
この部分をみて、カウンターアタックっぽいなーと思った。
スペースを見つけた時に最大速度だすには勇気がめっちゃ大事。
アジャイルとは「素早い」「機敏な」「柔軟な」と言う形容詞である。
「アジャイルをやる」みたいな表現はおかしい。
「アジャイルである」
「アジャイルになる」
が正しい。
「アジャイルプラクティス（メソッド）をやる」は言える。
アジャイル、およびスクラム開発において正しく運用できているか？
は期待される速度素早さで変更要求に対応できているかどうかである。
うまくいってないアジャイルはアジャイルではない。
なぜならはやくないからである。
うまくいってないアジャイル開発はこの世には存在しない。
「アジャイル」かどうかの判断基準が内部にあるから。
スクラム開発を実施しているが素早くならない。
「やり方が間違ってる？」と会議体のDetailを変えてみたりSprintの長さを弄ってみたり、
してもうまく行かないし
ここで「念ずれば叶う」みたいにアジャイル本読み漁っても大体状況が好転することはない。
大体スクラムなんて軽量のフレームワークであって、突然技術力が上がったり、急に並列で走っている機能開発の完了が早くなるわけではない。
スタックしているバックログの進捗が突然よくなるようなものではない
速攻戦術をまねたからと言って突然走るスピードが早くないわけではない。
走るスピードそのものが上がるわけではないのと同じである。
ただ単に外部からの要求が高すぎるだけの可能性もある。
大体このような状態にある時、FW（戦術）の上位にいる戦略部分でうまくいってないことが多い。
戦略の欠陥を戦術で賄うことはできない。
どういう状態になったらゴールなのか定義できてる？
うまくいってる状態が何なのか定義できてる？
チーム内で認識は合ってる？ステークホルダーとの認識は合ってる？
「ゴールが不明瞭」はサッカーでは物理的なため起きないがプロダクト開発では起きてしまう。
チームの良い状態の解像度を高めてそれに近づく必要がある。
ゴールの向きが不明瞭なままで最短でゴールに行き着くことは不可能である。
情報の非対称性はコミュニケーションコストを生む。
バックログのアイテム以外にチーム内でやるべきタスクはないか？
運用タスク・非機能要件・バージョンアップ対応などを含めた時にチーム内でバックログのアイテムとトレードオフが測れているか？
よしイケるっていうアクセルを踏める状態になっていない、つまり上記のようなプロジェクトを複雑にさせる要因が存在する時「シンプルに素早く」は難しい。
もしバックログに積まれているタスクを全て期限内に終えた時にゴール達成と言えるか？
もしそうでないのであればチーム全体としての戦略レベルでの解像度が低いと言える。
アジャイルプラクティスがうまく行ってないのではない。戦略が上手く作れていない状態で戦術レベルの方法論で悩んでも仕方ない。答えはそこには無い。
戦略が決まっていない時に戦術レベルのフレームワークでは失敗を回避できない。
これはイケるで！的な雰囲気は前向きな勇気の根源となるのでバックログのメンテナンスはめっちゃ大事。
計画通り進行しないこと自体では成功・失敗を判断することはできない。
計画を変更した結果顧客のニーズに素早く対応できて価値を生み出しているのであれば
それは正しい適応である。
Cursorは毎週のように出るモデルに素早く対応することでプロダクト価値を生み出してる。
おそらくCursorの開発組織は計画通りにタスクを進行はできていないと思う。
スプリント終了 → レトロスペクティブ
の時に計画したタスクが期限内に完了したか？
もといベロシティは上がってるか？
を重視しすぎる文化には問題がある。
タスクが期限内に終わるかどうかは将来の予測の不確実性を下げる意味では有用だがそれ以上でもそれ以下でもない。
チームの状態がいいかどうかをタスクの消化量で測ることはできない。
結局掛けている人数に対して生み出したプロダクト価値で判断すべきである。
タスクに対するビジネスインパクトはタスクが完了して世に出したあとにしか分からない。
かける人数が少なくて計画通りにタスクが終わったとしても「思ったより使われなかった」が起きたら組織としてはうまく行ったプロジェクトとは言えない。
工数が少なくてビジネスインパクトが大きいタスクを本来最優先で消化すべきなのに、エンジニアの評価をタスク消化量でしてしまうと捩れが起きてしまう。
計画通り実行ことが目的化した結果
①詳細仕様書レベルの要求
②調査タスク
③設計タスク
が重たくなりタスクに関わる人間の頭数が増えすぎるのも問題である。
不確実性を下げて計画通り進む確率は上がっているし、タスクがいっぱい消化できるのでベロシティとしては上がってるが、人数 x 時間に対してプロダクトの価値向上が見合っていなければチームの状態がうまく言ってるとは言えない。
これはパス成功率を重視した結果、横パスばかりになってる状態に似ている。
物事を早く進めるにはプロジェクトに関与する人数は少ない必要がある。
人が多いと横パスが増える。
不確実なプロジェクトを進める上で自分自身で決断するという行為には大きな勇気が必要。
色々検討したくなる心をグッと堪えて市場のフィードバックを得ながら前に推進してくと問題がたくさん起きる。
これを許容できる文化が縦に推進するスピードを生む。
是非はあるが中国がソフトウェア開発において優位性があるのはミスを許容して「言われたら直す」で進んでいく文化があるからなのかなと思う。使われない機能のバグは直さない。
「いっぱい文句言われてるってことはユーザー使われてる注力すべき分野」みたいな前向きさがあるらしい。
これを車や医療でやると、人命に関わるのでそう言った分野では使えないが、ソフトウェアの領域では市場でテストしていきながら進む手法は長期スパンでみると結果的にユーザーへの価値提供できる総量は多くなるんだと思う。
何か物事を決める時に外部の承認が必要な時にシンプルを維持できているとは言えない。
勝負所でチームと自分を信じ抜いて全力疾走できない状態で即効戦術は成功しない。
あれ？これっていいんでしたっけ？は共通認識がずれていればずれているほど起きる。
横パスが多ければ多いほど停滞する。
ミッションの意図を浸透させて各個人が縦に勇気を持って推進できる組織設計・文化づくりが大切。
我々エンジニアは専門職である。
物事が早く進むかは個人のスキルに依存する部分が大きい。
ここの最大値以上の速度が出ることはない。
起きた問題を自分で解決できるメリットは大きい。
スキルを磨き続けなければならない。
時代が変われば、ツールも変わって開発を取り巻く変化は激しい。
2001年の開発ではDockerもなければActiveRecordもない。自動テストも浸透してなければGitもない時代。
いろんなボトルネックが取り除かれて日々高速化している。
そんな中で過去有用だった手法が今自分たちの組織をインプルーブする上で有用なのかは懐疑的に捉えつつ取り入れなければならない
Gitによって並列作業が可能になったりAIによって開発が高速化する。
5倍のスピードになったからと言って、事業に与える影響が5倍になったり、成果物を排出するスピードが5倍になるわけではない。
レビューがボトルネックになる。
タスクに着手する時点でペアでアサイン・レビュワーを決めておく。
タスクが消化が早くなると意思決定と承認がボトルネックになる。
人間の認知負荷が高くなってる。
環境が変わればプラクティスも変わる。
過去有用だったプラクティスがそのまま適用できるようなことが減ってる。
ボトルネックを特定し、ボトルネックを取り除くマインドセットとプロセスに価値がある。
自分たちの持つ最大速度を出す、つまりアジャイルになるためにはとにかくシンプルを保つこと
→まずこれがめちゃくちゃ難しいことであると認知する
みたいなことを考えた。
Be the first to comment
