Webシステム発注初心者ガイド

10

振り返りとフェーズ2へ―システム担当者として学んだこと

今回のプロジェクトを振り返る

リリースから2ヶ月が経ち、システムも安定稼働してきた。

上司から「今回のプロジェクト、社内LTでシェアしてほしい」とリクエストが来たのを機に、改めて全体を振り返ってみた。

振り返りって、何のためにやるの?終わったならもういいじゃない。

振り返りは「次のプロジェクトをうまくやる」ためにやるんだよ。

特に初めてのシステム発注では「やってみて初めてわかること」が山ほどある。それを記録しておかないと、次に同じ轍を踏む可能性が高いんだよね。

会社にとっても貴重なノウハウになるから、ぜひまとめておこうね。


うまくいったこと

1. スコープを絞ったこと

最初に「見積書だけ」に絞ったのは正解だった。300万円・4ヶ月で完成したが、もし発注受付や請求書を一緒に作っていたら、700万円・10ヶ月になっていた。まず1つを完成させて、現場の反応を見てから次を考えられた。

2. 要件定義書を作ったこと

面倒だったが、これがあったことで「バグか仕様変更か」の線引きができた。開発中の追加費用もほぼ発生しなかった。

3. 定例MTGを週次でやったこと

毎週の確認で、問題が小さいうちに対処できた。承認フローのバグも、中間デモで発見できたからこそ追加費用なしで修正してもらえた。


大変だったこと・反省点

1. データ移行の工数を読めなかった

顧客マスターの整理に予想外の時間がかかった。次回は「データ移行」を開発スコープに入れて、C社にも工数を見積もってもらうべきだった。

2. トレーニングが直前になった

リリース2週間前にトレーニングをやったが、もっと早く「使い方の説明会」を設けるべきだった。ユーザーがシステムに慣れる時間が短く、リリース直後の問い合わせが多くなった。

3. 非機能要件が薄かった

「レスポンスタイムは2秒以内」「同時に何人まで使える」といった性能要件を詳しく書いていなかった。今回は問題が出なかったが、大規模なシステムではここが原因で揉めることがある。

反省点ばかりね……全部できてたら完璧なプロジェクトだったのに。

完璧なプロジェクトなんて存在しないよ。

大事なのは「反省点を次に活かすこと」だよ。初めてのシステム発注で、スケジュール内・予算内に完成させたのは、十分すごいことだからね。

プロのPMでも初めての業種・規模のプロジェクトでは同じような失敗をする。経験を積んで、少しずつ精度を上げていけばいいんだ。


システム担当者として学んだこと

今回のプロジェクトを通じて、「システム担当者」として大切なことが見えてきた。

1. 言語化する力が一番重要

「なんとなく欲しい」を「具体的な要件」に変える力。これがなければ、開発会社は動けないし、社内調整もできない。

2. 判断を止めないこと

開発中に「これ、どっちにしますか?」という質問が続々来る。即答できなくても、いつまでに回答するかをはっきり伝えること。判断を止めると開発が止まる。

3. 数字で話すこと

「大変そう」「難しそう」ではなく、「費用が300万増える」「期間が3ヶ月延びる」と数字で伝えると意思決定が早くなる。

4. 開発会社と「チーム」になること

「発注者と受注者」という関係ではなく、「同じゴールに向かうチーム」として接した方が、問題が起きたときに一緒に解決しようという姿勢になる。


フェーズ2へ向けて

フェーズ1のシステムが安定稼働し始めたところで、フェーズ2の検討を再開する時期が来た。

議事録に残した「フェーズ2として先送り」の項目:

  • 発注受付・受注登録
  • 請求書発行・入金管理連携
次はもうちょっとうまくできそう!データ移行も最初から計画に入れるし、トレーニングも早めにやるわ。

それが一番大事!経験を活かして、次はもっとスムーズにいくよ。

フェーズ2では、フェーズ1で構築した基盤があるから、連携も設計もやりやすくなるはずだよ。C社とも信頼関係が築けたし、コミュニケーションコストも下がってるしね。

今回の「Webシステム発注の旅」は一段落したけど、システム担当者としての旅は続いていく。これからも一緒に考えていこう!


まとめ:10話で学んだこと

テーマ学んだこと
第1話担当者になったシステムを「作る人」ではなく「依頼して管理する人」
第2話SaaS検討まず既製品を試す。自社特有ルールが多ければカスタム開発
第3話スコープ決定数字で示せば社内調整が動く。フェーズ分けは議事録に残す
第4話要件定義「なんとなく欲しい」を言語化する。社内承認してから発注
第5話開発会社選定価格より実績・体制・コミュニケーション。RFPで比較する
第6話契約請負vs準委任を理解。著作権・検収条件は必ず明記
第7話開発中変更は記録する。遅れの報告は喜んで受け取る
第8話テスト・検収UATは発注者の仕事。バグは再現手順と重要度で報告
第9話リリースデータ移行・トレーニングを忘れずに。リリースは月初め
第10話振り返り反省点を次に活かす。完璧なプロジェクトより、学ぶ経験

ガイドの一覧に戻る →