経営者・教育部門長の皆様へ。
システム開発の品質向上や投資効率向上はもちろん、生産性向上・コスト削減・納期確保、そして組織力強化にまで効く、超ドキュメントレビュー

    
 レビューに関するご相談は無料です。お問い合せは、こちらのフォームから。



 経営者、教育部門長の皆様へ。

 本気でシステム開発の品質向上や投資効率向上はもちろん、生産性向上・手戻りコスト削減・納期確保、さらにはレビューを通じたコミュニケーション活性化や人材育成など組織力強化を考えておられるなら従来のドキュメントレビューを超える、

 企業システム戦略を成功させる!【リスク指向】ドキュメント・レビュー実践法

 の社内研修(標準研修費用30名/50万円。研修期間1日)を、ご提案します。

※組織やその構成員が品質向上を心がけることは、コストを常に低下させることに他ならない。(W・エドワーズ・デミング)

 ただし、

 レビューは品質向上が目的。生産性向上やコスト削減は無理。

 品質向上には、しっかりレビューすることが重要なのは分かっているが、コストが嵩む。

 生産性向上したら、次からの見積もりに反映しなければならず売上がさがる。


 もし、こんな風に思っているなら、
 ここから先は、読むだけ時間の無駄かもしれません。



 要点は以下の2つです。

 1.リスク指向で、リスク強度(発生確率と影響度)の大きい指摘を多く抽出する。

 2.速読により2倍のスピード(生産性2倍)でレビューする。

以上をプロジェクト開始までにメンバー全員に教育研修する。1〜2名では効果は出ません。
自己啓発ではなく、会社の施策・教育投資として取り組む必要があります。

 一つ目は、1時間のレビューで発見できたリスクが後工程で発覚すると最大、
200倍の手戻りコストが発生すると言われているので、これらリスクの発見に集中します。

従来のように誤字脱字の類の間違いを、どれだけ時間をかけて指摘しても、結局、手戻りが発生
したのでは、生産性向上やコスト削減はできません。特に不確実性が高まっている昨今、

その時点では正解である「1+1=2」を穴のあくほど見ても”間違い”の指摘は
できませんね。

決めたはずの要件定義の追加・変更による手戻りコスト増加が失敗原因の半数以上です。

しかし、時空軸をずらし観点(視点・視野・視座)を変え1+1がもし、
1+2や2+3になったら、どんなリスクがどれくらいの確率で発生するかを予測し、
事前に対策を打つことで、要件定義の品質向上が図られ、結果的に、大幅な生産性向上、
手戻りによるコスト削減が見込めます。

 二つ目は、一つ目を効率的に行うため。レビューの効果を知っていても、
レビューそのものに時間がかかるため、形骸化していることが多い。
形骸化したレビューでは、生産性向上やコスト削減につながるリスクは発見できません。
速読訓練により、読解速度を2倍にできれば、2時間かかっていたレビューが1時間で
可能となり、確実に生産性が2倍になります。速読2倍はそれほど難しい技術ではなく、
ちょっとしたコツをつかめば可能な速度です。

これは個人的な自己啓発ではなく、会社の施策として取組み、プロジェクトの全員が
超ドキュメントレビューの観点を得なければ、実質的に生産性向上・コスト削減
を実現することは難しいので、社内研修がお奨めです。

また、リスク指向のレビューに組織的に取り組むことで、コミュニケーション活性化や人材育成など組織力強化が図られます。

研修費用は30名で50万円ほどです。研修時間は1日で充分です。

研修の効果は、リスク抽出件数や手戻りコストで明確に測定可能です。

実際、研修では前後にレビュー演習をして、指摘事項の質・量を測定してもらいますが、 これまで、一切の変化が得られなかったという受講者はゼロです。

1回のプロジェクトで最大200倍のコスト削減が可能です。ちょっとしたプロジェクトなら 直ぐに1000万円くらいになります。その最初にプロジェクト全員が50万円で研修を受け、
その結果、重大なリスクを回避することができれば容易に研修費は回収可能です。

例えば、マスターデータベースの主キーに設計変更が発生し、そのマスターを参照しているプログラムが100本くらいあれば、200時間くらいの手戻り作業が発生します。これを1時間のレビューでリスク抽出し、事前対策できれば、200分の1のコストで済みます。

ですので、決して高い教育投資ではないと思います。

研修内容等詳しくは、下記をご覧ください。

 企業システム戦略を成功させる!【リスク指向】ドキュメント・レビュー実践法



 さて、その前に、一般的に行われている従来のレビューについて、お話しします。

 レビューは、昔からソフトウェア工学の中で、
 品質を確保するために必ず実施すべき
 【重要なプロセス】として位置づけられています。

 それにも関わらず、レビューの実施方法やコツなど
 について、これまで詳しく解説されてきませんでした。

 書籍においても、ネットで検索しても、
 レビューについて、次のように書かれている程度です。

 ISO 9001:2008(JIS Q 9001:2008)の定義

 ・製品要求事項が定められている
 ・組織が、定められた要求事項を満たす能力を持っている
 ・開発設計の結果が要求を満たせるかどうかを評価する
 ・問題を明確にし、必要な処置を提案する。

 そのため、実際のソフトウェア開発の現場では、
 レビューについての正しい理解もないまま、
 形式的なレビューが横行しています。

 形式的なレビューとは、複数人が集まり、
 対象となる成果物(要求仕様書や設計書など)を
 読み合わせて、各人が思いつくままに、
 各人の経験に頼って、

 間違いや問題点と思われるところを指摘したり、
 認識合わせをしたりするのです。

 そして、いくつかの指摘事項を報告して、
 次の工程へと進みます。

 すなわち、レビューの”形”だけを整えるのです。

 レビューは、通常、2〜3時間行われますが、
 場合によっては、半日や1日をかけて行われる
 事もあります。

 成果物の量によっては、時間切れとなり、
 追加の日程が設定されることもあります。


 このように人と時間をかけてレビューをしても、
 誤字脱字の間違いや文法上の間違いなどの
 指摘に終始することも少なくありません。

 また、レビューと言いいながらも、
 成果物の説明に多くの時間を費やしています。

 時には、経験のあるベテランが有効な指摘を
 することもあります。
 しかし、いまでは誰もが未経験のプロジェクト
 も少なくありません。

 そもそも、プロジェクトというのは、
 同じことが繰り返されることはありません。

 単なる過去の経験だけでは、
 それほどレビューに役立たないものです。
 経験を次へ活かすためのコツや訓練が不足しています。

 ・定めたはずの製品要求事項に認識違いが潜在。
 ・要求事項の認識が違うので、組織が保持すべき能力も異なる。
 ・要求事項の認識が違うので、開発設計の結果に対する評価も無意味。
 ・誤解の上に要求事項が定まり、問題さえ認識されない。


 その結果、レビューを実施しても、
 【想定外】に変更や手戻りなどが発生してしまいます。

 変更や手戻りの発生は、時間とコストの超過に
 つながりますから、プロジェクトは失敗です。

 こうなると、レビューに費やした時間は、
 全くのムダということになります。


 社内規定などで、レビューが義務付けられているので
 これをやらないわけにはいけません。

 しかし、実質的にレビューをやるだけ時間のムダと
 いうことになると、できるだけ短時間で済ませたい
 というのが人情です。

 そこで、形だけのレビューが横行することになります。

 形だけのレビューでは、当然、本来の意図する効果は
 得られません。

 本来の意図する効果とは、プロジェクトの成功です。

 効果が得られなければ、やはり手戻りが発生し、
 プロジェクトは苦しむことになります。


 少し学習能力のある組織では、失敗の解析をします。

 なぜ、失敗したのか関係者が集まり、
 原因分析を行い、次回に向けた対策を立案します。

 原因分析では、なぜ、手戻りが発生したのか、
 レビューでなぜ、気がつかなかったのかなど、
 詳細に分析を進めます。

 しかし、行き着くところは、要件があいまいなまま
 設計を進めてしまったなどの原因に落ち着きます。

 そうなれば対策としては、

 「次回のレビューでは、より注意深く要件を確認しましょう。」

 という精神論に近い対策になります。

 これでは、何度、レビューを繰り返しても、
 同じ失敗を繰り返します。

 そして、後で振り返って、

 ”あの時に気がついていれば。。。”

 という後悔をすることになるわけです。


 かくして、やはりレビューは”やるだけ時間のムダ!”
 という認識が、現場の常識として深く根を張ることに
 なるのです。

 このように本来の目的から遠く離れてしまった
 多くの『常識的なレビュー(実は勘違い)』には、
 以下のような特徴があります。


 【レビューの常識】

  □レビューはセレモニーである

  □レビューは説明会である

  □レビューはQ&Aである

  □レビューは討議の場である

  □レビューは吊し上げの場である


 これらについて、簡単に説明しましょう。

 ・レビューはセレモニーである

  これまでに、お話したとおりです。
  レビューはやるだけ時間のムダですから、
  規定を守って実施したという形式的事実だけ
  が重要になります。

 これは、特にウォータフォール型の開発プロセスを採用しているプロジェクトに多く見られる傾向である。この古典的な開発プロセスにおけるドキュメント・レビューは、各工程での成果物を利害関係者で確認し、次の工程へ進んで良いことを判定するものである。このようなプロジェクトでは、ドキュメント・レビューは、一種のセレモニーの様相を呈している。

つまり、ドキュメント・レビューによって、成果物や利害関係者のコミュニケーションなどに対する実質的なフィードバックを得て、プロジェクトの進行方向を制御するものと言うよりは、次の工程に進めるための一里塚や式典として「とりあえず、やっておくもの」と位置づけられていることが多い。

大抵の場合、ドキュメント・レビューの主催者は、プロジェクト管理者または各チームのリーダなど管理・監督者になる。参加者は、各チームの代表者やユーザ代表者などが中心となり、担当者レベルの参加者は少ない。自由な雰囲気に乏しく、式典としての形が重んじられ、組織的かつ制度的に実施される。

そして、時間はできるかぎり短時間で済ますことが奨励され、込み入った質疑や指摘事項などは歓迎されないものだ。セレモニーであるから、満場一致で「シャン、シャン、シャン」と手拍子を打って閉会しなければならない。この場で多くの指摘事項が飛び出して、工程を手戻りすることなどは、最悪の結果である。

もし、突っ込んだ指摘事項をするような参加者があれば、ヒンシュクを買うだろうし、そのような指摘事項は、別の場を設けて行うように制されるかもしれない。セレモニーは、式次第に沿って粛々と行われなければならない。主催者であるプロジェクト管理者やリーダは、そのことを第一義にレビューを進行する。とにかく満場一致で、次の工程に進むことを合意しなければ、後のスケジュールが詰まっているのだ。

進め方も、レビュー対象となるドキュメントを作成した担当者が一通りの説明を行うが、そのドキュメントが事前に配布されることもあまりないため、参加者はあまり内容を深く理解することはできない。

あるいは、成果物であるドキュメントは、上席に整然と鎮座したままで内容を説明されることもなく、要約版を使用して簡単な説明が行われることもあるだろう。当然、突っ込んだ指摘事項などはあまり出てくることはない。参加者のほうも、レビューがセレモニーであることを承知しているため、深く突っ込んだ指摘などはしないことが多い。

また、そのような指摘をし難いような雰囲気が場に漂っている。たとえ指摘事項が何件か出たとしても、簡単な記述ミスや文章の書き方などで次の工程に進むには、ほとんど問題とならないようなことばかりである。レビュー報告書では、「特に大きな問題は無く、若干の指摘事項を成果物に盛り込んだ上で、次の工程に進むことを満場一致で合意した。」というようなことが報告される。

このように形式的なレビューではあるが、このセレモニーが終了した後では、レビュー対象となったドキュメントは利害関係者によって合意された正式なドキュメントとして凍結され、リリースされる。

これ以降、ドキュメントに対する変更は、原則、禁止されることになる。こうして、プロジェクトは麗しき誤解の上に、一見、粛々と進められていくのである。そして、最後に誤解が発覚して火を吹くことになる。それまで、ドキュメント・レビューに参加しながらも何ら指摘事項をしなかったにもかかわらず、この期に及んで責任を追及しあったりする。

あのセレモニーでの合意は、いったいなんだったのだろうか。その答えは、「ドキュメント・レビューは、所詮、セレモニーに過ぎない。」というものだ。プロジェクトの各工程終了時に成果物を利害関係者に披露し、一応のけじめをつけて次の工程に進むためのセレモニーとしての意味をドキュメント・レビューに持たせることは、決して悪いことではない。

もし、そのようなドキュメント・レビューを設定するのであれば、それ依然に実務担当者や有識者を集めた、実質的なドキュメント・レビューを実施し指摘事項を洗い出した上で、成果物に反映しておくことだ。そのような非公式なドキュメント・レビューも全く無しに、単なるセレモニーとしての意味しかないと勘違いをしているプロジェクトも少なくない。

プロジェクト管理者やリーダが、このような勘違いをしていると、参加者もわざわざ時間を裂いてドキュメントを細部まで読み込み、指摘事項を洗い出そうというモチベーションが無くなるため、ドキュメント・レビューは簡単に形骸化してしまう。そのうちに、参加者も「忙しいから一任する」と欠席者が多くなり、次第にスケジュール最優先で、ドキュメント・レビューそのものが実施されないまま、後工程に進むようになる。

これが高じると、ドキュメントを書いてレビューすることには価値が無く、とにかく動くものを作ってユーザに見せるのが一番手っ取り早く、唯一価値のあることだと言うことになる。しかし、上流工程で欠陥を発見してフィードバックをかけ修正するのと、テスト終了後に行うのとでは、数十倍から数百倍のコスト差があるという事実も忘れてはならない。時間を惜しんで、ドキュメント・レビューを単なるセレモニーと勘違いした代償としては、決して小さいものではない。

 ・レビューは説明会である

  レビューは関係者が認識あわせすることが
  重要なので、成果物をしっかり説明し、
  それを理解することに重点が置かれます。

 ドキュメント・レビューの中には、開催時間が半日から一日にも及ぶようなものがある。しかも、その大半はドキュメントの説明に費やされるのだ。レビュー開催通知を受けた参加者が会場に来ると、完成した分厚いドキュメントが配布される。そして、作成した担当者が、おもむろに1ページづつ説明を始める。

そして、次から次へと息をつく暇も無く説明が続けられる。参加者は、初めて目にする分厚いドキュメントの説明についていくのがやっとで、指摘事項などを洗い出している余裕は無い。説明する側は、とにかく完成したドキュメントを利害関係者に説明して合意を取り付けなくてはならない。一々、指摘事項にかまってなどいる時間は無いのだ。

このようなレビューには、ドキュメントの内容を十分理解してもらい、有識者にさまざまな角度から検討してもらいフィードバックを得るのだという考えは薄い。ただ、ひたすら自分の担当となっているドキュメントを一方的に説明することが主たる目的となっているのである。しばらくして参加者を見回してみると、半数近くが居眠りをしているようだ。

彼らの多くは有識者として呼ばれてはいるが、直接の利害関係者ではない。主催者からしてみれば、小うるさい有識者は寝ていてくれたほうが、余計な指摘をされずに済むので、説明がはかどりかえって好都合だ。

ドキュメントの説明を一生懸命に聞いているのは、直接の要求を出している顧客や利用者と、そのドキュメントを受け取って作業をすることになる後工程の担当者である。彼らは、このドキュメント・レビューでの説明が終了した後、特に問題が無ければ合意しなければならないという責任が発生しているため慎重だ。

レビューで合意した後は、ドキュメントに対する変更要求は、手戻りとなるため、原則、受け入れられない。 このようにドキュメント・レビューを成果物の説明会であると勘違いしているプロジェクトも少なくは無い。

この場合も、ドキュメント・レビューをフィードバックの有効なツールとして活用しようという認識は薄い。従って、有識者など第三者の意見を謙虚に聞くというような雰囲気に欠ける。あくまで前工程の担当者が、自己の作業結果を後工程の担当者に伝える、フィードフォワードが主たる目的なのである。説明の途中で、指摘事項など発見して欲しくは無いというのが、本音だろう。

とにかく、時間を割いて徹底的に説明するので、しっかり内容を理解して、後で誤理解や勘違いなどが発生しないようにしてほしいと思っているに違いない。ドキュメント・レビューに提示した成果物は、完成度が高く、指摘事項などあるはずがないと考えているのかもしれない。それ故、一方的に説明をして指摘する隙を与えないようにしているようにも見える。

実際、分厚いドキュメントを事前の配布も無く、その場で説明されたら大抵の参加者は、説明についていくことさえ難しい。レビューの開催時間が昼下がりのような時には、説明者の声は、心地よい子守唄である。たとえ、居眠りをしなくても、説明を聞いて内容を理解しながら、並行して指摘事項を洗い出していくのは、相当なものである。

こうして、担当者が一通り説明し終えたあとでの一言は、「皆さん十分ご理解いただけましたか?」であり、続いて「特に大きな問題が無ければ、これでドキュメントの内容について合意願います。」という調子である。これでは、指摘事項など出てくるはずがない。いや、出てこないようにレビューを意図的に統制しているのかもしれない。

長時間を割いてドキュメントの内容を利害関係者にしっかり説明するという点においては、セレモニーとして実施されるドキュメント・レビューよりは、まだ有意義であるかもしれない。しかし、このような長時間にわたり、分厚いドキュメントの説明を聞かなくてはならないような開催のやり方では、必然的に参加者の足は遠くなる。

特に、直接の利害関係者ではないが、有効なフィードバックを得るために必要な有識者の参画が得られなくなる可能性が高い。彼らにとっても時間は貴重なものであり、その貴重な時間を、直接に利害が発生しないドキュメントの説明を聞くために費やすのはムダだと思われてもしかたがない。

一方的な説明だけで、指摘事項などフィードバックを求めていないのであれば、有識者の参画は単なる飾りになってしまう。彼らも、そのようなレビューには、敏感に感じるところがあり、積極的には参加しなくなるだろう。そうなると、レビュー参加者は、ドキュメントを説明するものと説明を受けるものの2者だけになってしまう。

こうしたドキュメント・レビューからは、有効なフィードバックが得られることを期待することはできない。結局、最後は「ドキュメントを送付してもらえれば、こちらで時間のある時に読んで、不明点や指摘事項などは折り返し返信する。」というようなことになり、利害関係者や有識者が一同に会してのドキュメント・レビューは実施されなくなってしまうのである。

ドキュメント・レビューを単なるドキュメントの説明会と勘違いしているのは、レビューの目的や効果に対する正しい認識が欠けているからである。

 ・レビューはQ&Aである

  認識合わせや内容の理解に重点が置かれるため
  質問はたくさん出ます。そして、時間切れです。

 ドキュメント・レビューを説明会の場であると勘違いして、一方的にドキュメントを説明する主催者も、ただ説明を黙って聞いているだけの参加者も困りものだが、一方で、ドキュメントの内容に対して次々と質問ばかりを浴びせる参加者も、とんでもない勘違いをしている。

事前にレビュー対象となるドキュメントを配布しておかなかった主催者にも問題はあるが、だからといって説明に対して質問ばかりをしていても何も有効なフィードバックは得られない。主催側が、ドキュメント・レビューを利害関係者に理解してもらうための説明会であると勘違いしているのと同じく、参加者側もドキュメントを理解するのが主たる目的であると考えている場合に、このような勘違いが起こる。

一方的な説明を受けて何も指摘事項などのフィードバックをせずに、その場は理解したような姿勢を見せておきながら、後から指摘をするような参加者よりは、その場で不明点を質問して理解しようと努力する参加者のほうが、まだ、ましかもしれない。しかしながら、このQ&Aの勘違いをしている参加者にかかるとレビューの開催時間は、やはり長引くことになる。

理由は、1ページ説明を聞くたびに分からないところや疑問に思うところを質問して問い正すからだ。また、説明する側も一つ一つの質問に対して答えていくために、当然、説明のペースは落ちてしまう。説明する側にとっては、ドキュメントの内容は十分理解していることなので、参加者からの質問に答えることで得られるメリットはあまり無い。もちろん、参加者の中には、「良い質問」をして、新しい気づきを与えるような人もいるが、そのような人は質問だけに終始することはない。

むしろ、そのような「良い質問」をしない人に限って、ドキュメントを理解したり、疑問を解消したりするためだけの質問ばかりを発しがちである。また、このような勘違いをしている人は、レビュー対象のドキュメントを事前に配布されていたとしても、一読して指摘事項を洗い出してからレビューに望むのではなく、質問事項ばかり洗い出して質問リストを手にレビューへとやってくるのだ。

例えば、レビューの場で、「どこどこの入出力情報に矛盾がある」という指摘事項を端的に提示するのでなく、全ての入出力情報について逐一、その関連を質問して、その場で問い正そうというような勘違いをしている。そのためにレビューの実施時間が長くなりがちで、最悪の場合、質問によって時間切れとなり、ドキュメントを最後までレビューしきれずに延長されるか、もしくは、2回目以降を実施することになる。

参加者だけではなく、主催者側もこのような勘違いをしているケースもある。説明者がドキュメントの説明をしながらでも、また、一通り説明を終わったあとでも、「何かご質問はありますか?」と参加者に呼びかける。そうすると、参加者も何か質問をしなくてはならないような気になって、なにかと質問を捜して問いかけることになる。

そして、参加者から質問が出終わると「これで、ドキュメントの内容は十分理解いただけたと思いますので、次工程に進むこととします。」ということになる。とまあ、一方的に説明して合意を取り付けるよりは、質疑応答で理解を得た上での合意であるので、まだ、良心的だという見方もできる。

しかし、ドキュメント・レビューの意義は、利害関係者や有識者が一同に会することにより、ドキュメントに書かれている内容が十分かどうかを多面的に評価し指摘することでフィードバックをかけ、プロジェクトの軌道修正を図ったり、プロジェクトの状態をチェックしたりする場である。

いくら時間をかけてQ&Aを行い、そこに書かれていることだけを100%理解したところで、書かれていない不足していることや書いてあることの矛盾やあいまいさなどが指摘されなければ、有効なフィードバックには、なり得ないのである。

もっとも、レビューの時であろうが事前であろうが、配布されたドキュメントを読んで、参加者が十分に理解ができないような内容となっており、質問を山ほどしなければならないようでは、指摘事項を洗い出す依然に、書き直したほうが良いかもしれない。

そのようなドキュメントをレビューに提示して、しかも、質疑応答によって利害関係者や有識者に内容を理解してもらおうなどという勘違いをしているのでは、貴重な時間のムダである。ドキュメントは、読んで分かるように書くのが第一原則である。その上でのレビューが有効に働くというものだ。

ドキュメント・レビューに対する、このような勘違いをしている主催者や参加者が多いプロジェクトでは、レビューの貴重な時間のほとんどをQ&Aに費やしてしまうため、事前にドキュメントを読んで理解してきた参加者には、とてつもなく退屈なレビューとなってしまう。また、参加者として召集された有識者も、指摘事項を提示する間もなく、質疑応答のやり取りを聞いているだけの退屈な時間を過ごさなければならない。

このような状態が続くとレビューへの参加者は、質問をしてドキュメントを理解することを主たる目的とする人ばかりが集まるようになり、多方面から有効な指摘事項を示し適切なフィードバックを与えてくれるような有識者は、徐々に集まらなくなってしまう。

また、ドキュメントの内容が分かりやすく、読めば分かるような内容であった場合、レビューに参加する人が少なくなるか、Q&Aはほとんどないので、結果的に説明者が一方的に説明する説明会か、セレモニーとなってしまうことになる。

 ・レビューは討議の場である

  形式的より、少しはマシなレビューですが、
  討議を始めると時間ばかりかかります。

  時間切れになれば、残りは形式的に済ませます。
  そして、討議に参加しないレビューアにとっては、
  ムダな時間です。

 ドキュメントの品質を高めるために内容をレビューするのであるから、討議するのは悪いことではないという勘違いもある。確かに、ドキュメントを前に問題点を発見したならば、その問題を解決するにはどうすればよいかを議論したくなるのも人情だろう。

この手の勘違いは、先のレビューを説明会や質疑応答の場であると勘違いしている自己中心的な参加者に比べれば、ベテランや有識者で面倒見の良いタイプや技術的にレベルが高く議論好きなタイプに多いので、そのこと自体、悪くは無いのだが、時間管理や他の参加者への影響と言う面で厄介である。

なぜなら、一つの指摘事項について、何が問題なのか、どうすれば改善されるのかを懇切丁寧に説明し、議論を始めるとドキュメント・レビューは、遅々として進まなくなる。

数十から数百ページもあるドキュメントの内容について、指摘事項の一つ一つに対して討議していたのでは、全体を一通りレビューし終わるには、とても1時間や2時間では終わらない。短くて数日、下手をすれば、1週間かかっても終わらないかもしれない。

参加者は、貴重な時間を使って、自分の成果物ではない他人のドキュメントを読解して、指摘事項を洗い出さなければならないので、ある意味でボランティアである。相互扶助の精神が無ければ、やってはいられないのだ。

もし、レビューの主催者や参加者の数人が、討議の場であると言うような勘違いをしていて、延々と長時間に渡る討議を始めるようなことが、何度も重なれば、他の参加者の足は自然に遠のいてしまうだろう。

「レビューに参加すると、いつも長時間の討議になって終わらず、時間延長や追加のレビューに付き合わされるので、自分の仕事をする時間が無くなってしまう。」このような雰囲気がプロジェクトに蔓延するようになると誰も積極的にレビューに参加したがらなくなる。

また、ドキュメントの作成担当者も、レビューで延々と議論を吹っかけられるので苦痛を感じるようになり、これまた一方的な説明会かセレモニーとして簡単に済ませてしまうようになる。

しかし、一方で無下に指摘事項に対する討議を抑制しようとすれば、ベテランや有識者である彼らの気分を害してそれ以降のレビューに積極的に参加してもらえなく可能性がある。これでは、ベテランや有識者が、親切心から有効な指摘をし、改善策を討議してくれるという良い面が裏目に出てしまい、折角の彼らの貴重なノウハウをレビューに活かすことができずに残念なことである。

このような勘違いによる発言や討議は、レビューを始めてからでは、なかなか制止するのも言い出しにくく軌道修正が難しいので、ずるずると討議に深入りしてしまうことが多い。そこで、事前にレビューの目的や進め方などを、主催者が説明して理解しておいてもらう必要がある。つまり、一回のレビューに要する時間は1から2時間程度とし、この時間内にできるだけ多くの指摘事項を洗い出すことに、参加者の意識を集中しなければならない。

指摘事項に対して、どのように改善するのかは、担当者が要求分析作業なり設計作業なりをやり直すことであり、そのために必要であれば有識者を集めて実施する「検討会」は別に考える必要がある。

このようにレビューは、ある程度の討議への踏み込みは許容するとしても、1回あたりの開催を短時間で、かつ極力、時間内で終了するように、うまく参加者の発言をコントロールして実施しないと、プロジェクトを通じて何度も開催するレビューに、なかなか貴重な時間を割いて参加してもらうことが難しくなる。また、組織にもレビューを気軽に行おうと言う雰囲気が定着しない。

もし、個別の内容について深く突っ込んだ討議をするようなレビューを実施するのであれば、例えば、次のような手順を踏むことをプロジェクト運営要領に規定して、第一回目のレビュー開催時に参加者へ説明し了解を得ておくのが良い。

まず、最初は個々の指摘事項に対する討議には踏み込まないようにして、一通りレビューを終え全ての指摘事項を洗い出す。その後に、指摘事項のリスク評価を行い、優先順位をつけてから、優先度の高いもの数点にテーマを絞ったレビュー(検討会)を、別途、開催することとする。その際には、討議の進行具合によってはレビューの開催時間が長時間に及ぶ可能性があることを事前に通知し、それでも参加しても良いという有志だけを招集して実施する。

こうすれば、ドキュメント・レビューの主たる目的である、より多くの指摘事項を洗い出し、早い段階でフィードバックをかけるということを決められた時間内で達成することができる。そして、個別の指摘事項に対するベテランや有識者のノウハウを十分に注入して、よりよい成果を得ることもできる。

 ・レビューは吊し上げの場である
  誤字脱字や文法上の間違いに始まり、
  ことごとく問題点を指摘されるのは苦痛です。

  それが常識と思い込んでいるので、
  形式的に済ませようとします。

 ドキュメント・レビューがなかなか定着しない、プロジェクト・メンバが積極的にやりたがらない理由のひとつに、この勘違いがある。もしくは、勘違いではなく、実際にそのような雰囲気になっていることがあるかもしれない。勘違いにしろ、そうでないにしろ、自分の作成したドキュメントに対して他人から批判を受けるのは、気持ちの良いものではない。

この「批判」を受けるというところに、ドキュメントのレビューを受ける側にもレビューをする側にも、大きな勘違いがある。レビューの意義は、批判を受けることではなく、適切なフィードバックを利害関係者や有識者から得て、より品質の高い成果を出すことである。

また、実際にレビューの場で、ドキュメントの作成者を批判したり糾弾したりして、それが、教育指導であると考えているような勘違いをしているベテランや有識者がいるかもしれない。確かに、批判もフィードバックの一つであるが、レビューでのフィードバックとは本質的に異なるものだ。

レビューは、ドキュメントの不足部分や矛盾点など、あくまでドキュメントに対しての指摘であり、ドキュメントの作成者に対しての考え方や人格的な面を批判するものではない。「罪を憎んで、人を憎まず」という諺があるように、ドキュメント・レビューでは、「ドキュメントの不備を憎んで、人を憎まず。」の精神が大切である。

また、指摘事項は、客観的な指摘を行うことが主体であり具体的な内容の不備を指摘するものではない。例えば、要求仕様書の内容で「xxx処理の記述は、入力と出力の関係があいまいであり、不明確である。」というような指摘の仕方をするものであり、記述のしかたが良いとか悪いとか、あるいは、xxx処理のし方が良くないとかいう指摘をするのではない。

良いとか悪いとは、極めて主観的なところであり、どのような処理方式が最適なのかは、一概には断定できるものではない。もし、そのような点について議論するのであれば、レビューの場では「代替案との比較検討が不十分である。」というような指摘に留めておき、別に検討会を開催して議論すべきである。このように指摘の内容が主観的に偏ったり、担当者の考え方や人格面などを否定したりするようなことにならないためには、あらかじめ用意したチェックリストに従って、レビューを進めるのが良い。

こういった事前準備も無く、参加者がそれぞれ勝手に各自の主観に基づいて、ドキュメントの記述内容に対して、重箱の隅をつつくような指摘事項や果ては「てにをは」など、文法的なところまで事細かに指摘されるようでは、レビューされるほうは、たまったものではない。特に公式のレビューで、多くの参加者がいるところで、そのような指摘を受ければ、自分の仕事の成果そのものを公然と批判されているような気分になり、ドキュメント・レビューをしたがらなくなるのも仕方はない。

また、そのような批判めいた指摘事項をいくらフィードバックされても、前向きな品質向上に繋がる指摘事項とはならないことが少なくない。ドキュメント・レビューとは、こういうものだと組織全体が勘違いしているようでは、前向きで効果的なレビューが、利害関係者の自主的な発動で適時に実施されることは少なくなる。どうしても、ドキュメント・レビューは、プロジェクト管理者が強制的に開催するもので、管理的な色合いが濃いものとなってしまうだろう。

さらに、この勘違いによる最も大きな弊害は、ドキュメント・レビューに提出するドキュメントをぎりぎりまで完成度を高めようと担当者がガンバリ過ぎることである。とにかく、レビューで指摘(批判)を受けたくない一心で、できるだけ完成度を高めようともがくのである。そのため、レビュー開催日が迫ってくると進捗率がとたんに悪くなる傾向がある。

先週まで予定通り70%、80%と進捗していたのに、レビューの数日前になると突如、91%、92%と遅々として進まなくなる。どうしたことかと聞いてみると、自己チェックをしており気になるところが、まだ完全になっていないと言う。挙句の果てには、もう少し、時間を取って完璧を目指したいので、レビューの開催を延期したいと言い出す始末だ。これでは、何のためのレビューか分からない。

完成度は、70%から80%でも良いので利害関係者や有識者のレビューを受けることで、フィードバックを得て、早めに軌道修正するというレビュー本来の目的を全く勘違いしているのだ。担当者が一人でいくらかんばって100%の完成度に仕上げたところで、レビューで指摘事項が出れば、それを盛り込むために手戻りが発生することは確実である。

そうなった場合、ぎりぎりまでレビューを引き伸ばしたり、大きな指摘事項が発見されたり場合は、スケジュールもコストも危険にさらされることになる。そのタスクが、クリティカル・パス上のものであった場合には、その担当者のガンバリ過ぎのためにプロジェクト全体が危機に直面することになりかねない。それで、品質がより高まればよいが、早めにレビューを受けて指摘事項を盛り込んだ場合と大差ない。

このように、組織全体がレビューに対して「吊し上げの場である」というような勘違いをしており、メンバが強迫観念を持っていると、早めにレビューを受けてフィードバックをもらい、手遅れにならないうちに軌道修正しようという意識が働きにくくなり、単なる説明会やセレモニーで終わらせようとするためレビュー本来の効果が薄れてしまう。

このような勘違いを組織に蔓延させないためには、先に述べたようにレビューでの指摘ポイントをあらかじめチェックリストなどにまとめ統制をかけておくことや指摘事項に関するマナーなどを周知することが重要である。

また、常日頃から利害関係者間のコミュニケーションを良好に保ち、相互に指摘し合うことでシナジ効果によって、より良い品質を確保するのだと言う相互扶助の精神と他人からの指摘事項を素直に、かつ真摯に受け止め自分の仕事の糧とできるような「大人の心」を養っておく必要がある。行き過ぎた成果主義のために、ドキュメント・レビューで誰も有効なフィードバックをしなくなったり、互いに足を引っ張り合ったりしてプロジェクトが破綻するようでは本末転倒である。


 自社のレビューが、以上の【常識的レビュー】に一つでもあてはまれば、
 レビューが有効に機能していない可能性があります。



 このような常識的レビューから脱却し、

 観点(目の付け所:視点・視座・視野)を変え、

 『超ドキュメントレビュー』を行うことで、
 『常識を超えた本物のレビュー』を行うことができます。

  五輪書 水之巻 目付けという事

 それは、本来のレビューの目的を享受し、
 プロジェクトを成功に導くレビューです。

 プロジェクトの成功とは、赤字プロジェクトの撲滅、
 そして、顧客や利害関係者の満足と付加価値の最大化です。


 そこにある成果物に書かれたことだけを見て、
 間違いや問題点の指摘だけに終始するのではなく、

 【書かれていないこと(行間)】まで読んで、
 将来のリスクを発見する=【想定外】を減らす レビューです。

 つまり、「1+1=2」をいくら見つめても”間違い”は発見できません。

 「1+1=3」の”間違い”なら誰でも直ぐに見つけられます。
 しかし、システム開発で品質問題となり、生産性低下、コスト超過、納期遅れ
 となるのは、「1+1」が「1+2や2+3」に変わってしまう不確実性に起因する
 リスクなのです。これを早期に発見することで最大200倍のコスト削減が可能です。

 過去の事例解析だけでは、将来のリスクを検知し、
 対処することはできません。

 歴史学者が、必ずしも明日の世界情勢を予測できる
 わけではありません。

 アナリストは、そのための訓練(脳トレ)をしている
 からこそ、一般人よりも明日を読むことができるのです。

 【リスク指向】超ドキュメントレビューでは、そのような訓練もします。

 リスクが発見できれば、それを未然に防止でき、
 発生しても損失を最小に抑制できます。

 【リスク指向】超ドキュメントレビューにより、”見えないものを観る”訓練が
 進めば、メンバのリスクに対する感度が上がります。

 その結果、類似の失敗を繰り返すことが少なくなり、
 未経験の分野であっても、プロジェクトのリスクを低減することができます。

 そして、レビューに組織的に取り組むことで、コミュニケーション活性化や人材育成など
 組織力強化が図られます。

 具体的な例を見てみましょう。


 「重要な組立品の構成部品については、
  不良率が0.05%以下の場合に受入検収を合格とする。」

 このように要求仕様が文書化されていたとしましょう。

 常識的なレビューでは、

  →誤字脱字や数値等の間違いや矛盾はありません。


 実は、この要求仕様は、”組立品が”重要品目である場合に、
 その構成部品については、という意味であったのです。

 ところが、あるSEは、”構成部品が”重要であると
 理解して設計しました。

 その結果、システムは、どのような組立品であっても、
 重要な構成部品については、不良率が0.05%以下
 でなければ、受入検収が合格しないという問題が発生
 したのです。

 【リスク指向】超ドキュメントレビューなら、

  問題とは言い切れない表記上のリスク→後工程への悪影響
  →品質、プロジェクト品質(コミュニケーション、コスト、
   納期等)への悪影響

 として、リストアップできます。

 そして、リスク低減策として次のように文章を
 改善することができます。

 「重要な組立品について、その構成部品は、
  不良率が0.05%以下の場合に受入検収を合格とする。」


 いかがですか。


 もう一度、確認します。
 ここまで、読んでもまだ、

 レビューは時間の無駄!

 プロジェクトは何が起こるかわからないもの。

 要求変更は、あってあたりまえ、

 問題が起きた時に対処すればいい!

 そもそも、70%が失敗しているのが、この世界の常識。


 もし、こんな風に思っていて、レビューに失望しているなら、
 ここから先は、読まないで下さい。

 ほんとうに時間のムダです。

 これからも出たとこ勝負、突撃精神で、
 切った張ったの、火消しに努めて下さい。
 そして、火消し術を身につけていくのも
 悪いことではありません。

 悪いことではありませんが、孫子はそんな戦い方を戒めています。

  孫子の兵法 謀攻篇 百戦百勝は善の善なるものに非(あら)ざるなり。

 でも、ほんの少しでも希望を捨てていないなら、
 微かな光を消さないでいるなら、
 ほんとうに、プロジェクトを成功に導きたいなら

 『超ドキュメントレビュー』
 『常識を超えた本物のレビュー』

 その具体的な方法について解説した書籍があります。

 常識的なソフトウェア工学関連の書籍では、
 数行〜数頁しか書かれていないレビューについて、
 非常識に、徹底的に、書きました。

 書籍
 ------------------------------------------------------- 
 | ★ドキュメント・レビュー!!              
 |  要求仕様書・設計書のレビュー実践とチェックポイント 
 |                            
 |  Amazonで購入できます。             
 ------------------------------------------------------- 


 さらに、実際に要求仕様書、見積書、設計書を使用して、
 演習を行い、『超ドキュメントレビュー・常識を超えた本物のレビュー』
 を習得し、生産性向上・コスト削減を実現できる社内研修があります。



企業システム戦略を成功させる!【リスク指向】ドキュメント・レビュー実践法


これは個人的な自己啓発ではなく、会社の施策として取組み、プロジェクトの全員が
超ドキュメントレビューの観点を得なければ、実質的に生産性向上・コスト削減
を実現することは難しいので、社内研修がお奨めです。

研修費用は30名で50万円ほどです。研修時間は1日で充分です。

研修の効果は、リスク抽出件数や手戻りコストで明確に測定可能です。

実際、研修では前後にレビュー演習をして、指摘事項の質・量を測定してもらいますが、 これまで、一切の変化が得られなかったという受講者はゼロです。

1回のプロジェクトで最大200倍のコスト削減が可能です。ちょっとしたプロジェクトなら 直ぐに1000万円くらいになります。その最初にプロジェクト全員が50万円で研修を受け、
その結果、重大なリスクを回避することができれば容易に研修費は回収可能です。

例えば、マスターデータベースの主キーに設計変更が発生し、そのマスターを参照しているプログラムが100本くらいあれば、200時間くらいの手戻り作業が発生します。これを1時間のレビューでリスク抽出し、事前対策できれば、200分の1のコストで済みます。

ですので、決して高い教育投資ではないと思います。

 『企業システム戦略』実践コンサルティング

 お問い合せは、こちらのフォームからお願いします。

本書の一部を紹介しましょう。

まず、レビューをいつやるかですが、非常識にリスクを洗い出すには、リスクが事故になる前に行わなければ、意味がありません。常識的にセレモニーで終わらせるなら、ぎりぎりでもよいでしょう。しかし、リスクというからないは、発見したリスクを回避できるだけの時間的余裕を残しておかなければならないのです。

登り始めの3合目

まず、最初のレビュー時期は、作業が1/3ほど終了したところにある。ここでは、これから登ろうとする山を間違えていないか、登る経路は正しい方向を向いているかを確認し、評価する。このように登り始めのレビューでは、基本的な方向性を間違えていないか早めにチェックして、もし間違っていれば軌道修正をすることが目的である。

これまでも、何度か述べたように目的やスコープを大きく逸脱してしまうプロジェクトが思っている以上に少なくない。このように最初の方向性をチェックしないままで、最後のレビューで気がついてみたところで手遅れである。

これまで登ってきた山を一度降りて、再び別の山へ登りなおすには、かなりの労力と精神力が必要だ。例え、リーダだけが気力を振り絞ったところで、メンバ全員の士気を取り戻すことは、恐らく困難であろう。

ところで、この3合目かどうかを計るためには、山全体が見えていなければならない。その上で、どこまで登れば3合目かが分かるのである。プロジェクトで言えば、山全体というのがスコープ記述書であり、成果物記述書であり、WBSである。これらを、しっかりと定義しておかなければ、どこまで登ったのかさえも分からずに気がついたら、とんでもない別の山に登っていたと言うことにもなりかねない。

そして、どのような開発プロセスであっても、WBSはマクロからミクロへと展開されている必要がある。つまり、3合目ほど登ったところで全体の方向性が見えてくるような作業の進め方をしなければ、この時点でのレビューを実施する意義が薄れてしまう。

例えば、データ中心指向プロセスによる要求分析工程であれば、システム化対象業務全体のデータ・フロー・ダイヤグラムと主要なエンティティ関連図やエンティティ識別子が明確になったところあたりである。

オブジェクト指向プロセスでの要求分析工程であれば、全ての対象とする業務のユースケースが明確になり、主要なアクターやシナリオが定義されたあたりであろうか。これくらいの情報があれば、分析対象としている業務やユースケースが、ビジネス目的を達成するために必要十分なスコープとなっているかなどをレビューし、評価することができる。

逆に、こういった全体のスコープを明確化するところから作業せずに、いきなり詳細なクラス図まで落として1/3まで作業を進めたとしたら、「木を見て、森を見ず」の諺どおり、方向性が正しいのかどうかをレビューし評価することが難しい。

また、設計や実装などを小さい単位で繰返すような開発プロセスを採用していたとしても、全体を明らかにせず、いきなり細部の実装を反復しても整合性の取れた良いシステムには成り得ないであろう。絵を描くときと同じで、いきなり部分から細かく書き出しても、全体のバランスが悪く、画用紙からはみ出したり、片隅に偏ったりするであろう。

まず、全体のデザインを大まかに行うのが普通である。システム構築において全体のデザインとは、アーキテクチャのデザインである。細部のコードを実装する前に、必ず、アーキテクチャをデザインし、ドキュメント・レビューによって方向性の妥当性を評価しなければならない。統一プロセスなども、「反復して開発すべし」という実践原則を支えるのは、ユースケース駆動、アーキテクチャ駆動、リスク駆動という考え方である。

つまり、闇雲に片っ端から反復開発するのではなく、まず、ユースケースを全て洗い出して「方向付け」を行い、そのユースケースの中からアーキテクチャ上で、リスクの高いものを選んで、「推敲」を行いアーキテクチャのベースラインを決定する。それから、他のユースケースを反復して開発するのである。

この場合、「推敲」が終了して、アーキテクチャのベースラインが明らかになったところが3合目であろう。 このように、3合目にあたるところを、コストでも1/3、進捗でも1/3、出来高でも1/3というようにバランス良く分解されたWBSが理想である。

このバランスが悪いとタスクが1/3終了したところを3合目だとしてレビューしても、すでにコストは1/2を消費しているというのでは、手戻りが発生した場合の損失コストが大きくなる。また、予算を1/3消費したところを3合目としても、出来高が1/3でなければ作業の方向性が見えるところまで行っていない。

従って、WBSの分解と定義は非常に重要である。これには、成果物を適切に分解し、各成果物の出来高価値を正確に見積り、予算配分しておく必要がある。さらに、最初に手がける1/3のタスクは、全体の方向性を決定付けるような重要、かつ、リスクの高いものを選択しなければならない。同じ3合目であっても、全体の方向性には対して影響の無いリスクの低いタスクや成果物では、やはり、ここでレビューを実施する意義が薄れてしまうのである。

しかし、レビューをすることで、全体を明らかにしないまま、しかも、優先度の低い作業ばかり、はじめに手がけていると言う現場・現実を知るという意味での効果は大きい。このような作業の進め方では、その後のスコープ管理、進捗管理やコスト管理、EVMなどが有効に機能しなくなるからである。

本来、ドキュメント・レビューは、成果物に対して行うレビューであるが、このようにドキュメント自体の方向性を評価することが有効にできないとしても、作業の進め方そのものに問題があるかどうかを早めに知ることができるという点では、プロジェクト管理のツールとして極めて有効である。

何も知らずに担当者任せにして、全く方向のずれた作業を、しかも、細部からいきなり実装を反復するような進め方でやってきて、最終レビューで方向性が、ずれているというようなことが指摘されたならば、プロジェクトは一から出直すしか手はなくなってしまう。当然、コストも進捗も2倍以上、品質も劣化する。

なお、この時点でのレビューに裂く時間は、それほど多くなくて良い。目的は、方向性の妥当性を確認し、評価するだけであるから、この時点で時間をかけ細部について指摘事項を洗い出す必要はないであろう。また、時間をかけようにも、まだ3合目であるから、時間のかけようが無い。

頂上間近の7合目

こちらのドキュメント・レビューは、いよいよ本番である。作業タスクもほぼ終わり、成果物であるドキュメントも完成しているころである。この7合目というのは、ドキュメント・レビューが終了し、レビュー結果を成果物に反映し責任者の承認を得て、正式にリリースするところを10合目としてのことである。従って、担当者が、ほぼドキュメントを完成する時点でもある。

ここで、時々勘違いしていることは、7合目と言うのは、担当者がドキュメントを70%出来高を計上した時点であるというものだ。つまり、担当者がドキュメントを100%完成したところを10合目だと考えているわけである。それが、その工程の完成予定日だと。ここには、担当者が完成した後のレビューや承認過程での手戻りは、一切、考慮されていない。

もし、1日でも手戻りが入れば、即、完成予定日を遅れてしまうのだが、計画では楽観的に考えているのだ。実際、このように完成予定日を、「担当者がドキュメントを完成する日である」と勘違いしているプロジェクトでは、レビューによる手戻りや再レビュー、承認過程等において、ほぼ予定を遅れているのである。

もしくは、レビューや承認行為が形骸化して「セレモニー」や「めくらサイン」となっている場合には、その工程では遅れは生じないかもしれない。しかし、そのつけは、最後に大きくなって回って来ることになる。

さて、そのようなことにならないように、ここでの7合目とは、レビューや承認過程での指摘による手戻りは、必ず発生するものと言う前提に立ち、最初に定義した時点、すなわち、担当者がほぼドキュメントを完成する時点であるとすれば、レビュー結果の反映や承認過程での多少の手戻りは吸収することができ、完成予定日を遅れるリスクは少なくなる。

ここで、必要となるのが危険予知能力だ。もし、ドキュメント・レビューを実施した場合、指摘事項が多く発見され、手戻り期間が長くなるようであれば、7合目というのは、完成予定日に対して、かなり前の時点になる。逆に、ドキュメントの完成度が高く、手戻りが発生しないようであれば、承認期間の日数程度を完成予定日から逆算した時点を7合目とすればよい。

従って、この7合目というのは、WBS上の70%が終了した時点でもなく、出来高を70%計上した時でもない。ドキュメントの難易度や担当者のスキルなどによって、手戻りのリスクを予測し、その期間が吸収できるような時点を動的に選択しなければならない。

そこで、3合目に実施するレビューが重要な役割を果たすことになる。3合目のレビューによって、ドキュメントの方向性が正しいことを評価すると共に、担当者のスキルやリスクを評価することができるからである。それにより、最も適した7合目の時点を選択することが可能となる。

もし、あまりにもリスクが高いようであれば、5合目、6合目と中間レビューを追加して設定することでリスクを緩和することも可能となる。この3合目のドキュメント・レビューによって、現物・現場・現実という3現主義を実践しないままで、適切な7合目のレビュー時期を選定することは、ほぼ不可能であろう。

そうなると、例えば、出来高が70%計上された時点で、レビューを実施するといように固定的な選択をせざるを得なくなる。そこで、もし、大幅な手戻りが発生するような指摘事項があった場合、スケジュールの遅れは、必至である。逆に手戻りの発生リスクがほとんど無かった場合には、ドキュメントの完成度が70%であるので、残り30%がレビュー漏れとなり、後工程へリスクを持ち越す恐れがある。

このような場合は、レビュー時期は、ぎりぎりまで引きつけてから完成予定日の直前にレビューを行うほうが効率よく、レビュー漏れも少なくなる。もう一度、確認しておくが、7合目と言うのは、担当者がほぼドキュメントを完成した時点であり、70%完成した時点ではない。そして、担当者がほぼドキュメントを完成させてレビューを実施する時点は、完成予定日からリスク強度を加味した手戻り日数を逆算した時点である。

リスクが低いのならば、完成予定日の2〜3日前までに担当者は、ほぼドキュメントを完成させ、レビューを受ければよい。しかし、リスクが高いのであるならば、遅くとも1週間前には、ほぼドキュメントを完成させ、レビューを受けなければならないのである。リスクが高いにもかかわらず、1週間前までにドキュメントが完成せず、レビュー日程が遅れるようならば、その時点で、すでに完成予定日を遅れるリスクが発生していると判断すべきである。

幸いにも、完成予定日の1週間前にレビューを実施し、指摘事項が無く手戻りが発生しなければ、1週間を前倒しできることになり、後々のために「時間を貯金」できる。プロジェクトを成功させるには、予定どおりに作業をこなしていくだけでなく、可能な限り作業を前倒しし、不測の事態に備えて時間を貯金しバッファ(安全余裕)を確保しておくのが良い。

このように7合目のレビュー時期の設定は、プロジェクト管理の中で、非常に重要なポイントである。担当者がほぼドキュメントを完成させ、7合目のレビューを実施する日を、完成予定日の何日前に設定するかを適切に判断するには、3合目でのレビューを実施し、スコープや要件などの認識的リスク、アーキテクチャなどの技術的リスク、担当者のスキルなど人的リスク等々の多面的なリスク評価を行うことが必要である。

 書籍
 ------------------------------------------------------- 
 | ★ドキュメント・レビュー!!              
 |  要求仕様書・設計書のレビュー実践とチェックポイント 
 |                            
 |  Amazonで購入できます。             
 ------------------------------------------------------- 


 さらに、実際に要求仕様書、見積書、設計書を使用して、
 演習を行い、『超ドキュメントレビュー・常識を超えた本物のレビュー』
 を習得し、生産性向上・コスト削減を実現できる社内研修があります。



企業システム戦略を成功させる!【リスク指向】ドキュメント・レビュー実践法


これは個人的な自己啓発ではなく、会社の施策として取組み、プロジェクトの全員が
超ドキュメントレビューの観点を得なければ、実質的に生産性向上・コスト削減
を実現することは難しいので、社内研修がお奨めです。

研修費用は30名で50万円ほどです。研修時間は1日で充分です。

研修の効果は、リスク抽出件数や手戻りコストで明確に測定可能です。

実際、研修では前後にレビュー演習をして、指摘事項の質・量を測定してもらいますが、 これまで、一切の変化が得られなかったという受講者はゼロです。

1回のプロジェクトで最大200倍のコスト削減が可能です。ちょっとしたプロジェクトなら 直ぐに1000万円くらいになります。その最初にプロジェクト全員が50万円で研修を受け、
その結果、重大なリスクを回避することができれば容易に研修費は回収可能です。

例えば、マスターデータベースの主キーに設計変更が発生し、そのマスターを参照しているプログラムが100本くらいあれば、200時間くらいの手戻り作業が発生します。これを1時間のレビューでリスク抽出し、事前対策できれば、200分の1のコストで済みます。

ですので、決して高い教育投資ではないと思います。

 そして、レビューに組織的に取り組むことで、コミュニケーション活性化や人材育成など
 組織力強化が図られます。


 『企業システム戦略』実践コンサルティング

 お問い合せは、こちらのフォームからお願いします。

そして、【リスク指向】超ドキュメントレビューでは、品質・コスト・納期といった常識的な分野だけのリスク発見だけでなく、プロジェクトの成否に大きな影響を与えると言われている、組織管理やコミュニケーションにおけるリスクなども発見することができます。つまり、非常識なドキュメント・レビューは、ドキュメント上だけのリスク発見に留まらないのです。

Human Resource(組織管理)

組織管理とあるが、これはHuman Resource、つまり、人的資源に関する総合的なマネジメントである。PMBOKでは、プロジェクト管理としてQCDを満足するためには、QCDに着目するだけのマネジメントでは不足で、人的資源等にも配慮したマネジメントが必要であるとしている。

プロセスは、組織計画(計画)、要員の調達/確保(計画)、チーム結成/育成(実行)がある。組織計画(計画)では、プロジェクトインタフェース、必要要員の予測、制約情報を入力とし、組織編制標準、人事慣行、組織理論、ステークホルダ要求項目の検討をツールと実践技法として使用し、責任分担表、配員計画書、組織編成表などを出力する。

ここで、効果的な組織編成や責任分担、配員計画を行うには、入力に成果物記述書や成果物に対する識者の経験や知識も必要となる。これから作成しようとする成果物に要求されるQCDを正しく認識し、それに適した組織計画を立てなければ、その組織計画は単なるペーパ上の組織図であり、なんら実効性のある組織にはならない。

組織理論の中で「組織は戦略に従う」という有名な格言があるが、戦略が明確になれば、自然と組織は、その戦略を実行するのに適した形をとるようになるということである。従って、プロジェクトを遂行する上での戦略をしっかりと固める必要がある。そのためにも、成果物をしっかりとレビューしなければならない。

プロジェクトの最終アウトプットである成果物(稼動可能なシステム)と、そこに至る過程で生成すべき成果物(ドキュメント類)を明確にイメージすることで、目標とすべきQCDが定まり、実行すべきタスクやアクティビティ及びリスクなどが具体的になる。そうすると、そのタスクやアクティビティを実行する要員やプロセスも明確になってくる。

これを、逆からたどると「人材と学習」→「プロセス」→「顧客(QCD)」→「財務」といったバランススコアカードの戦略シナリオとなる。 バランススコアカードは、ロバート・S・キャプラン氏とデビッド・P・ノートン氏によって提唱された経営管理手法である。彼らは、「戦略とは、シナリオの仮説である」という格言を残している。

プロジェクトの目的から成果物の目標とすべきQCD、実行するプロセス、必要な人材と組織へとブレークダウンし、今度は、逆に、人材と組織が学習して向上すれば、プロセスが高度化し、それによりQCDが達成でき、顧客満足が得られ、最終的にプロジェクトの財務的業績(売上げ・利益)が確保されるというようにシナリオの仮説を立てる、これが、戦略である。

シナリオの仮説が無かったり、単なる数値目標だけをかかげたりするのは、戦略ではない。戦略無きところには、有効な組織も生まれ無い。従って、組織管理や人材マネジメントを、現地・現物・現実ではなく、単なる頭数やデータだけ行うべきではない。そのような組織計画で、プロジェクトのQCDをどのように測定し管理しようにも、空転するだけである。

この成果物及びそのリスクを正しく認識し、適材適所に組織計画を立てるために必要な識者の経験や知識は、ドキュメント・レビューによって養われる。さらに、ここで作成した組織計画は、その後も状況に応じて適切に維持されなければならないが、どのような要員スキルが不足し、どのように組織編成を変えていくのか、あるいは、スキルではなく量の問題なのかなど、ドキュメント・レビューを通じて、成果物の作成状況を正しく認識し、それに応じて適応していかなければならない。

3現主義を基礎とせず単なるデータのみを見て、人材を頭数だけの消費材のように考え、安易に足したり引いたりしても有効な人材マジメントにはならず、組織は破綻するだろう。

次に、組織計画の出力である配員計画書、配員プールの要求記述書を入力として、要員の調達/確保(計画)を行い、プロジェクト遂行要員、プロジェクトチーム名簿を出力する。ここでのツールと実践技法として、配員折衝、先行配員、要員調達などを行うにも、現物であるドキュメントなどの成果物を頭に置いた上でなければ、有能な人材を調達することは難しい。

なぜ、その人材を必要とするのかは、要求される成果物を念頭にプロジェクトの作業分解やタスク、特性や制約事項、リスクなどを具体的にして折衝しなければ、単に「システム設計ができる人を何人」とかでは、いざ実行段階になってプロジェクトとのミスマッチが発生する。

これでは、要員に良い影響を与えず士気も上がらないため、結果的にプロジェクトのQCDを達成することが難しくなる。まして、プロジェクトが始まってから、ミスマッチを解消するために要員を途中で頻繁に入れ替えるようなことが発生すれば、人材マネジメントは確実に破綻してしまう。すなわち、プロジェクトの崩壊である。

いよいよ実行段階では、組織計画や要員の調達/確保(計画)の出力である、プロジェクト遂行要員、プロジェクト計画書、配員計画書、進捗報告書、外部関係者のアドバイスを入力として、チーム結成/育成(実行)を実施し、業務遂行能力の向上、業務評価への基礎情報などを出力する。

ここでのツールと実践技法として、チーム育成活動、成果報酬・表彰規定、同一場所での執務、教育訓練などが使用される。このチーム育成活動を、適切に行い有効なものとするのにも、過去のドキュメント・レビューからのフィードバックによる経験や知識が必要となる。そして、プロジェクト実行中も状況に応じたチーム育成活動を継続していかなければならない。

その時にも、ドキュメント・レビューからのフィードバックが有効な入力となる。要員の一人一人が、常に結果を評価し、そこからのフィードバックを受け入れ、学習し成長し続ける組織「学習する組織」を構築するのにもドキュメント・レビューは有効である。

プロジェクト管理者に言われなくても、また、プロジェクトで規定された公式レビューだけに限らず、要員が自主的に、非公式/公式のドキュメントを、非公式/公式に、いつでも、どこでもレビューしフィードバックから学び成長するような組織が構築されたならば、プロジェクトは成功に大きく舵をきることができるにちがいない。

このような3現主義に基づくチーム育成活動を主体とした業務遂行能力の向上を図らずに、成果報酬や表彰規定、同一場所での執務、(強制的な)教育訓練を行い、ただ業績評価への基礎情報を収集するようなことでは、これまた組織は硬直したものとなり、躍動感溢れるダイナミックな組織管理が難しくなる。

それは、チーム結成/育成といったプロセスの実施が、要員の能力を120%引き出すどころか、低下させることになりかねない。これは、先の「組織は戦略に従う」という格言とは逆説的になる「戦略は組織に従う」という格言が示すように、硬直化した組織のために有効な戦略がとれなくなることを意味する。成果報酬や組織統制は、あくまで補助的なものとして位置づけるべきである。

要員は、組織管理や人材マネジメントが、ドキュメントなどの成果物を基に3現主義で行われているのか、それとも、単にデータや評価指標だけで官僚的に行われているのかに対して、実に敏感である。もし、自分たちが後者のタイプのマネジメントを受けていると感じたならば、当然、士気やモチベーションは低下し、プロジェクトの成功は難しくなる。

人材マネジメントとは、単に要員のスキルや頭数、組織編成を扱うのではなく、要員一人一人の士気やモチベーションまでを扱うのだと言うことを忘れてはならない。

G.M.ワインバーグ氏は、著書「スーパー・エンジニアへの道−技術リーダシップの人間学」の中で、リーダとは人を扱う仕事であり、QCDが怪しくなった時には、とにかく「人」を最優先にしなければならない、そうしなければ、決して仕事が終わらないからだと言っている。また、人を犠牲にして、QCDを追求すべき仕事など世の中に存在しないとも言っている。

プロジェクト管理の最終目的は、QCDの達成であっても、人材マネジメントは決して予備的なマメジメントではなく、これに失敗すれば、いかなるQCDに対するマネジメントも意味を成さなくなるほど重要なものと認識すべきである。そのような認識に立てば、決して、データや間接情報だけに頼ったマネジメントをすべきでなく、しっかりとドキュメント・レビューを通じた、3現主義に基づくマネジメントを展開すべきなのである。

Communication(コミュニケーション管理)

コミュニケーション管理は、プロジェクトにおける利害関係者間の情報伝達の総合的なマネジメントであり、公式な報告や連絡・会議等の他に非公式なあらゆる情報交換も含まれる。なお、ここでいう情報交換には、意思や感情なども含めた人間同士の相互作用まで含まれる。日本語では「管理」と訳されているが、本来、コミュニケーションは、管理というイメージとはそぐわないものである。英語のままのマネジメントというのが、しっくりする。

このコミュニケーションが、プロジェクトのQCDに及ぼす影響も計り知れないものがある。プロジェクトが失敗する原因としては、目的や要求に起因するものが多いが、それら問題の原因を掘り下げていくと必ずコミュニケーションの問題に行き当たる。業務やシステム(特にソフトウェア)というもの自体が、ハードウェアのように現物を前にして議論し難く、アイデアからソースコードに至るまで、全てが言語活動を中心としたコミュニケーション活動であることは、前述したとおりである。

開発段階で、どのような中間成果物を作るかによらず、プロジェクトの目的を伝え、要求を伝え、設計を伝え、ソースコードにするのである。この伝言を口頭だけで成し遂げるのは、ほとんど不可能であり、多かれ少なかれ成果物として、ドキュメントを作成することとなる。コミュニケーションの状況が顕著に現れるのが、このドキュメントなのである。

従って、公式/非公式を問わずドキュメント・レビュー無くして、コミュニケーションをマネジメントすることは不可能である。極論すれば、適切なタイミングでドキュメント・レビューを実施し、上流工程から伝えられた内容(入力)を、どのように自工程が理解し作業(変換)したのかという結果(出力)を、ドキュメントを通じて利害関係者にフィードバックしていないというのであれば、そのプロジェクトにはコミュニケーションが存在しないといっても過言ではない。

コミュニケーションの乏しい組織が、学習する組織になれる可能性は少ない。このように「風通し」が悪く、成長の無い組織では、発生する種々の問題(ノイズ)に、相互作用を及ぼしながら相乗効果や相互扶助により対処しながらプロジェクトを成功裡に治めることは困難である。 このコミュニケーション管理には、コミュニケーション計画(計画)、情報の配付(実行)、進捗管理(管理)、プロジェクト完了手続(終結)の各プロセスが定義されている。

コミュニケーション計画(計画)では、コミュニケーションの要求事項、制約条件、仮定条件などを入力とし、ステークホルダ分析をツールと実践技法として、コミュニケーション管理計画を出力する。ここで、ステークホルダ分析というのは、全ての利害関係者を正しく認識し、伝達漏れの無いようにすることと、利害関係者の性格や特徴を考慮して、最適なコミュニケーション方法、ツール、時期、頻度などを選択することである。

このように規定されてはいるが、実際にどうすれば良いかということが具体的に書かれていないのがPMBOKである。そこで、プロジェクトの初期段階では、プロジェクト計画書やプロジェクト憲章、プロジェクト成果物記述書などに対してドキュメント・レビューを実施するのも一つの手段である。

このような初期段階での、プロジェクトに対する重要な入力をレビューするという場に、どのような利害関係者が参加し、どのような発言をするのか、どのような姿勢を示すのかなどを、ドキュメントをレビューしながら、人間ウォチングしてみれば良い。きっと、利害関係者のさまざまな思惑や性格、特徴などが顔を出すことだろう。

このように、現場での顔を合わせてのコミュニケーションには、言語によるコミュニケーションだけでなく、非言語(ノン・バーバル)のコミュニケーションを図ることができる。ある調査によれば、コミュニケーションの70%が、ノン・バーバルなものであるという結果も出ている。コミュニケーションを、報告書や電子メールだけに頼らず、現物のドキュメントを目の前にしたレビューという場を通じて、ノン・バーバルなコミュニケーションをも図るようにすべきである。

プロジェクトの実行中での、情報の配付(実行)プロセスでは、作業結果、コミュニケーション管理計画などを入力とし、コミュニケーションスキル、情報検索システム、情報配付システムをツールと実践技法とし、プロジェクト記録、プロジェクト報告書、プレゼンテーションなどを出力する。

ここでいう、作業結果とはドキュメントなどの成果物であり、コミュニケーションスキルとは、ドキュメント・レビューなどで発揮されるものである。そして、レビューの結果を報告書やプレゼンなどでフィードバックするのである。「言った、言わない、聞いていない」の類は、このコミュニケーションの実行プロセスが有効に機能していないことが多い。

この問題の単純な解決策は、とにかく記録し文書化することである。また、電子メールなどの配布ツールだけに頼らず、対面式のアナログ・コミュニケーションを適度に持ち、情報や意図が確実に伝わっているかフィードバックを得ることである。さまざまな情報を入力し、自分の中で理解し変換し、また、他へ出力すると言うコミュニケーションスキルは、情報リテラシとも言われる。

日本では古くから、「読み、書き、そろばん」と言って、情報処理の基本的能力のことである。ただし、読むと言うのは、単にドキュメントやデータを読むだけではなく、相手の気持ちや場の雰囲気も読めなければならない。ドキュメント・レビューでは、成果物上の不備を指摘したり、されたりする。

これを子供の喧嘩にならずに、大人らしく、厳しくも親愛なる態度で指摘し、また、指摘されたならば、相互研鑽による成長の場、プロジェクトを成功させるためにフィードバックを得る場として真摯に受け入れる必要がある。ドキュメント・レビューへの参加者には、高いコミュニケーションスキルが要求されるのである。

このコミュニケーションの状況をマネジメントする進捗管理(管理)プロセスでは、プロジェクト計画書、作業結果、その他プロジェクト記録を入力とし、進捗の検討会議、差異分析、傾向分析、アーンドバリュー分析、情報配付ツールなどをツールと実践技法として使用し、進捗報告書、変更要求書を出力する。

ここでも、重要な入力は作業結果、すなわちドキュメントなどの成果物である。そして、ドキュメント・レビューを行うことで、進捗会議や各種分析の裏づけをとることができる。逆に、ドキュメント・レビューを実施せずに、進捗会議や分析を行っても、コミュニケーションの状況を本当に知ることは難しい。

にもかかわらず、進捗会議での報告や分析結果だけから、コミュニケーションをマネジメントできていると勘違いするのは、非常に危険である。ドキュメント・レビューに参加し、プロジェクトの目的や要求が、しっかり利害関係者で共有されているのか、その結果が、適切に成果物であるドキュメントに反映されているのかなどを自らの目で確認すると共に、レビューに参加している利害関係者の発言や態度などからコミュニケーションの状況を計ることが重要である。

上流工程でのドキュメント・レビューで、プロジェクトの目的や基本的な要求に対する理解不足などが原因となる指摘事項が多かったり、レビューの場で意見対立などしたりする場合には、コミュニケーション状態が良好であるとは言えない。そのような状況を上流工程で早めに知ることができれば、もう一度、目的や基本要件の説明を顧客やプロジェクト・オーナにしてもらい、利害関係者による共有の一致を図ることができ、プロジェクトが失敗に向かって突き進むのを回避することができるかもしれないのである。

あるいは、レビューの場で誰も積極的に発言しないとか、逆にミスを厳しく指摘し合うような状況であれば、要員間のコミュニケーションがうまく行っていない予兆であり、組織編成を再考したり、コミュニケーションを促進するための親睦会を設けたりすることも必要であろう。 このようにドキュメント・レビューは、ドキュメントの完成度や理解度からはもちろん、レビュー参加者の言動からも、コミュニケーションに関する有用なフィードバックを得ることができるのである。

そして、特に公式レビューよりも、非公式なレビューからのフィードバックがより有効であることが多い。そもそも、要員同士が自発的かつ頻繁に非公式なレビューを実施して、互いの情報交換を深め、フィードバックから学習し相互研鑽を図って成長しているような組織では、コミュニケーションの問題は皆無であろう。

逆に管理者がレビューを強制しなければ、誰もレビューをしようとしない組織では、コミュニケーションが良好に機能しているとは考え難い。かなりの個人主義・無関心・無責任が横行しているか、あるいは、レビューで他人を批判し、批判を受けるのは心が痛むなどという、未成熟でプロ意識に欠ける、病んだ組織ではないだろうか。

そして、プロジェクト完了手続(終結)プロセスでは、進捗測定書類、プロジェクト成果物、その他のプロジェクト記録を入力とし、進捗報告のツールと技法、プロジェクト報告書、プレゼンテーションをツールと実践技法として、プロジェクト完成記録、プロジェクト完了教訓を利害関係者に対して出力する。

最後のプロジェクト報告会議で、列席者が笑っているか、顔を歪めているかは、それまでの全てのドキュメント・レビューの縮図である。ドキュメント・レビューを全く行わないにもかかわらず、コミュニケーションを良好に保ち、最後に笑えるようなプロジェクトがあるならば、それは奇跡であろう。それでも奇跡が起こるのを待つのなら、プロジェクトをマネジメントする必要性は何も無い。

本書では、このような【リスク指向】超ドキュメントレビュー・常識を超えた本物のレビューを実践するために、特にプロジェクトの成否を分ける重要な上流工程のドキュメント・レビューに使用するチェックリストを収録しています。

ドキュメント・レビュー40のチェックリスト

 書籍
 ------------------------------------------------------- 
 | ★ドキュメント・レビュー!!              
 |  要求仕様書・設計書のレビュー実践とチェックポイント 
 |                            
 |  Amazonで購入できます。             
 ------------------------------------------------------- 


 さらに、実際に要求仕様書、見積書、設計書を使用して、
 演習を行い、『超ドキュメントレビュー・常識を超えた本物のレビュー』
 を習得し、生産性向上・コスト削減を実現できる社内研修があります。



企業システム戦略を成功させる!【リスク指向】ドキュメント・レビュー実践法


これは個人的な自己啓発ではなく、会社の施策として取組み、プロジェクトの全員が
超ドキュメントレビューの観点を得なければ、実質的に生産性向上・コスト削減
を実現することは難しいので、社内研修がお奨めです。

研修費用は30名で50万円ほどです。研修時間は1日で充分です。

研修の効果は、リスク抽出件数や手戻りコストで明確に測定可能です。

実際、研修では前後にレビュー演習をして、指摘事項の質・量を測定してもらいますが、 これまで、一切の変化が得られなかったという受講者はゼロです。

1回のプロジェクトで最大200倍のコスト削減が可能です。ちょっとしたプロジェクトなら 直ぐに1000万円くらいになります。その最初にプロジェクト全員が50万円で研修を受け、
その結果、重大なリスクを回避することができれば容易に研修費は回収可能です。

例えば、マスターデータベースの主キーに設計変更が発生し、そのマスターを参照しているプログラムが100本くらいあれば、200時間くらいの手戻り作業が発生します。これを1時間のレビューでリスク抽出し、事前対策できれば、200分の1のコストで済みます。

ですので、決して高い教育投資ではないと思います。

 そして、レビューに組織的に取り組むことで、コミュニケーション活性化や人材育成など
 組織力強化が図られます。



 『企業システム戦略』実践コンサルティング

 お問い合せは、こちらのフォームからお願いします。