リスク管理は難しいと思っている人が多いようです．どこから手を付ければいいのか分からない，と思っている人も多いでしょう．別のページで，「コミットメント」からリスク管理を行う方法について説明しましたが，ここでは，「差」からリスク管理を行う方法について説明します．
経済がグローバル化し、地球の裏側で起きた事件が、１時間もあれば世界中に伝達される時代にあって、「リスク管理」能力は、ますます重要視されるようになっていきます。もはや日本という限られた範囲でのビジネスは成立しなくなった今日、輸出企業に限らず、為替の動きやその方向性は、あらゆる企業にとって経営判断の重要なファクターです。
一方、ソフトウェアの開発現場にあっても、プロセッサーや半導体技術の飛躍的な向上によって、製品に求められる機能は、指数的に増加しはじめています。にもかかわらず、多くの開発組織では、目前の案件を何とかこなすことにすべての資源を投入してきたといっても過言ではありません。その代償として開発組織のスキルアップを怠ったことは否定できず、最近では顧客や市場の求めるような期間での開発が困難な状況になりつつあります。
言い換えれば、近視眼的な判断が優先し、組織としてのリスク管理を怠った「ツケ」が、ここにきて回ってきたということでも言えます。
リスク管理の必要性は、殆どの人は認識しています。“そんなものは必要はない”という人はいないでしょう。でも実際には、お世辞にもうまくやっているとは言えないのが実状です。
リスク管理が難しいという人を見ていると、第一に「リスク」の認識が正確ではないことです。リスクとは、「遭遇したくないことに遭遇する可能性」であり、「リスク管理」とは、その「可能性を消す」ことが中心的作業となります。ところが、現実に行われている「リスク管理」は、それが「起きたときの対応方法を考える」ことと認識されているため、予防措置よりも事後処理に重点が置かれています。（このあたりの問題は、「リスク管理に取り組もう」「リスクマネージメントの欠如」とも重複しますので、ここではこれ以上踏み込むことはさけます）
もう一つの原因は、「リスクの要因」を見つけることが上手ではないということです。この問題については「リスク管理に取り組もう」というページでも触れていて、そこでは、「role」と「commitment」という観点から「要因」を見つけだすことを提案していますが、このページでは、もう一つ別の方法として「差」から「リスクの要因」を見つける方法を提案します。
Ｂさんが率いた去年のプロジェクトは、顧客の要求する納期に対して半月の遅れで納品することが出来た。これはその組織においては“画期的”なことで、顧客からは大いに喜ばれ、社長もご満悦で、報償金ももらった。この時点でＢさんは“ヒーロー”となったわけです。
あれからわずか１年。今、Ｂさんの率いるプロジェクトは納期を３ヶ月後にひかえて破綻している。まだ実装も１／３しか終わっていない。それだって、半分ぐらいは“未完成”である。暫定的な仕様で、残っている部分の設計が進んでいくことで、その詳細が明確になり、その時点でもう一度、そのソースに修正が加えられることになる。言うまでもなく「設計」を省いたときに陥る状態である。
チームのメンバーは破綻状態に気づいており、中には『受難者のゲーム』や『私のがんばりをみてゲーム』を演じ始めている。みんな無口になって、“自分の仕事”に没頭しているため、Ｉ／Ｆの不一致や隠れ仕様の問題などは、おそらくもっと後になって、結合テストを始めたところに出てくるものと思われるが、すでに、メンバーの間では不信感が漂っている。
あの、ヒーローのＢさんが率いていたのに、どうしてこんなことになったのか？
一言で言えば、「同じプロジェクトは存在しない」ということです。にもかかわらず、これまでと「同じ」方法で対応しようとしたからです。
今回のプロジェクトは、予想されるオブジェクトのサイズは前回の３倍と見込まれている。といっても、開発期間は前回と同じ１年ということで、とうぜん、メンバーの増強が計られた。メンバーはＢさんを含めて約２倍の９人で、そのうち、前回のプロジェクトから引き続いて参加する人は４人である。当然、一人の分担は、単純に計算して前回の１．５倍になる。５名は、Ｂさんと一緒にチームを組むのは初めてで、その内の２名は２年目の殆ど新人に近い状態、残りの２名は、３〜４年目の比較的若い人たちで、あと一人は、６ヶ月前に中途で採用された人で年齢は２８歳である。
開発言語は、前回と同じだが、新しいメンバーの２名は、プログラミングの経験は乏しいし、中途採用された人のスキルは未知である。
悪いことに、最初から製品仕様が出てくるのが２ヶ月も予定を過ぎてしまった。先に完成した製品の後追い作業が残っていたため、新しい製品の仕様作成に取り掛かるのが遅れてしまったのが直接の原因であるが、もとより、この種の仕様が書ける人が１人しかいないのだから、これは容易に予想できたはずである。
Ｂさんは、もっと早く、仕様が出てくることを想定していたため、最初の１ヶ月間に、新しいメンバーに対して、前回の製品の仕様を見せたりしていただけで、それ以外に特になにもしていなかった。仕様が出てくる日程が明らかにされなかったため、その後も、ずるずると、製品の“学習”に時間を潰してしまった。
当然、仕様が出てきても、内容は「TBD」という文字があちこちに氾濫しており、とても使える状態ではなく、さらに３週間の時間を失うことになる。
Ｂさんは失った時間を取り戻そうと、このあと必要なプロセスの大部分を省いてしまった。システムの全体像をイメージするものも省かれたし、製品仕様から要求仕様書を作る作業も省かれた。設計書も省かれた。
こうして、チームは、破綻の道を歩み出すことになるのだが、はたしてこのことは防げなかったのかということが問われることになる。
ここで皆さんも気づかれたことと思いますが、ほとんどの問題は「差」から発生しているわけです。前回のプロジェクトの時との「差」です。
機能の規模やメンバーの構成に差があることはすぐに気づくでしょうが、仕様の担当者も、前回と今回とでは、取り掛かれるタイミングが違っているわけです。新しく参加した人たちも、プロジェクトの性質や製品の分野も違うかもしれません。分担の内容も違うでしょう。リーダーの作業の進め方も違うでしょう。製品仕様を書く人も、前回は手空きの状態だったが、今回はすぐに取り掛かれない状態であった。
開発環境も変わっているかも知れませんし、メンバーの考え方も、時代とともに変わってきているかも知れません。実際、「同質の世代」から「選択の世代」へと、人々の意識は変わっています。言わなくても分かるということは、次第に通用しなくなってきています。
あるいは、メンバーの国籍も多様化する傾向を見せており、これなどは非常に大きな「差」として、そこに立ちはだかることになります。
このような「差」は、すべて「リスクの要因」になりうるかどうか早い段階で考慮されなければなりません。その「差」はリスクの要因になりうるのか。なるとすれば、どのような問題を引き起こす可能性があるのか。そして今対応できる方法は何か。いというように、いわゆる「リスク管理」のステップを進めることになります。
Ｂさんにとっての「差」だけでなく、メンバー各自においても、これまで経験してきたものとの「差」は、しっかりと認識していなければなりません。一般に、プロジェクトの最初の「計画」の段階で、各自に於けるこの「差」をリストアップしたものが「新規性チェックリスト」です。そこでは「新規性」の度合いから、危険性を判断し、必要に応じて事前のトレーニングや学習などの機会を設けたり、試作のステップを組み込んだりして、失敗の可能性を減らすわけですが、新規性の要因は、まさに各自の於ける「差」そのものなのです。
「差」といっても、このように誰の目にも見えるものばかりではありません。メンバーの心の変化も、時には重大な問題を引き起こす可能性があります。自分の担当部分で行き詰まりかけているとき、それがちょっとした行動に現れてきます。日報の様なものを書いている場合は、そこで使われる言葉に変化が現れたり、提出の時間がずれ始めたりします。
ドキュメントに対する姿勢が雑になってきたり、これまで殆どスケジュール通りに進んできたのに、少しづつ遅れ始めたりします。あるいは、喫茶コーナーでのメンバーの会話も変わってきたりします。これらの変化は、注意していないと気づくのが遅れ、リスクとして認識する前に「問題」となって噴出することになります。
マネージャーは、日報も、ただ“目を通す”だけでなく、時系列に並べて、１週間ぐらい前にさかのぼって見たりして、早く「差」に気づくことが求められます。
このように「差」の認識は、リスクの要因を見つけだすのに大いに役に立ちます。プロジェクトをうまく進めるためには、この「差」を検知する仕掛けをあちこちに作ることが大事です。ただ「差」が見え始めるのを待っているのではなく、積極的に、「差」となって現れてくる仕掛けを作るのです。ちょっと大袈裟に言えば、センサーを張り巡らせるのです。
ＣＭＭのＫＰＡの一つである「プロジェクトの計画」のなかで求められているもの、たとえば、マイルストーン〔スケジュール）やサイズ見積り、リスクリストなどは、この「差」を検出するためのセンサーの働きをします。予定していたものと結果が違った、つまり「差」が生じてしまったとき、それが１時的な現象なのか、このあとに起きてくる「問題」の予兆なのかを検討するトリガーを与えてくれます。
私が進める「詳細なスケジュール」を書く方法も、それによって１日単位で「差」を検出することができ、その時点で、それが「リスクの要因」となるのかどうかを判断することができます。そしてそのようなスケジュールがチームに公開されていることで、本人だけでなく、リーダーやマネージャーも、その予兆を検知することができます。
もちろん、スケジュールが、すべてこのような意味のある「差」を生み出すとは限りません。最初から非現実的なスケジュールでは、たとえ「差」が生じたとしても、そこから「リスクの要因」を見つけだすことは出来ないでしょう。
残念ながら、現実にはそのような「差」をみつけるための「仕掛け」は殆ど為されていません。そのため、「リスク」として認識する前に、「問題」となって行く手を遮ることになるのです。
どうか、このページをご覧の皆さんは、この「差」に対する感覚を磨いてください。それが、あなたの「仕事人」としての役割を円滑に進めることになるでしょう。
いや、このスキルを持たないで、２１世紀にどのような役割を担うつもりでしょうか。