やはり場数が必要 ～SaPID Vo.6の参加レポート～
日本シリーズが終わり、若干燃え尽き症候群になっているJimmyです。
今回はSaPID club Vol.6に参加してきたのでその報告をしたいと思います。
SaPID culbとは
以下にイベント説明文を載せておきますが、SaPIDを実際に使ってみよう!!というイベントです。
システム思考とデザイン思考のハイブリッド型アプローチである「SaPID」の解説や体験・実践、関連情報の共有を行う場です。
業種に寄らず問題発見解決、プロセス改善、価値創出（デザイン～実装）、チーム変革などを系統的に進めるアプローチで、説明を聞けば誰でも理解できるものですが、一方で使いこなすには継続的な実践や訓練が必要です。 この場をきっかけに、少しでもシステム思考やデザイン思考を使いこなせる方、マンネリやモグラたたき状態から脱却できる方、そうなろうと思い行動する方が増えることを期待して当グループを作りました。
SaPIDとは
Systems approach based Process Improvement methodの略で、ソフトウェア関連業務に携わる当事者自らが解決すべき問題点を特定し、現実的に解決しながら段階的にゴールを目指す手法です。
以下の図のようなステップを踏みながら、改善活動を行っていきます。
この方法はいろいろな場で発表されているので、詳細はそちらを見ていただいた方が良いと思います。(参考資料に載せておきました。)
参加理由
前回実践してみて、「わかる」と「出来る」は全然違うと改めて理解しました。
また、続けて参加した方がもっと定着するのではないかと思ったため、今回もワーク実施者として参加しました。
実施内容①SaPIDに関する質疑応答
まずはSaPIDに関する質疑応答があったので、私は以下の質問をしました。
ワーク実施しているとSTEP3の問題構造化で要素が急激に増える現象が発生してしまいます。要素が爆発しないような工夫はしていますか。
安達さんは以下のように回答しました。
みなさんのワークを見ると、STEP2の時に、必要以上に掘り下げているように見えます。「なぜなぜ分析」に近い感じになっています。
SaPIDはなぜなぜ分析を目指していないので、STEP2では事実だけを聞き出せばよいです。そこからの理由は聞かないようにしています。
これを聞いて、なるほど。確かに。。と思いました。
STEP2はSTEP1で洗い出した問題が本当に起きているか事実を確認する作業であったり、複数問題があるものに対して切り分けたりする段階であるため、原因を分析するフェーズではないです。
書籍を読むと理解できるのですが、実際やるとついつい深追いしたくなります。。
この部分は意識して、取り組んでいこうと思いました。
実施内容②STEP2(事実確認・要素精査)～STEP3(問題分析・構造化)
今回は前回の続きではなく、何と安達さん主導でSTEP2(事実確認)～STEP3(問題分析・構造化)を実施しました。(いわゆるモブSaPIDというやつですね。)
何と豪華な。。
今までワーク実施者が行ったSTEP2の題材から改めて、事実確認・要素精査と問題分析・構造化を行いました。
実際に安達さんのワークをみて、この部分が必要だなと感じた部分を紹介したいと思います。
事実確認・要素精査の精度
ワークの様子を見ると、STEP2(事実確認・要素精査)の重要性が改めて分かりました。
実際、前回のイベント時にもSaPIDがうまくいかない要因としてSTEP2でしっかり精査されてないことが挙げられていました。
以前にワーク実施者が行った成果物を見ると以下の要素がありました。
記載している中に問題要素が2つになっている
問題が抽象的である
事実確認が十分に行われていない
これらは問題としてはよろしくないため、以下の対応をすべきです。
問題要素を1つに分解する(一文一義)
より具体化する(いつ、どこで、何が、どのように、どの程度など)
要素精査を行う(エビデンスを取ってくる)
また、安達さんは聞き出した情報をすべて記載せずに問題になっている部分だけを抜き出していました。
これは盲点でした。。
私の場合は、そのまま要素として残していました。
確かに、STEP3(問題分析・構造化)につなげるには不要な部分は除くべきだなとこのワークを見て感じました。
PRJマネジメント/テストマネジメントの知識
STEP3(問題分析・構造化)を行うときに、「○○でこういうことがありそうだよね」というところが多くみられました。
こういうところを見るとやはりテストマネジメント経験で出ているなと感じました。(私はない。。)
グループ名の適切さ
これが個人的に一番自分には足りないところだなと思った部分です。
STEP3の問題構造化にて、同じ要素があればまとめてグループ名を付けることができるのですがその名前が的確だなと感じました。
自分がワーク実施すると、命名したグループ名に引っ張られ、最終的に要素の置き場所に困るときが多かったです。
これを見て、改めて全体を要約でき、命名する力が必要だなと感じました。
この力はソフトウェアテストにも活きてくると思います。(テスト観点のまとめ、テストアーキテクチャ等)
実施内容③イベント後の談話
イベント後の談話があるのですが、これもこのSaPID clubのメインと言っても過言ではないですね（笑）
いろいろ参考になるお話が聞けたのですが、今回はSaPIDに関連する部分を紹介します。
SaPIDとふりかえりの違い
問題点を洗い出して、改善案と立てる活動の一つに「ふりかえり」もありますが、SaPIDの違いを教えていただきました。
ふりかえり
個別改善によく使われる(個々の問題の改善策を考える)
SaPID
いっぱいある問題の中から、ゴールに一番近づくものを選ぶときに使われる
チームの思考を可視化する一つ
チームでパフォーマンスを上げたいときに向いていると思う
ただ、個別改善でもSaPIDを使うことは出来るので、目的を明確にすることが大事とおっしゃっていました。
他にもためになる話はありました。聞きたい方はぜひ。SaPID culbへ（笑）
イベント参加後、やること
このイベントを通して、以下のことをしたいなと思いました。
自分のペースでいいからSaPIDの本を読み進めたい。
特にSTEP2の部分を読んで、アウトプットしたいなと思いました。
談話で聞いたふりかえり方法を真似してみる。
この方法を知りたい方は、安達さんに聞いてください（笑）
具体と抽象の本を久しぶりに読んでみる
要約する力の手助けになるかと思い、久しぶりに読んでみたいと思います。
SaPIDのイベント
12月はSaPIDのイベントが盛りだくさんです。
ぜひ、興味がある方は参加してみてください。
おわりに
今回は安達さん自らワークを実施するという個人的には豪華なイベントでした。
次は何するかは決まっていないですが、この記事を見てやってみていなという方がいれば、SaPID clubに参加していただければと思います。
SaPID clubはたぶん12/22(水)です。。
では、今日はこの辺で。
P.S. noteの新エディタ機能はとても使いやすかったです。