これは 😺TECHSCORE Advent Calendar 2019😺 の6日目の記事です。

馬場です。システムやサービスの開発で、ぼんやりとした設計の悩みを抱えていて、武器を増やさなくてはいけないと感じている今日このごろ。大阪でパタンランゲージのセミナーAgile Tour Osaka 2019 × miniPLoPがあったので参加しました。

セミナーでは３つの講義を聴講しました。

ソフトウェアシステム設計におけるアレグザンダー理論の活用。数理的システム設計手法の提案。 -15の幾何学的特性とパタンランゲージ-

kyon_mm さんの講演です。

技術的負債に対してはリファクタリングやDDDなどさまざまな解決法が存在していますが、どれも問題の一部しか解消しないということを指摘していました。その上で、要求を実現する構造を既存の技術に依存しない形で設計する「数理的システムアーキテクチャ設計」を提案していました。

要求開発とシステムアーキテクチャ設計の間に抽象的・普遍な構造を設計するステップを1個いれる、という話でしたが、私が実践するにはすこし難しかったですね。この手法を実行するには、高レベルな汎化・言語化の能力が必要そう、と質疑応答にもでてきていました。
既存システムがある派生開発はどうすすめたらよいか、という質問に対する「全体のTo Beな数理的システムアーキテクチャを設計できれば、現状とのGAPを見つつどこをせめていくか（あるいは変更しないのか）議論ができるのではないか」という回答は示唆と希望がありました。あきらめてはだめですね。

詳しくはこちら

The Power of Patterns and Pattern Languages

Joseph Yoderさんによる パターンとパタンランゲージの初歩のお話です。
GoF のデザインパターンなどソフトウェア開発においてパターンは馴染み深いと思いますが、利用するだけでなく自分たちの経験からパターンをつくって共有しよう、という話しでした。

パターン作成は、1. 成功した経験のコンテキスト/問題/解決方法を記述し、2. それに名前をつけることから始める、と紹介していました。ワークショップ形式で実際にパターンの記述に挑戦してみたのですが、そもそも成功経験が全く思いつかずにびっくりしました。「このやり方はうまくいった」ということは意識的に拾っていかないと頭に残らずにわすれられてしまうのかも。もったいないです。

質疑応答ではドメインエキスパートの話もでていました。「エキスパートがパターンプラクティスの記述に長けているとは限らない。むしろ当たり前に実行しすぎてエキスパート自体は記述できないことはよくある。なので分析して書き下す人はエキスパートと別にいてもいい」とのことです。なかなか自分の経験を「これがよかった、うまくいった」と自分からは言いづらいですが、チームメンバのよい行動をみつけて記述することはできそうです。ポイントは「コンテキスト」を記述すること、名前をつけることだと思うので、次の振り返りのときには実施したいと感じました。

アジャイル品質パターンのワークショップ

早稲田大学の鷲崎弘宜先生のアジャイル品質パターンのワークショップです。
アジャイル開発における品質管理の24のパターンを紹介後、参加者で実践したことがあるパターン・実践したいパターンをあげ、議論しました。品質管理に限らず、アジャイルのパターンには必ず相手を理解したり、目線をあわせるためのアクションに明示的に名前が与えられているんですよね。特に「一般的にQAチームと開発チームは仲が悪いですが...」という常識の上で話が進められており、どの現場でもチームビルディングには苦労しているものの、開発では絶対に必要なステップだと認識して、意識して取り組んでいるのだと感じました。また、場所柄（？）参加者に組込系ソフトウェアに関する人が多く、クラウドの開発をする私たちと品質管理への向き合い方が全く違ったのが興味深かったです。

アジャイル品質パターンに関しては、鷲崎先生もおすすめのこちらのページをご覧ください。

感想

ボトムアップになりがちなシステム開発で、全体の整合性をいつどうやってとりもどしたらいいのか？「パターン」を紡いで「ランゲージ」にするところにヒントがあるのではないか、と思いセミナーに参加しました。ですが、率直にまだ私レベルには手には追えない領域でした。難しい！

ただ、パタンランゲージの手前の、成功体験をパターンとして言語化する、というのは、今日からでもやりたいプラクティスでした。失敗の場合は、事象、原因、対策を言語化することを内外から強いられますが、成功経験はあまりないですよね。成功を紐解く方が楽しいですし。まずはこつこつ始めていきます。運営のみなさんありがとうございました。