脱力駆動開発記

ゲームアプリを作るエンジニアの技術メモ

MENU

Ruby合宿に参加してきました

3/3~7までruby合宿に参加して参りました。
ただいま帰りの新幹線です。最高に楽しかったのでとりあえず概要やら感じた事やらをつらつらと書いて行きます。

ruby合宿とは?
"このRuby合宿は、 大学、高等専門学校、高等学校の学生等を対象に、松江市在住のまつもとゆきひろ氏が開発したオープンソースプログラミング言語Ruby」を学ぶ、5日間の合宿形式の講座となります。 また、県内のIT企業の方々にも参加いただき、参加学生と意見交換を行うなど、交流する機会も設けることとしています。"
http://www.rubycamp.jpより


f:id:cocokyoro:20140308031044p:plain

目次

  • 新テーマ「島根PRプログラム」
  • チームメンバーと割り振り
  • 自分の役割
  • 問題点
  • 学び得たこと
  • 成果物
  • 今後
  • まとめ
・新テーマ「島根PRプログラム」

例年の合宿では島根関連のゲームの作成をテーマとしていましたが、今年は島根県PRプログラムというテーマでした。見るだけのプログラムでもよし、ユーザーの入力を受け付けてもよしということで自由度が広がりました。

例年のようにゲームではなくPRプログラムという形式をとった理由としては、テーマをゲームにするとどうしてもチームメンバー間で負担が偏ってしまうからだそうな。偏るというか、5、6人のチームのうちコーディングをするのが2人で他のメンバーは素材集めやプレゼン資料作りに終始してしまうことがざらにあったそうで。
それではいかんということで今年はテーマを一新し、PRプログラムにしたようです。

それと関連して合宿初日に「絶対にチームメンバー全員がコーディング作業に携わる事」という条件が提示されました。
で、それを補助するためのツールとしてシーンの遷移を簡単に行えるモジュールを使う事を推奨された。シーン1➡シーン2➡シーン3という風に担当箇所を切り分けることができるので、各シーンごとにそれぞれが自分のレベルにあったコーディングをした上で、最終的に一つの連続した作品ができるということですね。

・チームメンバーと割り振り

僕のチームは全部で5人。なんと小学生がいました。びっくり。
自分が最年長だったことと、一日目の基礎講義を終えた段階で他薦があったことも相まって自分がチームのリーダを務めることになりました。メンバーはRubyはほぼ未経験といった感じで、Ruby歴は自分が一番長いようでした。

作るアプリについてはムービー形式のものにして、5つのシーンに分割してそれぞれ担当すればいいかなと思っていましたが、ゲーム作成を強く希望するメンバーが一人いたため、オープニング➡ゲーム➡エンディングという3つのシーンに分け、それぞれオープニング:2人、ゲーム:2人、エンディング:2人という割り振りで作業を開始しました。自分もゲームやってみたかったのでちゃっかり担当になってます。

でそんなこんなで2日目から開発がスタートしたのだった。

・自分の役割

自分はリーダーということで、以前バイトでチーム開発をした際に得た反省を存分に活かしてやろうといきごんでいました。
・メンバーに仕事がない状況を作らない
・困っているときはすぐに発信してもらう
・一定時間ごとに進捗のシェアを行い過剰な負担がかかっている人がいないかを確認する(いた場合は仕事の再分配)
といった点をこころがけていました。

・問題点

チーム全体としての雰囲気だったり、作業量の分配とかは問題なく順調に進んでいたのですが、一番問題だったのはあれですね。ゲーム箇所のマージですね。
まあもちろんマージが簡単にはいかないというのはもちろん分かっていましたし、有る程度は覚悟していました。しかしもう一人が自分の全く想定していなかった構造で実装していたため、そのコードを理解するのに非常に時間がかかってしまいました。もっと早い段階でお互いに話こんでクラス構造を決めてから作業に入ればよかったという反省が。

あともう一つ、これは有る意味嬉しい誤算ではあるんですが、チームメンバーはrubyほぼ未経験にも関わらずコードの理解が早く、振った仕事が予想よりも早く終わっていました。作業はたくさん残っているためそれを適宜次のタスクとしてやってもらっていたのですが、当初の条件である「全員がコーディングに携わっている」という状況をなるべく崩さないようにするため、コーディング以外の仕事を後回しにし結果として積み残しの量が多くなってしまい自室で夜に消化するということが何度か。そこはもう少し要領よくすべきだったと思っています。

・学び得た事

まず、講師陣の方々がかっこよすぎた。
・エラー発生時の対処法
vimの知らなかったコマンド
・Procクラスの使い方
・@とself.の使い
・時間差処理の考え方
・クラスはどこまで抽象化すべきか
etc..
と、教わったことは山のようにあります。ニフティキャンプでの反省を活かし、講師の方がいるときには常に質問するテーマがあるように事前に準備していました。夜に自室で作業を進めて次の日の講義中に質問する、というフローを3日間続けられました。(睡眠時間は犠牲になったのだ

単純な知識以外で得た事は、なんとなくですがチームにおける理想のリーダー像が描けたことですかね。(描けただけでこの合宿中では残念ながら実行できませんでしたが
合宿以前はリーダーは他のメンバーに比べ成果物のイメージをより具体的に持っているべきだと考えていました。しかしそれはリーダーがやるべき当たり前の仕事であって、真にやるべきだったのは、そのイメージをチームメンバーにより正確に伝え共有することだという結論に至りました。
というのも、僕の伝え方が悪かったせいでメンバーの一人が勘違いをして必要のない機能を作ろうとしていたということがありました。僕がしっかり完成品のイメージを伝えることができていたなら、「それはおかしくないか?」とメンバーが勘違いに気づけるはずだったのです。
今後は「リーダーだから皆よりも一歩先の考えを」とかではなく、「自分の考えがメンバーにとって既知のものであるように」という姿勢でいきたいです。

・成果物

前述したように僕らの班はオープニング➡ゲーム➡エンディングの構成でプログラムを作成しました。
ゲーム部分は避けゲーになっています。
後日githubにて公開されるようです。
僕のコードは発表前日のデスマによりスパゲッティです。リファクタリング

・今後

<僕の今後>
Rubyもっと勉強します。
普段は「詰まったら調べて解決➡そこで知った知識を記録して蓄積」
という流れでコーディングしているため、体系的な知識に穴があることに今回気づきました。
一つの参考書を穴があく程読むというのは大学受験の倫理の教科書以来やっていないのですが、Rubyに関してはそのような学習をしたいというモチベーションが今高いです。

Ruby合宿の今後>
次回からのruby合宿ではなんとレゴのマインドストームを用いて組み込みのプログラムをやるかも、ということで今後も目を離せません。Rubyに少しでも興味ある人は是非参加することをお勧めします。
Ruby合宿では事前に基礎講義をやるため参加者はある程度Rubyのことを分かったうえで参加するのですが、チーム開発となると今の基礎講義だけでは足りてない要素があるというのを感じました。それはrubyの記法に関する基礎知識です。チームでの開発を行う合宿ならば、コーディングする上でのルールをちゃんと提供するのもいいんじゃないかなという。

@@hoge =2 #下の方で使う
.
.
keisan(@@hoge,3) #なんかこれ消すと動かん

みたいなコードを一人一人が書いてるとさすがにチームでの開発は難しいです。でも、何がいけないのか、どうあるべきなのか、変数はただの箱ではなくどのような値であるかを示す必要があり…だとか、クラスの頭は大文字で複数単語が続く場合は…とかいった資料はあらかじめ作っておいてもいいのかなーとか思いました。
(もちろん教科書にも書いてあるし事前講義でも部分的に触れてはいるのですが、体系的にまとめとくと重要性も伝わるのかなという
まあぐぐれば出てくるのですけどね http://shugo.net/ruby-codeconv/codeconv.html

・まとめ

本当に楽しい5日間でした。卒業直前という学生としては貴重な時期を使っての参加でしたが、それを補って余りあるバックがありました。
チームの皆、他の参加者の皆さん、イーストバックの方々、サンレイクの方々、及び関わった全ての人に感謝でいっぱいです。

以上です。
帰りの新幹線でばーっと書いたので読みにくい箇所もあるかもしれませんがご勘弁をm(__)m