「はじめよう！プロセス設計〜要件定義のその前に」を読んでみて

今回は以前読んだ「はじめよう！要件定義〜ビギナーからベテランまで」の姉妹本「はじめよう！プロセス設計〜要件定義のその前に」を読んだので内容と感想をまとめました。

業務で要件定義フェーズに携わる機会が多いのですが、その際にまずは既存の業務フローを整理することがよくあります。
その際、複雑な業務フローを分かりやすく効率的にまとめられたらと思い、本書を手に取りました。

プロセス設計とは

プロセス設計で行うことは以下と言われています。

• 出すべき成果を定める
  • 何のために一連のプロセスを実行するのか？を考える
• 成果を出すために必要な仕事を考えて定める
  • どういった活動が必要になるのか？を考える
• 定めた一連の仕事を誰でも理解して実行できるように図示する

ひとつのプロセスは複数の活動の連鎖によってできています。
連鎖ということは、それぞれの活動の間に「つなぎめ」が存在します。
プロセスを設計する際、そのつなぎめにも目を向ける必要があります。

良質なプロセスを作るのに必要な観点

活動と成果
業務における活動には必ず求められる成果があります。
プロセスを設計する際はまずはそのプロセスを通してどのような「成果」を求められているかを明確にする必要があります。

材料、道具、手順
業務を行う上で、必要な材料とそれらを加工するための道具は欠かせません。
また、道具の使い方や加工の手順も重要です。

そしてこれらの準備自体も、業務プロセスの一部として考慮する必要があります。
例）請求書確認という活動であれば、請求書が材料となるが、請求書の準備(作成)もまたひとつの活動になる。

実行条件
他からリクエストを受けた時、ある条件を満たした時など、活動の実行タイミングを定義しておく必要があります。

受け渡し
プロセスは活動の連鎖のため、成果物を後工程に引き継ぐ必要があります。
成果物をどう受け渡すかどうかも大事な観点のひとつです。
具体的には以下の方法があります。

• 直接
  • 口頭や手動での受け渡し
• 保管とピックアップ
  • 前工程の担当者が決められたところに成果物を保管し、後工程の担当者がそれをピックアップする
  • システムに保存しておき、後工程担当者が良きタイミングで閲覧する場合もこれにあたる

良質なプロセスを作るコツ

成果の定義をしっかりする

良質なプロセスとは、価値のある成果を導くことのできるプロセスです。
そのためには価値のある成果を定義する必要があります。
プロセス設計を始める前に、以下を確認しておきましょう。

• 活動を評価するのは誰か
• 活動はどういった基準で評価されるのか

いくら効率的で無駄のないプロセスであっても、価値の低い成果しか出せないのであれば良質なプロセスとは言えません。

事実をすべてプロセス図に書き起こす

活動の数が多いイケていないプロセスは、プロセス図全体が長くなります。
書き起こしているときはその作業自体がしんどくなり、省略したい衝動に駆られることもあるかもしれませんが、なんとかすべて書き出しましょう。
そうすると「既存プロセスがイケていない」ということを視覚的に気付くことができるし、関係者にも伝えやすくなります。
当事者は当たり前にやっているプロセスも、図式化することでプロセスの長さに気付けるかもしれません。

まずは基本形を整理する

例外処理や場合分けなど、詳細な部分に目を向けたくなるかもしれませんが、一度深掘りし始めると収拾がつかなくなる可能性があります。
まずは基本形を整理することに集中し、詳細な部分は別の作業として切り出すようにしましょう。

プロセスの開始地点から順に整理すると、細かい部分に気を取られてしまい、本来の目的から脱線しがちです。
そのため、まずはゴールを明確にし、そこから逆算して必要なステップを整理していく方が効率的です。

活動と活動の間の「滞留」を見逃さない

プロセスが短いからといって、プロセスにかかる時間が短いとも限りません。
活動と活動の間で滞留が発生している場合、プロセスにかかる時間が伸びてしまいます。
プロセスを整理する際は、その活動が即時で対応されるか、待ちが発生するのかという点も併せて確認する必要があります。
待ち時間が長くなってしまう場合は、担当者の持っている業務の数や優先度を整理する必要があるかもしれません。

プロセス設計に積極的に参加してもらうには

ヒアリング内容の重点ポイントを変える

担当者がプロセス設計に消極的な場合、モヤモヤポイント、工夫ポイントに注力してヒアリングしてみましょう。

プロセス設計のメリットを伝える

プロセスの図式化でメリットを得られるのはエンジニアだけではありません。
ユーザー自身にも以下のようなメリットがあるため、設計着手時にしっかり伝えましょう。

• お互いの仕事の内容を知るきっかけになる
• 全体の関係性における自分の仕事の役割を確認できる
• 当たり前だと思っていたことが実は意外な強みであることを発見できる可能性がある

ユーザーシナリオとは

活動においてITを利用する場合の手順を指します。
プロセスを整理したら、各活動でどうITを利用するかを考えます。

ユーザーシナリオの進め方

ユーザーのアクションの整理する

ユーザーがコンピューター上で行えるアクションの基本は以下です。

• 表示されたものを見る
• 表示された選択肢の中から選ぶ
• 値を入力する
• 実行を支持する

各活動で、どのアクションをするのかを明確にしましょう。

システムで行うことを整理する

ユーザーのアクションを受けてシステムが実行することの基本は以下です。

• ユーザーからのリクエストを受ける
• ユーザーへのレスポンスを返す
• 何らかの処理をする
• アウトプットを出す(画面、プリンタなど)
• データを保存する
• データを取得する
• 他のシステムと連携する
  • 送信、受信
• バリデーションを行う

上記のユーザーのアクションとシステムの行うことを並べていき、ユーザーシナリオを作成していきます。

個人的に印象に残った箇所

普通の処理はさほどイライラしたりすることもないので、ヒアリングのときには取り立てて言うこともないとして脇に追いやられてしまい、心の大半を占めている気疲れ・イライラモヤモヤを優先的に語っているのです。
（羽生 章洋『はじめよう！ プロセス設計 ～要件定義のその前に』、技術評論社、2016年、689ページ）

ユーザーに既存プロセスを確認する際は、聞き方によってはモヤモヤにフォーカスが当たりすぎて抜け漏れが発生する可能性があるなと思った。

「否定表現ではなく肯定表現を使う」ことと「語尾を曖昧にせず、きちんと言い切る・断言する」ということについても、ぜひとも常にしっかりと意識していただきたい
（羽生 章洋『はじめよう！ プロセス設計 ～要件定義のその前に』、技術評論社、2016年、860ページ）

設計書を書く際は意識します。

せっかくデジタル化したものを印刷して渡したり、添付ファイルなどで複製を蔓延させたり、人間がわざわざ別の画面に転記入力するのは、作業のPC化であってもIT化とは言えないのです。
（羽生 章洋『はじめよう！ プロセス設計 ～要件定義のその前に』、技術評論社、2016年、1402ページ）

私の担当システムでも一部こういった使われ方をされているな〜と思いました。

感想

次はシリーズ本３冊目を読む。

参考

• 羽生 章洋『はじめよう！ プロセス設計 ～要件定義のその前に』技術評論社、2016年