非エンジニアのプログラミング研修

2017年4月にアプリボットに配属されたビジネス職の新卒社員に対して、プログラミング研修を実施しました。実施してみて、非常に良い結果を得られたので、非エンジニアがプログラミングを学ぶメリットと、どのような研修を行ったのかをご紹介したいと思います。

●非エンジニアがなぜプログラミングを学ぶのか

サイバーエージェントもアプリボットも「インターネットのサービス」に軸足を置いています。またアプリボットは「モノづくり集団」という点を重視しています。

インターネットサービスのモノづくりにおいて、プロジェクトの中で多大な工数や期間を費やし、プロダクトのクオリティを大きく左右するのが、エンジニアリングでありプログラミングになります。

サービスを企画し、プロジェクトを運営するビジネス職が、このエンジニアリングを少しでも理解できているか否かは、そのままプロダクトのクオリティに直結すると考えています。

特に最近のゲーム開発はゲーム性が高く仕様も複雑になりがちで、開発期間も長くなり、1つのサービスを開発しリリースする、という経験が簡単にできなくなっています。

そのため、この研修を通して小規模ながら、アプリ開発も体験してもらいました。

つくったアプリの発表会の風景

●期間と内容

研修期間は2週間で、環境はUnityを使用。

・ロジック課題

まずはC#で文字列を画面に出力し、変数や四則演算、if文やfor文を利用した条件分岐とループ処理、といった基礎課題です。

このような形でC#のソースファイルに課題が記載してあり、一つ一つ自分でコードを書いて、Unityで実行して確認する、という流れで進んでいきます。

ロジック課題の最後は、簡単なターン制のバトルロジックを組むことです。

基礎課題から豹変した、あまりの丸投げっぷりに、みんな呆然でした(笑)

自分で手を動かせば、ある程度人に聞いて良い、としていたので周りの人を巻き込みながらなんとかクリアしていきます。

先輩だけでなく、新卒同士でも情報交換して教えあっていました

課題の説明を書きすぎず、ある程度考える余地(仕様を確認しないといけない余地)を残すのが良かったです。(決して適当に書いたから抜け漏れがあったわけでは…)

何度かロジックを作り直す経験をすることで、みんな「仕様変更(作り直す)って大変なんだな」とか、「最初の設計が大事」というのを実感していました。

完成したプログラムを実行するとこんな感じになります。

(ややこしいですが、「あく」がコード上のPlayerで「まおう」がEnemyのようです)

2,3日かけてもらう想定だったのですが、1日でみんな終わってしまいました!

コードレビューの様子

コードレビューで細かい不具合の指摘をしたり、人によって書き方が違うことがわかり、その必要性を実感してもらいました。

 

・UI課題

つぎに、UnityのuGUIを使って、画像やテキストの表示、ボタンの制御とアニメーション、表示のOn/Off、といったUIとアニメーションを表示するための課題です。

Scene、Hierarchy、Inspectorなど、Unityエディタの使い方やGameObjectをソースコードで利用するコンポーネントにアタッチする方法を軽く説明したあと、課題を進めてもらいました。

このUI課題では、がんばりがそのまま見た目に反映されるので、みんな楽しそうにやっていました。この後のアプリ課題を通して、UIやアニメーションのクオリティをあげるために、プログラミングと同等以上に地道に手間暇をかける必要があることを実感していきます。

 

・アプリ課題

最後に、ロジック課題の最後につくったバトルロジックに、UIと演出をつけるというアプリ課題です。

用意したベース環境は、タイトル画面、バトル画面、結果画面、のシーンに適当な画像がデフォルトで表示されている状態です。バトル画面には、ターン毎にコルーチンが定期的に呼び出されるようにしていました。(コルーチンの説明や課題等はこれまでにはやっていません)

課題をやり始めてからしばらくした後、重要なお題を出しました。

「課題をこなすだけでは面白くないので、個性を出してください。自分なりの工夫をしてください。発表会的なものもやろうと思うので、つくったものはコードやアニメーション等の実装上の工夫とかを説明できるようにしておいてください」

お題を出す前から独自の仕様を共有してくれていた、フルボディこと北畑くんの写真

せっかくゲームをつくるので、こういった遊び心が大事です。また、スケジュールを優先すべきときもあるが、やれと言われたことだけやったり、つくる人(エンジニア)の都合でクオリティの低い仕上がりにしてはいけない、といった話もしました。

この課題で、企画やUI、アニメーション、プログラミング、と小規模ではありますが全部自分で考え、最後までアプリをつくりきる、という開発の流れを学んでもらいました。

 

●アプリ課題の発表会

研修の最後に自分がつくったゲームの、アプリのプレゼン、コードやアニメーションの実装解説を行ってもらいました。

※アプリの画像は都合によりモザイクなど加工しています。見にくくてすみません。

・『あんちゃん』こと、安井さん

 新規プロジェクトで内定者バイトをしていたツテを活かし、アプリで使うリソースを調達。

シンプルな仕様で、UIやアニメーション等をしっかりと実装し、完成度の高いアプリをつくってくれました。

トップバッターだったこともあってか、コードやAnimatorを解説するときには会場から驚きの声が漏れていました!

あんちゃんは、ロジック課題は誰よりも苦手そうでした(笑)。文字通り足で稼ぐスタイルでがんばっていましたが、カンが良く後半はびっくりするくらいどんどんと理解を深めていきました。

【わからないことは聞きながらでも進める、聞いた後に可能な限り理解する】ということは仕事をする上で本当に大事なスキルだと思います。この調子でがんばっていきましょう。

・『やっさん』こと安本くん

某格闘ゲームをモチーフにした見た目に仕上げ、決着がつくまでのクライマックス感や演出をクオリティ高くつくってくれました。

よく夜遅くまで残っていて、「課題ができていないのではなく、趣味で残ってます」と言っていましたが、そのこだわりは、発表会一の歓声になりました。

やっさんは終始安定している印象で、着実にこなしていく安心感がありました。

発表会の数日前の進捗を見たときは、ここまでクオリティ高く仕上がるとは思っていなかったので、【コツコツと地道に前へ進む力は何よりも強い】ということと、【良い意味で期待を裏切ることの大切さ】、を改めて感じました。

・『ゆっけ』こと、高橋くん

他のメンバがタップで進行するように実装したのに対し、ベース環境通りにオートバトルで実装(オートバトルのほうが実装の仕方が直感的じゃなくて難しかったかもしれません)。ロジックも見た目もシンプルでわかりやすいアプリに仕上げてくれました。

ゆっけは要領よく課題を進めていき、課題の難易度に関わらず効率よく進めていました。【費用対効果】はどんな仕事であっても悩まされる問題なので、今後のプロジェクトでも効率よく開発を進め、【かけるべき所に時間をかける】、ということを意識してがんばって欲しいです。

・『フルボディ』こと、北畑くん

なんと、1vs1から3vs1になっています。しかも相手は全体攻撃をしてきて、ダメージにはちゃんとバラツキがある、というこだわりっぷり。

フルボディは、プログラミング経験があるだけあって、同期のみんなを助けながら、目に見えて楽しく実装していました。最後はアプリ開発の総合的な課題にしてしまったのですが、プログラミングを学ぶという観点では、抜群の難易度の実装に挑戦してくれました。【ロジカルに物事を考える力】は何をやるにも裏切ることはないでしょう。

・『ゆっきー』こと、矢野さん

自分の好きな世界観&キャラを登場させ、OPムービーやキャラの攻撃にはカットインまで実装してくれました。PlayerのAnimatorの複雑さはEnemyの3倍くらいでした!

SGEの「Craft Egg(クラフトエッグ)」から参戦したゆっきー。圧倒的な質問の数で、納得するまで聞く姿勢が印象的でした。何を質問していいかもわからない状況の中、的確に質問を投げていけるのは大事なスキルだと思います。(課題で基礎を教えずにスキップしている内容もあるので)理解が追いつかず、わからないまま進めたところもあると思いますが、【一見当たり前と思えることにも疑問を持つ】ことと【物事の本質を理解しようとする姿勢】は、良い企画を考えるための柱になってくれると思うので、今後も大事にして欲しいです。

授業参観にきた父親のように見守っていたCraft Egg男性陣

 

●まとめ

 発表会は終始和やかなムードで進んでいきました

この研修を通して、ソフトウェア開発がどういうものかを十分に体験できたと思います。

プログラミングを通して、サービスを開発する上で必要な多くの学びがあったのではないでしょうか。

プログラミングを多少なりとも理解したことが、今後の活躍に貢献することを期待します。

また、エンジニアもプロダクト・プロジェクトのため職種理解を進めるような活動をやっていかなければ、と実感しました。

最後に、この研修をやりながら学んでもらったはずの教訓をまとめました。

  • 初日の教訓

・理解する努力、とにかく手を動かして、プログラムを動かして、試しながら学ぶのが大事

・わからなかったら聞く、理解できなくても進めることもコツの一つ、

 わからないことをわかる、わかるためにどうしたらよいかは考える

・理解せずに進んだところは、あとで振り返ることが大事

 

  • ロジック課題の教訓

・課題(仕様)が曖昧で文章が伝わらないと、意図しないものができあがる。バグになる。

・仕様変更に耐えうるつくりと、シンプルなつくり

・コードは人によって書き方が違う、コードレビューの価値

・仕様や実装を後から変えたことによるとりあえず動く実装。リファクタリングの価値

 

  • UI課題の教訓

・参考書やサイトに欲しい情報の全部は載っていない。自分で調べ考える力が必要

 

  • アプリ課題の教訓

・やること(仕様)が丸投げされた場合の絶望感?やりがい?

・何から手を付けていくか

 →やるべきこと、やりたいことを整理

 →まずはシンプルにつくる

・実装者都合で妥協した仕様の功罪

・スピードとクオリティ