いつプロジェクトの完成が見えるのか
同じ開発環境で同じような開発内容のプロジェクトであっても、上手くいくプロジェクトもあり上手いかないプロジェクトもあります。上手くいかないプロジェクトは、問題ある箇所を修正し続け終わりが見えない状態になっている場合が多くあります。
上手くいくプロジェクトといかないプロジェクトで一体何が違うのでしょう。
プロジェクトの完成は何を持って完成するのか、これはなかなか難しい問題です。
システム開発において、要件を整理し、設計を行って、開発を行ってシステムができあがってみると、後から色々とお客様から不満が出てくることが多々あります。最初の要件定義や設計をきちっとやっていても、後から変更や追加の要望が出ることがあります。むしろ後から何の変更要求が無いプロジェクトは希少だと思います。
あるプロジェクトで、要件定義時にお客様にこの通りに作ればいいんだからと既存のシステムの資料をぽんと渡されて要件定義が始まりました。しかし、要件定義を進めていくと、既存システムにいくつも課題があり、設計上の不整合が見つかりました。正直、いただいた資料通りに作っても、価値が出せそうになかったので、全面的に要件を見直しさせていただきました。
その結果、当初お客様からリクエストしていただいたものと、実際に開発したシステムではかなりイメージの違う物になってしまいました。ただし、要件定義・設計の過程においてお客様と、十分に議論をさせていただいて、どうあるべきかをロジカルに導き出しているので、最終的にお客様に想像以上に満足していただくシステムを作ることができました。
ここで注意したいのは、お客様のリクエスト通りに進めると失敗する可能性が高いという事です。お客様のリクエストのままでは不完全で有り、要件をまとめていく段階で設計をしていく段階で合理的に整理し、あるべき姿に向けてロジカルにまとめていかなければ成らないと思います。
そのプロジェクトでは要件定義の段階では完成形には届いていませんでした。基本設計の段階でも大幅な見直しを行いました。開発が完了しても多少の追加仕様・仕様変更が発生しました。
厳密には、システムには完璧無いのだと思います。
開発のフェーズごとに段階的に詳細化を行い、徐々に完成形に近づけていくという作業を行っていかなければなりません。最初はラフスケッチでお客様とイメージを共有し、徐々に詳細のイメージを摺り合わせていきます。
またシステムは完成しても、その瞬間から改善したい箇所が見え始めます。
ただし自由にお客様から言われるままに追加で変更を受け入れていると開発はエンドレスになってしまいます。
よって、マイルストーンを決めて、要件・仕様を確定しそれをドキュメント化して残して、仕様確定後の変更・追加は追加コストが必要になることを理解していただく必要があります。
また、お客様のリクエストは重要度の低いものも含まれるので、無駄なコストが発生しないようにコントロールしてあげる必要があります。
プロジェクトは予算・納期を厳守すべきです。
よってプロジェクトの完成をどこまでやったら完成にするかは、予算・納期を厳守できる範囲内で重要度を決めてスコープや要件・仕様を確定した上で、完成レベルを決定すべきだと考えます。
引き渡しを納得していただけるシステム
引き渡しを納得していただけるシステムを納品する為には、お客様が目的とするシステムを実現するため、ちゃんとお客様が希望する要件をヒアリングし、予算内でなるべく費用対効果の高い機能から実現できるよう要件を整理し、お客様と最終イメージを共有しながら、開発を進めていく必要があります。
実際問題、お客様の予算は有限であり、スケジュールも決められています。その中で最大限の効果を得たいという気持ちは誰しも同じだと思います。お客様は後から欲が出てあれもこれもと要求が発散しがちになってしまいます。
そんな時に、重要な要件と捨てても良い要件を整理し、最適なシステムをコーディネートしていかなければなりません。また、システム仕様を決める過程が大切です。丁寧にコミュニケーションを取りながら手順を踏んでいく事が大切です。お客様が納得しなければ、引き渡しは実現できません。システム開発って本当に難しいと思います。
完成しないシステムとは
お客様に引き渡しを納得していただけていないプロジェクトがありました。
理由は、希望する要件が満たされていないからだそうです。
実際問題、「希望する要件」については、明確にドキュメント化されておらず、何処までをシステム化するかについてお互いに「言った言わない」で揉めていました。
PMには要件定義・基本設計をドキュメント化し認識の齟齬を明確化するよう指示を出しました。
要件定義・基本設計で品質を下げてしまう場合いくつかの傾向があると思います。
一つは開発側にお客様の要件が理解できるほど、十分な業務知識が足りていないということです。そのために理解しないまま勝手に要件をまとめてしまってる場合があります。
もう一つは設計におけるレビューが十分になされてない場合があります。レビューは社内レビューと対顧客レビューの両方です。
最後の一つはドキュメント化が省略されている場合があります。面倒くさいからという理由でドキュメントが作成されていない場合があります。
お客様の要件をちゃんと理解した上で、要件・基本設計をドキュメント化し、お客様と確認のレビューを繰り返していれば、最終納品の際にそれほど揉めないと思います。完成しないシステムはこれらのいずれかを省略している可能性が高いと思います。
必要なのは実態把握
実力が無いプロジェクトマネージャーの場合、何とかなるという判断で問題を放置することがあります。異常に気付いたら、第一報は「巧遅より拙速」が大切です。なる早で報告しなければなりません。
システム開発を行なっていると必ずといっていいほど、期待したくない課題が出てくるものです。
解決を求められている問題について、具体的に、原因と対策を明らかにし、いつまでに、誰が、何をどうするかまで決める必要があります。問題は丸投げしてはいけません。担当者が具体的に動けるところまで指示の形にしなければなりません。
また、プロジェクト進捗は進捗度を数値化し、遅延があるタスクを見える化する必要があります。
実力が無いプロジェクトマネージャーは、進捗を見える化していなかったり、問題・課題が具体的に整理できていなかったりします。また総じて、問題を隠蔽しようとする傾向にあると思われます。
テストデータを実際の値に近いものを使うことが大切
本番前のテストは、なるべく本番に近いデータを使ってテストする事をおすすめします。
本当の値が入ってこそ、見た目の問題や操作感の問題や運用上の懸念事項などが洗い出されると思います。
データ量も出来る限り本番に揃えていくと良いと思います。パフォーマンスや容量不足など思わぬ落とし穴に事前に気付く事ができます。
Follow me!
コメント