『こんな時だからこそ状況を把握する ~SaPIDでふりかえる~』を考察してブラッシュアップしてみた
前回は、SaPIDの教本に倣って問題構造図を作りました.
個人的にモヤモヤするところがあったので,その理由を考察して,問題構造図を修正していきたいと思います.
なぜ,モヤモヤするのか?
前回の最後に「なんかきれいにまとまりすぎてる」=あまり納得していない,で締めました.
まずは,なぜそう思ってるのか,個人的な見解を述べたいと思います.
メタ認知的な観点
wikipediaより引用すると,こんな能力らしいです.
現在進行中の自分の思考や行動そのものを対象化して認識することにより、自分自身の認知行動を把握することができる能力
自分の場合は,エニアグラムのタイプ4の気質を使って,自分の問題構造図にこう感じました.
自分自身を把握する方法は人それぞれだと思いますが,まずは問題構造図を作ったことで満足せずに,自分に対して,言葉を出して,問題構造図を説明してみるというのが必要だと思います.
ブランチ(TOCfE)との違いが原因か?
SaPIDとブランチのお作法の違いが,違和感の原因になってるのか考えてみました.
ブランチでは,因果関係を厳密に確認するため,次のように読んで違和感を見つけます.
- もし原因A(,かつ原因B)ならば,結果として結果Cである.
- もし原因Aならば,結果として結果Cである,なぜならば原因Bだからである.
SaPIDではこの確認を行っていないのですが,SaPIDでもやった方がいいのでしょうか?
自分の答えは否です. 理由としては,全体を把握するための工程だからです.
パズルを解くとき,こんな手順で進めると思います.
- 完成形の写真から,それぞれのピースがどこに位置するか大まかに決める.
- 範囲を狭めていき,徐々にピースの位置を特定する.
- ピースがちゃんとはまるか確認する.
SaPIDのSTAGE1は,パズルの作成工程の1に相当すると考えています. そのため,現段階ではブランチのようなチェックを行わなくてもよいと思っています.
まぁ,ブランチも,最初の段階では大まかに因果関係を決めているはずなので,どちらも同じ手法だと考えてよいと思います.
この問題構造図は失敗したのか?
すべての事象を出していない,この問題構造図は失敗なのでしょうか? 一度に,作りきらないといけないのでしょうか?
いや,そんなはずはないはずだ(反語)(笑.
いったん頭の中にあるモヤモヤが問題構造図に整理された状態で,頭の中はスッキリした状態です. 整理された状況と向き合ったことで、自分の本音や新しい気づきが得られると思います. 逆に,一度に作りきることは難しいと思います. 問題構造図を作ったことに満足せずに,作り変えていくとよいと思います.
不足している事象を追加する
というわけで,問題構造を作り変えていくことにします. 作り変える前に,以下の事を手掛かりに事象を増やしていきました.
行動の変化
最初は「時間がないから異常系はテスト後でもいいや」って思ってましたが,テレワークを実施したタイミングあたりから「やっぱりテスト前に異常系も実装しなきゃ」って変わってました.
どんな事を考えて実装していたか,時系列で出してみました.
まずは,基本的な実装の流れについて
- 1機能の正常ケースを試しに実装してみる
- ツールを動かしながら,ツールに必要な課題を洗い出す
- 1機能にテストコードを追加し,リファクタリングする
これは,自分の判断で進めた作業方法です(チームが決めた方法ではないところがミソ). この作業を,1機能の中で,納得するまで繰り返していったのですが,次のような事が起きていました.
異常ケースという沼
- すべて入力しないと,ツールが異常終了する.
- 正常ケースだけの実装だと,ツールが使いづらい(と感じた).
- 異常終了しないため,異常ケースを追加実装する.
- 異常ケースを追加すると,新たな異常ケースとなる条件が見つかる.
という沼に入りました.
機能改善という沼
また,不正に入力されたデータが入力された場合,こんな思考になりました.
- 入力データは多量の数値から構成される.
- 入力データが不正なのか判断することが難しい.
- 不正に入力されたデータは,実行する前にチェックできた方が良い(と思っている).
- 入力データに問題がないことをチェックできるように機能を改善する.
- 機能改善すると,新たな課題が見つかる.
状況の変化
周りの状況が変化しているので,それらも時系列で増やしていきます.
以下のような事象が出てきました.
- 協力社員がやめるので,作業を引き継ぐ
この点について,時系列で起きた事を洗い出してみました.
自分が持つ不満
最後に,自分の持つ不満も出してみました. というか,自分の不満が出ていなかったことが,前回しっくりこなかった理由かもしれない笑
- 職場のコミュニケーションが少ない
- 自分が正社員で一番年下
- 自分が仕事の内容が良く分かっていない
- などなど*1
問題構造図を修正する
新たな事象を出したところで,改めて問題構造図を作ってみます. 今ある問題構造図は捨てて,一から作り直します*2
今自分がクリアしたい問題は何か?
前回は『スケジュールがもっと遅れる(かもしれない)』が知りたかったですが,新たな事象を出していたところで,以下の3つが気になりました.
- 会社の開発規約に沿って開発していない.(だから,遅れているのではないか?)
- 自分の責任範囲が増え,開発が進んでいない.(だから,遅れているのではないか?)
- 自分が職場や人に相談しづらい.(だから,遅れているのではないか?)
1つ目から順番に作ってみることにしました.
問題構造を作るうえで,以下を気にしています.
グルーピングは,最初はざっくり,徐々に詳細化
『パズルのピースの位置を大まかに決める』ぐらいの感覚で,ざっくり決めていいと思います.
因果関係を作りながら,グループ内で細分化したり,グループ同士を大きなグループにまとめればいいと思いました.
グルーピングの名称について
グルーピング名称は,一般名称をできる限り使わないようにし,そのグループが何を表しているか,自分の言葉で示すようにしました.
起きた出来事・自分の考え・行動は区別する
少なくとも,この3つは分けるようにしました.
これらを一つにグルーピングしないように注意することで,ミスリードしないようにしてみました.
『会社の開発規約に沿って開発していない』の問題構造図(前半)は,次の図のようになりました.
ここから分かったことは以下でした.
- 開発規模の大きさに対する『悪魔のささやき』と,少しでも良い設計にしようとする『ささやかな良心』が存在したw
- 設計の変更は,成果物に対する不安などからくる自分の弱い心がそうさせているw
- いくら異常ケースや改善しても,設計変更はキリがないw
後半部は以下の通りです.
『ささやかな良心』によって作業した結果,『仕様書の修正』と『次工程への着手の遅れ』が発生している事が分かりました.
次に,『自分の責任範囲が増え,開発が進まない』ですが,以下のような可能性がありそうした.(断定はできない・・・)
- 今まで引き継ぎ対象が共有されてこなかったのは,職場環境が影響している可能性がある.
- 自分の業務の改善依頼した結果,仕様書の作成作業などで自分の作業を忙しくなる可能性がある.
- 自身の後退的な気質が影響してか,他人に無理強いをしないため,自分で作業を増やしている.
最後に,『自分が職場の人に相談しづらい』も入れてみましたが,今のところ,今の作業に影響を及ぼすところが見当たりませんでした*3
追記
レビューの実施の遅れが影響してそう…
感想
今回気を付けた点は,たまたまうまくハマったのかもしれませんが,結果的に前の問題構造図よりしっくりくる図が完成したと思っています.
なんとなーく「規模が大きかったとしても,自分の方針ではなく開発規約に沿ってたらスケジュール通りだったかも」って思っています(根拠はないけどw. 一方で,今回の設計だと成果物の品質は良くなかったと思いますので,その解決方法をSTAGE2で決めることになると思っています.
ただ,今,私が興味を持っていることは『開発スケジュールの遅延』ではなく『責任範囲が広くなってきて首が回らなくなりかけている』ことに作っているうちに気づきました. 実際は,もう少し時間が経てば『引き継ぎ』や『業務の改善依頼』が変わると思っています (引き継ぎは一過性な作業で,一方で,業務の改善依頼による仕様書作成は不要かもしれないと思っている). これらの状況の変化によって,今後の自分の作業内容も変わってきそうな気がします. そのため,その事象を確定させてから,STAGE2をやっていいと思いました.
最後に
安達さんの提案で,こんなイベントを企画しました.
本音は,その場でみなさんの質問に答えられるか分からないので内心ドキドキですが,みんなでワイワイ意見を出していくことで盛り上がればいいなぁと思います.