個人的振り返り：システム開発案件の留意ポイント（保守運用、納品について）

はじめに

ITエンジニアのキャリアも15年という時期にシステム開発案件で多大なる反省をすることとなりました。
せっかくの機会ということもあり、個人的目線でのシステム開発案件の流れをまとめていきたいと思います。

システム開発の流れ

流れは以下のポイントに分けます。
■プリセールス、見積もり、発注
■開発
■納品
■運用保守
業種、職種問わずなのかもしれませんが、共通して言えるのは"終わり"を意識するということです。本記事では納品、運用保守について書きます。

運用保守

"開発と運用保守はセットだ！"という言葉もよく聞きますが、ほんとにその通りです。
ただ、セットというのは"セットで考える"ということであり、必ずしも開発をしたベンダーが運用保守も行う。ということではありません。
システム開発だけを行い、運用保守は行わない会社もあります（どちらが主流なのかは私も知見がありません）。または納品先ではすでに運用保守を行う体制が存在しており、システム納品後は既存の体制で運用保守を行う。というケースもあります。
開発ベンダーがそのまま運用保守をするのか、他の体制に運用保守を引き継ぐのか、お客様ときちんとすり合わせを行い、システム開発案件としての着地点（終わり）を定めることが重要です。
運用保守についての考え方は会社によってさまざまのため、自分たちがシステム開発終了時にどのような状態となっていることを目指すのか、会社としても方針を固めておくとよいかもしれません。

納品

ほとんどのシステム開発はお客様の検収をもって納品となり、その後請求へとつながりますので、言わずもがなの大切なフェーズです。
システム開発の締めとなるため、開発でのやり残しがないようにきちんと点検を行い、お客様と認識合わせを行ったうえで検収を行います。
保守、運用の箇所でも触れましたが、お客様とすり合わせた着地点について点検を行いましょう。
以下によくある納品時に必要なものについて簡単に記載します。
・納品物：システム自体のプログラムソース、設計書、テスト結果、運用するための手順書など、開発案件ごとに定められたものはいろいろあると思います。納品時にはこれらを納める必要がありますので、（大丈夫だとは思いますが）この時点になって慌てて用意することがないように、日々の進捗の中で成果物を仕上げていかなければなりません。
・課題、変更管理一覧：開発期間中に発生した課題、変更管理について、納品時に結論が出ていない場合、納品後のトラブルの原因にもなる可能性があるため、しっかりと落としどころを決める必要があります。ポイントとしては『必ずしも解決がゴールではない』というところです。初期発注（今回のシステム開発）の範囲で対応するのか、追加費用・納期で対応するのか、別プロジェクトとするのか。そのうえで今回のシステム開発ではどこまでの対応を行うのか。を整理します。ご想像の通り、これらの調整も時間を要することが多いため、早め早めに対応をしましょう。

■さいごに

よく言われることですが、"終わり"を意識することに尽きるなと思います。最終的にどのような状態にしたいか、どのようなシステム開発として完了させたいか。を始めとして『ではどうすればそれができるのか？何が足りないのか？』を繰り返し考えていくことがより良いシステム開発につながるのだと思っています。