システムを作るプロジェクトはいろいろな工程に分かれています。設計書を書いたり、
プログラミングをしたり、テストをしたりと。
大きなプロジェクトほどマネジメントをしっかりと行っていないと問題が後回しになりがちです。
そしてだんだんと危険なプロジェクトになっていきます。
プロジェクトの最初の頃は定時に帰れていたけれど、いつの間にか残業が多くなったりというふうに。
そんなプロジェクトになっていませんか？
システムエンジニアとしてプロジェクトを色々と経験すると、問題が発生しそうな
プロジェクトがだんだんとわかってきます。
プロジェクトマネージャがその問題が小さいうちに気づいて早めに対処をしていければ
良いのですが、不幸にして、プロジェクトマネージャちゃんと管理を行っていないプロジェクトの場合は
気づかないうちに残業が多くなったり、作成した設計書やプログラムを再度書き直したりの
手戻りが発生します。
そんなプロジェクトで働いたら、だんだんとメンバーのモチベーションも下がり、悪循環に
陥ってしまいますよね。
そんなことにならないために早めに問題点を察知してプロジェクトの炎上を避けるための
ポイントを見ていきましょう。
もくじ
- プロジェクトが炎上してから反省していませんか？
- 危険なプロジェクトの特徴
- 危険なプロジェクトの対処方法
1.プロジェクトが炎上してから反省していませんか？
プロジェクトの最初は定時に帰れていたけれど、プロジェクトが進むうちに、
だんだん残業が多くなったり、仕様変更が多発して設計書やプログラムを何回も
修正したり。プロジェクトの後半になっていつも忙しくなっていませんか？
特に人数の多いプロジェクトの場合はウォーターフォールでの開発が一般的です。
その場合、設計⇒製造⇒テストの工程で進みます。各工程が終わってから次の工程に
進まないといけないのですが、設計をしながら製造をしたりと、２つの工程が並列で進んだり、
各工程の締め切りに間に合わないので他のプロジェクトから応援の人が増えて進捗が進むどころか
応援の人への対応で時間をさらに取られて遅れてしまったりと、だんだんと収拾がつかなくなっていきます。
そして、気が付けばプロジェクトは炎上していることになります。
プロジェクトの炎上は発生してからでないと気づけないものでしょうか？
そんなことはありません。炎上するプロジェクトは事前に察知できます。
今回はその予兆についての話です。
2.危険なプロジェクトの特徴
私の今までの経験から、次のプロジェクトは危険なプロジェクトになる可能性があります。
- 新規技術を使ったプロジェクト
- お客さんの要望が毎日変わる
- お客さんの要望が十分に取り入れられていない
- 進捗確認を毎日しない
- プロジェクトメンバー間の意思疎通が取られていない
「1.新規技術を使ったプロジェクト」
プログラミング言語や使用する技術がプロジェクトのメンバにとって経験があるものと
全く経験の無いものとではプロジェクトを進めるスピードが違います。
全く経験の無い技術であれば、作業に加えて新規技術の学習時間やプロトタイプ作成の
時間が必要になってきます。また、その技術で要求されるシステム上で実現可能かの検証も
しないといけません。新規技術は新しいもの好きの人にとっては使ってみたいという
誘惑がありますが、リスクも高いのです。
「2.お客さんの要望が毎日変わる」
プロジェクトあるあるなのですが、お客さんと打ち合わせするたびに、お客さんの発言が
毎回変わって、仕様がなかなか決まらないことがあります。プロジェクトの初期の方なら
良いですが、物を作成する段階になって変更になったら手戻りも発生し、危険な
プロジェクトになる可能性があります。
「3.お客さんの要望が十分に取り入れられていない」
これは、お客さんの要望をヒアリングする力が試されます。
例えば「画面にボタンを追加して欲しい」という要望があったとすると、
どの場所に追加するとか、どのようなときにボタンは押せたりするのかの確認が必要です。
あいまいなまま要望を聞いてしまうと、お客さんの考えとこちらの考えが乖離したまま
プロジェクトが進んでしまい、プロジェクトの後の工程で手戻りが発生します。
プロジェクトの後の工程で問題が発生するとコストが大きくなります。
「4.進捗確認を毎日しない」
毎日進捗管理を行わないとメンバ内での問題点の共有が後回しになり、その問題によって
メンバの作業が遅れたりします。また、毎日の生産性を把握するためにも進捗確認は
毎日必要です。問題点は早いうちに解決することがプロジェクトの全体最適となります。
「5.プロジェクトメンバ間の意思疎通が取られていない」
プロジェクト内でメンバの意思疎通が取られていないとメンバ間で情報共有ができに
くくなり、プロジェクトを進めるのに支障となることがあります。
例えば技術の情報共有や、コーディング規約などのルールの共有やメンバ間の設計の
インターフェース決め等がスムーズに進むかどうかです。
では、この問題を対処するためにどのようにすれば良いでしょうか？
一番悪いのは放置することです、問題を後回しにするほどそれに対応するコストは
どんどん増えていきます。
例えば、コーディングのミスをプログラムの段階で見つけた場合は、
プログラムソースを修正するだけで良いですが、リリース後に見つけた場合は、
プログラム修正⇒テスト⇒再リリースという手順が必要で
後回しにするほど対応コストはどんどん膨らんでいきます。
問題はなるべく早く見つけて対処する。これがプロジェクト管理の鉄則です。
これを次に見ていきましょう。
3.危険なプロジェクトの対処方法
ではもう一度、次の問題点について対処方法を見ていきましょう。
- 新規技術を使ったプロジェクト
- お客さんの要望が毎日変わる
- お客さんの要望が十分に取り入れられていない
- 進捗確認を毎日しない
- プロジェクトメンバー間の意思疎通が取られていない
「1.新規技術を使ったプロジェクト」
もし新規技術を使ったプロジェクトの場合は、新規技術の学習時間や調査の時間が
予定されているかを確認しましょう。また、新規技術を知っているメンバはいるのか？
どこにその技術を使おうとしているのか？を確認する必要があります。
「2.お客さんの要望が毎日変わる」
お客さんの要望が毎回変わる場合は、お客さんとの打ち合わせの議事録を作成します。
そして次の会議でその議事録の確認をします。どのような理由からその結論になったか、
それと比較して最終結論としましょう。お互いがWIN-WINの関係になるのが良いですよね。
「3.お客さんの要望が十分に取り入れられていない」
お客さんの要望とあっているかどうかは、プロトタイプを作って会っているかどうかを
確認します。プロジェクトの最初に手間はかかりますが、後になっての手戻りを考えると
なるべく早めに作業を行っておくことが大切です。
「4.進捗確認を毎日しない」
毎日進捗管理を行うようにして、遅れていた場合はどうするかのリカバリ方法も考えましょう。
進捗遅れに対して早めに対応するようにしましょう。
「5.プロジェクトメンバ間の意思疎通が取られていない」
毎日の進捗管理などを通してプロジェクト内でメンバの意思疎通を行いましょう。
情報共有化を行うことで不要な手戻りの発生を防ぐことができます。
いかがでしたか？「そのプロジェクト危険です！？炎上を避ける５つのポイント」
毎回、ステップアップするヒントを書いていきたいと思います。
ちょっとずつステップアップしていきましょう。
