フローを阻害する要因を解決し、不必要な認知的負荷の原因を取り除くことで、組織における文化的な問題を解消できるとNigel Kersten氏は論じた。コミュニケーションしやすい明確な戦略からスタートし、その後ストリーム・アラインド・チームとプラットフォーム・チームの創設に進むべきだ、と彼は提案した。
Nigel Kersten氏は、FlowCon France 2024で、ソフトウェア組織における高速フローの実現について講演した。
長い間DevOpsは、ソフトウェアを構築するチームとそのソフトウェアの保守や運用を担当するチームとの伝統的な関係を変えたい、より洗練された自動化を実装したい、という意図を明確化するために有効だったが、Kersten氏はもはやそれを信じていないと言う。
彼は「文化の醸成」や「DevOpsの促進」を第一目標に据えないようアドバイスした。その代わりに、ソフトウェアデリバリーに携わるチームの高速フローと低い認知負荷の向上に集中することだ。フローの阻害要因や不必要な認知負荷の原因を解決すれば、「文化的」な問題は消え始める、と彼は論じた。
デリバリーはますます予測可能になり、チーム間の摩擦は減少し、継続的改善の環境を作り出すための時間を生み出すことにつながる新しいスキル、プロセスの自動化、セルフサービスインターフェースの実装に投資するための時間が増えるでしょう。
コンテナ、VM、Infrastructure as Code、ソフトウェア定義ネットワーク、協調的バージョン管理、CI/CDなどの技術的な向上は、Kersten氏がソフトウェア組織において技術がいかに文化改革を推進できるかの中で説明したように、組織力学や不良製品デリバリーにまつわる文化的な問題の解決を可能にする。
初期のDevOpsムーブメントの主なドライバーの1つは、ソフトウェアを構築する人々とそれを本番稼動させる責任を負う人々との間の連携が欠如していたことで、そのため我々は皆、ソフトウェアデリバリーを改善するためにコラボレーションを強化する方法に多くの時間を費やした、とKersten氏は言う。これは素晴らしいことだったが、時が経つにつれてコラボレーションそのものが目標になり始めた、それはソフトウェア組織を運営する生産的な方法ではない、と彼は付け加えた。
Kersten氏は、チーム・トポロジーと、ここ数年で台頭してきたプラットフォーム・エンジニアリング、どちらもコラボレーティブな相互作用が普遍的に適切でないことを認識している、への注目の高まりについて言及した。
新製品の設計段階では開発とセキュリティのような機能間のコラボレーションは素晴らしいが、目標はX-as-a-serviceの相互作用に向かって進み、時間の経過とともにコラボレーションを最小限に抑えることであるべきです。
社内の開発者プラットフォームソリューションを探し回ったり、人々をストリーム・アラインド・チームに再編成したりする前に、明確に定義された簡単にコミニュケートする戦略があることを確認してください、とKersten氏は説明する。
第一にこれは組織構造やプラットフォーム・チームの採用より正しく行うことが重要であり、第二に正しいバリューストリームを定義し、プラットフォーム・チームを設置すべきかどうかを決定し、成功のためのハイレベル・ゴールを定義するために必要です。
Kersten氏は、『良い戦略、悪い戦略』という本と、戦略を定義するために使われるモデル：状況の診断、状況に対処するための指針となる方針、一連の具体的な行動、について言及した。行動計画のない戦略は単なるビジョンステートメントに過ぎない、と彼は言う。
戦略と行動が整っていれば、ストリーム・アラインド・チームやプラット・フォームチームを作る道筋はおのずと見えてくる、とKersten氏は結論づけた。彼は内部と外部の両方のフィードバック・ループを作成し、増幅することに焦点をあてることを提案した。
あなた自身に問いましょう。あなたの開発者は迅速に実験を行い、その実験を同僚やステークホルダーと簡単に共有できていますか？あなたのストリーム・アラインド・チームはプラットフォーム自体への今後の変更を認識していますか？あなたのプラット・フォームチームはストリーム・アラインド・チームをお客さまとして扱っていますか？彼らはロードマップを導くために、プロダクトディスカバリーやユーザーリサーチを行っていますか？
これらの質問に対する答が「いいえ」であるなら、高速フィードバック・ループとユーザー成果主導型文化の妨げとなっている障壁を取り除くことに集中せよ、とKersten氏は締めくくった。