速い画面を作っても、仕事は終わらない

事例設定：本巻の「青葉機材」は架空の機材レンタル会社である。会社、数値、会議、設計判断は学習のために作成したもので、IPAの過去問題や実在企業の事例ではない。

返事を待っている人は、CPUを待っていない

午前十時、工事会社から測定器を借りたいという電話が入る。営業担当者は在庫照会の画面を開く。表示に三秒。倉庫を選び直すと、また三秒かかる。「システムが遅い」という苦情は、もっともに聞こえた。

青葉機材は三つの倉庫で機材を管理している。営業は契約条件を確認し、倉庫は貸出し可能な実機を確認する。予約を確定するには両方の確認が必要だ。実機には点検中、返却予定、他の予約への割当てといった事情があり、棚にある台数がそのまま貸出し可能台数になるわけではない。

情報システム部門は画面の高速化を提案した。三秒を一秒にすれば、確かに操作は軽くなる。しかし、電話の記録をたどると、顧客へ可否を回答したのは午前十一時二十分だった。八十分のうち、画面を待った時間はほんの一部である。倉庫への確認、担当者からの折返し、営業による再確認が大半を占めていた。

速い画面は必要かもしれない。だが、それだけでは八十分の待ち時間を解けない。

ここで観測した事実は「回答に八十分かかった」であり、利用者の解釈は「システムが遅い」、最初の対策案は「画面を高速化する」である。事実、解釈、対策案を一つの文章にすると、原因を調べる前に実装方針が決まってしまう。SAシラバスは、対象業務の内容の確認、システム課題の定義、業務モデルの作成を区別している。これは工程名を暗記するためだけの区分ではない。何が起きているかを知ることと、何を変えるべきかを決めることは別の仕事だからである。1

一つの「遅い」を、異なる時計で測る

同じ業務には複数の時計がある。画面への要求から表示完了までの時間。担当者が実際に操作している時間。問い合わせを受けてから顧客へ回答するまでの経過時間。顧客が機材を必要とする時点までに、貸出しを確約できるかという期限。それぞれの時計は、異なる改善を評価する。

仮に一件の問い合わせで在庫画面を六回開くなら、三秒から一秒への改善で短縮できる画面待ちは十二秒である。この計算は、六回という操作回数が変わらず、ほかの処理へ影響しないという事例上の仮定に基づく。十二秒の短縮を過小評価する必要はない。毎日数百件の操作なら担当者の負荷に効く。ただし、その効果を「顧客への回答が八十分から短時間になる」と説明することはできない。

一方、倉庫確認を自動化すれば、待ち時間の大きな部分を減らせる可能性がある。ここで「自動化」という言葉だけを採用すると、別の問題が残る。倉庫担当者は何を根拠に貸出し可能と判断しているのか。点検結果は記録されているか。返却予定が遅れたとき、その情報は誰が更新するのか。これらが未整理なら、今まで電話で補っていた判断を、画面に移しただけになる。

測定の結果は、対策を一意に決めるものではない。どこに時間があるかを示し、次に調べる対象を絞る。営業の手元だけを観測すれば「電話を待つ時間」となるが、倉庫側へ視点を移すと、点検結果を紙から探す時間かもしれない。分析範囲を組織の境界で切ると、原因まで切り落とすことがある。

目的、業務要件、機能を一本の因果にする

経営側の目的を「回答の遅れによる失注を減らす」と置く。その目的を実現する業務のあり方として、「標準的な貸出し依頼は営業がその場で可否を判断できる」を検討する。さらに、その判断を支えるシステム機能として、点検状態、予約済数量、返却予定を合わせて確認する機能が候補になる。

この三つは同じ粒度ではない。

記述の例	その記述が決めていること
回答の遅れによる失注を減らす	事業上、何を改善したいか
標準条件の依頼を営業で判断し、例外は倉庫責任者へ回す	誰が、どの条件で、どの業務を担うか
指定期間の貸出し可能数量と判断根拠を表示する	システムがどの振る舞いを提供するか
所定の負荷条件で照会結果を所定時間内に表示する	その振る舞いに必要な品質・制約は何か

表は本事例の整理であり、規格がこの四行の名称や様式を一律に要求しているわけではない。業務要件は単なる経営目標の言い換えでもない。SAシラバスの業務要件には、手順、入出力情報、組織、責任、権限、ルール、制約などが含まれる。機能要件へ進む前に、人の仕事を含む新しい業務を決める必要がある。1

営業が判断できるようにする案には、業務側の変更が含まれている。今まで倉庫しか承認できなかった貸出しを営業へ委ねるなら、表示項目の追加だけでは完成しない。委譲する権限、判断できる条件、例外の扱い、教育を合わせて決めなければならない。

反対に、営業へ判断を委譲できない契約条件があるなら、その条件は設計の制約になる。「自動化できる技術がある」ことから「その業務を自動化してよい」ことは導けない。技術的実現性と、業務上の許容範囲は別に確かめる。

IPAの要件定義ガイドは、ビジネス要求の獲得・分析・文書化と、システム化要求の仕様化・確認を分けて扱っている。本巻でも、利用者の要望をそのまま機能一覧へ転記せず、必要な業務上の変化を間に置く。2

現行業務を正確に描くことと、そのまま残すこと

青葉機材では、同じ予約内容を営業と倉庫がそれぞれ入力していた。二重入力をなくす方針には、全員が賛成した。ところが、倉庫担当者は「営業の入力だけでは足りない」と言う。

営業が入力するのは、顧客が求める機種、数量、使用期間である。倉庫が入力するのは、実際に割り当てる個体、点検の状態、出庫の準備時刻だった。二つの入力は見た目が似ていても、すべてが重複ではない。

項目を照合すると、顧客名と契約番号は重複していたが、個体の割当ては倉庫で新たに決めていた。削除すべきものは前者の再入力であって、後者の判断ではない。業務改革を「既存作業を減らすこと」だけで捉えると、必要な統制や情報生成まで消してしまう。

As-Isは現状、To-Beは目標とする状態を表す整理である。現行を描いた後に未来の図を別に作るだけでは、変更の妥当性は説明できない。「この待ち時間を減らすために、この情報をこの時点で共有する」「この確認は事故防止に必要なので残す」という対応が要る。NASAのシステム工学ハンドブックでも、利害関係者の期待を運用構想と結び、関係者と合意する活動が扱われている。ただし、NASA固有の承認手続を一般業務システムへそのまま移植することは本巻の目的ではない。3

取り除く対象を判断するときには、作業の名前より、その作業によって何が確かめられ、何が生成されるかを見る。承認欄が二つあるという事実だけでは、無駄な二重承認とは言い切れない。契約条件の承認と安全点検の確認なら、保証対象が異なる。逆に、同じ情報を同じ基準で確認しているだけなら、統合できる余地がある。

境界の外に残した仕事にも、受渡しがいる

初回のシステム化では、特殊機材の貸出し判断を対象外にすることになった。専門的な点検が必要で、判断の条件がまだ十分に整理されていないからである。標準機材から始めるのは合理的な選択になり得る。

しかし、「対象外」とだけ書くと、営業はその依頼をどこへ回せばよいか分からない。

対象外であるのは、特殊機材の貸出し可否を自動判定する機能である。特殊機材への依頼が来たことを認識し、担当者へ引き渡し、結果を営業へ返す業務まで消えるわけではない。システムは判定をしなくても、受付番号や担当部署、対応状態を保持する必要があるかもしれない。この必要性は、対象外という語からではなく、採用した業務の流れから導く。

同じことは外部サービスとの連携にも起きる。外部が判断するからといって、自社側が受け取る結果の意味、期限、失敗時の連絡先が不要になるわけではない。どの仕事を内側で行うかを決めると同時に、外側へ何を渡し、何を受け取るかを決める。それが実際に使える境界である。

改善を証明する分母を残す

新しい業務では、標準依頼の回答時間を短縮できそうだ。そこで「平均回答時間を短縮する」を評価指標にした。だが、特殊機材の問い合わせを集計から外せば、何も改善しなくても平均は小さくなり得る。比較する対象が変わったためである。

この事例では、標準依頼と例外依頼を区分したうえで、それぞれの受付件数、回答完了時刻、未回答件数を記録することにする。標準依頼の条件は、対象機種、数量、使用期間、契約条件として定義する。改善前後で同じ定義を適用し、受付から回答までの経過時間と担当者の作業時間を別に測る。数値が必要なのは、目標を立派に見せるためではない。何が変わったかを後から区別するためである。

さらに、回答が速くても誤った貸出しを確約していれば、事業目的は達成できない。回答後の取消しや、約束した機材を用意できなかった事象も見なければならない。指標を一つ改善すると、別の重要な性質が悪化する場合がある。だからといって指標を無制限に増やすのではなく、採用した対策が損ない得るものを選んで監視する。

SAシラバスの投資効果・業務効果の評価には、改善目標と成果指標の設定、適切な指標による効果分析が含まれる。企画時の目標と稼働後の評価を離してしまうと、納入した機能は説明できても、投資の結果を説明できなくなる。1

営業担当者の最初の苦情は、間違いではなかった。三秒の画面は確かに遅い。ただし、その三秒の向こうには、共有されていない情報と、定まっていない判断権限があった。システムアーキテクトが扱うのは、画面の内側だけではない。

知識を答案へ戻す

午前Ⅱの判別軸。 業務目標、業務要件、機能要件、非機能要件を、単語の印象だけで分類しない。「誰が何を達成するか」「どの業務をどう行うか」「システムが何をするか」「どの条件・品質で行うか」という記述対象を確認する。手作業を含む責任・権限の設計を、画面仕様の問題へ縮めない。

午後Ⅰへの接続。 事例問題では、一般知識から原因を作らず、問題文にある待ち、再入力、承認、情報の更新時点を根拠にする。本事例なら「サーバ性能不足」ではなく、「倉庫の確認結果を待つため営業で回答を完結できない」と読む。サーバ負荷の事実が与えられていない限り、負荷を原因として足さない。

午後Ⅱへの接続。 「業務効率化のためシステムを刷新した」だけでは、設計判断が見えない。「回答の大半が倉庫確認待ちだったため、標準条件の依頼に限って営業へ判断権限を委譲し、その判断に必要な点検状態と予約状況を照会できるようにした」と書くと、観察、制約、業務変更、システム機能がつながる。これは本事例の説明例であり、公式解答や採点基準ではない。

立ち止まって考える：確認画面を一つ減らせば、改善といえるか

画面が確認していた対象を調べる必要がある。重複した内容確認なら削減できるかもしれない。一方、契約条件の承認と機材の安全確認を混同して削除すると、異なる責任まで消してしまう。操作時間だけでなく、誤確約や取消しの発生を含め、元の業務目的との関係で判断する。

出典と照合範囲

[1] IPA「システムアーキテクト試験 シラバス Ver.5.2」：4-2、4-3、4-6、5-2、20-1。業務分析・要件・効果評価の位置付けを照合。会社の数値や改善案は同資料にはなく、本書の架空設定である。公式PDF

[2] IPA「ユーザのための要件定義ガイド 第2版」：公開ページの目次、第4章「ビジネス要求定義」、第5章「システム化要求定義」。両領域を分ける構成を参照。本章は同書の要約・転載ではない。IPA公開ページ

[3] NASA Systems Engineering Handbook, 4.1 Stakeholder Expectations Definition：運用構想、利害関係者の期待、合意の関係を参照。NASA固有の役割・必須手続をSA試験の要件として扱ってはいない。NASA本文