AIにちまちまとタスクを任せるのではなく、もっと大胆に仕事を委任したい。そのために越えないといけない障壁の一つ、「仕事が塊のまま人の頭の中にあって切り出せないこと」をどうするかということを、最近よく考えている。
仕事が塊のままで細部の具体が見えていなければ、それを切り出して委任することは当然できない。切り出せなければ思い切って塊のまま全部渡すか、あるいは全く任せないかの二択になってしまう。 仮にエイヤと塊のまま任せると、結果の検証も塊のまま行うことになる。それでは全体に対して「ふーん」となんとなくの検証をすることになる。
塊のまま任せたくないが、かといって事前に仕事を分解することは難しい。結果、少し会話しては少し先を計画し、少し任せるという一問一答の進め方になることがよくある。ただその進め方ではつきっきりになった人間側で律速してしまい、AIの恩恵を活かしきれない。
塊をどう分解するかに真正面から向き合おうと考えたとき、ふと思い出したのがProcess Flow Diagramというプロセス設計手法だ。
Process Flow Diagram
PFDは、故 清水吉男氏が提唱したプロセス設計の記法だ。もとは構造化分析のDFD（Data Flow Diagram）で、清水氏はこれをソフトウェア開発の作業表現に転用し、DFDにはない「文書（成果物）」の記号を導入した。プロセスの間に必ず成果物を挟む形にすると、慣れていない人が書いても読み手がイメージしやすくなったのだという。記法自体はDFDとほぼ同じで、違いは成果物を第一級の要素として扱う点にある。
図の要素は4つしかない。
- 成果物：帳票のような記号で表す。何冊もある設計書のような複数の成果物は「複票」の記号でまとめる
- プロセス：丸で表す。下位のPFDに展開されるプロセスは二重丸にする
- フロー：成果物とプロセスをつなぐ矢印。既存の成果物を更新するプロセスには両矢印を使う
- トリガー：成果物を介さずにプロセスを起動する線。極力使わない
成果物で分解する
PFDの肝は、一連のフローをタスクではなく成果物で分解させる点にある。
このうれしさのひとつは、分解の難易度を下げる点にある。 塊を前にして、「どういう手順で進めるか」で分解していくのは、対象となる領域に一定の理解がないと難しい。 一方で「最後に何が存在していればいいか」から逆算し、「それを作るには手元に何が必要か」と問いを派生させていくことは比較的容易だ。終点から逆順に成果物を並べていくと、プロセスは成果物と成果物の間に自動的に切り出されていくからだ。
PFDが成果物中心であることには、もう一つのうれしさがある。 成果物で分解すると、検証対象は当然「成果物」になる。PFDの流儀に従えば、その成果物が満たすべきものを事前に定義することが求められる。これはそのまま受け入れ基準だ。
これをAI駆動開発に応用すると、AIに渡す指示（プロセス定義）とAIの出力を検収する基準（成果物定義）をそれぞれに定義する形に自然となる。 「何をどうやるか」と「何ができていればよいか」を分けて書けるのは、委任において決定的に重要だと思う。前者はAIに任せて構わないが、後者は人間が握っていたいからだ。
Process Flow DiagramはAI時代にこそ再評価されるべきだと思う
PFDが提唱された2000年代で、清水氏が想定していたのは人間のチームが行う開発プロジェクトだった。それがなぜ今、AIへの委任という文脈で効いてくるのか。
清水氏がPFDを書かせた動機の一つは、プロセスの設計を「実際に作業をする人」自身に取り戻すことにあった。組織標準を上から与えられて従うのではなく、今回の要求に合わせて自分で合理的なプロセスを設計し直す。要求は毎回変わるのだから、固定されたプロセスでは対応できない、という主張だ。
この「要求に合わせて合理的なプロセスを設計」する力が、これまでになく重要になっているのだと思う。実行はAIがやる。しかし何がどういう流れで、どういう品質でできていれば良しとするかは、人間が都度設計しなければならない。PFDはまさにその設計の記法になるのではないか。
もちろん、PFDをそのまま持ち込めばすべてが解決する話ではない。成果物が「存在する」ことと「品質が十分である」ことは別なので、定義には検証可能な基準を含める必要がある。成果物の定義を書くコストは軽くない。それをAIに任せればslopが生まれることもあるだろう。
そのような課題を踏まえても、このAI時代にプロセスの設計者としての役割があまねく求められるようになった今、その重要性は当時以上に高まったと思う。自分の仕事でも活用していきたい。Process Flow DiagramはAI時代にこそ再評価されるべきだと思う。
