00:01
はい、株式会社ゆめみで取締役をしているキースことくわはらです。 この番組では皆さんのモチベーションが上がることを目指してお届けしていきたいと思います。
第33回はコーディング試験のマイナスポイントについてお話ししたいと思います。
私ですけども採用のお仕事をさせていただいておりまして、面接もそうですし、カジュアルメンターもそうですし、コーディング試験のチェックもしているんですけども、
そのコーディング試験のチェックをしてきて感じていることとか考えていることというのがありましてですね。
特にですね、せっかく停止されたコードがものすごく良かったりとか、設計力も素晴らしかったりする、素晴らしいコードを書いているにも関わらずですけど、別のところで評価を下げてしまうポイントというのがいくつかありまして、
今回はそれについてまとめてお話ししていきたいなと思います。今回の内容ですけど、ゆめみ以外の企業でもやっぱり通用すると思いまして、
ですので、転職とか新卒採用活動を守られている学生の方にも役に立つ話になるかなと思っております。
最初、本題に入る前にちょっとお伝えしたいことがあったので、先にこれだけお話しさせていただきますが、当たり前のことなんですけど、
ちなみに弊社は受託企業ですね。受託企業という前提で聞いていただければありがたいですけど、設計力が高いとか、最新のツール、モダンな開発環境で実装したというお話ですね。
というのはとてもやっぱり評価にはなります。なるんですけども、それ以上にちゃんとまずアプリケーションが動作することと、
あとはですね、チーム開発を意識しているような行動だったりする、コミットだったり、リポジトリの運用だったりということの方が重要かなというふうに企業側で思うと思いますね。
こちらはですね、受託企業でも関係なくですね、事業会社でも自社プロダクトを持っている会社さんでも同じようなことが言えるんじゃないかなと思っております。
というのも、なんでこのアプリケーションを作るかというと、お客さんの問題を解決するとか、お客さんのビジネスを今後展開、加速させるためのシステムとかアプリケーションを作っていくという話なんですけど、
その作ったものに対する労働対価として我々はお金をいただきます。さらにそのいただいたお金の中からいろんなものをやりくりして、最終的にはお給料として我々はいただける話になります。
つまりですね、お客さんを最初に満足させないと、納得していただかないとお金はもらえないんですよね。
というところで、どうやったら満足するとか納得していただくかって話なんですけど、それはもちろん設計がどれだけ優れていたとしても、例えば納品したコードがどれだけ綺麗で、また可動性も高く、高速、また堅牢なコードだったとしてもですね、
03:00
そもそも動作しなければ全く評価されないし、むしろ会社としての評価を下げてしまう形になってしまいますね。
ですので、僕らはやっぱり正しく動くシステムとか正しく動くアプリケーションを作ることがやはり第一の市場命題になりますので、
安定して動作するコードをかける人っていう方がやはり企業としては信頼されますし、重宝もされますし、そういう人を求めるなというふうになんだかんだ思ってしまいますね。
またですね、開発速度が早いに越したことはないんですね。やっぱりそれは早ければ早いほど越したことはないんですけど、
自分のコードっていうのはやっぱり誰かに読まれますし、なので可動性だったり、他の人が私たちの書いたコードのリーディングタイムを減らすとか、
そんなに時間がかからないようなコードを書けているってこともものすごく重要ですので、そういうことを意識していくことが大事かなというふうに思っております。
もちろんですけども、一方で設計力高い人っていう方のコードっていうのはやっぱり大体動作してますし、可動性も高かったり、無駄のないコードになっていることももちろん多いんで、
基本的に設計力高い方っていうのは大体信頼はできますけど、それでもやっぱり動かないと評価にはならないので、ここだけ気をつけていきましょうという話ですね。
ということで、じゃあ具体的に本題に入っていきたいと思いますが、まず一つ目ですね。
一つ目はですね、提出されたリポジトリのReadMeが書かれていない、もしくはそのReadMeの説明が足りないっていうことですね。
やはりこれはちょっと評価を下げてしまいがちですね。
というのも、このリポジトリのアプリケーション、提出されたものがどうやって動くのかとか、
弊社が課題として出している、課題に対した返答としての提出コードであれば、こうやってやれば動くっていうのは大体わかるんですけど、ではないもの。
特に新卒採用のときは、その学生さんが独自で作られたアプリケーションだったりするものを動かすんですけど、
その動かし方がReadMeに書かれていないと、やっぱりこちらとしてもどうやって評価しているかわかんないとか、実際に動かしてみないと評価できないところがあるので、
そういうところが書かれていないとやっぱり困りますねっていう話になってしまいますね。
あとは、このアプリケーション実はまだ80%しか作られていなくて、ここだけちょっと動きませんとか、ここだけ変な動きをするっていうのに注意してくださいとか、
あとは、例えばそのAPIキーの値を、取得情報ですのでここだけは独自に用意してくださいとか、
注意書きがあるのであれば、まだそこも加味して僕らを評価するんですけど、じゃあないってなったときに僕らがこれをプロトグラムを解析して確認しなきゃいけないんですかって話になってしまうんですよね。
それはやはりよろしくないなというふうに思いますし、たまにマスターブランチが動かなくて、実はデベロップブランチは動けませんっていうことが提出者の方に確認を取ったときにそういうふうに言われたこともあって、
それもやっぱり書いてもらわないとこちとしてはわからないよねって話になるので、再転換に丸投げするっていうのはさすがにちょっと違うのかなっていうふうに感じておりますので、
06:02
そういう方っていうとそういう仕事の仕方もするのかなっていうふうに僕らは思ってしまうので、気をつけたほうがいいんじゃないかと思います。
2点目ですね。2点目はGitのコミットメッセージが雑なことが多いなと思って、そこもちょっと評価にやっぱり僕らを入れてしまいますね。
というのも、例えばこのソースコードのコミットメッセージを見ていくと、実はもう1コミットもしくは2コミットで提出されることもあれば、
コミット履歴を見るとパッケージ追加とか修正とかデバッグとかコードを書いてあったりして、そのコミットメッセージだけをパッと見ても結局何をしているのかよくわからなくて、
なんだかんだこのソースコードの中を見て、この人はこのリードでコミットするんだっていうことを結局確認しなきゃいけなくて、
さすがに最終的にはどれだけコミットメッセージが良くても、確認はもちろんするんですけど、
そのコミットメッセージをパッと見て内容がわかるのであれば、それに越したことはないので、そういうところもやっぱり確認はしてしまいますね。
個人開発をされて提出することがやっぱりほとんどですので、気持ちはとてもわかります。僕も。
なんですけど、やっぱり提出するものに関しては、そういうところも意識していただければいいなと思いますし、
こういう見方もあるんですけど、過去の自分っていうのは他人っていう見方がありますよね。
これ多分皆さんもよく経験したことあるかもしれないですけど、例えばこのコード誰が書いたと思って、
なんかすごい酷いコードが見つかって、Gitブレイブ叩いてみると、実は3日前の自分でしたみたいなこともよくあるんですね、この業界では。
ですので、過去の自分は他人というふうに思っていかないといけないですし、
そういうこと、つまり未来の自分を助けることにも繋がりますよね、このGitコミットメッセージっていうのは。
というのもありますので、それはチーム開発でも同様ですね。ということで、他人のことをやっぱり意識すると、
コミットメッセージ、例えば個人開発だとしても意識するほうがいいんじゃないかなと思っております。
そういう癖をつけるほうがもっといいのかなって感じですね。
次は当たり前のことなんですけど、動作しないで提出するようなこともちらほらありますね。
実際に動作の仕方とか動作環境とかっていうのはReadmeに書かれているんですけど、
それ通りに動かしたはずなのに動きませんみたいなことがちょいちょいあるんですね。
例えば読み込みのアプリ内で使っているインポートしているライブラリのパスですね。
パスの指定が間違っていたりとか、あとは単純に変数のスペルミスが間違ったのは提出されるとか。
あとはそのリンターを導入してるんですけど、そのリンターのエラーが起きたまま実は提出されていて、
多分提出された方のローカル環境では多分動いてたと思いますけど、
こちらで手順通りやってみたら動きませんみたいなことがあって、
ちょっとそれはちゃんと確認してくださいねっていうふうになりますし、
そこテストが甘いんだなっていうふうにこちらも受け取ってしまいますので気をつけていただければなと思います。
あとはたまにですけど環境周りの不備があったりもしますね。
ライブラリによってはローカル環境だと動くんですけど、
他の環境だとポート8080が動きませんみたいなこともごく稀にあったりするので、
09:00
そういうこともあるんだったらReadmeとかに記載していただくとか、
そういう確認もしていただければなと思っておりますね。
次はソースコードがレガシーな書き方をされているというところですね。
別にレガシーな書き方が悪いとは別に言う気はさらさらないんですけど、
ただレガシーな書き方で提出されたときにこちらがどう受け取るかと言いますと、
一つ目に技術のキャッチアップをあまりしてない方なのかなっていうふうにやっぱり映ってしまいますね。
とかあとはキャッチアップしない、もしくはその検査をしないとかというふうに感じてしまいますねっていう話になります。
あとは技術というか、僕らが使っている言語とかライブラリーもそうですけど、
というのは日々新しい機能が追加されていたりとか、使用策定がされていたりとか、
またセキュリティパッチが当たったりとか、常に進化することがもう当たり前な時代なんですよね、そういうものは。
ですのでそういうものをちゃんとキャッチアップを追っていくのも大事ですし、
自分たちの持っているスキルとかのアップデートもしていかないと、
やっぱり技術は完成した瞬間から錆び始めますので、
そこを意識して自分たちの技術をしっかり磨いていかなきゃいけないって話になりますね。
なので正しく動作するのはもちろん素晴らしいし、それが当たり前なんですけど、
ただ正しく動くだけでいいって言うともちろんそうではないですよね。
セキュリティ的に脆弱性があると、あるんですけど正しく動いてるといいでしょうって、そういう話にはならないですよね。
例えばですけどそういう話もあるので常にやっぱり技術のキャッチアップはしていただきたいし、
レガシーな書き方っていうのはそれだけでは技術的不細というふうに捉えることもできますので、
あまりそういうコードで提出されるとちょっとこちらとしてもうーんっていうふうに悩んでしまいますね。
続いてですね、デバッグのコードが残っていたりとか、
あとは大量のコメントアウトが残ったまま提出されることもありますね。
これはですけどやっぱり完成度をちょっと意識していただきたいなと思いますね。
というのもやっぱデバッグコードはもちろんデバッグなので、
これ未完成のまま提出されたんですかっていうふうにやっぱりこちらとしては受け取ってしまいます。
そのReadMeに書いてあったと、たとえ書いてあったとしてもそこはやっぱりちゃんと消すものは消していただきたいし、
残してるんだったらちゃんとその残すコメントをそのコメントアウトの上とかに書いていただけるとすごく助かるんですけど、
でもそういうこともなくて単純にこれ消し忘れだよねっていうふうに思ってしまうので、
そういうレベルで提出をするような方なんだなっていうふうにこっちは評価をしてしまう可能性がありますね、
その採点感によっては。
それはちょっと気をつけていただければいいと思いますし、
やはり僕らはですね、お客さんに最終的にそのソースコードを納品物として納品して、
それの対価としてお金をいただくんですけど、
その納品するものに関しては僕らもプロとしての意識が最低限とか持っていますので、
そういうことを企業に入るとやっぱり皆さんにも求められると思います。
ですので、そういうところも加味して、やはりデバッグコードとかはやっぱり消していただいた方がいいのかなと思います。
12:02
次が最後ですね。
最後ですけど、適切にファイルの分割ができていない、
もっと言うと設計がちゃんとされていないみたいなこともごくごくありますね。
なんか1ファイルに全部盛り込んで盛り込んで、
いろんなものを盛り込んで提出されるみたいなこともごくまるにありまして、
これはちょっとなっていう、さすがに評価を下げて下げざるを得ないようなソースコードだと言えますね。
かといってじゃあどういうのがいいのかっていうと、
どういう設計がいいとか、どういう風な分割の仕方、流度がいいのかっていうのは一概にやっぱり言えないですし、
いろんな仕組みとかテクニックとか、求められるアプリケーションのレベル感とか機能によって全然まちまちですので、
それはケースバイケースではあるんですけど、
かといってじゃあ全く考慮できないかというとそんなことはもちろんないですし、
工夫することはいくらでもできますし、
共通化であったりとか、例えばAPIコールするところだけそのモジュールに切り出すとか、
という感じで、保守性とか拡張性を意識するといくらでもやり方はあるなと思っていて、
そういうソースコードはやっぱり見ればわかりますね、こちら側としても。
たぶん仲間の方も読んだときにそういうことを思われると思うんで、
そういうことができていない、分割がちゃんとできていないっていうと、
やっぱりこちらとしては評価を下げざるを得ないような形になりますので、
意識していただければいいのではないかなと思います。
という感じですね、最後にですけど、今ちょっと偉そうにつらつろと発言させていただいたんですけど、
僕も学生の頃こんなことは全部ですけど本当にできていなくてですね、
今も学生の頃のソースコード実は僕今しめとしてまだ持っているんですけど、
過読性がすさまじく悪くて自分のこのコード何のために書いたのっていうのがわかんないところもよくありますね、
とかそのコミットメッセージも自分のためだけにしかやっぱり書いてなくて、
まあさすがに誰かに読ます気もなかったというか、
一応論文とかに載せるソースコードって出てあったんですけど、
その載せたソースコードもやっぱりひどくてですね、
もうちょっと恥ずかしいまま論文として残ってるんで、
もうちょっと自分の黒歴史として思ってるんですけど、
というのでやっぱりとてもじゃないですけど、
人に見てもらうようなご準備っていうのが自分はまだできていなかったっていう反省として持ってます。
ただでも自分もそうやって日々日々社会人になりまして計算をしていろいろ先輩からご指導もいただいて今に至るんですけど、
それを学生のうちからやっぱりできていればそれに越したことないですし、
それを今できてたらやっぱり採用面接とかですごく評価をされると思いますので、
そういう方が少しでも増えればいいなと思ってますし、
皆さんのソースコードのレベルが高まっていただければいいなと思って今日お話しさせていただきました。
少しでも参考になれば幸いです。
はい、というところで今回の収録は以上となります。
また何かご質問またレタートいただけましたらものすごく嬉しいので年々応募お待ちしております。
はい、ではこれ以上となります。
バイバイ。
