こんにちは。ソフトウエア・サイエンス ビジネスイノベーション事業部の細井です。入社して以来20年以上様々なプロジェクトに関わってきました。現在はプロジェクトリーダーとして、建設関連業務のプロジェクト管理システムに長期的に携わり、既存システムの刷新や業務理解・要件整理などを行っています。
はじめに：コードを読んでも「なぜその機能があるのか」は分からない
仕様書が十分に残っていないシステムでも、ソースコードを解析すれば、現在どのような処理をしているのかはある程度把握できます。例えば、「このデータを入力すると、この処理を行い、この結果を出力する」という動きです。
しかし、コードだけでは分からないことがあります。それは、**「なぜ、この機能が必要なのか」**という業務上の背景です。
長年利用されている業務システムでは、システム上の処理だけでなく、Excel、手作業、別システム、部門間のやり取りなどを組み合わせて業務が成り立っていることがあります。
つまり、仕様書やプログラムだけを調べても、仕様書に書かれていない業務ルールや暗黙の運用までは把握できない場合があります。
この記事では、業務フロー、アクター、用語、現場ヒアリングなどから、システムの「本当の使われ方」をどのように読み解き、刷新後の業務へつなげていくのかを紹介します。
この記事でわかること
- なぜシステムだけを見ても業務上の仕様が分からないのか
- 現行業務を理解するときに確認すべきポイント
- 業務用語を理解することがなぜ重要なのか
- 仕様書にない手作業や暗黙ルールをどう見つけるか
- アクターを把握しないことで起きる手戻り
- 現行業務から将来の業務フローをどう考えるか
この記事はこんな方におすすめです
- 仕様書と実際の業務が一致しているか分からない方
- システム刷新前に現行業務を整理したい方
- 現場ごとにシステムの使い方が異なっている方
- Excelや手作業が多く、実際の業務フローが見えにくい方
- 要件定義で現場との認識ズレを減らしたい方
SSIでは、レガシーシステムの刷新や複雑化・属人化した業務に対して「業務フロー中心設計技法」を用い、現状の業務から理想の業務までを可視化するアプローチを取っています。
このシリーズについて
この記事は「仕様書がないシステムの刷新」を3つの視点から解説するシリーズの業務理解編です。
刷新プロジェクト全体の進め方を知りたい方
「仕様書がないシステムの刷新方法」
データ・DB・ソースコードから現行システムを技術的に調査する方法を知りたい方
「仕様書がないシステムの技術的な読み解き方」
システムの動きが分かっても、業務の目的までは分からない
ソースコードを見れば、
- 何を入力するのか
- どのような処理を行うのか
- 何を出力するのか
といった機能は確認できます。一方で、「なぜこの処理が必要なのか」、「この機能を使った後、ユーザーは何をするのか」までは分からないことがあります。
例えば、システムからデータを出力した後にExcelで加工し、その結果を別システムへ入力しているかもしれません。そのような場合、元のシステムだけを解析しても業務全体は見えてきません。システム刷新では、単に現在の機能を再現するのではなく、その機能が業務の中でどのような役割を担っているのかを理解する必要があるのです。
まず確認するのは「誰が・いつ・何をするか」
現行業務を理解するときには、一つの機能だけをピンポイントで見るのではなく、その前後関係を確認します。私が特に意識しているのは、
- 誰が（Who）
- いつ・どのような場面で（When）
- 何をするのか（What）
です。例えば同じ入力項目を持つ画面が2つあったとしても、一つは日常業務を行う担当者、もう一つは別の立場の担当者が使っているかもしれません。
画面だけを見れば、「同じ情報なら一つにまとめればよい」と判断したくなります。しかし、アクターや利用場面が違えば、それぞれの画面が必要な理由も違います。
だからこそ、システムの機能を見るだけでなく、その機能が業務のどこに位置し、誰が何のために使っているのかまで確認します。
業務を理解するには、まず「用語」を理解する
業務システムでは、その企業や業界独自の言葉が数多く使われます。今回のような原価やプロジェクト管理に関わるシステムでも、一般的な原価管理の知識だけでなく、顧客企業独自の用語や業務上の意味を理解しなければ会話が成立しません。
そのため、まず一般的な業務知識を確認し、そのうえで顧客独自の言葉を一つずつ理解していきます。
用語理解と業務理解の流れ
- 業務領域の基本知識を調べる
- 顧客独自の用語を確認する
- 業務全体について自分なりの仮説を持つ
- ユーザーへ確認する
- 業務フローへ反映する
用語の意味が分からなければ、その業務の目的も正しく理解できません。例えば、あるお客様では「仕入品」という言葉に複数の意味がありました。一括で仕入れるものを指す場合もあれば、取扱頻度が低いものを指す場合もあります。
同じ言葉でも業務によって指しているものが異なるため、その違いを理解していないと、お客様との認識がずれてしまいます。
用語確認と業務フロー作成は、同時並行で進める
すべての用語を理解してから業務フローを作るわけではありません。実際には、業務フローを作る → 分からない用語・処理が出てくる → ユーザーへ確認する → 業務フローを修正するという作業を繰り返します。
業務フローを作ることで、
- 誰が
- 何を
- どの順番で行うのか
- どこでシステムを使うのか
- その結果をどこへ渡すのか
が見えるようになります。システムそのものだけでは見えなかった前後の業務も、業務フロー上に並べることで理解しやすくなります。
初期段階では、画面より業務フローを優先する
システム刷新というと、「新しい画面をどうするか」、「入力項目をどうするか」といった話から始めたくなるかもしれません。
しかし、将来の業務そのものを変えるのであれば、画面は後から変わる可能性があります。そのため、まず、
- 現在どのような業務をしているのか
- どこに課題があるのか
- 将来どのような業務にしたいのか
を整理します。その中で、「このExcel作業はシステム化しよう」、「この帳票は不要になる」、「この入力は一度で済むようにしよう」といった改善案を考えていきます。
画面やUIは、その業務を実現するための手段として考える方が自然です。
「仕様書にない仕様」は現場ヒアリングから見つかる
ユーザーへ業務をヒアリングすると、システムだけを見ていては分からない処理が出てきます。例えば、
- Excelでデータを加工している
- 紙で承認している
- メールで担当者へ連絡している
- 別システムへ再入力している
- 例外時だけ手作業で処理している
- 部門間で独自のルールがある
といったものです。こうした作業も、実際の業務を成立させている重要な要素です。例えば、「この機能を使った後、次に何をしますか？」と聞くことで、「実は次に別システムを使っています」ということが初めて分かる場合があります。
その結果、「刷新後は別システムを介さず、新システム側へ取り込めないか」といったTo-Beの検討にもつながります。
例えば、ある案件では、機器の原価は機器マスタから自動取得されるものと理解していました。
しかし、現場へのヒアリングで、一部の機器では別ツールで算出した原価を採用していることが分かりました。この運用は仕様書やシステムからは把握できず、ヒアリングによって初めて判明した業務ルールでした。
そのため、刷新時には特定の機器に限り原価を編集できる仕組みを検討することになりました。
「困っていること」を聞くと、刷新後の業務像が見えてくる
現状を把握するだけでなく、「現在どこで困っているのか」も確認します。例えば、
- 同じ情報を複数回入力している
- 手作業でExcelを加工している
- 別システムへ転記している
- 担当者の経験だけで判断している
といった課題です。これらを整理すると、「次のシステムでは何を改善すべきか」が見えてきます。
ただし、単純に作業を統合すればよいとは限りません。
「同じ入力だから統合する」が、業務上の正解とは限らない
例えば、2つの画面に同じような情報を入力しているとします。システムだけを見れば、「同じ情報を二度入力しているなら、一つの画面にまとめた方が効率的ではないか」と思います。
しかし、
- A画面はAという立場の人が使う
- B画面はBという立場の人が使う
のであれば、単純に統合すると業務が回らなくなる可能性があります。私自身も経験が浅い頃は、機能だけを見て、「こちらの方が効率的だろう」と判断して改修したことがあります。
しかし、業務全体を理解できていなかったため、良かれと思った変更が実際の利用方法と合わなかったこともありました。
こうした経験から、現在は、技術的な効率だけではなく、誰が何のために使っているのかを見ることを重視しています。
アクターの見落としが、リリース前の要件見直しにつながる
業務ヒアリングでは、「誰に聞くか」も非常に重要です。同じ会社の中でも、
- 日常的にシステムを使う担当者
- 複数案件を管理する担当者
- 管理職
- 部門責任者
- 導入や予算を判断する責任者
では、見ている課題が異なります。
実際のプロジェクトでも、機器の手配時期などを管理するシステムで、担当者とは長期間にわたって調整を続け、「この内容でリリースしましょう」という認識合わせが完了し、リリースに向けた最終確認を進めていた段階で、上位責任者からNGが出たことがありました。
日常的に操作する担当者との調整では大きな問題はないと考えていました。ところが、管理者から見ると、「一人が複数案件を持つ場合、手配期限を忘れる可能性がある。通知機能がなければ業務品質を担保できない」という重要な視点がありました。
そこで初めて、期限を通知するアラート機能の必要性が明確になりました。そのため、要件の見直しと追加対応が発生し、関係者間で改めて業務要件を整理することになりました。
なぜ見落としたのか
日常利用する担当者の視点では、その人自身の業務は見えていました。しかし、複数の担当者や案件を管理する側の視点が要件整理に十分入っていなかったのです。
この事例から得た教訓
- 実際の操作担当者だけに聞けばよいわけではない
- 管理者は、担当者とは違うリスクを見ている
- 最初に関係するアクターを洗い出す
- 主要利用者だけでなく、意思決定者も適切な段階で巻き込む
- 最後に上位者へ確認するのではなく、途中段階でも認識を合わせる
後工程で要件が変われば、設計や実装の見直しにつながり、顧客側・開発側の双方に追加負担が発生します。
顧客のTo-Beに、SIerがシステムの視点を加える
将来、「どのような業務にしたいのか」という方向性は、基本的には顧客側が持っています。一方で、「その業務をシステムでどう実現するか」には、システム側の知見が必要です。
例えば、
- 手作業をシステム化する
- 二重入力をなくす
- 複数システムの処理を統合する
- 帳票を廃止する
- 新しい通知機能を追加する
などです。顧客が将来の業務の骨格を描き、SIerがシステムの観点から肉付け・調整する。その両方を組み合わせることで、業務とシステムを両立したTo-Beへ近づいていきます。
SSIでも、業務フローからAs-IsとTo-Beを可視化し、顧客のビジネスプロセス分析・改善へつなげる「業務フロー中心設計技法」をITコンサルティングの特徴として掲げています。
業務を理解せずに刷新すると、業務が回らなくなる
現行システムの機能だけを見て刷新すると、「新しいシステムは完成したが、実際の業務では使いにくい」ということが起こる可能性があります。例えば、現在は少量の手作業で済んでいたものが、新システムではかえって手作業が増えるかもしれません。
また、「同じ入力だから一つにまとめた」結果、「実際には利用者や目的が違い、業務が回らなくなった」ということも考えられます。
システム刷新で重要なのは、現行機能をそのまま置き換えることではありません。業務全体を理解したうえで、本当に変えるべきものを見つけることです。
業務側から現行システムを把握するときのチェックリスト
| 確認項目 | 確認したいこと |
|---|---|
| アクター | 誰が業務・システムに関係しているか |
| 利用場面 | いつ、どの場面で利用するか |
| 業務目的 | なぜその機能・作業が必要なのか |
| 業務用語 | 顧客独自の言葉を理解できているか |
| 前後工程 | その作業の前後に何があるか |
| 手作業 | Excel、紙、メールなどが残っていないか |
| 例外処理 | 通常とは異なる運用がないか |
| 部門間連携 | 他部門へどのように情報を渡しているか |
| 現場課題 | 現在困っていることは何か |
| 意思決定者 | 最終的な判断をする人が誰か |
仕様書のないシステム刷新全体について知りたい方へ
業務理解は、現行調査の一部です。現行調査から刷新範囲、見積、将来像をどう整理するのかについては総合編で解説しています。
[ここに「仕様書がないシステムの刷新方法」への内部リンクを追加→CPS対応]
技術側からデータ・DB・コードを調査する方法については、技術調査編をご覧ください。
[ここに「仕様書がないシステムの技術的な読み解き方」への内部リンクを追加→CPS対応]
よくある質問
Q. ソースコードを見れば、現在の仕様は分かりませんか？
システム上の処理は確認できますが、なぜその処理が必要なのか、実際の業務でどう使われているのかまでは分からない場合があります。
Q. 業務フローがない場合、何から確認すればよいですか？
まず、誰が、いつ、何をしているのかを確認し、業務の前後関係を整理します。
Q. 現場ヒアリングでは何を聞くべきですか？
現在の作業内容だけでなく、その目的、前後の業務、手作業、困っていること、例外処理なども確認します。
Q. 実際の利用担当者だけに聞けば十分ですか？
十分とは限りません。管理者や部門責任者など、異なる立場の関係者から見た要件も確認することが重要です。
Q. 現行業務と将来の業務は、どちらを重視すべきですか？
両方必要です。現状を理解したうえで、本来どうしたいのかを整理することで、必要な刷新内容が見えてきます。
まとめ
仕様書に書かれていない「本当の使われ方」を把握するためには、システムだけを見るのでは不十分です。
- コードからは処理は分かっても、その背景や目的までは分からない
- 「誰が・いつ・何をするか」を整理する
- 顧客独自の業務用語を理解する
- 用語確認と業務フロー作成を同時並行で進める
- Excelや手作業など、仕様書にない運用も確認する
- 実際の利用者だけでなく、管理者や意思決定者も含めてアクターを整理する
- 技術的な効率だけでなく、業務全体で最適なTo-Beを考える
仕様書を復元すること自体が目的ではありません。業務の中で、そのシステムがなぜ必要なのかを理解することが、刷新すべき仕様を見極めるために重要です。
システムだけでなく、現行業務の整理から刷新を検討できます
- 仕様書と実際の業務が一致しているか分からない
- 現場独自のExcelや手作業が増えている
- 担当者によって業務やシステムの使い方が違う
- 業務フローから整理して刷新を考えたい
- 要件定義へ入る前に、関係者の認識を揃えたい
SSIは、業務フローを起点にAs-IsとTo-Beを可視化するITコンサルティングを提供し、必要に応じてシステム開発・導入、運用・保守まで支援しています。