アジャイルはアジリティを上げる物ですよという話に近いですが、 チームの文化が変化している事に最近気がついたので棚卸ししておきます。
以前は全ての手戻りをさけていた
手戻りを皆ざっくりと「作ったものが無駄ややりなおしになる事」をとらえていました。
そして、これを避けるために
- 本当にそれが「今後長期間」つかえるのか見きわめられるまで着手しない
- 事前の計画を綿密にやってから着手するつもりで、計画する事に多くの時間をつかう
という行動をとってしまうケースがありました。
なぜそのような状況がうまれたのか
そのような状況につながっていたのはいくつかの複合的な要素が関係していたように思います
- プログラムが改修に多くの時間がかかるような状態になってしまっていたこと
- 事業として時間や工数が不足していたこと
- ビジネスサイドとしての「作ったのに無駄になってごめん」という気持ち
- 開発サイドの「前につくった機能、無駄になったんですね」という空気
真に避けるべき手もどり
しかし、最近は本当に避けるべき手もどりはたとえば以下のような種類のものだと区別して意識するようになりました
- コミュニケーションのミスによってWhyやWhatが誤ってつたわっていた
- Howの正常系の部分しか考慮していないまま勢いでつくった設計
なぜ、このような手もどりは避けるべきかというと、それは「ユーザーへの提供価値に対する学習につながらない」からだと考えています。
もちろん、上記のようなミスを通して、上記のようなミスを発生させないコミュニケーションのあり方であったり設計の時の意識の習慣などの社内としての学習はつながるとおもいます。
しかし、そのような学習は本質的に「学習して減らしていくべき」事で理想的には無くなるべきものです。
避けるべきではない手もどり
逆に「避けよう」とするべきではない「手もどり」は
事業や試験実装の学習をプロダクトに反映するために過去の機能やコードを捨てる事
です
なぜ避けるべきではないか
上記を「避けよう」とすると事業やチームの文化などに様々な面で悪影響につながります:
- 検証をして事業の確度をあげる事よりも、最初から失敗がないように妄想で計画をねる事に執着し、停滞してしまう
- 不確実性の中で判断した内容に皆で挑戦する文化よりも、後知恵で冷笑的である文化が育ってしまう
- 試験実装すればすぐにわかる事の議論に時間をつかってしまう
- 「コードの状態が悪い」という本質的な課題に蓋をしてしまう
どうするべきか
上記のような手もどりを「避けない」ためには、「避ける」必要が発生してしまう状況を構造的、文化・心情的に遠ざける必要があります。
そのために実際のプロセスや日々のコミュニケーション、文化など様々な面で注意をする必要があります:
構造的
- WhyやWhatをきちんとローコンテキストで言語化、文書化する
- プログラムのアジリティをあげる
- 捨てやすい設計 (Easier To Change)
- 変更しやすい設計 (コナーセンスを適切に管理する)
- テストをきちんと充実させておく
- プロトタイプやインタビューなどで検証できるものは検証する
- 本質的な課題にコミットする
- コードの状態がわるい、事業の根幹が成果につながっていないといった、本質的な課題に向きあわずに小手先のテクニックで「ごまかそう」としていると、使える時間や工数がより逼迫し状況がより悪化するだけです
文化・心情的
- 決定の背後にある判断の説明を日々かかさない
- 選んだ理由、選ばなかった理由を明確にする
- 日頃から重視する価値や観点を皆で共有する
- 「学習による手もどり」はチームとして「歓迎する」文化をつくる
- 「結局使われなくなるのであれば、作らなかったのに」という反応ではなく「知見が増えてよかった」という価値観をつくる
- 日々の作業にたいしてきちんと報いる
- がんばったのに「ありがとう」も言われていない作業が結果捨てられる体験を生まない
