勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

ケース・スタディとケース・メソッド

中上級の技術者教育について考えている。経験的に有効な手法の一つに実際の事例を用いたグループワークがある。これをより改善するための方法を調べたり、考えたりしたことの覚え書き。

ケース・スタディとケース・メソッド

自分は実際の事例を用いたグループワークのことを雑に「ケース・スタディ」と呼んでいたのだけれども、どうやらこれは正しくないようだ。世の中にはケース・スタディとケース・メソッドという学習方法があるということを最近知った。

ケース・スタディ ケース・メソッド
事例の発端から結末までが明示されていて、それを第三者の客観的な立場から分析する。具体的状況の分析を通じて問題の原因を知り、再発防止のための教訓を学ぶことを目的とする 結末が明示されておらず、特定の状況での問題解決のための行動案を、当事者の主観的な立場から検討する。具体的状況について問題点を自ら発見し、それを解決していくための判断力を実践的に養うことを目的とする

うーん、自分はだいぶ混同していたことがわかる。

  • 「ふりかえり/レトロスペクティブ」「失敗学」のようなアプローチはどちらかというと「ケース・スタディ」に近しい。教訓抽出の取り組みである
  • メンバーの学習、スキルアップを目的とする活動は「ケース・メソッド」を使うべきだ
    • 結末は明示すべきではないらしい。この点をあまり意識していなかったな

土木学会「建設ケースメソッドのためのケース作成の手引き」に学ぶ

いろいろと調べていて学びが深かったのが土木学会が公開している建設ケースメソッドのためのケース作成の手引き(PDF)だ。

「ケースメソッド」の手法は、決まった答えのない領域において当事者が適切に判断し行動する能力を養うのに優れた方法であると言われています。それは、受講者が現実に起こった事例を基に作られた「ケース」を読み込み、そこに描かれる「修羅場」に対峙し、登場人物になりきって思い迷いながら判断、決断することによって、さながらその実体験したかのような効果(疑似体験)をもたらすします。そして、グループ討議や全体討議を通じて他者との間で掘り下げた意見交換を行うことにより、より深い考察や新たな気付きが生まれ、幅広い視野を持った実践対応力の涵養が行われるとされています。
建設ケースメソッドとは、この「ケースメソッド」の教育手法を建設分野に応用するものであります。
(同、1. 建設ケースメソッドとは より)

これだ、と思っている。素晴らしい資料だ。

  • 若手が決断を迫られる機会が減少しており、対策が必要という問題意識
  • 擬似体験を通じて実践対応力を育む
  • 現場で直面した「板挟み」を教材化する
  • ケースの肝は「修羅場」(単なる苦労話ではいけない)
  • 結末、結果はあえて書かない(正解をなぞるだけ、にしない)

実際に作成されたケース例などが以下のサイトで閲覧できる。参考にしたい
committees.jsce.or.jp

どんな用途で使うのか

(わたしの仕事である)ソフトウェア開発については、いくらでも使い所はありそうだ。プロジェクトマネジメントの領域でも、アーキテクティングでも良さそう。実際にPM教育では似たような取り組みをやったこともある。事例がベースになるので、各種のポストモーテムと関連させてプロセスに組み込んでしまうというのも良いかも。

  • プロジェクトマネジメントの領域
    • 計画:複雑な(もしくは困難な)プロジェクトの計画をどうやるか?
    • 交渉:クライアントからの要求で、トレードオフを考えながらどう交渉する?
    • 問題解決:プロジェクト中に発生する困難な問題にどう対応するか
    • 炎上対応:QCDの達成が難しい局面で、どうするか
  • アーキテクティングの領域
    • 設計判断:うーんよく考えてみたら、システム設計の面接試験 でいいような気がしてきた
    • 性能問題:どう対処するか
    • トラブル:どう対処するか

AIに書かせてみればいいんじゃない?

ここまでいろいろ考えてきたが、よく考えてみたら雑にAIに書かせてみればいいんじゃないか?という考えが降りてきた。これはちょっと研究してみよう。世の中に存在する豊富なトラブル事例をもとに、適当に合成できるのでは?