ソートリーダー
ソフトウェアエンジニアリングにおける生産性の神話
2つの10年間で、生産性の概念はソフトウェアエンジニアリングのあらゆる分野で進化し、拡大してきましたが、多くの場合、混乱したり矛盾した結果をもたらしてきました。私はこの分野での初期の頃、より多くの労働時間、より多くのコードライン、より多くの「活動」が自動的により良い結果をもたらすと思っていました。しかし、開発者からチームリーダー、エンジニアリングマネージャーへと昇進するにつれて、生産性に対する私の見方は、達成しようとしている目標に反する結果をもたらすことが多かったです。コードの品質が低下するだけでなく、開発者の幸福にも深刻な影響を及ぼしました。
この記事では、私が直面した誤解と、テクノロジー業界で生産性を取り巻く最も広範な神話を明らかにします。個人的な話、実践的なチーム経験、研究に基づく観察から、真正の生産性は、激しい、残業に燃えたスプリントよりも、ターゲットに焦点を当て、健康的な作業ルーチン、バランスのとれた組織文化に関係していることを主張します。私たちは、これらの幻想と戦うことで、ソフトウェアプロジェクトの管理と、それを作成する人々に対処する方法について、新しい考え方を始めることができることを希望しています。
残業の幻想
私が最初に知った生産性の幻想の1つは、長時間労働が必ずしもより良い結果をもたらすということです。仕事の初期の頃、私はある組織の支払いシステムの大規模なアップグレードを担当しましたが、時間が非常に限られていました。締め切りに対して圧力をかけられた私は、チームに夜遅くまで、そして週末まで約2ヶ月間残業するよう説得しました。
しかし、約6ヶ月後、問題が明らかになりました。チームの疲労した夜間コーディングセッションで導入された可能性のある微妙なバグが、プロダクションで表面化し始めました。これらの問題を修正するには、追加の時間とリソースが必要でしたが、顧客の信頼も損なわれました。さらに悪いことに、このヒーロー的な残業プッシュは、チームの2人の重要なメンバーがストレスと職務不満を理由に辞めたため、可能でした。すると、締め切りに応じた短期的な成功は、長期的なコストを払うことになったことが明らかになりました。したがって、時間が生産性を保証するという神話は、災難的でした。
質の時間よりも数量の時間
現代のソフトウェアエンジニアリングで必要な、創造性と問題解決力という2つの重要なスキルは、疲労によって大幅に制限されます。RescueTimeやTogglなどの時間追跡ツールを使用して、チームの作業パターンを研究してきましたが、興味深い結果が得られました。私たちの最高のコードは、開発者が定期的に4〜5時間の集中力を享受できるときに生成されます。個人が10時間または12時間の労働日に入ると、エラーレートは souvent に増加し、再作業にはさらに多くの時間がかかることがあります。より慎重なスケジュールを採用することで、バグの減少、チームの満足度の向上、そして最終的に、より予測可能な納期を実現しました。
フォーカスの誤り
別の根付いた神話は、開発者が毎分「プラグイン」してタイプしている限り、生産的であるとみなされるべきであるというものです。この誤解は、企業が厳格なアクティビティモニタリングシステムを実装することにつながり、キーストロークや画面時間にこだわることがあります。私は、会社が「オンライン」である最大の時間をコミットメントの印として奨励する文化を促進するのを見てきました。この認識は、計画、議論、研究、概念設計などのソフトウェア開発の不可欠な無形活動を完全に見落としています。
キーボードの外でのブレークスルー
これを最も印象的に示したのは、先年でした。私のチームは、トリッキーなマイクロサービスアーキテクチャの問題と戦っていました。2週間、コードを書き出して、複雑なサービスネットワークをデバッグしようとしました。最後に、より非公式な会話のために休憩スペースに退きました。コーヒーを飲みながら、白板に解決策を書き出しました。その解決策は、苦労していた複雑さの多くを切り捨て、よりシンプルなものでした。その30分の会話は、きっと何ヶ月にもわたる痛みを伴うリファクタリングを救ってくれました。効果的な問題解決は、IDEの範囲を超えて頻繁に発生することを思い出させるものでした。
生産性メトリクスの再考
「労働時間」や「活動」が欠陥のあるメトリックである場合、代わりに何を追跡するべきでしょうか。ソフトウェアエンジニアリングにおける従来の生産性の尺度は、通常、表面的な出力を重視しています。コードライン、コミット数、チケットのクローズ数などです。これらはある程度の洞察を提供できますが、誤用されやすいです。開発者は、より少ない論理的な変更をコミットしたり、より冗長な方法で行うことを選択したりして、コードラインの尺度を操作することができます。一般に、これらの尺度は、メンテナンスの問題を最小限に抑えることに貢献していないため、開発の進捗を追跡するのに適していません。
より包括的なアプローチ
数年間、私のチームと私は、努力が実際的な成果に繋がることを保証するために、意味のある出力の尺度を見つけることを試みてきました。
- 新機能の市場投入時間
実際のユーザーにとって価値のある機能をどれくらいの速さで提供できるか。これは、コードの変更よりも、機能が実際に有用であるかどうかを考慮するため、スループットを測るためのより信頼性の高い方法です。 - プロダクションインシデントの数
低インシデント率は、コードの品質が高い、テストが徹底的であり、健全なアーキテクチャ上の決定が下されたことを示唆します。頻繁なプロダクションインシデントは、開発における隠れた負債やコーナーカットを示唆します。 - コードの保守性スコア
SonarQubeなどの自動化ツールを使用して、重複、複雑さ、潜在的な脆弱性を検出します。スコアが時間の経過とともに安定したり改善したりする場合、長期的な品質を尊重する文化があることを示します。 - チームの知識共有
個人の出力のみに焦点を当てるのではなく、知識がどれくらい流れているかを確認しています。ペアがタスクに取り組み、徹底的なコードレビューを実施し、主要なアーキテクチャ上の決定を文書化していますか。情報に基づいたチームは、より集団的に問題に対処できます。 - 顧客満足度評価
最終的に、ソフトウェアはユーザーにとって存在します。肯定的なフィードバック、サポートチケットの低いボリューム、強力なユーザー採用率は、真正の生産性の優れた指標となる可能性があります。
これらのより広範な尺度に焦点を当てることで、私たちはコードを書き方についてのより良い決定を促進するだけでなく、優先順位をユーザーのニーズと保守可能なソリューションに合わせることを保証します。
戦略的な怠慢の力
私は、偉大な開発者は1日あたり何千行ものコードを書く人であると思っていました。時間の経過とともに、実際にはその逆であることがわかりました。実際、最高のエンジニアは「戦略的な怠慢」を実践します。複雑な解決策に飛び込むのではなく、より優雅な代替解決策を見つける時間を取ります。その解決策は、コードが少なく、依存関係が少なく、将来のメンテナンスが少ないものです。
私は、あるプロジェクトで、ジュニア開発者が3日間、約500行のコードを書いてデータ処理スクリプトを作成したことを思い出します。コードは冗長で、不要な部分がありましたが、動作しました。後日、リード開発者は、よりシンプルで、クリーンで、パフォーマンスも優れていた、50行の解決策を提示しました。
真正の生産性のためのツールとテクニック
真正の生産性の環境、つまり「忙しい仕事」ではなく、右のツールと右の組織的思考が必要です。数年間、さまざまなフレームワークを実験してきましたが、数多くの信頼性の高い戦略を見つけました:
- 修正ポモドーロテクニック
伝統的なポモドーロの25分のセグメントは、深いプログラミングタスクに短すぎることがあります。私のチームは、45分の集中ブロックに続いて15分の休憩を使用します。このリズムは、継続的な注意と必要な休憩時間のバランスをとります。 - カンバン/スクラムハイブリッド
私たちは、カンバンの視覚的なワークフローと、スクラムのイテレーティブサイクルを組み合わせます。TrelloやJiraなどのツールを使用して、WIPアイテムを制限し、タスクをスプリントにスケジュールします。これにより、コンテキストスイッチのオーバーロードを防ぎ、タスクを完了する前に新しいタスクを開始しないようにします。 - 時間追跡と成果分析
TogglやRescueTimeなどのツールで時間をログすることで、開発者の自然な生産的な時間帯に関する洞察が得られます。開発者ごとに、最も生産的な時間帯に重要なタスクをスケジュールし、9時から17時のスロットに制限されないようにします。 - コードレビューとペアプログラミング
コラボレーションの文化は、隠者のような行動よりも優れた成果をもたらします。コードレビューを頻繁に実施し、時々ペアを組み、問題を早期に発見し、知識を広め、コードベースの整合性を維持します。 - 継続的インテグレーションとテスト
自動テストと継続的インテグレーションパイプラインは、プロジェクトを混乱させる可能性のある、急いで作成されたチェックインを防ぎます。適切に構成されたテストは、早期に回帰をフラグし、思慮深い、漸進的な変更を促進します。
健全なエンジニアリング文化の構築
もしかしたら、最も有害な神話は、ストレスとプレッシャーが自動的に高いパフォーマンスをもたらすというものです。いくつかのリーダーは、開発者が厳しい締め切りに対して、常にスプリントし、高いステークスのリリースに対して努力することで、優れた結果を出すことができると主張しています。私の経験では、締め切りに対して一時的な努力がもたらされるかもしれませんが、慢性的なストレスは最終的にミス、バーンアウト、モラル問題につながり、プロジェクトをさらに遅らせることになります。
心理的安全性と持続可能な期待
私は、心理的安全性が確保され、開発者が懸念を表明し、別の解決策を選択し、早期にミスを報告することを快適に感じる環境で、より良い結果を達成しています。定期的な回顧を実施することで、このような文化を促進します。指をさすのではなく、プロセスを改善する方法を探ります。さらに、労働時間、休暇について現実的な期待を設定し、チームメンバーが休暩や休暇をとることを許可します。逆に思えるかもしれませんが、十分に休んだチームと評価されたチームは、常にプレッシャーのかかるチームよりも、一貫して高品質のコードを書きます。
ミーティングのない日と集中ブロック
私の前のチームで機能したのは、「ミーティングのない水曜日」の導入でした。開発者は、1日中、コードを書いたり、研究したり、テストしたりすることができました。ミーティングによる中断はありませんでした。水曜日の生産性は高まり、チーム全員がその静かな時間ブロックを愛していました。必要なミーティングを他の日にスケジュールし、短く切り、長い議論に陥らないようにしました。
実際のケーススタディからの教訓
より広いテクノロジー業界には、バランスのとれた、品質重視のモデルを採用することで、より優れた製品につながる例が数多くあります。Basecamp（旧37signals）などの企業は、カームで集中した作業の概念について公に話しています。労働時間を制限し、残業を奨励しないことで、BasecampやHEYのような一貫した安定した製品をリリースしています。逆に、高圧的なスタートアップは、バグが多い機能を急いでリリースし、開発者の善意を損ないます。
私は、チームがこれを真剣に受け止めたのを見ました。彼らはすべてのスケジュールを再構成し、時間制限を設けました。1クォーターで、開発者の満足度が飛躍的に上昇しました。しかし、より重要的是、サポートチケットの数が大幅に減少しました。
「生産性」の意味の再考
最終的に、私の経験は、ソフトウェアエンジニアリングにおける生産性を、エンドユーザーに持続可能な価値を提供し、開発チームの健康的な環境を維持することとして定義するようになりました。完全に埋め尽くされたスプリントバックログやコミットメッセージの長いリストに欺かれやすいですが、表面的なものを超えて、健全で保守可能なコードには、精神の明晰さ、協力的なコラボレーション、思慮深い計画が必要です。
バランスの取れた方程式
持続可能な成功の公式は、明確な目標、適切なツール、開発者の幸福とエンドユーザーのニーズを考慮したサポート的な文化のバランスをとります。これを3つの指針で表すことができます:
- 効果的な作業よりも延長作業: 実際に何が達成されるかが重要であり、チームが画面の前で座っている時間ではないです。
- 価値指向メトリクス: 結果、たとえば保守性、欠陥レート、またはユーザーサチスファクションに関するメトリクスを追跡します。
- 文化的継続的改善: 真の生産性は、作業の流れ、チームのコラボレーション、コードの書き方における漸進的な改善から来ます。回顧、柔軟なスケジューリング、知識の共有が、持続可能なペースを可能にします。
結論
ソフトウェアエンジニアリングにおける真正の生産性は、1日に多くの時間を詰め込むことや、数百行のコードを書くことではありません。むしろ、ユーザーにとって実際的な価値のある、堅牢でテスト済みのソリューションを構築することを意味します。これは、残業が成功をもたらすという神話や、休憩なしに常にコードを書くことが最高の名誉であるという考えを疑う時です。私たちの分野における生産性の見方を再定義する時です。
個人的な旅は、私に「労働時間」や「チケットのクローズ」などの尺度は、欺かされやすいものであることを教えてくれました。実際の生産性は、チームが活気づいており、責任あるコードを書き、機能が実際のユーザーのニーズと一致していることから来ます。そのためには、包括的なアプローチが必要です。思慮深いスケジューリング、意味のあるメトリクス、戦略的な怠慢、そして、明晰さ、コラボレーション、創造性を尊重する強力なエンジニアリング文化が必要です。新しい方法を調査し、時代遅れの仮定を捨てることを続ける限り、生産性が優れたソフトウェアのみならず、より良いテクノロジー業界を構築できるでしょう。
