OSS Gateワークショップ2016-06-11開催レポート
2016年6月11日（土）にOSS Gateワークショップを開催しました。
これまでのワークショップは広く参加者（ビギナーとメンター）を募集していますが、今回のワークショップは1つの企業の社員だけで開催しました。ビギナーもメンターも社員です。強制参加ではなく、希望者のみの参加です。この点はこれまでのワークショップと同様です。メンター全員が未経験者なのは一番最初のワークショップと同じです。なお、進行役だけは経験者である須藤が担当しました。
OSS Gateについての説明は、OSS Gateへようこそ！という記事をご覧ください。 次回のイベントはOSS Gateワークショップ2016-07-30 - OSS Gate | Doorkeeperですが、現時点では満員になっています。 9月24日でもいいよという方はOSS Gateワークショップ2016-09-24 - OSS Gate | Doorkeeperに登録してみてください。
今回のワークショップでこれまでと違うところはレポート係というワークショップの内容をまとめる専門の人をおいたところです。これまでは、参加した人それぞれにブログにまとめてね、としていましたが、今回はまとめることに専念する人がいました。
レポートをまとめる目的は以下の3点です。
- OSS Gateの取り組みを世に広め、OSSの開発に関わる人を増やす
- ワークショップのやり方を広め、進行役・メンターを増やしたり、東京以外での開催を支援する
- レポート係が客観的にワークショップの進め方を観察することで、ワークショップの改善点を見つけ、次回に活かす
今回もいつものように以下のような流れで進めました。
- 座席の配置
- OSS開発手順
- 立場の説明
- アイスブレイク
- 開発対象のOSSを決める
- 作業メモについて
- 動かしてみる
- 他の人に説明する
- 昼食
- フィードバック
- 整理する
- 編集する
- 報告する
- 他の人に説明する
- まとめ
座席の配置
今回は、メンター（ビギナーをサポートする人）が5人、ビギナー（OSSの開発に参加したいけどまだできていない人）が12人と、1:2くらいの割合でした。 メンター1人につきビギナーを2人くらい見ることになる計算です。
席の配置は重要です。メンターがビギナーをうまくサポートできるかどうかに関わるからです。ポイントはメンターとビギナーを隣同士にすることです。隣りにメンターがいないとビギナーは聞きにくくなります。メンターの目が届かないビギナーも出やすくなります。
これまではメンターがビギナーの2倍いることが多かったので1人のビギナーを2人のメンターで挟んでいましたが、今回は割合が逆なのでメンター1人の横にビギナー2人が座るようにしました。
- ビ: ビギナー
- メ: メンター
- □: 机
スクリーン・ホワイトボード
進行役
ビ□ビ ビ□ビ ビ□ビ
メ□メ □メ メ□メ
ビ□ビ ビ□ビ ビ□ビ
6人座れる島を3つ用意して、3つのグループに分けました。3人ずつの島を6つ用意することもできますが、そうすると横幅が広がって進行役が進め方を伝えるときに伝えにくくなるので3つの島にしました。体を横にするとスクリーンを見えるようにした（後ろを向かなくても全員がスクリーンを見れるようにした）ことも進行役が進めやすくするためです。
メンターが1人しかいないグループは進行役がサポートしました。
メンター1人につきビギナー2人だと、メンターが1人のビギナーにかかりきりになるともう1人のビギナーをサポートできなくなります。かかりきりになるような場面のときは進行役がサポートに入り、サポートが必要なビギナーが放置されないようにしました。
この体制で実施したところ、（未経験の）メンター1人につきビギナー2人という割合でもまわることがわかりました。これまではメンター2人につきビギナー1人という割合でやることが多かったので、どれだけメンターが少なくても大丈夫なのかはわかりませんでした。今回の経験はこれからの基準として使えそうです。
ただ、課題はありました。午後に数人のビギナーが同時に進行役のサポートが必要な状態になり、サポート待ちのビギナーがでる状態になりました。今回、進行役がやったような「メンターをサポートするメンター」を数人用意するとうまくまわりそうです。そうすればサポート待ちのビギナーを減らせます。この方法でうまくいくか、次回のワークショップで検証する予定です。
「メンターをサポートするメンター」が動きやすいように、それぞれの島の間に広めにスペースを作りました。これも席を配置するときの大事なポイントです。
OSS開発手順
以下の資料を使ってこのワークショップで体験するOSS開発手順を説明しました。
これまでと同じ資料を使っていましたが、資料をベースにしつつも随時説明を追加したり省略したりしました。進行役をできる人が増えるようにするためには、資料を更新し、須藤以外でも進行しやすいものにする必要があります。これは次回のワークショップでの課題です。
立場の説明
ビギナーとメンターの立場を説明しました。
ビギナーは、OSSの開発に参加したい人や、参加したことがあるけどまだ不安がある人です。目的はOSS開発に参加する（経験する）ことなので、なにかすごいことをする必要はありません。
メンターは、ビギナーをサポートする人です。相談されたときは答えを教えないことがポイントです。教えるのではなく、一緒に考えたり、一緒に調べたり、一緒に悩みます。具体的な言い方にするとこうです。サポートするときに自分のパソコンを使わないでください。検索するならビギナーのパソコンで検索します。動かして動作を確認するならビギナーのパソコンで動かして動作を確認します。それが「一緒に」ということです。ビギナーの目の前で「一緒に」やることで「メンターはすごいから自分でいろいろ解決できるんだよ」感を減らします。「結果」だけ与えられるとそう感じやすくなります。「過程」も経験すれば「自分でもできそう」感が増えます。
アイスブレイク
ワークショップをより充実したものにするためにいつもアイスブレイクを行っています。今回のワークショップでも行いました。
アイスブレイクの内容は、同じ島の人になぜ参加してみようと思ったかを話す、です。この内容にしている理由は次の通りです。
- なにかしら理由があるはずだから話す内容に困らない
- 参加した理由を自分で再確認する機会になり、ワークショップでなにを得たいかが明確になりやすい
- メンターがビギナーをサポートするときに助かる情報があるかもしれない
他に、「声を出すこと」自体がポイントです。一度声を出しておくと質問したり声をかけたりしやすくなるものです。
開発対象のOSSを決める
今日のワークショップでビギナーが開発対象にするOSSを決めます。決めるときはメンターがビギナーをサポートします。
これまでのワークショップではワークショップ開始前に進行役がすべてのビギナーの開発対象OSS決めをサポートしていました。メンターがすべてのビギナーの開発対象OSS決めをサポートをするのは今回がはじめてです。
メンターにビギナーのサポートの仕方を伝えるため、ビギナー1人に進行役の隣に来てもらい、決め方を実際に見せました。決めるときのポイントは、普段使っていて思い入れのあるものを選ぶことです。調べなくても名前が出てくるものや、どの機能で使っているかわかるものが望ましいです。有名なものよりも自分にとって思い入れのあるものを選びます。
実際に決め方を見せることにより未経験のメンターでもビギナーをサポートできることがわかりました。これは今回のワークショップで得られた知見です。
作業メモについて
何か新しい作業を始めたり、作業中に詰まったら、メモを残してもらいます。たとえば、インターネットで検索しようとしたときは「作業中に詰まった」ときなのでメモを残すポイントです。
メモにはできるだけ再現できる情報を書きます。実行したコマンドや表示されたエラーなどを省略せずに残しておくことが大事です。自分は不要だと思って省略した情報でも、開発者にとってはヒントになったりするからです。
作業メモを一覧しやすいように、作業メモはOSS GateのGitHub Issuesに作成しました。
動かしてみる
OSS開発手順の説明が終わったら、選んだOSSを実際に動かします。このときのポイントは、ユーザーとして動かすことです。動かしてみて詰まったことは都度メモしておき、あとで報告できるようにしておきます。
ビギナーは作業をしているとメモをとることを忘れてしまいがちです。ビギナーがメモをとることを忘れていそうなときにメモを取ることを思い出すようにすることは、メンターの大事な役割です。
他の人に説明する
午前の部の最後に、ビギナーはメンターに午前中にやったことを説明します。このとき、作業メモをベースに説明します。説明するメンターは違う島のメンターです。つまり、サポートしてもらっていたメンターとは別のメンターに説明します。
メンターはビギナーからやったことを聞いて次のようなことをフィードバックをします。
- 実は問題なのにスルーしてしまっていたり、無意識にやっていたけど実は大事なことだったといったことに気付くきっかけを与える
- この後どうすればよいかわからなくなってしまった人には、次にどう進めばよいかのアドバイスをする
この時間はメンターとビギナーが一対一で話すことになるため、片方のビギナーが話を聞いてもらっている間は、もう片方のビギナーには二人の近くに行って話を聞きます。他のビギナーのやったことから学ぶ機会にします。
ここでも、最初にビギナー1人に進行役の隣に来てもらって例を示しました。以下のようなやりとりをしました。
- 進行役：「まず何をしましたか？」
- ビギナー：「READMEを読みはじめました。長いなーと思いながら読み始めました。」
- 進行役：「READMEを見ながら話をしましょうか。（メモにREADMEへのリンクがなかったのを見て）READMEへのリンクをメモしておきましょうか。」
- ビギナー：「READMEを読んでいたらRailsプロジェクトを作らないと試せないとわかったのでRailsプロジェクトを作り始めました。」
- ビギナー：「Railsプロジェクトを作ろうと思って
rails newをしたらエラーがでたんですよね。」 - ビギナー：「最初なにが悪いかわからなかったんですが引数が足りないのが悪いとわかったので…」
- 進行役：「ちょっと待ってください。もしかしてエラーメッセージが違ったらすぐになにが悪いか気づけたりしましたか？」
- ビギナー：「あー、もしかするとそうかも…？」
昼食
ここで昼食休憩に入りました。チームごとにまとまってお昼ごはんを食べに行きます。
雑談で自分が使っているOSS開発に便利なツールを紹介している人がいました。こういう話を日常的にできるとよいですね。
フィードバック
午後からはフィードバックの時間です。以下の資料を使いました。
まず、改善できる箇所が見つかった人がどのくらいいるか確認しました。8割程度の人が見つかっていたので午後からはすぐにフィードバックをすることにしました。まだ見つかっていない人は進行役が順番にフォローすることにしました。ここでサポート待ちの人が増えてしまったことが課題です。「メンターをサポートするメンター」数人の体制で解決できないかを次回のワークショップで検証します。
まだ改善できる箇所を見つかっていない人に進行役がした質問は以下のようなものです。
- 今日やったことを教えてください。
- なぜこれにしたんですか？
- 何が知りたいですか？
- 何を知れなかったですか？
- どうなっているとよかったですか？
改善できる箇所が見つかった人はフィードバックを進めます。報告は以下の3ステップで進めます。
- 整理する
- 編集する
- 報告する
整理する
まず、ビギナーは自分にわかる文章としてまとめます。他の人にわからなくても自分がわかればOKです。
メンターは質問したり話をしたりしてビギナーの考えを整理します。
編集する
次は、報告を受ける側の開発者にとってわかりやすい文章にします。報告方法をまとめているOSSもあるので、その場合はそれに沿った報告方法にします。 メンターは、自分が報告を受けたときはどういう情報があるとうれしかったかという経験に基づくアドバイスします。
OSSを開発しているのは日本の人だけはありません。いろいろな国の人が開発していることがあります。そうすると時間的・空間的に離れていることがあります。 活動時間帯が異なると、1回のやりとりに丸一日かかってしまうことがあります。 できるだけやりとりが少なくて済むように、想像しなくても伝わるような情報を提供することがポイントです。そのためには、やったことだけでなく、やっていないことも書くとよいです。
報告する
今回はすべてのOSSがGitHubを使っていました。
GitHubの報告方法には主に2種類あって、報告だけ（issue）の場合と、パッチを添える（pull request）場合があります。すぐにパッチを作れるのであればpull requestでよいです。実際の変更があった方が説明だけよりも伝わりやすいからです。すぐに作れない場合は作れるまで待つよりも、issueとして報告する方がよいです。後で報告しようと思ったまま忘れてしまうかもしれないからです。忘れてしまうよりは報告してあった方がよいです。
報告に対して開発者から反応がある前にパッチができたら後からpull requestを作ることもできます。そのpull requestに「このissueに対応するものだよ」と書いておけば伝わります。無理して最初からpull requestにする必要はありません。
このフェーズは、OSS開発の経験が少ないメンターだと難しいと感じることがあるかもしれません。そのときは、他のメンターや進行役に相談します。困ったときは相談する、というのはビギナーでもメンターでも一緒です。進行役がビギナーのサポートを引き取ったときは、ビギナーのサポートが一段落した段階でメンターに現状を共有し、その後のサポートを引き継ぎました。
以上の整理する、編集する、報告するという流れでは特に区切りを設けずに、それぞれのペースでやりました。 メンターに見てもらってOKもらったら報告するというのがひとつのゴールで、それをみんなが一度は経験するというのを目指しました。
進行役がビギナーのサポートを多めに引き受けてしまい、予定よりも長めに時間をとることになってしまいました。このあたりも「メンターをサポートするメンター」を数人導入することで解消できそうです。
メンターからのよくあるアドバイス
説明が漠然としていたのでもう少し具体的にしたほうがよいというアドバイスはいろいろなところで聞かれました。ビギナーは開発者なら察してくれそうと思ってしまいがちですが、そういうことは期待しないほうがよいです。調べるのが難しいなら無理をしてまで調べる必要はありませんが、調べたことであればもれなく伝えます。
改善してほしい理由に対して指摘が入る場面もありました。ビギナーはつい「一般的には」という理由を使ってしまいがちですが、そうではなく「自分は」どうかという視点のほうがよいです。
例えば、RDoc形式のドキュメントをMarkdown形式に直してほしいとします。そのときに、「一般的にRDoc形式よりもMarkdown形式のほうがいい」という説明では、そのプロジェクトでの必要性が伝わりません。 それに対して、「自分はドキュメントを改良したいけど、RDoc形式では書きたくない。Markdown形式ならドキュメントを改良してもいいと思っている」 という伝え方をすれば、「改良してくれるならMarkdown形式にしてもいいかな」と開発者が思ってくれるかもしれません。
他には、複数の問題があるときに、どこまでをこのissueでやるのかといったアドバイスも行われていました。
他の人に説明する
すべての作業が終わった後に再びビギナーがメンターにやったことを説明する時間があります。
午前の最後に聞いてくれたメンターとは別のメンターに説明します。ポイントは午前の最後の時と同じで、ビギナーが気づいていなかった点を気づかせたり、気づかずによいことをしていたときによかったと気づかせたりすることです。
まとめ
さいごに、今日やったことをまとめました。資料は以下です。
ビギナーには、詰まったらメモを残す進め方や、問題が見つかったときに直すという選択肢があることを経験してもらいました。また、OSS開発はすごいことをする必要はないことも伝えました。開発者はREADMEを読まないので、初心者だからこそ気づくこともあります。
アンケート
最後にアンケートをとってすぐに確認してワークショップ全体をふりかえりました。これはいつもやっていることです。
これまでのワークショップではGoogleフォームでアンケートをとっていましたが、今回はGitHubのリポジトリーに用意したYAMLファイルを編集してpull requestを送ってもらうことにしました。データをまとめることが楽になりそうだからです。
アンケート結果
ビギナー・メンターともに全員が「満足」・「すごく満足」したワークショップでした。また、想定以上（「想定通り」または「想定より充実していた」）の内容と感じていました。
ビギナーの多くはこれからはOSSの開発に参加するとのことでした。
メンターはサポートすることでいろんなことに気づくきっかけになったようでした。
おわりに
2016年6月11日（土）に開催したOSS Gateワークショップの内容をまとめました。
OSS Gateワークショップを通じてOSS Gateの取り組みを知ることはできたでしょうか？進行役やメンターをやってみたい人の参考になったでしょうか？
ワークショップに参加したいという方（メンターでもビギナーでも）は、DoorkeeperのOSS Gateコミュニティページに次のワークショップの情報があるので参考にしてください。OSS Gateメンバーに聞きたいことがある方はチャットルームを使ってください。
今回のように企業で開催したいという方は前述のチャットルームで相談してください。個別に相談したい場合は須藤（kou@clear-code.com）に相談してください。