ソフトウェアプロセス改善手法 SaPID 導入の壁と工夫

導入

こんにちは、QAエンジニアの星野です。

突然ですが、改善活動はお好きでしょうか。

自分の所属するQAグループ内でSaPIDという改善手法の実施を行いました。

ここでは、SaPIDの紹介と導入〜初回の壁、失敗と工夫についてをお伝えいたします。

SaPIDとは

SaPIDという名前は、Systems analysis / Systems approach based Process Improvement methoD から命名されています。

公式な説明を以下に引用します。

SaPIDは、当事者自らがシステム思考を活用して対象のメカニズムをシステムとして構造的に捉え、最も効果的で現実的な箇所、あるいは新しい価値創出に有効な施策・対策をうち、成果をあげていくための手法です。

特定の個人が実践することも可能ですが、チームや関係者、組織のメンバーが参画し、デザイン思考を併用して一緒に成長する、そして新しい価値を共創する方法を併せ持つのがSaPIDの特徴です。

引用 : https://www.softwarequasol.com/sapid/

基本的には公式の提示している説明をお読みいただけば、どんなコンセプトでどんな特徴があるのか把握できるかと思います。

とはいえ参照する方が全員ではないと思いますので、私の思うSaPIDがどういうものかを箇条書きにします。

SaPIDとは、

• 当事者自らが主体的となり、
• 各々の感じている課題や懸念、不安や不満を挙げながら、
• それらの背景や真の課題を明らかにして、
• 課題と課題の因果関係（原因と結果）を可視化し、
• 改善したい課題と、改善するための活動の検討、改善できているかの評価方法を、
• 納得感をもって検討・決定することができる手法

であるというのが私の理解です。

後述しますが、改善にあたって問題解決を急ぎすぎて何を解決すべきか吟味せずに対策を考えてしまうことも多いと思います。

SaPIDは合理的かつ改善に取り組むチーム全員が納得感をもって進められるようになっており、そこが魅力だと思っています。

コンセプトは上記の通りです。

具体的な中身としては、各々が挙げた課題や事実の関係性をこちらの図のように明らかにしてきます。

課題や事実の関係性が可視化できたら、具体的な改善のターゲットを特定し関係性をたどって根本から問題を解決していく手法です。

導入の壁と乗り越え方

SaPID経験者がいない

名前こそ知っているものの、チーム内にSaPIDの経験者はおらず具体的に何をするのかもわかっていない状況でした。

そこでとりあえず雰囲気だけでも体験しようと思い、SaPIDの勉強会を探して参加してきました。

（connpassで検索すると最近でもSaPIDに関する勉強会は開催されています。）

ちょうど勉強会の中身がゆるく軽量化されたSaPIDのワークだったため、

チーム内で定期開催されている勉強会で体験してきたワークをさらに軽量化し、短時間でSaPIDの雰囲気と自分が魅力を感じた要素に絞ってチームに広めました。

学習コスト

どんな手法にも言えますが、SaPIDを知るために学習コストがかかります。

SaPIDを学ぶためにはまずは書籍で全体像の把握をおすすめします。

細かな内容や実践しないとわからないようなTipsも多いため、あまり木を見ずに森を見るように読み進めることを推奨します。

さらにSaPIDを実際に体験をするために、勉強会を探すか年１回程度開催されている公式のSaPID Bootcampへの参加するとなおよいでしょう（参加者は書籍を割引で購入できます）。

参考 : SaPID Bootcamp

SaPIDは今もアップデートされているため書籍の情報はSaPID Bootcampや勉強会の内容よりも少し古くなっていますが、考え方やコンセプトは変わりません。

基本的には書籍を読んで全体像を理解し、SaPIDを実践するときは書籍を開きながら細かい進め方やTipsを参照すると良いと思います。

後々必要になったら参照しようと付箋を貼りながら読み進めたところ、このような状態になりました。

こう見ると、さほど多くないと思います。

書籍自体も難解な箇所はないため、サクッと読み進められるはずです。

また、疑問点や感じた細かいことはtwitterでつぶやけば有識者や公式から助言をもらえることも多いです。

失敗と工夫

時間がかかってしまう

チームの学習

SaPIDの導入にあたりファシリテートを務める人が書籍や勉強会で学習コストを払っているかと思います。

しかし、チームで行う場合、全員がSaPIDのことをある程度知らなければなりません。

全員に書籍を読んでもらい勉強会やSaPID Bootcampに申し込んでもらうわけにもいきません。

ファシリテートを務める人がキックオフを行ったり、各STEPのはじめに説明を行うなど手厚くサポートをしたほうが良いでしょう。

SaPIDでは参加者のことを尊重することが大事であると明言されています。

仮にやり方に誤りがあっても大きな問題ではありませんので、正しさよりも参加者の改善へのやる気や積極性を損なわないように進めてください。

SaPIDは一度で終わりではありませんので、困ったことがあればその次の実施時に改善するだけのことです。

実施の長期間化

どんなことにも言えますが、初めての実施には時間がかかります。

ひとつずつ手順を確認したり、課題や意見を挙げるにも「何を考えるか」を考える時間がかかってしまうでしょう。

他にもSaPIDのSTEP2にあたる情報の精査や、STEP3の構造化を行う際の合意形成や構造図の整理など、コツを掴めば早くなるのですが要領を得るまではどうしても時間がかかります。

書籍の中で挙げる課題の数の目安について経験上20個程度と言及されているのですが、いざ実施すると本当にそのくらいの数がちょうどよいです。

はじめのSTEPで課題が多く上がると後のSTEPすべてに影響が出てくるため、優先順位づけをして挙げる数を絞ってもらうなどの工夫をすると良いでしょう。

書籍の中にはこういったTipsが随所に書かれているため、もし特定のSTEPで困った場合は改めてその章を読み直してみるとヒントが得られるかもしれません。

参考：挙げた課題が多くなりすぎて複雑化してしまった問題構造図

ファシリテーター兼当事者

自分を含め、導入を推奨する立場の人は、ファシリテーター兼当事者になってしまう問題があります。

進行上は大きな問題ではなく、むしろ他の参加者は見様見真似で進められるためスムーズになるのですが、

ファシリテーターがファシリテートではなく、SaPID全体の流れをファシリテーターの考える方向に誘導してしまいがちになります。

初回であればSaPIDに慣れるためにそのような進め方でも悪くはないかと思いますが、

慣れてきたらあくまで参加者の意見を引き出したり、課題の深堀りや隠れた別の課題を洗い出すことに専念するよう意識する必要があります。

私自身、これがうまく出来ている自信はないですが、参加者を巻き込んだ一人舞台にならないように常に意識しています。

問題解決慣れ

エンジニアであるがゆえの問題として、普段から問題解決に慣れていることが挙げられます。

日々、様々な問題を解決しているからこそ、課題を挙げるSTEPでも解決策を考えてしまいがちです。

問題を洗い出すフェーズではあくまで問題を洗い出すにとどめ、問題を精査する際も深堀りは行いますが解決策まで考えてしまわないように留意しなければなりません。

我々はつい「こうすればよいのではないか」「こんな手法がある」「〇〇があれば解決する」と考えてしまいがちです。

ファシリテートを行う人が意識するのはもちろん、参加者にも都度伝えておいたほうがよいです。

おわりに

今回はSaPIDについてご紹介しました。

日々の業務に課題や不満、不安を感じることがあれば、SaPIDの導入を考えてみてはいかがでしょうか。

チーム全員で大々的に始めることが難しければ、賛同してくれる人だけで小さく回して少しずつ周囲を巻き込んでいくとよいでしょう。