ブランチにまつわるエトセトラ
ロジック・ブランチで気づかされたことがあったので備忘録として。
ブランチを描く際に陥るケース
ブランチを書く際に、『何をブランチの事象にすればよいか分からない』と言う状況になると思います。
「とりあえず、ゴールを設定してみて、事象を挙げていこう。」と。
そこからアイテム出しをして因果関係を作っていくと、次のケースにぶつかります。
「ゴールに繋がりそうなアイテムが出てこない・・・」
実業務でも、そんな事起こってない？
ゴールを設定して説明しようとして、うまく説明できない事は、現実社会でも起こり得るケースだと思います。
例えば、以下のようなソフトウェア開発を例に説明したいと思います。
- ソフトウェアテストの計画がなく、テスト実施は各開発者の裁量で行なっている
- 新機能を開発した際に、単体テスト・結合テストで、正常系/異常系の確認は行った
- システムテストでUIから可能なテストを実施して、特に異常な動作が確認されなかったのでリリースした
- ある顧客の環境に新しいソフトをインストールし運用したところ、異常なケースが見つかり損害が発生した。
- 実は、その顧客向けの特殊仕様があり、新機能には特殊仕様の対応が含まれていなかった。担当した開発者も特殊仕様下のテストを行なっていなかった。
- 顧客「早急に再リリースしれ。あと、不具合が発生しないことを説明した資料よろ」
顧客にはどう説明する？
「再リリースしたソフトと今後の修正がが不具合がない事」の説明について、思考するんじゃないかと思います。
- 今回は、抜け漏れていた事を含めて、新機能の正常系・異常系を確認する
- 今後は、顧客と同等の環境でテストすることを徹底する
- 合わせて、過去に実施したテスト項目を再確認することを徹底する
- 担当者によっては何をOKとするか変わるので、今後は過去のテストの動作ログと比較する
でも、現状どれもできていないから顧客を説得することができない。。。何より、
「どうやったら不具合がないって言えるんだろう・・・？」
と考えるのではないかと思います。
『ブランチで陥りやすいケース』に置き換えると
もし『修正したソフトに不具合がないこと』をゴールに設定し、「今回自分たちが行なった作業」をブランチを描くと、こんな図になるんじゃないかと思います。
また、ブランチを描いている最中は、こんな事に悩むと思います（実際に自分で作ってみて感じた事）
自分たちの作業とゴールに因果関係を作ることができない
現実と違う事を説明するために、無理矢理繋ごうとしてしまい『ゴールから逆算して推測』し始めます（これ自体は悪くない）
自分たちの行動と推測の間に因果関係が作れるなら良いですが、そうならない場合は『推測の原因となる推測』を考え始めます。
考えた末に、『ゴールと同一の推測』や『ゴールとは矛盾してる推測』を作ってしまいます（ブランチを描いている最中は意外と気づいてない）ゴール達成のための十分な説明ができない
ゴールを設定しまったことで、ゴール達成の十分性を考えてしまいます。
下手すると「ゴール達成のために国際規格に準拠することが必要だ！！」と言いかねない状況になりますw*1
ブランチを描くために、ゴールを設定するのか？
実は、自分がブランチ描く際にはゴールを設定していました(笑
で、前述したみたいに、うまくいかないことの方が多かったです。
先日、他人のブランチの作成過程をみて、以下のことに気づきました。
ゴールは設定しない
ブランチを描く際は「現状把握」のために限った方が良いと思います。
そのため、ブランチの一番上にあるものはゴールではなく「最後に起こった出来事」になると思います。
ゴールではなく、あくまで観点として使う
何を事象とすればいいか分からないなら、観点の一つとして使うならありだと思います。
観点として「現状はどうだったのか？」を広げたり、掘り下げていけば、納得のいく現状をブランチで表現できるはずです。
現状とゴールとの差異を見つける
ゴールに近づいているか、作ったブランチを元に考える。
作成したブランチ(開発で実施したこと)がゴールに達成しないのは、そもそも何か問題があるんじゃないか？と気づくはずです。
こんな感じ？
「顧客環境下で不具合が発生した過程」を現状把握するためブランチを作成する。例えば、こんな感じ
※ 作成したブランチは何度か修正した最終版。一番初めのブランチは後述します。
「作ったソフトに不具合がないこと」をゴールとした場合に、
「（顧客が納得するような）十分な確認方法」として、何が足りなかったか分析する。
一例として挙げるなら、、、- 顧客は特殊仕様で運用している & 新機能の追加によって特殊仕様が動作しなくなっていた
「なぜ、特殊仕様の事を把握してなかったのか？」「どうしたら次回以降予防できるのか？」を考える
- 顧客は特殊仕様で運用している & 新機能の追加によって特殊仕様が動作しなくなっていた
最小手数で効果的なところを最初のターゲットにして、開発を改善したり、顧客への説明材料にした方が現実的だと思います。 *2
それでも、説明が足りない、と言われるなら・・・
次に改善可能なターゲットを説明すると良いと思う。
もしくは、アンビシャスターゲットツリーを使って、戦略的にゴールを目指す事を説明する方がいいと思うの(今回は省略
余談（ブランチの修正）
この記事をはじめに公開してから、ブランチの図を修正してみました。 どのように変更したか記載します。
修正前のブランチ
一番最初のブランチは次のように作りました。
- 「顧客の環境で不具合が発生する」までの出来事を挙げる
- 出来事を「ブランチ作成ルール(CLR)」に従って因果関係を繋いでいく
ただし、声に出して読んでいなかったため、違和感が残ってしまいました。
修正内容について
基本的には「ブランチ作成のルール(CLR)」に従って、声に出して修正していますが、次のように修正しています。
推測の追加
例えば、一番上の不具合発生の原因は「新しいソフトで運用する」だけでは十分ではないため、「顧客が運用している条件」「特殊仕様に対する修正」を補足情報を追加しました。因果の組み替え
「新機能をシステムに組み込む」→「UIから考えられる入力でテストを実施する」、「UIから考えられる入力でテストを実施する」＆「特に異常となるような動作が確認されない」→「新しいソフトをリリースする」までは、声に出して読んでみると、違和感がありました。
そのため、「新機能をシステムに組み込む」＆「UIから考えられる入力でテストを実施する」＆「特に異常となるような動作が確認されない」→「新しいソフトをリリースする」に変えました。文章の変更(具体化)など
特に「顧客の環境で不具合が発生する」は、起こった現象としては抽象的なので、「新しいソフトがインストールされた顧客環境では運用できない」に変更しています。
また、因果が特に重要そうでないものは1つの事象に統合しました。ただ、パワーポイントのスペースの制約で統合したので、付箋でブランチを作る際は逆に分けたままの方が使いやすいかも。
最後に
やっぱり、声を出して読むと気付きやすいですね(^^;;
まだしっくりこないところや足りない情報があるかもしれませんが、今の自分の実力ということで、生ぬるい目で見ていただいて、アドバイスしていただければ幸いです(^^;;
