こんな時だからこそ状況を把握する ~SaPIDでふりかえる~

みなさん,自粛生活,いかがお過ごしでしょうか?

私は転職してから3か月以上,ある案件のツールを開発しているわけですが,コロナ禍の影響により開発スケジュールが不透明になったり,在宅ワークになったりと様々なイベントが発生しています. 同じ部内でもコミュニケーションが疎になり,情報が錯そうしがちです.

解決方法は様々あると思いますが,まずは,自分の状況を把握しておくことが必要だと考えます. 自分の状況を把握しておくことができれば,こういったことができるようになると思います.

  1. 自分の考えのもと,自分の状況を正しく伝えることができる
  2. 自分の部署や外部の,突然の状況変化にも対応する準備ができる
  3. 自分の状況が明確であれば,外部の状況に関わらず,自ら改善を進める事ができる

そこで,転職後から行っている業務についてふりかえってみようと思います.

今回は,SaPID(Systems analysis/Systems approach based Process Improvement methoD)を使います. 「ソフトウェアプロセス改善手法SaPID入門」に書かれている作成順に従っていきます. www.amazon.co.jp

自分のやり方が若干含まれるかもしれません.*1 また,半日でやったこともあり足りない部分もありますので,その点はご了承していただけたらと思います.

STEP0 ビジネスゴール・成果状況/テーマ共有

SaPIDを使って,やりたいこと(=目的)を付箋に書きます. やりたいことを実現した結果,得られる期待も付箋に残すようにします.

f:id:kabe-aa:20200510201310j:plain
STEP0

まずは付箋に書き出す

「あんなこといいな,できたらいいな」

って頭の中で考えているよりは,まずは付箋に書きだします.

書き出した内容を明瞭にする

書き出してから,より具体的でふさわしい言葉に書き直していきます.

初めは,

開発をふりかえる

でしたが,もうちょっと何をしたいのか掘り下げました.

ツール開発案件を進めて,やったこと・起きたこと,をまとめる

して,「『まとめる』ってどうすることやねん?」って考えて,

転職後の開発案件で,起きた出来事をふりかえり,状況を把握する

にしました.

あまり突き詰めない

あまり突き詰めすぎて目的が達成できなくなりますので,,ある程度明瞭になったら,次に進みましょう.

進めていくうちにより具体的になったり,本当に知りたいことに気づくことなんて,よくある事ですので.

また,今回は個人ワークですので,自分が理解できること,あとで疑問にならない程度なら次に進んでも問題がないと思います. 後で人に説明するかもしれないため明瞭にする必要があると思いますが,適切な言語化についても後回しでよいと思います.

STEP1 問題点の洗い出し・引き出し

ここでは,出来事を出していきます. 基本的にはSTEP0の注意事項と同じですが,1つの付箋の明瞭性にこだわらず,書き出すことに集中します.

まずは,大きな出来事から時系列に書き出す

自分以外の人も共通で把握していること

左から右方向に,時系列に貼るようにします. この後,深掘りする出来事の数に合わせて,間隔を調整すると良いでしょう.

f:id:kabe-aa:20200510202648j:plain
STEP1-1

各時系列に対して,出来事を掘り下げる

自分に対して,こんな質問をしてみましょう 自分がやった出来事や感情,他人がやったこと,など思いつくことを出していきます. ※途中で,黄色い付箋がなくなったので,黄緑色の付箋と混在しています.

この時,どんなことが起きたの?

より具体的な出来事を出すために使います. 最初に出した出来事の近い出来事の下あたりに配置しておきます.

どうして,この出来事が起きたの?

その出来事が起こるキッカケを出します.

その結果,何が起きているの?

その結果によって,起きた事や,自分が思ったことを出していきます.

今,何が不安なのか?

現在の状況で,不安があれば出していきます. 重要度を上げて,赤い付箋にしました.

f:id:kabe-aa:20200510202805j:plain
STEP1-2

STEP2 事実確認・要素精査

書き出した付箋の事実確認を,SaPIDの原則や禁則に基づいて修正していきます. TOCfEだとCLRの明瞭性と存在の懸念に該当すると思います.

教本に書かれている原理・禁則に基づいて,見直したことは以下になります.

共通理解の原則

付箋を分けて記載することで,同じ言葉を省略しがちになります.

  • 異常系をすべて想定していない
  • 機能の見積もりが不足する
  • 見積もりしたら,リリーススケジュールを超えている

おそらく,因果関係を暗黙的に含んでいるためだと思いますが,後で見た時に分からないという状況を避けるため,きちんと書くようにしましょう

  • 各機能は,考えられる異常系を洗い出したものになっていない
  • 各機能の見積もりは,異常系を考慮していない
  • 異常系が考慮していない見積もりでも,製品リリースのスケジュールを超過する.

また,

  • 画面を設計しないといけない

も,書き出したときは分かっていても,後でふりかえると意味不明なので見直します.

  • ツールの使い勝手を良くするため,画面を開発する

具体化の原則

抽象的な表現を避け,どのような状態や結果なのかを具体的に把握できるように記載する.

と教本には書いてあります. 実際に,以下の点を気にするようにしていきました.

数量,質に関するもの
  • 本来,必要な機能よりも,機能が多くなる

多い,少ない,良い,悪い,など比較に使われる形容詞は具体性に欠けるので,数量・質を明らかにします. もし,数量・質が具体的に出すことができなければ,何が多い・少ないのか,何が良い・悪いのか書きます.

開発期間,工数に関するもの
  • 製品リリースのスケジュールが短期間 
  • 見積もりしたら,リリーススケジュールを超える
  • 見積もりを半分にする
  • 1ヶ月遅れていることが分かる
  • スケジュールが遅れている

短い,長い,小さい,大きい,遅れる,早まる,など比較に使われる形容詞は具体性に欠けるので,具体的な日時,期間を入れるようにします.

また,どうして,それが発生したのかを具体的にします. 例えば,『見積もりを半分にした理由は何でしょう?』みたいな.

これらを新たに付箋に書き出していきます.

  • CCPMを使って開発スケジュールを計画した
  • 正常系だけならば,半分の工数で間に合うと思った.
  • 異常系は,最悪,一度テストを実施した後でもよいと思った.
思い込みに注意する

事実に反している事,間違って認識していることがないか注意します.

例えば,先ほど追加した付箋

  • 正常系だけならば,半分の工数で間に合うと思った.
  • 異常系は,最悪,一度テストを実施した後でもよいと思った.

は,なぜ『思った』のでしょうか?(イタタタ・・・

思った,かもしれない,(自分は良くないと思ったので)こうやった,などは思い込みの可能性があります.

他にも,こんなのが挙げられます.

  • 仕様書通りに作ったが使いづらい(と思った)
  • スケジュールが遅れている(かもしれない)
  • 使い勝手が良くなるように修正していく(自分が判断して行った)

そこから新たな事実を出しましょう. ただし,すぐに思いつかない場合は,まずは事実と分けて認識することが大事です.

不足型に注意する

『レビュー不足』『テストが不十分』といった内容は,不足の一言で問題を解決しようとしていて,具体的に何が問題なのかが捉えられていないです.

教本によると,このように見直すとよいです.

十分・不十分となっている内容を具体的に示す.不足していることで発生している出来事を明確にする.

例えば,

  • 一部,営業の要望を満たしていない

は,具体性に欠けるため,以下のように変更します.

  • 営業の要望である,暗号化の機能が未対応である
  • 営業が作ったデータの内容が,顧客が見られる可能性がある

本来は,具体的な営業の要望や,作ったデータを見られたらいけない理由を付箋に書きだしても良いですが,ビジネスに関わるためここでは言及しません(笑

対策型に注意する

『~基準が存在しない』のような内容は,その逆の一言で問題を解決しようとしていますが,実際は解決できるのか不明です(新しい問題が発生する可能性がある)

教本では,以下のように記載されています.

それがないために発生している困った出来事や状態を記載する

今回はそれっぽいものがないと思いましたので省略します.

f:id:kabe-aa:20200510202904j:plain
STEP2

STEP3 問題分析・構造化

時系列で出来事を整理したものを,今度は原因→結果の関係に図示していきます.

気になった目的,一つに絞る

すべての事象を因果関係に結ぶこともできますが,複雑な図になり,何を解決したいのか分からなくなるため,気になった事象に絞った方がよいです.

今回は,

  • スケジュールが遅れている(かもしれない)

に絞って,左から右方向に因果関係をつないでいきます.選んだ目的は右上あたりに置きます.

なぜそう思うのか?で繋いでいく

最初に選んだ目的を結果として,原因となりえる事象を置きます.

この作業は,TOCfEのロジックブランチや,CLRの因果・十分性の懸念にあたります. ロジックブランチの作法に従ってもよいですが,それよりもかなり緩めに作ります(個人的な見解.

グループ化し,整理する

因果関係をつないでるうちに,同じレベルっぽい付箋が出てくるので,グループ化していくことで,因果関係の線を少なくするようにします.

例えば『スケジュールが遅れている(かもしれない)』につながる,以下の3事象を『今,直面している事』とグループ化しました.

  • テストに着手できない
  • 仕様書の修正が必要になる
  • 現状のツールと同じ結果が得られるか分からない

ここまでで,こんな感じですね.

f:id:kabe-aa:20200510203111j:plain
STEP3-1

情報が足りないところを補う

一見,グループ化してまとまっているように見えますが,各グループの中身について理解できるでしょうか? いや,これじゃできないでしょ(反語)w.

後で確認した時に,なぜこのグループにしたのか分からなくならないよう,もう一度事象を見直すとよいです.

なんとなく因果がありそう,原因がつながっていない

また,写真の赤の矢印は,間に何かありそうな気がしますので,もう少し突き詰めるようにします.

そうやって,出来上がった結果がこうなりました(料理番組風に)

f:id:kabe-aa:20200510203147j:plain
STEP3-2

まとめ

今回はSTAGE1の現状把握までをやってみました. 問題構造図に起こしてみて,

  1. 今の自分の状況を正しく伝える
  2. 突然の状況変化への対応への準備

は,まぁまぁできたと思いますし,突然の変化にも対応できそうな気がします.

  1. 外部の状況の変化に関わらず,改善が進められる

は,STAGE2以降の課題になると思います.

それ以外にも次の事が分かりました.

時間が経ったものは忘れやすい

最初のころのことなんて,ほとんど覚えてないです. 短い周期で見直すことがおすすめです*3

自分でも何を書いたのか分からなくなる

時系列で並べていた付箋を,因果関係に変えると,付箋の内容が理解できなくなったり,意味が通らなくなったりします. 原理や禁則に従って,注意深く見直すことが大事だと思いました*4

おわりに

ただ,ちょっときれいにまとまりすぎてるなぁ,って思ったり・・・

グルーピングした名前が原則から外れているからなのかもしれないのか,感情がなく生々しくないのか,個人的にはもやっとしていますw.

(いつか)次回は,STAGE2について言及したいと思います.*5

*1:特にTOCfEのロジック・ブランチ,CLRに影響されています

*2:個性化の原則に反しますが,今回は考えませんでした・・・

*3:とか言いつつ,同じことを繰り返すんだろうなあ(^^;;

*4:とか言いつつ,意味が通らない付箋を書くんだろうなぁ(^^;;

*5:今回のSTAGE0とSTAGE1に修正が起きなければ、という条件付きですがw