ビジネスアナリスト · 業務ごと
分析の単位は職種名ではなく業務である。以下の一つひとつが、その方向、判断が証拠に基づくのかプラットフォームの推論なのか、その理由、そして何を立証していないかを伴っている。
このページのすべての業務#
要件を引き出す
増強されつつある≈ 本サイトの推定関係者や利用者に話を聞き、何が必要かを突き止める。本人が言おうと思いつかないことも含めて。
チャットボットはいまや、構造化された要件の聞き取りを進められる。33回の模擬の聞き取りで、あるチャットボットは人の聞き手と同程度の数のよくある誤りを犯し、全要件の最大73.7%を引き出した。それでも著者たちは、機微な、あるいは複雑な要件の引き出しには人が主導する聞き取りが必要だと考えている。そこでは人と人とのやりとりが、口にされない要件を明らかにするからである。米国の予測は、ビジネスアナリストを含む職業の雇用が増えると見ている。
学生が関係者を演じた模擬の聞き取りであり、実際のプロジェクトやアナリストの時間を測ったものはここにはない。
要件とユーザーストーリーを書く
増強されつつある✓ 証拠に基づく聞き取ったことを、開発者や試験担当者がそのまま作業に使える要件の文書、仕様書、ユーザーストーリーにする。
言語モデルが届いたのはここである。米国退役軍人省は、ユーザーストーリーを生成しワークショップの結果を要約する導入済みのシステムを一覧に載せており、社会保障庁は、古いコードから業務要件の文書を生成するシステムを載せている。ある研究では、GPT-4 が起草した要件仕様書は初級の技術者のものに匹敵し、かかった時間はそのごく一部だった。実際の現場では得られるものはもっと小さい。ある IT コンサルティング会社では、アナリストが削減を10〜15%と見積もり、下書きは書き留められたことのない知識を取りこぼしていた。ある郵便グループの IT チームでは、ユーザーストーリーを書き直すエージェントの出力を、プロダクトオーナーが検証する必要があった。
一覧の記載は仕組みを説明するものであって、職員への影響ではない。研究が使っているのは、大学のプロジェクト一つ、コンサルティングのプロジェクト一つ、そして小さな試行である。
業務の流れを図にし分析する
増強されつつある≈ 本サイトの推定いま仕事がどう行われているかを図にし、どこで崩れるかを見つけ、変更の後にどう動くべきかを設計する。
ソフトウェアは、システムの記録から業務の流れを再構成し、図の下書きをつくれる。しかし、その流れがどうなるべきかを決めることには、それを回している人たちと、誰かが責任を負う損得の選択が関わる。道具がいまこの仕事のどれだけをしているかを測った一次資料は、ここにはない。
仕事の記述からの推論であり、ここに記録された一次資料で、業務の流れを図にする仕事や、そのうち道具が担う割合を測ったものはない。
ワークショップと関係者の合意形成
いまも人が主導≈ 本サイトの推定ワークショップを進め、部門どうしの食い違う要求を解きほぐし、範囲と優先順位について合意を取りつける。
道具はワークショップが何を結論したかを要約できるが、部門どうしを合意させることは人と人との交渉である。米国の予測は、経営分析職の雇用が2025年から2035年に10%、コンピュータシステムアナリストの雇用が8%増えると見ている。O*NET は、IT business analyst のようなビジネスアナリストの職名を、その両方に分類している。
予測が扱うのはコンサルタントやシステムアナリストを含むより広い職業であり、数えているのはタスクではなく職である。
受け入れと変更の管理
いまも人が主導≈ 本サイトの推定届いたものが要件を満たしているかを利用者と一緒に確かめ、変更の依頼をさばき、新しい働き方に向けて人を準備させる。
受け入れは、その仕組みを使う人たちに代わって下される判断であり、ここに記録された試行では、AI が改善したユーザーストーリーでさえ、使う前に人が検証していた。
ここに記録された一次資料に、受け入れやチェンジマネジメントの作業を測ったものはない。推論である。