プロジェクトを成功させるには？

― プロジェクト失敗の原因 ―

「要件がなかなか固まらない」「仕様がころころ変わる」「時間が足りない」「人が足りない」
プロジェクト失敗の原因として、これらの理由がよく挙げられます。

上の理由はすべて、営業担当者、プロジェクトマネージャ、外部設計担当者が解決すべき問題のようにも見えます。
たしかに、上流工程においてお客様の意図と開発側の認識のずれを残したままにしてしまうと、
開発工程全体の生産性を大きく損ねたうえ、お客様の希望と異なるシステムができあがってしまうことになります。

しかし、内部設計以降の下流工程において、開発者はそれを受け入れ、決定づけられた失敗への道を進むしかないのかというと、
決してそんなことはなく、成功のためにできることはたくさんあると思います。

― 技術的要因のインパクト ―

技術的な改善がその一つです。
技術的な要因がプロジェクトの成否に与えるインパクトは、
定量化しづらいため過小評価されがちですが、要件定義や外部設計に劣らず大きなものだと思います。

適切な実装手法の選択、再利用といった技術的な工夫、慣習は、開発を飛躍的に効率化することがあります。
技術的な問題には多くの場合、「正解」と言えるほど効果的で副作用の少ない解決策があります。
早い段階でそれらを採用することによって、品質を上げ、生産性を高めることが可能となります。

開発言語がフレームワークとともに提供されることの多い現在では、
ある手法を知っているか知らないか、その違いだけで生産性に大きな差が出ることもあるでしょう。

十分検討せずにアーキテクチャを選択したり、懸案を先延ばしにしたりすると、
取り返しのつかない品質悪化やスケジュール遅延を引き起こしてしまうことになりかねません。

一度発生した問題は、早めに解決しないと余分な工数を消費し続けます。
リリース後まで残してしまった場合、その問題の解決には開発中の何倍もの労力がかかり、
稼動中のシステムに対してデグレードのリスクを負うことになってしまいます。
納品後のバグ対応は、プロジェクトの採算評価をする際に考慮から漏れてしまいがちですが、
半年、一年と障害が発生し続けるようなことがあれば、かなりの工数がその対応に消費されることになります。

どんなに綿密に計画を立てても想定外の問題は発生するものですが、
それらを寝かせることなくきっちり解決していけば、開発の成功をより確実なものとすることができるでしょう。

― プロジェクト成功のために ―

もちろん、技術だけでプロジェクトを成功させられるわけではありません。
対象業務の本質を理解することも、適正な見積もりも、進捗管理も重要な要素です。
（コーディング担当者、テスト担当者においても、業務を理解すれば悩む時間が減り、判断を誤ることが少なくなります。）

しかし、技術は技術にとどまるわけではありません。
適切なアーキテクチャを設計し、効率よく実装することで、時間や人数の不足はある程度解消できます。
要件が固まらなくても、作業が進めやすく、仕様変更に影響を受けにくい仕組みを作ることは可能です。
使いやすい共通クラスを用意することで、可読性がよく、バグの少ないプログラムにすることができます。
適切なコメント、命名、APIといった「コミュニケーション」は、開発を円滑に進めるのに大きな威力を発揮します。
気の利いた、ユーザーフレンドリーな通知メッセージは、無用な問い合わせを減らすのに役立ちます。

開発の生産性、品質を上げるのに、必ずしも新しいプロセスモデルや特別な開発手法を導入する必要はありません。
課題・問題として上がったことを契機に、今までのやり方の中で一つ一つ改善していけば、着実な成果が得られます。

プロジェクトの成功率を高め、今より効率化したいとお考えでしたら、ぜひお声がけください。
御社の利益向上に貢献ができるよう、実効性を重視したご提案、ご協力をさせていただきます。