DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

サイバーエッセイ第６回に引き続き、プロジェクトマネジメントについて述べていきます。

プロジェクトの崩壊

プロジェクトの崩壊は、いくつかの単純な原因の組み合わせにより引き起こされるように私には見えます。最高の技術を結集して打ち上げたスペースシャトルやアポロ計画にも、事故の発生がありました。事故は、”完璧さへの過信”の影に身を潜めています。確かに、宇宙船、航空機、船などの事故には、技術的な不備に起因するようなこともありますが、いわゆる人災も数多くあります。

私がここで言いたいことは、システム開発のプロジェクトに関していえば、プロジェクト崩壊の原因は、ほとんどこの人災に当たるということです。そしてさらに言えることは、プロジェクトを実施してうまくいかない人（または、組織）は、何度でも失敗してしまうということです。それとは反対に、プロジェクトをうまく運営できる人（または、組織）は、いつでもうまくいっているという事実です。両者とも共通する何かがありそうです。

さて今回は、プロジェクト完全崩壊マニュアルの説明をすることにします。読者の皆さん方も、相当な失敗の経験をされていると思いますので、失敗するためにはどのような行動をしなければならないかは、ある程度分かっているとは思います。しかし、断片的な理解では、完全とはいきません。ここでは、開発のステージごとに、完全な失敗を目指して説明を試みたいと思います。

計画段階

この計画段階は、失敗を目指すものにとっては、大変重要です。もしこの段階で、十分な予算と期間が決まったとすれば、成功の基本的要件が、整いかねないことを理解すべきです。でも、予算や、期間が整ったとしても、具体的な目標をなくすことや、プロジェクトメンバーのやる気を削ぐような活動を積極的に行えば、後からでも、十分失敗することが可能です。むしろ、予算や期間の大きいプロジェクトの方が、大失敗になってダメージも相当大きくなりますので、適切かもしれません。

この段階を、大人数で、しかも決定権を持たない人を十分入れて長期間にわたって行うのも、プロジェクトを混乱させ、予算を浪費させるには効果的です。役員や部長クラスの会社の方針の決定者は、何だかんだと細かな理由をつけて参加や口出しをさせないことです。

プロジェクトは、参加メンバーの主張を詳細に分析し、すべての要求事項を満たすことが分かるまで期間を無視して行ってください。システムの技術アーキテクチャについては、ハードメーカーやツールベンダーの受け売りやセールストークを１００パーセント信じて、常に我が社は、世界の情報技術のトップであることを目指して、”何でもできる”といっているメーカー、ベンダーを採用すべきであります。

そのような方針を貫くことで、３年は、プロジェクトの進捗はないはずです。３年後には、ビジネス上の要件も大きく変わっているはずですので、プロジェクトは、いつも新鮮で振り出しの状態を維持できるはずです。

業務の分析段階

分析の段階での重点項目は、次のようにまとめることができます。

• 分析の範囲は曖昧にしておくこと
• 分析のプロジェクトチームは、できるだけ大きな人数で行うこと
• 分析チームは、できるだけ独断で物事を決めること（ユーザー部門で業務を知っている人が参画すると、何かと口うるさく注文をしてきますので、プロジェクトリーダーは、「その件については、プログラムの作成段階で何とかしましょう」と言って、いったん逃げるのがよいでしょう）
• 分析段階では、プロジェクトメンバーの各人が、「俺達は、システムのプロである。業務のどんな問題でも、プログラムで解決できる」という自負を持つこと

設計／構築段階

設計／構築段階は、プログラムのコンテストのようなものです。できるだけ、別のメンバーが作ることができないようなロジックを埋めこんでください。また、どちらが、プログラムの実行時の処理スピードが早いプログラム作ることができるかを競ってみる、絶好の機会です。個人的に開発したいろいろなテクニックを試してみても、面白いはずです。

また、流行のＣＡＳＥツールを使ってみるのもよいことです。ＣＡＳＥツールは、通常、ＣＯＢＯＬやＣなどのソースコードを生成しますが、生成したソースコードに手を加えて性能アップのテクニックを自慢するのも、楽しみの一つとなります。

とにかく、決められた設計仕様さえ満たせばこの仕事は終了できるわけですから、個人的な技量を自由に楽しむことが肝要です。

こんなことを取り留めとなく書いていると、空しくなってきました。そろそろ、まじめに書くことにします。事例にかかれたプロジェクトの失敗原因を逆説的に捉えれば、プロジェクトは、必ず成功するでしょう。

ここに示す３つの事例は、どれも私がかかわった失敗プロジェクトです。

例１　あるオフィス情報システムの支援ソフトウェアの日本語化プロジェクト

• 計画段階での安易な作業見積もりとプロジェクトの安請合い
• プログラマー思考で、全体の設計無しにプログラム修正に着手
• プアーなスケジュール管理
• 要員のアサインメントの不備により、プロジェクトメンバーは終わりのない過剰労働を強いられ、作業目標を失った状態になってしまった。

例２　メーカー生産情報システム

• メーカーの発注方法／ソフトハウスの受注の方法の理解の違い
• スケジュールと要員管理が具体化されていない
• 発注者とソフト会社相方の協力関係がなく、むしろ敵対関係になってしまった
• プロジェクトリーダーが遅れを取り戻すためプロジェクト開発作業に入ってしまった
• 役割分担と完了基準が設定されず、ソフト会社の責任と納期だけが一人歩きして、メンバーの過度な疲労と目標を失った状態

例３　銀行海外店システムパッケージ導入プロジェクト

• パッケージの設計思想を理解しないで、修正に無手勝流でに着手し、整合性がとれない
• 修正要件をユーザーの言うがままに受け入れた
• プロジェクトメンバーの役割分担がはっきりしない
• プロジェクト進行中に、何人もプロジェクトメンバーが交替した。その結果、修正中のパッケージ全体を理解しているメンバーがいなくなり、責任者がいない状態になった。

筆者から一言

「世の中のどのプロジェクトも、ここに示したの要素を含んでいます。読者は笑っているかもしれませんが、特に、計画段階の内容は、私が、いつも経験している課題です」

もえつき

ここ十数年の間に、私は、多くの崩壊したプロジェクトの立て直しの経験をさせていただきました。崩壊したプロジェクトに共通することは、プロジェクトメンバーの心の崩壊です。

言い換えれば、プロジェクトを推進しようとする気持ちの崩壊現象です。プロジェクトメンバーのほとんどは、技術的に崩壊したのではありません。精神的に崩壊したのです。英語では、このことは、燃えつき（Burn out）と言います。日本語での適切な表現は、やはり、〝キレル〟でしょう。切れるのか、斬れるのか、きれるのかは状況によると思いますが、ここでは、”キレル”とします。キレル原因には、いろいろあると考えることができますが、私は、90パーセントまでの原因は、次のことであると考えています。
　

• プロジェクトの明確な方針が無い
• 管理者が迷っていて、メンバーへの適切な作業指示がない
• 管理者、責任者が逃げる
• 設計・構築期間が長すぎる
• チーム編成が大きすぎる
• プロジェクト終了時に次のプロジェクトスケジュールが決まっているなど、モチベートすることがない場合（モチベーション）つまり、一生懸命やっても次のプロジェクトで苦労させられるだけ。
• メリハリがない
• 設計の変更要求が多すぎる（分析の完成度が低い）プロジェクトの中核を担っているのは、しょせん生身の人間です。人間の集中度に合ったプロジェクトの計画とスケジューリングをすべきであると思います。

ガイドラインを、次に示します。

• 人間の仕事として集中力を維持できる期間は、せいぜい、２から３カ月ですので、一つのチームが、担当する期間は、３カ月以内とする
• チーム編成は、１チーム３～６人とすること。コミュニケーション・ラインの数を考えると、理想は４人までとする
• プロジェクト終了時に楽しいことを企画する（旅行や休養の時間を計画する）
• 日時・週時単位の、明確な達成目標の提示と十分な管理をする
• 常に、プラス志向で物事を進めること

以上が、成功へのガイドです。　「絶対〝キレタ〟らあかんで」

プロジェクトのリズム－波動

プロジェクトというものは、弾みがつくと非常に強力なパワーを発揮するものです。

「宗教の本、物理の本、生命の本、経営の本･･･、世の中を構成している本質的なものの追求をしている本を手にしますと、世の中は、物質と波動で構成されている趣旨のことが書かれています。システム開発のプロジェクトも同様に、良いリズムに乗ったときに、心地良く成功に向って動き出します。

私は、人間の本質的なものは、波動であると思っています。人で構成しているシステム開発のプロジェクトも、成功要因の一つに良い弾みをつけることが挙げられます。システムに関する実務書やエンジニアリングの本では、このことが取り上げられている例は稀ですが、私は、本質的すぎて忘れられているのではないかと思います。

現に、武士の世界では、出陣の前に弾みをつけますし、現代でも、スポーツの大会で、応援や音楽が勝敗を左右する大きな力になることが数多くあります。

この事実は、波動と心が、何らかの繋がりを持っていることを示しています。私は、システム開発プロジェクトで最も大切なのは、計画の段階で、チームを成功するリズムに乗っけてしまうことだと思います。リズムが良くないプロジェクトは、たとえ、どんなに優れたメンバーを揃えたとしても、なかなか、思うように進捗することができません。プロジェクトの管理者やメンバーも、なんとなく重々しい、息苦しいようなムードを感じています。でも、これといったはっきりとした原因は、発見できないのです。

リズムをうまく利用したプロジェクトでは、これとは正反対に、どんどんうまくいきます。いわゆる〝波に乗る〟という状態になることです。この状態になると、プロジェクトのメンバーは、少々のことは勢いで乗り越えてしまいます。「始めよければ、終わりよし」。昔の人は、本質を分かっていますね。

リズムに乗ると良い結果が出る例は、数え切れない程あります。

• リズムに乗り切ったジャズのビックバンド
• アイスホッケーやサッカー、バスケットボースなどのチームプレーなど

さあ、今日も、明るく元気に、リズムに乗ってプロジェクトを進めましょう。

リソース・マネジメント

（現実のプロジェクトには常に何かが不足している）「プロジェクトには、常に何かが不足しています。もし満たされていれば、プロジェクト化して行うまでのことではないから」この言葉を常識だと思って、プロジェクトを担当してみてはいかがでしょうか。気が楽になります。

「いつも、なぜ俺だけが、こんな目に遭わなければいけないんだ」と思い悩んでみたところで、体に悪いだけですよ。世の中、あなただけが不幸な目に遭っているのではありません。

あいつがいたら、こいつがいたらなどと、いるわけない人のことを求めてはいけません。あいつがいたら、もしかするとあなたは、必要ないかもしれません。あなたがいるから、あいつはいないんです。

神様は、本当に平等です。私が、これまで経験したプロジェクトは、全て何かが足りませんでした。この言葉で、「俺も同感である」と思った人は、多いと思います。あなたの常識が、全く現実とかけ離れていたのです。ズレてたのです。このことを認識すべきです。

「人間は、自分に都合良く考える動物である」人間は、意外なところで、ズレているんですね。ズレている土台の上で、いくら正しい事を積み重ねても、結果は、ズレが増幅するだけです。

2000年7月24日