夏に講師として参加したサマースクールの内容がきれいにまとまってます。ぜひ読んでみてくださいな。
ちなみに、一か所だけ間違いというか、こちらが上手く伝えきれなかったものがあります。
「レトロスペクティブ」は2週間などのスパンで進める「スプリント」の終わりにやるもので、「スタンドアップ」が毎日行うものです。
記事を書いてくださったライターさんの勘違いではなく、たしか私たち講師が混乱するような説明をしてしまった、ということです。
ただ大枠で、僕らが紹介したかったコンピュータサイエンスやプログラミングを効果的に子供たちに学んでもらう「フォーマット」が簡潔に解説されています。
いくつか補足するとしたら・・・
問題を理解し、それに対する「真の解」を探す姿勢
これは「デザイン思考」のキモなんですが、「問題」が何か、そしてそれに対する「解」を探そう!という目的意識がとにかく一番大切です。
このサマースクールで子供たちに体験してもらったのは、アジャイルやスクラムと呼ばれるソフトウェア開発手法ですが、そのベースにあるのが「デザイン思考」です。
「デザイン思考」を理解するには、「非デザイン思考」を考えると分かりやすいです。今あるシステムを改善していく、既存の問題解決方法を出発点に新たな発想を試みる、未来も見据えて究極的なソリューションを作る。などです。
おそらく、「非デザイン思考」とそれをベースにしたプロセスで生み出される「解」はどんどんとよくなっては行くでしょう。だけども、「真の解」にたどり着けるかどうかというと、そうかもしれないし、そうでないかもしれない。
ここで前マイクロソフトCEOがiPhoneが出た時にそれを鼻で笑った有名な動画を見てみましょう。
まぁいろいろとDisってますが、「ビジネスでは使えないね、だってキーボードがないんだぜ」みたいなところ。
ここが「非デザイン思考」です。「キーボードありき」の発想だから、「真の解」である、すべてがタッチパネル・スクリーンにはなかなかどうしてたどり着けないわけです。
繰り返しイノベーションを生むプロセス
もちろん、全面タッチパネル・スクリーンは今の段階での「解」だけど、5年後、10年後、20年後には、どうなってるか分かりません。スクリーンが物理的ではなく、プロジェクトされるものかもしれないし、脳に直接つながってるかもしれないし、わかりません。
ということは、このサマークラスでも強調したように「答えのない問題に取り組む」こと、そして「常に今のベストの答えを提案していく」ことが大切になります。常に出していき、世に問う。「こんなのであなたの問題は解決しますか?楽になりますか?」そういう姿勢。
具体的にはアジャイルやスクラムという方法で、短い周期のプロセスに乗せて、解決を開発リリースしてきます。
リリースするたびに実際に使うひとから直接的にフィードバックを得ます。お客さんのレーティング、レビュー、バグなどのクレーム、さらにはSNSなどでのつぶやきなど。
間接的にフィードバックを得る必要があります。テレメトリーっといって、いつ、どのぐらいダウンロードしてくれたか、どのぐらいログインして使ってくれたか、どのぐらいの頻度でどの機能を使ったか、など。
そういうフィードバックを取り入れて、次のリリースでのかじ取りを決定します。
こういう短い周期のプロセスだと「実験」も出来ます。実際ABテストといって、異なるグループのユーザに既存の体験と新しい体験をしてもらって、その反応をみるという方法です。
こういう土台があると「実験→発見」からイノベーションにつなげることが可能になります。
プログラミングうんぬん以前の素養
プログラミングという技術的な知的活動がソフトウェアを開発していく上で重要なのは分かり切っていることですが、いやいやそれだけじゃぁ上手くいかないみたいだぞ、という認識が生まれて、定着してきているように感じます(いや、まだまだかな・・・?)
記事でも紹介されていますし、私たちも最重要要素としてサマースクールに取り入れたのが「チームワーク」と「コミュニケーション」です。簡単に一言で表すと「ひとりじゃ何も作れない」ということです。
もちろん、まれに天才がひとりですごいもの作っちゃうこともありますけど、それは0.001%とかの割合であって、一般人が作っていこうとなるとチームでやらないと無理ってことです。
チームワークという要素は、さらに「役割分担」「共通のゴール」「横断的な協力」などに分かれると思います。そういう難しい言葉を使わずに、体験型のアクティビティを通して直感的にチームワークを理解してもらおう、というのが今回のサマースクールのアプローチでした。
コミュニケーションに関するトピックは、こっちにがっつり書きました。
watanabe-tsuyoshi.hatenablog.com
プログラミング学習の立ち位置
ソフトウェア開発におけるもっとも重要な成果物はコードです。コード以外にもメタ情報的なドキュメンテーションや、デバイスの環境を構成・構築することなどもありますが、コアにあるのはコードです。
どんな成果物にも品質がありますから、質の高いコードが求められます。そういう意味で有能なプログラマー、というかソフトウェア開発者(Software Developer)やソフトウェア・エンジニアが必要になります。
でも、ここでも「デザイン思考」が重要になります。今使っているプログラミング言語(Java? C++? Python?)、今使っているプラットフォーム(自前サーバー、クラウド?)、今までやってきた開発手法(上流工程で設計、下請けが実装?)などの既存のものを出発点に「真の解」へ向かっていこうとしても、先に述べたように、上手くいかないとわかってきました。
それより、問題をしっかりと把握し、それに対してのソリューションを提案していく。だめそうだったらさっとひっこめる(Fail fast 素早く失敗しろ)というやり方で進めるとしたら「どのプログラミング言語を勉強したらいいですか?」という質問が的外れなのが分かると思います。
ただし、プログラミング言語の選択に関しては、持論はまず、一つを選び、その言語の機能をひととおり扱えるようなる、というのは、当然いろいろとかいつまんでどれも中途半端、よりいいです。母語(日本語)をまずしっかり理解してから、外国語(英語)という流れとまぁ同じです。
まとめ
仲間と講師をつとめたコンピュータサイエンス・サマースクールですが、結構深いでしょ?って話。プログラミング教育をどうやって「やった気になるだけ」で終わらないようにさせるか、常に模索してきたことで、これからも私自身も「デザイン思考」を稼働して進めていこうと思います。「真の解」はあるはず。だれでも小さなスティーブ・ジョブズになれると信じて・・・!