PMBOK適用のSW開発におけるリスクマネジメントの実際
どうやってSW開発プロジェクトでリスクマネジメントを行っていくのか。PMBOKでは具体的な実践内容については述べられていないので、PMBOKの内容を踏まえて自分なりにリスクマネジメントをしていかないといけない。
実際にはPMBOKだけではなく、一般的な品質保証とかリスク管理とかの知識を総合して対応が必要だと思っているが、なんとなしにやっている所もがあるので、ちょっと自分なりにまとめてみよう。
１．そもそもPMBOKでのリスク管理とは
個人的には割と統合マネジメントに近い物があると思っているのだが、冷静に纏めてみよう。
最近ドキュメントの方をみていないのでちょっと忘れている。
カテゴリ的には以下のフローでマネジメントをする事になる。
| 知識エリア | 立上げプロセス | 計画 | 実行 | 監視・管理 | 終結 |
| リスク管理 | - | ①リスク・マネジメント計画 ②リスク特定 ③定性的リスク分析 ④定量的リスク分析 ⑤リスク対応計画 | - | ⑥リスク・監視・コントロール | - |
最後のリスク・監視・コントロール以外は全てが計画プロセスにわりあたっているというのが特徴的である。
これだと計画時にミスると、リスク管理に失敗するというように見える。が、実際にはPJのライフサイクルを通して、新たなリスクが出てくるので、計画プロセスも監視コントロールプロセスも常時実行していかないといけない。
PJライフサイクルを通して、リスク特定⇒分析⇒対応計画⇒監視・コントロールを行う事が重要。
リスク・マネジメント計画
まず、PJでリスクマネジメントにどのように取り組むかを計画する。
リスク特定
リスクをリスク登録簿へあげつらう。ここでリスク自体が漏れてしまうと、後々問題になるので超重要。
なお、リスクとは、脅威と好機の両方が対象であることに注意。
定性的リスク分析
リスク特定で上がった各リスクに対して、発生確率と影響度を評価し、各リスクの対応優先度決めを行う。
定量的リスク分析
定性的リスク分析で、高優先度になったリスクに対して、プロジェクトに与える影響がどの程度になるのか数値で、定量的に分析を行う。分析の仕方にはいろいろなツールがある。
- インタビュー
- 確率分布
- 感度分析
- トルネード
- 期待金額価値分析（EMV)
- モデル化とシミュレーション
- 専門家の判断
リスク対応計画
特定した脅威、好機のリスク項目に対して、それぞれどう対応するかを決める。
脅威に対して
| 回避 | 脅威を完全に取り除く |
| 転嫁 | 第3者に脅威対応を渡す |
| 軽減 | 発生確率、影響度を受容可能な値にまで下げる |
| 受容 | 受け入れる |
好機に対して
| 活用 | 好機を確実に発生させるようにする |
| 共有 | 好機を第三者と共有する |
| 強化 | 発生確率と影響度を増加させる |
| 受容 | 対策せずに受け入れる |
リスク・監視・コントロール
リスク登録簿にあげつらったリスクの状況の追跡とその監視。
また、それ以外の新しいリスクが無いかリスク特定を行う。（実際にはここになると計画プロセスのリスク特定の作業に戻っている。）
２．具体的にどうやってリスクマネジメントするか
ここからはPMBOKを習得した上で、実務でどうやるかという点。
プロジェクトの最初に特定したリスクに関しては、常時監視しておき、新たなリスクの目が出ないか、リスクが顕在化していないか、顕在化していれば対策を実行という事をする必要がある。
次に、プロジェクトを進めている内に新たなリスクが出てくるので、それを検知する必要がある。SW開発においては、いろんなところでリスクを検知するアンテナを張っておく必要がある。
SW開発のプロセス的に見ていくと以下のような感じか。
| 開発フェーズ | 主なリスク特定の観点 |
| 企画、計画 | 最初のリスク特定フェーズ |
| 要求分析 | 要求漏れが出ないか。要求分析の範囲に問題が無いか |
| 基本設計 | 大きな勘違いや検討漏れが無いか |
| 詳細設計 | 設計漏れが無いか。ノウハウ的なものがないか。協調が出来てるか |
| 実装 | コーディングルールが守られてるか。設計通りか。 |
| テスト | テスト設計する技量があるか |
| リリース | 次工程への連絡漏れが無いか |
ちょっと書き出していくともっと大量にあるのだが、止まらなくなるからちょっとやめておこう。しかし、これをリスク特定の為の観点集みたいに纏めると便利そうである。
PMBOKの知識エリア別に見ていくとどうだろう
| 知識エリア | 主なリスク特定の観点 |
| 統合 | 変更管理されていない物がないか |
| スコープ | やらなくてよいことをやって時間ロスしてないか。 |
| タイム | メンバが時間を使えているか。スケジュール通りにいく見通しがあるか |
| コスト | お金、工数がものすごいかかる見通しになってないか |
| 品質 | 成果物が所望のものになってるか |
| リソース | 技術力が足りてるか |
| コミュニケーション | メンバ間で勘違いないか |
| リスク | - |
| 調達 | 外部のコントロールが出来てるか |
| ステークホルダ | 隠れたステークホルダによるツルの一声みたいなのがないか |
３．実務を通して難しいと感じる点、問題点
前節で上げたように、複数の開発フェーズ、知識エリアでいろんなリスク特定の観点があるが、PMが一人で出来る事には限界がある。
チームメンバがそれぞれリスク検知してそれの対処をしてくれると助かるんだが、そんなことが出来る人ばかりならば、そもそもPMは要らないというもどかしさ。
また、SW開発はOSSや外部モジュール等の流用資産を使わないと開発が出来ない程に巨大化してきているが、それらのSWがちゃんと動くのかという評価が出来るわけでもないので、そこのリスクをどうやって解消したらよいのかが難しい。購入品ならなんとかなるが、OSSとなると自己責任。みんなどうしてるんだろう。
OSSのコードはあるから静的、動的解析やテストでの品質確保は出来るが、いざ問題が発生したり、設計変更、機能追加が必要になった場合、とたんに対処できる人が居ないというリソース管理上のリスクが顕在化することになる。うーん。
また、ステークホルダにおけるリスク要素がある場合、そのリスク情報自体を共有する事が出来ないという問題がある。
上司や関係者に対して、「あなたのその行動がリスクです。」なんて言った日にはプロジェクトが崩壊する。
４．世間のリスクマネジメントの知見はどんなものがあるのか
世間一般でのリスクマネジメントの考え方をちょっとWebで見てみた。
すると、IPAから、まさに自分で難しいなと思っていたような事が書かれたペーパーが出ていた。
リスク事象ドライバーという内容で、リスク特定に役立ちそうな一覧が出ていた。
ITプロジェクトのリスク予防への実践的アプローチ
https://www.ipa.go.jp/files/000026834.pdf
また、上記は「実践・リスクマネジメント」という書籍を参考にしているようである。参考に見てみよう。
実践・リスクマネジメント―製品開発の不確実性をコントロールする5つのステップ
- 作者: プレストン・G.スミス,ガイ・M.メリット,澤田美樹子
- 出版社/メーカー: 生産性出版
- 発売日: 2003/12
- メディア: 単行本
- 購入: 1人 クリック: 6回
- この商品を含むブログ (2件) を見る
Redmineでプロジェクト管理
いつもMS-Projectでマネジメント業務を行っているが、よく使われているらしいRedmineを試しに使ってみた。
何が良いっていうと、なんせ無料で使えるというのが最大のメリットである。
しかしちょっと使ってみて以下の問題があることが分かった。
問題点
１．ガントチャートが自動で作れない。自分で開始日と終了日を入れないといけない。
２．予定作業工数を入れてもガントチャートに反映されない。終了日が必要。
３．ガントチャートの順番が自分で自由に変えられない。開始日で並んでるのかな？
ちょっとこの３点は個人的にはRedmineを使うには致命的だなと思った。
この解決にはプラグインを何かしら追加すれば解決はするらしい。例えば以下。
- Easy Gantt
- Rychee Redmine
それならそれで、他の機能を調べてみよう。
基本的な操作の流れ
基本的にはチケットドリブンで全てが決まっていくツールである。
マネジメントに使うには以下のような流れになる。
計画時
- チケットを登録
- イテレーション（Redmineではバージョン）を登録する。
- チケットの作業予定工数と優先度、担当者を割り付ける。
- チケットをイテレーションに関連づける。
- チケットの作業開始日を担当者別に調整する。
- ガントチャート上でスケジュール的に問題ないか担当者別にみていく。（重複タスクになっていないか。リソース割り付け調整など）
進行時
- 作業開始でステータスを進行中にする。
- ガントチャート上かチケット上で進捗を入れる。
- 進捗が100%になったら、ステータスを解決にする。
- 内容確認して問題がなければそのままステータスを終了にする。
- 内容確認して問題があれば、ステータスをフィードバック（差し戻し）にして、予定終了日と作業工数を追加、進捗を100%から下げる。
ポイント
- 子タスクを作ると、その親はただのサマリーとなってしまうので注意。最初からサマリーのつもりなら良いが。
- 進捗入れているタスクの子タスクを作ると、進捗がなくなってしまう
- Undo Redoが出来ないからちょっと操作ミスると悲惨
- 作業途中で何か共有すべき情報が出てきたら、Wikiやフォーラムを使おう。
ちょっと便利
カレンダー上に、下記が出るのが何気に便利。
- その日からやらないといけないチケット。
- その日までに終わらないといけないチケット。
ちょっと触ってみたが、やはり素のRedmineではMS-Projectの代わりに使うというレベルのツールではなかった。
あとは追加のプラグインがどれだけ使えるか。
ちらっと見た感じでは有償のRycheeは普通に使えそうなかんじだったが。
調達マネジメントにおける契約種類
PMBOKでは調達契約の内訳がインセンティブフィー等、いろいろと書かれているが、実際の実務上ではそんのもは聞いたことも見た事も無い。実務上でそんな困ったことは無いが、実際の所PMBOKの調達マネジメントは無視して業務していることに気付いた。
ちょっとここで、実務上（少なくとも日本国内）の調達契約業務とPMBOK上の調達契約の記載の整合性を確認してみよう。
日本国内におけるSW開発における契約種類
日本国内で仕事をしている際には、SW外部委託で検討が発生する業務委託契約の種類は、下記の２種類と思う。
- 請負契約
- 準委任契約
それぞれがどうゆうものかを整理しておく。それぞれの違いは、成果物と費用の関係だと思う。
請負契約
これは仕事の完成を約束するタイプの契約である。このSWをいくらで完成させてくれという契約であって、その過程や、実際にかかった費用は発注側は一切関知しない。仕事の成果物に対しての責任が受注側に発生するのがこれである。成果物完成後になんらかの瑕疵（不具合）があれば、一定期間以内（だいたい1年）ならば受注側は保障の範囲内で修正しないといけない。
準委任契約
業務の完成を保証しないタイプの契約である。発注側が依頼した業務を行っていた場合に報酬が支払われる。
下で説明する委任契約を法律上、拡大解釈したものである。
委任契約
準委任契約は事務作業に関する委託契約である。法律に関する契約をする時には委任契約と呼ばれる。
典型的なのが裁判の弁護の契約。
請負契約と準委任契約の違いは
端的に言えば、仕事を完遂する責任が生じるかどうか
PMBOKにおける契約種類
PMBOKででてくる契約の種類をまとめてみる。けっこういろいろあるが、やはり実務ではみないものである。
契約種類は大きく分けると2タイプに分かれる。
| 契約種類 | 発注側からすると | 受注側からすると |
| 定額契約 | 予算が確定出来る | 予算超過してしまったら損にしかならない。絶対嫌だ |
| 実費償還契約 | 予算がどれだけかかるか分からない。投資判断出来ない | 掛かった分だけ貰えるなら安心だ |
どちらもメリット、デメリットがある。というか、どちらかが安心を得て、どちらかがリスクを背負う形である。
どっちにする？というか、どっちがリスクを背負う？という2択にしかみえない。
発注側か納入側、どちらが強いかの力関係が影響しそうな感じである。
また、金に糸目を付けない。絶対やりきらないといけないPJ。だとすれば、実費償還契約でも良い気がする。
上記のそれぞれ具体的な契約内容をみてみよう。
| 定額契約 | 完全定額契約（FFP） | 普通の定額契約 |
| インセンティブフィー付定額契約（FPIF） | 普通の定額＋パフォーマンス目標の達成度合いに応じた成果報酬 | |
| 経済価格調整付定額契約（FP-EPA） | 普通の定額＋為替変動吸収部分あり（国外取引の場合に使われる） | |
| 実費償還契約 | コストプラス定額フィー契約（CPFF） | かかった費用＋一定額の納入者利益 |
| コストプラスインセンティブフィー契約（CPIF） | かかった費用＋パフォーマンス目標の達成度合いに応じた成果報酬 | |
| コストプラスアワードフィー契約（CPAF） | かかった費用＋パフォーマンス目標達成で貰える成果報酬 | |
| タイムアンドマテリアル契約 | T&M契約 | 単価（時給）だけ決める契約。 |
ビジョナリーカンパニー
ビジョナリーカンパニーについて調べてみた。
ビジョナリーカンパニーとは、ジェームズ・C・コリンズさんが成功したトップ企業のビジョンについて分析した結果を著した全4巻の書籍のタイトルである。
- 『ビジョナリー・カンパニー 時代を超える生存の原則』
- 『ビジョナリー・カンパニー2 飛躍の法則』
- 『ビジョナリー・カンパニー3 衰退の五段階』
- 『ビジョナリー・カンパニー4 自分の意志で偉大になる』
ビジョナリー・カンパニーとは
明確なビジョナリーカンパニーの定義はなさそうだが、おそらくこんなところである。
- 目先の利益より社会貢献し、世界を変える。結果、将来的に会社を残すことを目指している。（３M、Sony、）
- 誰でも聞いて直ぐに理解できる、心躍る行動指針、理念、目標を持っている。（【月に人類を送る】【ロードスターを宇宙に飛ばす】）
- 共通の理念を社員が全員信じている。（かなりブラックな会社のイメージ。）
- 何かの領域で世界一を目指している。
- 目指すべき方向が明確で、そこにそぐわない事には明確にNOといえる。（目先の利益があったとしても）
- 理念を追求することで、利益もついてきている。
※アメリカの3Mは、本業はない。と言われるほどに幅広い分野で活躍する会社であるが、「革新を起こし続ける」という一点において芯が通った会社である。実際に革新を起こし続けて今まで100年生き残ってきている。
怯むほどの目標を持て
わくわくする目標を持て
会社の基本経営理念をベースに大胆なBHAGを
理想の追求か、利益の追求かの2者択一は2流。両方とも実現させろ。
世界一になるには
世界一になれる領域を見つけ出すことが最も大切。そのためには、下記を実施する必要がある。
- 絞り込む（市場、商品、サービス、コンセプトの絞りこみで競合をなくす）
- ずらす（時間、品数、量、頻度をずらす）
- 変える（既存市場の不満に答える。利便性追求、）
いわばーブルーオーシャン戦略である。
ビジョンとは
【ビジョンは道具である。日々の行動基準や、迷った時の判断基準になる。】
経営法務とは
経営法務とは法律である。
テーマは下記の２つ。
- 会社法
- 知的財産
会社法
2企業間の取引（販売、対価支払）では、月末締め、翌月末現金振込みが多い。
A←⇒B
この場合、一定期間はお金を貰っていない一か月間がある。
本当にお金がもらえるのだろうか・・・・・という与信管理が必要。
与信管理とは、取引相手の信用度調査に始まり、支払が滞った場合にどうやって金を回収するかまでを考える事。
個人事業：資金提供者＝経営者
支払問題が発生した場合、経営者の個人資産にまで支払責任が発生する。（無限責任）
恐ろしい。一家離散とかが発生するやつだ。
株式会社：資金提供者＝株主
支払問題が発生した場合、株主には支払責任は発生しない。（有限責任）
大規模事業が出来る理由。こうじゃないと怖くて出来ない。
しかし、じゃあ、相手からしたら誰に責任取ってもらうのか。
そもそも信用出来る会社ですよという点を会社法に規定されている。
会社法は、役員がとるべき行動はこうですよ。と規定している。
会社法で、株式会社は事業失敗時に支払責任取らなくてよい。逆に、会社法によって、株式会社が悪いことをしないように規制されている。財務諸表が信用の拠り所。
株式会社の信用の基礎は財務諸表なので、物的会社と呼ばれる。
経済学・経済政策
ミクロ経済学
経済学の基本。
売り買いの目線で経済を論じる。売（生産者）。買（消費者）。
アダム・スミスは、市場は放置していれば、最も良い状態（市場均衡）になると言っている。
「神の見えざる手」というやつだ。
ここまでは、完全市場を前提として考えている。
完全競争市場とは、情報格差はなく、メーカーによる差別化もない純粋な市場と考える。
しかし、現実はそうではないので、不完全競争市場というのを議論しないといけない。
アダム・スミスがいうようにほっといてもうまくはいかない。市場の失敗。
現実には、独占企業（独占市場）もあって、純粋な完全市場はない。
マクロ経済学
経済学の応用。
国レベルでの経済を見る。しかし、２つの大きな考え方がある。
マクロ経済学には、３つの市場と、６つの登場人物がある。
【市場】
- 財・サービス市場
- 金融市場
- 労働市場
【登場人物】
- 家計
- 企業
- 政府
- 日銀
- 銀行
- 外国経済
