プロジェクトマネジメントについて、簡単に読めて全体像が把握できるような書籍が見つからなかったので、何回かに分けて、ここで書いてみようと思います。多少厳密さにかける部分もあるかと思いますが、よろしくお願いします。
----
プロジェクトとは、高い不確実性を伴う作業で、納期や予算があります。しかし、人間の本能だけに頼ってプロジェクトを進めたのでは、うまくいきません。そこで、うまくいったものを残し、うまくいかなかったものを捨てることで、ベストプラクティスを蓄積していく必要があるわけです。
プロジェクトマネジメントは「高い不確実性を伴う」と前回書きました。なぜ高い不確実性の伴うことをやるのでしょうか。
これは、高い不確実性が伴うものは、他社が参入しにくく、結果として高利益につながるためです。不確実性のないものは、誰がやっても同じになるため、価格競争になりやすいと考えられますが、不確実性が高いものは価格競争になりにくいと考えられるわけです。
では、不確実性は、どのような部分に生じるのでしょうか。
プロジェクトに伴う不確実性ですが、もう一つ「相互依存性」というものも不確実性を大きくします。これは複雑なソフトウェアの開発などでは、非常に重要な問題です。
相互依存性とは、プロジェクトの部品の1つが別の部品に依存しており、独立して設計などをおこなうことができない状態を指します。例えばパソコンの記憶容量を増やす場合、新しいハードディスクに交換すれば済みますが、これは記憶容量という要件がハードディスクだけによって実現されており、他の部品と相互依存性を持っていないために可能となっているのです。もしこれが、データベースサーバの性能を上げたいというものであれば、ハードウェア・ソフトウェアを含めた大規模な再設計が必要になるかも知れないわけです。
プロジェクトマネジメントを導入したら、プロジェクトが早く完了するようになるでしょうか。今回はこの点について考えてみましょう。はじめにお断りしておきますが、筆者は理想的ではないプロジェクトの経験がほとんどで、理想的なプロジェクトについては書籍などから学んだところが多いというのが実情です。これらは今後実行に移したいという状態であるため、裏づけが弱いと思われるところがあるかと思いますが、ご了承ください。
プロジェクトマネジメントを導入すると、一般的に早くプロジェクトが完了するようになるのですが、これは個々の作業が早く終わるということではありません。というのは、プロジェクトには不確実性があるため、不確実性を減らす作業が必要になるからです。
これまでの流れをまとめてみましょう。プロジェクトには大きな不確実性が存在するため、マネジメントのノウハウが必要になりますが、これは高い利益をもたらすことが期待できます。不確実性に対処するには、設計など上流工程に時間をかける必要があります。
さて、不確実性を「未来が予測できないこと」と考えてみると、プロジェクトマネジメントには3つの要素が必要になることがわかります。それは、「現在の状況を把握すること」「目的地を設定すること」「目的地に行く手段を考えること」です。
プロジェクトには複数の人がかかわるのが一般的ですから、プロジェクトを正確に記述して認識を共有することはとても重要です。今回は目標について説明します。
最上位の目標は「現在から将来にわたって、企業の収益を最大にすること」であるのが一般的だと思います(メルクのように、より社会的な目標を持っている会社もありますし、NPOのように利益を目的にしていない団体もあります)。この目標を達成するための手段として事業分野があり、例えば「ハードウェアの単純化が実現できるような、高度な擦り合わせを必要とするリアルタイムシステムの開発技術を持ち、その能力を販売する」のような目標が設定されます。これを達成するための手段として、個々のプロジェクトが存在します。
ここで注意しなければならないのは、目標が同じであっても、そのための手段が同じになるとは限らないということです。手段は、実際に行動を起こす人が決めるのが効率的です。これは、利益を上げる必要があるのはどの会社も同じですが、取り組む事業分野は会社が自分で選択するというのと同じです。
もし、目標が明確でなかったり、手段を上から指示したりすると、どういう問題が生じるでしょうか。
製品やサービスは、顧客に購入してもらってはじめて、企業に収益をもたらします。したがって製品やサービスは、対価以上の価値を持つ必要があります。ここで注意しなければならないのは、顧客が感じる価値や対価は、売り手が理解しているものとは異なる可能性があるということです。優れた製品やサービスを作ったり売ったりするには、顧客にとっての価値や対価をスタッフが感じられる必要があります。
これまで、スタッフが目標を共有することが重要であると書いてきました。しかし、スタッフにも個性があり、それぞれ得意分野が異なるのが普通です。スタッフで情報を共有して、それを効果的にアクションに結びつけるには、適材適所という考え方が必要になります。
ワインバーグのMOIモデルでは、スタッフが力を発揮できる環境を作る能力をリーダーシップとしており、このために以下の3つが必要であるとしています。動機づけ(Motivation)、組織化(Organization)、アイディア(Idea)がそれです。不確実性の高いプロジェクトにおいて、予期しないことが起きたときに頼れるのは人間の適応能力ですから、スタッフが力を発揮できる環境を作ることは重要です。実は、人によってこの3つの分野に得手不得手があります。
成果物の確認方法に「レビュー」と呼ばれるものがあります。今回はこのやり方について説明します。
「レビュー」は、作成者以外の人が成果物を見て、気づいた点をフィードバックする作業です。プログラム・ドキュメントなどどんなものでもレビューの対象になります。普通、複数の人でおこなわれますが、作成者でさえなければ1人でもレビューは可能です。ただし、管理者がレビューに参加すると、人事評価につながるため良くない、としている書籍もあります。
レビューの目的は、修正した方がいいところを、できるだけ早い段階で見つけることにあります。例えば、仕様書の抜け(機能の入れ忘れ)がコーディングのところで見つかったら、すでにコーディングされた他のモジュールにも修正が発生するかも知れません。レビューをおこなうことで、コーディングの前に問題を発見し、修正することができるわけです。
プロジェクトは普通、いくつかのタスクに分割することができます。ソフトウェアを作るプロジェクトの場合、ソフトウェアを分解したモジュールが、個々のタスクに割り当てられることになります。ソフトウェア全体や、個々のモジュールの動作は、仕様として記述されます。今回は、この仕様の書き方について説明します。
まず、ソフトウェア以外の例として、ボルトとナットを考えてみましょう。ナットのネジ穴に、ボルトのネジ部をかみ合わせることで、ナットとボルトで対象を締め付けることができます。別々のメーカーで違う時期に作られたボルトとナットであっても、組み合わせられる必要があります。またボルトもナットも、大量生産される工業製品ですから、精密に作ろうとすると不合格品が多くなり、コストが高くなる傾向があります。このため、ボルトとナットには標準規格(日本の場合はJIS)があり、許容差が決められています。
前回、仕様書の書き方を取り上げましたが、今回は仕様書の情報量について考えてみましょう。
情報学では、情報量を「あいまいさが減る度合い」としています。具体的には、あいまいさが半分になる情報量を1bitとしています。例えば、明日が晴れか雨かわからない場合、「明日の天気は晴れ」という情報は1bitとなります。ただしこれは「晴れ」が50%、「雨」が50%の場合です。もし「晴れ」が25%、「曇り」が25%、「雨」が25%、「雪」が25%であれば、「明日の天気は晴れ」という情報によってあいまいさが1/4になるため、情報量は2bitになります。
プロジェクトには、スケジュールがあります。多くの場合、プロジェクトが始まるときに見積もりをおこない、プロジェクトにどのくらいの時間・費用が必要かを予測します。
ここで注意しなければならないのは、見積もりは予測に過ぎないということです。強気の見積もりを出したからといってプロジェクトが早く進むわけではありません。車でA地点からB地点まで移動するのに、「1時間で行こう」と考えるだけでは何も変わらないのと同じです。
プロジェクトは個々のタスクにわけることができ、タスクを順におこなっていけば、プロジェクトが完了します。従って、タスクにどれだけの時間がかかるかを見積もれば、プロジェクト全体にかかる時間が計算できることになります。プロジェクトを早く進めるには、プロジェクトの遅れにつながるリスクをコントロールする必要があるのですが、これは次回以降に取り上げることとして、今回はタスクの見積もりをうまくやる手法を紹介しましょう。
前回はスケジュールのことを書きましたので、今回は「どうやればスケジュールをコントロールできるか」を書きたいところですが、視点を変えて「どういうことをやるとスケジュールが台無しになるか」を書きたいと思います。
基本的な点として、計画と実績を比較するのをおこたると、遅れが見えなくなります。一度に1日ずつ遅れて、最後には1ヶ月、1年と遅れることになるわけですから、計画と実績を比較することは大事です。プロジェクトマネジメントの経験の少ない組織では、どういったアクションや計画漏れが遅れにつながるのかを学習するのに、計画と実績の比較が役立つと思います。
もちろん、実現可能な計画を作っていなければ、進んでいるのか遅れているのかわかりません。プロジェクトの目標をタスクに落とし込んで、そこから積み上げて計画を作ることが大事です。
プロジェクトマネジメントにおけるレビューですが、天気予報のようなものと考えていただくとよいかも知れません。
天気予報には人工衛星の打ち上げなど多額の費用がかかりますが、天気を好きに変えられるようになるわけではありません。あくまで、未来の天気が予測できるというだけです。しかし、天気に合わせて自分の行動を変えることで、損失を予防することができるようになります。例えば、船舶は嵐を避けられるようになりますし、台風に備えることもできます。
プロジェクトの場合も同じで、損失につながる箇所をレビューによって早期に発見することで、未来の問題に備えることができます。そのまま気づかずに進んでしまえば、取り返すことのできない時間を失ってしまうことになります。
レビューの結果不合格になった場合は、成果物を修正して再レビューするのが原則です(不合格の程度によって、修正後レビューなしで合格としたり、逆にプロジェクト全体を再検討しなければならなくなることもあります)。ただしその結果、あとのタスクをする予定の人が空いてしまった場合には、注意が必要です。
計画を立てるときや、担当者に作業を割り当てるときに、無意識に短めのスケジュールでできるだろうと期待することがあるかも知れません。しかし2ヶ月の見積もりを無理に1ヶ月にしたところで、1ヶ月でできるようにはなりません。レビューは天気予報のようなものであり、未来が見えるようになるが、未来を変えられるようになるわけではないと前回説明したのはこういう意味です。
特に「1ヶ月でやってほしい」のように言ってしまうと、可能性が50%くらいしかなくても多くの人は受け入れてしまうと思います。これはおそらく「認知的不協和」と呼ばれる心理学上の現象として説明できると思いますが、マネジメントにとっては正確な情報が失われてしまうので注意が必要です。
プロジェクトをおこなう上で、指揮系統はとても重要です。しかしこれは、命令によってプロジェクトをコントロールするという意味ではありません。
プロジェクトを進める上で困ることのひとつは、目標などについて軸足が定まらず、現場で判断ができなくなることです。プロジェクトのゴールに不安材料が発生したとき、指揮系統によって適切な決断がおこなわれることは、大きな安心を生みます。
では、指揮命令はどのようにおこなうのがよいでしょうか。私がいいと思うのは、以下のような方法です。ただし、これは私のISTJの選好に依存している面があります。
プロジェクトでは複数の人が作業するのが普通ですから、会議(ミーティング)は避けられません。しかし計画を立てずに会議をおこなうと、時間は長くなり、得られるものは少なくなります。会議は全員の時間を拘束しますから、会議の方が効果的であるものに限定しておこなうべきです。
まず、表情が見えないと伝わらないものは、会って話す必要があります。例えば、プロジェクト目標の意識あわせなど、価値観や感情が関係するものは会議が向いていると考えられます。
リアルタイムな意見交換が必要なものも、会って話すのが効率的と考えられます。例えば、プロジェクトチーム内での作業担当の割り当てをメールで打ち合わせると、返答待ちの時間がとても長くなると考えられます。最近は電話会議やチャットもありますが、筆者は経験がないのでわかりません。
最初にお断りしておきますが、残念ながら筆者は「理想的な会議」の経験はなく、悪い会議の経験や、書籍などから得た知識が中心になっています。
会議の準備ですが、まず「会議で何を得たいか」を明確にします。「会議が終わったときにこうなっていたらいいな」というように想像してみてください。
製品開発の初期であれば、「アーキテクチャの要点についての意見を集め、検証のためのプロトタイプの要件をとりまとめて、担当者を割り当てる」のようなものが考えられます。アーキテクチャの要点といった話題には価値観が入ってきますから、会って話すのが有効と考えられます。会議が終わったときには担当者が決まり、アーキテクチャの要点が理解できるようなプロトタイプの開発がはじめられることを期待しています。
製品リリースが近くなれば、「未着手の機能のうち、製品に取り入れるものと、その担当者を決定する」といったものになるでしょう。これも価値観が関わりますし、担当者を任命するのではなく、適任者に立候補してほしい場合には会って話すのがよいと考えられます。会議が終わったときには、それぞれの担当者が担当分の作業を開始できることを期待しています。
次に、会議以前にできることはないかを考えます。参加者が8人を超える場合、減らすことができないかを検討するとよいでしょう。無理に減らす必要はありませんが、例えば進捗報告と技術打ち合わせが1つの会議になっている場合は、分割すると人数を減らせる場合があります。人数が多くなると熱のこもった議論がしにくくなりますので、難しめの議題には向きません。
これまでの内容をまとめてみましょう。プロジェクトで大事なのは、明確な目標を共有すること、現状を正確に認識することです。このための手段として、会議やレビュー、仕様書などを説明してきました。また、性格タイプや認知的不協和などの注意点も紹介してきました。
今までこれらをやっていないが、現状に満足していなくて、改善したいと考えている方もいらっしゃると思います。これからはじめる場合、以下のようなところから着手してみてください。
まず、自分自身が日記をつけます。ワインバーグの本から引用しますと、「たったいまから三箇月間、個人的な日記をつけるのに毎日五分間使うこと」となります。以下の点に注意してください。
- 必ず毎日書かなければなりませんが、同じ時刻に書く必要はありません
- 1文字も書かなくてもいいので、5分間の時間を使ってください
- webのように公開されたものではなく、プライベートな日記としてください
- 過去の内容を修正してはいけません
- 書く内容は、起こったこと、感じたことなど何でも構いません
これは毎日5分を費やすくらい、改善に真剣かというテストでもあります。そして、あとで日記を読み返すと、とても多くのことが学べます。
今回は計画立案について書いてみます。開発系プロジェクトの場合、リスクの大きさによって計画の立て方が変わるのが普通です。
もし過去に取り組んだものによく似ていて、不確実性がほとんどないという場合は、プロジェクトというよりもルーチンに近くなります。従って、前回の実績を元に計画を立案することができます。しかし過去に取り組んだものであっても、部品のバージョンアップなどが含まれていると不確実性が高くなりますので、注意が必要です。
逆に、新しい解決方法を製品に採用するような場合など、新技術が期待通りに機能するのかどうかがわからないケースもあります。このような場合は、開発の優先順位を決める必要があります。
タスクレベルのでの計画ですが、筆者の好みのやり方では、まず適切なサブゴール(マイルストーン)を設定します。このとき、サブゴールに求める役割には、以下の3つがあります。
最初に「製品が完成してお客がニコニコと使っているところまでを想定」します。当面のサブゴールは例えばプロトタイプかも知れませんが、最終的なゴールを常に意識することはとても重要です。
次に「動いているところが見える」という点も重要です。これは無理に動かすということではありません。タスクが作業完了になっていくに従い、動いているのが見える部分が増えていくと、安心できるということです。プロジェクトによっては動いているようすを見せるのが難しく、最後まで進まないと見えないということもありますが、この場合は最後になって驚かされ、手戻りが発生するというリスクがあります。リスクを減らすために、タスクを追加して可視性を確保することを検討します。
最後に「情報収集」という役割があります。これは、やってみなければわからないような技術分野であったり、顧客に見せてみないとわからないものであったりします。前述の「動いているところが見える」というものもこれの一種と考えることができます。もし、今ゴールが見えていないプロジェクトであれば、ゴールに関する情報を見つけるのが最優先になります。
これらはすべて「リスク管理」と考えることもできます。
今回はクリティカルチェーンと呼ばれるプロジェクトマネジメント手法を紹介します。クリティカルチェーンは、TOC(制約条件の理論)におけるプロジェクトマネジメント手法で、不確実性にどう対処しているかという点が参考になるかと思います。
まずこれまであったCPM(クリティカル・パス・メソッド)について説明します。CPMでは作業(タスク)のことをアクティビティ、作業と作業の中継点のことをノードと呼びます。ノードを「○」、アクティビティを「→」であらわすので、「○→○→○」のような図になります。個々のアクティビティの作業時間を見積もると、そこから全体の作業時間がわかります。普通、開始と終了のノードは1つずつですが、途中は枝分かれしたり合流したりします。
さて、アクティビティどうしが関連を持っており、AとBのアクティビティが完了しないとCのアクティビティが開始できない、といった場合があります。そこで、個々のアクティビティに「予想通りに進めばいつ開始できるか」の数字(最早開始時刻)を書き込みます。アクティビティが合流するイベントでは、もっとも遅いアクティビティ完了の予定が書き込まれることになります。さらに、これの逆をおこない、プロジェクトの完了から逆算して、「いつまでに開始すれば予定通り完了できるか」の数字(最遅開始時刻)を書き込みます。アクティビティの最早開始時刻と最遅開始時刻に差があれば、そのアクティビティで予定以上に時間がかかってもプロジェクト完了は遅れないので、この差をフロート(余裕)と呼びます。アクティビティの最早開始時刻と最遅開始時刻が同じだとフロートが0になり、このアクティビティが遅れるとプロジェクトの完了が遅れてしまいます。プロジェクトの開始から終了まで、フロートが0のアクティビティを順につないだ経路(パス)を、クリティカルパスと呼びます。CPMはクリティカルパスが遅れないように、重点的に管理をおこなう手法です。
クリティカルチェーンは、CPMやPERTに対して、バッファーマネジメントとリソース競合対策を追加することで、不確実性に対応したものです。
プロジェクトはいくつものタスクに分割することができます。では、タスクの時間の見積もりはどのようにおこなうのがよいでしょうか。残念ながら、筆者はまだこれについて確固たる答えを持っていないので、参考になりそうな考え方を紹介します。
普通、作業者は直感的な見積もりができますが、かなり不確実であることが多いと思います。これは「考える仕事」の度合いが大きいほど、答えが見つかるまでの時間のバラつきが大きく影響するということだと考えられます。一般的な計画立案では、考える度合いの大きい設計作業をプロジェクトの前半に置き、開発から切り離すことで、見積もりのブレを早期に発見できるようにします。
仕様や作業計画に「抜け」があると、見積もりが外れやすくなるという問題もあります。これは、ある作業を見積もりに盛り込むのを忘れていたというケースと、ある仕様を考慮するのを忘れていたというケースとがあります。後者の場合、その仕様を追加するのに大規模な変更が必要になる可能性があるので、前半(上流工程)で見つけられるような仕組みを用意することが重要です。
これらは、日頃の習慣でもある程度はカバーすることができます。
ブログ「三田ブログ」のカテゴリ「Project Management」に投稿されたすべてのエントリのアーカイブのページです。新しい順番に並んでいます。
前のカテゴリはMovable Typeです。
次のカテゴリはSwitching Costです。