【読書メモ】システム開発の問題について考える~世界一やさしい問題解決の授業―自分で考え、行動する力が身につく~
【本の内容】
簡単に本の内容を紹介。
人生でだれしもが体験する壁(問題)に対して
以下のような思考パターンよくなーいとのこと
①どうせやった〇〇だとという考え方で行動をしない
②精神論で対処すること。問題解決できない理由を精神論で議論すること
問題に対し必要な思考は、
①問題を認識すること
ここでいう問題とは、あるべき姿と現状のギャップのこと
②なぜその問題が発生しているかを複眼的に考える
例)分類図やロジックツリーなどを使用
③仮説をたてる
〇〇という行動をおこせば問題解決するだろう
④検証する
というもの。
【メモ】
①問題発生→再発防止対策は根本的な解決にはならない
この本にも記載されているが本当にそうだなと思う。
たとえば、このような表面的なたいさくになりかねない
問題:リグレッションを発生
対策:リグレッションを起こさないようにテスト項目を増やそう
こうした問題に対して、PGの内容やプロジェクトの状況、個人の技術・知識
などは事例によるから絶対的な解はないのかもしれないけど、
すくなくとも、対策を考える前に
「なぜリグレッションを起こしたのかを考えなくてはいけない気がする」
たとえば、
①修正個所に影響があると思われる部分を洗い出さなかった
②洗い出しは行ったが、洗い出しから漏れていた
③対抗テスト対象箇所には該当していたが、パターンが不足していた
などがあるし、上記の項目にさらに「なぜ〇〇だったのか」で
考えてみる必要があるのかもしれない。
単純にリグレッションが発生したから次からはテスト項目を増やしましょうという
考えよりは建設的に思える。
実際には
・修正者や試験者とのコミュニケーション齟齬
・納期が迫っていてパターンの洗い出しに時間をかけられない
などさまざまな要素が関わってくる気がするけども
自戒を込めて、問題やトラブル、手戻りなどが生じた時に
同じような事例で同じよう問題やトラブル、手戻りを起こさないような
対策を考えていける・改善していけるようにしたいなーと
②問題やトラブル、手戻りの原因を個人に帰結しない
あまりにも直接的に関わる当事者の責任感が薄かったら、なんか考え直すけど
基本的にはプロジェクトレベルで考えた時に
問題やトラブル、手戻りの原因を個人に帰結しない方がよいなと
理由は、個人の責任に帰結すると、プロジェクトにとって良い影響がない
まず、
①雰囲気が悪くなる
単純になんか働きづらい気がする
②個人の責任にするとチームとして再発防時に対する工夫がなくなる
こういうルールをつくろうやAは個々が弱いからここをフォローしようとか
③個人の知識経験は劇的に変化しづらいため、問題やトラブル、手戻りを起こす可能性がある