[#TiDD] パタンランゲージで経験を活かしたプロセスを構築する

プロセスが好きだと言うと若い人は怪訝そうに見られる。品質保証の人からは「SEPG(標準プロセスを制定するグループ)とかですか？」と聞かれる。アジャイルな人達は「プロセスやツールよりも個人と対話を」と言われる。

そんなことは無いはずです。一般に「プロセスはタスクの集合」と定義されるからです。つまり、ソフトウェア開発をしている人は皆、プロセスを実行しているからです。

モデリングの失敗

このようにプロセスが他人事の様に語られるのは、プロセスのモデリングに失敗しているからです。「ソフトウェアプロセスもソフトウェアである」と言われていますが、これまでのプロセスのモデルはプロセス特徴を表現できなかったからです。

そもそもプロセスモデリングは、プロセスの知識を伝達、理解、改善、管理、 支援、自動化するものです（参考：[#TiDD]失敗しないチケット駆動開発 - プロセスモデリングの視点から+告知 -）。しかし、ウォーターフォール(WF)の標準プロセスやスクラムは、メタなプロセスと汎用的なプラクティスを示したもので、過去の具体的な経験を伝え、そのノウハウをソフトウェア開発として活かす仕組みは、肥大化し易い標準プロセスによる管理や開発チームの習熟に依存しています。

例えばユーザデモ

たとえば「段取り８分」といわれるように段取りは重要ですが、例えばユーザデモをどのように調整するかといった基本的な事もうまく支援できません。

【標準プロセス】
仮に標準プロセスに実施方法を書いたなら、「うちはこのやり方です」と顧客に言ったり、何らかの事情でテーラリングしたくても制約を受けてしまう事があるでしょう。
逆に詳しく定義しなかった場合は、それぞれのプロジェクトでWBSなり線表に落としますが、どのような条件があってその計画にしたかがわかりません。このため、前回は顧客が用意してくれたので、デモ用のデータや会場の準備を忘れるかもしれません。
経験の少ないマネージャーなら、マイルストーンの設定だけで必要なタスクが漏れているかも知れません。

【スクラム】
スクラムではタスクの依存関係や期限をうまく管理しないいけませんが、タイムボックスからあふれて間に合わないなんてことが起きるかも知れません。
ベテラン揃いなら色々な工夫や調整を行うのでしょうが、それはプロセスで支援されるのではなく、開発に関わる人達の習熟に任されています。勉強会やコーチが必要な訳です。

どんなモデルなら支援できるか

これらのプロセスモデルをソフトウェアの概念に当てはめてみると、クラスや機能であって、段取りに必要な関連や状態概念が不足している様です。

【クラス指向】
WFの標準プロセスは抽象クラスの責務でモデル化されています。WBSに代表される様に細かな構造に分解してプロセスを定義します。インスタンスに相当する内容は自由だが責務だけは果たす様に求められています。CMMを提唱したハンフリー氏らはプロセスのスキップが最も大きな問題と考えていて、抜け漏れチェックが重視されています。ただし、このモデルに基づいてもインスタンス化する際に考慮が必要な内容は直接は支援されず、組織内で定義し、訓練によって実現しないといけません。

【機能指向】
スクラムのロールモデルは機能で分割され、ロール間やロール相互のコミュニケーションに必要なアーキテクチャ、具体的には外部との連絡、コンセンサスの共有、などの仕組みを持ちます。実現する順序はバックログで管理されますが、バックログの調整はオブジェクトである人に依存しています

このように プロマネ、リーダ、プロダクトオーナは苦労しています。それは具体的なプロセスで考えないといけない段取り、つまり状態があまり支援されていないからです。

【状態指向】
実際にプロジェクトを実施する際には、具体的な開発対象の状態が考慮されます。具体的には、いつまでに何を作るかを考えてそれに至る道筋を考えています。これがいわゆる段取りです。上記２つのモデルでは具体的な開発対象を直接扱いませんので支援が行えないのです。そこで開発対象の状態を考慮したプロセスが必要になります。

パタンランゲージ

そこでパタンランゲージです。開発の計画を立てる際は、ゴールや制約に合わせて、過去の経験した作業を当てはめ、必要に応じて作業を組み立て直します。まさにマネージャがしてる事です。

パタンランゲージを利用する際は、この工程をパタンランゲージとプロジェクトランゲージ2段階で行います。関係者からのインタビューで良いと思ったものをパタンランゲージとして整理し、制約を考慮して組み合わせてプロジェクトを段階的に構成していきます。

パタンランゲージはどのような問題（フォース）をどのように解決するかを集めた、いわゆるパターンの集合です。誤解を恐れずに言うと、そのドメインに特化したDDDのユビキタス言語に相当するものだと思います。

プロジェクトランゲージでは パタンランゲージを構造化・洗練したものを表の縦軸に、プロジェクト横軸に取った表を作成します。実施する交点につける印が多くなる様に、制約を考慮してプロジェクトの実施順序を決めます。ちょうどユーザーストーリーマッピングを左に回転させたようなイメージです。

（参考：本橋、中埜、羽生田、懸田、江渡、パタンランゲージからプロジェクトランゲージへ共創のプロセス(PDF)，AsianPLoP 2011）

パタンランゲージで経験を活かしたプロセスを構築する

ここで先ほどのユーザデモを考えてみましょう。ユーザデモはパタンの一つですので、パタンランゲージに加えられるでしょう。

それだったら従来のプロセスでユーザデモを追加したのとあまり変わらないのではないかと思われるでしょう。実はこの時点で他のパタンと同列に並んでいる所が後で効いてきます。

プロジェクトランゲージを作成する際はセンターと呼ぶ概念や対象物を明確にします。ユーザデモがより重視されるならレビュー作業を中心的なものにするかも知れませんし、逆にユーザデモをキーマンに対してだけ実施するかも知れません。

従来だとユーザデモのような作業は足し算でしかなく、標準プロセスや元のフレームワークを変更する事はできません。パタンランゲージは関係者で協議して方向性を決める（センタリング）しますので、バランスの良いプロセスを再構築できるのです。

どこから始めるか

パタンランゲージのやり方は、小規模プロジェクトでよくやっている事です。示された制約と使えそうな経験を思い浮かべ、依存関係のあるまとまりでその実施順序を決めていきます。

ソフトウェア開発の規模が小さくなると実施できる事が限られます。関係者で議論する事でバランスの良いプロセスを構築して、顧客の要望に応えていたのです。

経験を集めてパタンランゲージを構築する方法は、チケット駆動開発で作成した過去の履歴を分類して活用できると考えています。

まずはチケットにどのような経験が蓄積されているかを調べ、その結果を次回のSEA関西＆RxTstudyの勉強会で紹介するつもりです。

まとめ

具体的な計画をする際に現れる制約をモデル化せずにクラスを作ったり、枠組みを作っても上手くいきません。その状態で頑張れば頑張るほど、大事な事が個人に閉じてしまいます。

今回紹介したパタンランゲージのアイデアは、過去の経験を元にプロセスを構築する方法です。チケットをうまく利用する事で、プロジェクトに適したプロセスを構築できると思います。

【告知】
すでに募集している次回のRxTstudyの講演内容を変更し、上記のような考え方とチケットの関係を説明するつもりです。ぜひ、ご参加ください。

第65回 SEA関西プロセス分科会＆RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」 (07月30日) https://rxtstudy.doorkeeper.jp/events/44608