プロセス改善の取り組みのなかで“やり玉”にあがるものの一つに「リワーク」があります。このテーマは、先のプロジェクトで中途半端な「暫定仕様」で走った結果、後になって大幅に作り替えるような事態に遭遇したような状況から、提案されるものです。
“リワーク”が、なぜ問題になるのか。「リワークを伴わないプロジェクトなんてあるのか？」
確かに、リワークが「ゼロ」というプロジェクトはないでしょう。プログラムの“バグ”は、その後のリワークを要求します。作業の段取りの悪さは、複数の人の作業をやり直させるでしょう。仕様定義の遅れは、暫定仕様での作業を強いることになります。そして、結果として幾つかのバグは発見されるでしょうし、要求仕様も途中で変更されるでしょう。いや、最初から変更されることを承知作業を進めることだってあります。要求にユニークな番号をつけるのは、そのためでもあります。
では、“リワーク”の何処が悪いのでしょうか。この種のリワークが問題なのは、最初の時と違って、“リワーク”の時は検討が甘くなる傾向があるということです。リワークが発生したときは、すでに作業のステージが進行していますので、頭の中を切り替えたり、１ヶ月前のことを思い出したりしなければなりません。そこで、要求項目に番号を付けて、変更が予想される項目の番号を設計書やソースに埋め込んでいくことによって、思い出したりする行為を助ける効果を発揮したり、その際のモレを少しでも防いでくれます。このような必要かつ有効な手掛かりが無ければ、過去の状態に戻す行為が省かれたり、不十分な状態になってしまい、新たなバグを作りだすことになります。厄介なのは、この時に当人は“不十分な状況”であることには気付いていないことです。「時間」に追われているという状況も、それを加速することになるでしょう。これが、“リワーク”が問題になる理由です。
特に、リワークを想定していない状況では事前に何ら対応されていないために、リワークの作業の品質を落とす結果となってしまうのです。リワークが最初から想定されているのであれば、ある程度の対応は可能であり、作業の品質の低下をある程度防止することができます。
これらの「リワーク」は、ほとんどが文字通り「やり直し」作業であって、分かり易いのですが、実際にはもっと“厄介な”リワークがあります。それは、最初に“発生”したときに、必要な行動をとらなかったことで、後になってからは、その作業が非常に出来にくくなってしまい、そのために以後の作業に少なからぬ影響を与えてしまうものです。
たとえば、要求仕様やプロジェクトの計画書は、基本的にプロジェクトの工程の前の方に位置していて、多くの人は、これらが重要な役割を果たすということはイメージできています。しかしながら、現実には、これらが有効な形に書かれることは殆どないといっても過言ではありません。要求仕様や計画などは、当事者としては実際には、あれこれ考えているものです。でも、その結果として出てくるものは、精々「要約」でしかありません。計画を考えているときなどは、リスクについてあれこれ思いを巡らせているものです。でも、それが表現されないまま、計画に多少の余裕を持たせるという程度の対応だけで、実際の作業に入ってしまうものです。
このように、折角イメージしたリスク項目や計画（プラン）が表現されていないため、当人以外、誰も知る方法がありません。そこにどんなリスクが予想されているのか、この計画には、どのような考えが盛り込まれているのか、リソースの調達はどのように考えられているのか、誰も知らないわけです。プロジェクトの進行がうまく行って最後までそれらのことを誰も知る必要がなければ、まだ救われるのですが、プロジェクトの進行が思わしくない状況に限って、「計画はどうなっているのか」「リスクの対応はどうなっているのか」などという声が上がってきて、その時点で、計画書やリスク項目の書き出しが迫られます。
私は、これも「リワーク」と分類しています。確かに、以前に書かれたものを“書き直し”ているわけではありませんが、本来、書かれるべきタイミングを逸したことで、ここでは、「思い出して」書かなければなりません。実際に、プロジェクトは進んでいるわけですから、ここで“新たに”考え出すわけには行きません。“あのとき、確かこんなリスクを感じたはずだけど”とか“Ｂさんの作業が重複しないように考えたはずだけど”という具合に、思い出して書かなければなりません。これは、新しく考えるのと違って、大変な苦痛なのです。その結果、書かれるものは、結局中途半端なものでしかなくなるわけです。やっとの思いで書いたものであるにも関わらず、その効力を発しないものとなってしまいます。時間は、最初に考えたとき以上に使ったのに、効果はないわけですから、勿体ないことです。プロジェクトの最後になって納入す成果物が書かれた場合も同じです。そのような成果物からは、何も伝わってきません。
この種の成果物は、考えられたときに「形に」されなければなりません。たとえ、内容は不十分であっても、その後、さらに考えついた時点で順次追記していけば良いのです。最初に考えたときに書かれたことで、その後も、考えついたときに書けるのです。このときに書いておかなければ、その後になって“さかのぼって”書かかれることは実現しません。この差は、皆さんが想像する以上に大きいかもしれません。
このようなリワークが起きる原因として２つ考えられます。
１）どのようなものを書けば良いのか分からない（知らない）
２）そのタイミングに気付かない
リワークは、そのことに気付いた時点で、すでにリワークとなっている状態であって、リワークの防止ということでは手遅れなのです。
この種の厄介なリワークを防ぐには、どのような作業の流し方があるのかということを、もっと研究する必要があります。適切な文献を読んで、自分たちの作業のパターンと、どう違うのかを知ることが重要です。その意味でも、「ＣＭＭ」は絶好の指針となるはずです。「ISO 9000」も、一つのゴールとしての指針になります。その他、プロジェクト管理の本や、計画書の内容、要求仕様の書き方、設計書の構成など、自分たちの作業の特徴を考えながら、より有効な作業の流れを作り出すことです。
いつ、どのようなものをまとめれば良いのか。いや、いつどのようなことを考えれば良いのかは、作業の「流れ」を持たないかぎり見えてきません。逆に作業の流れを持つことで、有効な成果物の存在とタイミングが見えてきます。そして、早い段階で「ドキュメント体系」を作り、それにそって、想定されるドキュメントの「形」を早い段階で用意しておくことです。中身は無くても「箱」だけでも用意しておくのです。その後、作業が進むにつれて、先の方の箱は「目次」などの形で内容や構成で区切られていきます。そして、それに沿って、作業の無駄が省かれて行くことになります。
厄介なリワークの原因である、いつ、どのようなものを書けば良いのかという問題は、このようにしっかりした作業の流れを持つことで見えてきます。あとは、それを満たすべく具体的な「内容」を研究することです。これには、適切な文献を読んだり、うまくやっている人から話を聞くことです。そして、“すぐ”に、ひな形にしてまとめることです。その“瞬間”を逃したら、リワークになってしまうのですから。