ESの内容 - HackMD

# ESの内容期限:1/11 18:00 ## 謝辞ここにしか書けずに申し訳ございませんが、コメントありがとうございました！いただいたコメントをもとにブラッシュアップをし、無事提出できました！ ## 質問内容 ### 学生時代の取り組み ### 自己PR 「時間をかけて問題解決に取り組む粘り強さ」が私の強みです。私は辞書から単語を文字認識により素早く読み取ることを競うゲームの制作を始めました。しかし文字認識の速度が遅く、そのうえで辞書を引くという動作のゲームへの落としどころが見つからないなど問題が多数ありました。そこで現状の問題を洗い出し、まずはこのゲームで何を楽しんでほしいのかの軸を定めました。次に実際に展示をしてプレイをしてもらい、得られたフィードバックをもとに一つ一つ問題を解消しました。またプログラムの設計を行ってから実装に移ることで、改修が容易なコードを書くことができ、ゲームのブラッシュアップを比較的短い期間で行うことができました。このようにゲーム制作においてチームでの制作の方向性の確立やプログラムの設計を書きだして共有することが重要だと考えています。私はしっかりと準備をして、問題を地道に解決することで制作に貢献したいです。 #### Comments > 辞書から単語を文字認識により素早く読み取ることを競うゲーム誰が何をするゲームなのかよくわからない。ゲーム参加者が何をするのかもう少し詳しく。 > ゲーム制作においてチームでの制作の方向性の確立やプログラムの設計を書きだして共有することが重要制作の方向性が確立したからゲーム制作がうまく行ったというのはわかるが，「*チームでの*」の要素が上の例には全く出てきていない。うんｋぽうんぽーこ？ ### 志望した理由小学生の時からものを作ることが好きで、ゲームを作って楽しませる職業に就くことを希望としてました。その思いは絶えず、大学からチームでのゲーム制作を体験し、複数人でのゲーム開発そのものにも面白みを感じました。その結果、将来的に「面白いゲームを開発するための環境をよりよくするためのプログラムの作成」に深く携わりたいと考えました。幼少の時から現在まで貴社のゲームをたくさん楽しんできましたが特に初めての体験について「きっとこの動作をするとこう動くだろう」という動作が期待以上であることに感動しました。またCEDECやブログなども併せて拝見し、問題解決能力や技術力が素晴らしくそして魅力的であるように感じました。幼少から楽しませていただいたこの面白さを実現する開発環境のもとで開発を行い、その開発環境に貢献できることに魅力を感じたため、御社を志望しました。 #### Comments > 面白いゲームを開発するための環境をよりよくするためのプログラムの作成構文解釈上の曖昧さが存在し，少なくとも2通りに解釈できる。「面白いゲームを開発するための環境」なのか，「面白いゲームを開発するためのプログラムの作成」なのか決定不能。 > 幼少の時から...感動しました。適当なところで読点を打つべき。 > 「きっとこの動作をするとこう動くだろう」という動作が期待以上である「*『きっとこの動作をするとこう動くだろう』*」というのを期待と呼ぶのであれば，「動作が期待以上である」で十分なのでは。 * 御社と貴社が混ざっている ### 学生生活において特に力を入れた事柄 ### 部活動、サークル、アルバイトなどの経験から得たこと（リーダー経験があれば、エピソードなども教えてください）もともとはただ目の前のコードのみに集中することだけを意識してプログラムを書いていきましたが、それでは不十分であることをリーダーを経験したことで知りました。大学二年生の時に自分の作成したいゲームに対して制作チームを作ることで初めてリーダーを担当しました。リーダーは幅広い視野をもって仕事をこなす必要があるため、これまでの視野の狭い作業をしているだけでは予想できなかった問題に直面しました。例えば自分はUniRxを用いたMVPパターンによるコードを作成しましたが、他のプログラマーが理解できないためその技術を一部でしか使用できなかったり、マップの制作を依頼したところ、様々なアイテムを効率よく入手して自由に探索するゲームのはずが、制限時間が延長されるアイテムだけが重要視されていてマップは謎解きをするだけの遊びの幅がないようなものが作成されていました。つまりメンバーに必要な情報や制作するゲームの面白さが十分に伝わっていなかったために問題が数多く生じたのです。この経験から、共通の認識を持つためにメンバー間での教育と、どのようにゲームが面白いのかを理解できるように伝えることが大切だと学びました。特にメンバーの教育の観点では、チーム内のプログラマーの知識の範囲を考慮してどのレベルまでの技術を用いるかの判断力に生かされ、ゲームの面白さを伝える大切さは、後の個人制作のゲームのアピール、別のチーム制作での制作方針の議論にて生かされました。アルバイトではミドルウェアの制作会社に勤務し、テスト環境の構築及びテストの実行を担当しました。特にそこでは業務レベルの正確さが必要なため担当の人と不安や気づきについて逐一相談することで、作業するうえで何が重要なのかがより明確になりました。上記の経験から、人との相互理解のためプログラマーであってもしっかりコミュニケーションをやりきることが大切だと考えました。 > 大学二年生の時に自分の作成したいゲームに対して制作チームを作ることで初めてリーダーを担当しました。「大学2年生のときに自らゲームを立案して制作チームを組み，そこでリーダを務めました。」とかでよいのでは。 > つまりメンバーに必要な情報や制作するゲームの面白さが十分に伝わっていなかったために問題が数多く生じたのです。例示→主張ではなく主張→例示のほうが良いと思う。 > 共通の認識を持つためにメンバー間での教育果たしてこれは教育と呼ぶのか。「知識」のことを「認識」と呼ぶのはかなり危ないと思う。ここまでの文章を読むと，「共通の認識」というのは例えば「制作するゲームの面白さ」を指すように感じられるが，後ろの文を読んで初めてこの理解が誤りであることに気がつく。 > コミュニケーションをやりきる些末だが，単に「コミュニケーションをとる」で良いのでは。 * 横書きでは算用数字を使う ## ブラッシュアップ後 ### 学生時代の取り組みプログラミングを中心に幅広く視野を持って、様々な問題に取り組みました。小学生の時にゲーム制作の手段として初めてプログラミングに触れ、それ以来個人や複数人でのゲーム制作を通してプログラミングの腕を磨いていきました。その過程で得たプログラミング技術を、ゲームを制作する以外にも活用しました。その一つとして、所属サークルにてUniRxの使い方を教える講習会を開いたり、学生にプログラミングを教える教室に講師として参加するなど、プログラムを教えることに活用しました。これにより学習を通して経験してほしいことの考察に注力することができました。他にも学部研究にて原子核物理の数値計算を行うプログラムを作成し、正確なプログラムを異なる条件の実験での再利用方法を考えることに生かされました。このように、これまで培ったプログラミング技術を駆使することで、ゲーム制作にとどまらない様々な問題に取り組むことができました。 ### 自己PR 「時間をかけて問題解決に取り組む粘り強さ」が私の強みです。私は辞書から答えとなる単語をより素早く引くことを競うゲームを文字認識の技術を用いて制作しました。しかし文字認識の速度が遅かったり、直接ゲームの面白さを説明をしないと理解してもらえないなど、非常に多くの問題を抱えました。そこでまずは現状の問題を洗い出しました。次にこのゲームで何を楽しんでほしいのかの軸を定め、その軸に沿って問題を一つ一つ解消しました。結果として実際に展示をしたところ、プレイをしてもらった人の半数以上がすんなりとゲームシステムを理解して楽しんでもらうことができました。他にもプログラムを実装する前に緻密に設計を行うことで、ゲームのコード改修を1週間程度と比較的短い期間で行うことができました。このように地道に方針を立てることで複雑な問題を解決することによりチーム制作に貢献したいです。 ### 志望した理由小学生の時からものを作ることが好きで、ゲームを作って楽しませる職業に就くことを希望としてました。その思いは絶えず、大学からチームでのゲーム制作を体験し、複数人でのゲーム開発そのものにも面白みを感じました。その結果、将来的に「面白いゲームを生み出す開発環境を支えるプログラムの作成」に深く携わりたいと考えました。幼少の時から現在まで貴社のゲームをたくさん楽しませていただきました。その中で特に、初めての体験にて行う操作に対するゲーム上での動作が期待以上であることに感動しました。またCEDECやブログなども併せて拝見し、問題解決能力や技術力が素晴らしくそして魅力的であるように感じました。幼少から楽しませていただいたこの面白さを実現する開発環境のもとで開発を行い、その開発環境に貢献できることに魅力を感じたため、貴社を志望しました。 ### 学生生活において特に力を入れた事柄プログラムの設計の考察に、特に力を入れました。大学2年からUnityを用いた複数人でのゲーム開発の機会が増えました。しかし複数人で書いたコードがうまく動かなく、結局1人に任せた方が効率が良いという光景を何度も目の当たりにしました。このことを問題と考え、クリーンアーキテクチャについて技術書で1から学び、作成するプログラムのUML図を書く練習を重ねました。この経験から、開発期間に応じてどの程度設計を構築するべきかの知見が深まりました。実際にUnityを用いた8時間のゲームジャムに3人のプログラマーでチーム参加した際、「仕様からシーケンス図のみを作成する」という設計手法を用いて、一番複雑な自分のコーディング作業が設計込みで7時間で終えることが出来ました。 ### 部活動、サークル、アルバイトなどの経験から得たこと（リーダー経験があれば、エピソードなども教えてください）もともとはただ目の前のコードのみに集中することだけを意識してプログラムを書いていきましたが、それでは不十分であることをリーダーを経験したことで知りました。大学2年生の時に自らゲームを立案して制作チームを作り、そこでリーダーを務めました。リーダーは幅広い視野をもって仕事をこなす必要があります。そのためこれまでの視野の狭い作業をしているだけでは予想できなかった、メンバーに必要な情報や制作するゲームの面白さが十分に伝わらないという問題に直面しました。例えば私はUniRxを用いたMVPパターンによるコードを作成しましたが、他のプログラマーが理解できないためその技術を一部でしか使用できませんでした。またマップの制作を依頼したところ、様々なアイテムを効率よく入手して自由に探索するゲームのはずが、制限時間が延長されるアイテムだけが重要視されていてマップは謎解きをするだけの遊びの幅がないようなものが作成されていました。この経験から、共通の知識を持つためにメンバー間で情報共有することと、どのようにゲームが面白いのかを理解できるように伝えることが大切だと学びました。特にメンバー間で情報共有することの観点では、チーム内のプログラマーの知識の範囲を考慮してどのレベルまでの技術を用いるかの判断力に生かされ、ゲームの面白さを伝える大切さは、後の個人制作のゲームのアピール、別のチーム制作での制作方針の議論にて生かされました。一方、アルバイトではミドルウェアの制作会社に勤務し、テスト環境の構築及びテストの実行を担当しました。特にそこでは業務レベルの正確さが必要なため担当の人と不安や気づきについて逐一相談することで、作業するうえで何が重要なのかがより明確になりました。上記の経験から、人との相互理解のためプログラマーであってもしっかりコミュニケーションをとることが大切だと考えました。