このエントリーをはてなブックマークに追加LINEで送る

第11章 リスク管理

ハッピィ・エンジニアリング表紙

 大手の染料メーカーであるA社は、経営の多角化により、商品ラインアップを強化するとともに、営業プロセスの見直しを行った。その一環として、販売管理システムをリプレースすることにし、大手SIベンダのB社にシステム開発を依頼した。

 

 営業管理プロセスの確定が遅れ、営業状況のデータを集計する機能の仕様確定が行われないままに、プログラミングプロセスが終了しようとしていた。契約では、テストプロセスに入ると新規機能追加はいったん凍結される。その後の新規機能追加は、追加発注を行い、開発ボリュームやB社のプロジェクト体制など、実現可能性を判断した上で確定することになっていた。

 

 B社のプロジェクトマネージャは、営業状況集計機能を現在のリソースで納期までに開発することに、少し不安を覚えていた。ほかの機能や設計に大きく影響するような機能追加になると、それらはすでにテスト段階に進むだけあって、スケジュールへの影響が大きいかもしれない。しかし、あと数日でプログラミングプロセスの終了日程がくるので、「多分、この機能は追加されないだろう」とタカをくくっていた。「ヤブをつついて蛇を出しても仕方ないし、当面無視してやりすごすことにしよう」

 

 ところが、この判断がプロジェクトに大きなダメージを与えることになる。営業状況集計機能は、A社の事業部長や役員クラスが利用する機能である。事業部長は、営業管理プロセスの確定が遅れていることは知っていたので、

 

「今回はこの機能がなくても、業務が可能なところで十分としよう」

 

と思っていた。

 

 その意向をシステム担当者に告げると、システム担当者は、

 

「やっと、大枠の仕様が決まってきました。ベンダからは、順調に進捗していて問題ないと聞いていますし、事業部長や役員の皆様が必要な機能ですから、契約に問題ない以上はベンダにやってもらいましょう」

 

と答えた。事業部長も、

 

「そこまで順調だというのなら、ぜひやろう」

 

と同意した。システム担当者は、自社内に、

 

「営業状況集計機能の仕様が固まったので、プロジェクトスコープに含めます」

 

と伝えた。

 

 そして、B社のプロジェクトマネージャに電話をかけた。

 

「ようやく、営業データの集計機能の仕様が固まったんだけど、プログラミングプロセスの終了日まであと2日あるから、契約の範囲内でできるよね?各拠点のデータを本社サーバに転送して、サーバ上で集計したからメインフレームに送るだけなんだけど」

 

「時間的に厳しいですが、契約の範囲内ですし、その程度の追加だったらやれますよ。今のところスケジュールにも余裕があるし、少しがんばれななんとかなるでしょう。」

 

しかし…。

 

 現時点の販売管理システムに集計機能を追加するには、大きなハードルがあった。集計機能の確定が遅れ、何も決まっていなかったため、日締めの処理が抜けていたのである。さらに、複雑なデータ構造から、本社のサーバに送信するデータ形式への変換処理の作り込みに多くの工数が必要になることがわかった。その上、本社のサーバと販売管理システムのマスタデータは同一ではなく、一部のデータは本社のマスタデータの形式に変換する処理が必要となった。このデータも一対一に変換できればよいが、なんらかの判断をして2種類のデータに変換しなければならない。このときの条件判断の仕様が出てくるまでに、かなりの時間が必要になることは、過去の経緯から容易に想像できた。

 

 とはいえ、プログラミングプロセスの進捗状況は順調である。各チームは、それぞれ平均して80〜90%完了という進捗を計上している。これなら、各チームから2名ずつ、機能追加の設計にあて、ほかの機能が結合テストに入った段階で比較的余裕のあるプログラマをアサインすれば、なんとかなるのではないかと思われた。

 

「システム開発に残業はつきもの。休日出勤すればどうにかなるな」

 

 そんなとき、データエントリ機能でかなり根の深い問題が発生し、プログラミングが大幅に遅れ始めたという連絡が入った。プログラミングしている際に大きな仕様の抜けが見つかったのである。当然、要件レベルからの調整が必要だ。データエントリ機能を開発するチームリーダとSEに調整を指示した。まずデータエントリ機能の問題を解決しないことには、集計機能に手を出すわけにはいかない。ところが、抜けていた仕様を実現するには、データベースの設計変更が必要になる。データベース設計は、すでにチームを離れてしまったSIベンダの技術者が担当しており、データエントリ機能を開発しているチームでは、パフォーマンスに対する課題を解決しきれずにいる。

 

 さらにプログラマの投入が必要なため、手の空いているチームから2名を応援として投入しようと考えた。しかし、2名を投入するのが難しいことがこの段階で発覚したのである。進捗は80〜90%と報告されていたが、実際にはコーディングが完了しただけで、一度も動作確認やコードレビューが行われていないのである。単体テストに入りはしたものの、テストケースは全然消化されず、プログラマはデバッグ作業に追われている。

 

 それから2週間、やっとのことで結合テストが開始されたものの、集計機能にはまだ着手できていない。プロジェクトの終結には、暗雲が立ち込めている……。

第11章 リスク管理 ハッピィ・エンジニアリング記事一覧

11.1. リスク管理とは ハッピィ・エンジニアリング

むだ、むだ、むだ。むだとリスクは、いつも隣り合わせだと思うね。現実にむだになったプロジェクト作業、ほんとうに後戻りせざるを得ないような大きなむだは、かならずリスクが現実になった結果だ。そこで、わたしがなにか一つやるとしたら、リスク管理だね。プロジェクトが直面するリスクを管理することによって、プロジェ...

≫続きを読む

11.2. 現実のリスク管理 ハッピィ・エンジニアリング

 たいていの開発プロジェクトでは、何らかのタイミングでプロジェクトマネージャやプロジェクトリーダが、リスクとなりそうな部分に対する指摘を行い、技術者がその課題に対処するようなケースが多い。つまり、ある特定のタイミングで、一時的に、経験則によるリスクの発見、評価、対策を行っている。 「やらせる側」のプ...

≫続きを読む

11.3. 文化的な背景 ハッピィ・エンジニアリング

リスク管理が根付かない理由の多くは、「2.1 丸投げ文化」に記した「甘えと癒着の構造」に端を発している。 ユーザ企業はSIベンダに丸投げし、SIベンダは実現可能性を考慮に入れず、「できます、できます」と安易にプロジェクトを受注している。このため、プロジェクトに問題が発生した場合でも、的確にユーザ企業...

≫続きを読む

11.4. リスク管理への間違った意識 ハッピィ・エンジニアリング

 一般的なプロジェクトでのリスク管理への取り組みは、以下のような問題がある。リスクの抽出や検討がプロジェクトの任意の段階でしか行われない想定外の問題が発生するリスクが顕在化してからの対応となる 先送りしてきた問題や気づいていないリスクは、プロジェクトの後半に次々と顕在化していく。プロジェクトの後半は...

≫続きを読む

11.5. リスク管理を根付かせる ハッピィ・エンジニアリング

 個々のシステムの品質を均一にする上でも、プロジェクトマネージャやプロジェクトリーダの経験則やスキルに依存せず、リスクマネジメントをプロジェクトマネジメントプロセスに組み入れることは必要不可欠である。さらに、それが形骸化せず、文化として根付かせるために必要最低限、以下のような活動を行わなければならな...

≫続きを読む

11.6. リスク管理のメリット ハッピィ・エンジニアリング

 リスク管理のメリットは、そのリスクが顕在化し、順調に対処できてはじめて効果が理解できるため、目に見えにくいものである。しかし、プロジェクト全体を俯瞰してみると、そのメリットの大きさを認識することができる。 プロジェクト計画について、何度も計画を逸脱しないこと変化に対応しながら改訂していくことを強調...

≫続きを読む

11.7. リスク管理プロセス ハッピィ・エンジニアリング

 リスク管理プロセスは、プロジェクト計画段階から終結に至るまで継続的かつ段階的に行わなければならないプロセスである。継続的に行わないと、どこかの工程で現われるリスクを見落とすことになる。また、システムの機能が明確になり、作業内容が詳細化されていくに従い、プロジェクトの初期段階で抽出したリスクも詳細化...

≫続きを読む

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング