SIerのお仕事での失敗と教訓

こんにちは。SIerでお仕事していると色々なプロジェクトに携わりますが、成功することもあれば、失敗することもたくさんあります。ただ失敗から学ぶことはとても多く、次の成功のための貴重な教訓になります！今回はプロジェクトで経験したよくありそうな失敗例と、そこから得た教訓をみなさんとシェアしてみたいと思います。

ケース1：要件定義の不備

失敗例
ある金融業界向けの顧客管理システム開発プロジェクトで、クライアントとの要件定義が曖昧なまま進行してしまいました。
とくに顧客情報のセグメンテーション機能について、最初は「基本的なフィルタリング機能」でいいと言われていたのが、後になって「高度なデータマイニング機能」が必要だとわかりました。これにより設計段階で多くの手戻りが発生し、最終的には納期直前に多くの仕様変更依頼が入り、大幅な遅延とコスト超過が起こりました…。

教訓
当たり前ですが、要件定義の段階でしっかり時間をかけてクライアントと詳細に話し合い、明確な仕様を文書化することが大事です。とくに文書化が大事で、後になって文書と違うことを言ってゴネてくるクライアントさんは、さすがに多くはないと思います。
また変更管理プロセスを厳密に運用し、変更要求が出た場合には影響範囲をしっかり評価し、スケジュールと予算をクライアントに丁寧に説明しながら再調整を行うことも重要です。
そしてクライアントの担当者が変わる時には、十分な引き継ぎと要件確認を再度行うことも必要です。

ケース2：コミュニケーション不足

失敗例
ある取引業務のシステム開発プロジェクトで、チーム内のコミュニケーションが不足していました。
とくにリモートワークのメンバーとの連携がうまくいかず、情報の共有が滞っていました。リモートのメンバーが注文管理モジュールの開発を進めている間に、オフィスにいるメンバーが同じ機能の開発に対して別のアプローチを検討していることに気づかず、共通モジュールの開発において重複作業が発生しました。これにより、プロジェクトの進捗が遅れ、最終的には品質にも影響が出ました…。

教訓
ある程度の規模の開発であれば定期的なミーティングや進捗報告を行い、チーム内の情報共有を徹底することが大切です。とくにリモートワークも一般化した中で、オンラインツールを活用したコミュニケーションの仕組みを環境面とルール面で整えることが求められます。毎日のスタンドアップミーティングや、進捗を共有するためのオンラインホワイトボードを利用することも有効です。また、問題が発生した時にはすぐに全員で共有し、迅速に対応策を講じる体制を整えることが必要です。共有するカルチャーが根付けば、開発もトラブル対応もスピードアップしていくと思います。

ケース3：リスク管理の甘さ

失敗例
新しい技術を用いた決済システム開発プロジェクトで、初期段階でリスク評価を十分に行わずに進行しました。例えばですが、ブロックチェーンネットワークのスケーラビリティが予想よりも低く、トランザクション処理が遅延する問題が発生しました。これにより、プロジェクトは一時停止し、再評価と修正作業に多大な時間とコストがかかりました。最終的には、納期を大幅に遅延し、クライアントからの信頼も一部失う結果となりました…。

教訓
プロジェクト開始時にリスク評価を十分に行い、潜在的な問題を洗い出しておくことが大切です。リスクマネジメントプランを作成し、定期的にリスクの再評価を行うことで、未然に対策を講じることができます。新技術を導入する場合は、事前に十分なテストと有識者のレビューも行い、技術的な課題を早期に発見・解決することが必要です。

ケース4：リソース不足による遅延

失敗例
契約管理システム開発プロジェクトで、特定のスキルセットを持つエンジニアが不足していました。
当初の計画では十分なリソースが確保されていると思われましたが、他のプロジェクトとの兼務や急な離脱により、予定通りに進めることができなくなりました。例えば、主要なエンジニアが急病で長期休養を取ることになり、代替要員が見つからないまま作業が停滞。これにより、プロジェクト全体のスケジュールが大幅に遅延しました。

教訓
プロジェクト計画段階で、必要なリソースを正確に見積もり、余裕を持ったスケジュールを組むことが大事です。リソースの流動性を確保し、他のプロジェクトとの兼務が発生する場合は早めに調整を行う必要があります。さらに、バックアップ要員を確保し、急な離脱にも対応できる体制を整えることが求められます。例えば、定期的なリソースレビューを行い、リスクの高いポイントを事前に特定することが有効です。
万が一のリソースに備えられるのは大きなSIerの強みかもしれません。

ケース5：品質管理の不足

失敗例
オンラインバンキング関連システム開発プロジェクトで、テスト工程が十分に行われず、システム納品後に多くのバグが発覚しました。
とくにユーザーインターフェースの使い勝手や、レアなイレギュラーケースに対するテストが不十分であったため、クライアントから多くのクレームが寄せられ、追加修正対応に追われました。例えば、特定のブラウザでの動作確認が不十分で、顧客がアクセスできない状況が発生しました。

教訓
品質管理プロセスを徹底し、テスト工程に十分な時間とリソースを割くことが大切です。ユニットテスト、インテグレーションテスト、ユーザビリティテストなど、様々なテストを実施し、エッジケースにも対応できるようにする必要があります。また、テスト結果をしっかりとフィードバックし、品質改善に努めることが求められます。案件にもよりますが、テスト自動化ツールを導入し継続的にテストを実施する仕組みを整えることも有効です。

まとめ

SIerのプロジェクトには、多くの挑戦がありますが、失敗から得られる教訓は非常に貴重です！これらの教訓を活かし、次のプロジェクトで同じミスを繰り返さないよう努めることが、エンジニアとしての成長に繋がると思います。
また教訓として書いたことをただただ実行するだけだと、時間もかかりスピード感を失うことにもなりかねません。しっかりと手綱を握るリーダーさんや当事者意識をもったメンバーさんの存在はいつでも不可欠だなと思います。
失敗を恐れず、そこから学び続ける姿勢を大切にしましょう〜。
（具体例をぼかして一般化しながら書くのなかなか難しいですね…）