富士山と夏休みの宿題と全体最適

先週は、日本に来たばかりの研修生をつれて富士山に行って来た。実は、富士山がきれいな山だというのは、知ってはいるものの日本人である私でも富士山に登るのは実ははじめてだった。
（ちなみに今日の朝礼参加者の半分は、私と同じように富士山に登ったことがなかった。）
富士山に登るには、御殿場か三島からバスかなにかということになるのだが最初の計画では、駅レンタカーでと考えていたのに、前日予約ができていなかった。そもそも、夏休み最後の週末だから、忙しいお父さんが手っ取り早く電車（三島は新幹線でも行ける）と車で富士登山という構図はなんとなく理解できる。（それは、もしかしたら彼氏と彼女も同じかなぁ?）まだ、日曜日は宿題対策の為か、車が空いていたので無事に富士山に登頂（５合目までですが・・・）できた。これも学生症候群のおかげかなぁなどと考えた。

CCPM（クリティカルチェーン・プロジェクトマネジメント）は、不確定要素の多いプロジェクト型業務に、TOC（制約理論）の基本原理を適用したプロジェクト管理の手法である。制約条件の下、プロジェクト各工程の締め切り厳守を積み上げるアプローチではなく、プロジェクト全体の納期を守ること（あるいは短縮すること）を目的としている。提唱者はエリヤフ・ゴールドラット(Dr. Eliyahu M. Goldratt）博士で「ゴール」という小説がこの理論で書かれているのは有名です。、「ボトルネック工程がラインの全体スケジュールの制約条件となる」というのが趣旨ですが、日本では、ビーイングの岸良さんがよくテーマとして取り上げておられます。

そのなかに、学生症候群・・・納期のある作業を行う際に、最初に余裕があればあるほど、実際に作業を開始する時期を遅らせてしまうという、多くの人間に見られる心理的行動特性。「期間が足りないと主張して提出期限を延ばしてもらったのに、すぐには宿題を始めない学生」になぞらえて説明したことに由来する。とパーキンソンの法則・・・英国の歴史学者・政治学者であるC・ノースコート・パーキンソン（Cyril Northcote Parkinson）が唱えた法則で、狭義には「仕事は、その遂行のために利用できる時間をすべて埋めるように拡大する」（人は、時間があればあるだけなんかに時間を使っちゃうもんだ）という金言（思い当たる人は多いだろうなぁ）があった。この話、岸良さんが講演や著書で何度も話をされているのだが、「人間はこういうもんです。」確かに。

ＣＣＰＭは、だから細かくスケジュールをしてクリティカルチェーンを明確にし、全体のバッファをおいて管理しましょう。と提唱している。プロジェクトという不確定度の高い作業を行う場合の人間心理や行動特性、および社会的・組織的問題に配慮して、全体最適なプロジェクト管理（スケジューリング、タスクの実行、進捗管理）を行うことが大切であることそれが、実践では役にたつということを力説している。その為には、全体のマイルストーンや全体の作業の曖昧性をどうやって回避するかが大切になってくる。

ゴールドラット博士によれば、作業の所要時間見積もりの確度を90％としたとき、それが50％だった場合の見積もり時間は90％の3倍、なーんと実質の2倍以上のゆとりを確保しようとする（ゴールドラット）。そういった肥大したスケジュールで、作業着手を先延ばしする学生症候群を引き起こし、結局は遅れが生じたり、早期に完了しても計画上の終了日まで次工程に引き渡さないパーキンソンの法則が見られたりなどの問題が発生すると最初の工数の２倍3倍かかるのは当たり前のことになってしまう。

コスト超過だけで品質が保たれればまだよい方なのだが、よくよくこういうプロジェクトを観察していくと必ずしも時間をかけたから品質が上がるということにはならない。（考えてみてね。決まるまで時間がかかるんだから製造品質なんか良くならないよ。遅れた時にも言い訳もできないから、報告もできないじゃない。悪循環だよね。）これが、つもり積もって管理されない状態になってしまうのかしらと考えたりした。

実際の作業がわかるスケジュール管理、ＷＢＳの精度向上と教育としつけが大切であるということになるのかしらと考えた。それが、結局はゆとりのある人間的な開発に繋がり、良い品質に繋がる。それこそが、お客様のビジネスを支える為に必要なことだと思う。
我々の目指す技術は、お客様に高い付加価値を与えるものでなければならない。その大きな助けとなるのは、情報共有とプロジェクト管理の技術であり知識、知見というものではないだろうか。ＣＣＰＭに限らず、チームで情報共有して刻々と変わるプロジェクトの状況を把握し的確な判断を下すことは「全体最適」を図るということに繋がる。いかなる場合でもそれが大切である。

何事も、行き当たりばったりじゃあいけませんね。目的（ミッション）を理解して目標を定めてがんばりましょう。

プロジェクトも各仕事もＰＤＣＡサイクルで深化する

プロジェクトは、特定使命をもち、特定期間、特定制約のもとで行われる価値創造活動と定義されている。（Ｐ2Ｍの定義）そうして、プロジェクトはあらかじめスコープというものでその範囲を定義される。これはＰ２ＭとＰＭＢＯＫでも変わらないこと。スコープを表す為にＷＢＳ（ワーク・ブレイクダウン・ストラクチャー）というものがあるというのは何度かこのブログでも説明してきた。
今日は、それが各自の仕事に対しても毎日の仕事に対しても、同じような形をしているというお話をしたいと思う。簡単に言うと、毎日の仕事で学べるプチプロジェクトマネージメントの基礎ということになるかも。

ＷＢＳは、だれが、いつ、なにをするかを表すＷＰ（ワークパッケージ）から構成される。その下の作業手順はアクティビィ（作業）と呼ばれ、ＷＢＳは、そのツリー構造の全体で漏れなくプロジェクトの範囲を表している。ここでのポイントは実は、ツリー構造で表すというところにある。
ＩＴ業界と他の業界の大きな違いのひとつに形のないものを創っているということがあるとよく言われるのだが、最初から細かく実作業を洗い出すことはできないというのが、いまやこの業界の特徴のひとつと考えられている。段階的詳細化(Progressive Elaboration)は、この観点から考えると必然性のある方法なのだと思う。プロジェクトの基本属性のひとつにある不確実性というものを考えた時に進捗が進むことと詳細化が進み、作業とスケジュールが明確になりプロジェクトが実験していく仮定は、このＷＢＳが詳細に確定していくことで計ることができる。

ＷＢＳは、ひとりひとりが実際に作業を実現することができるレベルまで詳細化すること・・・少なくとも、人と期間と作業が明示され、理解することを計る情報でもある。その担当者が自分の担当範囲を曖昧なところを残さずに理解して、すぐに作業に入れるということをＷＢＳを立てている人は想定している。しかし、知的労働であるソフトウェアの開発では、この曖昧なことを残さずというのを実現するには調査の時間をとらなくては実現できないこともある。その調査や方式検討の時間をどれだけ密度を上げて最善の方法を採用するか・・・これは、我々の仕事ではとても重要なことだと思う。必ず、２つ以上の方法を考えて簡単な作業に分割し、それぞれにかかる時間とリスクを鑑みて考えうるうちで最善の方式を選択する。これはとても大切なことだと思う。

ひとつのツリーの末端の作業であれば、自分でその方法を考えて判断し実行することになる。それがひとつひとつの仕事に対しての計画と考えてみてほしい。プロジェクトでは、そのツリーのいろいろなところで、そういう検討が行われ常に考えうる最善の方法を採っていく・・・大きな問題の場合には、当然隣り合ったツリーの責任者も同席して決定することもある。しかし、問題を深耕して、分析し、決定するということは同じだし、実行した後で、その計画とどのように違っていたか、どのような問題があったかということを考えて、情報を共有化することも・・・一つ一つの仕事においても同じことだと思う。Ｐ２Ｍでは、計画時点でその効果も一緒に判断して計画することを提唱しているが、たとえば、そのひとつのパラメーターである時間だけでも、常に意識して計画との差異を押さえておくことが、大切だと思う。そういうひとつひとつの積み重ねで、計画を正確に立てることができたり、もっと効率のよい方法が見つかったり、悩んでいたことの解決法を見つけたりするのではないか・・・今の仕事をより深化することで、より早く仕事の達人に近づけるのかもしれない。

ひとつひとつの仕事が、次の自分の未来に繋がっている・・・
まずは、今日の仕事の計画からはじめてみましょう。
そうして、夕方にはその差異の理由を考えてみよう。明日のために。

「時を手に入れる/時間は何事にも代えがたいもの」

「時を駆ける少女」という小説が流行ったころ、時間と空間を旅することができたらどんなに幸せなのかと思った。歴史上の人物、例えば「聖徳太子」とか「上杉鷹山」とか・・・会いたい人が沢山いた。そう・・・なによりもほんの２か月前に戻ることが出来たなら、打つ手は沢山あると思うことも多かった。それは、最近も全く変わりは無い。そんな話を今日もしてみる。

1.ＱＣＤのトレードオフを管理することの重要性
ギリギリのスケジュールで受けたシステムでお客様からの仕様が出てこなかったり、不足していたような場合。あるいは、終わり近くに変更を頼まれた場合など。納期と品質に影響が出ることをお客様に説明しているだろうか。「すこし、納期と品質に影響がでます」とか「納期はなんとか行っても、品質に問題がでます」・・・そんな説明では、インパクトの大きさが伝わらないことは言うまでもない。「時々、システムダウンするかもしれません。」「ＤＢのチューニングが間にあわなくて検索して30秒ぐらい戻って来ないかもしれません」・・・・「お客様にリリースする品質が担保できません」ここまで言える人は少ない。「・・・・やってみます。」って言うのが許されるのは、ベンダーの下請けだけで（それでもダメな時もあるけど）エンドユーザのリリースまでの時間には常に限りがある。納期は、必ずやってくる・・・そして、品質のつけは「無償対応」という形で会社にひいてはみなさんに影響を及ぼす。だから、プロジェクトマネージメントが重要なのだと思う。しかし、プロジェクトマネージメントが正しく行われる為には、条件がある。それは、管理する対象・範囲が常に明確でなければならないということ。

2.プロジェクトの特徴・・・不確実性の高い期限のあるもの
プロジェクトの特徴は、「特定使命」「特定期間」「特定制約」、そして基本属性は「個別性」「有期性」「不確実性」、プロジエクトの要素は「スコープ・品質」「期間」「資源」。これはＰ２Ｍで定義されているものだが、不確実性の高い、期間の決まったものがプロジェクトであることはどうも揺ぎ無い事実のようである。その、スコープを定めるのにＷＢＳ（Work Breakdown Structure）というものが使われる。これは、ツリー構造で目的とする仕事を分解して表現することで細かくも全体的にも範囲（Scope）が把握できるという優れもの。段階的詳細化(ローリングウェブ)というのはこのこと。最初は骨組みだけで、詳細が決まったら徐々に詳細なＷＢＳに追加され変わっていく。この段階こそが、プロジェクトの不確実性をコントロールする為の重要なポイントなのだと理解してほしい。

3.ＷＢＳからスケジュールに与えるインパクトを計る
1.のような状況に陥った時にＷＢＳのレベルで作業の見積時間まで予測している人はいるだろうか？最初に、正しくＷＢＳがたてられていたならば、そんなに大変な作業ではないのだが一般的に、こういう変更のあるスケジュールの厳しいプロジエクトであればある程、ＷＢＳは貧弱で使い物にならなかったりする。理由は、ツリーを追いかけても大元の作業にリンクしていないからなのだ。（スケジュールの真中に作業を追加すると醜いから追加作業という枝を起こして、全部まとめて別のツリーにしている人までもいるぐらいだ。）これでは、最初の大枠で決めたこととなにが違っているのか、何が追加されているのか、なかなか把握することはできないだろう。（もしかしたら自分でも、正確には把握できていないかもしれない。）
インパクトをプロジェクト全体に対して計ることは難しい。だからこそ、日頃のひとつひとつの作業の「見える化」が重要だと思う。

ＷＢＳは、基本的には使いまわせるものだから（使いまわせるものにしてください）今日からでもきちんと更新し作業の詳細化を行うようにしてみてはどうだろうか。明日の自分の為に・・・今の自分の仕事はヤドカリのお家のようなものだと思う。次の仕事に進む時に次の誰かにきちんと渡せなければ、能率や品質が下がるのは自明の理だと思う。最近、忙しいと悲鳴をあげているあなた・・・思い当たるところはありませんか。

心をなくさないように・・・ＷＢＳはワールドビジネスサテライトではありませんからね。
今週もがんばっていきましょう。

「2006年 今年最後のメッセージ・・・」

全体研修のプロジェクトマネージメント研修のまとめについて書いて欲しいというリクエストを以前から頂いていた。このまま、今年も終ってしまうのもどうかと思うので約束どおり、最後に少しまとめを書いてみる。

プロジェクトゲームは、３～５人のチーム分けを行い４チームで1グループを作ってスタートする。最初にプロジェクトの目的とルールを書いた紙と作業のベースとなるボードと50枚ぐらいのカードを渡される。それぞれのチームの中で、リーダーとコストコントローラーとスケジュールコントローラーを決めるところからスタート。目的をそれぞれのチームで理解し役割を決めてゲームを始める。全体のコストは120万円。計画段階のコストは、毎分15,000円／人で実施段階のコストは、毎分75,000円／人つまり1対5という定義である。渡されたボードを見せ合わずに言葉だけでコミュニケーションを取り合って4チームのボードの模様を一緒にすることがこのプロジェクトの目的である。今回は、グループが5つ、それぞれの開発部門のグループと営業+北京組でひとつそれぞれに４つのチームがいるという構成。プロジェクトのオーナーは、出題した先生で、プロジエクトマネージャは各部門長という状況だった。

このゲームを一般論的なプロジェクトマネージメントの観点から私なりに進め方を考えて実際の問題点などを考えてみた。

◆ 目的を理解して全体のコストから大枠の計画を立てる　◆
計画時のコストと実施時のコストが１対５なので、実施にかける時間を最短にする必要がある。まず、目的を具体的にイメージできる様に理解し現状を把握し時間の枠組みをつくる。
やらなければならないことはなに？
①４つのグループで同じ模様にする為にはどんな条件があるか？
・カードは同じものが全部のグループにあるのだろうか？
・ボードの欠損個所は同じなのだろうか？
・全体の絵はもともと同じものなのか？
・ゴールはどんなことなのか？
②上記の4つの作業が現状分析のＷＢＳと考えられるので、そのマイルストーンを決めてスケジュールを立てる。おそらく、その予定された時間では終らないとかいろいろな問題があるかもしれない。。。
③時間を決めて調査した結果を持ち寄り、プロジェクトマネージャが方向づけを行う。
ポイントは、なにがなんだかわからない状況なのだからそれを各々のチームで調査して持ち寄って定義するということ。わからないから明確にすることが大切。ここでの質問も大切だが、現状はプロジェクトオーナーもわかっていないことがある。

◆　現状分析をどのように行うか・・・ありのままの姿を数値化する　◆
現状、４チームは相手がどんなカードを持ちどんなボードの状況であるか知らない。作業はどうするか？
①カードを種類毎に分けて枚数や数値の状況を調べる必要がある。
②ボードの状況をお互いに伝え合う必要がある
③コミュニケーションが取れるような配置と場所、会話する人を決める必要がある
④スケジュールコントローラーは、決められた時間を通知する必要がある
イメージはつかめたか？つかめないが作業の方向は決められるか？いろいろな場合がある。今回のトップだったチームはほとんど計画の時間を使ってはいなかった。いわゆるアジャイルのように目的はわかった、まずやってみようっという乗りで声を掛け合う人を決めてスタートしている。（しかし、この点は最下位チームも同じ）プロジェクトの進め方を決めるには問題の複雑性とリスクを判断することが重要である。逆に時間は置いといて、コストに着目したのがブビー賞の営業チームで長い時間をかけてなにがどうなっているかをコミュニケーションした為に時間はかなりオーバーでもコストは予算内であった。惜しむらくは、営業チームなのにプロジェクトオーナーへの質問がほとんどなかったこと。コミュニケーション力をもう少し発揮すれば、十分時間も短くできたはずだと思う。

◆　ゴールを定める方法を考える・・・あるべき姿を言葉で表現する　◆
分析の結果、どのような模様にするかということが決定できると思う。これがゴールであり、あるべき姿なのだが、今回は絵に書くといったことが出来ないから言語化して伝えることが重要。特にボードの向きと既にあるカードの種類と数などは分析の時にわかっているはずなので、チームでベースラインを定めることから作業していくことができるはず。この時点で、最初のスケジュールを少し詳しく追加することができる。
①ボードの状況や向きを合わせる
②既にセットされているカードを同じ状況にする。（ベースラインをあわせる）
③空いている個所に全部のチームにあるカードを置いていく必要がある。
分析が、しっかりされていないとこのゴールとそこに至る手順があいまいなままなので実施段階でいろいろな問題が発生する。その都度、意思決定を行うことになってしまうので複雑だと不整合に繋がる。ただ、分析に要する時間も実施に要する時間も時間というファクターでは同じ物なので納期とのトレードオフを判断しプロジェクトマネージャは計画をどこまでで切り上げるかという大きな意思決定を行う。このゲームの正解は、コストに着目して分析と計画に時間を使って実施時間を短くすることなのだが・・・現実は、計画しないで進んだチームが一番早かった。

実は、逆転できるとしたらここは大きなポイントだったのだと思う。そして実際なら、オーナーに模様についての質問や確認があるべきだったと思う。白いところを残してもいいのか？既にセットしてあるカードの上にカードを置いてもいいのか？これから実施する作業をイメージしていろいろな方法を考え、お客様に確認する。ここまでに時間が押していたとしたら・・・・納期を優先すべきか、納期の遅延が許されるのかの質問もあるかもしれない。たとえ、白一色の先生が最後に仰ったようなボードになったとしても、納期を優先しなければならないというケースもあるかもしれない。・・・その答えは、その判断は実はお客様とプロマネしかできないことなのだ。

しかし、最初のほうで白一色にしてしまって納期を守るか、納期を少し遅らせるか？とオーナーに聞いたならば、事の重要さにもよるが、両方ダメっといわれることもあり得るだろう。プロジェクトマネージャーは、常にステークホルダーの利害がどのような状況にあるのか考える必要がある。そして、想像する力が必要だ。メンバーの疲労度とか実現可能性の判断なども必要である。全体を見て、その壁の模様の重要さを判断することになる。これがプロジェクトの優先順位をつけること。ＣＦＳ（クリティカルサクセスファクター）としての模様の位置付けが重要だと思う。

ボードの模様について、「同じ模様にする」というだけの定義は曖昧でそのままでは作業できない。どういう方法が一番早く同じ模様になるのか・・・幾つかの方法を考えてみただろうか。この考えるというフェーズが設計にあたるのだと思う。ここに考えが及べば、勝ったようなもの。定義が曖昧だということは勘違いする可能性も秘めている。短い時間でどれだけいろいろな方式を考えられるか、そしてそのなかの最善である方式を決定して、メンバーに言語化して伝えなければならない。（最善は、最高という意味ではないＱＣＤの観点で最善の方法を決定する）・・・今回は、この工程をみんなかなり飛ばしてしまっていて、検討せずに思いついた方式で進めてしまった気がする。ゴールはどこか、そのゴールを定義してそのゴールに最短で至る方法を明確にし共有する。それがチームプレーでは重要なことなのだと思う。定めたゴールこそが、このプロジェクトの最優先事項になるのだ。

◆　実施・・・問題が起こった場合の判断　◆
実施にあたっては、流石に手馴れた感じだった。だれがリーダーシップを取って決めていくか？チームごとの回答はだれがするか？読み上げたカードを探してボードに置くのはだれか？というところを決めて、手際よく作業をこなしていたように見えた。ただ、チームのリーダーが集まって情報交換するということを行うのであれば、チームリーダーは経験のある人が出てこなければ迷走するだろう。若い人に道を譲るにしては・・・少し若すぎるリーダーも多かった。これは計画時にそれぞれの作業をイメージしてきちんとした体制を取れたかということに繋がる。適所適材を考えなければ時間を短くしてプロジェクトを成功に導くことはできない。

確かにプロジェクトマネージャが、全チームに声を掛けて進めていたところは早かった。途中で、分析不足計画不足の皺寄せか、ボードの方向の違いや模様が同じにならない箇所があったりといろいろな問題が起こってきた。その対応も、それぞれまちまちだったのだが、時間を優先して、辻褄があわないところを飛ばして進めていったところが、最も早く完了したようである。同じ問題にあった時に、状況が把握できずに最初の現状分析まで戻ったチームが最下位だった。進めながら考えるということは、かなりセンスがいることだし、複雑性が増すと難しい。リスクも高い。しかし、問題を仮に記録だけして置いておいて、残りを進めながら状況を把握していくという・・・素晴らしくリスキーで効率的な方式に賭けたチームが一位だった。ほとんどおなじ計画の時間だっのにと・・・この点は興味深いものがある。実際のプロジェクトも同じかもしれない。成功と失敗は紙一重なのだ。そして、不確実であってもリスクを最低限にしてＱ（品質）Ｃ（予算）Ｄ（納期）を守っていくことが我々のプロの技術であり、計画を立てるのはその為なのだと思う。調査と分析に基づいた計画を立てれば一番で無くとも、おそらく時間内にコストを押さえてプロジェクトを終了できる。そうでなければ、運の良いプロマネかカリスマプロマネしかプロジェクトを成功させられない。

◆　コンカレントにできる作業を随時平行で行う　◆
コンカレント開発とは、平行にできる作業を同時に走らせて時間を短縮する方法。例えば、基本設計中に開発のプロットタイプと、画面とＤＢと共通開発を別々のチームにして平行で走らせるようなもの。上記の例でいえば、分析の時にカードを種類別に何人かで調べる作業を行ったり、ボードの状況を伝え合う作業とも平行に出来たりする。遅かったチームのひとつであるプロマネが言っていたことで、メンバーがカードをちゃんと机に並べてなくて、言われた後全部から調べて置くから時間がかかったとのこと。流石にエンジニアのチームはどこも几帳面にカードを種類別昇順に並べていたので、実施時間は短くできたようである。

ことしの最後にとても長いブログになってしまったが、このプロジェクトゲームは実は本当のプロジェクト開発を効率よく行う要素がかなり圧縮して含まれていたと思う。問題を定義し、ゴールを定め、オーナーと合意したミニマムの要件で実施方式を決定しスケジュールを決める。問題が起こった場合には、プロジェクトマネージャの意思決定に委ねるが、常に納期と要件（品質）を考えて決定することが重要。プロジェクトマネージメントのＱ（品質）Ｃ（コスト）Ｄ（納期）を管理するということは、時間との戦いであり、お客様の望むものをどう言語化し共有するかということだと思った。

全く同じ問題を同じような５つのグループで実施してほとんど計画段階での差はなかったのに、倍の時間がかかっている。これは、マネージメント能力の差なのだろうか？・・・いやいやそんなことはない。プロジェクトマネージメントの計画がないということは、成功するのも失敗も、神様だけが知っているということなのかもしれない。不確実だからプロジェクトなのでしょうと言う人もいるけれども、いかにその不確実性に影響されないようにできるか・・・それは、スキームの開発や計画段階の調査によるところが大きい。それとなにより、目的が正しく定義され共有されているということが重要なことなのだと思う。実は終るまでゲームの内容を詳細に理解できていない人が多かったように思う・・・それでは、最短のシナリオが書けるはずはない。

時間はとても大切なもので取り返せないもの・・・今年最後の日につくづくそう思った。

「賢く働くことで激しく働くことに代える」　フレデリック・テイラー
半年前の全体会議の年度目標でこの話をしたことを覚えている来年こそ、この賢さ科学的な管理に基づいたプロジェクトマネージメントでみなさんが幸せになれるように・・・祈りを込めて最後のメッセージとして送ります。

2006年は、みんなの努力のおかげでとてもよい年で終ることができた。ありがとう。
2007年は、協力してもっともっと良い年にしましょうね。

「2006年度全体研修を終えて」

今年の全体研修は、いつも学校で教えて頂いている私の行っているＭＯＴの武富教授にプロジェクトマネージメントの基礎を教えて頂きました。出席できなかった人は本当に残念でした。金曜日の武富教授の授業は、100分の講義と1時間弱のプロジェクトマネージメントゲームという構成でしたので、私や法本君が今まで教わってきた時間の30分の1にもならない時間です。しかし、内容はポイントを整理してあったのでとてもわかりやすく勉強になったと思います。若い社員も多いのでいつもの授業よりゆっくりと丁寧に教えて頂けたと思います。みなさんにも理解して頂けましたでしょうか。ＥＶＭの計算式は知っていても、本来の意味が判らないようでは困る・・・というメッセージなのかもしれません。（わからなかった人は、復習しておきましょう）

どうして、今プロジェクトマネージメントなのか。みなさんは、理解して頂けましたでしょうか。アメリカのソフト開発はほとんどインドに変わってきている・・・そういえば、2005年度のＩＢＭのキックオフ大会がインドだったのでアメリカ国内で物議をかもしたというようなことを聞いたことがあります。（それでもＩＢＭの回答が素晴らしくて・・・我々は、アメリカの企業ではなくワールドワイドな企業である。今、世界の中心はインドだ・・・）日本企業は、ベトナムや中国、韓国といったところに発注することが多くなって来ています。物価が中国は1/5、インドは1/10とかよく言われていますよね。ガートナーの調査では2010年までに1/10のソフト開発者が職を無くすといわれています。それは、インドの技術者なのか中国の技術者なのか・・・我々日本の技術者なのか今のところ、その根拠も含めて全くわかりはしません。ただ、我々は彼らよりコストが高い・・・世界中のどこよりも高いかもしれません。そんな私達のサービスレベルを向上する為にプロジェクトマネージメントは必要な技術です。（インドの大きいソフト会社はほとんどＣＭＭのレベル5を取得しているそうです。）

今回の研修で、ＱＣＤのトレードオフの関係の難しさがわかったり、各業務の責任者全員の「ＱＣＤを守る」という意識が必要であること、コミュニケーション／プロジェクト内のチームビルディングが重要であることを教わりました。これらの一つ一つが、みなさんの無駄な仕事を少なくすることにも繋がるように思います。プロジェクト管理こそが、「技術とおもいやり、豊な人間性」を実現する為に必要なツールであるとは思いませんか。・・・特に今回、計画を立てるというところと契約を理解するというところを説明して頂けたのは、いろいろと私が相談していたからだと思います。このあたりは我が社のウィークポイントですがよくご理解頂けましたか。（そして対策しましょうね）

私が、今まで先生から教えていただいたことの中で、全ての根幹と言えるような定理があります。
・常にどうすればあるべき姿に近づけるか、結果を出せるかを意識する
我々ＩＴ技術者もプロフェッショナルである為には、こういう姿勢を持って仕事に望みたいと思います。私も最近、技術者としての自分の考えではなく、もっと高い視点でどうすることがお客さまの目的に添っているのかを考えるようにしています。そして、それを効率よくする為に先生は最初にゴールを定めるところからはじめるということを教えてくださいました。ゴールとは・・・成果物、満たさなければならない要件などです。私達が、ＱＣＤを管理することも結局はお客様のビジネスに影響を与えない為になのです。

そして、もうひとつ先生がいつもいう口癖があります。（我々はこれにいつも玉砕なわけですが・・）
・答えはひとつじゃない・・・
これには、続くことばがあります。もう私は暗記できるほど何度も言われましたけど・・・。「答えはひとつじゃない。だからこそ常に与えられた条件下で最善の選択をしなければならない。その根拠は、数字です。過去を語る時も、現在を表すのも、仮説を立てて数字で表してみてください。そして、未来を語る時にも、数字で語ってください。数字は嘘をつきません。必ずそのままの姿をありのままの姿をあらわしてくれます。」

先生は、今までいつも経営企画室の人達やＭＯＴの生徒を相手にしていたので今回のように若い人ばかりの講義はとても面白かったそうです。・・・ありがとうございました。

プロジェクトゲームのほうは、みなさんのまとめを頂いてから、来週にでも感想を述べたいと思います。

今週も宜しくお願いします。

ＩＴサービス業のプロジェクトマネージメントが難しいわけ

私が教えて頂いているプロジェクトマネージメントの先生方の間では、ＩＴサービス業のプロジェクトマネージメントは10年以上遅れているというのがもっぱらの定説。ドックイヤーとか、35歳定年説などとかくスピードに物言わせて先進的なことをしているようなイメージがあるこの業界なのにどうしてプロジェクトマネージメントの領域の遅れが目立つのだろうか。

ＩＴサービス業における優秀なエンジニア、プロマネというのは凡そスーパーマン（スーパーウーマン）のイメージである。どうスーパーマンなのかと言えば、最近の言葉で言えばアーキテクト、アナリスト、マネーメントの三位一体の人間が優秀なプロマネといわれている。これが、例えばプラントや建設業とは大きく違っているということをよく聞く。プラントの場合、見積、設計、購買（ほとんど全世界で造った物を必要な機能にあわせてスケジュールにあわせて購入していく仕事）、土木、建設と言う具合にそれぞれのスペシャリストを集めて仕事をする。また、アメリカではアナリストの部分である分析や戦略は、ビジネスコンサルタントの領域でその下でＩＴコンサルタントの領域があり、システムはその下流の部分・・・いわゆるシステム化の部分を受け持つことで明確に住み分けされていると聞く。だから、この三位一体のスーパーマン問題は日本のＩＴに限られていることなのかもしれない。

先日も、プラントの場合プロジェクトマネージャの年齢はほとんど30代後半で20代ではまだ見習だと教えて頂いた。ＩＴサービス業の場合には、大体30代後半のエンジニアは少なくとも弊社の場合は3％もいないし、この比率から想像がつくようにほとんどが管理職で現場に行かないものも含まれる。他社の場合、このようなことは無いとは思うが・・・流石に1000人の会社だとしても半分はいるのかしらと思う。人数はいるとしても、現場にいるエンジニアの数と考えるとやはり30％以下ではないのかと思う。大体、業界全体の平均年齢が未だに20代ということがその本質を物語っているような気がする。

そもそも、システムを創るという仕事はとても細かい仕事である上に物作り的な要素と最新の技術トレンドについていかなければならないという宿命とその上、お客様のいろいろな担当者とコミュニケーションを取り、人間関係を円滑に育み、全体的な調和の取れたシステムを創り上げなければならない。それに加えて、一番大切な仕事である納期と品質とコストを守ってシステムを完成させることということを忘れてはならない。しかも、創り上げる間にお客様のビジネスに変更が入るかもしれない。また、決定権はシステムをお使いになるお客様側にある訳なので常にお客様に確認を取りながらの仕事になる。我々ＩＴサービス会社は自分達だけでシステムを創っているということはなくいろいろな確認を取りながら、進捗の報告をしながらお客様と一緒にお客様の望むシステムを構築してということになる。これがプロジェクトの難しいところだと感じる。進捗管理や課題管理、変更管理と言った技術よりつくり手よりの話しもあるが、ステータスフォルダーを管理してコミュニケーションを円滑に取るといった人間的なマネージメント領域もかなり大きな割合で含まれている。

この人間的なマネージメント領域をよく考えて見ると、三位一体以上に大きな問題にぶち当たる。それは、技術とかマネージメントとか言う前のレベル。あたり前のことができる自立した人間でなければならないということ。日本語が正しく使えることとか、挨拶がきちんとできることとか、相手に感謝することとか、一緒に働いている人を思いやることとか・・・それが、企業教育では難しい部分だと思う。企業で教えるということなのかもよく判らないのだが現実は、毎年のように挨拶についてのネタが部門方針や朝礼メールに出て来ている状況。「しつけ」・・・は家庭で行うものではなくて、会社でも行うものもあるから。家庭では教えられないことも沢山あるのだから。社会人としてのイロハを教えることは、企業の責任でもあると考えるほうが今の自分の会社にはあっているように思う。いろいろと大切なことが沢山あって。・・・これは、形の上のことだけでなく仕事に対しての熱意とか、社会人としてのコミュニケーションのありかたとか多岐に渡る。そして、私は考える。本当に最初にみんなに覚えて欲しいことは、会社に入ったら会社はみんなを守り、みんなが幸せになる為にあるということ。そして、「未来を予測する最良の方法はそれを自分で創ること」（Ｔｈｅ ｂｅｓｔ ｗａｙ ｔｏ ｐｒｅｄｉｃｔ ｔｈｅ ｆｕｔｕｒｅ ｉｓ ｔｏ ｉｎｏｖｅｎｔ ｉｔ）というアラン・ケイの言葉は、会社とプロジェクトのどちらにもあてはまる基本的な考え方だと私は思う。

そしてそれは、あなたの生き方にもあてはまることに違いないから・・・。

プロジェクトマネージメントが難しいわけが多少は、わかってもらえただろうか。こたえはひとつじゃないから、ゆっくりと考えてみたらどうだろう。こたえはひとつじゃない・・・でも、採用できる答えは常にひとつで、そのひとつを取る局面ではあらゆる可能性と未来を予測する為に全てを洗い出して分析して議論して判断する必要があるのだ。こたえは、決して最初に思いついたひとつではないことをちゃんと覚えておいてほしい。こういう考え方が「ヒューマンシステム」には必要なことなのだと思う。ＩＴサービス業というのは、形の無いもの、曖昧なものを形にしてしくみを創る仕事だからこそ、こういった人間的なところの管理がＫＦＳに成り得るような気がしている。だからこそ「ヒューマンシステムを目指して進化していきたいと思う。人と人との繋がりを大切にシステムづくりにおもいやりを持って取り組む技術者集団・・・それが今までも、そしてこれからも我々が目指すところなのだ。