要件定義の進め方

システム開発の大炎上を防ぐために、上流工程(前工程)に位置する「要件定義」について、考えていくブログです。

要件定義書の作り方
PDCAサイクルではなく、PDCサイクルを回そう
あるべきV字モデルについて整理した
スコープを決めてから、QCDの議論をしよう

資料作成の8割はバックデータ作成

資料作成の8割はバックデータ作成

昔、大学の授業で聞いた言葉だ。プレゼンの授業だったと思う。資料作成自体は最後の上澄み作業であり、作業の大半は泥臭い裏どり作業なのだ、という内容の話だった。確かに、その先生の授業は面白く、人を惹きつけるような内容で、説得力があった。質疑応答も完璧だった。あらゆる質問を想定しているのであろう。隠しスライドがたくさんあった。

プレゼンというのは

主張を簡潔に述べて読み手を説得させるもので、細かい裏どり資料を見せる必要がない。裏どり資料を見せるか見せないかはケースバイケースだ。必ず見せる必要は無いとはいえ、万全な準備をしておかなければならない、そこが泥臭い仕事なんだ、そんなことを言われていた気がする。

裏どり作業は省略されることがある

あらゆる仕事において、しばしばこの泥臭い裏どり作業は省略されることがある。

例えば、社内で品質の確保ができたことを報告するために、「テスト完了」という言葉を資料で使うかもしれない。この言葉一つをとっても、話し手にとってのテスト完了と、読み手にとってのテスト完了は、意味合いが異なるかもしれない。ただ数をこなして、全部OKでもテスト完了だ。都合の悪いテストを対象外にしてもテスト完了だ。テストが終わって品質確保が完了した、それだけの説明にも、事実に基づいた裏どりデータを揃えておく必要があるのだ。

例として、

  • ①:ベンダーからのテスト完了報告を受けた
  • ②:ベンダーのテスト結果のサマリー見て、NGがないことを確認した
  • ③:ベンダーのテスト報告書を一通り確認し、問題ないと判断した
  • ④:ベンダーのテスト報告書とエビデンスを全て自分たちで確認し、問題ないと判断した

のケースがあったとする。報告書では、どれもテスト完了と記載できる。品質確保を裏付ける根拠として、強いのは、もちろん④だ。逆に、①は弱い(ただし、ベンダーが非常に優秀で、聞き手も話し手も全幅の信頼を寄せている場合は、①でも良い時はある)。

手を抜けば数分、手を抜かなければ数日

たった1行のテスト完了という言葉でも、手を抜けば数分、手を抜かなければ数日という差がでてくる。その時間差は、決して資料には現れない。どれだけ用意しても、突っ込まれないこともしょっちゅうある。だからこそ、手を抜いてもいいという誘惑が存在してしまう。

裏どり作業はしんどい

裏どり作業はしんどいものだ。創造的な仕事でもないし、単純な作業だ。はっきり言って、面倒くさい作業だ。他人の言うことを鵜呑みにしてテスト完了と報告してしまえば、どんなに楽であろうか。そんな時にいつも思い出すのが、「資料作成の8割はバックデータ作成」という言葉だ。品質に対する最終責任は自分、だからこそ、面倒臭くても、自分の目でちゃんと確認すること。これを意識して仕事をしたい。

結論:面倒くさくても、なるべく自分の目で確認しよう