「高専生と取り組むScrum」の資料が素晴らしい
「高専生と取り組むScrum」の資料が素晴らしいのでメモしておく。
【元ネタ】
【参考】
「Ameba流Scrum」を浸透させるために私たちが実践したこと
「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」の発表資料が素晴らしい #devsumi: プログラマの思索
PBLのためのScrumとチケット駆動開発を組み合わせた事例: プログラマの思索
【感想】
【1】社会に出るまでの教育の現場では、小学生・中学生・高校生・大学生も、実験や体験学習で、プロジェクトに似たような経験をする。
つまり、その場限りで、有期性を持ち、明確な回答が一意に決まっていないプロジェクトに対し、自分たちでどのようにアプローチして解決するか、その内容をレポートする宿題。
しかし、教育の現場では、そのようなレポートは、その中身や結果を正確に評価するのは難しい。
ビジネスなら、売上が上がった、利益が上がった、コストメリットがあった、社員の団結力が上がった、などの効果を見出すことができる。
でも、教育の現場は基本は、生徒に金額を付けて評価することはしないのが前提だ。
あくまでもその生徒の純粋な能力や人格を相対評価するだけで、その生徒が生み出した結果を評価すると、序列がはっきり出てしまい、教育しにくくなるデメリットが大きくなってしまうから。
だから、課題解決のようなプロジェクトをやっただけのレポート提出だけで終わってしまい、そこから得られた経験が蓄積されない弱点があるのだろう。
上記の資料では、Scrumを入れることによって、課題解決のPDCAサイクルを回し、生徒が自発的に学習しながら成長していくフレームワークを提供しようとする意図が見られる。
実際、Scrumのフレームワークに生徒がうまく乗って、アジャイルな開発サイクルを回せたようだ。
【2】一方、「「Ameba流Scrum」を浸透させるために私たちが実践したこと」では、「Scrumはフレームワークとして理解しやすく、開発マニュアルとしての役割にもなるので、現場のエンジニアの理解は早かった」という感想があって、同様な事象を上記の資料にも感じる。
また、PBLのためのScrumとチケット駆動開発を組み合わせた事例索でも、大学のソフトウェア開発の課題研究にも、Scrumのフレームワークが非常に有効だった、という研究成果もあった。
つまり、Scrumは、ソフトウェア開発という文脈では、教育現場やベンチャー企業など、開発プロセスがあまり重視されていない場にスムーズに導入しやすく、成果を出しやすい特徴があるように思える。
その理由はおそらく、次の3点があると思う。
(1)Scrumがフィードバックループを持つらせん状の開発サイクルを持っていること
(2)Scrumで定義するチームとメンバーがうまく役割分担されていること
(3)Scrumが定義する会議体を実践することでスムーズにプロジェクト運営できること
上記の3点さえ理解して運用すれば、チーム運営がうまく回るような仕組みをScrumは提供しているわけだ。
【3】ここで、上記の資料で興味深いのは、Scrumのロールを教育現場にどのようにマッピングしたか、という点だ。
下記のように、Scrumのロールをマッピングしたようだ。
・プロダクトオーナー:専攻科2年の生徒
・スクラムマスター:教師
・チーム:専攻科1年の生徒
・外部のステークホルダー:他の先生
先生がスクラムマスターになり、プロダクトオーナーとチームが生徒同士でチームを組んだならば、生徒が主体的にソフトウェアを設計して開発するとか、アイデアを出しては試す、ということがやりやすくなるだろう。
また、課題が出て困ったときには、先生がチームに助け舟を出すことで、チームが停滞しないように手助けできるだろう。
個人的には、Scrumが一番優れている点は、チームが主体的に進められるように、組織体制にソフトウェア開発の役割をうまくマッピングしてアジャイルに回す仕組みを作っている点だと思っている。
【4】また、上記資料の「ふりかえりと計画ミーティング」の内容がとても良いと思う。
ふりかえりでは、「できていないこと、に自ら気付く。率直な思いが出る: 不安・焦り・不信感・達成感」が出るとのこと。
初めてプロジェクトに携わり、色んな思いを吐き出すことで、また新たな成長を促す。
達成感があると同時に、やり残した感も出てくる。
そういう経験を積んでいくうちに、自分で課題を見つけて、自分なりの目標を掲げて、自ら成長していくわけだ。
【5】そんなことを思うと、教育現場そのものもScrumのフレームワークで回してしまえばいいのでは、と極端な提案がしたくなる。
例えば、こんな組織構造も考えられるのではないだろうか。
・プロダクトオーナー:教員(メイン)
・チーム:生徒数人
・スクラムマスター:各チームを自由に回るファシリテーター役の教員
・外部のステークホルダー:他の先生、教頭、校長
生徒が自発的に学習する環境を整えたいなら、生徒3~7人と教員のスクラムチームを作って、スプリント単位に全教科を学習していけばいい。
校長や教頭などは、ニワトリであり、部外者だ。
彼らはスプリントデモの時だけ参加すればいい。
他の場面で口出しする必要はない。
果たして、他の現場でも回せるのか、興味のある所。
【6】上記資料の最後にはこんな言葉がある。
とても意味深な言葉だと思う。
(引用開始)
高専生が将来、みなさんの「頼れる仲間」として活躍できるようになるには、彼らにどのような出会いの場を、どのように提供すればよいでしょうか?
(引用終了)
| 固定リンク
「コミュニティ」カテゴリの記事
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- 『世界一流エンジニアの思考法』が学べる環境を手に入れてかつ継続する方法の感想 #devboost(2023.12.10)
- 第25回東京Redmine勉強会の感想 #redminet(2023.11.05)
- パターンカタログよりもモンスターカタログの方が面白いね #jasstkansai(2023.06.24)
- デブサミ2023の感想(2023.02.11)
「Agile」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
コメント