はじめに
- アジャイル関連で耳馴染みのないワードが多いのでそのざっくり整理をしようと思った
- もっとあると思ったけどあんまり多くなかった
- アジャイルというよりスクラム？
謎ワード一覧
- 自己組織化
- 心理的安全性
- フィーチャーチーム（職能横断的なチーム）
- CI/CD
自己組織化
もう少し詳しいことは過去まとめてるからこっちみてくれ。
もっと公式的な情報が見たいならこっち。（LeSS）
ざっくり言えば「ゴールに向かって必要なことを有機的に行える組織」（自己解釈的表現）
ポイントは以下だと思ってる。（いずれも自己解釈）
- 目標を理解しており、現在の手段が妥当であるかを評価でき、問題があれば手段を変えることができる。
- ゴールの状態を正しく把握している
- ゴールまでの進捗を自分で把握できている
- 現在の手段で進捗が芳しくない場合は、手段を変える能力と権限を持っている。
- 特定メンバーの不在などを理由に機能しなくなるということは無く、チーム内の相互作用によって目標達成に向けた行動を行うことができる。
- 特定のリーダーに引っ張られるような旧来の組織体制とは異なる。
- 全員がリーダーシップをはっきするようなイメージの組織体制。
- 特定メンバーの不在などがあれば、チーム内で会話して必要があればその穴を埋めるような動きができる。
心理的安全性
個人的にまとめた記事はすでに上げてるから割愛。
公式な記事が見たいならGoogle re:workを見よう。
ざっくり言えば「失敗を表明することへの不安の少なさ」。（自己解釈）
ポイントは以下だと思ってる。
- 自分の失敗を表明することができる。
- 自分の失敗を表明する必要性を理解しており、自身が被る被害が許容範囲内であると確信している状態。
- 部下→上司に対する心理的安全性がよく話題になるが、上司→部下も同様。
フィーチャーチーム（職能横断的なチーム）
公式な記事はこちら。
フィーチャーチーム以外のもクロスファンクショナルなチームとか呼ばれたり、職能横断的とか機能横断的とか言われたりする。
ざっくり言えば「システム開発（要件定義〜リリース）を単一のチームで実行できる状態」。
- デザイナーやアプリケーションエンジニア・インフラエンジニアなどを単一チームとして取り扱うことがよく例に上げられる。
- 要員リソースを効率的に使うための体制ではなく、あくまでプロダクトを早くリリースするためのチーム体制。
- 局面によっては不慣れなタスクを扱う場面もあり、作業効率という面では不都合が多い。
- インフラチーム/アプリチームなどに分けると、情報連携などのボトルネックなどが生まれ、プロダクトリリースに時間がかかるとされるため、こういったチーム体制が提案されている。
- 要はリリース速度の短期間化を目指すためのアプローチの一つ。
CI/CD
正直に言えばこれを見てくれという気分。
公式な話とかならここら辺かしら。
ざっくり言えば「システム開発を小分けにして、常にメインブランチにマージし続けることで、ビックバンマージを避け、手戻りを減らせ。」という話。（だいぶ飛躍してるけど）
ポイントは以下。
- システムは「小さく」変更すること
- 開発者へのフィードバックを「高頻度」にすること
- 間違ってはいけないものは「自動化」すること
まとめ
すげぇざっくり解説にしたけど、たまにはこういう記事が欲しい時もあるので、軽くまとめてみた。
次回予告
本記事は、2022アドベントカレンダー「受託アジャイル」の記事です！他にも興味あれば見てってください。
次回は、スクラムの進捗管理の考え方です。