保守運用と開発のバランス

開発スピードが遅いという問題は、多くの企業で共通する課題です。特に、既存システムの保守運用に多くのリソースを割いており、新しい機能の開発に十分なリソースが確保できないというケースは多いです。このような状況の背景には、既存システムの複雑性や、保守運用の優先順位、開発体制の課題などが挙げられます。それでは、詳しくみていきましょう。

１．既存システムの複雑性
既存システムが複雑になると、バグ修正や機能追加の難易度が高まります。また、バグ修正や機能追加を行うことで、他のシステムに影響を与えるリスクも高まるため、慎重に検討した上で、作業を行う必要があります。改善策として、既存システムをモダナイズすることで、複雑性を軽減し、保守運用の効率化を図ることができます。モダナイゼーションとは「近代化」や「現代化」といった意味で、システムの構成や設計を見直して複雑性を軽減したり、クラウドネイティブ化やマイクロサービス化など、最新の技術を活用することで、既存のものを活かしながら最新の技術に適合した現代的なシステムへと置き換えることを指します。

２．保守運用の優先順位
保守運用には、セキュリティの脆弱性対策やパフォーマンスの改善など、さまざまなタスクが含まれます。これらのタスクの優先順位を適切に設定し、優先順位の高いタスクから順に作業を行う必要があります。改善策として、バグ検知やセキュリティ対策などの自動化ツールを導入することや、運用プロセスを標準化し、自動化の対象を拡大するなど、保守運用の自動化を進めることで、人的リソースを解放し新しい機能の開発に充てることができます。

３．開発体制の課題
開発体制に課題があると、開発のスピードが遅くなります。例えば、開発者のスキルや経験不足、開発プロセスの不備、コミュニケーション不足などが挙げられます。改善策として、開発者のスキルアップやキャリア開発を支援することや、開発プロセスを明確化し、コミュニケーションを円滑にすることで開発の効率化を図ることができるでしょう。

また、保守運用と開発のバランスを適切に取ることも重要です。保守運用を疎かにすると、システムの安定稼働が難しくなり、新たな不具合の発生やシステムの老朽化につながる一方で、保守運用に過度にリソースを割くと、新しい機能の開発が停滞してしいます。保守運用と開発のバランスを適切に取るためには、経営層やステークホルダーの理解と協力が不可欠であるため、開発スピードを向上させるためには、企業全体で取り組む必要があります。

作業量重視の弊害

人月、人工での計算で保守を依頼する場合、保守費用は、作業量に応じて算定されるます。そのため、保守会社は、作業量を減らすために、納品物の品質を落とす傾向にあります。具体的には、以下のようなものが挙げられます。

・不具合の原因を特定せず、表面的な修正だけを行う
・不具合の再発を防止するための対策を講じない
・保守対象のシステムやアプリケーションの全体像を把握せず、局所的な修正だけを行う

このような保守では、納品後に不具合が再発したり、新たな不具合が発生したりする可能性が高くなります。また、保守会社は、作業量を減らすために、納品物の品質を落とすだけでなく、作業の効率化を図ることも行うため、納品物や成果物に対して、十分な検証やテストを行うことが難しくなります。これにより、納品後の不具合がさらに増えてしまうという悪循環に陥る可能性があります。人月、人工での計算で保守を依頼する場合は、以下の点に注意しましょう。

・保守会社の品質管理体制を十分に確認する
・納品物や成果物に対して、十分な検証やテストを行う
・保守契約書に、不具合の再発防止などの条件を盛り込む

人月、人工での計算で保守を依頼する際には、「保守契約書に、不具合の再発防止のための対策を講じる旨を盛り込む」「保守対象のシステムやアプリケーションの全体像を把握するための、技術者間のコミュニケーションを促進する」「保守作業を、複数の技術者で分担して行う」といった対策を講じることで、納品後の不具合を減らすことができます。また、保守会社に依頼するのではなく、自社で保守を行うことも検討する必要があります。自社で保守を行うことで、納品物や成果物に対して責任を持って取り組むことができるでしょう。

不具合と追加要望の切り分け基準

システム開発において、依頼者側とベンダー側の間で「不具合」と「追加要望」の切り分けが曖昧になり、トラブルに発展するケースは少なくありません。依頼者側としては、思い通りに動かない機能はすべて「不具合」として、ベンダー側に修正を要求したくなります。一方、ベンダー側としては、リスク回避のために、すべてを「追加要望」として、追加費用を請求したくなります。

このような状況を避けるために、まず既存の不具合なのか、追加の要望なのかを正確に切り分けるための基準を設けることが重要です。不具合と追加要望の切り分け基準は、システムの種類や契約内容によって異なります。一般的には、以下のようなものが挙げられます。

仕様書に記載されている内容
→仕様書に記載されている内容と実装内容が一致しない場合は、不具合と判断されます。
機能の目的
→機能の目的を達成できていない場合は、不具合と判断されます。
実用上の問題があるかどうか
→実用上の問題がある場合は、不具合と判断されます。
コストや納期への影響
→コストや納期への影響が大きい場合は、追加要望と判断されます。

不具合と追加要望の切り分けは、依頼者側とベンダー側が共同で行う必要があります。具体的な進め方は、以下のとおりです。

１．依頼者側が、不具合として認識している内容をベンダー側に伝える。
２．ベンダー側が、仕様書や実装内容を検証し、不具合かどうかを判断する。
３．判断に至らない場合は、依頼者側とベンダー側で協議し、合意に至るまで検討する。

不具合と追加要望の切り分けは、不具合の場合には問題の解決の早期化によって被害を最小限に抑えることができます。また、追加要望の場合には、費用や納期を適正に設定することで、トラブルを回避することができます。何よりも、不具合と追加要望を適切に切り分けることで、依頼者側とベンダー側の信頼関係を構築することができます。

システム開発においては、不具合と追加要望の切り分けを明確にすることが、円滑なプロジェクトの遂行につながります。

密なコミュニケーションの重要性

ベンダーが依頼者の追加要望を勝手な解釈で進めると、本来、工夫すれば作らなくていい機能をわざわざ作って、工数が増えてしまいます。この原因は、ベンダーが依頼者からの追加要望を、自分の技術や経験に基づいて解釈することにあります。例えば、依頼者が「A機能をB機能と統合したい」と言った場合に、ベンダーは「A機能をB機能に追加する」と解釈したとしましょう。その結果、A機能をB機能に追加するだけの工数がかかってしまうのです。

このように、追加要望を勝手な解釈で進めると、本来の開発スケジュールが遅れる可能性もあります。例えば、依頼者が「新規機能の開発を来月から開始したい」と言った場合に、ベンダーは「来月から開発を始められるように、今から準備をしておきましょう」と解釈した場合、本来、来月から開発を始められるものを、今から準備を始めるために、今月の工数が減ってしまう事態に陥るのです。

以上のことから、ベンダーの勝手な解釈を防ぐためには、依頼者がベンダーと密にコミュニケーションを取ることの重要性が見えてきたのではないでしょうか。依頼者は、ベンダーに追加要望を伝える際に、以下の点に注意しましょう。

・具体的に何を実現したいのかを明確に伝える。
・実現したいことを実現するための方法を複数提案する。
・ベンダーの解釈を確認する。

具体的に何を実現したいのかを明確に伝えることで、ベンダーは勝手な解釈をする可能性が低くなり、実現したいことを実現するための方法を複数提案することで、ベンダーはより良い方法を選択しやすくなります。さらに、ベンダーの解釈を確認することで、勝手な解釈を防ぐことができます。

また、依頼者側がベンダーの技術や経験を理解しておくことで、勝手な解釈を防ぐことができます。例えば、ベンダーが特定の技術に強みを持っている場合、その技術を活用した解決策を提案する必要があるでしょう。これらを踏まえたうえで、ベンダーと依頼者の双方がコミュニケーションを密に取り、お互いの理解を深めることで、勝手な解釈を防ぎ、円滑なプロジェクトを進めることができます。

まとめ

いかがでしたか？

つまり、「依頼者側の要望を何も言わずに御用聞きスタイル」のSEは良いSEとはいえません。一見、何でもやってくれているように見えますが、要望の本質を捉え、時には依頼者側の業務フローの改善案まで考えることができるSEが、結果として一番コストが落とせる良いSEと言えるでしょう。

御用聞きベンダー、御用聞きSIerから脱却して、DXや劇的な生産性アップを目指しませんか。
現状のシステム分析についても、実績豊富なアタラキシアDXにお任せください！