ドキュメントレビューは、昔からソフトウェア工学の中で、品質を確保するために必ず実施すべき【重要なプロセス】として位置づけられています。それにも関わらず、ドキュメントレビューの実施方法やコツなど について、これまで体系的に詳しく解説されてきませんでした。書籍においても、ネットで検索しても、ドキュメントレビューについて、次のように書かれている程度です。
ISO 9001:2008（JIS Q 9001:2008）の定義
・製品要求事項が定められている
・組織が、定められた要求事項を満たす能力を持っている
・開発設計の結果が要求を満たせるかどうかを評価する
・問題を明確にし、必要な処置を提案する
そのため、実際のソフトウェア開発の現場では、ドキュメントレビューについての正しい理解もないまま、経験と勘に頼ったダメな間違いだらけのドキュメントレビューが横行しています。その結果、せっかくレビューをしても最後は手戻りが発生し品質・コスト・納期が悪化します。
そこでダメ！レビューに良くある５つの勘違いについて解説し、その解決策を紹介します。勘違いを克服し、品質・コスト・納期を改善する真に効果的なレビューが行えるようになります。
★効果的なドキュメントレビューを実践するための解決策はこちら！
１．研修 経験と勘だけのレビューから脱却する！
『【リスク指向】超ドキュメントレビュー実践法』
２．書籍「ドキュメントレビュー!!
要求仕様書・設計書のレビュー実践とチェックポイント」
◆間違いだらけのドキュメントレビュー
～ ダメ！なドキュメントレビューに見られる良くある５つの勘違い ～
ドキュメントレビューはセレモニーである
これは、特にウォータフォール型の開発プロセスを採用しているプロジェクトに多く見られる傾向である。この古典的な開発プロセスにおけるドキュメントレビューは、各工程での成果物を利害関係者で確認し、次の工程へ進んで良いことを判定するものである。このようなプロジェクトでは、ドキュメントレビューは、一種のセレモニーの様相を呈している。
つまり、ドキュメントレビューによって、成果物や利害関係者のコミュニケーションなどに対する実質的なフィードバックを得て、プロジェクトの進行方向を制御するものと言うよりは、次の工程に進めるための一里塚や式典として「とりあえず、やっておくもの」と位置づけられていることが多い。
大抵の場合、ドキュメントレビューの主催者は、プロジェクト管理者または各チームのリーダなど管理・監督者になる。参加者は、各チームの代表者やユーザ代表者などが中心となり、担当者レベルの参加者は少ない。自由な雰囲気に乏しく、式典としての形が重んじられ、組織的かつ制度的に実施される。
そして、時間はできるかぎり短時間で済ますことが奨励され、込み入った質疑や指摘事項などは歓迎されないものだ。セレモニーであるから、満場一致で「シャン、シャン、シャン」と手拍子を打って閉会しなければならない。この場で多くの指摘事項が飛び出して、工程を手戻りすることなどは、最悪の結果である。
もし、突っ込んだ指摘事項をするような参加者があれば、ヒンシュクを買うだろうし、そのような指摘事項は、別の場を設けて行うように制されるかもしれない。セレモニーは、式次第に沿って粛々と行われなければならない。主催者であるプロジェクト管理者やリーダは、そのことを第一義にドキュメントレビューを進行する。とにかく満場一致で、次の工程に進むことを合意しなければ、後のスケジュールが詰まっているのだ。
進め方も、ドキュメントレビュー対象となるドキュメントを作成した担当者が一通りの説明を行うが、そのドキュメントが事前に配布されることもあまりないため、参加者はあまり内容を深く理解することはできない。
あるいは、成果物であるドキュメントは、上席に整然と鎮座したままで内容を説明されることもなく、要約版を使用して簡単な説明が行われることもあるだろう。当然、突っ込んだ指摘事項などはあまり出てくることはない。参加者のほうも、ドキュメントレビューがセレモニーであることを承知しているため、深く突っ込んだ指摘などはしないことが多い。
また、そのような指摘をし難いような雰囲気が場に漂っている。たとえ指摘事項が何件か出たとしても、簡単な記述ミスや文章の書き方などで次の工程に進むには、ほとんど問題とならないようなことばかりである。ドキュメントレビュー報告書では、「特に大きな問題は無く、若干の指摘事項を成果物に盛り込んだ上で、次の工程に進むことを満場一致で合意した。」というようなことが報告される。
このように形式的なドキュメントレビューではあるが、このセレモニーが終了した後では、ドキュメントレビュー対象となったドキュメントは利害関係者によって合意された正式なドキュメントとして凍結され、リリースされる。
これ以降、ドキュメントに対する変更は、原則、禁止されることになる。こうして、プロジェクトは麗しき誤解の上に、一見、粛々と進められていくのである。そして、最後に誤解が発覚して火を吹くことになる。それまで、ドキュメントレビューに参加しながらも何ら指摘事項をしなかったにもかかわらず、この期に及んで責任を追及しあったりする。
あのセレモニーでの合意は、いったいなんだったのだろうか。その答えは、「ドキュメントレビューは、所詮、セレモニーに過ぎない。」というものだ。プロジェクトの各工程終了時に成果物を利害関係者に披露し、一応のけじめをつけて次の工程に進むためのセレモニーとしての意味をドキュメントレビューに持たせることは、決して悪いことではない。
もし、そのようなドキュメントレビューを設定するのであれば、それ依然に実務担当者や有識者を集めた、実質的なドキュメントレビューを実施し指摘事項を洗い出した上で、成果物に反映しておくことだ。そのような非公式なドキュメントレビューも全く無しに、単なるセレモニーとしての意味しかないと勘違いをしているプロジェクトも少なくない。
プロジェクト管理者やリーダが、このような勘違いをしていると、参加者もわざわざ時間を裂いてドキュメントを細部まで読み込み、指摘事項を洗い出そうというモチベーションが無くなるため、ドキュメントレビューは簡単に形骸化してしまう。そのうちに、参加者も「忙しいから一任する」と欠席者が多くなり、次第にスケジュール最優先で、ドキュメントレビューそのものが実施されないまま、後工程に進むようになる。
これが高じると、ドキュメントを書いてドキュメントレビューすることには価値が無く、とにかく動くものを作ってユーザに見せるのが一番手っ取り早く、唯一価値のあることだと言うことになる。しかし、上流工程で欠陥を発見してフィードバックをかけ修正するのと、テスト終了後に行うのとでは、数十倍から数百倍のコスト差があるという事実も忘れてはならない。時間を惜しんで、ドキュメントレビューを単なるセレモニーと勘違いした代償としては、決して小さいものではない。
ドキュメントレビューは説明会である
ドキュメントレビューの中には、開催時間が半日から一日にも及ぶようなものがある。しかも、その大半はドキュメントの説明に費やされるのだ。ドキュメントレビュー開催通知を受けた参加者が会場に来ると、完成した分厚いドキュメントが配布される。そして、作成した担当者が、おもむろに１ページづつ説明を始める。
そして、次から次へと息をつく暇も無く説明が続けられる。参加者は、初めて目にする分厚いドキュメントの説明についていくのがやっとで、指摘事項などを洗い出している余裕は無い。説明する側は、とにかく完成したドキュメントを利害関係者に説明して合意を取り付けなくてはならない。一々、指摘事項にかまってなどいる時間は無いのだ。
このようなドキュメントレビューには、ドキュメントの内容を十分理解してもらい、有識者にさまざまな角度から検討してもらいフィードバックを得るのだという考えは薄い。ただ、ひたすら自分の担当となっているドキュメントを一方的に説明することが主たる目的となっているのである。しばらくして参加者を見回してみると、半数近くが居眠りをしているようだ。
彼らの多くは有識者として呼ばれてはいるが、直接の利害関係者ではない。主催者からしてみれば、小うるさい有識者は寝ていてくれたほうが、余計な指摘をされずに済むので、説明がはかどりかえって好都合だ。
ドキュメントの説明を一生懸命に聞いているのは、直接の要求を出している顧客や利用者と、そのドキュメントを受け取って作業をすることになる後工程の担当者である。彼らは、このドキュメントレビューでの説明が終了した後、特に問題が無ければ合意しなければならないという責任が発生しているため慎重だ。
ドキュメントレビューで合意した後は、ドキュメントに対する変更要求は、手戻りとなるため、原則、受け入れられない。 このようにドキュメントレビューを成果物の説明会であると勘違いしているプロジェクトも少なくは無い。
この場合も、ドキュメントレビューをフィードバックの有効なツールとして活用しようという認識は薄い。従って、有識者など第三者の意見を謙虚に聞くというような雰囲気に欠ける。あくまで前工程の担当者が、自己の作業結果を後工程の担当者に伝える、フィードフォワードが主たる目的なのである。説明の途中で、指摘事項など発見して欲しくは無いというのが、本音だろう。
とにかく、時間を割いて徹底的に説明するので、しっかり内容を理解して、後で誤理解や勘違いなどが発生しないようにしてほしいと思っているに違いない。ドキュメントレビューに提示した成果物は、完成度が高く、指摘事項などあるはずがないと考えているのかもしれない。それ故、一方的に説明をして指摘する隙を与えないようにしているようにも見える。
実際、分厚いドキュメントを事前の配布も無く、その場で説明されたら大抵の参加者は、説明についていくことさえ難しい。ドキュメントレビューの開催時間が昼下がりのような時には、説明者の声は、心地よい子守唄である。たとえ、居眠りをしなくても、説明を聞いて内容を理解しながら、並行して指摘事項を洗い出していくのは、相当なものである。
こうして、担当者が一通り説明し終えたあとでの一言は、「皆さん十分ご理解いただけましたか？」であり、続いて「特に大きな問題が無ければ、これでドキュメントの内容について合意願います。」という調子である。これでは、指摘事項など出てくるはずがない。いや、出てこないようにドキュメントレビューを意図的に統制しているのかもしれない。
長時間を割いてドキュメントの内容を利害関係者にしっかり説明するという点においては、セレモニーとして実施されるドキュメントレビューよりは、まだ有意義であるかもしれない。しかし、このような長時間にわたり、分厚いドキュメントの説明を聞かなくてはならないような開催のやり方では、必然的に参加者の足は遠くなる。
特に、直接の利害関係者ではないが、有効なフィードバックを得るために必要な有識者の参画が得られなくなる可能性が高い。彼らにとっても時間は貴重なものであり、その貴重な時間を、直接に利害が発生しないドキュメントの説明を聞くために費やすのはムダだと思われてもしかたがない。
一方的な説明だけで、指摘事項などフィードバックを求めていないのであれば、有識者の参画は単なる飾りになってしまう。彼らも、そのようなドキュメントレビューには、敏感に感じるところがあり、積極的には参加しなくなるだろう。そうなると、ドキュメントレビュー参加者は、ドキュメントを説明するものと説明を受けるものの２者だけになってしまう。
こうしたドキュメントレビューからは、有効なフィードバックが得られることを期待することはできない。結局、最後は「ドキュメントを送付してもらえれば、こちらで時間のある時に読んで、不明点や指摘事項などは折り返し返信する。」というようなことになり、利害関係者や有識者が一同に会してのドキュメントレビューは実施されなくなってしまうのである。
ドキュメントレビューを単なるドキュメントの説明会と勘違いしているのは、ドキュメントレビューの目的や効果に対する正しい認識が欠けているからである。
ドキュメントレビューはＱ＆Ａである
ドキュメントレビューを説明会の場であると勘違いして、一方的にドキュメントを説明する主催者も、ただ説明を黙って聞いているだけの参加者も困りものだが、一方で、ドキュメントの内容に対して次々と質問ばかりを浴びせる参加者も、とんでもない勘違いをしている。
事前にドキュメントレビュー対象となるドキュメントを配布しておかなかった主催者にも問題はあるが、だからといって説明に対して質問ばかりをしていても何も有効なフィードバックは得られない。主催側が、ドキュメントレビューを利害関係者に理解してもらうための説明会であると勘違いしているのと同じく、参加者側もドキュメントを理解するのが主たる目的であると考えている場合に、このような勘違いが起こる。
一方的な説明を受けて何も指摘事項などのフィードバックをせずに、その場は理解したような姿勢を見せておきながら、後から指摘をするような参加者よりは、その場で不明点を質問して理解しようと努力する参加者のほうが、まだ、ましかもしれない。しかしながら、このＱ＆Ａの勘違いをしている参加者にかかるとドキュメントレビューの開催時間は、やはり長引くことになる。
理由は、１ページ説明を聞くたびに分からないところや疑問に思うところを質問して問い正すからだ。また、説明する側も一つ一つの質問に対して答えていくために、当然、説明のペースは落ちてしまう。説明する側にとっては、ドキュメントの内容は十分理解していることなので、参加者からの質問に答えることで得られるメリットはあまり無い。もちろん、参加者の中には、「良い質問」をして、新しい気づきを与えるような人もいるが、そのような人は質問だけに終始することはない。
むしろ、そのような「良い質問」をしない人に限って、ドキュメントを理解したり、疑問を解消したりするためだけの質問ばかりを発しがちである。また、このような勘違いをしている人は、ドキュメントレビュー対象のドキュメントを事前に配布されていたとしても、一読して指摘事項を洗い出してからドキュメントレビューに望むのではなく、質問事項ばかり洗い出して質問リストを手にドキュメントレビューへとやってくるのだ。
例えば、ドキュメントレビューの場で、「どこどこの入出力情報に矛盾がある」という指摘事項を端的に提示するのでなく、全ての入出力情報について逐一、その関連を質問して、その場で問い正そうというような勘違いをしている。そのためにドキュメントレビューの実施時間が長くなりがちで、最悪の場合、質問によって時間切れとなり、ドキュメントを最後までドキュメントレビューしきれずに延長されるか、もしくは、２回目以降を実施することになる。
参加者だけではなく、主催者側もこのような勘違いをしているケースもある。説明者がドキュメントの説明をしながらでも、また、一通り説明を終わったあとでも、「何かご質問はありますか？」と参加者に呼びかける。そうすると、参加者も何か質問をしなくてはならないような気になって、なにかと質問を捜して問いかけることになる。
そして、参加者から質問が出終わると「これで、ドキュメントの内容は十分理解いただけたと思いますので、次工程に進むこととします。」ということになる。とまあ、一方的に説明して合意を取り付けるよりは、質疑応答で理解を得た上での合意であるので、まだ、良心的だという見方もできる。
しかし、ドキュメントレビューの意義は、利害関係者や有識者が一同に会することにより、ドキュメントに書かれている内容が十分かどうかを多面的に評価し指摘することでフィードバックをかけ、プロジェクトの軌道修正を図ったり、プロジェクトの状態をチェックしたりする場である。
いくら時間をかけてＱ＆Ａを行い、そこに書かれていることだけを１００％理解したところで、書かれていない不足していることや書いてあることの矛盾やあいまいさなどが指摘されなければ、有効なフィードバックには、なり得ないのである。
もっとも、ドキュメントレビューの時であろうが事前であろうが、配布されたドキュメントを読んで、参加者が十分に理解ができないような内容となっており、質問を山ほどしなければならないようでは、指摘事項を洗い出す依然に、書き直したほうが良いかもしれない。
そのようなドキュメントをドキュメントレビューに提示して、しかも、質疑応答によって利害関係者や有識者に内容を理解してもらおうなどという勘違いをしているのでは、貴重な時間のムダである。ドキュメントは、読んで分かるように書くのが第一原則である。その上でのドキュメントレビューが有効に働くというものだ。
ドキュメントレビューに対する、このような勘違いをしている主催者や参加者が多いプロジェクトでは、ドキュメントレビューの貴重な時間のほとんどをＱ＆Ａに費やしてしまうため、事前にドキュメントを読んで理解してきた参加者には、とてつもなく退屈なドキュメントレビューとなってしまう。また、参加者として召集された有識者も、指摘事項を提示する間もなく、質疑応答のやり取りを聞いているだけの退屈な時間を過ごさなければならない。
このような状態が続くとドキュメントレビューへの参加者は、質問をしてドキュメントを理解することを主たる目的とする人ばかりが集まるようになり、多方面から有効な指摘事項を示し適切なフィードバックを与えてくれるような有識者は、徐々に集まらなくなってしまう。
また、ドキュメントの内容が分かりやすく、読めば分かるような内容であった場合、ドキュメントレビューに参加する人が少なくなるか、Ｑ＆Ａはほとんどないので、結果的に説明者が一方的に説明する説明会か、セレモニーとなってしまうことになる。
ドキュメントレビューは討議の場である
ドキュメントの品質を高めるために内容をドキュメントレビューするのであるから、討議するのは悪いことではないという勘違いもある。確かに、ドキュメントを前に問題点を発見したならば、その問題を解決するにはどうすればよいかを議論したくなるのも人情だろう。
この手の勘違いは、先のドキュメントレビューを説明会や質疑応答の場であると勘違いしている自己中心的な参加者に比べれば、ベテランや有識者で面倒見の良いタイプや技術的にレベルが高く議論好きなタイプに多いので、そのこと自体、悪くは無いのだが、時間管理や他の参加者への影響と言う面で厄介である。
なぜなら、一つの指摘事項について、何が問題なのか、どうすれば改善されるのかを懇切丁寧に説明し、議論を始めるとドキュメントレビューは、遅々として進まなくなる。
数十から数百ページもあるドキュメントの内容について、指摘事項の一つ一つに対して討議していたのでは、全体を一通りドキュメントレビューし終わるには、とても１時間や２時間では終わらない。短くて数日、下手をすれば、１週間かかっても終わらないかもしれない。
参加者は、貴重な時間を使って、自分の成果物ではない他人のドキュメントを読解して、指摘事項を洗い出さなければならないので、ある意味でボランティアである。相互扶助の精神が無ければ、やってはいられないのだ。
もし、ドキュメントレビューの主催者や参加者の数人が、討議の場であると言うような勘違いをしていて、延々と長時間に渡る討議を始めるようなことが、何度も重なれば、他の参加者の足は自然に遠のいてしまうだろう。
「ドキュメントレビューに参加すると、いつも長時間の討議になって終わらず、時間延長や追加のドキュメントレビューに付き合わされるので、自分の仕事をする時間が無くなってしまう。」このような雰囲気がプロジェクトに蔓延するようになると誰も積極的にドキュメントレビューに参加したがらなくなる。
また、ドキュメントの作成担当者も、ドキュメントレビューで延々と議論を吹っかけられるので苦痛を感じるようになり、これまた一方的な説明会かセレモニーとして簡単に済ませてしまうようになる。
しかし、一方で無下に指摘事項に対する討議を抑制しようとすれば、ベテランや有識者である彼らの気分を害してそれ以降のドキュメントレビューに積極的に参加してもらえなく可能性がある。これでは、ベテランや有識者が、親切心から有効な指摘をし、改善策を討議してくれるという良い面が裏目に出てしまい、折角の彼らの貴重なノウハウをドキュメントレビューに活かすことができずに残念なことである。
このような勘違いによる発言や討議は、ドキュメントレビューを始めてからでは、なかなか制止するのも言い出しにくく軌道修正が難しいので、ずるずると討議に深入りしてしまうことが多い。そこで、事前にドキュメントレビューの目的や進め方などを、主催者が説明して理解しておいてもらう必要がある。つまり、一回のドキュメントレビューに要する時間は１から２時間程度とし、この時間内にできるだけ多くの指摘事項を洗い出すことに、参加者の意識を集中しなければならない。
指摘事項に対して、どのように改善するのかは、担当者が要求分析作業なり設計作業なりをやり直すことであり、そのために必要であれば有識者を集めて実施する「検討会」は別に考える必要がある。
このようにドキュメントレビューは、ある程度の討議への踏み込みは許容するとしても、１回あたりの開催を短時間で、かつ極力、時間内で終了するように、うまく参加者の発言をコントロールして実施しないと、プロジェクトを通じて何度も開催するドキュメントレビューに、なかなか貴重な時間を割いて参加してもらうことが難しくなる。また、組織にもドキュメントレビューを気軽に行おうと言う雰囲気が定着しない。
もし、個別の内容について深く突っ込んだ討議をするようなドキュメントレビューを実施するのであれば、例えば、次のような手順を踏むことをプロジェクト運営要領に規定して、第一回目のドキュメントレビュー開催時に参加者へ説明し了解を得ておくのが良い。
まず、最初は個々の指摘事項に対する討議には踏み込まないようにして、一通りドキュメントレビューを終え全ての指摘事項を洗い出す。その後に、指摘事項のリスク評価を行い、優先順位をつけてから、優先度の高いもの数点にテーマを絞ったドキュメントレビュー（検討会）を、別途、開催することとする。その際には、討議の進行具合によってはドキュメントレビューの開催時間が長時間に及ぶ可能性があることを事前に通知し、それでも参加しても良いという有志だけを招集して実施する。
こうすれば、ドキュメントレビューの主たる目的である、より多くの指摘事項を洗い出し、早い段階でフィードバックをかけるということを決められた時間内で達成することができる。そして、個別の指摘事項に対するベテランや有識者のノウハウを十分に注入して、よりよい成果を得ることもできる。
ドキュメントレビューは吊し上げの場である
ドキュメントレビューがなかなか定着しない、プロジェクト・メンバが積極的にやりたがらない理由のひとつに、この勘違いがある。もしくは、勘違いではなく、実際にそのような雰囲気になっていることがあるかもしれない。勘違いにしろ、そうでないにしろ、自分の作成したドキュメントに対して他人から批判を受けるのは、気持ちの良いものではない。
この「批判」を受けるというところに、ドキュメントのドキュメントレビューを受ける側にもドキュメントレビューをする側にも、大きな勘違いがある。ドキュメントレビューの意義は、批判を受けることではなく、適切なフィードバックを利害関係者や有識者から得て、より品質の高い成果を出すことである。
また、実際にドキュメントレビューの場で、ドキュメントの作成者を批判したり糾弾したりして、それが、教育指導であると考えているような勘違いをしているベテランや有識者がいるかもしれない。確かに、批判もフィードバックの一つであるが、ドキュメントレビューでのフィードバックとは本質的に異なるものだ。
ドキュメントレビューは、ドキュメントの不足部分や矛盾点など、あくまでドキュメントに対しての指摘であり、ドキュメントの作成者に対しての考え方や人格的な面を批判するものではない。「罪を憎んで、人を憎まず」という諺があるように、ドキュメントレビューでは、「ドキュメントの不備を憎んで、人を憎まず。」の精神が大切である。
また、指摘事項は、客観的な指摘を行うことが主体であり具体的な内容の不備を指摘するものではない。例えば、要求仕様書の内容で「ｘｘｘ処理の記述は、入力と出力の関係があいまいであり、不明確である。」というような指摘の仕方をするものであり、記述のしかたが良いとか悪いとか、あるいは、ｘｘｘ処理のし方が良くないとかいう指摘をするのではない。
良いとか悪いとは、極めて主観的なところであり、どのような処理方式が最適なのかは、一概には断定できるものではない。もし、そのような点について議論するのであれば、ドキュメントレビューの場では「代替案との比較検討が不十分である。」というような指摘に留めておき、別に検討会を開催して議論すべきである。このように指摘の内容が主観的に偏ったり、担当者の考え方や人格面などを否定したりするようなことにならないためには、あらかじめ用意したチェックリストに従って、ドキュメントレビューを進めるのが良い。
こういった事前準備も無く、参加者がそれぞれ勝手に各自の主観に基づいて、ドキュメントの記述内容に対して、重箱の隅をつつくような指摘事項や果ては「てにをは」など、文法的なところまで事細かに指摘されるようでは、ドキュメントレビューされるほうは、たまったものではない。特に公式のドキュメントレビューで、多くの参加者がいるところで、そのような指摘を受ければ、自分の仕事の成果そのものを公然と批判されているような気分になり、ドキュメントレビューをしたがらなくなるのも仕方はない。
また、そのような批判めいた指摘事項をいくらフィードバックされても、前向きな品質向上に繋がる指摘事項とはならないことが少なくない。ドキュメントレビューとは、こういうものだと組織全体が勘違いしているようでは、前向きで効果的なドキュメントレビューが、利害関係者の自主的な発動で適時に実施されることは少なくなる。どうしても、ドキュメントレビューは、プロジェクト管理者が強制的に開催するもので、管理的な色合いが濃いものとなってしまうだろう。
さらに、この勘違いによる最も大きな弊害は、ドキュメントレビューに提出するドキュメントをぎりぎりまで完成度を高めようと担当者がガンバリ過ぎることである。とにかく、ドキュメントレビューで指摘（批判）を受けたくない一心で、できるだけ完成度を高めようともがくのである。そのため、ドキュメントレビュー開催日が迫ってくると進捗率がとたんに悪くなる傾向がある。
先週まで予定通り７０％、８０％と進捗していたのに、ドキュメントレビューの数日前になると突如、９１％、９２％と遅々として進まなくなる。どうしたことかと聞いてみると、自己チェックをしており気になるところが、まだ完全になっていないと言う。挙句の果てには、もう少し、時間を取って完璧を目指したいので、ドキュメントレビューの開催を延期したいと言い出す始末だ。これでは、何のためのドキュメントレビューか分からない。
完成度は、７０％から８０％でも良いので利害関係者や有識者のドキュメントレビューを受けることで、フィードバックを得て、早めに軌道修正するというドキュメントレビュー本来の目的を全く勘違いしているのだ。担当者が一人でいくらかんばって１００％の完成度に仕上げたところで、ドキュメントレビューで指摘事項が出れば、それを盛り込むために手戻りが発生することは確実である。
そうなった場合、ぎりぎりまでドキュメントレビューを引き伸ばしたり、大きな指摘事項が発見されたり場合は、スケジュールもコストも危険にさらされることになる。そのタスクが、クリティカル・パス上のものであった場合には、その担当者のガンバリ過ぎのためにプロジェクト全体が危機に直面することになりかねない。それで、品質がより高まればよいが、早めにドキュメントレビューを受けて指摘事項を盛り込んだ場合と大差ない。
このように、組織全体がドキュメントレビューに対して「吊し上げの場である」というような勘違いをしており、メンバが強迫観念を持っていると、早めにドキュメントレビューを受けてフィードバックをもらい、手遅れにならないうちに軌道修正しようという意識が働きにくくなり、単なる説明会やセレモニーで終わらせようとするためドキュメントレビュー本来の効果が薄れてしまう。
このような勘違いを組織に蔓延させないためには、先に述べたようにドキュメントレビューでの指摘ポイントをあらかじめチェックリストなどにまとめ統制をかけておくことや指摘事項に関するマナーなどを周知することが重要である。
また、常日頃から利害関係者間のコミュニケーションを良好に保ち、相互に指摘し合うことでシナジ効果によって、より良い品質を確保するのだと言う相互扶助の精神と他人からの指摘事項を素直に、かつ真摯に受け止め自分の仕事の糧とできるような「大人の心」を養っておく必要がある。行き過ぎた成果主義のために、心理的安全性が低下しドキュメントレビューで誰も有効なフィードバックをしなくなったり、互いに足を引っ張り合ったりしてプロジェクトが破綻するようでは本末転倒である。
★効果的なドキュメントレビューを実践するための解決策はこちら！
■１２０社１０００人以上が受講！！
１．研修・オンライン講座
経験と勘だけのレビューから脱却する！レビューを体系的に学び、成果につなげる！
『【リスク指向】超ドキュメントレビュー実践法』
※実務ですぐに使えるチェックリストを使用した演習付き！
危険予知能力を高め、リスクを見つける！
『100の失敗事例に学ぶ！企業システム戦略の危険予知訓練』
※すぐに実践で役立つ100の失敗事例による危険予知訓練の演習付き！
■便利な道具箱
■自動でしゃべるパワーポイント（VBAマクロ）
ノート欄のテキストを音声合成エンジンが読み上げ、画面も自動で切り替わるVBAマクロ！
音声を録音するよりとっても楽です。失敗して録音をやり直す手間もなく、部分的な変更も楽々です。
■簡易日程計算（Excel/VBA)
製品構成展開されたツリーデータを使用して、製品を期日までに組立完成させるために必要な日程を計算するExcel/VBA！
■簡易原価積上げ計算（Excel/VBA)
製品構成展開されたツリーデータを使用して、製品を構成する部材の原価を積上げ、製品原価を計算するExcel/VBA！
■簡易所要量計算（Excel/VBA)
製品構成展開されたツリーデータを使用して、製品を組み立てるために必要な部品の個数を
計算するExcel/VBA！
PR広告！TechAcademy [テックアカデミー]
PR広告！システム開発業者を完全無料でご紹介します！【EMEAO!】
コメント