なぜ開発速度は上がらないのか？ソフトウェアデリバリーを停滞させる真の犯人とは

ソフトウェアデリバリーの効率性を阻害する要因にはどのようなものがあるのでしょうか。一般的に、技術的負債、複雑すぎるアーキテクチャ、あるいは不十分な自動化が挙げられますが、本質的なボトルネックは、チーム間のサイロ化や過度なコンテキストスイッチ、そして「なぜこれを作るのか」という目的の不透明さにあることが多いです。効率的なデリバリーを実現するためには、プロセスの見直しだけでなく、心理的な安全性やデプロイを阻害するレガシーなルールを徹底的に排除することが不可欠です。

素晴らしい論文だね。ソフトウェア開発におけるQAの役割は過小評価されすぎてる。

現場で真逆の結果を見てきた身としては、ちょっと信じがたいな。QAを外すと、開発者が本番環境の品質を自律的に意識し始めるんだよ。QAがやってたことを開発者がやるせいで時間を浪費してる、と言う人もいるけど、自分にはそうは思えない。実際、自分が体験した2つのケースでは、どちらもインシデントが減って、そのまま安定したからね。

いい記事だった。QAのポジションが不可欠だってことは、痛い目を見て学んだよ。

「結合度が高まると、調整や整合性の確保、戦略の共有といった作業にかなりの時間が無駄になる。裏を返せば、あるコンポーネントが壊れたときに全員が影響を受けることで、またかなりの時間が失われることになる」

これって雑な文章、それとも英語力の問題？ ここで公開されるにあたって査読のハードルとかないの？ なんか他人のデータをまとめただけの低品質な4ページの調査資料って感じで、独自の経験則による裏付けも全くないし。ぶっちゃけ、これならブログで十分だったんじゃないかな。

ソフトウェア開発が遅延する最大の要因は、一度に抱え込みすぎることだと確信してる。チームとしては、一度に一つのプロジェクトに集中するべきだよ。

チームに別のプロジェクトやワークストリーム、新しいアイデア、調査案件を突っ込むのは、ほぼ百害あって一利なしだね。

• コンテキストスイッチが増えて、メンバーのストレスがすぐ溜まる
• バスの要因（誰かがいなくなると仕事が止まるリスク）が増す。1人しか担当してない案件だとその人が不在の瞬間に作業がストップするし
• 担当人数が減れば、結局は1人でできる作業量に引きずられる（並列化できる作業なら、2人いれば単純に2倍速いのに）
• 依存関係の解消が遅くなる。PRのレビューを通すような基本的なことさえ大仕事になってしまう
• 問題に触れる人数が減ることで、過去の経験を活かす機会も減り、結果として開発スピードが落ちる

他にも色々あるけど、どんなプロジェクトでも最大の並列処理を目指すべきだ。

うちはレビューの待ち時間が明らかにボトルネックだったから、（ほとんどのチケットで）ハンドオフを同期的にすることでそれを排除したよ。レビュー用カラムにチケットが入ったら、レビュー担当者とすぐに通話をつなぐんだ。レビューの待ち時間をなくすことによるメリットは、レビュー担当者のコンテキストスイッチによるコストを圧倒的に上回る。特にパッチが通話中に読み込める程度のサイズなら、その場で指摘して即座に修正のやり取りができるから、誰かを待たせる必要もなくなるしね。

「QAを責めるな…」

今って何年だっけ！？ まだQAを責めるなんて人いるの？ もしいるなら、カレンダーを見て21世紀にアップデートしてくれよ！