第118号：プロセス改善ストーリー：ある新米SEPGの1日(改善の時間がない)

CMMIを使ったプロセス改善活動で悩むポイントなどを、初心者向け解説本でよく見かける会話形式の文章で解説していきます。
プロセス改善に関する会議中の会話を通して、問題点を解決する糸口を見つけ出していく様子を感じ取って頂ければ幸いです。

＜登場人物＞
　()は会話文中の省略形
　野比(野)：改善グループのメンバ。新米SEPG。
　土良(土)：CMMIコンサルタント。改善グループの相談に乗っている。

さて、野比たちの改善グループは、現場に展開するプロセス資産の作成を進めていますが、何やら活動時間の確保の問題が起こっているようです。

とある改善会議で、野比が土良に泣きつくように質問した。

野「土良さ～ん、ちょっと困ったことになりました。」

土「野比さん、どうしましたか？」

野「先週まで改善グループの３名で標準プロセスの作成を進めていましたが、今週に入って社内にトラブルプロジェクトが勃発して、メンバの骨川さんと源さんもそのサポートに入ってしまいました。当面抜けられそうにありません。
　　
そのプロジェクトは私の元上司の郷田さんの担当なので、『オレのプロジェクトを手伝えないってか。野比も来ないとぶっとばすぞ』と、私も支援に入るよう要請されています。『ぶっとばす』はまあ半分冗談だとして、私も週に２～３日は支援に入ることになりそうです。
　　
そんな状態なので、活動の時間が全然とれず、進捗がストップしています。このままでは、１ヶ月後に控えたプロセス資産のリリースに間に合いません。どうしたら良いでしょう？」

土「なるほど、状況は分かりました。改善活動の時間がとれないんですね？お話を聞いた限りでは、何かしら見直しが必要そうですね。」

野「はい、やっぱり計画を変更して１ヶ月後のプロセス資産のリリースは延期するしかないですかね・・・？」

土「そうですね、しかし、単に時間が確保できないからといって、簡単に当初の計画を変更するべきではないのではないでしょうか。計画上でこれはやるとコミットしたことは、まずは何があっても『やりきる』という気持ちが必要です。キャッチアップは不可能な状態ですか？」
　　
野「う・・・たしかにそうですね。まずは最初に立てた目標達成がありきで、遅れが出た場合は、キャッチアップが可能か考えるべきですよね。」

野「しかし、実際問題として、今のやり方のまま進めても厳しそうです。何かやり方を見直すいい手はないもんでしょうか？」

土「たとえば、スコープや納期を変えずに、やり方を変えて効率を上げるプロジェクトマネジメントの手法の例としてはこんなのがありますね。」

と言って、土良はポケットからタブレットPCを取り出し、手法の例を説明し始めた。

・クラッシング・・・追加コスト（要員追加、残業、休日出勤）投入
・ファストトラッキング・・・クリティカルパスの作業タスクを並行的に実施
・標準化・・・作成するプロセス資産をテンプレート化して作業効率を上げる
・平準化・・・負荷がかかっている作業を割り振り直して滑らかにする
・タスク詳細化・・・大雑把なタスクを細分化して作業を分担できるようにする

野「なるほど、いろいろやり方があるんですね。」

野「とはいえ、今回は追加要員も望めないので、このままの作業量を１ヶ月で完了させるのはやはり無理がありそうです。一体どうしたら・・・。」

土「計画のフィージビリティがないとなると、優先順位を考慮した上で、スコープと納期の調整を考えるのはいかがでしょう。」

野「優先順位はどうやって考えたらいいですか？」

土「今回の活動のゴールや制約条件から『重要度』を考えるのと、その対応にかかる『コスト』を算出して、重要度とコストのポイントの掛け算で優先度を出すのが１つの方法ですね。
　　
重要度(1:低⇔5:高)×コスト(1:高⇔5:低)＝優先度（低:1～高:25）
例）重要度3×コスト2＝優先度6
　　
これで優先度が低いものは、今回のスコープから削って次の改善サイクルでのリリースに回すか、そもそも対応不要とします。」
　　
野「なるほど。今回の１ヶ月後のリリースというのは、改善グループの組織目標でもありますし、当社の成熟度レベル２達成目標時期を考えると、やはりリリース時期を変えるのは難しい気がします。
　　
ただ、現在のリリース対象のプロセス資産には、『標準プロセス』『利用ガイド』『書式』『サンプル』『ツール』などいろいろありますが、いくつかは最初のリリースの時にはなくても良いものがありそうなので、リリース対象を見直すことはできそうです。」
　　
土「『標準プロセス』や『書式』は、プロセスの実装をする上で重要度は高そうですが、反面、『利用ガイド』や『ツール』は、使用者の利便性を高めるには良さそうものの、対応コストがかかりそうですし、今すぐなくても大丈夫ではないでしょうか。」
　　
野「そうですね！　ではそのやり方で優先順位を評価して、分割リリースの計画を提案してみます！」

土「あと補足ですが、改善活動を停滞させないためには、普段の仕事の中に改善を行う時間を確保しておくことを忘れないようにして下さい。」

野「どういうことですか？」

土「開発プロジェクト作業と改善活動の作業を同時に行っていると、どうしても改善活動の方の優先順位が下がって、いつの間にかやらなくなってしまうことがあります。
　　
そうならないためには、例えば月の何％は改善活動にリソースを割り当てるよう要員計画を立てる、"この日は改善活動をする日"というのをあらかじめ決めておく、といった手があります。
　　
グーグル社には、社員は業務時間の20%は新しい仕事を創出するために自由に使って良いという『20%ルール』があるのは有名です。現在はそのルールはあまり有効活用されていないという話もあるようですが、同社のイノベーティブなサービスを生み出す源泉がそこにあるとも言われています。

野「へ～、興味深い話ですね。」

土「忙しい時だからこそ、改善の時間を確保して、より品質の高い仕事を効率的に出来るようにしたいものですね。」

＜野比のノビノビ日記　～今日のまとめ～＞
やれやれ、一時はどうなることかと思ったけど、なんとか見直した計画で進められそうだ。
あのままだったら自分一人じゃどうにもならないから、タイムマシンで過去の自分をたくさん連れてきて、夏休みの宿題を一気に仕上げるなんてマンガみたいことを考えるところだったよ。

さて、今日の話をまとめておこう。
・活動の遅れが出てもすぐに計画変更しない。やりきる気持ちを持つ。
・計画変更の前に、作業のやり方を見直すことで計画通り進められるようキャッチアップを検討する。
・計画変更の際は、目標や制約事項から優先順位を評価してスコープや納期の見直しをはかる。
・普段の業務の中に改善活動の時間を設けよう！