BtoB SaaSのデザイン・開発において「業務理解」という言葉が使われる、これってどういう意味なのか？
先ず、ユーザーがどんな業務を行っているか知る必要がある。それが分かれば、その業務を「こう変えていこう」と議論することができるから
やることは「今の業務を別の業務に変えること」なのである。今の業務が煩雑になっている非効率になっている属人化してしまっている、そこから脱却するために今の業務を止め、別の新しい業務に置き換えよう。これをやろうとしているのである ※ここで使っている「業務」とは「業務フロー（業務の流れ・やり方）」のことである
BtoB SaaSとは「ソリューション」のこと、つまり課題を解くもの。SaaSを作る前に課題が分かっていないといけないし、課題を見つけるためには業務を理解しないといけない。業務内に潜む問題・課題を特定し、それを解くことが目的であり、ソリューション候補がSaaSなのである。つまり、SaaSを作るときに始めにやらないといけないことは、ユーザーの業務実態を知ることなのである
【要するに】BtoB SaaSを作ろうとしている、と言うことは、課題を特定しないといけない、そのためにはユーザーの業務を理解しないといけない、なので、始めにリサーチを行いユーザーの業務フローを把握し、業務内に潜む問題を見つける所から始めないといけない
これをロジックに落とすと、「SaaSを作る予定 → 課題特定 → 業務把握」となる。これを正しいロジックに落とすと「ユーザーの業務実態の把握 → 課題特定 → ソリューション（SaaS）設計」となる
SaaSを作るときの起点は「業務理解」なのである。では、どうやって業務理解を進めるのか？
先ず、そもそも業務とは何か？を考えたときに、私は以下だと考えている
時間軸が存在している
そこにタスクが埋め込まれていく
物理 / 非物理がある
人が介在する
これらを統合的に表現するなら「時間経過の中に人が行うタスクがありそれらは物理空間 or 非物理空間で行われる」
では、タスクとは何か？それは「情報の移動と物理世界での何かしらの変化」である
これだと概念的なので、具体的な表現に置き換えると以下のようになる
「（業務とは）その人が会社で行う仕事のことで、色々な人達が関わっている。業務時間内に行われるもので、情報（例：従業員情報）を扱ったり、ツール（例：勤怠管理ツール）を使ったりする」
これが業務である
この（ユーザーの）業務を知ることが始めの一歩目なのである
（脱線したが改めて）どうやってそれを知るのか？その方法とは？
Contextual Inquiryと言う手法論がありこれが使える
ユーザーの業務が全く分からないとき、インタビューを通してそれを理解することができる。インタビューするときに「人 / 物 / 情報 / 空間 / 時間軸」の軸でユーザーの業務を聞いていけると、業務実態が顕になってくる。これが仮説生成型のリサーチ