FSZからのお知らせ

システム構築プロジェクト、成功への道筋

こんばんは、吉田皓一です。

 
数あるシステム化、開発の経験から成功したプロジェクトの要因は戦争と同じで指揮官、つまりプロジェクトマネージャのマネジメント力にかかっていると新ためて思っております。
 
戦争では勝つ、負けるという単純な判断で戦います。システム化も品質のいいシステムを予算内で納期までに終えると言う単純明快な判断でマネージメントすればいいのです。ですからマネージャは名誉職、飾り、纏め役であってはいけません。現場の作業者(IT技術者)まかせになっていてもいけません。
 
つまり下記8要素をとりいれ実施できる人材をえらんでください。プロジェクト成功、不成功はプロジェクトマネージャの選出できまってしまいます。

成功への8要素
 プロジェクトマネージャの役割   
 システム化の目的・目標の明確化
 システムのコンセプトをはっきり
 開発方法論を理解
 プロジェクト管理
 べンダー・パートナーとの関わり
 ソフトの選択
 
1.プロジェクトマネージャの役割(PMRと省略)

PMRこそがプロジェクトを動かす要で、動かす機関車で、そしてすすむ方向を定める船長です。歳は関係ありません。つまりPMRの意志こそプロジェクトの意志でなければなりません。プロジェクトメンバーはシステム化をなしとげる為の必要な技術の技術者集団でなければなりません。ですから大袈裟ですが生死をともにできるメンバ-はみずから探してくることです。失敗する多くのケースは責任をとれないところで人があつめられ、「ハイあなたPMRとしてたのみます」というプロジェクトです。

PMRは自らプロジェクトタスクとその成功の為のストーリー(プロジェクト工程)を構築し、メンバーを適材適所に配備する。ことです。「これでやってくれ」と上から命令されたプロジェクトはいくら、プロジェクトメンバー、一人ひとり優秀でも絶対成功しません。

2.システム化の目的・目標の明確化

今から開発するシステムは会社にとってどのような位置つけのものかPMRの言葉で会社経営方針とプロジェクトの目的・目標をリンクさせ、文章化し、社内プロジェクト、パートナーにまで周知徹底させる。たとえばどんな資料にも、目的・目標を明示した用紙・画面をつかう等。プロジェクト達成はシステム構築ではなく会社方針の達成・具現化であるとメンバー一同の意識を変えるところからはじまります。
 
3.システムのコンセプトをはっきりさせる。

システムの構想、概念、システムの構造、IT技術、開発方法論などはPMRみずから先頭にたち立案する事です。自分も参画したものだから評価もできる(おかしくなれば変える事もできる)し責任もとれる。また、人の話しも聞ける。(解っているからできる)
 
4.開発方法論を理解

開発方法論をしっかり理解する事によりプロジェクト管理ができます。開発工程への分解その期間の推定、人材の配備、を行い何が本プロジェクトのRISKになりうるかを事前に知ってく事が管理する上での必要な事前準備です。
 
5.プロジェクト管理

5.1 プロジェクト管理で大事なことはリーダやメンバーの意見、報告は参考に、PMR自ら状況把握する事です。つまり人の話はほどほどにしてみずから現場の状況を常にWATCHして、みずから判断することです。他人の判断・意見のせいにしない事です。常に現時点から先2ケ月先の状況を複数予測し、その対策を考えておく。(こうなればこうする、こうなればこの手をうつ、こうなりそうだから今からこうする);ほとんどの場合未知なだけに複数の状況を頭にいれておくことです。自分の責任を他人の意見、判断で左右されたくないという思いが重要で心地よい報告を待っている自分をよくみつめる事です。(いやな報告ほど重要、またいやな情報には耳を貸したくないのが本音だが、いやな情報ほど重要です。)責任は自分でしかとれない、それなら自分の眼で判断するという気持ちが重要です。

5.2 協力会社といえどもそのメンバーの管理まで意識しておく。つまり責任があると考えるべきで仕事が遅れたり、費用がUPしそうでも責任はPMRにきます。PRMが他社の責任にするプロジェクトで成功された案件はないといっても過言ではありません。パートナーもプロジェクトの一員。パートナーのリーダも自分の片腕として、自社メンバーとの差をつけない。適材適所が必要です。
 
6.ユーザ部門との関わり

現場ユーザは保守的(現行の保証を求める)です。ユーザのニーズには費用で議論、システム化の目的・目標に合致しているかで議論すべきで現行の機能を満足させる、させないで議論すべきではありません。例えば他社事例を説明したり、必要だと要望される機能を使う頻度、などすべて具体的事例や方法論ではなしあいましょう。大事なのは
・ユーザの立場に立った具体的課題と複数解決案を提示する。(問題提起だけではダメ)
・ユーザTOPへはPMRが直接説明する。
・常にユーザTOPとコミュニケーションPATHを作っておく。
 
7.ベンダー・パートナーとの関わり

協力会社、ベンダーTOPとの強いコミュニケーションPATHをつくる必要があります。いい事も、悪い事も常に情報交換してプロジェクトの成功を一緒に分かち合える土壌をつくる事です。
 

関連記事