「システム開発、何から手をつければいいんだ…」と困っていませんか？

システム開発は、調達で固めた仕様を、実際に動くシステムへ落とし込む工程です。
ここで躓くと、次のようなトラブルにつながります。

• スケジュールがズルズル遅れる
• 完成後に「思ってたのと違う」が頻発する
• カスタマイズが膨らみ、追加費用が積み上がる

今回の記事では、私が会計システム入替を行ったうちの前半4工程（キックオフ・要件定義・概要設計・詳細設計）を解説します。
現場で「苦労した点」や「工夫した点」もお伝えするので、ぜひ最後までご覧ください。

目次

• 1. システム開発の4工程と今回扱う範囲
• 2. 工程①｜キックオフ
  • 2-1. キックオフでやったこと
• 3. 工程②｜要件定義
  • 3-1. 要件定義でやったこと
  • 3-2. 要件定義の規模感
• 4. 工程③｜概要設計（基本設計）
  • 4-1. 概要設計でやったこと
  • 4-2. 概要設計の規模感
• 5. 工程④｜詳細設計
  • 5-1. 詳細設計でやったこと
  • 5-2. 詳細設計の規模感
• 6. システム開発（前半）で工夫したこと
  • 6-1. 現行システムのフロー図を作って認識を揃えた
  • 6-2. カスタマイズは最小限に説得
  • 6-3. 業務担当者の負担を抑えて会議を組んだ
  • 6-4. ベンダーと良好な関係を築いた
• 7. 開発を通じて感じたこと　～システム入替は発注者も大変～
• まとめ

1. システム開発の4工程と今回扱う範囲

システム開発は、調達で決めた方針を、動くシステムへ作り上げる工程です。
私のプロジェクトでは、契約締結から本稼働まで、約16ヶ月かかりました。

主な工程は、次のとおりです。

• キックオフ
• 要件定義
• 概要設計（基本設計）
• 詳細設計
• 製造
• テスト（単体・結合・総合）
• ユーザー（社内）検証
• 本稼働

この記事では、前半の4工程（キックオフ・要件定義・概要設計・詳細設計）に絞ってお伝えします。
製造以降は、次回の記事で解説する予定です。

2. 工程①｜キックオフ

キックオフは契約締結直後、発注側と受注側が初めて全体で集まる場です。
プロジェクトの全体像と進め方を、両社で合意するためのものです。
また担当者同士の顔合わせの場でもあります。

2-1. キックオフでやったこと

キックオフは1～2時間程度の会議で、議題は次のとおりです。

• プロジェクト計画書の説明と合意
• 全体スケジュールの確認
• 打ち合わせ計画表の確認

私のプロジェクトでは、キックオフから10日後には最初の要件定義が始まりました。
契約直後から、フルスロットルで動き出します。

現場メモ①

キックオフで、私はベンダーに「スケジュールが間に合わなくなったらどうしますか？」と尋ねました。
回答として「リソース（人員）を追加して何とか間に合わせます」とのことです。
しかし、開発が終わった今振り返ると、リソースが追加された気配はなく、普通に遅れました。
ベンダーとの口約束は鵜呑みにせず、トラブルはつきものだと思った方が、慌てずに対応できます。

現場メモ②

過去に料金システムの更新（ベンダー入替なし）も経験したことがあります。
その時はキックオフから要件定義開始まで半年以上空きました。
ただの更新だと、それだけスケジュールに余裕があります。
逆にベンダー入れ替えだと、最初からみっちりとしたスケジュールになります。

3. 工程②｜要件定義

要件定義とは、発注者（ユーザー）の要望を整理し、システムに実装すべき機能や条件をすり合わせる工程です。
開発の土台となる「設計図」を作成し、関係者間の認識ズレや手戻りを防ぐ役割を持ちます。

3-1. 要件定義でやったこと

今回のプロジェクトにおいて要件定義は、プロポーザルで提示した「機能要件」を中心に進めました。
各機能について、ベンダーがデモを見せながら「こんな感じで対応します」と説明し、発注側が確認していく流れです。
カスタマイズや運用代替で提案をもらった項目は、具体的にどのようなカスタマイズや代替案にするかを定義していきます。

要件定義書のイメージは、次のような形です。

大項目	中項目	要件内容	対応方針	備考
予算管理	予算登録	部門別・項目別に予算を登録	標準対応
予算管理	予算振替	振替元・振替先を指定して振替	運用代替	備考に振替フロー追記
契約管理	契約台帳	契約金額・期間・相手方を一覧照会	カスタマイズ	検索画面を追加実装
共通	帳票出力	出力レイアウトを利用者側で変更	運用代替	EUC（Excel）で対応

なお、要件定義を行うなかで、機能要件には書いていないものの、運用上どうしても必要な要件も出てきます。
この場合は、ベンダーと協議して、追加カスタマイズを依頼することになります。

現場メモ

開発では、ベンダーに無理を頼む場面が必ず出てきます。
逆にベンダーからも、譲歩してほしい要求も出てきます。
開発をスムーズに進めるためには、一方的な要求はせず、お互いWin-Winの関係を築くように心がけました。

3-2. 要件定義の規模感

私のプロジェクトでは、要件定義の期間は約11週間でした。
中心となる業務担当者会議は9回、合計約30時間の集中討議です。
会議は共通機能・予算・支払・契約・固定資産・債権管理など、テーマ別に分けて進めました。
最終的に、要件定義書に64件のカスタマイズと運用判断を確定させました。

現場メモ

要件定義は「分からないことだらけ」のスタートです。

• 使ったことのないシステムで、ベンダーの説明を聞いてもピンとこない
• 事前デモを入れてもらいましたが、それでも分からない
• 私自身、普段は会計システムを使わないので、現場の疑問も分からない

結果として、「ベンダーから質問される → 分からない → 現場に聞く → 後日回答」のループになり、要件定義のスピードが落ちました。
もし次に同様のプロジェクトをやるなら「自分が既存システムを使い込む」「現場メンバーに新システムを早めに触らせる」のを徹底します。

4. 工程③｜概要設計（基本設計）

要件定義で「やる」と決めたことを、画面・帳票・処理に落とし込んでいく工程です。
別名「基本設計」や「外部設計」とも呼ばれ、発注者と開発側の認識を合わせる重要な役割を持ちます。

4-1. 概要設計でやったこと

要件定義書は「何を実現するか」のレベルです。
概要設計では、それを「具体的にどう実現するか」まで詰めます。

たとえば、要件定義書に「契約台帳の検索画面を追加実装する」と書かれているとします。
概要設計では、次のような点のイメージを固めていきます。

• その画面にどんな項目を並べるか
• 検索条件は何にするか
• 結果一覧はどう表示するか

帳票も同様であり、帳票1枚ごとに項目位置・印字内容・決裁欄の配置まで決める作業に膨らみます。

概要設計は、次のようなイメージです。

このような帳票やシステムのレイアウトに対し「どこに・何を・どう印字するか」の指示を、1枚ずつ書き込んでいきます。

4-2. 概要設計の規模感

私のプロジェクトでは、概要設計の期間は約6週間でした。
担当者会議の回数は、要件定義より多い13回です。

会議が要件定義より増えるのは、決めたはずの仕様が、具体的な画面・帳票に落とす段階で再協議になることもあるからです。
要件定義書で定めた1項目に対して、概要設計では丸一日かかることもありました。

現場メモ

概要設計フェーズで「情シスの役割は調整だ」と強く感じました。
部門間の利害調整、ベンダーとの仕様調整、スケジュール調整、参加者調整。
設計のアウトプットを出すのはベンダーですが、それを「現場で回るもの」に落とし込むのは情シスの仕事です。
ここを丁寧にやらないと、後の製造・テストで「思ったのと違う」が頻発します。

5. 工程④｜詳細設計

詳細設計とは、概要設計で決めた仕様をもとに、開発者が迷わずコードを書けるレベルまでシステムの内部構造や処理手順を具体化する工程です。

5-1. 詳細設計でやったこと

詳細設計は、ベンダー側の作業が中心です。
画面ごとのコントロール定義・項目チェック・データベースの読み書きを、製造（プログラミング）に直接落とせるレベルまで仕様を詰めます。
レビューも承認も、受注者社内で完結します。
発注側のレビューは、概要設計までで終わりです。
発注側は、ベンダーから来る質問に答えるのが、おもな仕事になります。

5-2. 詳細設計の規模感

私のプロジェクトでは、詳細設計の期間は約3ヶ月でした。
発注者側の仕事は問い合わせへの回答です。
「ここの仕様、どっちで解釈すればいいですか？」といった質問がくるので、なるべく早く回答するよう心掛けました。

現場メモ①

詳細設計フェーズは、要件定義・概要設計に比べて、情シス側はかなり楽な期間でした。
打ち合わせもほとんどなく、質問対応だけとなります。
詳細設計はベンダーに任せて、こちらは要件定義の振り返りや、テストの準備に時間を回しましょう。

現場メモ（失敗）②

ただしベンダーに任せきりにするのは危険です。
私は課題管理とスケジュール管理を、ベンダー任せにしていました。
これは完全に失敗です。
後半になって、次のような状況が続きます。

• リスケの回数が妙に多い
• スケジュールも遅れている
• でも、どこがどう遅れているのかが分からない

問いただすと、電子決裁の部分が間に合っていないと、ようやく明かされました。
それまでも進捗は何度も聞いていましたが、「ちょっと確認しますね」とはぐらかされていました。
はぐらかされ始めたら黄色信号。
進捗は自分でも数字で管理し、ベンダーに丸投げしないことが大事だと学びました。
詳しいことは、また別記事で解説します。

6. システム開発（前半）で工夫したこと

ここまでの4工程で、私が意識した工夫を4つ紹介します。

6-1. 現行システムのフロー図を作って認識を揃えた

要件定義に入る前に、私は2日かけて、現行システムの業務フロー図を作りました。
作り方は次のとおりです。

• 初版は私がエクセルで起こす
• それを業務担当メンバーに共有して、誤りや漏れを修正してもらう

目的は、「現行運用がどうなっているのか」「新システムでどう変わるのか」をメンバーで共有することです。
特に、収入の取消・更正・返金など、処理の流れが複雑な領域でこのフロー図が活きました。

現場メモ

システムを入れ替えると、運用が変わる部分が必ず出てきます。
フロー図を作っておくと、その変更点が一目で分かるようになります。
自分自身の理解が深まるのはもちろん、メンバーと認識を揃える土台にもなるので、手間をかけてでも作って正解でした。

6-2. カスタマイズは最小限に説得

要件定義の中で、業務担当者からは多くのカスタマイズ要望が出てきます。
言われるがままに全部受けると、開発費用も期間も膨らみます。
私は、できるだけ運用回避でカバーするよう、業務担当者を説得しました。

たとえば、ある担当者から「システム入力の途中で画面を閉じる時に、警告を出してほしい」という要望が出ました。
仕様書にない筋違いの要望ですが、頭ごなしに断るのも難しいものです。

その方に対しては、次のように説明しました。

「このカスタマイズをやるには、画面一つひとつにプログラム修正を追加する必要があります。簡単そうに見えますが、開発ベンダーにも情シスにも、相当な負担がかかります」

冷静にできない理由を伝えて、最後は納得してもらえました。

現場メモ

ほかによく使っていた説得ロジックがあります。
「このパッケージは他社でもごまんと使われています。最初は運用に慣れず戸惑うと思いますが、他社も同じように運用でカバーしているはずです」という伝え方です。
運用を変えるのは大変ですが、システム入替だから仕方ない、とある種あきらめてもらっていました。

6-3. 業務担当者の負担を抑えて会議を組んだ

業務担当者は、本業を抱えながらプロジェクトに参加しています。
プロジェクトのために、本業を止めるわけにはいきません。
私は、打ち合わせ項目に合わせて、参加者を絞って会議を設定しました。

概要設計の13回の会議も、毎回参加者の組み合わせを変えて運営しました。
要員調整シートで、項目ごとに「この部門は必要／不要」を整理しています。

イメージは、次のような形です。

日付	議題	会計	予算	調達	工事	全員
2/27	支払関連	○	△	−	−	−
2/28	予算振替	○	○	−	−	−
3/6	契約関連	−	−	○	△	−
3/12	共通経費	○	○	○	○	○

なるべく最小限の会議参加で済むように工夫し、業務担当者の負担を最小限に抑えました。

6-4. ベンダーと良好な関係を築いた

概要設計の途中で、要件定義に定めのない追加要望が出てきました。
「予算執行状況表をExcelで出力したい」「合計残高試算表もExcelで」など、現場が触り始めて気づいた要望です。

仕様書には書いていないので、ベンダーは断ることができます。
それでも私がベンダーに頼み込み、対応してくれることとなりました。

現場メモ

ベンダーに対し「あれやれ、これやれ」と高圧的に扱うのは、長い目で見て損です。
仕様書にないことを助けてもらう場面が、必ず出てきます。
パートナーとして尊重し、Win-Winで進める姿勢が、結局は早く・確実にプロジェクトを進められます。
逆に、情シス側で対応できるものは引き受けて、ベンダーの開発工数を抑えることもあります。
お互いさまの関係づくりが、プロジェクトを円滑に進める鍵だと思います。

7. 開発を通じて感じたこと　～システム入替は発注者も大変～

正直、システム開発に携わるまでは、発注者（情シス）はそこまで大変になることはないだろうと思っていました。
実際に開発するのはベンダーであり、情シスは進捗を見ていればいいだろう、と。

しかし実際は、まったく違います。
発注者の仕事は、ベンダーへの指示を的確に行うことです。
ここをしっかりできないと、イメージと違うシステムが出来上がり、その責任はすべて発注側に返ってきます。

「ベンダーに任せておけば良いシステムができる」ことはありません。
発注側が何をどう伝えるかで、完成するシステムが変わります。

まとめ

システム開発の前半4工程で意識した工夫は、次の4つです。

• 現行システムのフロー図を作って、現行運用と新システムの差を共有する
• カスタマイズは最小限に絞り、運用回避を説得する
• 要員調整で、業務担当者の通常業務を圧迫しない
• ベンダーと良好な関係を築き、Win-Winで進める

一番の教訓は、「システム開発は発注者も大変」ということでした。
最終的に判断するのは情シス、全体を見渡せるのも情シス、ベンダーから判断を求められるのも情シスです。

ただ、ここまでは序盤です。
このあとに製造・テスト・データ移行・検証・本稼働が控えています。
次回以降も、これら工程の解説と、そこで起きた苦労を書きますので、お楽しみに。