『怒らないからヤバいと思っていること全部言う会』はSaPIDでもっと有効的にできるかも

この記事で伝えたいこと

  • 『怒らないからヤバいと思っていること全部言う会』の内容はSaPIDでも言っている気がする。

  • SaPIDの紹介

  • SaPIDを用いて実践する、問題発見のコツ

『怒らないからヤバいと思っていること全部言う会』とSaPIDの繋がり

先日、以下の記事を読みました。

www.yutorism.jp

この記事の

むしろ、リスクを洗い出す場においては、『こんなヤバいことがあるぞ』『いや、もっとヤバいかもしれない』『そこがヤバいならたぶんここも・・・』と考えうる限りのアイデアをブレスト的に進めていったほうが良いんじゃないのかなあと思う。

という内容、まさに後述するSaPIDのSTEP1そのものな気がしました。

あと、この記事のコメント

『怒らないからヤバいと思っていること全部言う会』の有用性について - ゆとりずむ

「最悪の場合どうなるか」を先に考えとくといい。意外と「部長が社長にめちゃくちゃ謝る」ぐらいのことだったりする。

2018/02/20 10:15
b.hatena.ne.jp

という内容は、SaPIDのSTEP2にあたると思いました。

また、最近話題の『カイゼンジャーニー』のP25には、問題解決をナビゲートするための手順として、以下のように書かれています。

<手順>

①問題発見フェーズ

 ①-1 問題点を自由気ままに出し、全部意見へ仮置きする

②事実発見フェーズ

 ②-1 意見をもとに不利益を記載する

 ②-2 これらの深掘りのもと事実を記載する

③対策フェーズ

 ③-1 事実の問題が再発しない対策案を考え、ベスト案をマークする

 ③-2 これらの対策を誰が・いつ行うのかを記載する

しかし、これはコラムの1つに書かれているに過ぎず、具体的にどのように行えば良いか、どのようなところに陥りやすいのかは記載していません。*1

SaPIDでは似たような方法を行いつつ、対策までどうやって持っていくのかを考えています。

SaPIDとは

SaPIDの公式ページに以下のように書かれています。

SaPIDとは、”Systems analysis/Systems approach based Software Process Improvement methoD”の略語で、当事者自らが解決すべき問題点を特定し、現実的に解決(改善)しながら段階的・継続的にゴールを目指す手法です。

SaPID(SaPID2.0)の全体像は、以下のようになっています。

f:id:nihonbuson:20180225222356j:plain

https://www.software-quasol.com/sapid2-0/ より

冒頭で書いた『怒らないからヤバいと思っていること全部言う会』は、この中のSTEP1「問題洗い出し・引き出し」と似たようなことをしているように見えます。

真の問題発見のコツ

SaPIDでは問題だと思う点をSTEP1でどんどん付箋に書いていきます。*2

ヤバいと思っていることを言っていくと、例えば以下のような意見が出てくるはずです。

f:id:nihonbuson:20180226121830j:plain

これは問題なのでしょうか?

この「コードレビューが不足している」は、「不足」という単語を使うことで、問題点っぽく見せています。

また、「コードレビューをもっとしていけば良くなるだろう」という、解決策が思い浮かんでいる状態での意見に見えます。

SaPIDでは、このような意見を「不足型」「解決型」と呼んでおり、この意見はSTEP2で直していくことになります。*3

この段階では、解決策ではなく、問題となっているものを見つける必要があります。

そのために有効な質問(声かけ)の一つは、

「コードレビューが不足したことで、どんなことが起こったの?問題ないなら、むしろ効率的にレビューできてるじゃん。」

です。

そして、こういうことを言っても、実際に問題が起きているから「コードレビューが不足している」と言っているはずです。

例えば、

「実は、出荷後に重大な不具合が発覚して、コードレビューで防げる内容だったんだよね」

とか

「実は、読みづらいコードが大量にコピペして作られていて、その元となったコードは、コードレビューしてなかったんだよね」

とかいう回答が得られたら、これらも正に問題点です。

f:id:nihonbuson:20180226122813j:plain f:id:nihonbuson:20180226122826j:plain

そして、「重大な不具合」とか「読みづらいコード」の詳細を聞いてみましょう。

詳細な内容が例えば静的チェックで引っ掛けられる話であれば、「コードレビューに工数をかけること」ではなく、「自動の静的チェックを充実させよう」が解決策になっていくかもしれません。*4

ある案件に対して無数のプログラムの書き方があるように、ある問題点に対しては、複数の解決策があるはずです。

「コードレビュー不足」などの解決型の問題の出し方では、解決策を1つしか見れていないことに繋がります。もっと効果的な解決策があるかもしれないのに…。

f:id:nihonbuson:20180225232217p:plain

あくまでも私達がこの時点で見つけたいのは解決策ではなく、問題点です。

また、同時に

「コードレビューが不足になった経緯を教えて?」

と質問するのも良いかもしれません。

「実は、なかなかコードレビューに時間を取れなかった」

と答えるかもしれない一方、

「実は、コードレビューの経験が無くて、どこを指摘すれば良いか分からなかった」

という答えが出てくるかもしれないです。

このように、「コードレビューが不足している」に陥ったきっかけを聞いてみるのも良いと思います。*5

質問した時に、「実は○○で…」という回答を貰ったら大成功!それが本当の問題である可能性が高いです。

問題は時系列のある別の問題と繋がって発生していることがあります。

これをSaPIDではSTEP3「問題分析・構造化」で繋げる作業をしています。

これも、改善策を考えていく中で重要な作業になります。

何よりも問題の全体図が把握しやすくなり、会議の参加者に納得感が生まれます。

実際にSaPIDを書いてみた例

先日、私はSaPID+ Bootcampに行ってきました。

www.software-quasol.com

上述は、この中で得た内容を元に書いています。

ちなみに私の成果物の写真はこれです。内容の詳細は見えないようにしています。

f:id:nihonbuson:20180225234921j:plain

この写真の付箋1枚1枚が、私が出した問題点です。*6

そして、写真を見てもらうと分かる通り、問題点が矢印で結ばれています。

これが、問題点が繋がっている部分です。

f:id:nihonbuson:20180225235802j:plain

私が作成した成果物は、特徴が2つあります。

1つ目は、問題点がループしている、つまり悪循環になっているように見えること(赤矢印部分)

2つ目は、当初はまったく別タスクで、繋がりなんて存在しないと思っていた2つの事象が、実は問題で繋がっていたこと(青点線部分より上と下で別のタスク)

このように、SaPIDを用いることで、問題点を整理することができます。

問題点を整理することで、「まず取り組める改善策はなんだろう?」と考えることができます。

SaPIDを学びたい場合

私がここまで書いた内容は、SaPIDの中のごく一部でしかありません。

なので、興味を持った方は「こうやって使えば良いんだ」と思わず、SaPIDを勉強してみるのをオススメします。

書籍から学ぶ

以下の本を読むのが良いと思います。

体験型イベントに参加して実際に一通りやってみる

1泊2日で行うSaPID+ Bootcampが年1回開催されています。

www.software-quasol.com

体験型イベントに参加して雰囲気を知る

直近では3月7日に開催されるJaSST'18 Tokyo(ソフトウェアテストシンポジウム)で、SaPIDを用いたチュートリアルがあります。

リンク: JaSSTソフトウェアテストシンポジウム-JaSST'18 Tokyo-セッション概要

事前参加申込は終了しましたが、当日券の販売があります。

ネットから情報を取得する

SaPIDの公式ページも沢山の情報が載っていてオススメです。

www.software-quasol.com

さいごに

今回は、『怒らないからヤバいと思っていること全部言う会』をきっかけに、SaPIDの紹介と、問題発見のコツについて書きました。

この記事を読むことで、皆さんがSaPIDに興味を持ったり、業務での問題発見に役立つならば幸いです。

参考文献

  • SaPID公式ページ
    • 特に、SaPID_Blogの「[STEP1:問題洗い出し・引き出し]で「~不足」が出てきた場合の[STEP2:事実確認・要素精査]での対処例」はとても参考にしました。

*1:これは『カイゼンジャーニー』での本筋ではないので、詳しく書かれてなくても仕方がないことです。

*2:チームで行う場合、付箋に書くことで、誰の発言かを意識せずに済む効果もあります。

*3:このような意見が出ること自体はOKですし、変に萎縮して意見を出さなくなる恐れもあるため、STEP1ではどんどん付箋に書くべきです。ブレストの類いと同じです。

*4:ただし、ここで解決策まで考える必要はありません!ここではあくまでも問題点を洗い出しているだけです。

*5:実際は「コードレビューの時間が取れない」とか、「コードレビューで指摘する場所が分からない」とかは、やはり「不足型」「解決型」なので、もう少しツッコミをしたいところです。

*6:ちなみに、付箋を貼っているものはゴミ袋ではなく、移動可能かつ拡張可能なホワイトボードです。