1. 日報の書き方を共有して気づいたこと 2026年11月5日、職場で「日報の書き方共有会」を開いた。統一ルールを作る会ではない。「みんな、普段どうやって日報を作っているのか」という素朴な疑問から、それぞれの書き方や考え方を持ち寄った。 そこで私が気づいたのは、日報の形式の違いというより、進捗を何で表すかの違いだった。約25年IT業界で仕事をしてきた私には、かつての日報には数字が多かったという記憶がある。ただし、これは私が関わった現場の経験であり、当時の開発現場すべてに当てはまる話ではない。今回の共有会も限られた職場での観察で、世代や業界全体の傾向を示すものではない。 2. かつての日報には数字が並んでいた 従来型の開発プロジェクトで、私は設計なら「本日作成したページ数／累積ページ数／完了予定ページ数」、実装なら「本日作成した行数／累積行数／完了予定行数」といった報告をしていた。単体テストでは作成・実施ケース数を、不具合では当日と累計の検出件数を記録した。レビューなら参加人数、時間、対象ページ数、指摘件数を並べることもあった。 数字を集める理由は、作業量を数えることだけではない。計画と実績の差を見て、遅れが広がっていないか、次の判断が必要かを第三者も把握できるようにするためだ。計画を基準に実績を追う進捗管理では、作業や成果物の単位と基準が揃っていることが前提になる。[1] ページ数、行数、ケース数は、その前提を置きやすい単位だった。大きな工程を分解し、完了予定と累積実績を並べれば、少なくとも「計画と比べてどこにいるか」は話しやすくなる。 3. 数字が示していたもの、示していなかったもの ただし、数字が示すのは定義した対象だけだ。設計書が十ページ増えても、要求の曖昧さが解けたとは限らない。コードが千行増えても、利用者の課題が解決したとは限らない。テストケースを多く実施しても、重要なリスクを網羅したとは限らない。行数は言語や書き方、何を一行と数えるかでも変わる。 IPAの開発データ白書はSLOC（ソースコード行数）を生産性の統計に使う一方、IPA自身が、流用開発やOSS利用、再構築などでは現行のSLOC指標が見積もりや計画生産性の妥当性評価に合わない場合が増えると説明している。[2] これは「LOCは無意味」ということではない。対象や目的を揃えた統計や、同一プロジェクト内の推移を見る補助情報にはなり得るが、価値や品質の代理指標として単独で扱うと誤解を招く。 数字は問いを答えるための道具だ。「何を判断したいのか」を置かず、取りやすい数字だけを集めれば、進捗を測っているつもりで作業量を記録しているだけかもしれない。 4. アジャイルで数字は不要になったのか Scrumは透明性・検査・適応を軸に、作業と成果を見えるようにし、合意した目標への進み方を頻繁に確かめ、必要なら調整する。[3] スプリントのバーンダウンは残作業の推移を眺める一つの方法であり、スループット（一定期間に完了した仕事の数）やサイクルタイム（着手から完了までの時間）は、仕事の流れを理解する手掛かりになる。これらはScrumの必須ルールというより、現場で使われる可視化・分析手法だ。 したがって、アジャイルが定量管理を捨てたとは言えない。日々の個人報告より、チームのバックログ、スプリント目標、完成したインクリメント、フローの傾向に管理の焦点を移す場合がある。Scrum Guideも「進捗は数字で報告せよ」とは定めず、成果物と目標の透明性・検査を求めている。[3] 個人の日報の数字が減っても、プロジェクト全体で何も測っていないとは限らない。 DORAは現在、変更のリードタイム、デプロイ頻度、失敗したデプロイからの復旧時間、変更失敗率、デプロイ手戻り率を、スループットと不安定さの観点から扱う。[4] これはコードを書いた量より、変更を安全に届けられているかを見る指標だ。ただし、これらも単独でチームを順位付けする魔法の数字ではなく、改善の対象を探すためのものと捉えたい。 5. AIが3,000行のコードを書いた日 ここで、説明のための仮想例を置こう。実測値ではない。AIが3,000行を生成したが、検証して2,800行を破棄し、残った200行で要求を満たしたとする。日報に「3,000行生成」とだけ書けば、進捗を大きく見せる一方で、その後の検証と破棄を隠してしまう。「200行を採用」とだけ書いても、要求を満たすか、テストが通ったか、レビューで受け入れられたかは分からない。 報告したいのは生成量そのものより、何が受け入れ可能な状態になったかだろう。たとえば「対象機能を実装し、受け入れ条件を満たすテストを確認した。生成案の大半は仕様不一致で破棄。セキュリティレビューが残り、認証方式の判断待ち」と書けば、成果、検証、残作業、判断事項が一緒に伝わる。 AI支援開発の生産性を測る研究でも結果は一様ではない。Googleの企業内実験では特定タスクの所要時間短縮が報告された一方、研究者は別のツールや環境へ効果を一般化できないと述べる。[5] DORAの2024年調査はAI採用と個人の生産性認識に利点を見いだす一方、デリバリーの安定性・スループットとのトレードオフも報告した。[6] 生成速度と、レビュー・テストを経た成果は同じ指標ではない。 6. これからの日報に必要なもの 日報に載せる数字は、目的に応じて選べばよい。計画との差を判断するなら、完了した成果物や残作業の見積もりが要る。フロー改善なら、サイクルタイムや滞留件数が役立つことがある。品質や運用影響を見たいなら、テスト結果、重大な不具合、リリース後の失敗や復旧も見る。AI利用の効果を確かめるなら、生成行数だけでなく、レビュー時間、修正・破棄、受け入れ済み変更、手戻りなどを、対象範囲と期間を揃えて観察する必要がある。 日報は全指標を詰め込む場所ではない。読む人が次の判断をするために、完了したこと、検証の結果、残っていること、リスクや判断待ちを必要な粒度で伝える。数字はその説明を支えるときに添える。個人の作業量を比較する用途に変わると、難しい仕事を避けたり、指標だけを良く見せたりする誘因も生まれる。計測には、誰が何のために使うのかという合意も必要だ。 7. おわりに 昔の定量報告が正しく、今の書き方が間違いだとは思わない。ページ数や行数には、計画からのずれを早く見つける合理性があった。一方、成果物の品質や価値を直接表さない限界もあった。開発の進め方が変われば、見るべき数字も変わる。 定量報告が古くなったのではない。定量化する対象を見直す必要がある。日報から数字が消えたとき、プロジェクトは何を見えるようにしているのだろう。数字が残っているとき、その数字は誰のどんな判断を助けているのだろう。第三者が状況を理解し、次の判断を行えるようにすること――その報告の本質を、私たちは改めて問い直せる。 --- 参考資料 [1] U.S. Government Accountability Office, *GAO Schedule Assessment Guide: Best Practices for Project Schedules*, 2015. https://www.gao.gov/products/gao-16-89g [2] IPA（独立行政法人情報処理推進機構）, 「『ソフトウェア開発データ白書』シリーズに関するよくある質問と回答」, 発行年記載なし（2018-2019版を基準とする旨の記載あり）. https://www.ipa.go.jp/archive/publish/wp-sd/qa.html [3] Ken Schwaber and Jeff Sutherland, *The 2020 Scrum Guide*, 2020年11月. https://scrumguides.org/scrum-guide.html [4] DORA / Google Cloud, “DORA’s software delivery performance metrics”, 発行年記載なし（ウェブ資料、2026年11月5日確認）. https://dora.dev/guides/dora-metrics/ [5] M. A. A. et al., “How much does AI impact development speed? An enterprise-based randomized controlled trial,” arXiv:2410.12944, 2024. https://arxiv.org/abs/2410.12944 [6] DORA / Google Cloud, *Accelerate State of DevOps Report 2024*, 2024. https://dora.dev/research/2024/dora-report/