はじめに
本記事はQmonus Value Streamの投稿キャンペーン記事です。
目次はこちら
理論編はこちら
この記事では、モダンな開発における指標について分析し、どうして指標をうまく扱うことができていないのかを分析します。また、指標の扱いを失敗することによる具体的な問題例を考えます。
いいね、ストックをよろしくお願いします！
現代の指標
モダンな開発現場の日常
以下の文章は、モダンな指標を利用した開発現場で日常的に起こっている出来事の一部です。
- あなたがプログラムを書いているとき、コンパイラは継続的にコードに型検査を行い、誤った箇所を赤く表示してくれます
- あなたがコードを書き終え、GitHubにコードをプッシュしました
- GitHub Actionsが実行され、リンターが実行され、単体テストが実行され、テストカバレッジが計測されます
- あなたは自分の書いた機能に満足し、今週の仕事を終えました
- さて、毎週日曜日の夜に定時実行されるワークフローは、今週の発見したバグの数を報告し、Slackに通知してくれました
- 月曜日の朝のミーティングでは、プロジェクトマネージャーがバグの密度が多いコードについて指摘しています
- ミーティングの結果、同僚のエンジニアがレビューすることで品質の低さの原因を発見し、信頼性を改善することになりました
指標
指標：ソフトウェアの品質について知るための手掛かり
ソフトウェア開発の現場では、実に様々な指標が使われています。例えば、単体テストの失敗はバグの存在を示す指標です。
さきほど紹介したモダンな開発現場で強調して示したものは全て指標です。
指標は、ソフトウェア開発プロジェクトに秩序をもたらし、開発生産性を上げ、快適なエンジニアリングを可能としてくれます。
みんな指標を分かっていない
これらの指標の概要と、いかにそれが有益であるか、どのような素晴らしいツールを使えばそれらの指標を使えるのかについての情報はすでにたくさんあります。
しかしながら、これらの指標について、なぜ有用なのかについての情報はほとんどありません。具体的には、以下のような知識が不足しているのです。
- 指標がどうして有効なのか
- 指標はいつ有効ではなくなるのか
- 新しい指標に出会ったときに有用性を判断するにはどうしたらいいのか
- 現場で指標を最大限活用できる条件はなにか
- 誤った指標の使われ方とはなにか
- 指標の使われ方の正しさを判定する条件はなにか
つまり、指標を開発環境に導入する背景にある揺るぎない基礎と理論については、あまり語られてきませんでした。多くのエンジニアは、経験的になんとなく良さげな指標を、なんとなく良さげなタイミングで測定しているにすぎないのです。
理解せずに指標を使わないと危険
指標には、固有の特性と扱い方があります。適切に理解せずに指標を活用すると、かえって開発者体験を悪化させます。
指標の扱いの失敗例
この章では、指標の扱いを失敗したことにより、ソフトウェア開発プロジェクトに悪影響を及ぼした例を3つ示します。
これらのそれぞれのケースについて、以下のようなことを考えて読んでみてください。
- どんな問題があるのでしょうか？
- 問題が起こることは事前に予測できなかったのでしょうか？
- 問題の原因を統一的に説明するにはどうすればよいのでしょうか？
- 問題と指標はどのように関連するのでしょうか？
case1
- 6月1日、真面目な性格のプロジェクトリーダー、佐藤健太は、C2テストカバレッジを監視するシステムを導入しました。カバレッジが低下すると、チームのSlackチャンネルに警告が送信されるようにしたのです
- 6月15日、最初の警告が鳴り響きました。チームの若手エンジニア、田中美咲は「やばい！」と叫び、ベテラン開発者の山本浩二は「またか」とため息をつきました。チームは必死になってテストケースの修正に取り組みました
- 7月に入っても警告は続き、疲れ果てたチームメンバーたちは、徐々に警告を無視するようになりました
- 8月1日、佐藤は「みんな、テストカバレッジ上げるの諦めちゃダメだぞ！」と叫びましたが、誰も耳を貸しませんでした
- 9月15日、テストカバレッジは導入前よりも低下していました。チームの誰もが、もはやテストカバレッジの存在すら忘れていたのです
- 10月1日、悪夢が現実となりました。重大なバグが本番環境で発見され、顧客からクレームが殺到したのです。慌てふためいた佐藤は「もっとテストを書いておけば…」と後悔の念に駆られました
case2
- 2024年7月1日、完璧主義者の技術リーダー、鈴木梨花は、チームのコード品質向上を目指してLintツールを導入しました。「これで皆のコードがピカピカになるわ！」と鈴木は意気込みました
- 7月、若手エンジニアの高橋陽太は熱心にLintを実行し、警告を一つ一つ修正していました。「鈴木さん、Lintって便利ですね！」と彼は感激していました
- しかし、8月に入ると忙しさが増し、ベテラン開発者の中村健一は「あー、めんどくさい。今回だけLintはスキップだ」とつぶやきながらコードをプッシュしました
- 9月、締め切りに追われる中、チームの多くがLintの実行を省略するようになりました。プロジェクトマネージャーの伊藤美穂は「納期が先だからね」と黙認していました
- 10月15日、新たに加入したエンジニアの山田太郎が「このコード、読みにくいですね」と指摘しました。鈴木は愕然としてコードベースを確認し、規約に違反するコードが溢れていることに気づきました。「どうしてこうなったの…」と落胆する鈴木。チームは急遽ミーティングを開き、コード品質の回復と、より効果的なLint運用について話し合うことになりました
case3
- 2025年1月、プロジェクトマネージャーの野村智子は、毎週の経営会議で優れた品質指標を報告し、満足げに微笑んでいました。テスト、Lint、カバレッジ、すべての指標が緑色で輝いていました。しかし、この輝きの裏には秘密がありました
- プロジェクトの中核を担っていたのは、天才プログラマーとして知られる藤田駿でした。彼は深夜まで没頭してコードを書き、他のメンバーのコードレビューを厳しく行い、テストケースの設計も完璧でした。「藤田さんがいるから安心だね」 とチームメンバーの小林美咲はよく言っていました
- 2025年6月15日、衝撃的なニュースが飛び込んできました。藤田が突然の転職を発表したのです。「え？藤田さんが辞めるの？」チーム全体が動揺しました
- 藤田が去った後、チームは徐々に混乱に陥っていきました。テスト結果にエラーが出ても、それが本当の問題なのか、単なる誤検出なのか判断できなくなりました。新機能の追加時、どのテストケースが不足しているのかも分からなくなりました。コードレビューは形骸化し、誰も深いレビューができなくなりました
- 9月になると、顧客からのクレームが増え始めました。野村は焦りました。「どうして？指標は全部グリーンなのに…」
おわりに
指標の扱いについて学ぶには、理論と実践の両方が必要です。そのため、この連載は理論編と実践編に分かれています。
- 理論編では、指標が一般に持っている性質とその仕組み、指標の分類と分類ごとの特徴について学びます
- 実践編では、開発現場で使われている様々な指標について、使われる場所と特性、最適な活用方法を学びます
それでは、はじめましょう！