パタン的転回を用いた ゆる思考の適用を、主にソフトウェア開発やプロダクト管理の手法やプラクティスについて、もう少し具体的な例で概要を示したい。
◇ ◇ ◇
状況
ソフトウェア開発やその周辺では、様々な方法論がある。たとえば、能力成熟度モデル統合や、PMBOKなどの体系、DDDからUML、ウォーターフォール型開発から、アジャイル型開発まで、先人たちの知見は素晴らしい。
どのぐらい昔だったのか覚えていないのだけれど、どこに行ってもCMMIのレベルをあげる、なんて耳にしている時代があったような気がする*1。ITサービスマネジメントにおけるベストプラクティス（成功事例）はITILもある。監査の人たちとは、CoBITをベースによく会話した。最近、よく耳にするのはアジャイル型開発もScrumやXP、クリスタルクリア、リーン…様々あり、読むとなるほど参考になるなぁ、と思うことが多い。私自身は、ワインバーグのエゴレスプログラミングを拡張した、エゴレス開発が成功体験としてある。
その中で、異なったフレームワークや方法論によって論争が起こることが多い。アジャイル型開発対ウォーターフォール型開発などの対立のエントリがブログやSNSで盛り上がった。しかし、私の経験からすると、ウォーターフォール型開発においても、実質的にはアジャイル的なプラクティスを実施することは多い。スクラムというアジャイル型開発を実施していても実質的にウォーターフォール型開発に近い状態で回す場合もある。ほとんどの案件が0.5人日から2人日程度であれば、ウォーターフォール型開発でもうまくいく。さらに、ソフトウェア開発の周りを見てみれば、それこそ個人、チーム、ビジネスなどの切り口はあるものの、置かれている状況は千差万別である。
ビジネスに関しても、様々な方法論やベストプラクティスがあふれている。生活もだ。「これをすればうまくいく！」みたいな本はあふれている。パタンのコミュニティも大量のパタンを生み出し、成功体験があふれかえっている。さらには、インターネットの発展で、それこそ無数にも思える情報があふれている。まさしく百花繚乱であり、何を選択するべきか、どのようにすべきかよくわからない。
論争は、それぞれのパラダイムの発展に寄与する部分もある。何を選択すべきかの参考になる場合もあろう。しかしながら、たまに終着点を感じないような状態になることが多い。そして、不毛にも思える議論は、健全な成長や営みを阻害するような状況も発生しているようさえにも感じる。
問題
どのような標準や方法論に準拠すればよいのだろうか。「あるべき姿」はどんな姿なんだろうか。
ビジネスを目的にするのであれば、ベストプラクティスを選べば、フォロワーの戦略を取ることになる。はずれはないものの、他のビジネスとの差異を作り出すことが困難になる。
プラクティスは、その文脈の中でのみ評価される。文脈を読まずに著名なベストプラクティスや方法論に実施することは、ネガティブな結果を生み出してしまうことさえ、ある。たとえば、アジャイル型開発のスクラムでの例を挙げよう。朝会をやるべき、というモデルに従って朝会をしたところ、リッチな会話がなくなってしまった。ソフトウェア開発者と、製品企画担当者が分化していなかったので、プロダクトオーナー役を決めたところ、状況の分離が進み、コミュニケーションがギスギスしてしまった。コールセンター的な役割をする業務で、電話があるごとに対応する必要があった場合、計画作りをしたところで、意味をなさない。など、文脈の中でのみ、プラクティスは評価されるのである。
それゆえ：（解決策（案））
まずは現場を見て、現場の状況に合わせた解決策を探し出そう。パタン（の種）を作り出すときは、過去の知見やノウハウを参照することによって、より豊かで納得性の高い方法を実施しよう。
先のメタな方法論として、パタンもしくはパタンランゲージを用いると、方法論が持つ目的や関心と、その現場などの状況が持つ問題の目的や関心をすりあわせることができる。例えば、パタンのプロセス自身にもこの考え方を適用できる。未来を織りなすパタンの文脈の中で、問題解決を探る方法として制約条件の理論のクラウドを用いることができる。たとえば、情報のオープン戦略：攻殻機動隊 Stand Alone Complexに対する解決策案 - ari’s viewは、パタンにクラウドを埋め込み、クラウドで見つかった解決策（インジェクション）をパタンの解決策案として採用することもできる。パタンランゲージと制約条件の理論のマッピングができているので、そのほかの応用も利くし、不足しているところも補完できる。たとえば、クラウドを見ただけでは、状況やストーリが見えづらい。そこで、パタンとして表記することによって、第三者に伝えるというメリットを見いだした*2。
この方法論でこうすべきだ！このプラクティスではこのようになるべきだ！的で原理主義的になりやすい硬直した状況をゆるめることができる。実際、別の記事で紹介したが、アジャイルとウォーターフォールの組み合わせや、CCPMの組み合わせなど、複数の事例がある。それもいいけれど、これもいい、では、文脈やリソースにあわせて、次の一歩はこのようにしよう、という、方法にとらわれずにデザインを行おう。
その結果、ビジネスやソフトウェア開発で発生している問題やジレンマを当事者として解決する。「おしきせ」でも「命令・指示された方法」をそのまま実行するのではない。それも制約とした道筋を感じながら、自分たちの物語を紡ぎたい。そのときの結論についても、指示や命令した人と話し合うことができれば、なお良い。このようにパタン的転回によって、関心や目的が相対化され、非常に幅広い視点を持ち、その中で現実的な方法が選択できる*3。
◇ ◇ ◇
この概要が示した通り、ソフトウェア開発やその周辺においても、健全な営みができることを祈っている。
