速いシステムを作っても、仕事が遅くなる理由

架空事例：青葉機材が機材貸出しの業務を見直す。件数、処理時間、組織名、投資判断は独自の説明用設定であり、実際の業務調査や投資効果を示さない。

画面は速くなった。受付は遅くなった

新しい予約画面は二秒以内に応答した。以前は五秒かかっていたので、性能は改善した。それなのに営業が一件の貸出しを確定するまでの時間は、かえって長くなった。

新システムでは、顧客名を入力した後、機材の型番を検索し、納期を確認し、別の画面で契約条件を調べ、上司へ承認を依頼する。必要な情報が複数のシステムへ散らばっていた。画面を速くしても、処理の間を行き来する手間は消えなかった。

応答時間と、業務が完了するまでの時間は違う。これは技術部門の失敗だけではない。何を改善する投資だったのか、目的を定義しないままシステムの機能へ進んだことが原因である。

IPA SAシラバスVer.5.2は、システム化計画の立案で対象業務の確認、課題定義、業務モデル、方式選定、実現可能性、投資効果の予測を要求している。1 アーキテクトは技術の選定より前に、事業上の問題を特定する。

問題と、依頼された解決案を分ける

営業部長は「検索画面を一つにしてほしい」と依頼した。これは解決案である。背後の問題は、受付に時間がかかり、顧客へ納期を回答できないことかもしれない。

仮に画面を一つにまとめても、機材の在庫情報が前日のままなら、正しい貸出可否を判断できない。問い合わせに時間がかかる原因が、データの更新方法や部門間の確認手順にあれば、UI変更だけで目標は達成しない。

現状業務を調べるときは、標準手順書だけでなく、実際にどこで待っているかを見る。営業が手元の表計算へ在庫情報を転記し、配送担当へ電話で確認しているなら、その二重管理が課題になる可能性がある。ただし、その手作業があるからといって全てを自動化すべきとは限らない。例外時の安全確認として必要な部分もあるからだ。

IPAの要件定義ガイド第2版の公開目次には、業務の現状理解、関係者の合意、データ・インタフェース・非機能・運用・移行の要求を明確にする観点が整理されている。2 ここでは公開目次の範囲を参照し、販売されていた本文全体を確認したとは扱わない。

業務モデルは、画面設計の前にある

青葉機材の貸出しには、予約受付、与信確認、機材引当、配送計画、返却受付、整備という仕事がある。どれがどの情報を参照・更新するか、誰が判断するかを整理すると、初めてシステムの機能を割り当てられる。

同じ「予約確認」という名前でも、顧客向けの予約状況照会と、営業が出庫を確約する判断は異なる。顧客が予約希望を出した時点で枠を確保するのか、契約条件の承認後に確保するのかで、データの更新タイミングも必要な整合性も変わる。

業務モデルの役割は、現行の画面を写すことではない。業務として達成したい仕事と、組織・情報・判断の関係を描くことである。そこからシステム化する範囲と、人の判断を残す範囲を選ぶ。

DFDはデータの受渡し、ER図は情報の実体と関連、CRUDマトリクスは機能がデータをどう操作するかを見る。表現する対象が違うので、図の数を増やせば分析が深くなるわけではない。検討中の問題に応じて必要な表現を選ぶ。1

KPIは、改善した理由を説明できるか

「一件当たりの受付時間を半分にする」と定めた。指標としては分かりやすい。しかし、急いで確認を省くと、誤った貸出確約が増えるかもしれない。

青葉機材は受付時間だけでなく、納期の誤回答件数と手戻り件数を併せて測る案を考える。短縮した時間が、後からの訂正や苦情に置き換わっていないかを見るためである。指標は、望ましい結果を代表している必要がある。

先行指標と結果指標も区別する。契約条件の照合を自動化した割合は、業務改善の進み方を見る指標になり得る。顧客へ確定回答するまでの時間や誤確約件数は、業務結果を評価する指標である。前者だけを良くしても後者が改善するとは限らない。

システム稼働後に指標を再び測るなら、同じ定義で比較する必要がある。旧システムの受付時間に電話確認を含めず、新システムだけ含めれば、数字は比較できない。期間、対象業務、例外処理を含むかを明記する。

PoCで分かることと、本番でしか分からないこと

技術担当は、新しい在庫照会APIを試し、数百件のデータを高速に検索できた。実現可能性を確認するPoCとしては意味がある。しかし、実際には複数拠点が同時に更新し、回線が途切れ、機材番号の体系も一部異なっている。

試作で確認したのは、限定した条件のもとで技術が動くことだ。現場で利用する人員、移行時の照合、契約先の利用状況、運用保守の費用まで確定したわけではない。

実現可能性には技術的な成立だけでなく、納期、予算、データの移行、継続運用、関係者との合意が含まれる。方式を評価するとき、何をまだ実証していないかを記録することが重要になる。1

「クラウドならスケールできる」という言葉も条件付きだ。データベースの更新が集中しているなら、アプリケーションの台数だけ増やしても効果がない場合がある。何が律速しているかを見なければ、投資の選択は決められない。

システム化しない選択も、方式の一つ

配送員が機材の点検状態を確認する仕事を考える。すべての判断を自動化する案もあるが、現場の目視検査を残し、結果だけをシステムへ記録する案もある。

自動化できることと、業務の責任を自動化すべきことは別である。法令や契約、利用者の能力、例外の頻度により選択は変わる。業務全体を見ないまま、技術的に処理できる部分をすべて対象にすると、費用も責任も膨らむ。

逆に手作業を残す場合、システムとの情報の受渡しや、記録の時点が曖昧なら別の欠陥を生む。人の仕事とソフトウェアの仕事の境界は、責任が消える場所ではない。

投資判断へ戻す

青葉機材が初めに抱えていた問題は、受付時に顧客へ正しい納期を伝えられないことだった。画面の応答改善は、その一部の手段にすぎない。

方式を比較する際は、業務目標への寄与、初期費用、継続費用、リスク、移行可能性を並べる。安価な構成でも例外対応に人手がかかれば、総保有費用は高くなる。性能がよくても業務の目的に結び付かない機能は、投資効果を説明できない。

システムアーキテクトの仕事は、最新技術に詳しいことだけではない。採用した方式が、解決したい業務問題へどう作用するかを、導入前と導入後で確かめられる形にすることである。

知識を答案へ戻す

午前Ⅱ。 業務モデル、システム化対象、非機能要件、PoC、KPI、投資効果の位置づけを区別する。似た名称の図や手法を目的から選ぶ。

午後Ⅰ。 顧客の依頼、現行業務の問題、設計方式の条件を本文から分離する。提案された機能が業務目標へ必要かを検討する。

午後Ⅱ。 調査した業務の課題、選択肢、採用理由、未確認の制約、効果測定の方法と結果を具体的な順序で説明する。

立ち止まって考える：予約画面の応答を5秒から2秒へ改善できた。業務効率も改善したと言い切れるか

言い切れない。受付完了までの工程、データの鮮度、承認待ち、例外処理、誤確約などを含む業務全体を評価しなければならない。

出典と照合範囲

[1] コンプリートテキスト第1・3・4・8・25章、IPA SAシラバスVer.5.2：システム化計画、業務モデル、方式、PoC、投資効果の関係を参照した。本文の指標と業務例は独自の仮定。公式シラバス

[2] IPA「ユーザのための要件定義ガイド 第2版」公開紹介・目次：データ、インタフェース、非機能、運用・移行などを検討する観点を参照した。販売された本文全体を閲覧したと主張しない。IPA公開ページ