二ヶ月間のApplibotでの内定者アルバイトを終えて

2020.04.13

はじめに

　初めまして。
　Applibotで20卒内定者アルバイトをしていた鈴木と申します。業務ではクライアントエンジニア（Unityエンジニア）をしておりました。

　今回は私がアルバイトをしていた2ヵ月間の振り返り、得られた事について幾つかお話いたします。

自己紹介

　私は大学で材料学を学んでおり、プログラミングの講義等はほぼありませんでした。

　とはいえ私自身が何もエンジニアらしいことをしていなかったわけではなく、趣味としてゲーム作りをしており、Unity、C#に加えてC++を少し扱う事が出来ました。

入社前

　さて、最初に何故Applibotをアルバイト先として選んだのかについてお話します。

　Applibotからは比較的交流が多くなるであろう仕事を提示されました。私はIT企業の働き方について知らない部分が多く、会社を知るためにも多くの社内交流を求めていた部分があったため、お互いが求める業務内容がマッチングし、Applibotに2020年2月から2カ月間お世話になることになりました。

　初めての実務という事もあり、入社直前まで非常に胸が高鳴ったのを覚えています。

入社後

　入社後の事柄について「最初の仕事と失敗」、「紙とペンでの記録」、「より良いUIへの相談例」という3点をお話します。どれも独立したお話で、業務の中で特に得たものが大きいと感じた事柄です。

・最初の仕事と失敗

　さて、私が入社後受けた最初のタスクは担当画面のバグの修正でした。そのバグは他の画面では既に修正されており、コードを読み解きながら修正済みの画面の内容を模倣する事でバグを修正するよう指示を受けました。いきなりですが、ここでアルバイト中の最大の失敗をしました。コードを読み解く部分に集中してしまい、本来自分が触るような部分では無い所まで読む範囲を広げてしまったために与えられた情報に自分自身の理解が追い付かずに非常に時間をかけてしまいました。

　それではなぜこのような事になってしまったのでしょうか。これは私の判断基準のミスがあったのだと考えています。私はこれまで「分からない場合は聞く」という認識で業務をしていましたが、コードの読み解きは読めば読むほどコードを理解していくため、自分自身は着実にゴールへ進んでいる認識がありました。そのため、「分からない」という状態ではないと考えていたのです。とはいえあまりにも時間が掛かってしまっていたので、一旦メンターさんに相談をしたところ、すぐにやるべきことやタスクで触る範囲などを説明してくれたため、加速度的に実装する事が出来ました。

　この話の反省点は「分からない場合は聞く」という基準の設定です。たとえ作業が進んでいて「分からないわけではない」といった状況でも、遅くては意味がありません。期限までに終わらせることが必須となります。そのため私は基準を改めて、「問題があるなら聞く」という基準で以後進める事にしました。この基準の場合、以前より格段に相談する回数は増えましたが、その後のタスクの消化速度をかなり改善する事が出来ました。

・紙とペンでの記録

　私は入社前では「IT企業なのだから紙やペンはあまり使わないだろう」と思っていましたが、PCへのメモと紙へのメモを巧みに使いこなす人が多く、使い分けが大切だと言う事を知りました。特に私は最終的に紙をかなり使っていたと思います。

　私はプランナーの方とよく仕様の確認や調整をしていたことが多く、特にゲーム画面内に何が必要なのか、どのように配置されるのかを話ながら決めて実装していくことが多くありました。プランナーとの認識合わせの中で、“ゲーム画面内のデザイン”を言葉だけで説明するのはとても難解です。そのため私はノートと付箋を持ち歩いて、毎回ゲーム画面を書きながら認識合わせをしていました。ノート以外でも付箋をよく使っていました。付箋にはタスクを書いて進捗管理をしていました。

ノートの利点は
- いつ誰が話し合って何を決めたかを保持しておける
- 話し合いに参加していない人にも情報共有をしやすい
付箋の利点は
- 机に貼ると私が何をしているのかが周囲に伝わる
- 自由に移動できるので進捗管理ができる

　特に新人である私が周囲に「何をしているのか」をアピールできるのは予想以上の利点となりました。メンターの方にも伝える事が出来、非常に有用でした。

　最終日に確認してみると、2カ月で大型のノートで数十ページ、棚の中に入れた使用済みの付箋は山のようになっており、アルバイト中に紙とペンでの記録法を実務で有用に使う事が出来たと考えています。

・より良いUIへの相談例

　私がプランナーの方と直接お話したのは今回が初めての事でした。お話したプランナーの多くが非常に深くゲームを考えている方々で、どの様に実装するべきなのか、ユーザーの為には如何すべきなのかといったお話を多くしていただきました。ここではプランナーの方と相談した事例を一つ紹介したいと思います。ただし、以下は例としての話で実際に業務で行った内容とは異なります。あくまで”考え方の例”としての仮の事例です。

　-アイテム破棄画面-

　今ユーザーはアイテム破棄画面で複数のアイテムをまとめて破棄しようとしています。選択されたアイテムには選択順に番号が割り振られます。現在左上から4つのアイテムを選んでいますが黄色の手裏剣アイテムをユーザーは選択したいと考えています。しかしユーザーは多数のアイテムの中で、黄色の手裏剣アイテムを見失っている状況だと仮定します。

図1. アイテム破棄画面

　そこでユーザーは黄色の手裏剣を探すためにフィルター機能を使い、沢山ある青色の剣を非表示にしました。すると既に選択していた青色の剣も非表示となってしまいました。

　-アイテム破棄画面選択を保持-

　さて、ここからが問題です。非表示のアイテムの選択状態を保持するべきでしょうか。例えば選択状態を保持した画面ではこのようになります。

図2. アイテム破棄画面フィルターON 選択を保持

　保持した場合は図2のように青色の剣のアイテムが画面内では非表示となっていますが、選択状態のまま保持されているため、赤色の槍の選択番号は変わっていません。また、ユーザーは黄色の手裏剣を見つけたことにより、このアイテムも選択状態にしました。画面上では3番目が最大の数字ですが、非表示で4番目の青色の剣を保持しているため、黄色の手裏剣は5番目の選択となります。

　-アイテム破棄画面選択を解除-

　では次に、選択状態を保持せずに解除した場合の画面を見て見ましょう。

図3. アイテム破棄画面フィルターON 選択を解除

　解除した場合は図3のように青色の剣の選択状態が解除されています。また、2番目が解除されたことによって赤色の槍の選択番号が変わっています。こちらでも、ユーザーは黄色の手裏剣を見つけたことにより、このアイテムも選択状態にしました。画面上では2番目が最大の数字で、非表示の青色の剣は選択解除されているため割り込む事も無く、黄色の手裏剣は3番目の選択となります。

　さて、この2通りの選択はどちらの方がより良いでしょうか。結論として言うならば「選択状態を解除」した方がより良いと言う事です。それは何故でしょう。それではこの後に破棄ボタンを押した時と事を考えてみましょう。

　-アイテム破棄画面選択保持の破棄リスト-

　非表示の選択状態を保持したままアイテムを破棄した場合、どのような事が起きるでしょうか。

図4. アイテム破棄画面選択保持の破棄リスト

　図4は非表示でも選択状態を保持した場合の画面です。フィルターをかけていた時に非表示としていたアイテムが急に破棄されましたね。
　ユーザーは確かにそのアイテムを選択をしたのですが、図4では表示されていません。つまり表示と実際の選択アイテムに差異があることになります。

　-アイテム破棄画面選択解除の破棄リスト-

　それでは非表示の選択状態を解除してアイテムを破棄した場合はどうなるでしょうか。

図5. アイテム破棄画面選択解除の破棄リスト

　対して図5は非表示になったアイテムの選択状態を解除した場合の画面です。こちらは非表示のアイテムが急に破棄される事はありません。
　つまり表示と実際の選択アイテムが合致しています。そのため、こちらの方がユーザーが混乱しないため、より良い仕様と言えるでしょう。

　いかがだったでしょうか。この問題には他の解決法も多々ありますが（選択は非表示にしない、破棄確認画面、警告等々）一例として紹介させて頂きました。今回は相談例として書きましたが、実際の仕様もこれに近い形で紙とペンを使って書いていきながらプランナーの方と認識のすり合わせを行い決めていきました。私としてもユーザーを混乱させないように、今後もより一層より良い仕様を考えています。