いざやるとやっぱり大変だった。〜SaPID club vol.5 参加レポート〜
こんにちは。
時間を確保次第、イベントに参加しているJimmyです。
今回は、SaPID club vol.5の参加報告をしていきたいと思います。
SaPID clubとは
以下にイベントの説明文を載せておきます。
システム思考とデザイン思考のハイブリッド型アプローチである「SaPID」の解説や体験・実践、関連情報の共有を行う場です。
業種に寄らず問題発見解決、プロセス改善、価値創出（デザイン～実装）、チーム変革などを系統的に進めるアプローチで、説明を聞けば誰でも理解できるものですが、一方で使いこなすには継続的な実践や訓練が必要です。 この場をきっかけに、少しでもシステム思考やデザイン思考を使いこなせる方、マンネリやモグラたたき状態から脱却できる方、そうなろうと思い行動する方が増えることを期待して当グループを作りました。
まとめると、SaPIDを実際に使ってみよう!!というイベントです。
SaPIDとは
Systems approach based Process Improvement methodの略で、ソフトウェア関連業務に携わる当事者自らが解決すべき問題点を特定し、現実的に解決しながら段階的にゴールを目指す手法です。
＜出典＞ソフトウェアプロセス改善手法SaPID入門 現場力を引き出すシステムズアプローチ
全体像としては以下の図が適切かなと思います。
＜画像元＞https://www.softwarequasol.com/sapid/
これらのステップを踏みながら、改善活動を行っていきます。
この方法はいろいろな場で発表されているので、詳細はそちらを見ていただいた方が良いと思います。(参考資料に載せておきました。)
参加理由
前回ワークの見学者として参加したときに、SaPIDの使い方というよりも、問題解決のヒントが得られるかもと感じました。
そして、ワークを実践し、難しさを体感する方が身に付きやすいかもと思い、今回初めてワーク実施者として参加しました。
今回実施した内容
今回は実施したものとしては、SaPIDのSTEP3の続きで問題構造化を進めました。
前回までは以下の資料確認のこと
問題構造化をざっくり説明すると、STEP2までに出た情報を基に、因果関係でつなぎながら、関係者に背景、プロセスや現状を確認し、構造図にするものです。
＜画像元＞SaPID概説スライド_vol04終了時分.pdf https://www.softwarequasol.com/sapid/sapid-club/
前回までは特定のタイミングで発生するものの構造化をしたので、今回は常時発生しうる問題の構造化を行いました。
やってみての感想
全体を通して思ったことは、
やっぱむずかしい。。。
特に今回作った構造化を既存の構造化に当てはめるところが難しかったです。。
新しい構造化を組み込むと既存の構造化でおかしい部分とかが判明したりと、なかなか変更しにくい状態だったため、作り変えるのに時間がかかりました。
また、SaPIDの問題構造化では似たような情報をグループ化する方法があるのですが、そのグループ名に引っ張られて進まない時がありました。(安達さんのフォローで何とか理解、ファシリテートうまいなぁと感じました。)
結局この日には、問題構造図が完成しませんでした。。次回こそは、完成してほしいですね。
何を学んだ？知った？
今回、自分にとって学びになったことを記録していきます。
■問題構造化にする前の、STEP2(事実確認・要素精査)が不十分だと、構造化できない
今回ワークを実施していく中で、取り扱う問題・現状の中には以下の部分で不十分なところがありました。
・主語がわからない
・具体的な指標がない
・複数の問題・現状が含まれている
このようなものがあると、構造化を進めることが困難になります。(因果関係が説明できない、その問題・現状が孤立する等)
また、安達さん自身もイベント後の西さんとの対話で「STEP2ができていないからSTEP3で詰まる」とおっしゃっていました。
これはSaPIDだけでなく、改善活動を行う上で大事な考え方なのかなと思いました。現状起きている問題を取り違えて改善活動をしてしまうというのはよくあることかもしれないですね。
STEP2(事実確認・要素精査)のワーク実施様子は以下の動画から見れます。
https://www.softwarequasol.com/sapid/sapid-club/
■問題構造図は正確かつ、詳細に表すというより、関係者全員が理解できる図を作成すること
ワーク実施中、問題構造化を進めていく中で、とても詳細な部分が気になっていました。
その時に、安達さんは「問題構造図はあくまでもモデルなので、メインが抑えられていれば良い。関係者全員が構造図を見て、理解でき、現状を表現できていると判断できればよいので、ある程度省略しても良い。」という旨をおっしゃっていました。
統計学や機械学習の世界では以下のGeorge E. P. Box格言がありますね。
"All models are wrong; but some are useful"（全てのモデルは間違っている、だが中には役立つものもある）
つまり、テンプレートにとらわれず、関係者全員とコミュニケーションを取りながら問題分析をしていくことで本当に解決したい問題が見えてくるという風にとらえました。(間違えていたら、すみません。)
個人的にはワーク実施中、構造化に対して違和感に感じた部分があるものの、質問ができなかったので、次回参加出来たら質問できるようにしたいなと思いました。
■5W3Hを常に考えながらすすめること
当たり前じゃないかと思う方が多いと思います。しかし、恥ずかしながらワーク実施中に意識できたかと言われると、出来なかったなという印象です。
「構造化でつながなきゃ」「完成しないと」という気持ちが先行して、本当の問題を見落としていたなと感じました。
【5W3H】
When(いつ)/Where(どこで)/Who(誰が)/Why(なぜ)/What(何を)/How(どのように)/How many(どのくらい/数量)/How much(いくら/費用)
最後に
今回参加してみて、分かるとできるは全然違うなと改めて感じました。
ただ、とても良い経験になりましたし、SaPID以外でも使える内容が多かったなと思いました。
※ワークはmiroを使うので、練習しておいた方が良いと思います。(私は苦戦しました笑)
次回は11/24を予定しているとのことで、日程があえば再挑戦したいと思いました。
ぜひ、今回の記事をみてやってみたいなと思った方がいらっしゃれば、ワーク実施者で参加することをお勧めします。(どうしても声が出せないとかであれば、見学者として参加するのも全然OKだと思います。)
また参加したら、noteで報告したいと思います。
では、今日はこの辺で。
参考資料
この記事が気に入ったらサポートをしてみませんか？