新卒プログラマー1年の学び

あいさつ

どうも、hakaseです。
今年も今日で最後ですね。いかがお過ごしですか。

私は必至こいてこの記事書いてますｗ

この記事はタイトル通り新卒プログラマーとして一年過ごして得た
学びやら気づきやらを書き連ねていく記事です。

なのでかな～り雑多な感じになるでしょうし
オチもないでしょうが、
まぁ年末年始のちょっぴり暇な時間にでもざらっと流し読みしてもらえればと思います。

あと先に言っておくとコード等はありません。
今回はあくまで学びや気づきという
理屈とか考え方とかそっち系のお話なので。

わかりやすさをとりあえず最優先

私はゲーム業界にプログラマーとして入ったわけですが、
入って研修を受けるまでは可読性＜速度なんだろうなぁと思っていました。

もちろんクリティカルなところではそうなるのですが、
そうじゃない部分では可読性≧速度くらいに落ち着くそうです。

要は速度も大事だけど基本は可読性を優先しようねってことです。

これがなんでかって話ですが、
仕事で作ったコードは基本的にメンテをして数年単位で運用するからです。
そしてそのメンテをするのは往々にして自分以外の誰かです。

自分以外にメンテができないコードは所謂属人化を招き、
イテレーション速度の低下や
ブラック的な労働環境を強いらざるを得ない状況を作り出します。

逆に自分以外でもメンテができるコードならば、
必要になったときできる人がメンテを行えるため、
イテレーションを止めることは無くなりますし、
なんなら改良してよりよいシステムにすることもできるでしょう。

私も他の人の作った機能のテストやメンテ的な仕事をさせてもらいましたが、
読みやすいコードだとわざわざ担当者に話を聞かなくても、
コード読んで自分でサクッと対処できます。数十分～一時間くらい。
(もちろん担当者に確認はしますが)

逆に読みづらいコードだと担当者にがっつり話を聞かなきゃいけなくなって
かなり時間を取られます。
状況にもよりますがそれだけで一日が終わるなんてこともありました。

コードが読みやすいか読みにくいかだけで、
これだけメンテやテストにかかる時間が変わったりするわけです。

よく読みやすいコードが大事だといわれると思いますが、
これだけ時間の差があると散々言われる理由もわかりますよね。

わからなかったらわかりそうな人に投げる

私がやるとわからないからいろんな人に話聞いたり、
ドキュメントを読み漁ったりで一日、二日かかるようなことも、
わかる人に投げると一時間やそこらでできることが往々にしてあります。

もちろん自身の成長のためにあえて投げず自分一人でやるのも大事です。
ただ仕事ってのは勉強や趣味とかと違って期限があります。
期限は守らなくてはなりません。

なので何かやるときはまず手を付ける前に
ざっくりといいのでタスクの見積もりを行い、
無理そうだったらわかりそうな人に投げる。

これをちゃんとやってくださいと先輩方に結構言われました。
(私自身なんでも自分一人で処理しようとしちゃうタイプなので)

何かを作るときはそれが誰の何のためかを考える

基本的にモノづくりってのは誰かの何かのためです。

ゲーム作りだったら
「ゲームを遊んでくれた人」に「楽しい時間を提供するため」でしょう。
(もちろん他のもあるとは思いますが)

例えば開発効率化のためのツールを開発することになったとします。
そして一応要件定義書的な資料があったとします。
これを何も考えず愚直に実装すると大抵の場合そのツールは使われません。

なぜか。
全ての要求がもれなく完璧に書かれた要件定義書は存在しない
からです。

世界中探せばもしかしたらそういう完璧な要件定義書があるかもですが、
少なくとも私と私の先輩方は一度も見たことがありません。

多かれ少なかれもれがあります。
なんだったらそのもれに要求者自体が気づいていないことも多々あります。

そしてそのもれがあるため、
「使いづらい」
「思ってたような使い方ができない」
というようなストレスを与えてしまいツールが放置されます。

じゃあどうすればそのもれを補完することができるか。
ぶっちゃけそこがエンジニアの腕の見せ所です。

誰が使うのか？
アーティスト？
プログラマー？
プランナー？

アーティストが使うなら基本GUIで完結しておくべきでしょう。
不測のツール落ちケアでオートセーブとかあると喜ばれるかもしれません。

プログラマーならマクロやスクリプトで自動化できるようになっているものが多いですね。

プランナーならデータを一覧で見れたり、
ボタン一つデータ更新なんかできたりしたら嬉しいかもしれませんね。

何のために使うのか？
アセットを大量に作るため？
一品物のハイクオリティアセットを作るため？

大量に作るんならプリセットかなんかがあって、
ボタンを二、三回押すだけでアセットが出来上がるべきでしょう。

逆にハイクオリティアセットを作るならば、
編集自由度は限りなく高くし、
プレビュー画面とかもただ見るだけじゃなくて
色々な角度から見れるようにしておいた方がいいでしょう。

どのくらいの頻度で使うのか？
ほぼずっと使うのか？
何か特定のタイミングでのみ使うのか？

ずっと使うなら限りなく少ない操作で目的が達成できるべきでしょう。
またマウスの移動なんかも少ない方がいいでしょうね。
腱鞘炎なりたくないでしょうし。

特定タイミングのみならば操作ミスが起きにくいよう、
押せないボタン等はグレーアウトしてみたり、
ツール内から使用法を確認できるようにしてみたり、
わかりやすさを重視してみるべきでしょう。
また自動化して問題ないなら自動化してしまうのもいいでしょう。
(コードコミット時に自動ビルドするとか)

とまぁざっと書きましたが、
検討するべき項目やそれに対する回答は無数にあります。
この辺は私自身まだまだ勉強中です。

大事なのは誰が何のために使うのかを考えて、
要求者と仕様のすり合わせをちゃんと行うことです。

しっかりすり合わせができていれば、
ユーザー満足度が高いツールができるでしょうし、
逆なら満足度が低いツールになるでしょう。

あとがき

とりあえずざらっとこの1年で言われたことを
なるべく短くわかりやすいようまとめました。

もちろん細かい部分で言われたことやら気づきやらは
もっとあるんですが、
その辺まで書くと記事の文量が膨大になりすぎて、
読む人も書く人もつらいので。

あと細かく書こうとすると
ある程度詳しい業務内容に突っ込んだ形になってしまうので
ちょっと怒られそう・・・

とまぁそんなこんなで今回はこれで以上です。

2020年そこまでたくさん記事は出せませんでしたが、
当ブログを見てくださりありがとうございました。
2021年はなんとか更新頻度上げていきたいと思っていますので、
来年も当ブログをよろしくお願いいたします。

それでは今回はこの辺でノシ

はかせのラボ

私の頭の中を書いていく雑記ブログです