「はじめよう!プロセス設計 ~要件定義のその前に」を読んだ

UCWD-Studio.として個人で事業をしてた以前から「わざわざお金を出してまでシステムの開発を依頼する以上、開発されたシステムにはビジネスに直結する明確な目的があるはずなのに、どこかの工程でその目的がすっぽり抜ける案件が多い」ことにすごく疑問やモヤモヤする部分があって「はじめよう!プロセス設計 ~要件定義のその前に」を手に取ってみました。

この本より先に出版された前作「はじめよう! 要件定義 ~ビギナーからベテランまで」を以前読んでたのもきっかけです。

前作でもそうでしたが、本書においても新しく出現する用語や言葉が乱発して読み進めるほど難しく感じる……となりやすい部分を思い切った要約で平易で、分かりやすさを重視した言い回しが特長で、実際就寝前の1時間前後ほどの読書時間で3-4日ほどで読み終えられた、とても読みやすい本でした。

とても簡素な本書の要約

本書ではプロセスをある成果を出すためにやることと定義した上で、

  • プロセスとは意識しないだけで(日常に)当たり前に存在する
  • プロセスには実施するスキルと習慣化が必要となる
  • プロセスは目に見えないため、実働してるプロセスの良し悪しを測るのが難しい
    • ので、問題の本質であるはずの日常業務の悪習慣や無理や無駄が放置されやすい

旨に触れた上で、ストーリーとしてのビジネス・プロセス(及び更にその小粒度のサービスデザイン、ユーザシナリオ)設計の方法と、その中におけるITの役割を中心に話が進んでいきます。

仕事におけるプロセス設計についての話では、

  • 検討範囲を限定するためにスコープを確定すること
  • 確定したスコープの範囲でゴールを明確に設定すること

ことの重要性に触れられることが多いですが、本書においてもその点の重要性は強く語られています。当然といえば当然ですよね、ある成果を出すためにやることを設計するわけですから。もちろん、そうした観点からのゴール設定の重要性もあるのですが、本書では

  • (あまり想定を広げすぎると)収拾がつかなくなる
  • ある程度大雑把に満遍なく(スコープの範囲で)デザインしてからディテールを詰める方が均質なプロセスデザインデザインがしやすい

と、より実践的な理由も挙げられています。

本書を読み終えて

最初にわざわざお金を出してまでシステムの開発を依頼する以上、開発されたシステムにはビジネスに直結する明確な目的があるはずなのに、どこかの工程でその目的がすっぽり抜ける案件が多いと触れましたが、個人的な印象として目的が案件から抜ける工程は

  1. お客様が開発を依頼した段階で自分の役割が終わったと思ってしまう
  2. 開発工程に進んだ段階で案件窓口が「案件の目的」を伝えられずに開発に進み、必要と思われる機能だけが揃って目的は果たせないシステムに落とし込まれる

の大雑把にこの2点だと感じてます。そうした問題が起こるのは個々で色々な事情が絡み合って起こり得ることなのでここでは細かく踏み込みませんが、仕事の上でシステムの開発が必要と判断され、開発を依頼されたということは仕事の上で解決しなければならない課題や達成すべき目標が本来存在するはずです。

プロセスがある成果を出すためにやることである以上、プロセスの設計とそのプロセスに沿ったシステムの開発がとても大切ということを改めて感じます。

また本書の「まとめ」は筆者の結構熱い想いがにじみ出てて、とても印象に残りました。

プロセス設計は決してシステム開発の場面だけで必要な作業でもありませんし、システムを開発する側だけが知っているべきスキルでもありません。なぜなら、ある成果を出すためにやることだからです。

そういう点では「業務を改善していかないと……」と漠然と感じている、もしかすると近い将来システム開発を依頼する側に立つかもしれない、仕事に従事するみなさんにもお勧めできる一冊です。